linux-kernel - Re: wl1251 & mac address & calibration data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 16 Dec 2016 11:26:55 +0100
From:   Pali Rohár <pali.rohar@...il.com>
To:     Arend Van Spriel <arend.vanspriel@...adcom.com>
Cc:     Kalle Valo <kvalo@...eaurora.org>,
        Sebastian Reichel <sre@...nel.org>,
        Pavel Machek <pavel@....cz>,
        Michal Kazior <michal.kazior@...to.com>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Tony Lindgren <tony@...mide.com>,
        "linux-wireless" <linux-wireless@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        "Luis R. Rodriguez" <mcgrof@...nel.org>
Subject: Re: wl1251 & mac address & calibration data

On Thursday 15 December 2016 21:12:47 Arend Van Spriel wrote:
> On 15-12-2016 16:33, Pali Rohár wrote:
> > On Thu Dec 15 09:18:44 2016 Kalle Valo <kvalo@...eaurora.org> wrote:
> >> (Adding Luis because he has been working on request_firmware()
> >> lately)
> >> 
> >> Pali Rohár <pali.rohar@...il.com> writes:
> >>>>> So no, there is no argument against... request_firmware() in
> >>>>> fallback mode with userspace helper is by design blocking and
> >>>>> waiting for userspace. But waiting for some change in DTS in
> >>>>> kernel is just nonsense.
> >>>> 
> >>>> I would just mark the wlan device with status = "disabled" and
> >>>> enable it in the overlay together with adding the NVS & MAC
> >>>> info.
> >>> 
> >>> So if you think that this solution make sense, we can wait what
> >>> net wireless maintainers say about it...
> >>> 
> >>> For me it looks like that solution can be:
> >>> 
> >>> extending request_firmware() to use only userspace helper
> >> 
> >> I haven't followed the discussion very closely but this is my
> >> preference what drivers should do:
> >> 
> >> 1) First the driver should do try to get the calibration data and
> >> mac
> >> 
> >>        address from the device tree.
> > 
> > Ok, but there is no (dynamic, device specific) data in DTS for
> > N900. So 1) is noop.
> 
> Uhm. What do you mean? You can propose a patch to the DT bindings [1]
> to get it in there and create your N900 DTB or am I missing
> something here. Are there hardware restrictions that do not allow
> you to boot with your own DTB.

What is [1]?

N900's bootloader does not support DTB and it does not pass any DTB. It 
boots kernel in ATAGs mode. What we are doing is appending DTB compiled 
from kernel sources to end of zImage.

But that appended DTB cannot contains device specific nodes (e.g. 
calibration data for device) as zImage is there for any N900 device, not 
just only one.

> >> 2) If they are not in DT the driver should retrieve the
> >> calibration data
> >> 
> >>        with request_firmware(). BUT with an option for user space
> >>        to implement that with a helper script so that the data
> >>        can be created dynamically, which I believe openwrt does
> >>        with ath10k calibration data right now.
> > 
> > Currently there is flag for request_firmware() that it should
> > fallback to user helper if direct VFS access not find needed
> > firmware.
> > 
> > But this flag is not suitable as /lib/firmware already provides
> > default (not device specific) calibration data.
> > 
> > So I would suggest to add another flag/function which will primary
> > use user helper.
> 
> I recall Luis saying that user-mode helper (fallback) should be
> discouraged, because there is no assurance that there is a user-mode
> helper so you might just be pissing in the wind. The idea was to have
> a dedicated API call that explicitly does the request towards
> user-space.
> 
> By the way, are we talking here about wl1251 device or driver as you
> also mentioned wl12xx? I did not read the entire thread.

Yes, we are talking about wl1251 device, which is in Nokia N900 and 
wl1251.ko and wl1251_spi.ko drivers.

I mentioned wl12xx as it already uses similar approach with mac address 
via request_firmware(). And as those drivers are very similar plus from 
one manufactor and in same kernel folder I mentioned similar API for 
consistency...

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)