linux-kernel - Re: [PATCH v4 2/5] mtd: nand: Qualcomm NAND controller driver

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] [day] [month] [year] [list]

Message-ID: <20151218194836.6f04a6e6@bbrezillon>
Date:	Fri, 18 Dec 2015 19:48:36 +0100
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	Archit Taneja <architt@...eaurora.org>
Cc:	dehrenberg@...gle.com, cernekee@...il.com, sboyd@...eaurora.org,
	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
	linux-arm-msm@...r.kernel.org, computersforpeace@...il.com,
	agross@...eaurora.org
Subject: Re: [PATCH v4 2/5] mtd: nand: Qualcomm NAND controller driver

Hi Archit,

On Thu, 17 Dec 2015 15:18:46 +0530
Archit Taneja <architt@...eaurora.org> wrote:

> 
> >
> > Note that you could put the oobfree area at the end of the OOB area,
> > since this 10-10-10-16-10 representation is already a virtual
> > representation of the OOB area (ECC bytes are actually interleaved with
> > in-band data on the flash).
> 
> But, when I read from the controller's internal buffer via DMA, I first
> get the oobfree area, and only then the last step's ECC bytes. So, the 
> content in chip->oob_poi is in the same order as mentioned
> above (10-10-10-16-10).
> 
> If the upper layers uses MTD_OPS_AUTO_OOB, and if I have a different
> layout as what it is in the oob_poi buffer, then it'll end up
> reading/writing the wrong bytes in nand_transfer_oob/nand_fill_oob.
> 
> Are you suggesting that I modify the contents of oob_poi by hand such
> that it has a cleaner 10-10-10-10-16 representation?

Hm, I thought you could just place the free oob bytes wherever you want
since there's only one oobfree region. AFAICS, it's just a matter of
passing ->oob_poi + 40 instead of passing ->oob_poi + 30 when preparing
the DMA descriptor (30 and 40 are just numbers for this specific use
case).
Anyway, I won't complain if you address all comments but this one.

Best Regards,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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/