From: Mehmet Fide <mehmet.fide@gmail.com>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>,
Larisa Grigore <larisa.grigore@nxp.com>,
James Clark <james.clark@linaro.org>,
Mark Brown <broonie@kernel.org>,
Vladimir Oltean <olteanv@gmail.com>,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 6.12.y] spi: spi-fsl-dspi: Avoid setup_accel logic for DMA transfers
Date: Mon, 10 Aug 2026 16:14:37 +0200 [thread overview]
Message-ID: <20260810141437.2805389-1-mehmet.fide@gmail.com> (raw)
Please consider commit cac7e5054115 ("spi: spi-fsl-dspi: Avoid setup_accel
logic for DMA transfers") for 6.12.y. It is in mainline since v6.17 and
applies cleanly to 6.12.y.
It went in as a cleanup, so it carries neither a Fixes: tag nor a stable
tag, but on vf610 the logic it removes corrupts data in DMA mode, in two
ways:
1. For an odd number of bytes the accel logic packs into 16 bit frames and
computes the word count as len / 2, so a 5 byte transfer puts 4 bytes in
the first DMA transfer and leaves the last byte to a second one with
different timing.
2. With SPI_LSB_FIRST the accel helpers byte swap through cpu_to_be16(),
which combines with the hardware LSBFE bit and puts multi byte transfers
on the wire in the wrong byte order.
Both are visible on a Colibri VF50 (vf610, DSPI in DMA mode), and both go
away with this commit, which is what we have been carrying locally against
6.12 to get correct transfers. Every stable tree older than 6.17 is
affected in the same way.
Thanks,
Mehmet
next reply other threads:[~2026-08-10 14:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 14:14 Mehmet Fide [this message]
2026-08-11 8:40 ` [PATCH 6.12.y] spi: spi-fsl-dspi: Avoid setup_accel logic for DMA transfers Mehmet Fide
2026-08-11 9:09 ` James Clark
2026-08-11 9:13 ` Mehmet Fide
2026-08-11 18:55 ` Sasha Levin
2026-08-11 21:28 ` Vladimir Oltean
2026-08-12 8:20 ` James Clark
2026-08-12 16:26 ` Sasha Levin
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=20260810141437.2805389-1-mehmet.fide@gmail.com \
--to=mehmet.fide@gmail.com \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=james.clark@linaro.org \
--cc=larisa.grigore@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=sashal@kernel.org \
--cc=stable@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