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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 5207 bytes --]

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@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@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]