Hello Rafael, > >> >> > I have this doubt lingering on, and I'd appreciate if some one could >> throw light on this: >> > >> > The kernel hotplug driver pciehp can initiate hotplug based on what >> it senses from the HW (button press etc). >> > >> > The user space can also initiate the same operations by using >> "rescan" or "remove" attributes in sysfs. >> > >> > My questions: >> > >> > 1) Is it safe to mix the above two? >> >> Not right now, but with these patches applied: >> >> https://patchwork.kernel.org/patch/3466551/ >> https://patchwork.kernel.org/patch/3466581/ >> https://patchwork.kernel.org/patch/3466601/ >> https://patchwork.kernel.org/patch/3466591/ >> https://patchwork.kernel.org/patch/3466631/ >> https://patchwork.kernel.org/patch/3466641/ >> https://patchwork.kernel.org/patch/3466651/ >> https://patchwork.kernel.org/patch/3491811/ >> https://patchwork.kernel.org/patch/3466491/ >> https://patchwork.kernel.org/patch/3473341/ >> >> it should be. >> > Not sure if my last mail reached out to the list, sending again: Thanks for the pointer. I assume the above patch set also takes care of the situation, where a hotplug driver attempts to initiate a new hotplug event, before the previous operation was complete on that hot-pluggable slot? E.g.: If a card was very quickly added and immediately removed before the PCI core could process "ADD" event (or vice versa). In other words, if pciehp_enable_slot() was called before the pciehp_disable_slot() returns. Is this situation covered by the locks introduced by the patchset above? If yes, then I assume the following patch is not needed? http://lists.openwall.net/linux-kernel/2013/12/17/724 Thanks, Rajat -- 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
