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
--
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
