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

Tudor Ambarus tudor.ambarus at linaro.org
Thu Nov 20 00:49:36 PST 2025



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 at linaro.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 at bootlin.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



More information about the linux-mtd mailing list