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

Takahiro Kuwano tkuw584924 at gmail.com
Fri May 13 20:51:46 PDT 2022


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.

> We need to differentiate between the mode the flash currently is using
> (nor->addr_nbytes) and the mode parsed by SFDP (params->addr_nbytes).
> 
The flash's address mode affects the address length of Non-4B opcodes,
including read/write any register ops used in SMPT parse and Infineon
(spansion) specific hooks.

The 4B opcodes always take address length of 4 regardless of flash's
address mode. In these Infineon chips, 4B opcodes for read/program/
erase are available and 4BAIT advertises them. We don't have to enter
4 byte address mode for read/program/erase.

So, I think we need to differentiate between address length for
read/program/erase and flash's default address mode.

Obviously we are using nor->addr_nbytes as address length for read/
program/erase and should keep this usage.

For flash's default address mode, my preference is to use
params->addr_nbytes, but I should rename it to something like
params->def_addr_nbytes and rework spi_nor_set_addr_nbytes().

 static int spi_nor_set_addr_nbytes(struct spi_nor *nor)
 {
	if (nor->flags & SNOR_F_HAS_4BAIT) {
		nor->addr_nbytes = 4;
	} else if (nor->params->def_addr_nbytes) {
 		nor->addr_nbytes = nor->params->def_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).
> 
With param->def_addr_nbytes, I think we can keep nor->addr_nbytes = 0
during SFDP parse.

Thanks,
Takahiro


 






More information about the linux-mtd mailing list