Re: [RFC/RFT PATCH] gpiolib: reverse-assign the fwnode to struct gpio_chip

[Linus Walleij]

On Sat, Oct 7, 2023 at 9:45 AM Andy Shevchenko <andy@xxxxxxxxxx> 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