Re: wl1251: NVS firmware data

Ming Lei
2014-11-27T14:21:50Z

On Thu, Nov 27, 2014 at 10:06 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> Hello,
>
> wifi driver wl1251 needs NVS calibration data for working. These
> data are loaded by driver via request_firmware from userspace
> file: ti-connectivity/wl1251-nvs.bin. In linux-fimrware git tree
> there is generic wl1251-nvs.bin file which is used by default.
>
> Driver wl1251 is used on Nokia N900 cellphone for its wifi chip.
> This cellphone has one special MTD partition (called CAL) where
> are stored some configuration data in special binary (key-value)
> format. And there is also stored correct calibration data for
> specific device (each device has different data). It is preferred
> to use those data instead generic one (provided by linux-firmware
> git tree).
>
> Now my question is: How to correctly load calibration data from
> special Nokia N900 CAL partition into wl1251 kernel driver?

It is better to let user space script handle the request.

>
> By default kernel reads ti-connectivity/wl1251-nvs.bin file from
> VFS if exists without any userspace support. If it fails then it
> fallback to loading via udev.

You can remove or rename this file so that loading from user space
can be triggered.

>
> Reading correct data from CAL partition is not easy (structure is
> difficult), but there is open source program which can parse CAL
> partition and write NVS data to stdout. So adding this CAL parser
> into kernel is not good idea (program is GPLv3+ code --
> incompatible with kernel).
>
> So how to solve this problem? How to load correct NVS data from
> CAL partition into wl1251 driver?
>
> It is possible to tell kernel to use some helper userspace
> program for loading data and if it fails then fallback to direct
> loading? E.g first try to use model specific data and if it fails
> for some reasons then fallback to reading genetic data.

One solution is to introduce request_firmware_user() and let
this API handle your case, but CONFIG_FW_LOADER_USER_HELPER
has to be enabled.

If request_firmware_user() fails, request_firmware_direct() can be
tried further.

Thanks,
Ming Lei