[PATCH v15 6/8] mtd: spi-nor: Retain nor->addr_width at 4BAIT parse

[Michael Walle]

[btw the subject still has the old name of the addr_width]

Am 2022-05-13 03:26, schrieb Takahiro Kuwano:
> On 5/13/2022 7:14 AM, Michael Walle wrote:
>> Am 2022-05-10 00:10, schrieb tkuw584924 at gmail.com:
>>> From: Takahiro Kuwano <Takahiro.Kuwano at infineon.com>
>>> 
>>> In 4BAIT parse, keep nor->params->addr_width because it may be used 
>>> as
>>> current address mode in SMPT parse later on.
>> 
>> Mh I'm not sure this is needed at all.
>> 
>> SFDP spec says
>>   Variable address length (the current setting of the address
>>   length mode defines the address length)
>> 
>> and
>>   When the length is defined as variable, the software or hardware
>>   controlling the memory is aware of the address length mode last
>>   set in the memory device and this same length of address.
>> 
>> We don't set any address mode until all the SFDP parsing is
>> over. Therefore we should always be in 3 byte mode, no?
>> 
> Actually there are some devices that have variable address length but
> 4 byte mode by default (I will work on those devices after this series
> is settled). To support such case, I prefer to use params->addr_nbytes
> as current address mode so that I can fix it in post_bfpt_fixup() hook.

Are there public datasheets available? So these devices have a 3 byte
and a 4 byte mode, but after reset, they are in the 4 byte mode? Looks
like it should be fixed in a different way. I'm not sure the "current
mode" handling is correct.

We need to differentiate between the mode the flash currently is using
(nor->addr_nbytes) and the mode parsed by SFDP (params->addr_nbytes).

At some point, the mode is switched and nor->addr_nbytes becomes
params->addr_nbytes. It seems in your case nor->addr_nbytes should
be 4 right from the beginning. Which also means nor->addr_nbytes
should be 3 for the other cases (and probably not 0).

-michael