Tejun Heo wrote:
> For misc ATAPI commands which transfer variable length data to the
> host, overflow can occur due to application or hardware bug. Such
> overflows can be ignored safely as long as overflow data is properly
> drained. libata HSM implementation has this implemented in
> __atapi_pio_bytes() but it isn't enough. Improve drain logic such
> that...
>
> * Multiple PIO data phases are allowed. Not allowing this used to be
> okay when transfer chunk size was set to 8k unconditionally but with
> transfer hcunk size set to allocation size, treating extra PIO data
> phases as HSM violations cause a lot of trouble.
>
> * Limit the amount of draining to ATAPI_MAX_DRAIN (16k currently).
>
> * Don't whine if overflow is allowed and safe. When unexpected
> overflow occurs, trigger HSM violation and report the problem using
> ehi error description.
>
> * If the device indicates that it wants to transfer odd number of
> bytes, it should be rounded up not down.
>
If the trailing data is odd-lengthed, normally the situation is that
we have odd-lengthed real data before the trailing data. e.g. The real
data is 9 bytes, but the drive returns 10 bytes (so, the trailing data
is 1 byte).
In ata_data_xfer(), we have the following code:
/* Transfer trailing 1 byte, if any. */
... (for write case) ...
iowrite16(le16_to_cpu(align_buf[0]), ap->ioaddr.data_addr); or
... (for read case) ...
ioread16(ap->ioaddr.data_addr)
The PATA bus is actually 16-bit wide. So, ata_data_xfer() actually
implicitly transfers one more byte than we see if it's odd-lengthed.
That's why in atapi_pio_bytes(), the trailing length was round down
instead round up.
--
albert
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
