From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Fri, 6 Jul 2018 15:51:35 +0200 Subject: [U-Boot] [RFC PATCH 17/20] cmd: mtd: add 'mtd' command In-Reply-To: <20180706154217.77507999@xps13> References: <20180606153040.21397-1-miquel.raynal@bootlin.com> <20180606153040.21397-18-miquel.raynal@bootlin.com> <20180706142649.22a2dc93@xps13> <201a9342-c330-a882-3e48-d53b74b6cef1@denx.de> <20180706154217.77507999@xps13> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Miquel, On 06.07.2018 15:42, Miquel Raynal wrote: > Hi Stefan, > > Stefan Roese wrote on Fri, 6 Jul 2018 15:21:20 +0200: > >> Hi Miquel, >> >> On 06.07.2018 14:26, Miquel Raynal wrote: >>> Jagan Teki wrote on Fri, 6 Jul 2018 17:08:57 >>> +0530: >>>>> On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal wrote: >>>>> There should not be a 'nand' command, a 'sf' command and certainly not >>>>> another 'spi-nand'. Write a 'mtd' command instead to manage all MTD >>>>> devices at once. This should be the preferred way to access any MTD >>>>> device. >>>> >>>> So are you planning to integrate sf, nand command in future, adding >>>> them dm conversion of many stuff. I would like to reommend to go with >>>> spinand command. I have been through this and finally added spinor >>>> command, which I will going to in soon. once all are converted to dm, >>>> it would be easy and meaningfull to have common command. >>>> I'm not sure we are in sync about this. The whole point of the previous >>> discussion was to decide whether or not we should make full use of >>> the MTD stack or not. I think it was pretty clear on the fact that >>> people prefer to be close to Linux's architecture on this regard. >>>> MTD being an abstraction of the type of memory, I don't get the >>> point in creating yet another command each time a new type of >>> device is supported. The fact that all the drivers of these devices >>> register to the MTD layer makes it trivial to interact with. So why >>> should we wait? >> >> Yes, please don't add new commands for each subsystem / device-type. >> I like the idea of adding one new command-set (your mtd command) and >> extending this one to all other device-types over the time. >> >> BTW: I'm testing your SPI NAND patches right now (still struggling >> with some Gigadevice SPI NAND) and found that the "mtd" command is >> not really in-line with the usual U-Boot commands. Here some >> comments: >> >> - Use hex values per default (addresses, sizes and soffset) >> - "mtd read" just prints the read values. It makes more sense >> to read into memory instead (similar to the "mtd write") > > I absolutely agree with this! I sent this series to show people what I > planned to contribute but this mtd command is still a WIP and there are > plenty of things to address. > >> >> I have some patches to address these issues in the queue (still >> need some massaging), which you can fold into your patchset, once >> we agree on this. > > I am currently working on a new iteration of this series in which the > mtd.c file will change quite a bit. I plan to send a new version early > next week. I suppose this one will be much more stable to base your > fixes/enhancements on. That sound really great. Looking forward to seeing the new version next week. :) Thanks, Stefan