linux-kernel - Re: [PATCH v11 2/6] gpiolib: allow to specify the firmware node in struct gpio

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: <CAMRc=Mf5d1i34eBez+pOYjjdyfRL9N_ha_==Cn1rANr=2CB9aQ@mail.gmail.com>
Date:   Tue, 30 Nov 2021 21:25:35 +0100
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Kent Gibson <warthog618@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Shuah Khan <shuah@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v11 2/6] gpiolib: allow to specify the firmware node in
 struct gpio_chip

On Tue, Nov 30, 2021 at 5:15 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Tue, Nov 30, 2021 at 04:41:23PM +0100, Bartosz Golaszewski wrote:
> > Software nodes allow us to represent hierarchies for device components
> > that don't have their struct device representation yet - for instance:
> > banks of GPIOs under a common GPIO expander. The core gpiolib core
>
> core .. core ?!
>
> > however doesn't offer any way of passing this information from the
> > drivers.
> >
> > This extends struct gpio_chip with a pointer to fwnode that can be set
> > by the driver and used to pass device properties for child nodes.
> >
> > This is similar to how we handle device-tree sub-nodes with
> > CONFIG_OF_GPIO enabled.
>
> Not sure I understand the proposal. Can you provide couple of (simplest)
> examples?
>
> And also it sounds like reinventing a wheel. What problem do you have that you
> need to solve this way?
>
> ...
>
> > +#if IS_ENABLED(CONFIG_OF_GPIO)
> > +     if (gc->of_node && gc->fwnode) {
> > +             pr_err("%s: tried to set both the of_node and fwnode in gpio_chip\n",
> > +                    __func__);
> > +             return -EINVAL;
> > +     }
> > +#endif /* CONFIG_OF_GPIO */
>
> I don't like this. It seems like a hack right now.
>
> Is it possible to convert all GPIO controller drivers to provide an fwnode
> rather than doing this? (I believe in most of the drivers we can drop
> completely the of_node assignment).
>

Yes, it's definitely a good idea but I would be careful with just
dropping the of_node assignments as callbacks may depend on them
later. Also it's not just about the gpio_chip of_node assignment -
drivers also use a bunch of OF APIs all around the place. I would
prefer that it be done one by one and every modified driver be tested.

Bart