Fallback sequence in scsi_transport_spi

Fallback sequence in scsi_transport_spi

[Hannes Reinecke]

Hi James,

it appears that the fallback sequence in
scsi_transport_spi.c:spi_dv_retrain()
is somewhat incorrect.

According to SPI-3 (spi3r14, actually), the flags DT, IU, and QAS can be
set in the following order of precedence (Table 55, p 155):
- DT
- IU
- QAS

This implies that for QAS DT and IU _have_ to be set. Vice versa for a
retrain we first should unset QAS, then IU (as QAS without IU is
invalid) and then DT.

However, the fallback routine in spi_dv_retrain first unsets IU, _then_
QAS, and ignoring DT entirely. This smells a bit fishy.
Any reasons for this?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fallback sequence in scsi_transport_spi

[James Bottomley]

On Mon, 2005-07-25 at 10:30 +0200, Hannes Reinecke wrote:
> it appears that the fallback sequence in
> scsi_transport_spi.c:spi_dv_retrain()
> is somewhat incorrect.
> 
> According to SPI-3 (spi3r14, actually), the flags DT, IU, and QAS can be
> set in the following order of precedence (Table 55, p 155):
> - DT
> - IU
> - QAS

Actually, this is superceded by spi4 and 5.  QAS is now optional for any
transfer agreement.

> However, the fallback routine in spi_dv_retrain first unsets IU, _then_
> QAS, and ignoring DT entirely. This smells a bit fishy.
> Any reasons for this?

DT is theoretically a more stable transfer mechanism in the face of line
noise than ST, so if the drive supports it, it makes some sense to back
down the periods still retaining DT if possible.  DT also mandates data
group transfers if IU isn't mandated, so it's a safer protocol at
detecting errors as well.

James