STRUCT NPEM(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– struct npem(9) β€” the NPEM device properties glow-up πŸ’–

okay so bestie, this is a page from the Kernel API Manual and honestly? it's giving "the blueprint for every NPEM LED in your box." let's get into it 🧚


✨ NAME ✨

struct npem β€” NPEM device properties, aka the whole personality of an NPEM device in one struct 🫢


🌸 SYNOPSIS 🌸

struct npem {
    struct pci_dev *dev;
    const struct npem_ops *ops;
    struct mutex lock;
    u16 pos;
    u32 supported_indications;
    u32 active_indications;
    unsigned int active_inds_initialized:1;
    int led_cnt;
    struct npem_led leds[];
};

look at her. she's structured. she's iconic. πŸ‘‘


πŸ’… MEMBERS πŸ’…

  • dev β€” the PCI device this driver is attached to. like, the whole reason she's here πŸ’–
  • ops β€” backend specific callbacks. the pluggable vibe layer, iykyk πŸ”Œ
  • lock β€” serializes concurrent access to the NPEM device by multiple LED devices. one at a time, bestie, we do not let the LEDs talk over each other 🚦
  • pos β€” cached offset of the NPEM Capability Register in Configuration Space; only used if NPEM registers are accessed directly and not through _DSM. a little cached shortcut, no cap πŸ“
  • supported_indications β€” cached bit mask of supported indications; non-indication and reserved bits in the NPEM Capability Register are cleared in this bit mask. so what's actually supported gets to stay in the mask, the rest gets politely ✨ yeeted ✨
  • active_indications β€” cached bit mask of active indications; non-indication and reserved bits in the NPEM Control Register are cleared in this bit mask. same deal, but for what's lit up rn πŸ”₯
  • active_inds_initialized β€” whether active_indications has been initialized; lowkey the messiest member and honestly the most interesting, so listen up:

On Dell platforms, it is required that IPMI drivers are loaded before the GET_STATE_DSM method is invoked: they use an IPMI OpRegion to get/set the active LEDs. By initializing active_indications lazily (on first access to an LED), IPMI drivers are given a chance to load. If they are not loaded in time, users will see various errors on LED access in dmesg. Once they are loaded, the errors go away and LED access becomes possible.

so tl;dr: the laziness is on purpose. it's not a bug, it's a scheduling strategy. if you're seeing LED errors in dmesg right after boot, that's just the IPMI drivers being fashionably late. they show up, the errors dip, and everything slays. πŸ’€βœ¨
  • led_cnt β€” size of the leds array. she counts. she's organized. she ate πŸ“Š
  • leds β€” array containing LED class devices of all supported LEDs. the whole squad, all in one array 🌈

πŸ‘€ SEE ALSO πŸ‘€

  • Kernel file ./drivers/pci/npem.c
  • struct npem_led(9)
  • struct npem_ops(9)
  • dsm_evaluate(9)

go read them, they're all friends, it's a whole friend group 🫢


and that's the page, bestie! πŸŽ€ this little masterpiece lives under ./drivers/pci and it's dated October 2026 β€” so mark your calendar, <rainbow>struct npem(9) is coming for you` πŸ’œβ­ see you there πŸ˜­πŸ’–

πŸ“¦ where this page comes from