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