From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1758958AbdACNeG convert rfc822-to-8bit (ORCPT <rfc822;w@1wt.eu>);
        Tue, 3 Jan 2017 08:34:06 -0500
Received: from mail.free-electrons.com ([62.4.15.54]:32814 "EHLO
        mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1758845AbdACNcG (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 3 Jan 2017 08:32:06 -0500
Date: Tue, 3 Jan 2017 14:32:01 +0100
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Icenowy Zheng <icenowy@aosc.xyz>
Cc: Richard Weinberger <richard@nod.at>,
        "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
        David Woodhouse <dwmw2@infradead.org>,
        Brian Norris <computersforpeace@gmail.com>,
        Marek Vasut <marek.vasut@gmail.com>,
        Cyrille Pitchen <cyrille.pitchen@atmel.com>,
        "Valdis.Kletnieks@vt.edu" <valdis.kletnieks@vt.edu>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 14/15] mtd: nand: hynix: rework NAND ID decoding to
 extract more information
Message-ID: <20170103143201.14fcf294@bbrezillon>
In-Reply-To: <3073151483449433@web27m.yandex.ru>
References: <1483448495-31607-1-git-send-email-boris.brezillon@free-electrons.com>
        <1483448495-31607-15-git-send-email-boris.brezillon@free-electrons.com>
        <3073151483449433@web27m.yandex.ru>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 03 Jan 2017 21:17:13 +0800
Icenowy Zheng <icenowy@aosc.xyz> wrote:

> 03.01.2017, 21:01, "Boris Brezillon" <boris.brezillon@free-electrons.com>:
> > The current NAND ID detection in nand_hynix.c is not handling the
> > different scheme used by Hynix, thus forcing developers to add new
> > entries in the nand_ids table each time they want to support a new MLC
> > NAND.
> >
> > Enhance the detection logic to handle all known formats. This does not
> > necessarily mean we are handling all the cases, but if new formats are
> > discovered, the code should evolve to take them into account instead of
> > adding more full-id entries in the nand_ids table.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> >  drivers/mtd/nand/nand_hynix.c | 228 ++++++++++++++++++++++++++++++++++++++----
> >  1 file changed, 209 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/nand_hynix.c b/drivers/mtd/nand/nand_hynix.c
> > index 06c8e8b0ec68..a35ca3a593f5 100644
> > --- a/drivers/mtd/nand/nand_hynix.c
> > +++ b/drivers/mtd/nand/nand_hynix.c
> > @@ -13,21 +13,56 @@
> >   */
> >

[...]

> > + switch (oobsize) {
> >                  case 0:
> >                          mtd->oobsize = 128;
> >                          break;
> > @@ -46,23 +81,178 @@ static void hynix_nand_decode_id(struct nand_chip *chip)
> >                  case 5:
> >                          mtd->oobsize = 16;
> >                          break;
> > - default:
> > + case 6:
> >                          mtd->oobsize = 640;
> >                          break;
> > + default:
> > + /*
> > + * We should never reach this case, but if that
> > + * happens, this probably means Samsung decided to use  
> 
> Is this "Samsung" a copy-n-paste error? ;-)

Indeed, and this is not the only place where I'm wrongly mentioning
Samsung. I'll fix that.

Thanks,

Boris