[PATCH v1 1/1] gpiolib: Do not unexport GPIO on freeing

[PATCH v1 1/1] gpiolib: Do not unexport GPIO on freeing

[Andy Shevchenko]

Since the legacy exporting is gone with 2f804aca4832 ("gpiolib:
Kill unused GPIOF_EXPORT and Co") there is no need to unexport
GPIO on freeing. Remove that call.

Note, the other users of this functionality do that explicitly,
except one SH boardfile which doesn't free GPIO anyways, so it
is safe to drop the call.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/gpio/gpiolib.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a8da38ee721a..7a9c9934365a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2117,8 +2117,6 @@ static bool gpiod_free_commit(struct gpio_desc *desc)
 
 	might_sleep();
 
-	gpiod_unexport(desc);
-
 	spin_lock_irqsave(&gpio_lock, flags);
 
 	gc = desc->gdev->chip;
-- 
2.40.0.1.gaa8946217a0b

Re: [PATCH v1 1/1] gpiolib: Do not unexport GPIO on freeing

[Andy Shevchenko]

On Fri, Jun 02, 2023 at 07:22:58PM +0300, Andy Shevchenko wrote:
> Since the legacy exporting is gone with 2f804aca4832 ("gpiolib:
> Kill unused GPIOF_EXPORT and Co") there is no need to unexport
> GPIO on freeing. Remove that call.
> 
> Note, the other users of this functionality do that explicitly,
> except one SH boardfile which doesn't free GPIO anyways, so it
> is safe to drop the call.

Note, that this might be squashed with the above mentioned commit, because
I haven't checked current users I didn't do the removal in that patch.

But this will probably needs rebase which is not good thing process wise.
So, just my 2 cents in case.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/1] gpiolib: Do not unexport GPIO on freeing

[Andy Shevchenko]

On Fri, Jun 02, 2023 at 07:29:00PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 02, 2023 at 07:22:58PM +0300, Andy Shevchenko wrote:
> > Since the legacy exporting is gone with 2f804aca4832 ("gpiolib:
> > Kill unused GPIOF_EXPORT and Co") there is no need to unexport
> > GPIO on freeing. Remove that call.

> > Note, the other users of this functionality do that explicitly,
> > except one SH boardfile which doesn't free GPIO anyways, so it

Actually OMAP3 as well with the same idea, once requested those never freed.
Bart, should I update the commit message?

> > is safe to drop the call.
> 
> Note, that this might be squashed with the above mentioned commit, because
> I haven't checked current users I didn't do the removal in that patch.
> 
> But this will probably needs rebase which is not good thing process wise.
> So, just my 2 cents in case.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/1] gpiolib: Do not unexport GPIO on freeing

[Linus Walleij]

On Fri, Jun 2, 2023 at 6:22 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> Since the legacy exporting is gone with 2f804aca4832 ("gpiolib:
> Kill unused GPIOF_EXPORT and Co") there is no need to unexport
> GPIO on freeing. Remove that call.
>
> Note, the other users of this functionality do that explicitly,
> except one SH boardfile which doesn't free GPIO anyways, so it
> is safe to drop the call.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Makes sense!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

Re: [PATCH v1 1/1] gpiolib: Do not unexport GPIO on freeing

[Bartosz Golaszewski]

On Fri, Jun 2, 2023 at 6:34 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Jun 02, 2023 at 07:29:00PM +0300, Andy Shevchenko wrote:
> > On Fri, Jun 02, 2023 at 07:22:58PM +0300, Andy Shevchenko wrote:
> > > Since the legacy exporting is gone with 2f804aca4832 ("gpiolib:
> > > Kill unused GPIOF_EXPORT and Co") there is no need to unexport
> > > GPIO on freeing. Remove that call.
>
> > > Note, the other users of this functionality do that explicitly,
> > > except one SH boardfile which doesn't free GPIO anyways, so it
>
> Actually OMAP3 as well with the same idea, once requested those never freed.
> Bart, should I update the commit message?
>
> > > is safe to drop the call.
> >
> > Note, that this might be squashed with the above mentioned commit, because
> > I haven't checked current users I didn't do the removal in that patch.
> >
> > But this will probably needs rebase which is not good thing process wise.
> > So, just my 2 cents in case.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

I did it myself when applying, thanks!

Bart