On Tue, Aug 23, 2016 at 02:52:21PM -0500, Bjorn Helgaas wrote: > Everybody probably knows this, but the problem is not with LED control > per se. The problem is multiple writers to the Slot Control register. > Each write to Slot Control is a "command", and software is responsible > for waiting for one command to complete before writing another (see > PCIe r3.0, sec 6.7.3.2). > > It's no problem to make pciehp keep its mitts off the LEDs; the > problem is if ledmon writes Slot Control for the indicators, and > pciehp writes Slot Control for some other reason at about the same > time. > > Sinan has a very interesting idea... Maybe we can work with that. > Hmm, it looks like if we have an attention indicator, we already put > an "attention" file in sysfs (see attention_write_file()). That > should eventually call into pciehp_set_attention_status(), where we > currently only support off/on/blink states. > > What if you made a quirk that replaced pciehp_set_attention_status() > with a special version that supported the extra states you need and > made ledmon use that sysfs file instead of writing Slot Control > directly? Would everything just work? I'm on board with this idea. I'll get some testing started and send a new version if/when successful. -- 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
