[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5485FF17.1070504@gmail.com>
Date: Mon, 08 Dec 2014 21:42:15 +0200
From: Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
To: Dan Williams <dcbw@...hat.com>,
Pali Rohár <pali.rohar@...il.com>
CC: 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 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)
Ivo
--
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
Powered by blists - more mailing lists