[+cc Blazej]
On Thu, Jul 11, 2024 at 10:30:06AM +0200, Mariusz Tkaczyk wrote:
> Patchset is named as PCIe Enclosure LED Management because it adds two features:
> - Native PCIe Enclosure Management (NPEM)
> - PCIe SSD Status LED Management (DSM)
>
> Both are pattern oriented standards, they tell which "indication" should blink.
> It doesn't control physical LED or pattern visualization.
>
> Overall, driver is simple but it was not simple to fit it into interfaces
> we have in kernel (We considered leds and enclosure interfaces). It reuses
> leds interface, this approach seems to be the best because:
> - leds are actively maintained, no new interface added.
> - leds do not require any extensions, enclosure needs to be adjusted first.
>
> There are trade-offs:
> - "brightness" is the name of sysfs file to control led. It is not
> natural to use brightness to set patterns, that is why multiple led
> devices are created (one per indication);
> - Update of one led may affect other leds, led triggers may not work
> as expected.
I see the sysfs interface (/sys/.../leds/10000:02:05.0:enclosure:fail,
etc). I assume this is intended for things like ledmon? I think this
should be documented somewhere in Documentation/ABI/ if it's not
already there.
I think that sysfs interface is the same for NPEM and _DSM?
I guess this is basically a newer, better, more generic approach to
the pciehp functionality added by 576243b3f9ea ("PCI: pciehp: Allow
exclusive userspace control of indicators") for NVMe behind VMD?
I suppose it's too late for any hope of unifying all these things in
terms of the user interface? I guess we're stuck with maintaining
576243b3f9ea regardless since users are using it, but the VMD stuff in
ledmon seems like kind of an ugly special case.
Bjorn
