On Fri, Feb 19, 2010 at 09:31:46AM +0530, Rajat Jain wrote: > > 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 .... No, they can check the last one, or something every once in a while. > 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? Test a value that you know will not be this one. > 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); You wait until you do a read :) Seriously, look at the existing drivers in the kernel, they should all handle this just fine. 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
