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 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D Date: Tue, 01 Mar 2022 22:57:10 +0100 [thread overview] Message-ID: <67810d13180a2718ad7ccc28815d2894@walle.cc> (raw) In-Reply-To: <20220228134505.203270-4-tudor.ambarus@microchip.com> Am 2022-02-28 14:45, schrieb Tudor Ambarus: > Macronix has a bad habbit of reusing flash IDs. While MX25L3233F > supports > RDSFDP opcode, MX25L3205D does not support it and does not recommend > issuing opcodes that are not supported ("It is not recommended to adopt > any other code not in the command definition table, which will > potentially > enter the hidden mode."). > > We tested the RDSFDP on the MX25L3205D and the conclusion is that the > flash didn't reply anything. Given that it is unlikely that RDSFDP will > cause any problems for the old MX25L3205D, differentiate between the > two > flashes by parsing SFDP. > > Tested MX25L3233F. Generated a 256 Kbyte random data and did an erase, > write, read back and compare test. The flash uses for reads > SPINOR_OP_READ_1_4_4 0xeb, for erases SPINOR_OP_BE_4K 0x20, and for > writes > SPINOR_OP_PP 0x02. > > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> > Acked-by: Pratyush Yadav <p.yadav@ti.com> > --- > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/jedec_id > c22016 > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/manufacturer > macronix > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/partname > mx25l3233f > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/sfdp > > mx25l3233f-sfdp > > > # xxd -p mx25l3233f-sfdp > 53464450000101ff00000109300000ffc2000104600000ffffffffffffff > ffffffffffffffffffffffffffffffffffffe520f1ffffffff0144eb086b > 083b04bbeeffffffffff00ffffff00ff0c200f5210d800ffffffffffffff > ffffffffffff003650269cf97764fecfffffffffffff Is quad enable working or has this the same problem as the macronix flash in patch 4? Judging by the length of the SFDP this also lacks the required information to select an appropriate enable method. I haven't had closer look though. > > # sha1sum mx25l3233f-sfdp > 1b6e0f75b4a6d08d570082992455affa72b2dc81 mx25l3233f-sfdp > > drivers/mtd/spi-nor/macronix.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/macronix.c > b/drivers/mtd/spi-nor/macronix.c > index d81a4cb2812b..2754bbef3d2e 100644 > --- a/drivers/mtd/spi-nor/macronix.c > +++ b/drivers/mtd/spi-nor/macronix.c > @@ -8,6 +8,24 @@ > > #include "core.h" > > +static int mx25l3205d_post_bfpt_fixups(struct spi_nor *nor, > + const struct sfdp_parameter_header *bfpt_header, > + const struct sfdp_bfpt *bfpt) > +{ > + /* > + * Macronix has a bad habit of reusing flash IDs: MX25L3233F collides > + * with MX25L3205D. MX25L3233F defines SFDP tables, while the older > + * variant does not. > + */ > + nor->name = "mx25l3233f"; > + > + return 0; > +} > + > +static const struct spi_nor_fixups mx25l3205d_fixups = { > + .post_bfpt = mx25l3205d_post_bfpt_fixups, > +}; > + > static int > mx25l25635_post_bfpt_fixups(struct spi_nor *nor, > const struct sfdp_parameter_header *bfpt_header, > @@ -44,7 +62,10 @@ static const struct flash_info macronix_nor_parts[] > = { > { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32) > NO_SFDP_FLAGS(SECT_4K) }, > { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64) > - NO_SFDP_FLAGS(SECT_4K) }, > + /* ID collision with mx25l3233f. */ > + PARSE_SFDP > + NO_SFDP_FLAGS(SECT_4K) > + .fixups = &mx25l3205d_fixups }, > { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64) > NO_SFDP_FLAGS(SECT_4K) }, > { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128) -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 3/6] mtd: spi-nor: macronix: Handle ID collision b/w MX25L3233F and MX25L3205D Date: Tue, 01 Mar 2022 22:57:10 +0100 [thread overview] Message-ID: <67810d13180a2718ad7ccc28815d2894@walle.cc> (raw) In-Reply-To: <20220228134505.203270-4-tudor.ambarus@microchip.com> Am 2022-02-28 14:45, schrieb Tudor Ambarus: > Macronix has a bad habbit of reusing flash IDs. While MX25L3233F > supports > RDSFDP opcode, MX25L3205D does not support it and does not recommend > issuing opcodes that are not supported ("It is not recommended to adopt > any other code not in the command definition table, which will > potentially > enter the hidden mode."). > > We tested the RDSFDP on the MX25L3205D and the conclusion is that the > flash didn't reply anything. Given that it is unlikely that RDSFDP will > cause any problems for the old MX25L3205D, differentiate between the > two > flashes by parsing SFDP. > > Tested MX25L3233F. Generated a 256 Kbyte random data and did an erase, > write, read back and compare test. The flash uses for reads > SPINOR_OP_READ_1_4_4 0xeb, for erases SPINOR_OP_BE_4K 0x20, and for > writes > SPINOR_OP_PP 0x02. > > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> > Acked-by: Pratyush Yadav <p.yadav@ti.com> > --- > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/jedec_id > c22016 > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/manufacturer > macronix > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/partname > mx25l3233f > # cat > /sys/devices/platform/ahb/ahb:apb/f0020000.spi/spi_master/spi1/spi1.0/spi-nor/sfdp > > mx25l3233f-sfdp > > > # xxd -p mx25l3233f-sfdp > 53464450000101ff00000109300000ffc2000104600000ffffffffffffff > ffffffffffffffffffffffffffffffffffffe520f1ffffffff0144eb086b > 083b04bbeeffffffffff00ffffff00ff0c200f5210d800ffffffffffffff > ffffffffffff003650269cf97764fecfffffffffffff Is quad enable working or has this the same problem as the macronix flash in patch 4? Judging by the length of the SFDP this also lacks the required information to select an appropriate enable method. I haven't had closer look though. > > # sha1sum mx25l3233f-sfdp > 1b6e0f75b4a6d08d570082992455affa72b2dc81 mx25l3233f-sfdp > > drivers/mtd/spi-nor/macronix.c | 23 ++++++++++++++++++++++- > 1 file changed, 22 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/macronix.c > b/drivers/mtd/spi-nor/macronix.c > index d81a4cb2812b..2754bbef3d2e 100644 > --- a/drivers/mtd/spi-nor/macronix.c > +++ b/drivers/mtd/spi-nor/macronix.c > @@ -8,6 +8,24 @@ > > #include "core.h" > > +static int mx25l3205d_post_bfpt_fixups(struct spi_nor *nor, > + const struct sfdp_parameter_header *bfpt_header, > + const struct sfdp_bfpt *bfpt) > +{ > + /* > + * Macronix has a bad habit of reusing flash IDs: MX25L3233F collides > + * with MX25L3205D. MX25L3233F defines SFDP tables, while the older > + * variant does not. > + */ > + nor->name = "mx25l3233f"; > + > + return 0; > +} > + > +static const struct spi_nor_fixups mx25l3205d_fixups = { > + .post_bfpt = mx25l3205d_post_bfpt_fixups, > +}; > + > static int > mx25l25635_post_bfpt_fixups(struct spi_nor *nor, > const struct sfdp_parameter_header *bfpt_header, > @@ -44,7 +62,10 @@ static const struct flash_info macronix_nor_parts[] > = { > { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32) > NO_SFDP_FLAGS(SECT_4K) }, > { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64) > - NO_SFDP_FLAGS(SECT_4K) }, > + /* ID collision with mx25l3233f. */ > + PARSE_SFDP > + NO_SFDP_FLAGS(SECT_4K) > + .fixups = &mx25l3205d_fixups }, > { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64) > NO_SFDP_FLAGS(SECT_4K) }, > { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128) -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:58 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 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 [this message] 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=67810d13180a2718ad7ccc28815d2894@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.