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
Link: https://lore.kernel.org/r/20250501081918.3621432-3-lee@kernel.org
Signed-off-by: Lee Jones <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.
Link: https://lore.kernel.org/r/20250501081918.3621432-2-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
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.
Link: https://lore.kernel.org/r/20250501081918.3621432-1-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
