[PATCH 1/3] led: led-test: Remove standard error checking after KUNIT_ASSERT_*()

[PATCH 1/3] led: led-test: Remove standard error checking after KUNIT_ASSERT_*()

[Lee Jones]

If a KUNIT_ASSERT_*() call ends up in an assertion, the test is marked
as a failure and the subsequent error checking is never executed, making
it superfluous.  Remove it for simplicity and to avoid confusion.

Signed-off-by: Lee Jones <lee@kernel.org>
---
 drivers/leds/led-test.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/leds/led-test.c b/drivers/leds/led-test.c
index 068c9d0eb683..23820189abe3 100644
--- a/drivers/leds/led-test.c
+++ b/drivers/leds/led-test.c
@@ -26,8 +26,6 @@ static void led_test_class_register(struct kunit *test)
 
 	ret = devm_led_classdev_register(dev, cdev);
 	KUNIT_ASSERT_EQ(test, ret, 0);
-	if (ret)
-		return;
 }
 
 static struct kunit_case led_test_cases[] = {
-- 
2.49.0.906.g1f30a19c02-goog

[PATCH 2/3] leds: led-test: Fill out the registration test to cover more test cases

[Lee Jones]

Upon successful LED class device registration, it is expected that
certain attributes are filled out in pre-defined ways.  For instance, if
provided, the .brightness_get() call-back should be called to populate
the class device 'brightness' attribute, 'max_brightness' should be
initialised as LED_FULL (at least until we can rid these pesky enums)
and the sysfs group should be created with the class device name
supplied by the caller.

If subsequent registrations take place that would result in name
conflicts, various outcomes are expected depending on which flags are
set.  If LED_REJECT_NAME_CONFLICT is disabled, registration should
succeed resulting in an iteration on the provided name.  Conversely, if
it's enabled, then registration is expected to fail outright.

We test for all of these scenarios here.

Signed-off-by: Lee Jones <lee@kernel.org>
---
 drivers/leds/led-test.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/led-test.c b/drivers/leds/led-test.c
index 23820189abe3..bc85e4513745 100644
--- a/drivers/leds/led-test.c
+++ b/drivers/leds/led-test.c
@@ -10,22 +10,51 @@
 #include <linux/device.h>
 #include <linux/leds.h>
 
+#define LED_TEST_POST_REG_BRIGHTNESS 10
+
 struct led_test_ddata {
 	struct led_classdev cdev;
 	struct device *dev;
 };
 
+static enum led_brightness led_test_brightness_get(struct led_classdev *cdev)
+{
+	return LED_TEST_POST_REG_BRIGHTNESS;
+}
+
 static void led_test_class_register(struct kunit *test)
 {
 	struct led_test_ddata *ddata = test->priv;
-	struct led_classdev *cdev = &ddata->cdev;
+	struct led_classdev *cdev_clash, *cdev = &ddata->cdev;
 	struct device *dev = ddata->dev;
 	int ret;
 
+	/* Register a LED class device */
 	cdev->name = "led-test";
+	cdev->brightness_get = led_test_brightness_get;
+	cdev->brightness = 0;
 
 	ret = devm_led_classdev_register(dev, cdev);
 	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	KUNIT_EXPECT_EQ(test, cdev->max_brightness, LED_FULL);
+	KUNIT_EXPECT_EQ(test, cdev->brightness, LED_TEST_POST_REG_BRIGHTNESS);
+	KUNIT_EXPECT_STREQ(test, cdev->dev->kobj.name, "led-test");
+
+	/* Register again with the same name - expect it to pass with the LED renamed */
+	cdev_clash = devm_kmemdup(dev, cdev, sizeof(*cdev), GFP_KERNEL);
+	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, cdev_clash);
+
+	ret = devm_led_classdev_register(dev, cdev_clash);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	KUNIT_EXPECT_STREQ(test, cdev_clash->dev->kobj.name, "led-test_1");
+	KUNIT_EXPECT_STREQ(test, cdev_clash->name, "led-test");
+
+	/* Enable name conflict rejection and register with the same name again - expect failure */
+	cdev_clash->flags |= LED_REJECT_NAME_CONFLICT;
+	ret = devm_led_classdev_register(dev, cdev_clash);
+	KUNIT_EXPECT_EQ(test, ret, -EEXIST);
 }
 
 static struct kunit_case led_test_cases[] = {
-- 
2.49.0.906.g1f30a19c02-goog

[PATCH 3/3] leds: led-test: Provide tests for the lookup and get infrastructure

[Lee Jones]

This API allows providers to offer an specific LED to be looked-up by a
consumer.  Consumers are then able to describe the aforementioned LED
and take a reference on it.

For convenience, we're testing both sides of the API in just one test
function here.  In reality, both the provider and the consumer would be
logistically orthogonal.

CMD:
  tools/testing/kunit/kunit.py run --kunitconfig drivers/leds

RESULTS:
  [16:38:57] Configuring KUnit Kernel ...
  [16:38:57] Building KUnit Kernel ...
  Populating config with:
  $ make ARCH=um O=.kunit olddefconfig
  Building with:
  $ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=20
  [16:39:02] Starting KUnit Kernel (1/1)...
  [16:39:02] ============================================================
  Running tests with:
  $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
  [16:39:03] ===================== led (2 subtests) =====================
  [16:39:03] [PASSED] led_test_class_register
  [16:39:03] [PASSED] led_test_class_add_lookup_and_get
  [16:39:03] ======================= [PASSED] led =======================
  [16:39:03] ============================================================
  [16:39:03] Testing complete. Ran 2 tests: passed: 2
  [16:39:03] Elapsed time: 6.255s total, 0.001s configuring, 5.131s building, 1.106s running

Signed-off-by: Lee Jones <lee@kernel.org>
---
 drivers/leds/led-test.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/leds/led-test.c b/drivers/leds/led-test.c
index bc85e4513745..ddf9aa967a6a 100644
--- a/drivers/leds/led-test.c
+++ b/drivers/leds/led-test.c
@@ -57,8 +57,37 @@ static void led_test_class_register(struct kunit *test)
 	KUNIT_EXPECT_EQ(test, ret, -EEXIST);
 }
 
+static void led_test_class_add_lookup_and_get(struct kunit *test)
+{
+	struct led_test_ddata *ddata = test->priv;
+	struct led_classdev *cdev = &ddata->cdev, *cdev_get;
+	struct device *dev = ddata->dev;
+	struct led_lookup_data lookup;
+	int ret;
+
+	/* First, register a LED class device */
+	cdev->name = "led-test";
+	ret = devm_led_classdev_register(dev, cdev);
+	KUNIT_ASSERT_EQ(test, ret, 0);
+
+	/* Then make the LED available for lookup */
+	lookup.provider = cdev->name;
+	lookup.dev_id = dev_name(dev);
+	lookup.con_id = "led-test-1";
+	led_add_lookup(&lookup);
+
+	/* Finally, attempt to look it up via the API - imagine this was an orthogonal driver */
+	cdev_get = devm_led_get(dev, "led-test-1");
+	KUNIT_ASSERT_FALSE(test, IS_ERR(cdev_get));
+
+	KUNIT_EXPECT_STREQ(test, cdev_get->name, cdev->name);
+
+	led_remove_lookup(&lookup);
+}
+
 static struct kunit_case led_test_cases[] = {
 	KUNIT_CASE(led_test_class_register),
+	KUNIT_CASE(led_test_class_add_lookup_and_get),
 	{ }
 };
 
-- 
2.49.0.906.g1f30a19c02-goog

Re: [PATCH 1/3] led: led-test: Remove standard error checking after KUNIT_ASSERT_*()

[Lee Jones]

On Thu, 01 May 2025 09:19:11 +0100, Lee Jones wrote:
> If a KUNIT_ASSERT_*() call ends up in an assertion, the test is marked
> as a failure and the subsequent error checking is never executed, making
> it superfluous.  Remove it for simplicity and to avoid confusion.
> 
> 

Applied, thanks!

[1/3] led: led-test: Remove standard error checking after KUNIT_ASSERT_*()
      commit: ea82d1979ca379b64adf6ee4ca09c2e3f96298e4
[2/3] leds: led-test: Fill out the registration test to cover more test cases
      commit: 025415faccf52ce96dacc462a5bdaebae30079ac
[3/3] leds: led-test: Provide tests for the lookup and get infrastructure
      commit: 2de105202e025c7b8c7c36792363879a773bdb96

--
Lee Jones [李琼斯]