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

[Christian Marangi]

On Wed, Jun 29, 2022 at 09:57:53PM +0200, Sven Eckelmann wrote:
> 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.
>

I see, you are right. The main problem is that get_mac_ascii can't be
provided with nvmem. Wonder if we have an alternative solution to split mac
patching with precal extraction.

> Kind regards,
> 	Sven
> 
> [1] https://patchwork.kernel.org/project/linux-wireless/patch/20211016234609.1568317-1-chunkeey@gmail.com/#24559755



-- 
	Ansuel