Re: wl1251 & mac address & calibration data

[Kalle Valo]

Arend Van Spriel <arend.vanspriel@xxxxxxxxxxxx> writes:

> On 18-12-2016 13:09, Pali RohÃr wrote:
>
>> File wl1251-nvs.bin is provided by linux-firmware package and contains 
>> default data which should be overriden by model specific calibrated 
>> data.
>
> Ah. Someone thought it was a good idea to provide the "one ring to rule
> them all". Nice.

Yes, that was a bad idea. wl1251-nvs.bin in linux-firmware.git should be
renamed to wl1251-nvs.bin.example, or something like that, as it should
be only installed to a real system only if there's no real calibration
data available (only for developers to use, not real users).

>> But overwriting that one file is not possible as it next update of 
>> linux-firmware package will overwrite it back. It break any normal usage 
>> of package management.
>> 
>> Also it is ridiculously broken by design if some "boot" files needs to 
>> be overwritten to initialize hardware properly. To not break booting you 
>> need to overwrite that file before first boot. But without booting 
>> device you cannot read calibration data. So some hack with autoreboot 
>> after boot is needed.

Providing the calibration data via Device Tree is the proper way to
solve this. Yes yes, I know N900 doesn't support it but that's a
deficiency in N900, not Linux.

>> And how to detect that we have real overwritten calibration data and
>> not default one from linux-firmware? Any heuristic or checks will be
>> broken here. And no, nothing like you need to reboot your device now
>> (and similar concept) from windows world is not accepted.
>
> Well. After reading and creating calibration data you could just rebind
> the driver to the device to have it probed again.

Or load wl1251 as a module and make sure calibration data is installed
before the module is loaded. LEDE does that with ath10k:

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata;h=97875bd79a579a0010da3f60324b6ec966fe9c6a;hb=HEAD

> But yeah, the default one from linux-firmware should never have been
> there in the first place.

Agreed.

-- 
Kalle Valo