The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Cc: Uwe Kleine-König <[email protected]>
Signed-off-by: Yangtao Li <[email protected]>
---
drivers/cpuidle/cpuidle-kirkwood.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-kirkwood.c b/drivers/cpuidle/cpuidle-kirkwood.c
index 13bf743f885b..602c4dfdd7e2 100644
--- a/drivers/cpuidle/cpuidle-kirkwood.c
+++ b/drivers/cpuidle/cpuidle-kirkwood.c
@@ -59,15 +59,14 @@ static int kirkwood_cpuidle_probe(struct platform_device *pdev)
return cpuidle_register(&kirkwood_idle_driver, NULL);
}
-static int kirkwood_cpuidle_remove(struct platform_device *pdev)
+static void kirkwood_cpuidle_remove(struct platform_device *pdev)
{
cpuidle_unregister(&kirkwood_idle_driver);
- return 0;
}
static struct platform_driver kirkwood_cpuidle_driver = {
.probe = kirkwood_cpuidle_probe,
- .remove = kirkwood_cpuidle_remove,
+ .remove_new = kirkwood_cpuidle_remove,
.driver = {
.name = "kirkwood_cpuidle",
},
--
2.39.0
On Wed, Jul 12, 2023 at 05:40:13PM +0800, Yangtao Li wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Cc: Uwe Kleine-K?nig <[email protected]>
> Signed-off-by: Yangtao Li <[email protected]>
Reviewed-by: Uwe Kleine-K?nig <[email protected]>
Can you pick this up?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hello Rafael, hello Daniel,
On Mon, Dec 04, 2023 at 12:55:17PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Jul 12, 2023 at 05:40:13PM +0800, Yangtao Li wrote:
> > The .remove() callback for a platform driver returns an int which makes
> > many driver authors wrongly assume it's possible to do error handling by
> > returning an error code. However the value returned is (mostly) ignored
> > and this typically results in resource leaks. To improve here there is a
> > quest to make the remove callback return void. In the first step of this
> > quest all drivers are converted to .remove_new() which already returns
> > void.
> >
> > Trivially convert this driver from always returning zero in the remove
> > callback to the void returning variant.
> >
> > Cc: Uwe Kleine-K?nig <[email protected]>
> > Signed-off-by: Yangtao Li <[email protected]>
>
> Reviewed-by: Uwe Kleine-K?nig <[email protected]>
>
> Can you pick this up?
This patch isn't in next yet. Is this still on someone's radar for
application? Would be great if this patch made it into the mainline
during the upcomming merge window.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Hello,
On Wed, Mar 06, 2024 at 10:33:06PM +0100, Uwe Kleine-K?nig wrote:
> On Mon, Dec 04, 2023 at 12:55:17PM +0100, Uwe Kleine-K?nig wrote:
> > On Wed, Jul 12, 2023 at 05:40:13PM +0800, Yangtao Li wrote:
> > > The .remove() callback for a platform driver returns an int which makes
> > > many driver authors wrongly assume it's possible to do error handling by
> > > returning an error code. However the value returned is (mostly) ignored
> > > and this typically results in resource leaks. To improve here there is a
> > > quest to make the remove callback return void. In the first step of this
> > > quest all drivers are converted to .remove_new() which already returns
> > > void.
> > >
> > > Trivially convert this driver from always returning zero in the remove
> > > callback to the void returning variant.
> > >
> > > Cc: Uwe Kleine-K?nig <[email protected]>
> > > Signed-off-by: Yangtao Li <[email protected]>
> >
> > Reviewed-by: Uwe Kleine-K?nig <[email protected]>
> >
> > Can you pick this up?
>
> This patch isn't in next yet. Is this still on someone's radar for
> application? Would be great if this patch made it into the mainline
> during the upcomming merge window.
It didn't made it into the merge window leading to 6.9-rc1. What are
the chances to get it into v6.10-rc1?
I just checked, the patch was submitted when Linus's tree was just after
v6.5-rc1. So it already missed four merge windows without any maintainer
feedback :-\
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |
On 09/04/2024 18:32, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Mar 06, 2024 at 10:33:06PM +0100, Uwe Kleine-König wrote:
>> On Mon, Dec 04, 2023 at 12:55:17PM +0100, Uwe Kleine-König wrote:
>>> On Wed, Jul 12, 2023 at 05:40:13PM +0800, Yangtao Li wrote:
>>>> The .remove() callback for a platform driver returns an int which makes
>>>> many driver authors wrongly assume it's possible to do error handling by
>>>> returning an error code. However the value returned is (mostly) ignored
>>>> and this typically results in resource leaks. To improve here there is a
>>>> quest to make the remove callback return void. In the first step of this
>>>> quest all drivers are converted to .remove_new() which already returns
>>>> void.
>>>>
>>>> Trivially convert this driver from always returning zero in the remove
>>>> callback to the void returning variant.
>>>>
>>>> Cc: Uwe Kleine-König <[email protected]>
>>>> Signed-off-by: Yangtao Li <[email protected]>
>>>
>>> Reviewed-by: Uwe Kleine-König <[email protected]>
>>>
>>> Can you pick this up?
>>
>> This patch isn't in next yet. Is this still on someone's radar for
>> application? Would be great if this patch made it into the mainline
>> during the upcomming merge window.
>
> It didn't made it into the merge window leading to 6.9-rc1. What are
> the chances to get it into v6.10-rc1?
>
> I just checked, the patch was submitted when Linus's tree was just after
> v6.5-rc1. So it already missed four merge windows without any maintainer
> feedback :-\
Sorry, it is applied now.
Thanks
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Hello Daniel,
On Tue, Apr 23, 2024 at 09:22:23AM +0200, Daniel Lezcano wrote:
> On 09/04/2024 18:32, Uwe Kleine-K?nig wrote:
> > On Wed, Mar 06, 2024 at 10:33:06PM +0100, Uwe Kleine-K?nig wrote:
> > > On Mon, Dec 04, 2023 at 12:55:17PM +0100, Uwe Kleine-K?nig wrote:
> > > > On Wed, Jul 12, 2023 at 05:40:13PM +0800, Yangtao Li wrote:
> > > > > The .remove() callback for a platform driver returns an int which makes
> > > > > many driver authors wrongly assume it's possible to do error handling by
> > > > > returning an error code. However the value returned is (mostly) ignored
> > > > > and this typically results in resource leaks. To improve here there is a
> > > > > quest to make the remove callback return void. In the first step of this
> > > > > quest all drivers are converted to .remove_new() which already returns
> > > > > void.
> > > > >
> > > > > Trivially convert this driver from always returning zero in the remove
> > > > > callback to the void returning variant.
> > > > >
> > > > > Cc: Uwe Kleine-K?nig <[email protected]>
> > > > > Signed-off-by: Yangtao Li <[email protected]>
> > > >
> > > > Reviewed-by: Uwe Kleine-K?nig <[email protected]>
> > > >
> > > > Can you pick this up?
> > >
> > > This patch isn't in next yet. Is this still on someone's radar for
> > > application? Would be great if this patch made it into the mainline
> > > during the upcomming merge window.
> >
> > It didn't made it into the merge window leading to 6.9-rc1. What are
> > the chances to get it into v6.10-rc1?
> >
> > I just checked, the patch was submitted when Linus's tree was just after
> > v6.5-rc1. So it already missed four merge windows without any maintainer
> > feedback :-\
>
> Sorry, it is applied now.
Is it expected that this patch didn't appear in next yet now that you
applied it?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | https://www.pengutronix.de/ |