[PATCH] libata: Handle SATA bridges better

[PATCH] libata: Handle SATA bridges better

[Alan Cox]

In some situations we find that SATA devices are attached via PATA/SATA
bridges. When we find this we need to change a couple of bits of behaviour

-	Error changedown behaviour for SATA is different - no point
dropping to PIO
-	40/80 wire cable detection testing cannot be done.

Thus we need to detect this case and update the cable type accordingly.

Signed-off-by: Alan Cox <alan@redhat.com>

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc1-mm1/drivers/ata/libata-core.c linux-2.6.22-rc1-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.22-rc1-mm1/drivers/ata/libata-core.c	2007-05-18 16:22:53.000000000 +0100
+++ linux-2.6.22-rc1-mm1/drivers/ata/libata-core.c	2007-05-18 16:40:23.000000000 +0100
@@ -2186,6 +2186,16 @@
 	if (ap->ops->cable_detect)
 		ap->cbl = ap->ops->cable_detect(ap);
 
+	/* We may have SATA bridge glue hiding here irrespective of the
+	   reported cable types and sensed types */
+	for (i = 0; i < ATA_MAX_DEVICES; i++) {
+		dev = &ap->device[i];
+		if (!ata_dev_enabled(dev))
+			continue;
+		if (ata_id_is_sata(dev->id))
+			ap->cbl = ATA_CBL_SATA;
+	}
+
 	/* After the identify sequence we can now set up the devices. We do
 	   this in the normal order so that the user doesn't get confused */
 

Re: [PATCH] libata: Handle SATA bridges better

[Tejun Heo]

Alan Cox wrote:
> In some situations we find that SATA devices are attached via PATA/SATA
> bridges. When we find this we need to change a couple of bits of behaviour
> 
> -	Error changedown behaviour for SATA is different - no point
> dropping to PIO
> -	40/80 wire cable detection testing cannot be done.
> 
> Thus we need to detect this case and update the cable type accordingly.
> 
> Signed-off-by: Alan Cox <alan@redhat.com>
> 
> diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.22-rc1-mm1/drivers/ata/libata-core.c linux-2.6.22-rc1-mm1/drivers/ata/libata-core.c
> --- linux.vanilla-2.6.22-rc1-mm1/drivers/ata/libata-core.c	2007-05-18 16:22:53.000000000 +0100
> +++ linux-2.6.22-rc1-mm1/drivers/ata/libata-core.c	2007-05-18 16:40:23.000000000 +0100
> @@ -2186,6 +2186,16 @@
>  	if (ap->ops->cable_detect)
>  		ap->cbl = ap->ops->cable_detect(ap);
>  
> +	/* We may have SATA bridge glue hiding here irrespective of the
> +	   reported cable types and sensed types */
> +	for (i = 0; i < ATA_MAX_DEVICES; i++) {
> +		dev = &ap->device[i];
> +		if (!ata_dev_enabled(dev))
> +			continue;
> +		if (ata_id_is_sata(dev->id))
> +			ap->cbl = ATA_CBL_SATA;
> +	}
> +

I'm not sure this is correct.  The SATA bridge can be at the far side of
PATA cable near to the drive.  ie.

PATA host <========= PATA cable ==========> P/SATA bridge : SATA drive

In this case, most of the cable is PATA and cable detection matters.
Another problem is that there are still codes which interpret ap->cbl ==
ATA_CBL_SATA as SATA host port.  They need to be fixed first before
using ap->cbl for the actual cable type.

-- 
tejun

Re: [PATCH] libata: Handle SATA bridges better

[Alan Cox]

> I'm not sure this is correct.  The SATA bridge can be at the far side of
> PATA cable near to the drive.  ie.
> 
> PATA host <========= PATA cable ==========> P/SATA bridge : SATA drive

Yes

> In this case, most of the cable is PATA and cable detection matters.

The cable detection is done by the drive not the bridge, and for the
boards I've got access to this means that the cable detection doesn't work
at all. This is a big problem with things like the VIA C7 embedded boards
which currently run at the wrong speeds as a result.

> Another problem is that there are still codes which interpret ap->cbl ==
> ATA_CBL_SATA as SATA host port.  They need to be fixed first before
> using ap->cbl for the actual cable type.

I thought we had those all sorted now. A grep shows there is nobody doing
conditional checking off the ap->cbl cable in drivers/ata any more. They
did in the past - which is this patch got held up - but no longer that I
can see.

Alan

Re: [PATCH] libata: Handle SATA bridges better

[Tejun Heo]

Alan Cox wrote:
>> I'm not sure this is correct.  The SATA bridge can be at the far side of
>> PATA cable near to the drive.  ie.
>>
>> PATA host <========= PATA cable ==========> P/SATA bridge : SATA drive
> 
> Yes
> 
>> In this case, most of the cable is PATA and cable detection matters.
> 
> The cable detection is done by the drive not the bridge, and for the
> boards I've got access to this means that the cable detection doesn't work
> at all. This is a big problem with things like the VIA C7 embedded boards
> which currently run at the wrong speeds as a result.

I think host side detection should work as long as the bridge properly
releases CBLID after IDENTIFY.  Drive side detection seems hopeless
unless the bridge modifies IDENTIFY data accordingly.  Maybe the best we
can do here is allowing user to select transfer mode.  :-(

>> Another problem is that there are still codes which interpret ap->cbl ==
>> ATA_CBL_SATA as SATA host port.  They need to be fixed first before
>> using ap->cbl for the actual cable type.
> 
> I thought we had those all sorted now. A grep shows there is nobody doing
> conditional checking off the ap->cbl cable in drivers/ata any more. They
> did in the past - which is this patch got held up - but no longer that I
> can see.

Hmm... I was looking at sata_scr_valid().  I think this needs to be
converted to ATA_FLAG_SATA test too.

-- 
tejun

Re: [PATCH] libata: Handle SATA bridges better

[Tejun Heo]

Alan Cox wrote:
>> I think host side detection should work as long as the bridge properly
>> releases CBLID after IDENTIFY.  Drive side detection seems hopeless
>> unless the bridge modifies IDENTIFY data accordingly.  Maybe the best we
>> can do here is allowing user to select transfer mode.  :-(
> 
> There are far too many systems with this kind of bridge to just dump it
> on the user. I'll have a think about doing it only if the controller
> hasn't decided the cable is 40 wire. That might work.

Okay.

>>>> Another problem is that there are still codes which interpret ap->cbl ==
>>>> ATA_CBL_SATA as SATA host port.  They need to be fixed first before
>>>> using ap->cbl for the actual cable type.
>>> I thought we had those all sorted now. A grep shows there is nobody doing
>>> conditional checking off the ap->cbl cable in drivers/ata any more. They
>>> did in the past - which is this patch got held up - but no longer that I
>>> can see.
>> Hmm... I was looking at sata_scr_valid().  I think this needs to be
>> converted to ATA_FLAG_SATA test too.
> 
> Possibly but PATA controllers don't have ->scr_read so its ok as is.

I'll submit a patch just in case.  I think we used to do depend on that
for PATA/SATA combined controllers before new init model.

Thanks.

-- 
tejun

Re: [PATCH] libata: Handle SATA bridges better

[Alan Cox]

> I think host side detection should work as long as the bridge properly
> releases CBLID after IDENTIFY.  Drive side detection seems hopeless
> unless the bridge modifies IDENTIFY data accordingly.  Maybe the best we
> can do here is allowing user to select transfer mode.  :-(

There are far too many systems with this kind of bridge to just dump it
on the user. I'll have a think about doing it only if the controller
hasn't decided the cable is 40 wire. That might work.

> >> Another problem is that there are still codes which interpret ap->cbl ==
> >> ATA_CBL_SATA as SATA host port.  They need to be fixed first before
> >> using ap->cbl for the actual cable type.
> > 
> > I thought we had those all sorted now. A grep shows there is nobody doing
> > conditional checking off the ap->cbl cable in drivers/ata any more. They
> > did in the past - which is this patch got held up - but no longer that I
> > can see.
> 
> Hmm... I was looking at sata_scr_valid().  I think this needs to be
> converted to ATA_FLAG_SATA test too.

Possibly but PATA controllers don't have ->scr_read so its ok as is.