From: Andy Shevchenko <andy@kernel.org>
To: Linus Walleij <linus.walleij@linaro.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>
Subject: Re: [RFC/RFT PATCH] gpiolib: reverse-assign the fwnode to struct gpio_chip
Date: Sat, 7 Oct 2023 10:39:50 +0300 [thread overview]
Message-ID: <ZSELRvVk3G1y258L@smile.fi.intel.com> (raw)
In-Reply-To: <CACRpkdaqPm9471q7Sg-cxcLTTE63=NuKuSUFiFtPsaUoRiB3jA@mail.gmail.com>
On Sat, Oct 07, 2023 at 12:22:01AM +0200, Linus Walleij wrote:
> On Fri, Oct 6, 2023 at 9:08 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > I don't see any good reason for it not having the fwnode assigned.
> > User calling gpio_device_find() will have to jump through hoops in
> > order to match the device by fwnode
>
> Yeah I would add
>
> struct fwnode_handle *gpiochip_get_fwnode(struct gpio_chip *gc)
> {
> return dev_fwnode(&gc->gpiodev->dev);
> }
>
> so it's easy for external users to get the fwnode if they really need it.
> This and a few more changes and we can drop gc->fwnode altogether
> can't we?
This would work, but the problem here is to understand which fwnode
(semantically) the caller wants to use.
One is the GPIO device's, and the other is what provider explicitly assigned.
Currently the latter case is transparent in a sense that GPIO device will get
the same fwnode as GPIO chip submitted by the provider.
Internally GPIOLIB must use GPIO device fwnode and rely only on it.
Externally it depends. Basically it's provider's business to know if it
is safe to use gc->fwnode or not and when.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-10-07 7:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 11:51 [RFC/RFT PATCH] gpiolib: reverse-assign the fwnode to struct gpio_chip Bartosz Golaszewski
2023-10-06 13:14 ` Andy Shevchenko
2023-10-06 19:07 ` Bartosz Golaszewski
2023-10-07 7:45 ` Andy Shevchenko
2023-10-07 15:53 ` Linus Walleij
2023-10-09 18:28 ` Bartosz Golaszewski
2023-10-06 13:24 ` Andy Shevchenko
2023-10-06 19:07 ` Bartosz Golaszewski
2023-10-06 22:22 ` Linus Walleij
2023-10-07 7:39 ` Andy Shevchenko [this message]
2023-10-07 7:36 ` Andy Shevchenko
2023-10-06 22:14 ` Linus Walleij
2023-10-07 7:03 ` 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=ZSELRvVk3G1y258L@smile.fi.intel.com \
--to=andy@kernel.org \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=dipenp@nvidia.com \
--cc=linus.walleij@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).