On Wed, 19 May 2021 12:18:12 +0200 Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote: > Em Wed, 19 May 2021 10:02:53 +0200 > Marek Behún <kabel@xxxxxxxxxx> escreveu: > > > What possible configurations does this support? > > > > Does this blink on rx/tx activity for a specific ethernet port? > > > > When the indicator is set to monitor Ethernet, it can work on either > LAN1, LAN2 or both LAN interfaces. > > > There is a work in progress to add support for transparent offloading of > > LED triggers, with the netdev trigger being the first target. > > > > This means that after that is done, you could implement this driver so > > that when netdev trigger is enabled on a supported interface, your > > driver will offload the blinking to the HW. > > On NUC leds, this is already offloaded to HW/firmware. > > All it takes is to tell the BIOS via ACPI/WMI what LED will be used > for monitoring the Ethernet activity, and on what port(s). Can the LED be put into software controlled mode and also into HW controlled mode so that HW blinks the LED on ethernet activity? If so, then this is what I am talking about: transparent HW offloading of LED triggers: - I have a LED in /sys/class/leds - I set "netdev" trigger on this LED - I set ethernet interface for which the LED should blink - if the HW can blink the LED for that particular ethernet interface, the driver should use HW blinking... > > This should probably also work for HDD activity, but this would need a > > blockdev trigger first... > > HDD activity is also HW/firmware monitored. The only thing the Kernel > needs to to is to select what LED will be set as the HDD activity > indicator. Ditto as above, if we had a "blockdev" LED trigger. Marek
