On Mon, Aug 22, 2016 at 11:55:24AM -0500, Bjorn Helgaas wrote: > I was imagining these LEDs as some sort of extension to the PCIe > hotplug model, but I think that was a mistake: logically, they have > nothing to do with hotplug, and the only reason they're currently > associated with hotplug is because you chose to re-use a bus (VPP) > that happens to be connected to the Slot Control registers. > > From an architectural point of view, these LEDs seem device-specific > or storage-specific, with no connection to PCIe at all, so I don't > know why we would put them in the PCIe spec or teach pciehp about > them. It's not entirely for hotplug scenarios, but it does help with user pain points locating devices they intend to hot remove. I hear many vendors are for the concept of proposing new status and location indicator definitions to PCIe. I don't think anyone is suggesting the implementation requiring this patch be made standard; this generation of hardware is just a non-standard implementation that needs a quirk to help fill the gap. Would it be more palatable if I modify the quirk such that when set, pciehp provides a sysfs entry allowing arbitrary user defined Slot Control commands? That removes the dangerous direct access from user space. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
