Re: [REQUEST] Review changes for new nvmem patch for dynamic partition
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-chunk...@gmail.com/#24559755 -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [REQUEST] Review changes for new nvmem patch for dynamic partition
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-chunk...@gmail.com/#24559755 signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [REQUEST] Review changes for new nvmem patch for dynamic partition
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. > But I am currently not 100% sure why cmdline is so special here. cmdline is so special because it does have priority against any parser. We had a hack patch to support nvmem with device that used cmdlinepart but this is now dropped as we have an upstream solution. > > Kind regards, > Sven -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [REQUEST] Review changes for new nvmem patch for dynamic partition
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'". But I am currently not 100% sure why cmdline is so special here. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[REQUEST] Review changes for new nvmem patch for dynamic partition
Hi, Finally a correct solution for providing nvmem cells with dynamic partition (partition from cmdline, smem, other parser...) has been merged in mtd-next. 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. This way the new patch works just as the old cmdlinepart nvmem hack patch. I would ask for some testing and if someone can check if I did some mistake in some dts file that got converted to the new partition node name format. This is the PR https://github.com/openwrt/openwrt/pull/10153 -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
