From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, linux-leds@vger.kernel.org,
Lukas Wunner <lukas@wunner.de>,
Stuart Hayes <stuart.w.hayes@gmail.com>
Subject: Re: [PATCH 2/2] PCI/NPEM: Add Native PCIe Enclosure Management support
Date: Mon, 11 Mar 2024 10:47:50 +0100 [thread overview]
Message-ID: <20240311104750.00000c24@linux.intel.com> (raw)
In-Reply-To: <20240306224008.GA554220@bhelgaas>
On Wed, 6 Mar 2024 16:40:08 -0600
Bjorn Helgaas <helgaas@kernel.org> wrote:
> > + pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_NPEM);
> > + if (pos == 0)
> > + return;
> > +
> > + if (pci_read_config_dword(dev, pos + PCI_NPEM_CAP, &cap) != 0 ||
> > + (cap & PCI_NPEM_CAPABLE) == 0)
> > + return;
> > +
> > + /*
> > + * OS should use the DSM for LED control if it is available
> > + * PCI Firmware Spec r3.3 sec 4.7.
> > + */
> > + if (npem_has_dsm(dev))
> > + return;
>
> Does Linux have support for this _DSM? I don't see any, and I guess
> this check means that if we have a device that supports NPEM on a
> platform that supplies this _DSM, we can't use NPEM.
No, Linux doesn't support _DSM. It was proposed in previous iterations by Stuart
but I dropped it. We decided that it need to be strongly rebuild because
"pci/pcie" is not right place for ACPI code so we cannot register _DSM
driver instead of NPEM as it was proposed and I don't have _DSM capable
hardware to test it.
>
> The stated intent of the _DSM (from the Feb 12, 2020 ECN at
> https://members.pcisig.com/wg/PCI-SIG/document/14025) is to provide
> NPEM-like functionality via an abstraction layer on top of NPEM, SES,
> or other implementations.
>
> The _DSM also gives the platform a chance to intercept and change or
> reject indications requested by OSPM, although that isn't mentioned as
> part of the intent.
>
> I'm interested in your thoughts about this. One possibility would be
> to omit this check for now and add it back when the _DSM is supported,
> so we could use NPEM directly when advertised by a device. Or we
> could keep this as-is and prohibit use of NPEM if the _DSM exists,
> even though we know how to operate it.
I decided to implement it 2nd way because I don't know if I can use NPEM if
_DSM is implemented, I mean that hardware may do not response on NPEM requests.
I choose safer approach, I have no opinion.
I will follow community voice.
Thanks,
Mariusz
next prev parent reply other threads:[~2024-03-11 9:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 14:23 [PATCH 0/2] Native PCIe Enclosure Management Mariusz Tkaczyk
2024-02-15 14:23 ` [PATCH 1/2] leds: Init leds class earlier Mariusz Tkaczyk
2024-02-15 14:23 ` [PATCH 2/2] PCI/NPEM: Add Native PCIe Enclosure Management support Mariusz Tkaczyk
2024-03-06 22:40 ` Bjorn Helgaas
2024-03-07 12:25 ` Lukas Wunner
2024-03-11 9:47 ` Mariusz Tkaczyk [this message]
2024-03-11 22:13 ` Bjorn Helgaas
[not found] ` <CAL5oW00nSZV=oAjWPbYTwVGZ9OS1hW9hyZ5C0yzWbMjAstAA2g@mail.gmail.com>
2024-03-12 9:08 ` Mariusz Tkaczyk
2024-03-22 19:56 ` Bjorn Helgaas
2024-03-22 21:30 ` Dan Williams
2024-03-22 21:42 ` Bjorn Helgaas
2024-03-22 21:51 ` Dan Williams
2024-03-23 5:09 ` 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=20240311104750.00000c24@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=helgaas@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--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.