<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/leds, branch v6.16</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>treewide, timers: Rename from_timer() to timer_container_of()</title>
<updated>2025-06-08T07:07:37+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2025-05-09T05:51:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=41cb08555c4164996d67c78b3bf1c658075b75f1'/>
<id>41cb08555c4164996d67c78b3bf1c658075b75f1</id>
<content type='text'>
Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move this API to the canonical timer_*() namespace.

[ tglx: Redone against pre rc1 ]

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'backlight-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight</title>
<updated>2025-06-03T19:52:25+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-06-03T19:52:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a9dfb7db96f7bc1f30feae673aab7fdbfbc94e9c'/>
<id>a9dfb7db96f7bc1f30feae673aab7fdbfbc94e9c</id>
<content type='text'>
Pull backlight updates from Lee Jones:
 "Framebuffer Subsystem (fbdev):
   - The display's blanking status is now tracked in 'struct fb_info'
   - 'framebuffer_alloc()' initializes the blank state to FB_BLANK_UNBLANK
   - 'register_framebuffer()' sets the state to 'FB_BLANK_POWERDOWN' if
     an 'fb_blank' callback exists, ensuring 'FB_EVENT_BLANK' listeners
     correctly see the display being turned on during the first modeset
   - The 'FB_EVENT_BLANK' event data now includes both the new and the
     old blank states
   - 'fb_blank()' has been reworked to return early on errors, without
     functional changes, in preparation for further state tracking
     improvements
   - Fbdev now calls dedicated functions in the backlight subsystems to
     notify them of blank state changes, instead of relying on fbdev
     event notifiers
   - For LCDs, fbdev also calls a dedicated function to notify of mode
     changes
   - Removed the definitions for the unused fbdev event constants
     'FB_EVENT_MODE_CHANGE' and 'FB_EVENT_BLANK' from the header file

  Backlight Subsystem:
   - Implemented fbdev blank state tracking using the (newly enhanced)
     blank state information provided directly by 'FB_EVENT_BLANK'
   - Removed internal blank state tracking fields ('fb_bl_on') from
     'struct backlight_device'
   - Moved the handling of blank-state updates into a separate internal
     helper function, 'backlight_notify_blank()'
   - Removed support for fbdev events and replaced it with a dedicated
     function call interface ('backlight_notify_blank()' and
     'backlight_notify_blank_all()') for display drivers to update
     backlight status

  LCD Subsystem:
   - Moved the handling of display updates (blank events and mode
     changes) from fbdev event notifiers to separate internal helper
     functions ('lcd_notify_blank',
     'lcd_notify_mode_change')
   - Removed support for fbdev events and replaced it with dedicated
     function call interfaces ('lcd_notify_blank_all()',
     'lcd_notify_mode_change_all()')
   - The LCD subsystem now maintains its own internal list of LCD
     devices instead of relying on fbdev notifiers

  LED Backlight Trigger:
   - Moved the handling of blank-state updates into a separate internal
     helper, 'ledtrig_backlight_notify_blank()'
   - Removed support for fbdev events and replaced it with a dedicated
     function call, 'ledtrig_backlight_blank()', for fbdev to notify
     trigger of blank state changes
   - The LED backlight trigger now maintains its own internal list of
     triggers instead of relying on fbdev notifiers

  Qualcomm WLED Backlight:
   - Added a NULL check after 'devm_kasprintf()' in 'wled_configure()'
     to prevent a potential NULL pointer dereference if memory
     allocation fails"

* tag 'backlight-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
  backlight: pm8941: Add NULL check in wled_configure()
  fbdev: Remove constants of unused events
  leds: backlight trigger: Replace fb events with a dedicated function call
  leds: backlight trigger: Move blank-state handling into helper
  backlight: lcd: Replace fb events with a dedicated function call
  backlight: lcd: Move event handling into helpers
  backlight: Replace fb events with a dedicated function call
  backlight: Move blank-state handling into helper
  backlight: Implement fbdev tracking with blank state from event
  fbdev: Send old blank state in FB_EVENT_BLANK
  fbdev: Track display blanking state
  fbdev: Rework fb_blank()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull backlight updates from Lee Jones:
 "Framebuffer Subsystem (fbdev):
   - The display's blanking status is now tracked in 'struct fb_info'
   - 'framebuffer_alloc()' initializes the blank state to FB_BLANK_UNBLANK
   - 'register_framebuffer()' sets the state to 'FB_BLANK_POWERDOWN' if
     an 'fb_blank' callback exists, ensuring 'FB_EVENT_BLANK' listeners
     correctly see the display being turned on during the first modeset
   - The 'FB_EVENT_BLANK' event data now includes both the new and the
     old blank states
   - 'fb_blank()' has been reworked to return early on errors, without
     functional changes, in preparation for further state tracking
     improvements
   - Fbdev now calls dedicated functions in the backlight subsystems to
     notify them of blank state changes, instead of relying on fbdev
     event notifiers
   - For LCDs, fbdev also calls a dedicated function to notify of mode
     changes
   - Removed the definitions for the unused fbdev event constants
     'FB_EVENT_MODE_CHANGE' and 'FB_EVENT_BLANK' from the header file

  Backlight Subsystem:
   - Implemented fbdev blank state tracking using the (newly enhanced)
     blank state information provided directly by 'FB_EVENT_BLANK'
   - Removed internal blank state tracking fields ('fb_bl_on') from
     'struct backlight_device'
   - Moved the handling of blank-state updates into a separate internal
     helper function, 'backlight_notify_blank()'
   - Removed support for fbdev events and replaced it with a dedicated
     function call interface ('backlight_notify_blank()' and
     'backlight_notify_blank_all()') for display drivers to update
     backlight status

  LCD Subsystem:
   - Moved the handling of display updates (blank events and mode
     changes) from fbdev event notifiers to separate internal helper
     functions ('lcd_notify_blank',
     'lcd_notify_mode_change')
   - Removed support for fbdev events and replaced it with dedicated
     function call interfaces ('lcd_notify_blank_all()',
     'lcd_notify_mode_change_all()')
   - The LCD subsystem now maintains its own internal list of LCD
     devices instead of relying on fbdev notifiers

  LED Backlight Trigger:
   - Moved the handling of blank-state updates into a separate internal
     helper, 'ledtrig_backlight_notify_blank()'
   - Removed support for fbdev events and replaced it with a dedicated
     function call, 'ledtrig_backlight_blank()', for fbdev to notify
     trigger of blank state changes
   - The LED backlight trigger now maintains its own internal list of
     triggers instead of relying on fbdev notifiers

  Qualcomm WLED Backlight:
   - Added a NULL check after 'devm_kasprintf()' in 'wled_configure()'
     to prevent a potential NULL pointer dereference if memory
     allocation fails"

* tag 'backlight-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
  backlight: pm8941: Add NULL check in wled_configure()
  fbdev: Remove constants of unused events
  leds: backlight trigger: Replace fb events with a dedicated function call
  leds: backlight trigger: Move blank-state handling into helper
  backlight: lcd: Replace fb events with a dedicated function call
  backlight: lcd: Move event handling into helpers
  backlight: Replace fb events with a dedicated function call
  backlight: Move blank-state handling into helper
  backlight: Implement fbdev tracking with blank state from event
  fbdev: Send old blank state in FB_EVENT_BLANK
  fbdev: Track display blanking state
  fbdev: Rework fb_blank()
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: tps6131x: Add support for Texas Instruments TPS6131X flash LED driver</title>
<updated>2025-05-22T08:24:51+00:00</updated>
<author>
<name>Matthias Fend</name>
<email>matthias.fend@emfend.at</email>
</author>
<published>2025-05-14T10:10:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b338a2ae9b316df1d81b5289badcc8cbbbfe1b2b'/>
<id>b338a2ae9b316df1d81b5289badcc8cbbbfe1b2b</id>
<content type='text'>
The TPS61310/TPS61311 is a flash LED driver with I2C interface. Its power
stage is capable of supplying a maximum total current of roughly 1500mA.
The TPS6131x provides three constant-current sinks, capable of sinking up
to 2 x 400mA (LED1 and LED3) and 800mA (LED2) in flash mode. In torch mode
each sink (LED1, LED2, LED3) supports currents up to 175mA.

Signed-off-by: Matthias Fend &lt;matthias.fend@emfend.at&gt;
Link: https://lore.kernel.org/r/20250514-leds-tps6131x-v5-2-a4fb9e7f2c47@emfend.at
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The TPS61310/TPS61311 is a flash LED driver with I2C interface. Its power
stage is capable of supplying a maximum total current of roughly 1500mA.
The TPS6131x provides three constant-current sinks, capable of sinking up
to 2 x 400mA (LED1 and LED3) and 800mA (LED2) in flash mode. In torch mode
each sink (LED1, LED2, LED3) supports currents up to 175mA.

Signed-off-by: Matthias Fend &lt;matthias.fend@emfend.at&gt;
Link: https://lore.kernel.org/r/20250514-leds-tps6131x-v5-2-a4fb9e7f2c47@emfend.at
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: flash: Add support for flash/strobe duration</title>
<updated>2025-05-14T08:25:09+00:00</updated>
<author>
<name>Richard Leitner</name>
<email>richard.leitner@linux.dev</email>
</author>
<published>2025-05-07T07:51:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6a09ae8281986d5fb5ce0115135c05a5afb8718e'/>
<id>6a09ae8281986d5fb5ce0115135c05a5afb8718e</id>
<content type='text'>
Add support for the new V4L2_CID_FLASH_DURATION control to the LEDs
driver.

Signed-off-by: Richard Leitner &lt;richard.leitner@linux.dev&gt;
Link: https://lore.kernel.org/r/20250507-ov9282-flash-strobe-v4-2-72b299c1b7c9@linux.dev
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for the new V4L2_CID_FLASH_DURATION control to the LEDs
driver.

Signed-off-by: Richard Leitner &lt;richard.leitner@linux.dev&gt;
Link: https://lore.kernel.org/r/20250507-ov9282-flash-strobe-v4-2-72b299c1b7c9@linux.dev
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: rgb: leds-mt6370-rgb: Improve definition of some struct linear_range</title>
<updated>2025-05-14T08:25:08+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2025-05-02T14:51:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f1c86ab98640e9288049673ca2e4517a9df7ed83'/>
<id>f1c86ab98640e9288049673ca2e4517a9df7ed83</id>
<content type='text'>
Use LINEAR_RANGE() instead of hand-writing it. It is more robust, should
the layout of the structure change one day.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/1ce4245107e0a51dce502a007a69899bda018d5f.1746197460.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use LINEAR_RANGE() instead of hand-writing it. It is more robust, should
the layout of the structure change one day.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/1ce4245107e0a51dce502a007a69899bda018d5f.1746197460.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: led-test: Provide tests for the lookup and get infrastructure</title>
<updated>2025-05-14T08:25:07+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2025-05-01T08:19:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cfa40f29df08c7ad296c81a2fac677830af83ec7'/>
<id>cfa40f29df08c7ad296c81a2fac677830af83ec7</id>
<content type='text'>
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 &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: led-test: Fill out the registration test to cover more test cases</title>
<updated>2025-05-14T08:25:06+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2025-05-01T08:19:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=eb58933b78cdad9b879dc2dd248e7284341a1cfc'/>
<id>eb58933b78cdad9b879dc2dd248e7284341a1cfc</id>
<content type='text'>
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 &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: led-test: Remove standard error checking after KUNIT_ASSERT_*()</title>
<updated>2025-05-14T08:25:05+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2025-05-01T08:19:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1d7f25483c8791f395dd857cce8a6a65bcfa295f'/>
<id>1d7f25483c8791f395dd857cce8a6a65bcfa295f</id>
<content type='text'>
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 &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: pca995x: Fix typo in pca995x_of_match's of_device_id entry</title>
<updated>2025-05-14T08:25:04+00:00</updated>
<author>
<name>Jesse Karjalainen</name>
<email>jesse@ponkila.com</email>
</author>
<published>2025-04-26T02:04:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b441b95a592c42f8448f9bd912b91e1e9b4262ff'/>
<id>b441b95a592c42f8448f9bd912b91e1e9b4262ff</id>
<content type='text'>
Remove the stray space between the '.' and the 'data' field name in
the PCA995x device-tree match table.

Signed-off-by: Jesse Karjalainen &lt;jesse@ponkila.com&gt;
Link: https://lore.kernel.org/r/20250426020454.47059-1-jesse@ponkila.com
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove the stray space between the '.' and the 'data' field name in
the PCA995x device-tree match table.

Signed-off-by: Jesse Karjalainen &lt;jesse@ponkila.com&gt;
Link: https://lore.kernel.org/r/20250426020454.47059-1-jesse@ponkila.com
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>leds: Provide skeleton KUnit testing for the LEDs framework</title>
<updated>2025-05-14T08:25:02+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee@kernel.org</email>
</author>
<published>2025-04-24T14:45:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5039a33fed8851fcf384fae2bcb8fd4858edd597'/>
<id>5039a33fed8851fcf384fae2bcb8fd4858edd597</id>
<content type='text'>
Apply a very basic implementation of KUnit LED testing.

More tests / use-cases will be added steadily over time.

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

OUTPUT:
  [15:34:19] Configuring KUnit Kernel ...
  [15:34:19] 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
  [15:34:22] Starting KUnit Kernel (1/1)...
  [15:34:22] ============================================================
  Running tests with:
  $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
  [15:34:23] ===================== led (1 subtest) ======================
  [15:34:23] [PASSED] led_test_class_register
  [15:34:23] ======================= [PASSED] led =======================
  [15:34:23] ============================================================
  [15:34:23] Testing complete. Ran 1 tests: passed: 1
  [15:34:23] Elapsed time: 4.268s total, 0.001s configuring, 3.048s building, 1.214s running

Link: https://lore.kernel.org/r/20250424144544.1438584-1-lee@kernel.org
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Apply a very basic implementation of KUnit LED testing.

More tests / use-cases will be added steadily over time.

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

OUTPUT:
  [15:34:19] Configuring KUnit Kernel ...
  [15:34:19] 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
  [15:34:22] Starting KUnit Kernel (1/1)...
  [15:34:22] ============================================================
  Running tests with:
  $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
  [15:34:23] ===================== led (1 subtest) ======================
  [15:34:23] [PASSED] led_test_class_register
  [15:34:23] ======================= [PASSED] led =======================
  [15:34:23] ============================================================
  [15:34:23] Testing complete. Ran 1 tests: passed: 1
  [15:34:23] Elapsed time: 4.268s total, 0.001s configuring, 3.048s building, 1.214s running

Link: https://lore.kernel.org/r/20250424144544.1438584-1-lee@kernel.org
Signed-off-by: Lee Jones &lt;lee@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
