Messages in this thread | | | Subject | Re: Proposed change to mtd read functions (Was Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo) | From | Artem Bityutskiy <> | Date | Mon, 14 Nov 2011 19:38:53 +0200 |
| |
On Mon, 2011-11-14 at 10:08 -0800, Mike Dunn wrote: > 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.
Yeah, although in the previous proposal I also assumed something like that, not "cumulative".
Just a side note - take my suggestions with a grain of salt - I do not actively work on MTD any longer so may mislead you :-)
> > 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?
Add the argument without implementing its support, amend all users and make them compile.
> 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?
We can create a branch regardless, if you find this useful.
I guess one big patch should be OK. If it causes issues we can later think how to split it.
-- Best Regards, Artem Bityutskiy [unhandled content-type:application/pgp-signature] | |