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 -- http://www.livejournal.com/~pavelmachek
Attachment:
signature.asc
Description: PGP signature
