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 <[email protected]>
---
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
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
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
On Fri, Jun 2, 2023 at 6:22 PM Andy Shevchenko
<[email protected]> 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 <[email protected]>
Makes sense!
Reviewed-by: Linus Walleij <[email protected]>
Yours,
Linus Walleij
On Fri, Jun 2, 2023 at 6:34 PM Andy Shevchenko
<[email protected]> 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