Static allocatin is deprecated and may cause probe mess,
if probe order is unusual.
like this example
[ 2.553833] twl4030_gpio twl4030-gpio: gpio (irq 145) chaining IRQs 161..178
[ 2.561401] gpiochip_find_base: found new base at 160
[ 2.564392] gpio gpiochip5: (twl4030): added GPIO chardev (254:5)
[ 2.564544] gpio gpiochip5: registered GPIOs 160 to 177 on twl4030
[...]
[ 2.692169] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[ 2.697357] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[ 2.703643] gpiochip_find_base: found new base at 178
[ 2.704376] gpio gpiochip6: (omap-gpmc): added GPIO chardev (254:6)
[ 2.704589] gpio gpiochip6: registered GPIOs 178 to 181 on omap-gpmc
[...]
[ 2.840393] gpio gpiochip7: Static allocation of GPIO base is deprecated, use dynamic allocation.
[ 2.849365] gpio gpiochip7: (gpio-160-191): GPIO integer space overlap, cannot add chip
[ 2.857513] gpiochip_add_data_with_key: GPIOs 160..191 (gpio-160-191) failed to register, -16
[ 2.866149] omap_gpio 48310000.gpio: error -EBUSY: Could not register gpio chip
So probing was done in an unusual order, causing mess
and chips not getting their gpio in the end.
Signed-off-by: Andreas Kemnade <[email protected]>
---
maybe CC stable? not sure about good fixes tag.
drivers/gpio/gpio-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 80ddc43fd875..f5f3d4b22452 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1020,7 +1020,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc,
if (!label)
return -ENOMEM;
bank->chip.label = label;
- bank->chip.base = gpio;
+ bank->chip.base = -1;
}
bank->chip.ngpio = bank->width;
--
2.30.2
On Fri, Jan 13, 2023 at 9:59 PM Andreas Kemnade <[email protected]> wrote:
>
> Static allocatin is deprecated and may cause probe mess,
> if probe order is unusual.
>
> like this example
> [ 2.553833] twl4030_gpio twl4030-gpio: gpio (irq 145) chaining IRQs 161..178
> [ 2.561401] gpiochip_find_base: found new base at 160
> [ 2.564392] gpio gpiochip5: (twl4030): added GPIO chardev (254:5)
> [ 2.564544] gpio gpiochip5: registered GPIOs 160 to 177 on twl4030
> [...]
> [ 2.692169] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> [ 2.697357] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> [ 2.703643] gpiochip_find_base: found new base at 178
> [ 2.704376] gpio gpiochip6: (omap-gpmc): added GPIO chardev (254:6)
> [ 2.704589] gpio gpiochip6: registered GPIOs 178 to 181 on omap-gpmc
> [...]
> [ 2.840393] gpio gpiochip7: Static allocation of GPIO base is deprecated, use dynamic allocation.
> [ 2.849365] gpio gpiochip7: (gpio-160-191): GPIO integer space overlap, cannot add chip
> [ 2.857513] gpiochip_add_data_with_key: GPIOs 160..191 (gpio-160-191) failed to register, -16
> [ 2.866149] omap_gpio 48310000.gpio: error -EBUSY: Could not register gpio chip
>
> So probing was done in an unusual order, causing mess
> and chips not getting their gpio in the end.
>
> Signed-off-by: Andreas Kemnade <[email protected]>
> ---
> maybe CC stable? not sure about good fixes tag.
>
> drivers/gpio/gpio-omap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 80ddc43fd875..f5f3d4b22452 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1020,7 +1020,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc,
> if (!label)
> return -ENOMEM;
> bank->chip.label = label;
> - bank->chip.base = gpio;
> + bank->chip.base = -1;
> }
> bank->chip.ngpio = bank->width;
>
> --
> 2.30.2
>
This could potentially break some legacy user-space programs using
sysfs but whatever, let's apply it and see if anyone complains.
Bart
On Fri, Jan 13, 2023 at 9:59 PM Andreas Kemnade <[email protected]> wrote:
> Static allocatin is deprecated and may cause probe mess,
> if probe order is unusual.
>
> like this example
> [ 2.553833] twl4030_gpio twl4030-gpio: gpio (irq 145) chaining IRQs 161..178
> [ 2.561401] gpiochip_find_base: found new base at 160
> [ 2.564392] gpio gpiochip5: (twl4030): added GPIO chardev (254:5)
> [ 2.564544] gpio gpiochip5: registered GPIOs 160 to 177 on twl4030
> [...]
> [ 2.692169] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> [ 2.697357] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> [ 2.703643] gpiochip_find_base: found new base at 178
> [ 2.704376] gpio gpiochip6: (omap-gpmc): added GPIO chardev (254:6)
> [ 2.704589] gpio gpiochip6: registered GPIOs 178 to 181 on omap-gpmc
> [...]
> [ 2.840393] gpio gpiochip7: Static allocation of GPIO base is deprecated, use dynamic allocation.
> [ 2.849365] gpio gpiochip7: (gpio-160-191): GPIO integer space overlap, cannot add chip
> [ 2.857513] gpiochip_add_data_with_key: GPIOs 160..191 (gpio-160-191) failed to register, -16
> [ 2.866149] omap_gpio 48310000.gpio: error -EBUSY: Could not register gpio chip
>
> So probing was done in an unusual order, causing mess
> and chips not getting their gpio in the end.
>
> Signed-off-by: Andreas Kemnade <[email protected]>
Dangerous but beautiful change. Let's be brave.
Reviewed-by: Linus Walleij <[email protected]>
> maybe CC stable? not sure about good fixes tag.
I wouldn't do that from the outset. If there are no problems
for a few kernel releases we can think about doing that.
Yours,
Linus Walleij
* Bartosz Golaszewski <[email protected]> [230116 08:38]:
> On Fri, Jan 13, 2023 at 9:59 PM Andreas Kemnade <[email protected]> wrote:
> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> > index 80ddc43fd875..f5f3d4b22452 100644
> > --- a/drivers/gpio/gpio-omap.c
> > +++ b/drivers/gpio/gpio-omap.c
> > @@ -1020,7 +1020,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, struct irq_chip *irqc,
> > if (!label)
> > return -ENOMEM;
> > bank->chip.label = label;
> > - bank->chip.base = gpio;
> > + bank->chip.base = -1;
> > }
> > bank->chip.ngpio = bank->width;
> >
> > --
> > 2.30.2
> >
>
> This could potentially break some legacy user-space programs using
> sysfs but whatever, let's apply it and see if anyone complains.
Worth a try for sure, fingers crossed. I guess /sys/class/gpio will
break at least.
Regards,
Tony
Hi,
On Mon, 16 Jan 2023 15:24:42 +0100
Linus Walleij <[email protected]> wrote:
> > maybe CC stable? not sure about good fixes tag.
>
> I wouldn't do that from the outset. If there are no problems
> for a few kernel releases we can think about doing that.
I have the impression that numbering somehow changed here.
In earlier kernel, omap_gpmc started at >400 and gpio-twl4030 also
(both base = -1 now), so no conflicts with the static allocation of
the soc-gpios. I have not investigated/bisected yet. But perhaps
additionally, a patch ensuring that dynamic allocation starts at
a higher number to not interfer with static numbering with be interesting.
That could then be more easily backportable.
Regards,
Andreas