Hello, On Wed, Apr 12, 2023 at 07:16:10PM +0200, Uwe Kleine-König wrote: > On Tue, Mar 14, 2023 at 07:00:20PM +0100, Uwe Kleine-König wrote: > > Hello, > > > > this patch series adapts the platform drivers below drivers/hwspinlock 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. > > > > The omap driver could return -EBUSY. This is first changed to return > > zero to drop the duplicated error message. I assume this error path is > > dangerous. For sure the platform device binding goes away and so > > devm_platform_ioremap_resource is undone. So probably the user of the > > hwspinlock that prevented its removal will soon access an unmapped > > virtual address resulting in an oops. This is true with and without my > > patch. IMHO hwspin_lock_unregister() shouldn't return an error code but > > care that all users go away and then return void. > > > > After this change the two platform_drivers can be trivially converted to > > .remove_new(). > > Gentle ping! > > Who is supposed to apply this series (or point out a good reason to not > do that)? Still no maintainer feedback on my series :-\ Would a resend help? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
