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 - To unsubscribe from this list: 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
