Re: libata bridge limits

[Jens Axboe <jens.axboe@oracle.com>]

On Tue, Aug 26 2008, Tejun Heo wrote:
> Jens Axboe wrote:
> > Given that this problem should be going away and that it only really
> > matters on very select devices (like this SSD), I think we should just
> > add a quick white list for the bridge limits.
> 
> Yeah, it sucks that up & coming SSDs are still using PATA-SATA bridges.
>  The expectation when adding the wildcard limitation was that those P/S
> bridges are not gonna be around for too long and the limit is most
> likely not be an actual problem.  Oh well...

I would hope that only the current generation do that, and to be honest
I'm still pretty baffled that they exist :-)

> > Below is a quick'n dirty for that...
> > 
> > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> > index 79e3a8e..fe8033a 100644
> > --- a/drivers/ata/libata-core.c
> > +++ b/drivers/ata/libata-core.c
> > @@ -2097,9 +2097,70 @@ retry:
> >  	return rc;
> >  }
> >  
> > +struct ata_blacklist_entry {
> > +	const char *model_num;
> > +	const char *model_rev;
> > +	unsigned long horkage;
> > +};
> > +
> > +static const struct ata_blacklist_entry ata_bridge_whitelist[] = {
> > +	/*
> > +	 * The following devices sit behind a bridge, but don't need
> > +	 * transfer rate or size limits applied.
> > +	 */
> > +	{ "Mtron", },
> > +
> > +	/* End Marker */
> > +	{ }
> > +};
> 
> Any reason this can't be part of the existing blacklist?  It already
> supports wildcard matching and all.

Sure, just with an inverse flag, I'll do that.

-- 
Jens Axboe