linux-kernel - Re: [PATCH 09/14] iio: pressure: mprls0025pa: mitigate SPI CS delay violation

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: <aUYrXpyaM6YdMfUd@debian-BULLSEYE-live-builder-AMD64>
Date: Sat, 20 Dec 2025 01:51:42 -0300
From: Marcelo Schmitt <marcelo.schmitt1@...il.com>
To: Petre Rodan <petre.rodan@...dimension.ro>
Cc: Jonathan Cameron <jic23@...nel.org>,
	David Lechner <dlechner@...libre.com>,
	Nuno Sá <nuno.sa@...log.com>,
	Andy Shevchenko <andy@...nel.org>,
	Andreas Klinger <ak@...klinger.de>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH 09/14] iio: pressure: mprls0025pa: mitigate SPI CS delay
 violation

On 12/18, Petre Rodan wrote:
> Based on the sensor datasheet in chapter 7.6 SPI timing, Table 20,
> during the SPI transfer there is a minimum time interval between the
> CS being asserted and the first clock edge (tHDSS).
> This minimum interval of 2.5us is being violated if two consecutive SPI
> transfers are queued up, at least on my SPI controller (omap2_mcspi) [1]
> As you can see in the first package that only contains a NOP the interval
> is 0.75us (half a 800kHz clock cycle).
> 
> This patch mitigates the problem by implementing a different measurement
> technique that does not involve checking for the EOC indicator before
> reading the conversion, thus making sure SPI transfers are not queued up.
The correct way of fixing that is with protocol specific delay. Generic delays
like fsleep won't guarantee any delay between CS drop and fist SCLK edge. 
For SPI, we unfortunately we don't have any interface to set a pre-SCLK delay
so I suggest to make an spi_message with a dummy transfer to cause the initial
2.5 µs delay. E.g.

/* dummy transfer with no data, just cause the delay */
xfers[0].delay.value = 2500 * NSEC_PER_SEC;
xfers[0].delay.unit = SPI_DELAY_UNIT_NSECS;

/* normal data transfer  */
xfer[1].tx_buf = data->tx_buf;
xfer[1].rx_buf = data->rx_buf;
...

Also, I don't see how the proposed change is 'implementing a different
measurement technique'. Consider updating the commit description or providing
better explanation.

> see Option 2 in Table 19 SPI output measurement command.
> Note that Honeywell's example code also follows this technique for both i2c
> and SPI.
> 
> This change only affects users that do not define the EOC interrupt in the
> device tree.
> 
> Remove defines that are no longer used.
> 
> [1] https://pasteboard.co/66WN38MRI1wc.png
> 
> Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/micropressure-mpr-series/documents/sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf?download=false
> Signed-off-by: Petre Rodan <petre.rodan@...dimension.ro>