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

[Tudor.Ambarus at microchip.com]

On 5/14/22 06:51, Takahiro Kuwano wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On 5/13/2022 6:40 PM, Michael Walle wrote:
>> [btw the subject still has the old name of the addr_width]
>>
> Yes, it must be fixed in next rev.
> 
>> 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
> I will send datasheets to you in another email. At this point, only
> summary datasheet is available in website.
> 
>> and a 4 byte mode, but after reset, they are in the 4 byte mode? Looks
> Yes.
> 
>> like it should be fixed in a different way. I'm not sure the "current
>> mode" handling is correct.
>>
> Yes, we may want to introduce a new flag like SPI_NOR_4BAM_DEFAULT and check
> the flag in BFPT parse. Once I send another series, please review.
> 

Sounds good on a first look. We can consider nor->addr_nbytes of value 3 as
default and change it to 4 when such a flag is set. But you don't need such
flag in this particular case, don't you? Also, can the default number of addr
bytes be retrieved from SFDP? Anyway, let this for later and respin the series,
please.

Cheers,
ta