[U-Boot] [RFC PATCH 17/20] cmd: mtd: add 'mtd' command

[Stefan Roese]

Hi Miquel,

On 06.07.2018 15:42, Miquel Raynal wrote:
> Hi Stefan,
> 
> Stefan Roese <sr at denx.de> wrote on Fri, 6 Jul 2018 15:21:20 +0200:
> 
>> Hi Miquel,
>>
>> On 06.07.2018 14:26, Miquel Raynal wrote:
>>> Jagan Teki <jagannadh.teki at gmail.com> wrote on Fri, 6 Jul 2018 17:08:57
>>> +0530:
>>>>> On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal <miquel.raynal at bootlin.com> 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