All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Walle <michael@walle.cc>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
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: Tue, 01 Mar 2022 22:52:45 +0100	[thread overview]
Message-ID: <328762851786f1158505f9159ba3e5bc@walle.cc> (raw)
In-Reply-To: <20220228134505.203270-3-tudor.ambarus@microchip.com>

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?

>  		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))

> +				spi_nor_no_sfdp_init_params(nor);
> +			} else {
> +				dev_err(nor->dev, "BFPT parsing failed. Please consider using
> SPI_NOR_SKIP_SFDP when declaring the flash\n");
> +				return ret;
> +			}
>  		}
>  	} else if (nor->info->no_sfdp_flags & SPI_NOR_SKIP_SFDP) {
>  		spi_nor_no_sfdp_init_params(nor);

-michael

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

WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <michael@walle.cc>
To: Tudor Ambarus <tudor.ambarus@microchip.com>
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: Tue, 01 Mar 2022 22:52:45 +0100	[thread overview]
Message-ID: <328762851786f1158505f9159ba3e5bc@walle.cc> (raw)
In-Reply-To: <20220228134505.203270-3-tudor.ambarus@microchip.com>

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?

>  		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))

> +				spi_nor_no_sfdp_init_params(nor);
> +			} else {
> +				dev_err(nor->dev, "BFPT parsing failed. Please consider using
> SPI_NOR_SKIP_SFDP when declaring the flash\n");
> +				return ret;
> +			}
>  		}
>  	} else if (nor->info->no_sfdp_flags & SPI_NOR_SKIP_SFDP) {
>  		spi_nor_no_sfdp_init_params(nor);

-michael

_______________________________________________
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-01 21:53 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 [this message]
2022-03-01 21:52     ` Michael Walle
2022-03-03 14:41     ` Tudor.Ambarus
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=328762851786f1158505f9159ba3e5bc@walle.cc \
    --to=michael@walle.cc \
    --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=miquel.raynal@bootlin.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=p.yadav@ti.com \
    --cc=richard@nod.at \
    --cc=sr@denx.de \
    --cc=tudor.ambarus@microchip.com \
    --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.