[PATCH RESEND 0/2] drivers: base: Add tests showing devm handling inconsistencies

Maxime Ripard posted 2 patches 10 months, 4 weeks ago
There is a newer version of this series
drivers/base/test/.kunitconfig           |   2 +
drivers/base/test/Kconfig                |   4 +
drivers/base/test/Makefile               |   3 +
drivers/base/test/platform-device-test.c | 278 +++++++++++++++++++++++++++++++
drivers/base/test/root-device-test.c     | 120 +++++++++++++
5 files changed, 407 insertions(+)
[PATCH RESEND 0/2] drivers: base: Add tests showing devm handling inconsistencies
Posted by Maxime Ripard 10 months, 4 weeks ago
Hi,

This follows the discussion here:
https://lore.kernel.org/linux-kselftest/20230324123157.bbwvfq4gsxnlnfwb@houat/

This shows a couple of inconsistencies with regard to how device-managed
resources are cleaned up. Basically, devm resources will only be cleaned up
if the device is attached to a bus and bound to a driver. Failing any of
these cases, a call to device_unregister will not end up in the devm
resources being released.

We had to work around it in DRM to provide helpers to create a device for
kunit tests, but the current discussion around creating similar, generic,
helpers for kunit resumed interest in fixing this.

This can be tested using the command:
./tools/testing/kunit/kunit.py run --kunitconfig=drivers/base/test/

Let me know what you think,
Maxime

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Maxime Ripard (2):
      drivers: base: Add basic devm tests for root devices
      drivers: base: Add basic devm tests for platform devices

 drivers/base/test/.kunitconfig           |   2 +
 drivers/base/test/Kconfig                |   4 +
 drivers/base/test/Makefile               |   3 +
 drivers/base/test/platform-device-test.c | 278 +++++++++++++++++++++++++++++++
 drivers/base/test/root-device-test.c     | 120 +++++++++++++
 5 files changed, 407 insertions(+)
---
base-commit: a6faf7ea9fcb7267d06116d4188947f26e00e57e
change-id: 20230329-kunit-devm-inconsistencies-test-5e5a7d01e60d

Best regards,
-- 
Maxime Ripard <mripard@kernel.org>