linux-kernel - Re: [PATCH v4 2/6] spi: spi-fsl-dspi: Store status directly in cur

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: <e23bac2c-c39c-4446-9305-e7e51eabcb4b@linaro.org>
Date: Mon, 21 Jul 2025 15:02:09 +0100
From: James Clark <james.clark@...aro.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Vladimir Oltean <vladimir.oltean@....com>, Mark Brown
 <broonie@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Larisa Grigore <larisa.grigore@....com>, Frank Li <Frank.li@....com>,
 Christoph Hellwig <hch@....de>, linux-spi@...r.kernel.org,
 imx@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/6] spi: spi-fsl-dspi: Store status directly in
 cur_msg->status



On 21/07/2025 2:39 pm, Vladimir Oltean wrote:
> On Mon, Jul 21, 2025 at 02:25:55PM +0100, James Clark wrote:
>> Hi Vladimir,
>>
>> Just wanted to check if you are ok for me to send a new version with your
>> fixes included now?
> 
> Yes, sorry for not being clear, the tests which I wanted to run were
> these ones:
> https://lore.kernel.org/linux-spi/20250630152612.npdobwbcezl5nlym@skbuf/
> 

Got it, thanks.

>> I assume from the other discussion that we don't want to always enable DMA
>> mode either, and we'll just leave it for s32g target mode only?
> 
> Yeah, for sure don't enable DMA mode unconditionally. I don't have time
> right now to look into Mark's can_dma() suggestion - if you don't have
> either, I suppose it is what it is, and the performance improvements
> brought by your enhanced DMA patches can be brought over to other SoCs
> at some unspecified time in the future.

I think incremental is better yes, there wouldn't be much or any of this 
thrown away anyway.

I'm also not sure if it would fit with can_dma as that starts mapping 
stuff in the core layer. We want to avoid that because we need to write 
that control word for each SPI word. We could still change mode 
conditionally in the DSPI driver though, or make can_dma more flexible. 
But on top of this for sure.

James