linux-kernel - Re: [PATCH][RFC] mtd: spinand: fix detection of GD5FxGQ4xA flash

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: <20191028174131.65c3d580@xps13>
Date:   Mon, 28 Oct 2019 17:41:31 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Chuanhong Guo <gch981213@...il.com>
Cc:     linux-mtd@...ts.infradead.org,
        Jeff Kletsky <git-commits@...ycomm.com>,
        Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Frieder Schrempf <frieder.schrempf@...tron.de>,
        Boris Brezillon <bbrezillon@...nel.org>,
        Stefan Roese <sr@...x.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH][RFC] mtd: spinand: fix detection of GD5FxGQ4xA flash

Hello,

Chuanhong Guo <gch981213@...il.com> wrote on Wed, 16 Oct 2019 09:38:24
+0800:

> GD5FxGQ4xA didn't follow the SPI spec to keep MISO low while slave is
> reading, and instead MISO is kept high. As a result, the first byte
> of id becomes 0xFF.
> Since the first byte isn't supposed to be checked at all, this patch
> just removed that check.
> 
> While at it, redo the comment above to better explain what's happening.
> 
> Fixes: cfd93d7c908e ("mtd: spinand: Add support for GigaDevice GD5F1GQ4UFxxG")
> Signed-off-by: Chuanhong Guo <gch981213@...il.com>
> CC: Jeff Kletsky <git-commits@...ycomm.com>
> ---
> RFC:
> I doubt whether this patch is a proper fix for the underlying problem:
> The actual problem is that we have two different implementation of read id
> command: One replies immediately after master sending 0x9f and the other
> need to send 0x9f and an offset byte (found in winbond and early GD flashes.)
> Current code only works if SPI master is properly implemented (i.e. keep MOSI
> low while reading.)

I am not entirely against the fix, but this is a SPI host controller
issue, right? Can you try to fix the controller driver instead?

Thanks,
Miquèl