[U-Boot] [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver

[Scott Wood <oss@buserror.net>]

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.