Control: tag -1 upstream On Sun, 2016-05-22 at 17:23 +0200, Steinar H. Gunderson wrote: > Package: src:linux > Version: 4.5.3-2 > Severity: normal > > Hi, > > My ODROID XU4 has a blue LED on it, which, after # has been fixed, > is supposed to be a heartbeat LED, being solid-on during the bootloader > and then flashing when the OS is active. (The manual says so, and > “heartbeat” is the default mapping in the device tree for XU4.) > > However, Debian's kernel ships with CONFIG_LEDS_TRIGGER_HEARTBEAT=m, > which means this function doesn't work out of the box. As a workaround, > you can load the module manually (or put it in /etc/modules). I don't know of a > way to have the device tree signal to the kernel that a given module should be > loaded The device tree already tells the kernel what trigger should be used, and the kernel can then make the decision whether that requires loading a module. > (and I don't know how that would interact with initramfs), but I haven't > looked too deeply. However, it should probably come up as soon as possible to > check that the bootloader actually managed to boot the kernel, and it's not > big (the .ko is ~9 kB), so it's probably best to just build it into the kernel, > which is also what the Kconfig help text says. > > On a quick grep, it seems most of these LEDs in the device trees are mapped > to either cpu*, mmc, default-on or heartbeat. CPU is already built in > and MMC logically gets loaded along with the device, but always-on and > heartbeat are built as modules. > > So my guess would be that the kernel should have these changes: > > CONFIG_LEDS_TRIGGER_HEARTBEAT=y > CONFIG_LEDS_TRIGGER_DEFAULT_ON=y I disagree; it doesn't make sense to build in every trigger that might be needed. This is really a bug in the LED device core, not in our configuration. Ben. -- Ben Hutchings friends: People who know you well, but like you anyway.
Attachment:
signature.asc
Description: This is a digitally signed message part