From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
linux-acpi@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] gpiolib: consolidate GPIO lookups
Date: Fri, 4 Nov 2022 21:56:57 -0700 [thread overview]
Message-ID: <Y2XtGTAjEB24tqrF@google.com> (raw)
In-Reply-To: <Y2V+8tiwstXbTWoq@smile.fi.intel.com>
On Fri, Nov 04, 2022 at 11:06:58PM +0200, Andy Shevchenko wrote:
> On Fri, Nov 04, 2022 at 11:52:26AM -0700, Dmitry Torokhov wrote:
> > On Fri, Nov 04, 2022 at 07:17:27PM +0200, Andy Shevchenko wrote:
> > > On Thu, Nov 03, 2022 at 11:10:15PM -0700, Dmitry Torokhov wrote:
>
> ...
>
> > > > +static struct gpio_desc *gpiod_find_by_fwnode(struct fwnode_handle *fwnode,
> > > > + struct device *consumer,
> > > > + const char *con_id,
> > > > + unsigned int idx,
> > > > + enum gpiod_flags *flags,
> > > > + unsigned long *lookupflags)
> > > > {
> > >
> > > > + struct gpio_desc *desc = ERR_PTR(-ENOENT);
> > >
> > > No need, just return directly.
> > >
> > > > + dev_dbg(consumer, "GPIO lookup for consumer %s in node '%s'\n",
> > > > + con_id, fwnode_get_name(fwnode));
> > >
> > > %pfwP ?
> >
> > OK. Although, I think I like %pfw (without 'P') better as it gives
> > results like:
> >
> > /soc/i2c@11007000/edp-bridge@8
> >
> > or
> >
> > \_SB.PCI0.I2C1.D010
> >
> > which should help identifying the exact node.
>
> I agree.
>
> > > > + /* Using device tree? */
> > > > if (is_of_node(fwnode)) {
> > > > + dev_dbg(consumer, "using device tree for GPIO lookup\n");
> > > > + desc = of_find_gpio(to_of_node(fwnode),
> > > > + con_id, idx, lookupflags);
> > > > } else if (is_acpi_node(fwnode)) {
> > >
> > > With direct return, no need for 'else' here.
> >
> > When we have several branches of equal weight I prefer not to have
> > early/inline returns, but I can add:
> >
> > } else {
> > desc = ERR_PTR(-ENOENT);
> > }
> >
> > at the end, what do you think?
>
> No strong opinion here.
>
> > > > + dev_dbg(consumer, "using ACPI for GPIO lookup\n");
> > > > + desc = acpi_find_gpio(fwnode, con_id, idx, flags, lookupflags);
> > > > }
> > > >
> > > > + return desc;
> > > > +}
>
> ...
>
> > > > + struct gpio_desc *desc = ERR_PTR(-ENOENT);
> > >
> > > We can get rid of the assignment, see below.
>
> Still below another thought which affects this.
>
> > > > + if (fwnode)
> > >
> > > Do we need this check?
> >
> > Yes, I would prefer to have it as it clearly informs the reader that we
> > are only doing lookup by node if we actually have a node.
> >
> > gpiod_find_and_request() expects that it gets a valid node and in the
> > followup change it will be dereferencing fwnode without checking for
> > NULL-ness.
>
> But most of the code will check for the NULL anyway. The exceptions are
> dev_dbg() and accessing to the secondary fwnode.
I think it is just a matter of what I want to express through source. I
want to show that the device might not have fwnode, and that we only
descend into gpiod_find_by_fwnode() in cases where we actually have
fwnode.
>
> > > Debug message above (when %pfw is used) would be even useful when
> > > fwnode == NULL.
>
> > > > + desc = gpiod_find_by_fwnode(fwnode, consumer, con_id, idx,
> > > > + &flags, &lookupflags);
>
> Looking into drivers/base/property.c makes me realize that you might need to
> test for error pointer as well.
>
> Perhaps something like
>
> if (IS_ERR_OR_NULL(fwnode))
> return ERR_PTR(-ENOENT);
>
> in the gpiod_find_by_fwnode() needs to be added. Can you check this?
No, only fwnode->secondary pointer can be PTR_ERR()-encoded.
From comment to set_primary_fwnode() in drivers/base/core.c
* Valid fwnode cases are:
* - primary --> secondary --> -ENODEV
* - primary --> NULL
* - secondary --> -ENODEV
* - NULL
I do not believe we should be concerned about someone passing secondary
pointers from fwnodes directly into gpiolib.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2022-11-05 4:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 6:10 [PATCH 0/6] Add support for software nodes to gpiolib Dmitry Torokhov
2022-11-04 6:10 ` [PATCH 1/6] gpiolib: of: change of_find_gpio() to accept device node Dmitry Torokhov
2022-11-04 6:10 ` [PATCH 2/6] gpiolib: acpi: change acpi_find_gpio() to accept firmware node Dmitry Torokhov
2022-11-04 6:10 ` [PATCH 3/6] gpiolib: acpi: teach acpi_find_gpio() to handle data-only nodes Dmitry Torokhov
2022-11-04 6:10 ` [PATCH 4/6] gpiolib: acpi: avoid leaking ACPI details into upper gpiolib layers Dmitry Torokhov
2022-11-04 6:10 ` [PATCH 5/6] gpiolib: consolidate GPIO lookups Dmitry Torokhov
2022-11-04 17:17 ` Andy Shevchenko
2022-11-04 18:52 ` Dmitry Torokhov
2022-11-04 21:06 ` Andy Shevchenko
2022-11-05 4:56 ` Dmitry Torokhov [this message]
2022-11-07 10:44 ` Andy Shevchenko
2022-11-04 6:10 ` [PATCH 6/6] gpiolib: add support for software nodes Dmitry Torokhov
2022-11-04 18:08 ` Andy Shevchenko
2022-11-04 19:33 ` Dmitry Torokhov
2022-11-04 20:57 ` Andy Shevchenko
2022-11-05 4:48 ` Dmitry Torokhov
2022-11-07 11:08 ` Andy Shevchenko
2022-11-07 16:12 ` Dmitry Torokhov
2022-11-07 20:59 ` Andy Shevchenko
2022-11-07 21:02 ` Andy Shevchenko
2022-11-04 15:50 ` [PATCH 0/6] Add support for software nodes to gpiolib Bartosz Golaszewski
2022-11-04 17:18 ` Andy Shevchenko
2022-11-08 10:55 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2XtGTAjEB24tqrF@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.