[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141208210018.GB14895@kroah.com>
Date: Mon, 8 Dec 2014 16:00:18 -0500
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Pali Rohár <pali.rohar@...il.com>
Cc: Marcel Holtmann <marcel@...tmann.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>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
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, Dec 08, 2014 at 08:15:18PM +0100, Pali Rohár wrote:
> On Nokia N900 NVS data are generated on-the-fly from some bytes
> from CAL (/dev/mtd1), from state of cellular network and from
> some other regulation settings.
When is this "generated"? At boot time? Or by the firmware loader
program you have hooked into being called by the kernel at "load the
firmware now please" call time?
> So I think that files stored in linux-firmware.git tree (which
> are also installed into /lib/firmware/) should be loaded with
> request_firmware function. Or not? Do you think something else?
> What other developers think?
>
> I'm against kernel driver for CAL (/dev/mtd1) for more reasons:
>
> 1) we have userspace open source code, but licensed under GPLv3.
> And until kernel change license, we cannot include it.
You can change the license of your code if you want to, don't make this
type of nonsense argument.
> 2) NVS data are (probably) not in one place, plus they depends on
> something other.
What is "something other"? Where are they located? Why would the
firmware interface know or care anything about this?
> 3) If manufacture XYZ create new device with its own storage
> format of calibration data this means that correct solution for
> XYZ is also to implement new kernel fs driver for its own format.
Yes, as it is doing it's own custom thing, why overload an existing
interface to do something it was never designed to do?
> Do you really want to have in kernel all those drivers for all
> different (proprietary) storage formats?
Yes, we are not afraid of lots of different drivers. That is not even a
valid argument, you know better than this :)
> 4) It does not help us with existence of generic file
> /lib/firmware/ti-connectivity/wl1251-nvs.bin which comes from
> linux-firmware.git tree.
Again, not an issue. If you don't want that file in the repo, ask for
it to be removed, and it will be, just send a patch to do it.
greg k-h
--
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