[REQUEST] Review changes for new nvmem patch for dynamic partition
ansuelsmth at gmail.com
Wed Jun 29 13:08:27 PDT 2022
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:
> - 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 . 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,
>  https://firstname.lastname@example.org/#24559755
More information about the openwrt-devel