All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>
Cc: sr@denx.de, vigneshr@ti.com, jaimeliao@mxic.com.tw,
	richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
	knaerzche@gmail.com, Nicolas.Ferre@microchip.com,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, macromorgan@hotmail.com,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com,
	zhengxunli@mxic.com.tw, p.yadav@ti.com, mail@david-bauer.net,
	code@reto-schneider.ch
Subject: Re: [PATCH v4 2/6] mtd: spi-nor: core: Handle ID collisions between SFDP & non-SFDP flashes
Date: Thu, 3 Mar 2022 14:41:28 +0000	[thread overview]
Message-ID: <72679fc7-42e4-d7b8-1fb9-463f225217fc@microchip.com> (raw)
In-Reply-To: <328762851786f1158505f9159ba3e5bc@walle.cc>

On 3/1/22 23:52, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am 2022-02-28 14:45, schrieb Tudor Ambarus:
>> A typical differentiator between flashes whose ID collide is whether
>> they
>> support SFDP or not. For such a collision there will be a single
>> flash_info entry where the developer should specify:
>> 1/ PARSE_SFDP - so that the flash that supports SFDP to initialize its
>>    parameters by parsing the SFDP tables
>> 2/ any of the no_sfdp_flags less SPI_NOR_SKIP_SFDP, to initialize the
>>    flash parameters via the static no_sfdp_flags for the flash that
>>    doesn't support SFDP.
>> Use the logic the above to handle ID collisions between SFDP & non-SFDP
>> flashes.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>>  drivers/mtd/spi-nor/core.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index fbf3278ba29a..aef00151c116 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -2639,8 +2639,17 @@ static int spi_nor_init_params(struct spi_nor
>> *nor)
>>       if (nor->info->parse_sfdp) {
>>               ret = spi_nor_parse_sfdp(nor);
> 
> Can we return -ENOENT here if sfdp isn't supported, so we
> can differentiate between "no sfdp present" and other errors?

I'll take a look.

> 
>>               if (ret) {
>> -                     dev_err(nor->dev, "BFPT parsing failed. Please consider using
>> SPI_NOR_SKIP_SFDP when declaring the flash\n");
>> -                     return ret;
>> +                     /*
>> +                      * Handle ID collisions between flashes that support
>> +                      * SFDP and flashes that don't. Initialize parameters
>> +                      * for the flash that doesn't support SFDP.
>> +                      */
>> +                     if (nor->info->no_sfdp_flags & ~SPI_NOR_SKIP_SFDP) {
> 
> Shouldn't this be
> if (!(nor->info->no_sfdp_flags & SPI_NOR_SKIP_SFDP))

No, because this will be true when no_sfdp_flags is zero, and the method
from below will be called. I would like to call it when any of the
no_sfdp_flags are defined, less the SPI_NOR_SKIP_SFDP flag. So when one
declares a flash like:
+      { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64)
+             /* ID collision with mx25l3233f. */
+             PARSE_SFDP
+             NO_SFDP_FLAGS(SECT_4K) 

First we will try to retrieve the flash params from SFDP. If SFDP fails,
then we'll init the flash based on the no_sfdp_flags. If SFDP succeeds
the no_sfdp_flags is ignored.

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

WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <michael@walle.cc>
Cc: sr@denx.de, vigneshr@ti.com, jaimeliao@mxic.com.tw,
	richard@nod.at, esben@geanix.com, linux@rasmusvillemoes.dk,
	knaerzche@gmail.com, linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, macromorgan@hotmail.com,
	miquel.raynal@bootlin.com, heiko.thiery@gmail.com,
	zhengxunli@mxic.com.tw, figgyc@figgyc.uk, p.yadav@ti.com,
	mail@david-bauer.net, code@reto-schneider.ch
Subject: Re: [PATCH v4 2/6] mtd: spi-nor: core: Handle ID collisions between SFDP & non-SFDP flashes
Date: Thu, 3 Mar 2022 14:41:28 +0000	[thread overview]
Message-ID: <72679fc7-42e4-d7b8-1fb9-463f225217fc@microchip.com> (raw)
In-Reply-To: <328762851786f1158505f9159ba3e5bc@walle.cc>

On 3/1/22 23:52, Michael Walle wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Am 2022-02-28 14:45, schrieb Tudor Ambarus:
>> A typical differentiator between flashes whose ID collide is whether
>> they
>> support SFDP or not. For such a collision there will be a single
>> flash_info entry where the developer should specify:
>> 1/ PARSE_SFDP - so that the flash that supports SFDP to initialize its
>>    parameters by parsing the SFDP tables
>> 2/ any of the no_sfdp_flags less SPI_NOR_SKIP_SFDP, to initialize the
>>    flash parameters via the static no_sfdp_flags for the flash that
>>    doesn't support SFDP.
>> Use the logic the above to handle ID collisions between SFDP & non-SFDP
>> flashes.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>>  drivers/mtd/spi-nor/core.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index fbf3278ba29a..aef00151c116 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -2639,8 +2639,17 @@ static int spi_nor_init_params(struct spi_nor
>> *nor)
>>       if (nor->info->parse_sfdp) {
>>               ret = spi_nor_parse_sfdp(nor);
> 
> Can we return -ENOENT here if sfdp isn't supported, so we
> can differentiate between "no sfdp present" and other errors?

I'll take a look.

> 
>>               if (ret) {
>> -                     dev_err(nor->dev, "BFPT parsing failed. Please consider using
>> SPI_NOR_SKIP_SFDP when declaring the flash\n");
>> -                     return ret;
>> +                     /*
>> +                      * Handle ID collisions between flashes that support
>> +                      * SFDP and flashes that don't. Initialize parameters
>> +                      * for the flash that doesn't support SFDP.
>> +                      */
>> +                     if (nor->info->no_sfdp_flags & ~SPI_NOR_SKIP_SFDP) {
> 
> Shouldn't this be
> if (!(nor->info->no_sfdp_flags & SPI_NOR_SKIP_SFDP))

No, because this will be true when no_sfdp_flags is zero, and the method
from below will be called. I would like to call it when any of the
no_sfdp_flags are defined, less the SPI_NOR_SKIP_SFDP flag. So when one
declares a flash like:
+      { "mx25l3205d",  INFO(0xc22016, 0, 64 * 1024,  64)
+             /* ID collision with mx25l3233f. */
+             PARSE_SFDP
+             NO_SFDP_FLAGS(SECT_4K) 

First we will try to retrieve the flash params from SFDP. If SFDP fails,
then we'll init the flash based on the no_sfdp_flags. If SFDP succeeds
the no_sfdp_flags is ignored.

Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-03-03 14:42 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 13:44 [PATCH v4 0/6] mtd: spi-nor: Handle ID collisions Tudor Ambarus
2022-02-28 13:44 ` Tudor Ambarus
2022-02-28 13:45 ` [PATCH v4 1/6] mtd: spi-nor: core: Report correct name in case of " Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 21:38   ` Michael Walle
2022-03-01 21:38     ` Michael Walle
2022-04-05 19:41   ` Pratyush Yadav
2022-04-05 19:41     ` Pratyush Yadav
2022-02-28 13:45 ` [PATCH v4 2/6] mtd: spi-nor: core: Handle ID collisions between SFDP & non-SFDP flashes Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 21:52   ` Michael Walle
2022-03-01 21:52     ` Michael Walle
2022-03-03 14:41     ` Tudor.Ambarus [this message]
2022-03-03 14:41       ` Tudor.Ambarus
2022-03-03 14:51       ` Michael Walle
2022-03-03 14:51         ` Michael Walle
2022-03-03 15:25         ` Tudor.Ambarus
2022-03-03 15:25           ` Tudor.Ambarus
2022-03-03 15:42           ` Michael Walle
2022-03-03 15:42             ` Michael Walle
2022-03-03 16:03             ` Tudor.Ambarus
2022-03-03 16:03               ` Tudor.Ambarus
2022-03-03 16:39               ` Michael Walle
2022-03-03 16:39                 ` Michael Walle
2022-02-28 13:45 ` [PATCH v4 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 21:57   ` Michael Walle
2022-03-01 21:57     ` Michael Walle
2022-03-03 15:28     ` Tudor.Ambarus
2022-03-03 15:28       ` Tudor.Ambarus
2022-03-03 15:33       ` Michael Walle
2022-03-03 15:33         ` Michael Walle
     [not found]         ` <CAEyMn7aN+wJnYkTJU_nWA9bPzF1sezA9_=E5YG5rnPBLMAmabA@mail.gmail.com>
2022-03-03 16:45           ` Michael Walle
2022-03-03 16:45             ` Michael Walle
2022-03-04  0:36             ` Tudor.Ambarus
2022-03-04  0:36               ` Tudor.Ambarus
2022-03-04 14:36               ` Michael Walle
2022-03-04 14:36                 ` Michael Walle
2022-04-05 19:50                 ` Pratyush Yadav
2022-04-05 19:50                   ` Pratyush Yadav
2022-02-28 13:45 ` [PATCH v4 4/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L12805D and MX25L12835F Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01  7:55   ` Heiko Thiery
2022-03-01  7:55     ` Heiko Thiery
2022-03-01  8:52     ` Tudor.Ambarus
2022-03-01  8:52       ` Tudor.Ambarus
2022-03-01  9:31       ` Heiko Thiery
2022-03-01  9:31         ` Heiko Thiery
2022-02-28 13:45 ` [PATCH v4 5/6] mtd: spi-nor: Introduce Manufacturer ID collisions driver Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 22:19   ` Michael Walle
2022-03-01 22:19     ` Michael Walle
2022-03-03 16:12     ` Tudor.Ambarus
2022-03-03 16:12       ` Tudor.Ambarus
2022-03-03 21:38       ` Michael Walle
2022-03-03 21:38         ` Michael Walle
2022-03-04  7:07         ` Tudor.Ambarus
2022-03-04  7:07           ` Tudor.Ambarus
2022-03-04 14:10           ` Michael Walle
2022-03-04 14:10             ` Michael Walle
2022-03-04 21:20   ` George Brooke
2022-03-04 21:20     ` George Brooke
2022-03-07  7:07     ` Tudor.Ambarus
2022-03-07  7:07       ` Tudor.Ambarus
2022-02-28 13:45 ` [PATCH v4 6/6] mtd: spi-nor: manuf-id-collisions: Add support for xt25f128b Tudor Ambarus
2022-02-28 13:45   ` Tudor Ambarus
2022-03-01 22:23   ` Michael Walle
2022-03-01 22:23     ` Michael Walle
2022-03-03 21:04     ` Chris Morgan
2022-03-03 21:04       ` Chris Morgan
2022-03-03 23:50       ` Tudor.Ambarus
2022-03-03 23:50         ` Tudor.Ambarus
2022-03-04  2:23         ` Chris Morgan
2022-03-04  2:23           ` Chris Morgan
2022-02-28 13:55 ` [PATCH v4 0/6] mtd: spi-nor: Handle ID collisions Michael Walle
2022-02-28 13:55   ` Michael Walle
2022-02-28 15:39   ` [PATCH] mtd: spi-nor: Move XMC to manufacturer ID collisions driver Tudor Ambarus
2022-02-28 15:39     ` Tudor Ambarus
2022-03-01  6:47   ` [PATCH v2] " Tudor Ambarus
2022-03-01  6:47     ` 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=72679fc7-42e4-d7b8-1fb9-463f225217fc@microchip.com \
    --to=tudor.ambarus@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=code@reto-schneider.ch \
    --cc=esben@geanix.com \
    --cc=heiko.thiery@gmail.com \
    --cc=jaimeliao@mxic.com.tw \
    --cc=knaerzche@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --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 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.