From: Bjorn Helgaas <helgaas@kernel.org>
To: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Cc: linux-pci@vger.kernel.org, "Lukas Wunner" <lukas@wunner.de>,
"Christoph Hellwig" <hch@lst.de>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Stuart Hayes" <stuart.w.hayes@gmail.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Keith Busch" <kbusch@kernel.org>,
"Marek Behun" <marek.behun@nic.cz>, "Pavel Machek" <pavel@ucw.cz>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v6 2/3] PCI/NPEM: Add Native PCIe Enclosure Management support
Date: Wed, 14 Aug 2024 16:49:30 -0500 [thread overview]
Message-ID: <20240814214930.GA5507@bhelgaas> (raw)
In-Reply-To: <20240814122900.13525-3-mariusz.tkaczyk@linux.intel.com>
On Wed, Aug 14, 2024 at 02:28:59PM +0200, Mariusz Tkaczyk wrote:
> Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows
> managing LED in storage enclosures. NPEM is indication oriented
> and it does not give direct access to LED. Although each of
> the indications *could* represent an individual LED, multiple
> indications could also be represented as a single,
> multi-color LED or a single LED blinking in a specific interval.
> The specification leaves that open.
> ...
> Driver is projected to be exclusive NPEM extended capability manager.
> It waits up to 1 second after imposing new request, it doesn't verify if
> controller is busy before write, assuming that mutex lock gives protection
> from concurrent updates.
> Driver is not registered if _DSM LED management
> is available.
IMO we should drop this sentence (more details below).
> NPEM is a PCIe extended capability so it should be registered in
> pcie_init_capabilities() but it is not possible due to LED dependency.
> Parent pci_device must be added earlier for led_classdev_register()
> to be successful. NPEM does not require configuration on kernel side, it
> is safe to register LED devices later.
>
> Link: https://members.pcisig.com/wg/PCI-SIG/document/19849 [1]
I can update this myself, no need to repost just for this, but I think
these links are pointless because they're useless except for PCI-SIG
members, and I don't want to rely them being permalinks anyway.
A reference like "PCIe r6.1" is universally and permanently
meaningful.
> +struct npem {
> + struct pci_dev *dev;
> + const struct npem_ops *ops;
> + struct mutex lock;
> + u16 pos;
> + u32 supported_indications;
> + u32 active_indications;
> +
> + /*
> + * Use lazy loading for active_indications to not play with initcalls.
> + * It is needed to allow _DSM initialization on DELL platforms, where
> + * ACPI_IPMI must be loaded first.
> + */
> + unsigned int active_inds_initialized:1;
What's going on here? I hope we can at least move this to the _DSM
patch since it seems related to that, not to the NPEM capability. I
don't understand the initcall reference or what "lazy loading" means.
Is there some existing ACPI ordering that guarantees ACPI_IPMI happens
first? Why do we need some Dell-specific thing here?
What is ACPI_IPMI? I guess it refers to the "acpi_ipmi" module,
acpi_ipmi.c?
> +#define DSM_GUID GUID_INIT(0x5d524d9d, 0xfff9, 0x4d4b, 0x8c, 0xb7, 0x74, 0x7e,\
> + 0xd5, 0x1e, 0x19, 0x4d)
> +#define GET_SUPPORTED_STATES_DSM 1
> +#define GET_STATE_DSM 2
> +#define SET_STATE_DSM 3
> +
> +static const guid_t dsm_guid = DSM_GUID;
> +
> +static bool npem_has_dsm(struct pci_dev *pdev)
> +{
> + acpi_handle handle;
> +
> + handle = ACPI_HANDLE(&pdev->dev);
> + if (!handle)
> + return false;
> +
> + return acpi_check_dsm(handle, &dsm_guid, 0x1,
> + BIT(GET_SUPPORTED_STATES_DSM) |
> + BIT(GET_STATE_DSM) | BIT(SET_STATE_DSM));
> +}
> +void pci_npem_create(struct pci_dev *dev)
> +{
> + const struct npem_ops *ops = &npem_ops;
> + int pos = 0, ret;
> + u32 cap;
> +
> + if (!npem_has_dsm(dev)) {
> + 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_CAP_CAPABLE) == 0)
> + return;
> + } else {
> + /*
> + * OS should use the DSM for LED control if it is available
> + * PCI Firmware Spec r3.3 sec 4.7.
> + */
> + return;
> + }
I know this is sort of a transient state since the next patch adds
full _DSM support, but I do think (a) the fact that NPEM will stop
working simply because firmware adds _DSM support is unexpected
behavior, and (b) npem_has_dsm() and the other ACPI-related stuff
would fit better in the next patch. It's a little strange to have
them mixed here.
> +++ b/include/uapi/linux/pci_regs.h
> ...
> +#define PCI_NPEM_CAP 0x04 /* NPEM capability register */
> +#define PCI_NPEM_CAP_CAPABLE 0x00000001 /* NPEM Capable */
> +
> +#define PCI_NPEM_CTRL 0x08 /* NPEM control register */
> +#define PCI_NPEM_CTRL_ENABLE 0x00000001 /* NPEM Enable */
Spaces instead of tabs after #define, as you did below (mostly), would
make the diff prettier.
> +#define PCI_NPEM_CMD_RESET 0x00000002 /* NPEM Reset Command */
> +#define PCI_NPEM_IND_OK 0x00000004 /* NPEM indication OK */
> +#define PCI_NPEM_IND_LOCATE 0x00000008 /* NPEM indication Locate */
> ...
> +#define PCI_NPEM_STATUS 0x0c /* NPEM status register */
> +#define PCI_NPEM_STATUS_CC 0x00000001 /* NPEM Command completed */
Ditto.
Bjorn
next prev parent reply other threads:[~2024-08-14 21:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-14 12:28 [PATCH v6 0/3] PCIe Enclosure LED Management Mariusz Tkaczyk
2024-08-14 12:28 ` [PATCH v6 1/3] leds: Init leds class earlier Mariusz Tkaczyk
2024-08-14 12:28 ` [PATCH v6 2/3] PCI/NPEM: Add Native PCIe Enclosure Management support Mariusz Tkaczyk
2024-08-14 21:49 ` Bjorn Helgaas [this message]
2024-08-15 5:45 ` Lukas Wunner
2024-08-15 17:42 ` Bjorn Helgaas
2024-08-20 13:25 ` Mariusz Tkaczyk
2024-08-20 13:52 ` Lukas Wunner
2024-08-14 12:29 ` [PATCH v6 3/3] PCI/NPEM: Add _DSM PCIe SSD status LED management Mariusz Tkaczyk
2024-08-14 20:27 ` [PATCH v6 0/3] PCIe Enclosure LED Management Bjorn Helgaas
2024-08-21 14:02 ` Lee Jones
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=20240814214930.GA5507@bhelgaas \
--to=helgaas@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=marek.behun@nic.cz \
--cc=mariusz.tkaczyk@linux.intel.com \
--cc=pavel@ucw.cz \
--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.