linux-kernel - [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-next>] [day] [month] [year] [list]

Message-Id: <20210621152320.3811194-1-linux@rasmusvillemoes.dk>
Date:   Mon, 21 Jun 2021 17:23:17 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     linux-mtd@...ts.infradead.org
Cc:     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,
        Esben Haabendal <esben@...nix.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: [RFC 0/3] mtd: spi-nor: dealing with reused JEDEC id c22016

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

-- 
2.31.1