| Message ID | 20230308100012.2539189-1-u.kleine-koenig@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | ARM: Convert to platform remove callback returning void | expand |
On Wed, Mar 8, 2023, at 11:00, Uwe Kleine-König wrote: > Hello, > > this patch series adapts the platform drivers below arch/arm to use the > .remove_new() callback. Compared to the traditional .remove() callback > .remove_new() returns no value. This is a good thing because the driver core > doesn't (and cannot) cope for errors during remove. The only effect of a > non-zero return value in .remove() is that the driver core emits a warning. The > device is removed anyhow and an early return from .remove() usually yields a > resource leak. > > By changing the remove callback to return void driver authors cannot > reasonably assume any more that there is some kind of cleanup later. > > All drivers in arch/arm returned zero unconditionally in their remove callback, > so they could all be converted trivially to .remove_new(). > > Note that this series depends on commit 5c5a7680e67b ("platform: Provide > a remove callback that returns no value") which is included in v6.3-rc1. Looks good to me, Reviewed-by: Arnd Bergmann <arnd@arndb.de> > I'm unsure who will pick up this series. Will it go as a whole via arm-soc? Or > will the individual maintainers pick it up? I can take it through the soc tree, please send it to soc@kernel.org once you are done getting Acks. Since all eight patches in the series have the exact same changelog text and are all trivial, I'd prefer them to be folded into a single patch if that works for you. Arnd
On Wed, Mar 08, 2023 at 04:06:47PM +0100, Arnd Bergmann wrote: > On Wed, Mar 8, 2023, at 11:00, Uwe Kleine-König wrote: > > Hello, > > > > this patch series adapts the platform drivers below arch/arm to use the > > .remove_new() callback. Compared to the traditional .remove() callback > > .remove_new() returns no value. This is a good thing because the driver core > > doesn't (and cannot) cope for errors during remove. The only effect of a > > non-zero return value in .remove() is that the driver core emits a warning. The > > device is removed anyhow and an early return from .remove() usually yields a > > resource leak. > > > > By changing the remove callback to return void driver authors cannot > > reasonably assume any more that there is some kind of cleanup later. > > > > All drivers in arch/arm returned zero unconditionally in their remove callback, > > so they could all be converted trivially to .remove_new(). > > > > Note that this series depends on commit 5c5a7680e67b ("platform: Provide > > a remove callback that returns no value") which is included in v6.3-rc1. > > Looks good to me, > > Reviewed-by: Arnd Bergmann <arnd@arndb.de> > > > I'm unsure who will pick up this series. Will it go as a whole via arm-soc? Or > > will the individual maintainers pick it up? > > I can take it through the soc tree, please send it to > soc@kernel.org once you are done getting Acks. > > Since all eight patches in the series have the exact same > changelog text and are all trivial, I'd prefer them to be > folded into a single patch if that works for you. No, they are not all identical, they all have their individual subject prefix :-) Honestly: I don't care much. I split it because for most other subsystems that's what the respective maintainers seem to prefer. I'll care for that, i.e. wait a bit to give others the chance to ack (or object) and then send it as you recommended. Thanks. Best regards Uwe
Hello, this patch series adapts the platform drivers below arch/arm to use the .remove_new() callback. Compared to the traditional .remove() callback .remove_new() returns no value. This is a good thing because the driver core doesn't (and cannot) cope for errors during remove. The only effect of a non-zero return value in .remove() is that the driver core emits a warning. The device is removed anyhow and an early return from .remove() usually yields a resource leak. By changing the remove callback to return void driver authors cannot reasonably assume any more that there is some kind of cleanup later. All drivers in arch/arm returned zero unconditionally in their remove callback, so they could all be converted trivially to .remove_new(). Note that this series depends on commit 5c5a7680e67b ("platform: Provide a remove callback that returns no value") which is included in v6.3-rc1. I'm unsure who will pick up this series. Will it go as a whole via arm-soc? Or will the individual maintainers pick it up? Best regards Uwe Uwe Kleine-König (8): ARM: locomo: Convert to platform remove callback returning void ARM: sa1111: Convert to platform remove callback returning void ARM: scoop: Convert to platform remove callback returning void ARM: imx: mmdc: Convert to platform remove callback returning void ARM: omap1: omap-dma: Convert to platform remove callback returning void ARM: pxa: sharpsl_pm: Convert to platform remove callback returning void ARM: sa1100: jornada720_ssp: Convert to platform remove callback returning void ARM: sa1100: neponset: Convert to platform remove callback returning void arch/arm/common/locomo.c | 6 ++---- arch/arm/common/sa1111.c | 6 ++---- arch/arm/common/scoop.c | 6 ++---- arch/arm/mach-imx/mmdc.c | 5 ++--- arch/arm/mach-omap1/omap-dma.c | 6 ++---- arch/arm/mach-pxa/sharpsl_pm.c | 6 ++---- arch/arm/mach-sa1100/jornada720_ssp.c | 5 ++--- arch/arm/mach-sa1100/neponset.c | 6 ++---- 8 files changed, 16 insertions(+), 30 deletions(-) base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6