diff mbox series

gpio: mvebu: Make use of devm_pwmchip_add

Message ID 20230717142743.2555739-1-u.kleine-koenig@pengutronix.de
State New
Headers show
Series gpio: mvebu: Make use of devm_pwmchip_add | expand

Commit Message

Uwe Kleine-König July 17, 2023, 2:27 p.m. UTC
This allows to get rid of a call to pwmchip_remove() in the error path. There
is no .remove function for this driver, so this change fixes a resource leak
when a gpio-mvebu device is unbound.

Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,

Note that irq_domain_remove() also isn't called so there is another
resource leak introduced by 812d47889a8e ("gpio/mvebu: Use
irq_domain_add_linear")

 drivers/gpio/gpio-mvebu.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)


base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5

Comments

Andy Shevchenko July 17, 2023, 2:37 p.m. UTC | #1
On Mon, Jul 17, 2023 at 04:27:43PM +0200, Uwe Kleine-König wrote:
> This allows to get rid of a call to pwmchip_remove() in the error path. There
> is no .remove function for this driver, so this change fixes a resource leak
> when a gpio-mvebu device is unbound.

Reviewed-by: Andy Shevchenko <andy@kernel.org>
Andy Shevchenko July 17, 2023, 2:40 p.m. UTC | #2
On Mon, Jul 17, 2023 at 04:27:43PM +0200, Uwe Kleine-König wrote:

> Note that irq_domain_remove() also isn't called so there is another
> resource leak introduced by 812d47889a8e ("gpio/mvebu: Use
> irq_domain_add_linear")

I believe it's only theoretical issue as quite likely GPIO will be used and
hence one can't unbound it. Or unbound is unconditional? In that case we
have much bigger issue in the kernel.
Uwe Kleine-König July 17, 2023, 2:49 p.m. UTC | #3
On Mon, Jul 17, 2023 at 05:40:11PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 17, 2023 at 04:27:43PM +0200, Uwe Kleine-König wrote:
> 
> > Note that irq_domain_remove() also isn't called so there is another
> > resource leak introduced by 812d47889a8e ("gpio/mvebu: Use
> > irq_domain_add_linear")
> 
> I believe it's only theoretical issue as quite likely GPIO will be used and
> hence one can't unbound it. Or unbound is unconditional? In that case we
> have much bigger issue in the kernel.

You might want to test

	echo f1018100.gpio > /sys/bus/platform/drivers/mvebu-gpio/unbind

(where f1018100.gpio is the name of one of links in
/sys/bus/platform/drivers/mvebu-gpio#) and if that succeeds you should
consider

diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index a68f682aec01..620ab247abff 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -1306,6 +1306,7 @@ static struct platform_driver mvebu_gpio_driver = {
 	.driver		= {
 		.name		= "mvebu-gpio",
 		.of_match_table = mvebu_gpio_of_match,
+		.suppress_bind_attrs = true,
 	},
 	.probe		= mvebu_gpio_probe,
 	.suspend        = mvebu_gpio_suspend,

which prevents that path and so the leak (by not providing
/sys/bus/platform/drivers/mvebu-gpio/unbind).

Best regards
Uwe
Bartosz Golaszewski July 19, 2023, 11:34 a.m. UTC | #4
On Mon, Jul 17, 2023 at 4:27 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
>
> This allows to get rid of a call to pwmchip_remove() in the error path. There
> is no .remove function for this driver, so this change fixes a resource leak
> when a gpio-mvebu device is unbound.
>
> Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
>
> Note that irq_domain_remove() also isn't called so there is another
> resource leak introduced by 812d47889a8e ("gpio/mvebu: Use
> irq_domain_add_linear")
>
>  drivers/gpio/gpio-mvebu.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index a68f682aec01..a35958e7adf6 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -874,7 +874,7 @@ static int mvebu_pwm_probe(struct platform_device *pdev,
>
>         spin_lock_init(&mvpwm->lock);
>
> -       return pwmchip_add(&mvpwm->chip);
> +       return devm_pwmchip_add(dev, &mvpwm->chip);
>  }
>
>  #ifdef CONFIG_DEBUG_FS
> @@ -1243,8 +1243,7 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
>         if (!mvchip->domain) {
>                 dev_err(&pdev->dev, "couldn't allocate irq domain %s (DT).\n",
>                         mvchip->chip.label);
> -               err = -ENODEV;
> -               goto err_pwm;
> +               return -ENODEV;
>         }
>
>         err = irq_alloc_domain_generic_chips(
> @@ -1296,9 +1295,6 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
>
>  err_domain:
>         irq_domain_remove(mvchip->domain);
> -err_pwm:
> -       pwmchip_remove(&mvchip->mvpwm->chip);
> -
>         return err;
>  }
>
>
> base-commit: 06c2afb862f9da8dc5efa4b6076a0e48c3fbaaa5
> --
> 2.39.2
>

Applied, thanks!

Bart
diff mbox series

Patch

diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index a68f682aec01..a35958e7adf6 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -874,7 +874,7 @@  static int mvebu_pwm_probe(struct platform_device *pdev,
 
 	spin_lock_init(&mvpwm->lock);
 
-	return pwmchip_add(&mvpwm->chip);
+	return devm_pwmchip_add(dev, &mvpwm->chip);
 }
 
 #ifdef CONFIG_DEBUG_FS
@@ -1243,8 +1243,7 @@  static int mvebu_gpio_probe(struct platform_device *pdev)
 	if (!mvchip->domain) {
 		dev_err(&pdev->dev, "couldn't allocate irq domain %s (DT).\n",
 			mvchip->chip.label);
-		err = -ENODEV;
-		goto err_pwm;
+		return -ENODEV;
 	}
 
 	err = irq_alloc_domain_generic_chips(
@@ -1296,9 +1295,6 @@  static int mvebu_gpio_probe(struct platform_device *pdev)
 
 err_domain:
 	irq_domain_remove(mvchip->domain);
-err_pwm:
-	pwmchip_remove(&mvchip->mvpwm->chip);
-
 	return err;
 }