On Tue, 2016-06-07 at 07:41 +0200, Boris Brezillon wrote: > On Mon, 06 Jun 2016 18:54:03 -0500 > Scott Wood <o...@buserror.net> wrote: > > > Of course the driver model > > is probably the long-term solution. > > Definitely, and talking about things that need to be reworked, do you > know why u-boot is using its own MTD partition infrastructure instead > of relying on mtdpart.c?
U-Boot's partition code predates the importation of the MTD code. > That's really a pain when one wants to add a new feature (like > definitions of partitions in the DT, or SLC mode on MLC NANDs) because > he has to do it twice. Defining partitions in the DT isn't such a great idea, at least on reference boards, as it's configuration that users are likely to want to change. > And that's not the only inconsistent part in the MTD/NAND layer IMO. > MTD is providing a generic abstraction for all flashes, but nand_util > is still directly accessing the NAND layer instead of going through the > MTD abstraction. As with partitions, that code predates the existence of the MTD abstraction in U-Boot. > By using the MTD abstraction everywhere (I mean for all flash devices), > we could provide generic utils (flash erase, flash write), even if > specific tools might be needed in a few cases. There are a lot of special NANDisms being handled in that code (bad block skipping, JFFS2 OOB cleanmarkers, etc), so I wonder what a generic version would look like. > Anyway, good to hear that you plan to switch to the driver model. I don't plan to do much of anything with the NAND code -- I'm still acting as custodian because nobody stepped up when I asked for volunteers to take it over a couple years back, but it's pretty low on my priority list regarding active development[1]. But if someone else wants to DM-ize a NAND driver I have no problem with that. :-) -Scott [1] Linux syncs are an exception, as they're easier to do than to review, especially since a patch only shows the end result rather than the process to produce it. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
