Re: [PATCH 5/5] libata: add @disable_on_err argument to ata_set_mode()

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

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.