linux-kernel - [PATCH 0/3] spi: fix spi-mux/spi_optimize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240708-spi-mux-fix-v1-0-6c8845193128@baylibre.com>
Date: Mon,  8 Jul 2024 20:05:27 -0500
From: David Lechner <dlechner@...libre.com>
To: Mark Brown <broonie@...nel.org>,
	Oleksij Rempel <o.rempel@...gutronix.de>,
	Marc Kleine-Budde <mkl@...gutronix.de>
Cc: David Lechner <dlechner@...libre.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	linux-spi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] spi: fix spi-mux/spi_optimize_message() compatibility

Since the spi-mux controller driver is doing unusual things with SPI
messages, it needs special handling with regard to spi_optimize_message
and friends.

The main fix along with a detailed explanation is in the second patch.

The first patch is another unrelated general fix that I noticed while
working on this.

And the third patch is not exactly related, but I needed it for the
particular peripheral driver I was using for testing the main fix.

I tested this for both cases when spi_optimize_message() is called to
pre-optimize a message and when it is not.

---
David Lechner (3):
      spi: don't unoptimize message in spi_async()
      spi: add defer_optimize_message controller flag
      spi: mux: set ctlr->bits_per_word_mask

 drivers/spi/spi-mux.c   |  2 ++
 drivers/spi/spi.c       | 20 +++++++++++++++++---
 include/linux/spi/spi.h |  4 ++++
 3 files changed, 23 insertions(+), 3 deletions(-)
---
base-commit: f42920e81a8f5f9fdf4a46b233ae14c22996e52b
change-id: 20240708-spi-mux-fix-6e2da5b5673d

Best regards,
-- 
David Lechner <dlechner@...libre.com>