• Mariusz Tkaczyk's avatar
    PCI/NPEM: Add Native PCIe Enclosure Management support · 4e893545
    Mariusz Tkaczyk authored
    Native PCIe Enclosure Management (NPEM, PCIe r6.1 sec 6.28) allows managing
    LEDs in storage enclosures. NPEM is indication oriented and it does not
    give direct access to LEDs. Although each indication *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.
    
    Each enabled indication (capability register bit on) is represented as a
    ledclass_dev which can be controlled through sysfs. For every ledclass
    device only 2 brightness states are allowed: LED_ON (1) or LED_OFF (0).
    This corresponds to the NPEM control register (Indication bit on/off).
    
    Ledclass devices appear in sysfs as child devices (subdirectory) of PCI
    device which has an NPEM Extended Capability and indication is enabled in
    NPEM capability register. For example, these are LEDs created for pcieport
    "10000:02:05.0" on my setup:
    
      leds/
      ├── 10000:02:05.0:enclosure:fail
      ├── 10000:02:05.0:enclosure:locate
      ├── 10000:02:05.0:enclosure:ok
      └── 10000:02:05.0:enclosure:rebuild
    
    They can be also found in "/sys/class/leds" directory. The parent PCIe
    device domain/bus/device/function address is used to guarantee uniqueness
    across leds subsystem.
    
    To enable/disable a "fail" indication, the "brightness" file can be edited:
    
      echo 1 > ./leds/10000:02:05.0:enclosure:fail/brightness
      echo 0 > ./leds/10000:02:05.0:enclosure:fail/brightness
    
    PCIe r6.1, sec 7.9.19.2 defines the possible indications.
    
    Multiple indications for same parent PCIe device can conflict and hardware
    may update them when processing new request. To avoid issues, driver
    refresh all indications by reading back control register.
    
    This driver expects to be the 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, and it assumes the mutex lock gives
    protection from concurrent updates.
    
    If _DSM LED management is available, we assume the platform may be using
    NPEM for its own purposes (see PCI Firmware Spec r3.3 sec 4.7), so the
    driver does not use NPEM. A future patch will add _DSM support; an info
    message notes whether NPEM or _DSM is being used.
    
    NPEM is a PCIe extended capability so it should be registered in
    pcie_init_capabilities() but it is not possible due to LED dependency.  The
    parent pci_device must be added earlier for led_classdev_register() to be
    successful. NPEM does not require configuration on kernel side, so it is
    safe to register LED devices later.
    
    Link: https://lore.kernel.org/r/20240904104848.23480-3-mariusz.tkaczyk@linux.intel.comSuggested-by: default avatarLukas Wunner <lukas@wunner.de>
    Signed-off-by: default avatarMariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
    Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    Tested-by: default avatarStuart Hayes <stuart.w.hayes@gmail.com>
    Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    Reviewed-by: default avatarIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
    4e893545
Kconfig 8.64 KB