linux-kernel - RE: [PATCH] mtd: increase max page/OOB size to support 16K pagesize NAND

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: <C3050A4DBA34F345975765E43127F10F25E47537@SZXEMA512-MBX.china.huawei.com>
Date:	Fri, 13 Dec 2013 11:10:10 +0000
From:	Caizhiyong <caizhiyong@...ilicon.com>
To:	Brian Norris <computersforpeace@...il.com>
CC:	David Woodhouse <dwmw2@...radead.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	David Woodhouse <David.Woodhouse@...el.com>,
	Quyaxin <quyaxin@...ilicon.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Huang Shijie <b32955@...escale.com>,
	"Artem Bityutskiy" <artem.bityutskiy@...ux.intel.com>,
	"Wanglin (Albert)" <albert.wanglin@...ilicon.com>
Subject: RE: [PATCH] mtd: increase max page/OOB size to support 16K pagesize
 NAND

> On Fri, Dec 13, 2013 at 05:03:49AM +0000, Caizhiyong wrote:
> > From: Cai Zhiyong <caizhiyong@...wei.com>
> > Date: Fri, 13 Dec 2013 12:52:46 +0800
> > Subject: [PATCH] mtd: increase max page/OOB size to support 16K pagesize NAND.
> >
> > The Toshiba's TC58TEG5DCJTA pagesize is 16K, oob size is 1280 bytes.
> > So increase the NAND_MAX_OOBSIZE and NAND_MAX_PAGESIZE.
> 
> It would help if we had nand_base/nand_ids support for TC58TEG5DCJTA
> before we try to increase NAND_MAX_PAGESIZE and NAND_MAX_OOBSIZE yet
> again. AFAICT, nand_base will not detect new, large Toshiba flash
> properly anyway.

There are a lot of 16K page size NAND, they are used in android system.

Many NAND need read retry and data randomization, kernel does not support this feature.
Kernel also does not support synchronous NAND.
As you know, is someone doing some work to support those feature now?

If Kernel support TC58TEG5DCJTA, the read retry and data randomization also
need be supported, it will be a big project.

> 
> > Signed-off-by: Cai Zhiyong <caizhiyong@...wei.com>
> > ---
> >  include/linux/mtd/nand.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index f3ea8da..2f0a7f2 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -56,8 +56,8 @@ extern int nand_unlock(struct mtd_info *mtd, loff_t ofs,
> uint64_t len);
> >   * is supported now. If you add a chip with bigger oobsize/page
> >   * adjust this accordingly.
> >   */
> > -#define NAND_MAX_OOBSIZE	744
> > -#define NAND_MAX_PAGESIZE	8192
> > +#define NAND_MAX_OOBSIZE	1280
> > +#define NAND_MAX_PAGESIZE	16384
> 
> It might be time to draw a line in the sand: next person who needs to
> increase MAX_{PAGE,OOB}SIZE gets the job of killing the macro? We are
> long overdue for dynamic buffer allocation.
> 
> There are two drivers that use the macros, plus nand_chip.buffers.*. The
> drivers can be weaned off by allocating a small, fixed-size temporary
> buffer for the few tasks that need it. With nand_base.c, I think we can
> get by with waiting to allocate nand_chip.buffers until after we detect
> the writesize/oobsize.
> 
> So Cai, are you up for this?

Ok, I will try update it.

> 
> >
> >  /*
> >   * Constants for hardware specific CLE/ALE/NCE function
> >
> 
> Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/