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/[email protected]/#24559755 -- Ansuel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
