[REQUEST] Review changes for new nvmem patch for dynamic partition

[Sven Eckelmann]

On Wednesday, 29 June 2022 21:37:43 CEST Christian Marangi wrote:
> On Wed, Jun 29, 2022 at 09:32:14PM +0200, Sven Eckelmann wrote:
> > On Wednesday, 29 June 2022 18:33:53 CEST Christian Marangi wrote:
> > [...]
> > > A node name change is required for the new patch to work. Since we are
> > > not aware of device that use cmdline as partition parser, I converted
> > > each device that use nvmem-cells to the new format.
> > 
> > I am not 100% if you reference here the mtdparts from cmdline or something 
> > else. If the former is the case then please perform a
> > "git grep 'partitions are passed via bootloader'".
> >
> 
> Problem is that it's not that easy... I notice that comment on some
> ipq40xx dts but many ath79 device have fixed-partition defined and still
> use cmdlinepart with no comments about it... guess how we discovered that
> when the nvmem migration was done.

Ah, I think you meant "we are not always aware whether a device uses cmdline
as partition parser" and not "we are not aware of device that use cmdline as 
partition parser". At least this would make more sense here.

Other question regarding the changes in 11-ath10k-caldata: You've dropped the 
caldata_extract in various places which would usually copy the pre-cal (or 
cal) data from the ART partition to /lib/firmware/$FIRMWARE. But I see in 
various places that there are things like ath10k_patch_mac still in there. 
Take for example linksys,ea8500:


 	linksys,ea8500)
-		caldata_extract "art" 0x5000 0x2f20
 		ath10k_patch_mac $(macaddr_add $(mtd_get_mac_ascii devinfo hw_mac_addr) 2) 
		;;

I thought that a "pre-calibration" nvmem-cell would then be used by ath10k to 
get the (pre-)cal data [1]. So it doesn't make a lot of sense to me that there 
is now still a ath10k_patch_mac which tries to operate on 
/lib/firmware/$FIRMWARE (which should not exist). The script section shouldn't 
be called in the first place because the "pre-calibration" nvmem-cell has a 
higher priority in ath10k, right? I can also see the changes
to qcom-ipq8064-eax500.dtsi but no mac address fix.

Kind regards,
	Sven

[1] https://patchwork.kernel.org/project/linux-wireless/patch/20211016234609.1568317-1-chunkeey@gmail.com/#24559755
-------------- 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/20220629/6b9662bf/attachment.sig>