From: "Pali Rohár" <pali.rohar@gmail.com>
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Cc: Marcel Holtmann <marcel@holtmann.org>,
Ming Lei <ming.lei@canonical.com>, Pavel Machek <pavel@ucw.cz>,
"John W. Linville" <linville@tuxdriver.com>,
Grazvydas Ignotas <notasas@gmail.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Kalle Valo <kvalo@adurom.com>, Sebastian Reichel <sre@ring0.de>,
David Gnedt <david.gnedt@davizone.at>
Subject: Re: wl1251: NVS firmware data
Date: Mon, 8 Dec 2014 22:08:56 +0100 [thread overview]
Message-ID: <201412082208.56307@pali> (raw)
In-Reply-To: <20141208210018.GB14895@kroah.com>
[-- Attachment #1: Type: Text/Plain, Size: 2445 bytes --]
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@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2014-12-08 21:08 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 14:06 wl1251: NVS firmware data Pali Rohár
2014-11-27 14:21 ` Ming Lei
2014-11-27 14:43 ` Pali Rohár
2014-11-27 15:13 ` Ming Lei
2014-12-06 13:00 ` Pali Rohár
2014-11-27 15:14 ` Greg Kroah-Hartman
2014-11-27 15:24 ` Pali Rohár
2014-11-27 15:34 ` Ming Lei
2014-11-27 15:16 ` Greg Kroah-Hartman
2014-11-27 15:22 ` Pali Rohár
2014-11-27 15:58 ` Greg Kroah-Hartman
2014-12-06 12:49 ` Pavel Machek
2014-12-06 13:02 ` Pali Rohár
2014-12-08 15:18 ` Ming Lei
2014-12-08 15:22 ` Pali Rohár
2014-12-08 15:35 ` Ming Lei
2014-12-08 16:37 ` Greg Kroah-Hartman
2014-12-08 16:47 ` Pali Rohár
2014-12-08 17:05 ` Marcel Holtmann
2014-12-08 17:11 ` Pali Rohár
2014-12-08 18:50 ` Marcel Holtmann
2014-12-08 19:15 ` Pali Rohár
2014-12-08 19:26 ` Dan Williams
2014-12-08 19:36 ` Pali Rohár
2014-12-08 19:46 ` Marcel Holtmann
2014-12-08 19:56 ` Pali Rohár
2014-12-08 22:51 ` Dan Williams
2014-12-08 23:23 ` Pali Rohár
2014-12-08 23:42 ` Dan Williams
2014-12-08 23:52 ` Pali Rohár
2014-12-08 19:42 ` Ivaylo Dimitrov
2014-12-08 22:41 ` Dan Williams
2014-12-09 5:10 ` Marcel Holtmann
2014-12-08 19:41 ` Marcel Holtmann
2014-12-08 19:41 ` Marcel Holtmann
2014-12-08 19:52 ` Pali Rohár
2014-12-08 21:00 ` Greg Kroah-Hartman
2014-12-08 21:08 ` Pali Rohár [this message]
2014-12-08 20:57 ` Greg Kroah-Hartman
2014-12-08 21:11 ` Pali Rohár
2014-12-08 23:27 ` Pali Rohár
2014-12-09 5:25 ` Marcel Holtmann
2014-12-09 0:48 ` Ming Lei
2014-12-09 0:48 ` Ming Lei
2014-12-09 4:08 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201412082208.56307@pali \
--to=pali.rohar@gmail.com \
--cc=aaro.koskinen@iki.fi \
--cc=david.gnedt@davizone.at \
--cc=gregkh@linuxfoundation.org \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=kvalo@adurom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=marcel@holtmann.org \
--cc=ming.lei@canonical.com \
--cc=netdev@vger.kernel.org \
--cc=notasas@gmail.com \
--cc=pavel@ucw.cz \
--cc=sre@ring0.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.