[PATCH 0/3] hwspinlock: Convert to platform remove callback returning void

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

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().

Best regards
Uwe

Uwe Kleine-König (3):
  hwspinlock: omap: Emit only one error message for errors in .remove()
  hwspinlock: omap: Convert to platform remove callback returning void
  hwspinlock: u8500: Convert to platform remove callback returning void

 drivers/hwspinlock/omap_hwspinlock.c | 8 +++-----
 drivers/hwspinlock/u8500_hsem.c      | 6 ++----
 2 files changed, 5 insertions(+), 9 deletions(-)

base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
-- 
2.39.2