[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201412082208.56307@pali>
Date: Mon, 8 Dec 2014 22:08:56 +0100
From: Pali Rohár <pali.rohar@...il.com>
To: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
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 Monday 08 December 2014 22:00:18 Greg Kroah-Hartman wrote:
> 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?
>
When userspace system network daemon is started.
> > 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.
>
Code is not mine, so I cannot change license.
> > 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?
>
fcc bit and some other data retrieved from daemon which
communicating with cellular modem.
> > 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
--
Pali Rohár
pali.rohar@...il.com
Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists