| Message ID | 20220903-gpiod_get_from_of_node-remove-v1-2-b29adfb27a6c@gmail.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Get rid of [devm_]gpiod_get_from_of_node() public APIs | expand |
On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > I would like to limit (or maybe even remove) use of > [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned > a bit, so let's switch to the generic device property API. > It may even > help with handling secondary fwnodes when gpiolib is taught to handle > gpios described by swnodes. I would remove this sentence from all commit messages since it's a debatable thing and might even not happen, so the above is a pure speculation.
On Mon, Sep 05, 2022 at 01:57:01PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > > > I would like to limit (or maybe even remove) use of > > [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned > > a bit, so let's switch to the generic device property API. > > > It may even > > help with handling secondary fwnodes when gpiolib is taught to handle > > gpios described by swnodes. > > I would remove this sentence from all commit messages since it's a > debatable thing and might even not happen, so the above is a pure > speculation. I have the patches. Granted, I had them since '19 ;) but I'm rebasing them and going to push them. I need them to convert bunch of input drivers away from platform data. Thanks.
On Mon, Sep 5, 2022 at 9:37 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Mon, Sep 05, 2022 at 01:57:01PM +0300, Andy Shevchenko wrote: > > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov > > <dmitry.torokhov@gmail.com> wrote: > > > > > > I would like to limit (or maybe even remove) use of > > > [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned > > > a bit, so let's switch to the generic device property API. > > > > > It may even > > > help with handling secondary fwnodes when gpiolib is taught to handle > > > gpios described by swnodes. > > > > I would remove this sentence from all commit messages since it's a > > debatable thing and might even not happen, so the above is a pure > > speculation. > > I have the patches. Granted, I had them since '19 ;) but I'm rebasing > them and going to push them. I need them to convert bunch of input > drivers away from platform data. That's good news! Are you referring to this patch set mentioned in a discussion from 2017 thru 2020? https://lore.kernel.org/linux-input/20200826161222.GA1665100@dtor-ws/ I put aside GPIO descriptor conversion for input devices (keys, buttons) in board files anticipating a swnode mechanism. Yours, Linus Walleij
On Mon, Sep 05, 2022 at 11:03:38PM +0200, Linus Walleij wrote: > On Mon, Sep 5, 2022 at 9:37 PM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > On Mon, Sep 05, 2022 at 01:57:01PM +0300, Andy Shevchenko wrote: > > > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov > > > <dmitry.torokhov@gmail.com> wrote: > > > > > > > > I would like to limit (or maybe even remove) use of > > > > [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned > > > > a bit, so let's switch to the generic device property API. > > > > > > > It may even > > > > help with handling secondary fwnodes when gpiolib is taught to handle > > > > gpios described by swnodes. > > > > > > I would remove this sentence from all commit messages since it's a > > > debatable thing and might even not happen, so the above is a pure > > > speculation. > > > > I have the patches. Granted, I had them since '19 ;) but I'm rebasing > > them and going to push them. I need them to convert bunch of input > > drivers away from platform data. > > That's good news! > > Are you referring to this patch set mentioned in a discussion > from 2017 thru 2020? > https://lore.kernel.org/linux-input/20200826161222.GA1665100@dtor-ws/ > > I put aside GPIO descriptor conversion for input devices (keys, buttons) > in board files anticipating a swnode mechanism. Yep, that one, exactly. It is taking a bit longer than I anticipated ;) Thanks.
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c index 47d26b5d9945..a8925dcd7edd 100644 --- a/drivers/gpu/drm/tegra/output.c +++ b/drivers/gpu/drm/tegra/output.c @@ -133,11 +133,11 @@ int tegra_output_probe(struct tegra_output *output) } } - output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev, - output->of_node, - "nvidia,hpd-gpio", 0, - GPIOD_IN, - "HDMI hotplug detect"); + output->hpd_gpio = devm_fwnode_gpiod_get(output->dev, + of_fwnode_handle(output->of_node), + "nvidia,hpd", + GPIOD_IN, + "HDMI hotplug detect"); if (IS_ERR(output->hpd_gpio)) { if (PTR_ERR(output->hpd_gpio) != -ENOENT) return PTR_ERR(output->hpd_gpio);
I would like to limit (or maybe even remove) use of [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned a bit, so let's switch to the generic device property API. It may even help with handling secondary fwnodes when gpiolib is taught to handle gpios described by swnodes. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>