linux-kernel - Re: [RFC 0/3] mtd: spi-nor: dealing with reused JEDEC id c22016

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8735taxna8.fsf@geanix.com>
Date:   Tue, 22 Jun 2021 11:26:55 +0200
From:   Esben Haabendal <esben@...nix.com>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     linux-mtd@...ts.infradead.org,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Boris Brezillon <bbrezillon@...nel.org>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Michael Walle <michael@...le.cc>,
        Pratyush Yadav <p.yadav@...com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/3] mtd: spi-nor: dealing with reused JEDEC id c22016

Rasmus Villemoes <linux@...musvillemoes.dk> writes:

> We use the Macronix chip mx25l3233f in a number of
> products.
>
> Unfortunately, it has the same JEDEC id as another chip which is
> already listed in macronix_parts[]. Since that other one does not
> support SFDP, and its data sheet warns against issuing commands not
> explicitly listed, we can't just do RDSFDP anyway and decide that it's
> an mx25l3205d when the chip returns garbage.
>
> For lack of better alternative, start allowing multiple entries with
> the same JEDEC id in the parts tables. That allows a correctly written
> device tree to specify the right chip, without being overruled by the
> "JEDEC knows better" heuristic, while being backwards-compatible (as
> long as new chips with recycled ids get added after the existing
> ones).
>
> While a step forward, this isn't quite a complete solution for our case:
>
> Some of our platforms are based on LS1021A, thus using the
> spi-fsl-qspi driver. Back in the 4.19 kernel, when the driver was
> fsl-quadspi, we couldn't get the flash recognized unless we
> monkey-patch-replaced the mx25l3205d entry with the mx25l3233f one
> (i.e. added the SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ bits) - we'd
> fail in spi_nor_select_read() because
> shared_hwcaps&SNOR_HWCAPS_READ_MASK would be empty. In contrast, with
> current master, the chip works with or without the third patch in this
> series, i.e. whether it is detected as a mx25l3205d or mx25l3233f. But
> the read performance is ~3 times worse than in our patched 4.19 - I
> haven't quite figured out why quad read doesn't seem to be used or
> work.
>
>
> Rasmus Villemoes (3):
>   mtd: spi-nor: core: create helper to compare JEDEC id to struct
>     flash_info
>   mtd: spi-nor: core: compare JEDEC bytes to already found flash_info
>   mtd: spi-nor: macronix: add entry for mx25l3233f
>
>  drivers/mtd/spi-nor/core.c     | 18 +++++++++++++-----
>  drivers/mtd/spi-nor/macronix.c |  3 +++
>  2 files changed, 16 insertions(+), 5 deletions(-)

For whole series:

Acked-by: Esben Haabendal <esben@...nix.com>