[PATCH] mtd: spi-nor: spansion: Add SMPT fixup for S25FS512S

Marek Vasut marek.vasut at mailbox.org
Mon Oct 27 15:22:11 PDT 2025


On 10/20/25 1:35 PM, Tudor Ambarus wrote:

Hello Tudor,

I apologize for my slow response.

>>>>> The "Index Value" shall be the map_id that you passed in the code:
>>>>> spi_nor_post_smpt_fixups(nor, &map_id);
>>>>>
>>>>> Can you please print the map_id value that you obtain without updating it?
>>>>
>>>> 0x4
>>>
>>> This translates to CR3NV[3] = 1, CR1NV[2] = 0,  CR3NV[1] = 0.
>>>>
>>>>> Let's also print the values of CR3NV and CR1NV.
>>>>
>>>> Both 0x0 and 0x0 .
>>>
>>> But here CR3NV is 0, it contradicts the result from above.
>>
>> Maybe I messed up and was reading it the wrong way ?

I really wonder if I might be reading the CR3NV the wrong way ?

>>> Maybe it's the same problem that Takahiro identified: the flash needs
>>> 8 dummy cycles, but the code uses zero dummy cycles, resulting in
>>> reading garbage data, depending on whether your IO lines are pulled up/down
>>> or floating.
>>>
>>> Can you redo the test with the following please?
>>
>> Sure, although I saw some further discussion between you and Kuwano-san , is this still applicable ?
> 
> It's still applicable, it will confirm what Kuwano-san discovered:
> the flash needs 8 dummy cycles for using that read reg command.
> 
> We'll also need a hook to amend the CR3NV[1] value (which is reserved,
> zero on some flavors of flash) and replace it with 1, similar to what
> you did in this patch.
> 
> You can either test or let Kuwano-san come up with a patch addressing
> both issues and test his patch afterwards, sync up with him please.
> 
>>
>>> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
>>> index 21727f9a4ac6..85443c903e59 100644
>>> --- a/drivers/mtd/spi-nor/sfdp.c
>>> +++ b/drivers/mtd/spi-nor/sfdp.c
>>> @@ -752,7 +752,7 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
>>>                     read_data_mask = SMPT_CMD_READ_DATA(smpt[i]);
>>>                   nor->addr_nbytes = spi_nor_smpt_addr_nbytes(nor, smpt[i]);
>>> -               nor->read_dummy = spi_nor_smpt_read_dummy(nor, smpt[i]);
>>> +               nor->read_dummy = 8;
>>>                   nor->read_opcode = SMPT_CMD_OPCODE(smpt[i]);
>>>                   addr = smpt[i + 1];
>>>    @@ -767,6 +767,8 @@ static const u32 *spi_nor_get_map_in_use(struct spi_nor *nor, const u32 *smpt,
>>>                    * Configuration that is currently in use.
>>>                    */
>>>                   map_id = map_id << 1 | !!(*buf & read_data_mask);
>>> +               dev_err(nor->dev, "i = %d, buf = %02x, map_id = %02x\n",
>>> +                       i, buf[0], map_id);
>>>           }
>> Sorry for the late reply.
> yeah, no worries, it's still fresh.

With current mainline, without the aforementioned patch, with my 
CR1NV/CR3NV printing (maybe broken):

CR1NV=00
CR3NV=00
map_id=00000004

With the read_dummy=8 addition above and the dev_err, I get:

spi-nor spi0.0: i = 0, buf = 00, map_id = 00
spi-nor spi0.0: i = 2, buf = 02, map_id = 00
spi-nor spi0.0: i = 4, buf = 00, map_id = 00
map_id=00000000

The reported failure persists:

spi-nor spi0.0: Failed to parse optional parameter table: ff81

Let me test the patchset from Kuwano-san next .

Thank you for your help!

-- 
Best regards,
Marek Vasut



More information about the linux-mtd mailing list