From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Wed, 08 Jun 2016 19:44:35 -0500 Subject: [U-Boot] [PATCH 3/6] mtd: nand: Add the sunxi NAND controller driver In-Reply-To: <20160607074155.0020e237@bbrezillon> References: <1465226478-22252-1-git-send-email-boris.brezillon@free-electrons.com> <1465226478-22252-4-git-send-email-boris.brezillon@free-electrons.com> <31991e89-53e0-0d9c-c643-241c6f8e8d51@redhat.com> <20160606182223.1636b0df@bbrezillon> <1465235808.22191.86.camel@buserror.net> <20160606203133.07e61264@bbrezillon> <1465257243.22191.97.camel@buserror.net> <20160607074155.0020e237@bbrezillon> Message-ID: <1465433075.22191.117.camel@buserror.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 2016-06-07 at 07:41 +0200, Boris Brezillon wrote: > On Mon, 06 Jun 2016 18:54:03 -0500 > Scott Wood 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.