From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Thierry Reding <treding@nvidia.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Bartosz Golaszewski <brgl@bgdev.pl>
Subject: Re: [rft, PATCH v3 1/1] gpiolib: Get rid of not used of_node member
Date: Wed, 16 Nov 2022 16:09:44 +0200 [thread overview]
Message-ID: <Y3TvKJAejVAZEVPJ@smile.fi.intel.com> (raw)
In-Reply-To: <Y3Tp2y9U8PcDh1r/@orome>
On Wed, Nov 16, 2022 at 02:47:07PM +0100, Thierry Reding wrote:
> On Wed, Nov 16, 2022 at 11:18:59AM +0200, Andy Shevchenko wrote:
> > All new drivers should use fwnode and / or parent to provide the
> > necessary information to the GPIO library.
...
> > + /* If the calling driver did not initialize firmware node, do it here */
> > if (gc->fwnode)
> > fwnode = gc->fwnode;
> > else if (gc->parent)
> > fwnode = dev_fwnode(gc->parent);
> > + gc->fwnode = fwnode;
>
> I'm not sure we want to set this one. We recently discussed this in
> another thread and my reading is that gc->fwnode is supposed to be used
> only to explicitly override which fwnode to use if the default isn't
> appropriate. Right now the standard way to access the device's fwnode
> seems to be dev_fwnode(&gdev->dev), with only very few exceptions, so
> it'd be great if we could settle on that, rather than introduce a second
> field that contains the same value and use them interchangeably.
>
> One way we could enforce this is by setting gc->fwnode to NULL here
> instead of fwnode. That should cause a crash anywhere it's used after
> this, so we should be able to easily weed out any abuses.
>
> Of course if people prefer to use gc->fwnode instead, then we may want
> to remove all uses of gdev->dev.fwnode. There's simply no point in
> keeping the same value in two different place, it's just going to lead
> to a big mess.
I prefer that we explicitly use GPIO device firmware node.
Independently on this message I came up with another patch
(I'm just about to sent it right away) which I think it
the best to have in current case.
Ideally I would like to see const struct gpio_chip *gc to be a parameter
to the GPIO chip add(). But it may happen in distant future.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-11-16 14:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 9:18 [rft, PATCH v3 1/1] gpiolib: Get rid of not used of_node member Andy Shevchenko
2022-11-16 9:27 ` Andy Shevchenko
2022-11-16 13:47 ` Thierry Reding
2022-11-16 14:09 ` Andy Shevchenko [this message]
2022-11-16 14:39 ` Andy Shevchenko
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=Y3TvKJAejVAZEVPJ@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=dmitry.torokhov@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=treding@nvidia.com \
/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.