public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <p.yadav@ti.com>
Cc: <michael@walle.cc>, <vigneshr@ti.com>, <figgyc@figgyc.uk>,
	<mail@david-bauer.net>, <linux@rasmusvillemoes.dk>,
	<esben@geanix.com>, <knaerzche@gmail.com>,
	<code@reto-schneider.ch>, <zhengxunli@mxic.com.tw>,
	<jaimeliao@mxic.com.tw>, <heiko.thiery@gmail.com>,
	<macromorgan@hotmail.com>,  <sr@denx.de>,
	<miquel.raynal@bootlin.com>, <richard@nod.at>,
	<linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 2/7] mtd: spi-nor: core: Report correct name in case of ID collisions
Date: Mon, 5 Jul 2021 13:27:51 +0000	[thread overview]
Message-ID: <888b75ad-e1d0-9ec6-80cd-de6796f1c4d5@microchip.com> (raw)
In-Reply-To: <579514fe-3134-c964-48ac-af729c4ccffc@microchip.com>

On 7/5/21 4:24 PM, Tudor Ambarus - M18064 wrote:
> On 7/5/21 4:13 PM, Pratyush Yadav wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 02/07/21 05:41PM, Tudor Ambarus wrote:
>>> Provide a way to report the correct flash name in case of ID collisions.
>>> There will be a single flash_info entry when flash IDs collide, and the
>>> differentiation between the flash types will be made at runtime
>>> if possible.
>>
>> I am not sure if having one entry for all flashes with a collision is a
>> good idea. For example, say we have one flash which supports SFDP and
>> that's all we need for it. Another flash with the same ID does not
>> support SFDP so it needs the SPI_NOR_DUAL_READ, etc. flags. How would
>> you handle this case with the same entry? You would have to set all the
>> flags in the disambiguation function. And nor->info is declared as const
>> so you can't change the flags in there. Any code checking for
>> info->flags would not work properly for these type of flashes. Wouldn't
>> it be better to have multiple entries with the same ID and just pick the
>> one we need in the disambiguation function?
> 
> Your scenario is hit in patches 3/7 and 4/7. In case of ID collisions between
> a SFDP and a non-SFDP compliant flash, I propose to set SPI_NOR_PARSE_SFDP, as
> well as all the other required flash info flags that statically init the flash.
> The SFDP flash will init all its NOR flags at runtime, while the non-SFDP flash

s/runtime/based on SFDP data

> will issue a RDSFDP command that will fail, and then it will init all the NOR
> flags based on the flash info flags.
> 
>>
>> Anyway, if you do decide to go with this approach, comments below.
> 
> Right, thanks.
> 

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

  reply	other threads:[~2021-07-05 13:28 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02 14:41 [PATCH 0/7] mtd: spi-nor: Handle flash ID collisions Tudor Ambarus
2021-07-02 14:41 ` [PATCH 1/7] mtd: spi-nor: core: Introduce SPI_NOR_PARSE_SFDP Tudor Ambarus
2021-07-04 13:11   ` Heiko Thiery
2021-07-05 12:58   ` Pratyush Yadav
2021-07-02 14:41 ` [PATCH 2/7] mtd: spi-nor: core: Report correct name in case of ID collisions Tudor Ambarus
2021-07-04 13:11   ` Heiko Thiery
2021-07-05 13:13   ` Pratyush Yadav
2021-07-05 13:24     ` Tudor.Ambarus
2021-07-05 13:27       ` Tudor.Ambarus [this message]
2021-07-05 16:09       ` Pratyush Yadav
2021-07-06  5:19         ` Tudor.Ambarus
2021-07-06  6:39           ` Pratyush Yadav
2021-07-02 14:41 ` [PATCH 3/7] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D Tudor Ambarus
2021-07-06  6:14   ` Pratyush Yadav
2021-07-02 14:41 ` [PATCH 4/7] mtd: spi-nor: macronix: Handle ID collision b/w MX25L12805D and MX25L12835F Tudor Ambarus
2021-07-04 13:11   ` Heiko Thiery
2021-07-05  7:51   ` Tudor.Ambarus
2021-07-05 10:45     ` Heiko Thiery
2021-07-05 10:59       ` Michael Walle
2021-07-05 11:12         ` Heiko Thiery
2021-07-05 11:51       ` Tudor.Ambarus
2021-07-06  6:17   ` Pratyush Yadav
2021-07-02 14:41 ` [PATCH 5/7] mtd: spi-nor: Introduce Manufacturer ID collisions driver Tudor Ambarus
2021-07-06  6:34   ` Pratyush Yadav
2021-07-06  6:46     ` Tudor.Ambarus
2021-07-02 14:41 ` [PATCH 6/7] mtd: spi-nor: manuf-id-collisions: Add support for xt25f128b Tudor Ambarus
2021-07-06  6:28   ` Pratyush Yadav
2021-07-06  6:39     ` Tudor.Ambarus
2021-07-06  6:41       ` Pratyush Yadav
2021-07-06 17:49       ` Chris Morgan
2021-07-02 14:41 ` [PATCH 7/7] mtd: spi-nor: manuf-id-collisions: Add support for xm25qh64c 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=888b75ad-e1d0-9ec6-80cd-de6796f1c4d5@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=code@reto-schneider.ch \
    --cc=esben@geanix.com \
    --cc=figgyc@figgyc.uk \
    --cc=heiko.thiery@gmail.com \
    --cc=jaimeliao@mxic.com.tw \
    --cc=knaerzche@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=macromorgan@hotmail.com \
    --cc=mail@david-bauer.net \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=sr@denx.de \
    --cc=vigneshr@ti.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox