Re: libata bridge limits

[Jeff Garzik <jeff@garzik.org>]

Jens Axboe wrote:
> On Tue, Aug 26 2008, Jeff Garzik wrote:
>> Jens Axboe wrote:
>>> OK, something like this. Jeff, if you think this is fine, let me know
>>> and I'll submit a proper patch with description and so on.
>>>
>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>>> index 79e3a8e..879ceac 100644
>>> --- a/drivers/ata/libata-core.c
>>> +++ b/drivers/ata/libata-core.c
>>> @@ -2100,6 +2100,10 @@ retry:
>>> static inline u8 ata_dev_knobble(struct ata_device *dev)
>>> {
>>> 	struct ata_port *ap = dev->link->ap;
>>> +
>>> +	if (ata_dev_blacklisted(dev) & ATA_HORKAGE_BRIDGE_OK)
>>> +		return 0;
>>> +
>>> 	return ((ap->cbl == ATA_CBL_SATA) && (!ata_id_is_sata(dev->id)));
>>> }
>>>
>>> @@ -3998,6 +4002,9 @@ static const struct ata_blacklist_entry 
>>> ata_device_blacklist [] = {
>>> 	{ "TSSTcorp CDDVDW SH-S202N", "SB00",	  ATA_HORKAGE_IVB, },
>>> 	{ "TSSTcorp CDDVDW SH-S202N", "SB01",	  ATA_HORKAGE_IVB, },
>>>
>>> +	/* Devices that do not need bridging limits applied */
>>> +	{ "Mtron",		NULL,		0, },
>>> +
>>> 	/* End Marker */
>>> 	{ }
>>> };
>>> diff --git a/include/linux/libata.h b/include/linux/libata.h
>>> index 225bfc5..9f194c0 100644
>>> --- a/include/linux/libata.h
>>> +++ b/include/linux/libata.h
>>> @@ -364,6 +364,7 @@ enum {
>>> 	ATA_HORKAGE_IPM		= (1 << 7),	/* Link PM problems */
>>> 	ATA_HORKAGE_IVB		= (1 << 8),	/* cbl det validity bit bugs 
>>> 	*/
>>> 	ATA_HORKAGE_STUCK_ERR	= (1 << 9),	/* stuck ERR on next PACKET 
>>> 	*/
>>> +	ATA_HORKAGE_BRIDGE_OK	= (1 << 10),	/* no bridge limits */
>>>
>>> 	 /* DMA mask for user DMA control: User visible values; DO NOT
>>> 	    renumber */
>>
>> This one seems fine to me...
> 
> OK, so here's a version that I also tested. I applied the bridge ok flag
> to MTRON MSP-SATA, that is the closest match to the 70xx and 75xx
> series.
> 
> ---
> 
> From: Jens Axboe <jens.axboe@oracle.com>
> Subject: [PATCH] libata: add whitelist for devices with known good pata-sata bridges
> 
> libata currently imposes a UDMA5 max transfer rate and 200 sector max
> transfer size for SATA devices that sit behind a pata-sata bridge. Lots
> of devices have known good bridges that don't need this limit applied.
> The MTRON SSD disks are such devices. Transfer rates are increased by
> 20-30% with the restriction removed.
> 
> So add a "blacklist" entry for the MTRON devices, with a flag indicating
> that the bridge is known good.

applied