Return-path: Received: from mail.linuxfoundation.org ([140.211.169.12]:54141 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752586AbaLHVAU (ORCPT ); Mon, 8 Dec 2014 16:00:20 -0500 Date: Mon, 8 Dec 2014 16:00:18 -0500 From: Greg Kroah-Hartman To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Marcel Holtmann , Ming Lei , Pavel Machek , "John W. Linville" , Grazvydas Ignotas , "linux-wireless@vger.kernel.org" , Network Development , Linux Kernel Mailing List , Ivaylo Dimitrov , Aaro Koskinen , Kalle Valo , Sebastian Reichel , David Gnedt Subject: Re: wl1251: NVS firmware data Message-ID: <20141208210018.GB14895@kroah.com> (sfid-20141208_220042_461004_2D92B882) References: <201411271506.20457@pali> <201412081811.46943@pali> <30072B9E-2495-4F90-AC91-9C0D7E08F44E@holtmann.org> <201412082015.18501@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: <201412082015.18501@pali> Sender: linux-wireless-owner@vger.kernel.org List-ID: 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