Skip to contentSkip to conversation

gpiolib: Do not unexport GPIO on freeing

PATCH Superseded Andy Shevchenko 3 participants 5 messages Jun 2, 2023 – Jun 9, 2023 GPIO

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Andy Shevchenko

author
#0 lore raw

PATCH 1/1 gpiolib: Do not unexport GPIO on freeing

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(-)
drivers/gpio/gpiolib.c +0 -2
index a8da38ee721a..7a9c9934365a 100644
@@ -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;
Signature · 1 line
2.40.0.1.gaa8946217a0b
author
#1 lore raw
Quoted 7 lines · 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.

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.

Signature · 2 lines
With Best Regards,
Andy Shevchenko
author
#2 lore raw
Quoted 7 lines · Andy Shevchenko
Quoted 6 lines · 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

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

Quoted 7 lines
Quoted 1 line

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.

Signature · 2 lines
With Best Regards,
Andy Shevchenko
#3 lore raw
Quoted 18 lines · Andy Shevchenko
Quoted 7 lines · Andy Shevchenko
Quoted 6 lines · 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

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

Quoted 5 lines
Quoted 1 line

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.

Quoted 8 lines
Quoted 2 lines

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

Reviewed-by on v1 1/1
#4 lore raw
In reply to Andy Shevchenko
Quoted 9 lines · 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 <[email protected]>

Makes sense!

Reviewed-by Linus Walleij <[email protected]>

Yours,
Linus Walleij