lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFLxGvyX1Q8qGXkWW+JiyQSfP=1dFzeZ7C4OCJHk2pFGX7zygw@mail.gmail.com>
Date: Thu, 29 Aug 2024 10:52:07 +0200
From: Richard Weinberger <richard.weinberger@...il.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Andreas Kemnade <andreas@...nade.info>, grygorii.strashko@...com, ssantosh@...nel.org, 
	khilman@...nel.org, linus.walleij@...aro.org, linux-omap@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpio: omap: use dynamic allocation of base

On Mon, Jan 16, 2023 at 9:54 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> On Fri, Jan 13, 2023 at 9:59 PM Andreas Kemnade <andreas@...nade.info> 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 <andreas@...nade.info>
> > ---
> > 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.

FWIW, this broke users pace on my side.
Not a super big deal, I'll just revert this patch for now.
Maybe the application in question can get rewritten to find the gpio by label.

-- 
Thanks,
//richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ