On Wed, 6 Mar 2024 16:40:08 -0600 Bjorn Helgaas <helgaas@xxxxxxxxxx> 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
