Re: [PATCH v11 2/6] gpiolib: allow to specify the firmware node in struct gpio_chip

[Andy Shevchenko]

On Wed, Dec 01, 2021 at 02:11:28PM +0100, Bartosz Golaszewski wrote:
> On Tue, Nov 30, 2021 at 10:04 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> >
> > On Tue, Nov 30, 2021 at 10:00 PM Andy Shevchenko
> > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > >
> > > On Tue, Nov 30, 2021 at 09:25:35PM +0100, Bartosz Golaszewski wrote:
> > > > On Tue, Nov 30, 2021 at 5:15 PM Andy Shevchenko
> > > > <andriy.shevchenko@xxxxxxxxxxxxxxx> 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.
> > >
> > > GPIO library does it for us among these lines:
> > >
> > >         struct fwnode_handle *fwnode = gc->parent ? dev_fwnode(gc->parent) : NULL;
> > >
> > >         of_gpio_dev_init(gc, gdev); <<< HERE!
> > >         acpi_gpio_dev_init(gc, gdev);
> > >
> > >         /*
> > >          * Assign fwnode depending on the result of the previous calls,
> > >          * if none of them succeed, assign it to the parent's one.
> > >          */
> > >         gdev->dev.fwnode = dev_fwnode(&gdev->dev) ?: fwnode;
> > >
> >
> > Except that it doesn't and I noticed that when working on the
> > subsequent patch. The child gpiochipX devices all had the parent's
> > fwnode assigned as their primary fwnode and no secondary fwnode.
> >
> > Note that this driver doesn't use neither OF nor ACPI in which case
> > gdev->dev has no fwnode and the parent's one is used. This patch
> > addresses it. If you have a better idea, let me know.
> >
> > Bart
> 
> Let me maybe rephrase the problem: currently, for GPIO devices
> instantiating multiple banks created outside of the OF or ACPI
> frameworks (e.g. instantiated manually and configured using a
> hierarchy of software nodes with a single parent swnode and a number
> of child swnodes representing the children), it is impossible to
> assign firmware nodes other than the one representing the top GPIO
> device to the gpiochip child devices.
> 
> In fact if we want to drop the OF APIs entirely from gpiolib - this
> would be the right first step as for gpio-sim it actually replaces the
> gc->of_node = some_of_node; assignment that OF-based drivers do for
> sub-nodes defining banks and it does work with device-tree (I verified
> that too) thanks to the fwnode abstraction layer.

I still don't see how you set up hierarchy of primary/secondary fwnodes.

And I don't like this change. It seems it band-aids some issue with fwnode
usage. What the easiest way to reproduce the issue with your series applied
(without this change)?

-- 
With Best Regards,
Andy Shevchenko