[PATCH 00/22] fb: handle remove callbacks in .exit.text and convert to .remove_new

[Helge Deller]

On 11/7/23 10:17, Uwe Kleine-König wrote:
> there are currently several platform drivers that have their .remove
> callback defined in .exit.text. While this works fine, it comes with a
> few downsides: Since commit f177cd0c15fc ("modpost: Don't let "driver"s
> reference .exit.*") it triggers a modpost warning unless the driver
> struct is marked with __refdata. None of the drivers in
> drivers/video/fbdev get that right (which is understandable the warning
> was added only recently). While it would be possible to add that marker,
> that's also a bit ugly as this bypasses all other section checks that
> modpost does. Having the remove callback in .exit.text also means that
> the corresponding devices cannot be unbound at runtime which is
> sometimes usefull for debugging purposes.
>
> To fix the modpost warning I picked the progressive option and moved the
> .remove() callbacks (and for two drivers also .probe()) into .text (i.e.
> the default code section) and dropped .suppress_bind_attrs = true (which
> is implicitly set for drivers using platform_driver_probe()).  Note even
> though these patches fix a warning, it currently only happens with W=1,
> so this isn't urgent and there is no need to apply these before v6.7.
> The next merge window is fine (although I wouldn't object an earlier
> application of course :-) The alternative is to add the __refdata
> marker, ideally with a comment describing the need. (See e.g. commit
> 141626dbc2e6 ("rtc: sh: Mark driver struct with __refdata to prevent
> section mismatch warning") .)
>
> As a follow-up I converted the affected drivers to .remove_new(). There
> was already a series doing this for the other drivers in
> drivers/video/fb, but my coccinelle script missed these drivers as it
> didn't handle
>
> 	.remove = __exit_p(removefunc),
>
> . See commit 5c5a7680e67b ("platform: Provide a remove callback that
> returns no value") for an extended explanation and the eventual goal. I
> considered creating a second series for this conversion, but as the
> patches conflict I put all patches in a single series to make it easier
> to apply it.

Thanks Uwe!

I've applied the series as-is to the fbdev for-next git tree.
The patches look ok, and if they survive the next few days they will go
upstream soon.

Helge