[PATCH] mtd: spi-nor: spansion: Fixup params->set_4byte_addr_mode for SEMPER

[Takahiro Kuwano]

On 6/12/2025 4:04 PM, Tudor Ambarus wrote:
> 
> 
> On 6/12/25 8:01 AM, Takahiro Kuwano wrote:
>> On 6/10/2025 12:19 AM, Tudor Ambarus wrote:
>>> Hi, Takahiro,
>>>
>>> On 6/5/25 9:55 AM, tkuw584924 at gmail.com wrote:
>>>> From: Takahiro Kuwano <Takahiro.Kuwano at infineon.com>
>>>>
>>>> Infineon SEMPER flash family does not support E9h opcode as Exit 4-byte
>>>> mode (EX4B). Therefore, params->set_4byte_addr_mode is not determined by
>>>> BFPT parse. Fixup it up by introducing vendor specific EX4B opcode (B8h)
>>>> and function.
>>>>
>>>> Fixes: c87c9b11c53ce ("mtd: spi-nor: spansion: Determine current address mode")
>>>> Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano at infineon.com>
>>>> ---
>>>>  drivers/mtd/spi-nor/spansion.c | 29 +++++++++++++++++++++++++++++
>>>>  1 file changed, 29 insertions(+)
>>>>
>>>> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
>>>> index bf08dbf5e742..9162b9297ce8 100644
>>>> --- a/drivers/mtd/spi-nor/spansion.c
>>>> +++ b/drivers/mtd/spi-nor/spansion.c
>>>> @@ -17,6 +17,7 @@
>>>>  
>>>>  #define SPINOR_OP_CLSR		0x30	/* Clear status register 1 */
>>>>  #define SPINOR_OP_CLPEF		0x82	/* Clear program/erase failure flags */
>>>> +#define SPINOR_OP_CYPRESS_EX4B	0xB8	/* Exit 4-byte address mode */
>>>>  #define SPINOR_OP_CYPRESS_DIE_ERASE		0x61	/* Chip (die) erase */
>>>>  #define SPINOR_OP_RD_ANY_REG			0x65	/* Read any register */
>>>>  #define SPINOR_OP_WR_ANY_REG			0x71	/* Write any register */
>>>> @@ -58,6 +59,13 @@
>>>>  		   SPI_MEM_OP_DUMMY(ndummy, 0),				\
>>>>  		   SPI_MEM_OP_DATA_IN(1, buf, 0))
>>>>  
>>>> +#define CYPRESS_NOR_EN4B_EX4B_OP(enable)				\
>>>> +	SPI_MEM_OP(SPI_MEM_OP_CMD(enable ? SPINOR_OP_EN4B :		\
>>>> +					   SPINOR_OP_CYPRESS_EX4B, 0),	\
>>>
>>> I wonder if it would make sense to have per vendor opcodes. Updating the
>>> set_4byte_addr_mode() method wouldn't be needed in this case, you would
>>> just need to use some nor->vendor->ops->ex4b opcode, right?
>>>
>> Do you mean introducing new vendor opcodes structure into nor or
>> nor->params?
> 
> something like that. Maybe not right now, but something to have in mind
> if we keep seeing vendor specific opcodes that are different than the
> usual (BFPT-described?) ones.
> 
Understood, thanks!