Hello Greg, > > Consider that the device in the slot is working normally, with its > > driver attached to the device, and is doing all sorts of read / write > > operations on the device registers that have been mapped into the PCI > > memory space. Now when that device is suddenly plugged out (and thus its > > registers suddenly disappear from the PCI memory space), the device > > driver is still unaware as it is doing the register reads / writes on > > the device. At this point, IMHO any attempt to access the device > > registers will result in an exception (BUS error?) as the device is > > gone. Correct? > > The driver will suddenly start reading all 0xff and will then need to > abort whatever it was doing. Usually all drivers handle this just fine > today, as this is what they needed to do when they were pccard devices. > Nothing new here at all. It is fairly common for the drivers to have such code: Val1 = ioread32(reg1); Val2 = ioread32(reg2); Val3 = ioread32(reg3); Val4 = ioread32(reg4); Do you mean the above code is wrong and it should be re-written as: If ((Val1 = ioread32(reg1)) == 0xFFFFFFFF) /* Abort */ If ((Val2 = ioread32(reg2)) == 0xFFFFFFFF) /* Abort */ Etc .... Checking for 0xFFFFFFFF at every read is a pain, don't you think so? And more over, what is a register ACTUALLY contains the value 0xFFFFFFFF? How do we differentiate this with the case when the device has been plugged out? Finally, how do we re-write the following code to handle this correctly? iowrite32(val1, reg1); iowrite32(val2, reg2); iowrite32(val3, reg3); iowrite32(val4, reg4); Thanks, Rajat Jain > > > From what I understood from the "pciehp.ko" code, it seems that on > > detecting that a device has been plugged out, pciehp_disable_slot() is > > called only in workqueue context (that will happen later). This would > > lead to removal of the device from the PCI hierarchy in the kernel data > > structures, and ultimately the driver will also be detached. > > Yes. > > > But my question is that it may be too late for all of the above to > > happen, and the driver code may still get a chance to run and continue > > execution from where it was interrupted (accessing device registers) due > > to surprise removal interrupt. And this is bound to break things. So > > what am I missing here? > > Nothing, the driver individually needs to handle the fact that it might > at any time, start getting invalid data. If it doesn't, it needs to be > fixed. Do you have a driver that does not handle this properly? > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
