From: Pavel Machek <pavel@ucw.cz>
To: stuart hayes <stuart.w.hayes@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, Keith Busch <kbusch@kernel.org>,
kw@linux.com,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Subject: Re: [PATCH v2] Add support for PCIe SSD status LED management
Date: Wed, 2 Jun 2021 11:05:04 +0200 [thread overview]
Message-ID: <20210602090504.GA10900@amd> (raw)
In-Reply-To: <6ee11975-fad7-1a82-f7f3-279ebd4f67cb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
Hi!
> >>> [ok] [locate] failed rebuild pfa hotspare ica ifa invalid disabled
> >
> >So what does this do? Turns the LED on if driver is in "ok" or
> >"locate" states?
> >
>
> 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.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2021-06-02 9:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-01 20:38 [PATCH v2] Add support for PCIe SSD status LED management Stuart Hayes
2021-06-01 21:20 ` Randy Dunlap
2021-06-01 22:38 ` Pavel Machek
2021-06-02 3:18 ` stuart hayes
2021-06-02 9:05 ` Pavel Machek [this message]
2021-06-02 15:36 ` stuart hayes
2021-06-02 22:40 ` Pavel Machek
2021-06-04 20:13 ` stuart hayes
2021-06-02 16:33 ` Marek Behún
2021-06-01 23:39 ` Randy Dunlap
2021-06-01 23:48 ` kernel test robot
2021-06-01 23:48 ` kernel test robot
2021-06-02 7:05 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210602090504.GA10900@amd \
--to=pavel@ucw.cz \
--cc=bhelgaas@google.com \
--cc=kbusch@kernel.org \
--cc=kw@linux.com \
--cc=linux-leds@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=stuart.w.hayes@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.