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
next prev parent 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: linkBe 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.