On Wed 17 May 05:53 PDT 2017, Pali Roh?r wrote:

On Wednesday 17 May 2017 14:06:06 Johannes Berg wrote:

quoted

On Tue, 2017-05-16 at 01:13 +0200, Luis R. Rodriguez wrote:

quoted

quoted

quoted

Now for N900 case there is a similar scenario
alhtough it has additional requirement to go to user-space due to
need to use a proprietary library to obtain the NVS calibration
data. My thought: Why should firmware_class care?

Agreed.

In fact, why should the *driver* care either? IOW - why should
"request_firmware_prefer_user()" even exist?

There are default/example NVS data, which are stored in /lib/firmware
and installed by linux-firmware package. Those example calibration data
should not be used for real usage, but Pavel told us that on N900 they
are enough for working WIFI connection. They does not contain valid MAC
address, so kernel should generate some (random?).

So kernel driver should get NVS calibration data from userspace (which
know how where to get or how to prepare them) and in case userspace do
not have it, then we can try fallback to those example data (as people
reported us they can be useful instead of non-working WIFI).

We're going to see a similar case with the Qualcomm DB410c WiFi soon,
where there is default calibration for the chip (wcn3620) but specific
calibration data for the particular board or product using this chip.

As with your case we expect to have a "generic" calibration file
integrated in linux-firmware, but providing means to supporting
device-specific calibration is probably going to be requested shortly.


We have however altered the reference design of picking the MAC address
from the calibration data and have the bootloader pass it via DT - so
our calibration data doesn't need to be specific to each unit.

Regards,
Bjorn