linux-kernel - Re: [RFC/RFT PATCH] gpiolib: reverse-assign the fwnode to 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]

Date:   Sat, 7 Oct 2023 17:53:26 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andy Shevchenko <andy@...nel.org>
Cc:     Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org, Dipen Patel <dipenp@...dia.com>,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: Re: [RFC/RFT PATCH] gpiolib: reverse-assign the fwnode to struct gpio_chip

On Sat, Oct 7, 2023 at 9:45 AM Andy Shevchenko <andy@...nel.org> wrote:

> The providers decide themselves
> if they want to have any specific device node for the chip or inherit
> it from the physical hardware. Note, there are two types of the FW descriptions
> of the GPIO controller, when it's 1:1 to the banks and when it's one device
> with list of children, one per bank. Due to this differences we have
> this field in the GPIO chip to begin with.

So this is the real problem right, for example a pin controller with
six sub-nodes that are GPIO chips but not necessarily devices.

In DT terms:

pinctrl@0 {
   compatible = "...";
(...)
   gpio@0 {
        (...)
    };
    gpio@1 {
        (....)
    };
(...)
    gpio@5 {
        (....)
    };
};

And now each of these subnodes spawn a gpio_chip and a gpio_device
and now the big question is what fwnode (in this example of node) to use for
each.

I was under the impression that despite the main device does not
spawn subdevices in the Linux device model, the subdevices always
have their individual fwnode, and when we create the gpio_chip for
it, that creates a gpio_device and that *is* the device for that fwnode,
if there is no corresponding say platform_device or similar.

So e.g. assigning the fwnode of the parent (the pin controller in this
example) to these gpio_chips flattens the hierarchy and that
would be a *bug* in my mind (but maybe not in everyone else's
mind).

But IIUC what you are saying is that sometimes there are drivers that
do this?

Yours,
Linus Walleij