From: Lee Jones <lee@kernel.org>
To: lee@kernel.org, Pavel Machek <pavel@kernel.org>,
linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: bettyzhou@google.com, ynaffit@google.com, tkjos@google.com,
jacek.anaszewski@gmail.com
Subject: [PATCH 2/3] leds: led-test: Fill out the registration test to cover more test cases
Date: Thu, 1 May 2025 09:19:12 +0100 [thread overview]
Message-ID: <20250501081918.3621432-2-lee@kernel.org> (raw)
In-Reply-To: <20250501081918.3621432-1-lee@kernel.org>
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
next prev parent reply other threads:[~2025-05-01 8:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-01 8:19 [PATCH 1/3] led: led-test: Remove standard error checking after KUNIT_ASSERT_*() Lee Jones
2025-05-01 8:19 ` Lee Jones [this message]
2025-05-01 8:19 ` [PATCH 3/3] leds: led-test: Provide tests for the lookup and get infrastructure Lee Jones
2025-05-08 13:53 ` [PATCH 1/3] led: led-test: Remove standard error checking after KUNIT_ASSERT_*() Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250501081918.3621432-2-lee@kernel.org \
--to=lee@kernel.org \
--cc=bettyzhou@google.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=tkjos@google.com \
--cc=ynaffit@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox