RE: How does Linux handle PCI-E Surprise unplug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux