Alan wrote: >> To prevent that, the value is cached on driver probe and written back on >> driver detach on pata_amd, which is necessary even when there is no > > Which is useless. I can agree to 'not always effective' but its useful in common driver load/unload cases. >> suspend/resume as mode programming alters the content of the register. >> amd74xx cannot be unloaded, so caching is enough. Also, doesn't >> suspend/resume cycle store and restore PCI space anyway? > > If I load the driver after a kexec or after a suspend/resume cycle both > of which are quite valid your code breaks. I wrote about kexec in the other reply. And about loading after suspend/resume, yeap, it's outside of saved area, so it'll probably contain reset or random value. Again, the worst that happens is limiting transfer mode to udma33, which, considering the likelihood of the scenario weighted against the common case, is acceptable, IMHO. I think the first thing we need to do is verifying this problem. If this is a rare problem, let's forget about it. If it can be easily reproduced, we need to do something about it one way or the other - maybe sniffing BIOS mode as I did or maybe different smart trick. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
