netdev - Re: wl1251: NVS firmware 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]

Message-ID: <1418078493.31640.4.camel@dcbw.local>
Date:	Mon, 08 Dec 2014 16:41:33 -0600
From:	Dan Williams <dcbw@...hat.com>
To:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Marcel Holtmann <marcel@...tmann.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ming Lei <ming.lei@...onical.com>, Pavel Machek <pavel@....cz>,
	"John W. Linville" <linville@...driver.com>,
	Grazvydas Ignotas <notasas@...il.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Aaro Koskinen <aaro.koskinen@....fi>,
	Kalle Valo <kvalo@...rom.com>,
	Sebastian Reichel <sre@...g0.de>,
	David Gnedt <david.gnedt@...izone.at>
Subject: Re: wl1251: NVS firmware data

On Mon, 2014-12-08 at 21:42 +0200, Ivaylo Dimitrov wrote:
> 
> On  8.12.2014 21:26, Dan Williams wrote:
> >
> > a) change driver to prefer a new "wl1251-nvs-n900.bin" file, but fall
> > back to "wl1251-nvs.bin" if the first one isn't present
> > b) have a "wl1251-cal-nvs-update" service that, if wl1521-nvs-n900.bin
> > is *not* present mounts the CAL MTD, reads the data, writes it out into
> > wl1521-nvs-n900.bin, and the rmmod/modprobes the driver
> >
> > and done?  Stuff that's not N900 just wouldn't ship the update service
> > and would proceed like none of this happened.
> >
> > Dan
> >
> >
> 
> That would mean that the driver should not be built-in, as afaik we 
> cannot rmmod built-in drivers. Sure, it will work after a reboot, but 
> this is a bit hacky, agree?
> 
> Also, new NVS file needs to be loaded when fcc regulation changes(flying 
> abroad), so that would mean that the device would be outside of those 
> until reboot (in case of built-in driver)

Regulatory stuff needs to be hooked into CRDA or the existing regulatory
codepaths, not some other path.  So when cfg80211 sets the regulatory
domain on the driver the driver needs to get the necessary NVS data.
Either the NVS for every domain (which cannot be a lot of them) gets
hardcoded into the driver, and then selected based on what cfg80211
says, or the driver needs to ask userspace for the NVS data based on
what cfg80211 says.  In all cases, cfg80211 drives the regulatory domain
[1].

a) How many regulatory domains does the driver support, how much data is
there for each domain, and can that be put into the driver instead of
getting it from the CAL partition?

b) what do *other* (non-N900) wl1251 devices do for regulatory data?

Dan

[1] unless there's some *restriction* hardcoded into the EEPROM of the
device, which in the case of the N900 there isn't, since the regulatory
data changes based on the MCC/MNC of the cellular side.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html