linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: albertl@mail.com
Cc: jeff@garzik.org, linux-ide@vger.kernel.org,
	alan@lxorguk.ukuu.org.uk, liml@rtr.ca, jens.axboe@oracle.com
Subject: Re: [PATCH 05/13] libata: improve ATAPI draining
Date: Thu, 29 Nov 2007 16:26:11 +0900	[thread overview]
Message-ID: <474E6993.3070008@gmail.com> (raw)
In-Reply-To: <474E5C22.7010405@tw.ibm.com>

Albert Lee wrote:
> 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.

Hmmm... it's tricky.  When draining a partial chunk because of
odd-length short buffer on even-length chunk, it needs to be rounded
down but on all other cases it needs to be rounded up, right?

This is basically because count isn't updated with actually consumed
number of bytes.  I'll fix it and post an updated patch.

Thanks.

-- 
tejun

  reply	other threads:[~2007-11-29  7:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-27 15:13 [PATCHSET] libata: improve ATAPI data transfer handling Tejun Heo
2007-11-27 15:13 ` [PATCH 01/13] libata: update atapi_eh_request_sense() such that lbam/lbah contains buffer size Tejun Heo
2007-11-27 15:13 ` [PATCH 02/13] cdrom: add more GPCMD_* constants Tejun Heo
2007-11-27 15:13 ` [PATCH 03/13] libata: rename ATA_PROT_ATAPI_* to ATAPI_PROT_* Tejun Heo
2007-11-27 15:13 ` [PATCH 04/13] libata: add ATAPI_* cmd types and implement atapi_cmd_type() Tejun Heo
2007-11-27 15:13 ` [PATCH 05/13] libata: improve ATAPI draining Tejun Heo
2007-11-29  6:28   ` Albert Lee
2007-11-29  7:26     ` Tejun Heo [this message]
2007-11-29 14:34       ` Tejun Heo
2007-11-27 15:13 ` [PATCH 06/13] libata: make atapi_request_sense() use sg Tejun Heo
2007-11-27 15:13 ` [PATCH 07/13] libata: kill non-sg DMA interface Tejun Heo
2007-11-27 15:13 ` [PATCH 08/13] libata: change ATA_QCFLAG_DMAMAP semantics Tejun Heo
2007-11-27 15:13 ` [PATCH 09/13] libata: convert to chained sg Tejun Heo
2007-11-27 15:13 ` [PATCH 10/13] libata: add qc->dma_nbytes Tejun Heo
2007-11-27 17:20   ` Alan Cox
2007-11-27 15:13 ` [PATCH 11/13] libata: implement ATAPI drain buffer Tejun Heo
2007-11-27 15:13 ` [PATCH 12/13] libata: implement ATAPI per-command-type DMA horkages Tejun Heo
2007-11-27 15:13 ` [PATCH 13/13] libata: use PIO for misc ATAPI commands Tejun Heo
2007-11-27 16:56   ` Alan Cox
2007-11-27 23:01     ` Tejun Heo
2007-11-27 23:31       ` Mark Lord
2007-11-27 23:34         ` Mark Lord
2007-11-27 23:37         ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=474E6993.3070008@gmail.com \
    --to=htejun@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=albertl@mail.com \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).