Le 25/08/2022 à 15:36, Linus Walleij a écrit :

On Thu, Aug 18, 2022 at 2:46 PM Arnd Bergmann [off-list ref] wrote:

quoted

On Thu, Aug 18, 2022 at 2:25 PM Linus Walleij [off-list ref] wrote:

quoted

quoted

git grep 'base = -1' yields these suspects:

arch/arm/common/sa1111.c:       sachip->gc.base = -1;
arch/arm/common/scoop.c:        devptr->gpio.base = -1;
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:      gpt->gc.base = -1;
arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c: gc->base = -1;

That's all! We could just calculate these to 512-ngpios and
hardcode that instead.

How do the consumers find the numbers for these four?

For SA1111 the chip gets named "sa1111" and some consumers actually
use proper machine descriptions, maybe all?

arch/arm/mach-sa1100/jornada720.c:              GPIO_LOOKUP("sa1111",
0, "s0-power", GPIO_ACTIVE_HIGH),
arch/arm/mach-sa1100/jornada720.c:              GPIO_LOOKUP("sa1111",
1, "s1-power", GPIO_ACTIVE_HIGH),
(...)

For Scoop it is conditionally overridden in the code. I guess always
overridden.

For powerpc these seem to be using (old but working) device tree
lookups, so should not be an issue.

Sadly I'm not 100% sure that there are no random hard-coded
GPIO numbers referring to whatever the framework gave them
at the time the code was written :(

On my PPC board, the one before the last looks suspicious ....

[    0.573261] gpio gpiochip0: registered GPIOs 496 to 511 on 
/soc@ff000000/cpm@9c0/gpio-controller@950
[    0.577460] gpio gpiochip1: registered GPIOs 464 to 495 on 
/soc@ff000000/cpm@9c0/gpio-controller@ab8
[    0.586011] gpio gpiochip2: registered GPIOs 448 to 463 on 
/soc@ff000000/cpm@9c0/gpio-controller@960
[    0.591057] gpio gpiochip3: registered GPIOs 432 to 447 on 
/soc@ff000000/cpm@9c0/gpio-controller@970
[    0.595979] gpio gpiochip4: registered GPIOs 400 to 431 on 
/soc@ff000000/cpm@9c0/gpio-controller@ac8
[    0.629292] gpio_stub_drv gpiochip5: registered GPIOs 384 to 399 on 
/localbus@ff000100/cpld-cmpc@5,0000000/gpio-controller@2
[    0.636556] gpio_stub_drv gpiochip6: registered GPIOs 368 to 383 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@00
[    0.639503] gpio_stub_drv gpiochip7: registered GPIOs 352 to 367 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@02
[    0.642434] gpio_stub_drv gpiochip8: registered GPIOs 336 to 351 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@04
[    0.645257] gpio_stub_drv gpiochip9: registered GPIOs 320 to 335 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@10
[    0.648230] gpio_stub_drv gpiochip10: registered GPIOs 304 to 319 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@20
[    0.651070] gpio_stub_drv gpiochip11: registered GPIOs 288 to 303 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@22
[    0.653986] gpio_stub_drv gpiochip12: registered GPIOs 272 to 287 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@24
[    0.656807] gpio_stub_drv gpiochip13: registered GPIOs 256 to 271 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@26
[    0.659761] gpio_stub_drv gpiochip14: registered GPIOs 240 to 255 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@28
[    0.662622] gpio_stub_drv gpiochip15: registered GPIOs 224 to 239 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@2A
[    0.665454] gpio_stub_drv gpiochip16: registered GPIOs 208 to 223 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@2C
[    0.673552] gpio_stub_drv gpiochip17: registered GPIOs 192 to 207 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@30
[    0.677281] gpio_stub_drv gpiochip18: registered GPIOs 176 to 191 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@32
[    0.680235] gpio_stub_drv gpiochip19: registered GPIOs 160 to 175 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@40
[    0.685876] gpio_stub_drv gpiochip20: registered GPIOs 144 to 159 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@42
[    0.694431] gpio_stub_drv gpiochip21: registered GPIOs 128 to 143 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@44
[    0.697257] gpio_stub_drv gpiochip22: registered GPIOs 112 to 127 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@50
[    0.700220] gpio_stub_drv gpiochip23: registered GPIOs 96 to 111 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@52
[    0.703183] gpio_stub_drv gpiochip24: registered GPIOs 80 to 95 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@54
[    0.708226] gpio_stub_drv gpiochip25: registered GPIOs 64 to 79 on 
/localbus@ff000100/fpga-m@4,0000000/gpio-controller@34
[    0.756817] gpio gpiochip26: registered GPIOs 0 to 2 on generic
[    4.530397] gpio gpiochip27: registered GPIOs 36 to 63 on max7301

Another reason the base is assigned from above (usually
from 512 and downward) is that the primary SoC GPIO usually
want to be at base 0 and there is no guarantee that it will
get probed first. So hard-coded GPIO bases go from 0 -> n
and dynamically allocateed GPIO bases from n <- 512.

Then we hope they don't meet and overlap in the middle...

quoted

quoted

and in that case it is better to delete the use of this function
altogether since it can not fail.

S32_MAX might be a better upper bound. That allows to
just have no number assigned to a gpio chip. Any driver
code calling desc_to_gpio() could then get back -1
or a negative error code.

Making the ones that are invalid today valid sounds like
a step backwards to me if the goal is to stop using
gpio numbers and most consumers no longer need them.

OK I get it...

Now: who wants to write this patch? :)

Christophe? Will you take a stab at it?

Which patch should I write ?

Christophe