From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
"dwmw2@infradead.org" <dwmw2@infradead.org>
Cc: Richard Weinberger <richard@nod.at>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marek Vasut <marek.vasut@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v3 3/4] mtd: rawnand: micron: add fixup for ONFI revision
Date: Thu, 21 Jun 2018 09:14:51 +0200 [thread overview]
Message-ID: <20180621091451.1a0226de@bbrezillon> (raw)
In-Reply-To: <5e3b8f2f896f44aaab97086dceb2a69b@svr-chch-ex1.atlnz.lc>
On Wed, 20 Jun 2018 21:12:02 +0000
Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:
> On 20/06/18 19:54, Boris Brezillon wrote:
> > On Wed, 20 Jun 2018 17:05:43 +1200
> > Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
> >
> >> Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
> >> revision number field of the ONFI parameter page. Rather than rejecting
> >> these outright assume ONFI version 1.0 if the revision number is 00 00.
> >>
> >> Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> >> ---
> >> This is now qualified on vendor == MICRON. I haven't qualified this
> >> based on specific chips the ABAFA (id=d1) and ABBFA (id=a1) variants are
> >> documented to have this behaviour.
> >>
> >> Changes in v2:
> >> - use fixup_onfi_param_page
> >> Changes in v3:
> >> - add code comment next to workaround
> >>
> >> drivers/mtd/nand/raw/nand_micron.c | 13 +++++++++++++
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
> >> index 5ec4c90a637d..5cec79372181 100644
> >> --- a/drivers/mtd/nand/raw/nand_micron.c
> >> +++ b/drivers/mtd/nand/raw/nand_micron.c
> >> @@ -289,6 +289,19 @@ static int micron_nand_init(struct nand_chip *chip)
> >> return 0;
> >> }
> >>
> >> +static void micron_fixup_onfi_param_page(struct nand_chip *chip,
> >> + struct nand_onfi_params *p)
> >> +{
> >> + /*
> >> + * MT29F1G08ABAFAWP-ITE:F and possibly others report 00 00 for the
> >> + * revision number field of the ONFI parameter page. Assume ONFI
> >> + * version 1.0 if the revision number is 00 00.
> >> + */
> >> + if (le16_to_cpu(p->revision) == 0)
> >> + p->revision = cpu_to_le16(1 << 1);
> >
> > Would be better to have macros defining all version numbers in rawnand.h
> >
> > #define ONFI_VERSION_1_0 BIT(1)
> > #define ONFI_VERSION_2_0 BIT(2)
> > #define ONFI_VERSION_2_1 BIT(3)
> > #define ONFI_VERSION_2_2 BIT(4)
> > #define ONFI_VERSION_2_3 BIT(5)
> > #define ONFI_VERSION_3_0 BIT(6)
> > #define ONFI_VERSION_3_1 BIT(7)
> > #define ONFI_VERSION_3_2 BIT(8)
> > #define ONFI_VERSION_4_0 BIT(9)
> >
>
> Make sense. Do you want me to do so in a v4 or send a new patch and
> clean up the other uses?
It can be part of your v4, but yes, the idea is to first introduce the
macros and patch existing users, and then use it in this patch.
next prev parent reply other threads:[~2018-06-21 7:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 5:05 [PATCH v3 0/4] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F Chris Packham
2018-06-20 5:05 ` [PATCH v3 1/4] mtd: rawnand: marvell: Handle on-die ECC Chris Packham
2018-06-20 7:46 ` Boris Brezillon
2018-06-20 21:10 ` Chris Packham
2018-06-20 5:05 ` [PATCH v3 2/4] mtd: rawnand: add manufacturer fixup for ONFI parameter page Chris Packham
2018-06-20 7:49 ` Boris Brezillon
2018-06-20 5:05 ` [PATCH v3 3/4] mtd: rawnand: micron: add fixup for ONFI revision Chris Packham
2018-06-20 7:54 ` Boris Brezillon
2018-06-20 21:12 ` Chris Packham
2018-06-21 7:14 ` Boris Brezillon [this message]
2018-06-20 5:05 ` [PATCH v3 4/4] mtd: rawnand: micron: support 8/512 on-die ECC Chris Packham
2018-06-20 8:02 ` Boris Brezillon
2018-06-20 22:22 ` Chris Packham
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=20180621091451.1a0226de@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
/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).