From: Rosen Penev <rosenp@gmail.com>
To: linux-ide@vger.kernel.org
Cc: Damien Le Moal <dlemoal@kernel.org>,
Niklas Cassel <cassel@kernel.org>,
linux-kernel@vger.kernel.org (open list)
Subject: [PATCH] ata: pata_ep93xx: fix endianness bug in trailing byte transfer
Date: Mon, 1 Jun 2026 12:09:21 -0700 [thread overview]
Message-ID: <20260601190921.20167-1-rosenp@gmail.com> (raw)
ep93xx_pata_data_xfer() handles a trailing odd byte by reading/writing
a full 16-bit word and extracting the first byte. The current code
uses cpu_to_le16()/le16_to_cpu() wrapping, but then assigns through a
u8 pointer (*pad), truncating the value.
On the READ path, *pad = cpu_to_le16(...) truncates the u16 to u8.
On little-endian this happens to give the right byte, but on big-endian
cpu_to_le16() puts the valid byte in the upper 8 bits and truncation
keeps the lower 8 bits (zeros), losing the data.
On the WRITE path, le16_to_cpu(*pad) zero-extends pad[0] (u8) to u16
(0x00BB) and then on big-endian byte-swaps to 0xBB00. The hardware then
receives 0x00 as the first byte instead of 0xBB.
The readl()/writel() calls inside ep93xx_pata_read_data() and
ep93xx_pata_write_data() already handle endianness correctly, so the
trailing byte can just use the raw read/write value directly without
the cpu_to_le16/le16_to_cpu wrappers. Remove the pad[] array and
simplify.
Assisted-by: Opencode:Big-Pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
drivers/ata/pata_ep93xx.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/ata/pata_ep93xx.c b/drivers/ata/pata_ep93xx.c
index 3f61712af5bb..a0dfdacf54e5 100644
--- a/drivers/ata/pata_ep93xx.c
+++ b/drivers/ata/pata_ep93xx.c
@@ -495,19 +495,12 @@ static unsigned int ep93xx_pata_data_xfer(struct ata_queued_cmd *qc,
/* Transfer trailing 1 byte, if any. */
if (unlikely(buflen & 0x01)) {
- unsigned char pad[2] = { };
-
buf += buflen - 1;
if (rw == READ) {
- *pad = cpu_to_le16(
- ep93xx_pata_read_data(
- drv_data, IDECTRL_ADDR_DATA));
- *buf = pad[0];
+ *buf = ep93xx_pata_read_data(drv_data, IDECTRL_ADDR_DATA);
} else {
- pad[0] = *buf;
- ep93xx_pata_write_data(drv_data, le16_to_cpu(*pad),
- IDECTRL_ADDR_DATA);
+ ep93xx_pata_write_data(drv_data, *buf, IDECTRL_ADDR_DATA);
}
words++;
}
--
2.54.0
next reply other threads:[~2026-06-01 19:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 19:09 Rosen Penev [this message]
2026-06-01 19:16 ` [PATCH] ata: pata_ep93xx: fix endianness bug in trailing byte transfer sashiko-bot
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=20260601190921.20167-1-rosenp@gmail.com \
--to=rosenp@gmail.com \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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