Re: [RFC/PATCHSET] libata: new reset mechanism

[Jeff Garzik <jgarzik@pobox.com>]

Tejun Heo wrote:
> Hello, all.
> 
> Currently libata uses ->phy_reset to reset ports.  However,
> ->phy_reset is tightly woven into probing process (directly
> manipulating device[]->class and disabling ports on failure) and thus
> awkward to use for error handling or other purposes.
> 
> Another problem with the current scheme is that libata doesn't have
> much control over reset process, which isn't very nice for both
> initialization and error handling.
> 
> This patchset implements new reset mechanism.  The new mechanism can
> peacefully live side-by-side with ->phy_reset mechanism and low level
> drivers can be converted gradually.  This patchset converts sata_sil,
> sata_sil24, ata_piix and ahci as a start.
> 
> This patchset is composed of the following 14 patches.
> 
> #01-03	: implement new reset mechanism and standard callbacks
> #04	: preparation for low level driver conversion
> #05	: convert sata_sil
> #06-07	: convert sata_sil24 and add hardreset
> #08-09	: convert ata_piix
> #10-14	: convert ahci and add softreset

Hard and soft reset should be implemented as

	qc = ata_qc_new_init()
	qc->tf.protocol = ATA_PROT_HARD_RESET;
	... ata_qc_issue() ...

which automatically takes advantage of the ability to specify a behavior 
using the qc_prep/qc_issue driver hooks.  The ATA passthru CDB supports 
this method of programming (hard and soft reset are specified 
protocols), and this is very similar to how the SiI 3124 behaves.  Other 
FIS-based controllers will implement qc_issue/qc_prep such that they 
send two Control FIS's.  Taskfile-based controllers use the currently 
implemented method.

On a separate note, E.D.D. support can probably be dropped.  No driver 
uses it AFAIK.  It was only used during development and in the early 
libata days.

Further, we should lean towards avoiding hard reset, and issuing SRST 
most of the time, even for drivers currently doing hard reset (COMRESET).

	Jeff