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

[Marek Vasut <marex@denx.de>]

On 9/25/21 2:12 AM, Marek Behún wrote:
> On Fri, 24 Sep 2021 22:09:15 +0200
> Marek Vasut <marex@denx.de> wrote:
> 
>> I have a feeling the discussion is again banking toward "mtdparts" and
>> "DT", which really is a solved problem, or at least we agreed upon the
>> solution.
> 
> I was trying to explain to Patrick how he can convert the ST board so
> that the mtd partitions will be defined in DT and board code won't need
> mtdids if he also converts to distro boot correctly.
> 
>> The patch is trying to fix MTDIDS and their look up in
>> get_mtd_device_nm(). This is all U-Boot stuff, it has nothing to do with
>> passing mtd partitions to Linux at all.
> 
> The solution here is to get rid of MTDIDS also. But I guess this will
> take some time, so it does make sense for get_mtd_device_nm() to
> return the same device as previously when given argument "norN".

I'd say MTDIDS is user ABI, so we shouldn't break it until there is 
clear way forward. (yes, I agree with pretty much all you are saying, I 
just want to make this clear)

> The reason why I put SPI NOR name into mtd->name was because otherwise
> the `mtd list` command did not print that name anywhere (since it
> doesn't know how, because that SPI-NOR data are private for the
> jedec_spi_nor driver).
> 
> Since
> - every mtd device has mtd->type, for NOR flash this is MTD_NORFLASH
> - we can iterate mtd devices in order they were registered
>    (mtd_for_each_device does this)
> we can easily implement a function
>    get_mtd_device_by_type_and_id()

No, we cannot. We have to make sure the Parallel NORs go first, SPI NORs 
second, otherwise we break the old ABI. That's what Patrick is valiantly 
battling here.

> that, when given string "norN" will find the N-th mtd device of type
> MTD_NORFLASH.
> 
> This function could than be called from get_mtd_device_nm() if
> everything failed, or in some other way.
> 
> Tom, Marek, Patrick, what do you think?

Maybe we should go with a simpler counting approach first (at least for 
this release) and then improve on that ? That would give us some time to 
think the solution through ... at which point I wouldn't even be opposed 
to passing full DT path to ubi part, something like:

ubi part /soc/controller@0x1234/flash@0/partition@1

or something like that. The above is always stable and unique because it 
is hardware path, it does get flushed right down to get_mtd_device_nm(), 
and it basically skips MTDIDS. With DT aliases you can probably write 
some shorthand for a long HW path.