From: stuart hayes <stuart.w.hayes@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-pci@vger.kernel.org, Lukas Wunner <lukas@wunner.de>,
Bjorn Helgaas <bhelgaas@google.com>,
Keith Busch <kbusch@kernel.org>,
kw@linux.com
Subject: Re: [PATCH v3] Add support for PCIe SSD status LED management
Date: Mon, 4 Oct 2021 13:04:28 -0500 [thread overview]
Message-ID: <4909152d-7517-5ed9-393c-9c020e901688@gmail.com> (raw)
In-Reply-To: <20210818070503.GF22282@amd>
On 8/18/2021 2:05 AM, Pavel Machek wrote:
> Hi!
>
>> This patch adds support for the PCIe SSD Status LED Management
>> interface, as described in the "_DSM Additions for PCIe SSD Status LED
>> Management" ECN to the PCI Firmware Specification revision 3.2.
>>
>> It will add (led_classdev) LEDs to each PCIe device that has a supported
>> _DSM interface (one off/on LED per supported state). Both PCIe storage
>> devices, and the ports to which they are connected, can support this
>> interface.
>>
>> Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
>
> I believe these are not LEDs, right? This is something that displays
> information to the user, but how exactly it is implemented is up to
> BIOS vendor.
>
> I don't think it is good fit for LED subsystem.
>
> Best regards,
> Pavel
>
I think it very likely these will be LEDs on most, if not all, systems
(likely enough that the PCI ECN has "LEDs" in the name)... they have
been LEDs on every system I've seen. I would suspect that systems which
support more than one or two of the states won't have a 1-to-1 mapping
of logical LEDs to physical LEDs, though, but might instead use
something like IBPI (SFF-8489) to use fewer LEDs and be easier to read
at a glance.
I'm not sure I understand why the LED subsystem would be that much worse
a fit for this than for keyboard (or other) indicator LEDs. I
understand that many other indicators are more likely to have each
single kernel LED mapped to a single physical LED, but functionally they
are both kernel LEDs controlling on/off indicators which are likely
displayed on LEDs that are always visible on the system.
next prev parent reply other threads:[~2021-10-04 18:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 21:36 [PATCH v3] Add support for PCIe SSD status LED management Stuart Hayes
2021-08-14 6:23 ` Lukas Wunner
2021-10-04 17:41 ` stuart hayes
2021-10-05 4:41 ` Williams, Dan J
2021-08-18 7:05 ` Pavel Machek
2021-10-04 18:04 ` stuart hayes [this message]
2021-10-05 5:14 ` Williams, Dan J
2021-10-06 2:42 ` stuart hayes
2021-10-06 20:15 ` Dan Williams
2021-10-07 8:24 ` Pavel Machek
2021-10-07 11:32 ` Tkaczyk, Mariusz
2021-11-02 16:23 ` stuart hayes
2021-11-06 2:52 ` Dan Williams
2021-11-07 14:40 ` James Bottomley
2021-11-12 0:56 ` Krzysztof Wilczyński
2021-11-25 22:13 ` Bjorn Helgaas
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=4909152d-7517-5ed9-393c-9c020e901688@gmail.com \
--to=stuart.w.hayes@gmail.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=kbusch@kernel.org \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=pavel@ucw.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).