All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vignesh Raghavendra <vigneshr@ti.com>
To: <Tudor.Ambarus@microchip.com>, <michael@walle.cc>
Cc: juliensu@mxic.com.tw, ycllin@mxic.com.tw,
	linux-mtd@lists.infradead.org, heiko.thiery@gmail.com,
	p.yadav@ti.com, zhengxunli@mxic.com.tw
Subject: Re: spi-nor: maxronix MX25L12835F support
Date: Tue, 2 Mar 2021 11:19:14 +0530	[thread overview]
Message-ID: <c4db1916-18fe-5167-31c1-6bc652bb6212@ti.com> (raw)
In-Reply-To: <116efdb0-8b82-914d-2389-d73e2ea2e89a@microchip.com>



On 3/1/21 8:55 PM, Tudor.Ambarus@microchip.com wrote:
> 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@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.
> 

If we do go down the road of "detect SFDP first", we should add
SPI_NOR_SKIP_SFDP to flashes that currently don't claim DUAL/QUAD/OCTAL
capability currently in order to avoid any surprises due to wrong values
in the table.

Regards
Vignesh



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-03-02  5:50 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-15 21:53 spi-nor: maxronix MX25L12835F support Heiko Thiery
2021-02-16  9:27 ` Pratyush Yadav
2021-02-16  9:45   ` Heiko Thiery
2021-02-16  9:48   ` Michael Walle
2021-02-16 10:16     ` Pratyush Yadav
2021-02-16 10:20       ` Pratyush Yadav
2021-02-16 10:41         ` Heiko Thiery
2021-02-16 10:48           ` Pratyush Yadav
2021-02-16 10:55             ` Heiko Thiery
2021-02-16 11:05               ` Pratyush Yadav
2021-02-16 11:15     ` Tudor.Ambarus
2021-02-18  5:45       ` zhengxunli
2021-02-18  7:15         ` Heiko Thiery
2021-02-18  7:56         ` Tudor.Ambarus
2021-02-18  8:49           ` Tudor.Ambarus
2021-02-18  7:43       ` Heiko Thiery
2021-02-18  9:27         ` Tudor.Ambarus
2021-02-18 10:15           ` Heiko Thiery
2021-02-18 10:26             ` Tudor.Ambarus
2021-02-18 10:36               ` Heiko Thiery
2021-02-19  2:45               ` zhengxunli
2021-02-27 21:52               ` Heiko Thiery
2021-03-01 10:52                 ` Vignesh Raghavendra
2021-03-01 11:11                   ` Tudor.Ambarus
2021-03-01 13:36                     ` Pratyush Yadav
2021-03-01 13:50                       ` Michael Walle
2021-03-01 14:09                         ` Tudor.Ambarus
2021-03-01 14:42                           ` Michael Walle
2021-03-01 15:25                             ` Tudor.Ambarus
2021-03-02  5:49                               ` Vignesh Raghavendra [this message]
2021-03-03 13:44                                 ` Heiko Thiery
2021-03-04  7:02                                   ` Vignesh Raghavendra
2021-03-04  7:10                                     ` Heiko Thiery
2021-03-19 14:33                                       ` Stefan Herbrechtsmeier
2021-03-01 15:40                         ` Pratyush Yadav
2021-03-01 14:03                       ` Tudor.Ambarus
2021-06-28  7:29 ` Tudor.Ambarus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4db1916-18fe-5167-31c1-6bc652bb6212@ti.com \
    --to=vigneshr@ti.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=heiko.thiery@gmail.com \
    --cc=juliensu@mxic.com.tw \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michael@walle.cc \
    --cc=p.yadav@ti.com \
    --cc=ycllin@mxic.com.tw \
    --cc=zhengxunli@mxic.com.tw \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.