linux-kernel - Re: [PATCH] spi: stm32: use runtime PM to enable/disable controller

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: <20231215182739.GA96945@gnbcxd0016.gnb.st.com>
Date: Fri, 15 Dec 2023 19:27:39 +0100
From: Alain Volmat <alain.volmat@...s.st.com>
To: Mark Brown <broonie@...nel.org>
CC: Ben Wolsieffer <ben.wolsieffer@...ring.com>, <linux-spi@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue
	<alexandre.torgue@...s.st.com>
Subject: Re: [PATCH] spi: stm32: use runtime PM to enable/disable controller

Hi,

sorry for the delay.

On Thu, Dec 14, 2023 at 10:58:54AM +0000, Mark Brown wrote:
> On Mon, Dec 04, 2023 at 03:20:55PM -0500, Ben Wolsieffer wrote:
> > Instead of disabling the SPI controller between each message, do it
> > as part of runtime PM.
> 
> This doesn't apply against current code, please check and resend.

I rapidly gave a try on this patch on top of the spi/for-next branch
(manually fixing the conflict due to the MASTER->HOST renaming).
It turns out that with that applied, transfers on the MP13
(compatible: st,stm32h7-spi) are not working anymore while simply
removing it back it works again.
(test is simply doing loopback spidev_test)

spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 kHz)
TX | 8D D6 73 8B 9D 8B 1C 7D 8D 80 EC 32 F9 0D BA AD 9F 88 A5 9B 3F AA 48 8C 21 35 0D C1 C8 E5 6A 81  |..s....}...2........?.H.!5....j.|
RX | 8D 00 00 00 D6 00 73 00 8B 00 00 00 9D 00 00 8B 1C 00 00 00 7D 00 00 8D F9 00 00 00 BA 00 00 00  |......s.............}...........|

The RX data contains lots of 00 between each byte.  Moreover it seems
that with this patch applied non-dma transfer (when there is no dmas
properties within the node) are now failing.

I'll check that and give more details but could you avoid applying this
patch for the time being ?

Thanks.
Alain