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]
Date:	Wed, 5 Nov 2014 03:40:04 -0800
From:	Brian Norris <computersforpeace@...il.com>
To:	Huang Shijie <shijie8@...il.com>
Cc:	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	David Woodhouse <dwmw2@...radead.org>,
	linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Mike Voytovich <mvoytovich@...pal.com>,
	Roy Lee <roylee@...pal.com>
Subject: Re: [PATCH v4 1/4] mtd: nand: provide detailed description for raw
 read/write page methods

On Sat, Oct 25, 2014 at 11:55:27AM +0800, Huang Shijie wrote:
> On Mon, Oct 20, 2014 at 10:46:14AM +0200, Boris Brezillon wrote:
> > read_page_raw and write_page_raw method description is not clear enough.
> > It clearly specifies that ECC correction should not be involved but does
> > not talk about specific layout (by layout I mean where in-band and
> > out-of-band data are stored on the NAND media) used by NAND/ECC
> > controllers.
> > 
> > Those specific layouts might impact MTD users and thus should be hidden (as
> > already done in the standard NAND_ECC_HW_SYNDROME implementation).
> > 
> > Clearly state this constraint in the nand_ecc_ctrl struct documentation.
> > 
> > Signed-off-by: Boris Brezillon <boris.brezillon@...e-electrons.com>
> > ---
> >  include/linux/mtd/nand.h | 17 +++++++++++++++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index e4d451e..b14d190 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -455,8 +455,21 @@ struct nand_hw_control {
> >   *		be provided if an hardware ECC is available
> >   * @calculate:	function for ECC calculation or readback from ECC hardware
> >   * @correct:	function for ECC correction, matching to ECC generator (sw/hw)
> > - * @read_page_raw:	function to read a raw page without ECC
> > - * @write_page_raw:	function to write a raw page without ECC
> > + * @read_page_raw:	function to read a raw page without ECC. This function
> > + *			should hide the specific layout used by the ECC
> > + *			controller and always return contiguous in-band and
> > + *			out-of-band data even if they're not stored
> > + *			contiguously on the NAND chip (e.g.
> > + *			NAND_ECC_HW_SYNDROME interleaves in-band and
> > + *			out-of-band data).
> > + * @write_page_raw:	function to write a raw page without ECC. This function
> > + *			should hide the specific layout used by the ECC
> > + *			controller and consider the passed data as contiguous
> > + *			in-band and out-of-band data. ECC controller is
> > + *			responsible for doing the appropriate transformations
> > + *			to adapt to its specific layout (e.g.
> > + *			NAND_ECC_HW_SYNDROME interleaves in-band and
> > + *			out-of-band data).
> >   * @read_page:	function to read a page according to the ECC generator
> >   *		requirements; returns maximum number of bitflips corrected in
> >   *		any single ECC step, 0 if bitflips uncorrectable, -EIO hw error
> > -- 
> > 1.9.1
> > 
> thanks for this patch. 
> 
> hi Brian, what's your opinion about this patch?

I like the concept. It might be more succinctly described along the
lines of "the same layout as the non-raw versions (i.e., .read_page /
.write_page)". But the extra words may help for being more explicit.

I haven't taken a closer look at the other patches yet.

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/

Powered by blists - more mailing lists