Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
MIME-Version: 1.0
References: <20231006115147.18559-1-brgl@bgdev.pl> <ZSAIUVAQ6ifi8LTL@smile.fi.intel.com>
 <CAMRc=MdrLSPCEsQ6OEgRX-7Wh7ka+Rczja=QjY-srozj3cz68w@mail.gmail.com> <ZSEMnqAynnrfBxX1@smile.fi.intel.com>
In-Reply-To: <ZSEMnqAynnrfBxX1@smile.fi.intel.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Sat, 7 Oct 2023 17:53:26 +0200
Message-ID: <CACRpkdYTQ52fT5iiUXcO_Le2nYp5akdEPuq8brrSU+C0LFeOAQ@mail.gmail.com>
Subject: Re: [RFC/RFT PATCH] gpiolib: reverse-assign the fwnode to struct gpio_chip
To:     Andy Shevchenko <andy@kernel.org>
Cc:     Bartosz Golaszewski <brgl@bgdev.pl>, linux-gpio@vger.kernel.org,
        linux-kernel@vger.kernel.org, Dipen Patel <dipenp@nvidia.com>,
        Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sat, Oct 7, 2023 at 9:45=E2=80=AFAM Andy Shevchenko <andy@kernel.org> wr=
ote:

> 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 descri=
ptions
> of the GPIO controller, when it's 1:1 to the banks and when it's one devi=
ce
> 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 =3D "...";
(...)
   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 fo=
r
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