Re: [PATCH] libata-core More robust parsing for multi_count(v5)

[Mark Lord <liml@rtr.ca>]

Mark Lord wrote:
> Tejun,
> 
> I need a way to limit the multi_count to a specific maximum
> value for sata_mv.  ISTR that some PATA chips may also have
> an upper hardware limit on multi_count.
> 
> Generally, "8" is safe for all chipsets.  Going above that
> requires knowledge of what the chipset can tolerate.
> 
> How about a u8 multi_count_max field in the ata_host struct?
> Use 0xff for "multi_count not allowed", and anything else
> in there as an upper limit for the chipset.
..
Alan Cox wrote:
>
> If its only one driver why not do it the way we do things like transfer
> length limits for LBA48 (see pata_it821x and others)
..

Okay, I've looked at pata_it821x.c now, and I just don't see it.
That particular driver seems to limit *all* transfers to 256 max,
not just those of a particular protocol, like mult-sect I/O.

Am I missing something there?

The limit for sata_mv chipsets seems to actually be 7-sectors or less
for read/write multiple.  Which means a max of 4 in practice.

Similarly, we should also be preventing *any* PIO of more than one DRQ
for sata_mv.  But I don't see a sensible way to do that either.

In practice, that part does seem to work fine with the PIO polling
that sata_mv uses.

But what to do about the read/write multiple issue ?

???