On Tue, 2016-06-07 at 07:41 +0200, Boris Brezillon wrote:
On Mon, 06 Jun 2016 18:54:03 -0500 Scott Wood oss@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.