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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aRiLQn4F9U4WrWaF@debian-BULLSEYE-live-builder-AMD64>
Date: Sat, 15 Nov 2025 11:16:34 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: David Lechner <dlechner@...libre.com>
Cc: Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Marcelo Schmitt <marcelo.schmitt@...log.com>,
	Michael Hennerich <michael.hennerich@...log.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Jonathan Cameron <jic23@...nel.org>,
	Andy Shevchenko <andy@...nel.org>,
	Sean Anderson <sean.anderson@...ux.dev>, linux-spi@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org
Subject: Re: [PATCH v2 4/6] spi: axi-spi-engine: support
 SPI_MULTI_BUS_MODE_STRIPE

On 11/12, David Lechner wrote:
> On 11/11/25 9:12 AM, Marcelo Schmitt wrote:
> > Hi David,
> > 
> > The updates to spi-engine driver look good.
> > Only one comment about what happens if we have conflicting bus modes for the
> > offload case. Just to check I'm getting how this is working.
> > 
> 
> ...
> 
> >> @@ -284,6 +316,24 @@ static int spi_engine_precompile_message(struct spi_message *msg)
> >>  			min_bits_per_word = min(min_bits_per_word, xfer->bits_per_word);
> >>  			max_bits_per_word = max(max_bits_per_word, xfer->bits_per_word);
> >>  		}
> >> +
> >> +		if (xfer->rx_buf || xfer->offload_flags & SPI_OFFLOAD_XFER_RX_STREAM ||
> >> +		    xfer->tx_buf || xfer->offload_flags & SPI_OFFLOAD_XFER_TX_STREAM) {
> >> +			switch (xfer->multi_bus_mode) {
> >> +			case SPI_MULTI_BUS_MODE_SINGLE:
> >> +			case SPI_MULTI_BUS_MODE_STRIPE:
> >> +				break;
> >> +			default:
> >> +				/* Other modes, like mirror not supported */
> >> +				return -EINVAL;
> >> +			}
> >> +
> >> +			/* If all xfers have the same multi-bus mode, we can optimize. */
> >> +			if (multi_bus_mode == SPI_ENGINE_MULTI_BUS_MODE_UNKNOWN)
> >> +				multi_bus_mode = xfer->multi_bus_mode;
> >> +			else if (multi_bus_mode != xfer->multi_bus_mode)
> >> +				multi_bus_mode = SPI_ENGINE_MULTI_BUS_MODE_CONFLICTING;
> > 
> > Here we check all xfers have the same multi-bus mode and keep the mode that has
> > been set. Otherwise, we set this conflicting mode and the intent is to generate
> > SDI and SDO mask commands on demand on spi_engine_precompile_message(). OTOH,
> 
> s/spi_engine_precompile_message/spi_engine_compile_message/
> 
> Probably just a typo, but just to be clear, the "on demand" bit happens in the
> compile function rather than precompile.

Yes, I wanted to say spi_engine_compile_message() but miss pasted the other when
replying.

> 
> > if all xfers have the same multi-bus mode, we can add just one pair of SDI/SDO
> > mask commands in spi_engine_trigger_enable() and one pair latter in
> > spi_engine_trigger_disable(). I guess this is the optimization mentioned in the
> > comment.
> > 
> Your understanding is correct.

Awesome. Thanks for clarifying that out.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ