linux-kernel - Proposed change to mtd read functions (Was Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo)

Open Source and information security mailing list archives

Date:	Mon, 14 Nov 2011 10:08:45 -0800
From:	Mike Dunn <mikedunn@...sguy.com>
To:	dedekind1@...il.com
CC:	David Woodhouse <dwmw2@...radead.org>,
	Ivan Djelic <ivan.djelic@...rot.com>,
	Robert Jarzmik <robert.jarzmik@...e.fr>,
	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Proposed change to mtd read functions (Was Re: [PATCH v2 07/16] mtd/docg3:
 add OOB layout to mtdinfo)

On 11/13/2011 12:27 PM, Artem Bityutskiy wrote:
> On Sun, 2011-11-13 at 11:55 -0800, Mike Dunn wrote:
>> An objection might be that mtd should not be setting policy.  It's also a fairly
>> sizeable modification.  The alternative would be to implement a mechanism to
>> return the corrected error count to the higher layer (e.g., ubi) for each read
>> operation.  This would be even more work, requiring modifications to mtd and ubi.
> Yeah, probably just returning the ECC correction count is cleaner
> design. Probably we can add another argument to the mtd read function
> and if the return code is -EUCLEAN (correctable bit-flips happened), it
> would contain the highest ECC correction count encountered while reading
> this region of the flash.

This would be better than the cumulative error count over the entire block,
because the highest count on any one page is more significant, I think.

>  So the SW which does not care, will not
> require any changes.
>
> I am not sure if you'll need to mtd interfaces from mtd->func(...) to
> mtd_func(mtd, ...) for this or not, though.

I don't (yet) see why I would need to. 

Just adding the argument to mtd->read(), mtd->read_oob(),  would be a simple
change, but large in scope, affecting all users of the mtd interface.  Any
advice on how to proceed?  Should it be one big patchset, with individual
patches for changes to mtd, nand, one_nand, mtdchar, each driver, ... ?  If it
is not all merged at once, the build will be broken for the unpatched
components.  Or is that acceptable, and the patches can be submitted piecemeal,
starting with, say, mtd, nand, nandsim, mtdram, mtdchar?  Or should we
temporarily create a branch from l2-mtd until we're satisfiled that this is all
stable?

Thanks,
Mike

> Artem.
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>

--
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/

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