On Wed, Jul 29, 2026 at 10:49 PM Christophe Leroy (CS GROUP) <[email protected]> wrote: > > > > Le 29/07/2026 à 20:32, Rosen Penev a écrit : > > On Wed, Jul 29, 2026 at 3:55 AM Madhavan Srinivasan <[email protected]> > > wrote: > >> > >> > >> On 6/2/26 2:56 PM, Rosen Penev wrote: > >>> On Tue Jun 2, 2026 at 12:51 AM PDT, Bartosz Golaszewski wrote: > >>>> On Tue, 2 Jun 2026 07:01:29 +0200, Rosen Penev <[email protected]> said: > >>>>> Use gpio_generic_chip_init() to set up the PPC44x GPIO chip > >>>>> instead of open-coding the basic get, set, locking and state handling. > >>>>> > >>>>> Keep the PPC44x-specific direction callbacks because they still need to > >>>>> program ODR and the OSR/TSR registers around the generic data and > >>>>> direction registers. > >>>>> > >>>>> Assisted-by: Codex:GPT-5.5 > >>>>> Signed-off-by: Rosen Penev <[email protected]> > >>>>> --- > >>>> ... > >>>> > >>>>> @@ -124,10 +102,11 @@ static int > >>>>> ppc4xx_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val) > >>>>> { > >>>>> struct ppc4xx_gpio_chip *chip = gpiochip_get_data(gc); > >>>>> + struct gpio_generic_chip *gen_gc = &chip->chip; > >>>>> struct ppc4xx_gpio __iomem *regs = chip->regs; > >>>>> unsigned long flags; > >>>>> > >>>>> - spin_lock_irqsave(&chip->lock, flags); > >>>>> + gpio_generic_chip_lock_irqsave(gen_gc, flags); > >>>> If you're already doing it, can you use lock guards too? > >>> Sure. btw, I avoided placing > >> > >> Do you have plan to address this comment in v2 > > Yeah I have it fixed locally. > > You should probably put patch > https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/ > as first patch in this series in order to enable applying the fix to > 6.18 without applying the entire series and to avoid any future conflict. Not sure what you mean by this.
I assume the simplest way to proceed is to wait for that patch to be merged first and then proceed with this patch series. > > Christophe > > > > > > I'm not sure if this has to do through the PPC or GPIO tree. > >> > >> Maddy > >>> > >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20260517063754.21819-1-rosenp%40gmail.com%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C2ac0ec525c7045cd969508deed9fc7e0%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639209467691381845%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iqGebSy%2BbKMBFZz%2FZwZ9N2Jf8v63FkGPNhrdUf864fE%3D&reserved=0 > >>> > >>> in the beginning of the series. My thinking is that's for older kernels. > >>> I believe either the generic API or devm_gpiochip_add_data fixes this. > >>>> Bart > >>> >
