nvmem: Defining cells on mtd created by mtdparts
Sven Eckelmann
sven at narfation.org
Sun Oct 10 05:53:13 PDT 2021
Hi,
OpenWrt switched [1] their MAC address (from flash) retrieval code from their
mtd-mac-address based solution [2] to nvmem-cells. The mtd-mac-address based
solution had the benefit that it could find the correct partition by using
get_mtd_device_nm - which was label based. So a lookup for a partition which
was defined via mtdparts was absolutely no problem. This doesn't seem to be
the case for nvmem - at least not how it is integrated at the moment in
OpenWrt.
This means that the performed switch broke the vendor defined MAC addresses
when the u-boot must dynamically define the partitions via mtdpart - and where
fixed-partitions are not possible in the DT. The bootloaders used by the ath79
usually have no devicetree support and cannot modify the device tree (beside
the problem to get the sources for these bootloaders). These devices will now
only have random mac addresses.
Since there are most likely more devices out there which use mtdparts, I would
guess that there might already be a strategy out there which can be used to
define the nvmem-provider for mtdparts defined partitions. At least I saw that
Bartosz Golaszewski added all the mtd devices automatically as nvmem provider
in c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem
API"). So there might also be something for nvmem-cells to find the correct
mtd instead of relying on the fixed-partitions registration + of_node (which
doesn't exist because it comes from mtdparts and not devicetree).
Right now nvmem_cell_get (actually __nvmem_device_get) in
nvmem_get_mac_address just return -517 (EPROBE_DEFER). So the nvmem_device is
not yet registered - which absolutely makes sense when mtdparts is used.
of_nvmem_find will just not be able to find the of_node for this partition
via bus_find_device_by_of_node because there is no such of_node for mtdparts
partitions.
Kind regards,
Sven
[1] https://github.com/openwrt/openwrt/pull/4041
[2] https://github.com/openwrt/openwrt/commit/5ae2e786395c7f9db0167ebe875be5df9502d8d8
-------------- 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.openwrt.org/pipermail/openwrt-devel/attachments/20211010/cae054f8/attachment-0001.sig>
More information about the openwrt-devel
mailing list