On Gwe, 2006-03-24 at 10:04 -0500, Jeff Garzik wrote: > * set features - xfer mode fails We should retry here btw but don't > * we offline failed device > * we talk to another device on the same bus > * now the PATA cable is possibly spewing something the failed device > won't like The only thing that will matter is address setup timings. Since we compute the acceptable modes and set modes according to the pair of drives if present I would expect the disabling to risk us setting a wrong mode. A deferred disable would behave better perhaps > Another scenario: some of the drivers/ide hardware supported only by > the 'generic' driver. Some of the hardware, we can do what the device > is already programmed to do, and that's it. It might be in DMA mode, in > which case we can DMA. But we can't [re]tune it at all. All handled by the PATA patches which don't use the usual mode compute path at all but their own setup function replacement. > Thus if set features - xfer mode fails, we can do the easy thing -- stop > talking to the port completely -- or the hard thing, recovery. Recovery > should involve attempting to see if the device, which by definition > responded to IDENTIFY DEVICE successfully, will once again respond to > IDENTIFY DEVICE. We don't care what mode the other device is in, we just care that any shared timing address setup is the slower of the pair on the cable. We could just assume its in PIO_0 for timing purposes then offline it after timing set up. - : 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
