On Wed, Aug 28, 2024 at 01:04:16PM +0900, Dominique Martinet wrote:
> 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, I'll go revert this!
greg k-h
