spi-nor: maxronix MX25L12835F support

[Tudor.Ambarus at microchip.com]

On 3/1/21 4:42 PM, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am 2021-03-01 15:09, schrieb Tudor.Ambarus at microchip.com:
>> On 3/1/21 3:50 PM, Michael Walle wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know
>>> the content is safe
>>>
>>> Am 2021-03-01 14:36, schrieb Pratyush Yadav:
>>>> I think printing the correct flash name is somewhat important. Other
>>>> than the handful of people who are reading this thread, few would
>>>> know
>>>> that SPI NOR calls mx25l12835f as mx25l12805d or vice versa. This can
>>>> cause a lot of confusion among people trying to debug any issues.
>>>
>>> Unfortunately, this is kind of a mess. If multiple flash devices
>>> share the same id, it seems to be first come first serve. The kernel
>>> will print the name which was introduced first.
>>>
>>> This isn't the only flash which is affected. Have a look at
>>>   drivers/mtd/spi-nor/winbond.c
>>> There are all kind of flash names, some of them are not even existing
>>> as this particular string, eg. take w25q64jwm, its actually "Winbond
>>> W25Q64JW-IM or W25Q64JW-JM".
>>>
>>> So yes, it would be nice to have such a thing, but for now, I will
>>> take the kernel output as a rough estimation what might really be
>>> used on the board.
>>>
>>
>> How about naming them something like "updated-flash-name ||
>> first-name".
>> Anyway, these are just workarounds. Manufacturers shouldn't use the
>> same
>> JEDEC ID for new flashes. They should at least add an extended ID.
> 
> Mh, what about a list of names? I mean yes it is a workaround, but
> there is actual hardware doing this, so IMHO linux has to deal with
> it in some way. OTOH that list might be long and doesn't look good
> in dmesg (or wherever that string might be used).
> 
> It might come in handy to have a mechanism in place if someone
> really cares about it though.
> 

A list of names with differentiation at run-time, where possible,
sounds good. Otherwise we'll stick to a default name, whatever that
will be. Do you care to scratch a patch for the list of names idea?

We'll still have a single flash entry, with a list of names, and we
still need to either do the SFDP detection first, or to trigger the
SFDP detection with an explicit flash info flag. I'll follow Pratyush's
steps and evaluate the "detect SFDP first" idea.