Greg Kroah-Hartman wrote on Thu, Jun 13, 2024 at 01:33:32PM +0200:
> 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 ignored (apart
> from emitting a warning) 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. Eventually after all drivers
> are converted, .remove_new() will be renamed to .remove().
A bit late to the party here (this patch was included as commit
0096d223f78c in v5.10.219), but 5.10 does not have .remove_new()
(missing commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value")) so there is no way this commit will work.
I'm not building this driver so don't really care and this can be left
as is as far as I'm concerned (and since it's been over 2 months
probably no-one is using this driver on this old kernel, it doesn't look
enabled on e.g. debian's build); so this is just a head's up for mail
archives if anyone is notified about the problem they'll want to either
revert this or pick up the above commit.
(I checked quickly and that commit was backported to 5.15, so 5.10 is
the only tree where that broke, and there is no other driver in 5.10
that tries to set .remove_new)
Thanks,
--
Dominique
