linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Chuanhong Guo <gch981213@gmail.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Stefan Roese <sr@denx.de>, Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	open list <linux-kernel@vger.kernel.org>,
	Frieder Schrempf <frieder.schrempf@kontron.de>,
	linux-mtd@lists.infradead.org,
	Richard Weinberger <richard@nod.at>,
	Brian Norris <computersforpeace@gmail.com>,
	Jeff Kletsky <git-commits@allycomm.com>
Subject: Re: [PATCH][RFC] mtd: spinand: fix detection of GD5FxGQ4xA flash
Date: Sun, 3 Nov 2019 20:03:21 +0800	[thread overview]
Message-ID: <CAJsYDVJgwRfg2kfmuG4P-NCEAZ4box+=Yb53d0J+rAjLRpc3Ww@mail.gmail.com> (raw)
In-Reply-To: <20191028174131.65c3d580@xps13>

Hi!

On Tue, Oct 29, 2019 at 12:41 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hello,
>
> Chuanhong Guo <gch981213@gmail.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@gmail.com>
> > CC: Jeff Kletsky <git-commits@allycomm.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.)

Correction: Only early GigaDevice nand chips uses this implementation.
Winbond chips uses a dummy byte instead of an address byte so there's
no problem for Winbond chips.

> > 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?

I think this is a spi nand framework issue. GigaDevice uses an unusual
READ ID implementation, and as a result, both host controller and chip
are reading during the first byte after 0x9f command: chip is reading
the address/offset byte and host is expecting the first ID byte.
Here lies two problems:
1. According to the sequence diagram in their datasheet, MISO pin is
in High-Z state during the 0x9f command and the offset byte, and host
could read anything during this time instead of a fixed 0x0 or 0xff
byte, so the check of first byte should be removed. This is what this
patch is doing.
2. If there's a buggy SPI host controller that didn't keep MOSI low
during reading operation, the chip will get 0xff as ID offset, causing
the read vendor/device ID to be swapped. I never met such a controller
so far, but if there is one, it will be a silicon bug that can't be
fixed by software. To fix this one, we'll have to make a second
read-id implementation in spi nand framework.

The second problem only exist in theory, so my preference is to apply
this patch and fix only the first problem for now.

Regards,
Chuanhong Guo

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2019-11-03 12:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16  1:38 [PATCH][RFC] mtd: spinand: fix detection of GD5FxGQ4xA flash Chuanhong Guo
2019-10-28 16:41 ` Miquel Raynal
2019-11-03 12:03   ` Chuanhong Guo [this message]
2019-11-03 13:27     ` Boris Brezillon
2019-11-05 18:20       ` Miquel Raynal

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='CAJsYDVJgwRfg2kfmuG4P-NCEAZ4box+=Yb53d0J+rAjLRpc3Ww@mail.gmail.com' \
    --to=gch981213@gmail.com \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=frieder.schrempf@kontron.de \
    --cc=git-commits@allycomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=sr@denx.de \
    --cc=vigneshr@ti.com \
    /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;
as well as URLs for NNTP newsgroup(s).