linux-kernel - Re: [PATCH 02/28] spi: spi-mem: Create a repeated address operation

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] [day] [month] [year] [list]

Message-ID: <a9161234-de04-4090-afb4-7b619cae3c35@linaro.org>
Date: Thu, 20 Nov 2025 10:49:36 +0200
From: Tudor Ambarus <tudor.ambarus@...aro.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: Mark Brown <broonie@...nel.org>, Richard Weinberger <richard@....at>,
 Vignesh Raghavendra <vigneshr@...com>, Pratyush Yadav <pratyush@...nel.org>,
 Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
 Steam Lin <STLin2@...bond.com>, Santhosh Kumar K <s-k6@...com>,
 linux-spi@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 02/28] spi: spi-mem: Create a repeated address operation



On 11/19/25 7:10 PM, Miquel Raynal wrote:
> Hi Tudor,
> 

Hi, Miquel!

> First, thank you very much for all this precious feedback! I am happy to
> get feedback not only on the spi-mem side, but also on the NAND changes!

yeah, I had a spare window and reviewed as much as I could. The set won't go
in this cycle anyway, I plan to review the rest as well. But not just now :)

> 
> On 05/11/2025 at 16:43:58 +01, Tudor Ambarus <tudor.ambarus@...aro.org> wrote:
> 
>> On 10/31/25 6:26 PM, Miquel Raynal wrote:
>>> In octal DTR mode, while the command opcode is *always* repeated,
>>
>> this info is wrong: opcode can be repeated, inverted or a dedicated 16bit,
>> so please fix this to not mislead readers
> 
> I didn't know :) But yeah I had SPI NAND mind which was obviously
> wrong. I'll correct.
> 
>>> addresses may either be long enough to cover at least two bytes (in
>>> which case the existing macro works), or otherwise for single byte
>>> addresses, the byte must also be duplicated and sent twice: on each
>>> front of the clock. Create a macro for this common case.
>>>
>>> Signed-off-by: Miquel Raynal <miquel.raynal@...tlin.com>
>>> ---
>>>  include/linux/spi/spi-mem.h | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
>>> index 81c9c7e793b6ab894675e0198d412d84b8525c2e..e4db0924898ce5b17d2b6d4269495bb968db2871 100644
>>> --- a/include/linux/spi/spi-mem.h
>>> +++ b/include/linux/spi/spi-mem.h
>>> @@ -43,6 +43,14 @@
>>>  		.dtr = true,					\
>>>  	}
>>>  
>>> +#define SPI_MEM_DTR_OP_RPT_ADDR(__val, __buswidth)		\
>>
>> I find the name too generic. This is an macro for 1 byte addresses,
>> right?
> 
> Yes it is. The name mimics the "dtr command repeat" macro name. Maybe
> you want to include the info that it is  carrying a single byte? maybe
> "*RPT_SINGLE_BYTE_ADDR"? but that's a big too long IMO. Any other idea?
Let's keep it as you proposed, I see how they are used in patch 27/28 and
it looks alright.

Cheers,
ta