On Thu, Aug 01, 2024 at 11:06:26AM +0200, Marek Behún wrote: > It is not my intention to be unreasonable, I am just asking questions. > I am sorry for getting into this discussion this late. Thanks for your understanding! > On Wed, Jul 31, 2024 at 05:52:49PM +0200, Lukas Wunner wrote: > > "Blinking" in the rx/tx activity context means that the LED is turned on > > when traffic is flowing and off when it is not flowing. Because traffic > > is usually not flowing constantly, the LED is "blinking". > > > > In the NPEM context, my understanding is "blinking" means the LED turns > > on or off *in a regular interval* to indicate that the corresponding > > NPEM bit has been set. > > Ah! So the LEDs states is not supposed to be managed by hardware, > but by software? From the userspace? Yes the LEDs will be controlled through ledmon(8), which is maintained by Mariusz. Though conceivably any other piece of software will do as well. Basically the PCIe Base Spec defines registers to set/get LED states (NPEM). And the PCI Firmware Spec defines an alternative ACPI _DSM interface to control the same LEDs. The spec says ACPI _DSM shall be preferred over direct register access (NPEM) whenever _DSM is available. The idea apparently being that a portion of the LEDs is under control of platform firmware and the remaining LEDs are under OS control. And by using the _DSM interface, there are no conflicting register accesses by firmware and OS. The enclosure vendor is free to use e.g. LEDs which are on continuously, or they may choose to let certain LEDs blink in a regular interval. E.g. the enclosure vendor may decide that the "failure" LED is red and blinks in a regular interval when its corresponding register bit is set so that it's easier for an administrator to identify the faulty drive in a rack full of other drives with tons of LEDs. Conceivably we could one day add a led_trigger for some or all of these LEDs. Question is whether it makes sense. Maybe if the nvme driver can detect a faulty drive it could trigger that the failure LED is lit up. The design to use one led_classdev per register bit was chosen precisely to allow for such future extensions. Thanks, Lukas
