From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: jgarzik@pobox.com
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
alan@lxorguk.ukuu.org.uk, rjw@sisk.pl
Subject: [PATCH] libata-sff: fix 32-bit PIO regression
Date: Sun, 8 Feb 2009 23:53:07 +0400 [thread overview]
Message-ID: <200902082253.07438.sshtylyov@ru.mvista.com> (raw)
Commit 871af1210f13966ab911ed2166e4ab2ce775b99d (libata: Add 32bit PIO support)
caused all kind of errors on the ATAPI devices, so it's been empirically proven
that one shouldn't read/write an extra data word when a device isn't expecting
it already. "Don't do it then"; however still taking a chance to use 32-bit I/O
one last time when there are exactly 3 trailing bytes. Oh, and stop pointless
swapping bytes to and fro as well by using io*_rep() which shouldn't byte-swap.
This should fix the kernel.org bug #12609.
---
This is hopefully better replacement for Hugh Dickins most recent patch
(http://marc.info/?l=linux-ide&m=123352294619281)...
drivers/ata/libata-sff.c | 23 ++++++++++++++++-------
1 files changed, 16 insertions(+), 7 deletions(-)
Index: linux-2.6/drivers/ata/libata-sff.c
===================================================================
--- linux-2.6.orig/drivers/ata/libata-sff.c
+++ linux-2.6/drivers/ata/libata-sff.c
@@ -773,18 +773,27 @@ unsigned int ata_sff_data_xfer32(struct
else
iowrite32_rep(data_addr, buf, words);
+ /* Transfer trailing bytes, if any */
if (unlikely(slop)) {
- __le32 pad;
+ unsigned char pad[4];
+
+ /* Point buf to the tail of buffer */
+ buf += buflen - slop;
if (rw == READ) {
- pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
- memcpy(buf + buflen - slop, &pad, slop);
+ if (slop < 3)
+ ioread16_rep(data_addr, pad, 1);
+ else
+ ioread32_rep(data_addr, pad, 1);
+ memcpy(buf, pad, slop);
} else {
- memcpy(&pad, buf + buflen - slop, slop);
- iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
+ memcpy(pad, buf, slop);
+ if (slop < 3)
+ iowrite16_rep(data_addr, pad, 1);
+ else
+ iowrite32_rep(data_addr, pad, 1);
}
- words++;
}
- return words << 2;
+ return (buflen + 1) & ~1;
}
EXPORT_SYMBOL_GPL(ata_sff_data_xfer32);
next reply other threads:[~2009-02-08 19:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-08 19:53 Sergei Shtylyov [this message]
2009-02-08 20:11 ` [PATCH] libata-sff: fix 32-bit PIO regression Alan Cox
2009-02-08 22:10 ` Sergei Shtylyov
2009-02-08 21:12 ` Hugh Dickins
2009-02-08 22:18 ` Sergei Shtylyov
2009-02-08 23:48 ` Mikael Pettersson
2009-02-09 0:03 ` Sergei Shtylyov
2009-02-09 0:19 ` Jeff Garzik
2009-02-09 10:43 ` Sergei Shtylyov
2009-02-09 10:56 ` Sergei Shtylyov
2009-02-09 0:07 ` Sergei Shtylyov
2009-02-09 10:22 ` Hugh Dickins
2009-02-09 16:42 ` Sergei Shtylyov
2009-02-09 16:48 ` Sergei Shtylyov
2009-02-09 18:14 ` Hugh Dickins
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=200902082253.07438.sshtylyov@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.