nvmem: Defining cells on mtd created by mtdparts

[Sven Eckelmann]

On Tuesday, 12 October 2021 20:24:46 CEST Pratyush Yadav wrote:
[...]
> I have been wanting to fix this problem for a while but just never got 
> around to it. I was thinking about either extending the mtdparts syntax 
> to maybe add nvmem cell information in there or adding a separate 
> cmdline argument that complements mtdparts with nvmem cell info. Dunno 
> if either of these would work well though...

At least for the devices I have in mind, this doesn't seem to be a good 
solution. The devices are shipped since years and the bootloader isn't updated 
with firmware updates. So changing to a different mtdparts might sometimes not 
be easily possible.

But this might help in situations which don't have this limitation.

> > Ansuel Smith just proposed in OpenWrt [1] a workaround. It basically adds a 
> > minimal fixed-partitions parser to the mtd cmdlinepart parser (responsible for 
> > the mtdparts=) that tries to find the matching (size + offset) fixed-partition 
> > from the devicetree. The code in mtd_device_parse_register
> > (add_mtd_partitions -> add_mtd_device -> mtd_nvmem_add) will then 
> > automatically take care of the rest.
> 
> I don't quite see how this helps. You say that some devices don't have a 
> device tree at all so how would you even match the fixed partition? And 
> this of course doesn't solve the problem where you might want nvmem 
> cells with a partition layout that is different from the one in device 
> tree.

I personally had a different thing in mind. The situation for OpenWrt's ath79 
target (and Linux's ath79) is that they use DTs and some of these devices are 
still using some information which are not part of the device tree. But the
DT partitions for the nvmem-cells MUST match the ones in mtdparts

But you are right, this will definitely not solve situations when there is no 
DT used. And didn't say that I needed a solution for this - I was (hopefully) 
always referring to devices which use mtdparts (which can also be used with 
devices which are using DTs)

Kind regards,
	Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20211012/77510863/attachment.sig>