From: sashiko-bot@kernel.org
To: "Paul Cercueil" <paul.cercueil@bootlin.com>,
"Pratyush Yadav" <pratyush@kernel.org>,
"Michael Walle" <mwalle@kernel.org>,
"Takahiro Kuwano" <takahiro.kuwano@infineon.com>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Mark Brown" <broonie@kernel.org>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Cc: "Kees Cook" <kees@kernel.org>, "Tony Luck" <tony.luck@intel.com>,
"Guilherme G . Piccoli" <gpiccoli@igalia.com>,
linux-mtd@lists.infradead.org,
"Bharat Bhushan" <bbhushan2@marvell.com>,
"Sunil Kovvuri Goutham" <sgoutham@marvell.com>,
"Tanmay Jagdale" <tanmay@marvell.com>
Subject: Re: [PATCH v3 4/7] spi: cadence-xspi: Clear "SDMA ready" IRQ flag after polling
Date: Wed, 14 Oct 2026 16:01:15 +0000 [thread overview]
Message-ID: <sashiko-outbox-171511@kernel.org> (raw)
In-Reply-To: <20261014154301.157755-5-paul.cercueil@bootlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] spi: cadence-xspi: Endianness data corruption in SDMA FIFO accessors
--
commit 1ca06d1541637f6b734fe45112366c1987d59785
Author: Tanmay Jagdale <tanmay@marvell.com>
spi: cadence-xspi: Clear "SDMA ready" IRQ flag after polling
When polling for the "SDMA ready" event, once the corresponding bit is
set in the CDNS_XSPI_SDMA_TRIGGER we should reset it to zero. Otherwise,
any subsequent call to cdns_xspi_is_sdma_ready() will just return early.
Fixes: 931e389ded0f ("spi: cadence: Add Marvell xfer operation support")
Cc: stable@vger.kernel.org
> diff --git a/drivers/spi/spi-cadence-xspi.c b/drivers/spi/spi-cadence-xspi.c
> index 39c868a5b171c..095bf640b379a 100644
> --- a/drivers/spi/spi-cadence-xspi.c
> +++ b/drivers/spi/spi-cadence-xspi.c
> @@ -1068,12 +1068,20 @@ static bool cdns_xspi_is_sdma_ready(struct cdns_xspi_dev *cdns_xspi, bool sleep)
> {
> u32 ctrl_stat;
>
> - return !readl_relaxed_poll_timeout
> - (cdns_xspi->iobase + CDNS_XSPI_INTR_STATUS_REG,
> - ctrl_stat,
> - (ctrl_stat & CDNS_XSPI_SDMA_TRIGGER),
> - sleep ? MRVL_XSPI_POLL_DELAY_US : 0,
> - sleep ? MRVL_XSPI_POLL_TIMEOUT_US : 0);
> + if (readl_relaxed_poll_timeout
> + (cdns_xspi->iobase + CDNS_XSPI_INTR_STATUS_REG,
> + ctrl_stat,
> + (ctrl_stat & CDNS_XSPI_SDMA_TRIGGER),
> + sleep ? MRVL_XSPI_POLL_DELAY_US : 0,
> + sleep ? MRVL_XSPI_POLL_TIMEOUT_US : 0)) {
> + return false;
> + }
> +
> + /* Clear the flag */
> + writel(CDNS_XSPI_SDMA_TRIGGER,
> + cdns_xspi->iobase + CDNS_XSPI_INTR_STATUS_REG);
> +
> + return true;
> }
[Severity: High]
Does this code corrupt data on big-endian architectures?
In m_ioreadq(), register accessors are used instead of stream accessors to
read bulk stream data from the SDMA FIFO:
drivers/spi/spi-cadence-xspi.c:m_ioreadq() {
...
do {
u64 b = readq(addr);
*buffer++ = b;
} while (--full_ops);
...
}
Because addr is not incremented, this reads from a FIFO. Register accessors
like readq() perform byte-swapping, which reverses the byte stream within
each 8-byte chunk on big-endian systems.
Similarly, for partial transfers in m_ioreadq():
drivers/spi/spi-cadence-xspi.c:m_ioreadq() {
...
while (len) {
u64 tmp_buf;
tmp_buf = readq(addr);
memcpy(buf, &tmp_buf, min(len, 8));
...
}
Combining a byte-swapping readq() with memcpy() extracts incorrect bytes on
big-endian systems because the reversed 64-bit word places the wrong stream
bytes in the lowest memory addresses.
The same behavior appears in m_iowriteq() when writing to the SDMA FIFO:
drivers/spi/spi-cadence-xspi.c:m_iowriteq() {
...
do {
writeq(*buffer++, addr);
} while (--full_ops);
...
}
Should these be converted to stream accessors to preserve byte order on
big-endian systems?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014154301.157755-1-paul.cercueil@bootlin.com?part=4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-10-14 16:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 15:42 [PATCH v3 0/7] spi: Add support for panic mem writes Paul Cercueil
2026-10-14 15:42 ` [PATCH v3 1/7] spi: spi-mem: " Paul Cercueil
2026-10-14 15:42 ` [PATCH v3 2/7] mtd: spi-nor: Wait for NOR ready with poll_timeout_us() Paul Cercueil
2026-10-14 15:42 ` [PATCH v3 3/7] mtd: spi-nor: Add support for panic writes Paul Cercueil
2026-10-14 15:57 ` sashiko-bot
2026-10-14 15:42 ` [PATCH v3 4/7] spi: cadence-xspi: Clear "SDMA ready" IRQ flag after polling Paul Cercueil
2026-10-14 16:01 ` sashiko-bot [this message]
2026-10-14 15:42 ` [PATCH v3 5/7] spi: cadence-xspi: Add irq-less support Paul Cercueil
2026-10-14 16:00 ` sashiko-bot
2026-10-14 15:43 ` [PATCH v3 6/7] spi: cadence-xspi: Add support for panic writes Paul Cercueil
2026-10-14 16:03 ` sashiko-bot
2026-10-14 15:43 ` [PATCH v3 7/7] spi: dt-bindings: cadence: Make XSPI's IRQ line optional Paul Cercueil
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=sashiko-outbox-171511@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bbhushan2@marvell.com \
--cc=broonie@kernel.org \
--cc=gpiccoli@igalia.com \
--cc=kees@kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=paul.cercueil@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sgoutham@marvell.com \
--cc=takahiro.kuwano@infineon.com \
--cc=tanmay@marvell.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=tony.luck@intel.com \
--cc=vigneshr@ti.com \
/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