lkml.org 
[lkml]   [2021]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v11 2/6] gpiolib: allow to specify the firmware node in struct gpio_chip
    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@bgdev.pl> wrote:
    > >
    > > On Tue, Nov 30, 2021 at 10:00 PM Andy Shevchenko
    > > <andriy.shevchenko@linux.intel.com> 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@linux.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.
    > > >
    > > > 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


    \
     
     \ /
      Last update: 2021-12-01 14:41    [W:4.351 / U:0.440 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site