[PATCH v4 0/2] mtd: spi: nor: force mtd name to "nor%d"

[Marek Vasut]

On 9/22/21 9:23 PM, Tom Rini wrote:
> On Wed, Sep 22, 2021 at 09:05:36PM +0200, Marek Behún wrote:
>> On Wed, 22 Sep 2021 20:24:18 +0200
>> Marek Vasut <marex at denx.de> wrote:
>>
>>> On 9/22/21 7:29 PM, Marek Behún wrote:
>>>> (Adding also Tom.)
>>>>
>>>> Hi Patrick, Marek,
>>>>
>>>> I find this either not complete or not needed:
>>>>
>>>> - either you need mtd names to be of this format so that old MTDPARTS
>>>>     config definitions do not need to be changed, i.e. something like
>>>>       CONFIG_MTDPARTS_DEFAULT="nor0:1M(u-boot),0x1000 at 0xfff000(env)"
>>>>     does not work currently, and you want to make it work.
>>>>
>>>>     I find your solution here incomplete because MTDPARTS can also be
>>>>     used to be passed to Linux as mtdparts parameter, but there is no
>>>>     guarantee that the "norN" numbering you are creating in U-Boot will
>>>>     be the same as the one in kernel.
>>>>
>>>> - or it is not needed, because you can remove MTDPARTS definition from
>>>>     the board config entirely and move the information into device tree.
>>>>     In fact this was the main idea behind making the series
>>>>       Support SPI NORs and OF partitions in `mtd list`
>>>>     The SPI-NOR MTDs after this series can have conflicting names,
>>>>     because you can still choose between them via OF path with the `mtd`
>>>>     command.
>>>>
>>>>     Tom and I were of the opinion that MTDPARTS should be deprecated and
>>>>     removed in favor of OF. Marek Vasut says that this is not possible
>>>>     for every board, and so needs to stay.
>>>>
>>>> BTW, I find it a little weird for Marek to defend old API which should
>>>> be converted to DT, when in discussion about DM USB / Nokia N900
>>>> USB TTY console [1] he was defending the opinion that we should be
>>>> heading to DT in U-Boot.
>>>>
>>>> [1]
>>>> https://patchwork.ozlabs.org/project/uboot/patch/20210618145724.2558-1-pali@kernel.org/
>>>
>>> That USB discussion is completely unrelated to the problem here, the USB
>>> discussion is about internal (i.e. not user facing) conversion to DM/DT.
>>> The user-facing ABI does not change there. Also, that discussion was
>>> about patching USB stack to permit new non-DM/DT operation, not fixing
>>> existing one.
>>
>> This is not only about the user ABI (altough now I agree that you are
>> correct there, see below). What I meant is this:
>>    Should we push for converting to device-tree even if for some boards
>>    it is not possible, and would mean removing them?
>>
>>    Because you are saying that MTDPARTS cannot be converted to DT for
>>    some boards.
>>
>>    But N900 also cannot be reasonably converted because of space
>>    issues, as far as I understood. Yes, it has gigabytes of eMMC storage,
>>    and it was proposed to put SPL in MTD and U-Boot proper into eMMC on
>>    VFAT/ext4, but this simply cannot be done reasonably, because:
>>    - it would break Linux userspace (existing OS upgrade system would
>>      have to be rewritten and backwords compatibility would be broken)
>>    - it would make bootstrapping (booting newer version of U-Boot) while
>>      developing U-Boot a pain in the ass or maybe even impossible
>>    - I beleive there was some other reason Pali mentioned, but I cannot
>>      remember anymore
>>
>>> This problem here is user facing ABI, the mtdparts/mtdids. That user
>>> facing ABI got broken. Boards which do depend on it, even those
>>> currently in tree, are broken. Not all boards can update their
>>> environment, so some backward compatibility of the user facing ABI
>>> should be in place, even though it might not be to the degree Linux
>>> kernel does so. So far, it seems most of the U-Boot command line
>>> interface has managed to retain backward compatibility, I don't see why
>>> this here should be handled any differently.
>>
>> OK, I get that the if `mtd nor0` was working before, it should work also
>> now. But the conversion from MTDPARTS to device tree could be probably
>> done for lots of these, see below.
>>
>>> Note that there are not just a few boards that are broken, but hundreds.
>>> I believe that itself justifies a fix, instead of just throwing all
>>> those hundreds of boards overboard.
>>>
>>> u-boot$ git grep -l CONFIG_MTDIDS configs | wc -l
>>> 203
>>
>> Only 96 of those also grep the substring "nor". But okay, that is still
>> a lot. The question is how many of them could be rewritten to DT:
>>
>>    for cfg in $(git grep -l 'CONFIG_MTDIDS.*nor[0-9]' configs); do
>>      fgrep CONFIG_DEFAULT_DEVICE_TREE "$cfg"
>>    done | wc -l
>>
>> 92 of those 96 have CONFIG_DEFAULT_DEVICE_TREE defined.
>>
>> Of these, 65 contain CONFIG_DM_SPI_FLASH=y, so at least these 65 could
>> be converted. Of the rest 27, how many could also be converted to DM?
>> How may use non-DM drivers?
> 
> I was thinking maybe we have problems with the platforms that "mtdparts
> default", of which we have a handful and most of that handful also do it
> to then make use of the partition table within U-Boot (dfu, or update
> the on-flash U-Boot).  Of those, it might make most sense to poke the
> maintainer directly on how to proceed.

I have a feeling you are talking about a different problem here.

What is broken is U-Boot only look up of MTD device from which to attach 
e.g. UBI or jffs2. That's MTDIDS. There you have that nor0 stuff, see:
cmd/jffs2.c: * mtdids=nor0=edb7312-nor,nand0=edb7312-nand
That is what currently does not work in U-Boot, it has nothing to do 
with Linux.