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 5/6] mtd: spi-nor: Introduce Manufacturer ID collisions driver
Date: Tue, 01 Mar 2022 23:19:50 +0100 [thread overview]
Message-ID: <0edfa6e267995a127181173496b471ea@walle.cc> (raw)
In-Reply-To: <20220228134505.203270-6-tudor.ambarus@microchip.com>
Am 2022-02-28 14:45, schrieb Tudor Ambarus:
> Some manufacturers completely ignore the manufacturer's identification
> code
> standard (JEP106) and do not define the manufacturer ID continuation
> scheme. This will result in manufacturer ID collisions.
>
> An an example, JEP106BA requires Boya that it's manufacturer ID to be
> preceded by 8 continuation codes. Boya's identification code must be:
> 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x68. But Boya ignores
> the
> continuation scheme and its ID collides with the manufacturer defined
> in
> bank one: Convex Computer.
>
> Introduce the manuf-id-collisions driver in order to address ID
> collisions
> between manufacturers. flash_info entries will be added in a first
> come,
> first served manner. Differentiation between flashes will be done at
> runtime if possible. Where runtime differentiation is not possible, new
> compatibles will be introduced, but this will be done as a last resort.
> Every new flash addition that define the SFDP tables, should dump its
> SFDP
> tables in the patch's comment section below the --- line, so that we
> can
> reference it in case of collisions.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
> drivers/mtd/spi-nor/Makefile | 1 +
> drivers/mtd/spi-nor/core.c | 3 +++
> drivers/mtd/spi-nor/core.h | 1 +
> drivers/mtd/spi-nor/manuf-id-collisions.c | 32 +++++++++++++++++++++++
> drivers/mtd/spi-nor/sysfs.c | 2 +-
> include/linux/mtd/spi-nor.h | 6 ++++-
> 6 files changed, 43 insertions(+), 2 deletions(-)
> create mode 100644 drivers/mtd/spi-nor/manuf-id-collisions.c
>
> diff --git a/drivers/mtd/spi-nor/Makefile
> b/drivers/mtd/spi-nor/Makefile
> index 6b904e439372..48763d10daad 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> spi-nor-objs := core.o sfdp.o swp.o otp.o sysfs.o
> +spi-nor-objs += manuf-id-collisions.o
> spi-nor-objs += atmel.o
> spi-nor-objs += catalyst.o
> spi-nor-objs += eon.o
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index aef00151c116..80d6ce41122a 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1610,6 +1610,7 @@ int spi_nor_sr2_bit7_quad_enable(struct spi_nor
> *nor)
> }
>
> static const struct spi_nor_manufacturer *manufacturers[] = {
> + &spi_nor_manuf_id_collisions,
I'm still not convinced it should be the first entry here. We will
put other vendors at a disadvantage who play fair. I doubt we will
always checking any new IDs for duplications - or some might slip
through. Putting it as the last entry will make sure, legitimate
users will always come first.
Esp. because xmc reuses vendor id whose flashes we also support
making a collision very likely. Unlike boya who reuses "convex
computers" where we will probably never see an SPI flash from.
That being said. I'd also suggest to only allow flashes with
SFDP here, so we have at least some clue to differentiate
between flashes. If there will ever be a flash without SFDP
and which is using a non-legitimate vendor id, then we'll
need to either deny support for it or specify it by a name
(i.e. device tree compatible or similar). But these should
go into a seperate list then.
> &spi_nor_atmel,
> &spi_nor_catalyst,
> &spi_nor_eon,
> @@ -3037,6 +3038,8 @@ int spi_nor_scan(struct spi_nor *nor, const char
> *name,
>
> if (!nor->name)
> nor->name = info->name;
> + if (!nor->manufacturer_name)
> + nor->manufacturer_name = nor->manufacturer->name;
>
> dev_info(dev, "%s (%lld Kbytes)\n", nor->name,
> (long long)mtd->size >> 10);
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index b7fd760e3b47..f727e632c0ee 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -500,6 +500,7 @@ struct sfdp {
> };
>
> /* Manufacturer drivers. */
> +extern const struct spi_nor_manufacturer spi_nor_manuf_id_collisions;
> extern const struct spi_nor_manufacturer spi_nor_atmel;
> extern const struct spi_nor_manufacturer spi_nor_catalyst;
> extern const struct spi_nor_manufacturer spi_nor_eon;
> diff --git a/drivers/mtd/spi-nor/manuf-id-collisions.c
> b/drivers/mtd/spi-nor/manuf-id-collisions.c
> new file mode 100644
> index 000000000000..75c5ad6480ee
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/manuf-id-collisions.c
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Used to handle collisions between manufacturers, where
> manufacturers are
> + * ignorant enough to not implement the ID continuation scheme
> described in the
> + * JEP106 JEDEC standard.
> + */
> +
> +#include <linux/mtd/spi-nor.h>
> +#include "core.h"
> +
> +static void boya_nor_late_init(struct spi_nor *nor)
> +{
> + nor->manufacturer_name = "boya";
> +}
> +
> +static const struct spi_nor_fixups boya_nor_fixups = {
> + .late_init = boya_nor_late_init,
> +};
> +
> +static const struct flash_info id_collision_parts[] = {
> + /* Boya */
> + { "by25q128as", INFO(0x684018, 0, 64 * 1024, 256)
> + FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
> + NO_SFDP_FLAGS(SPI_NOR_SKIP_SFDP | SECT_4K | SPI_NOR_DUAL_READ |
> + SPI_NOR_QUAD_READ)
> + .fixups = &boya_nor_fixups },
No PARSE_SFDP nor SKIP_SFDP?
> +};
> +
> +const struct spi_nor_manufacturer spi_nor_manuf_id_collisions = {
> + .parts = id_collision_parts,
> + .nparts = ARRAY_SIZE(id_collision_parts),
> +};
> diff --git a/drivers/mtd/spi-nor/sysfs.c b/drivers/mtd/spi-nor/sysfs.c
> index 017119768f32..fa0cf1a96797 100644
> --- a/drivers/mtd/spi-nor/sysfs.c
> +++ b/drivers/mtd/spi-nor/sysfs.c
> @@ -14,7 +14,7 @@ static ssize_t manufacturer_show(struct device *dev,
> struct spi_mem *spimem = spi_get_drvdata(spi);
> struct spi_nor *nor = spi_mem_get_drvdata(spimem);
>
> - return sysfs_emit(buf, "%s\n", nor->manufacturer->name);
> + return sysfs_emit(buf, "%s\n", nor->manufacturer_name);
> }
> static DEVICE_ATTR_RO(manufacturer);
>
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 449496b57acb..3087589d01ac 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -351,7 +351,10 @@ struct spi_nor_flash_parameter;
> * @bouncebuf: bounce buffer used when the buffer passed by the MTD
> * layer is not DMA-able
> * @bouncebuf_size: size of the bounce buffer
> - * @name: used to point to correct name in case of ID collisions.
> + * @name: used to point to correct flash name in case of ID
> + * collisions.
> + * @manufacturer_name: used to point to correct manufacturer name in
> case of
> + * ID collisions.
> * @info: SPI NOR part JEDEC MFR ID and other info
> * @manufacturer: SPI NOR manufacturer
> * @addr_width: number of address bytes
> @@ -382,6 +385,7 @@ struct spi_nor {
> u8 *bouncebuf;
> size_t bouncebuf_size;
> const char *name;
> + const char *manufacturer_name;
> const struct flash_info *info;
> const struct spi_nor_manufacturer *manufacturer;
> u8 addr_width;
-michael
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2022-03-01 22:20 UTC|newest]
Thread overview: 40+ 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:45 ` [PATCH v4 1/6] mtd: spi-nor: core: Report correct name in case of " Tudor Ambarus
2022-03-01 21:38 ` Michael Walle
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-03-01 21:52 ` Michael Walle
2022-03-03 14:41 ` Tudor.Ambarus
2022-03-03 14:51 ` Michael Walle
2022-03-03 15:25 ` Tudor.Ambarus
2022-03-03 15:42 ` Michael Walle
2022-03-03 16:03 ` Tudor.Ambarus
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-03-01 21:57 ` Michael Walle
2022-03-03 15:28 ` Tudor.Ambarus
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-04 0:36 ` Tudor.Ambarus
2022-03-04 14:36 ` Michael Walle
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-03-01 7:55 ` Heiko Thiery
2022-03-01 8:52 ` Tudor.Ambarus
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-03-01 22:19 ` Michael Walle [this message]
2022-03-03 16:12 ` Tudor.Ambarus
2022-03-03 21:38 ` Michael Walle
2022-03-04 7:07 ` Tudor.Ambarus
2022-03-04 14:10 ` Michael Walle
2022-03-04 21:20 ` George Brooke
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-03-01 22:23 ` Michael Walle
2022-03-03 21:04 ` Chris Morgan
2022-03-03 23:50 ` Tudor.Ambarus
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 15:39 ` [PATCH] mtd: spi-nor: Move XMC to manufacturer ID collisions driver Tudor Ambarus
2022-03-01 6:47 ` [PATCH v2] " 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=0edfa6e267995a127181173496b471ea@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox