On 28/10/2021 13:52, Kalle Valo wrote:
v1 -> v2:
- use %zu and %u in the format string for size_t
and u32 types (catched by the "kernel test robot").
- reworded commit message + successfully tested on QCA9880v2
I placed the nvmem code in front of the current "file" method
(firmware_request). Reason is that this makes it easier for me
to test it. If needed it can be moved to a different place.
Looks good to me. Before I apply this, I want to mention to that I have
had a long in my deferred queue related two patchsets:
https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-1-ansuelsmth@xxxxxxxxx/
https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-2-ansuelsmth@xxxxxxxxx/
Oh ok, serves me right for not looking thoroughly googling this first.
Alban Bedel and Ansuel's work made this nvmem all possible. And indeed,
the second patch here looks eerie similar.
Do you want to go with his two patches instead?
I would prefer to take your patch.
Ok.
I'll change mine, so it just consists of the cal_mode for the older
QCA9880v2,QCA9887 and add the -EPROBE_DEFER handling. This
-EPROBE_DEFER only ever comes up with the Meraki gear. This is because
Meraki likes putting the MACs-Values into SoC-connected AT24
eeproms-chips. Everyone else just have them in a proper FLASH
partition. Though, this's usually nothing more than adding the
following line:
if (ret == -EPROBER_DEFER)
return ret;
So I'll drop this version and wait for v3?
I guess that "waiting for v3" won't be necessary in this case.
If @Ansuel doesn't voice any concerns, you might as well just
apply v2.
The "[1/2] ath10k: Try to get mac-address from dts" patch
will need a respin, so it can apply cleanly.
Is Anyone interested? If not, I can take a shot at it on Saturday.
(There's the tiny question of that device_get_mac_address() which
ath10k currently uses. It looks a lot like of_get_mac_address() too!
but with extra ACPI (through FWNODE-which also includes OF), but
without NVMEM.)
Cheers,
Christian
