Hello Rafael / Bjorn, > > > 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. > 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 ��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
