Linux SPI subsystem development
 help / color / mirror / Atom feed
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

             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