Re: [PATCH 05/13] libata: improve ATAPI draining

[Albert Lee <albertcc@tw.ibm.com>]

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