![]() | ||||||||||
Messages in this thread |
On Wed, Apr 28, 2004 at 07:38:10PM -0500, Brian King wrote: > Greg KH wrote: > >>>What driver is doing this? > >> > >>The ipr driver, a scsi device driver for ppc64. > >> > >>http://marc.theaimsgroup.com/?l=linux-scsi&m=108144942527994&w=2 > >> > >>The driver runs BIST at device initialization time to ensure that the > >>device > >>is in a clean state. > > > > > >Ick. It sounds like "clean state" isn't always true if userspace can > >mess the device up by simply reading its config space :) > > Yeah, its not so much the device, bus the way pSeries PCI bridges work. > Other adapters would have the same problem, but after a quick grep it > doesn't look like running BIST is a very common thing to do in most > Linux drivers. Not really. > >Worse case thing, stop the whole machine while doing BIST if you want to > >prevent this from happening (not that I'm actually suggesting you do it, > >but if you really think it's the only way...) > > Yeah, mdelay(2000) kind of sticks out in a code review;) And, as pointed out by others, will not work :) > Two ideas I had would either be to create interfaces in the pci layer > that a device driver could call to disable all pci adapter accesses and > one to re-enable them. We could probably just make all pci accesses fail > when disabled. These interfaces could then grab the lock and set the > state on the pci_dev, then the read/write interfaces would check the > state after acquiring the lock. Ick, we currently don't keep track of the mapping of things to do this very easily. I don't know what to suggest. Good luck, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 13:02 [from the cache] ©2003-2008 | ||||||||||