Re: [PATCH v2] Add support for PCIe SSD status LED management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 6/2/2021 5:40 PM, Pavel Machek wrote:
Hi!

This would cause the system to somehow show the user that that this drive
(or drive slot) is the one that it wants a person to be able to physically
locate (possibly by flashing a blue LED on/near the drive), and also that
the drive is OK.  It would presumably do that by lighting the LEDs on/near
the drive with certain colors and/or flashing patterns, though it could, in
theory, put "OK" in an LCD on the drive slot.  How the states are displayed
to the user is beyond the scope of the specs.

(The _DSM and NPEM specs provide for a way to control status LEDs on a drive
or drive slot.  Typically drives will have 2 or 3 LEDs that are illuminated
in different colors or flashing patterns to indicate various states (like
those listed in IBPI / SFF-8489), though the _DSM / NPEM specs do not
specify how the states are displayed.)

Well, LED subsystem expects to know how many LEDs are there and what
the LEDs are, and expects individual control over them.

"2 or 3 LEDs with unknown patterns", or LCD display is outside of scope
of LED subsystem, so this should be independend.


Yes... I had originally submitted this without using the LED subsystem, and
Greg K-H said I had to (see
https://www.spinics.net/lists/linux-pci/msg102013.html).  Here's the
relevant bit.

...

So I'm not sure what to do.

Explain to Greg that you don't know how particular system implements
the indication. It can be small display, 2 LEDs, 3 LEDs, etc... LED
subsystem expects direct LED control.

Best regards,
								Pavel


Is there any chance you would accept drive status LEDs using the LED subsystem, if the driver was rewritten to represent each possible drive state as a single led_classdev device, each with no special attributes, just brightness of 0 or 1?

The drive states are logically each displaying one bit of information to the user, and each could actually be physically represented by a physical LED (though probably not). I only combined them into a single led_classdev device with an extra attribute because I thought it made more sense to do so, but it sounds like I might have made a bad choice in doing so.

In support of using the LED subsystem for this--there are other LEDs in linux which aren't necessarily always represented by single physical LEDs, such as "caps lock" for keyboards. Virtual consoles display keyboard indicators as text in a window rather than an LED--and someone _could_ make a weird keyboard that displays the 3 bits of caps/scroll/number lock info as a decimal number on a display. My point is that it seems to me that the LED subsystem is already being used for things that logically display a bit of information to the user, which may or may not be represented by a single LED. (Ethernet port LEDs are another possible example--they might combine link present, link speed, and activity all on one LED, by using different colors and flashing patterns.)




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux