Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755087AbaLIF0G (ORCPT ); Tue, 9 Dec 2014 00:26:06 -0500 Received: from senator.holtmann.net ([87.106.208.187]:60321 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750722AbaLIF0D convert rfc822-to-8bit (ORCPT ); Tue, 9 Dec 2014 00:26:03 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: wl1251: NVS firmware data From: Marcel Holtmann In-Reply-To: <201412090027.46485@pali> Date: Tue, 9 Dec 2014 06:25:59 +0100 Cc: Greg Kroah-Hartman , 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 Content-Transfer-Encoding: 8BIT Message-Id: References: <201411271506.20457@pali> <201412081747.30965@pali> <20141208205721.GA14895@kroah.com> <201412090027.46485@pali> To: =?utf-8?Q?Pali_Roh=C3=A1r?= X-Mailer: Apple Mail (2.1993) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pali, >> Use your own custom usermode helper for stuff like this, not >> the firmware interface. But use a binary sysfs file if you >> want, that seems to make sense for it... >> >> greg k-h > > Patch for telling permanent mac address from userspace via sysfs > file was rejected for inclusion into mainline kernel. > > So I do not think that now maintainers of network subsystem allow > it for nvs data... > > https://lkml.org/lkml/2013/12/8/35 this magic sysfs that has to be written to at the right time of the boot process to make this all work is something that will not work. I does not work for WiFi and it does not work for Bluetooth. Seems the discussion come full circle now and we are back to square one. The problem is that either the driver does not register the device with mac80211 until it gets the MAC address provided by userspace or mac80211 should get an unconfigured state. The unconfigured state is something telling userspace that the device is present, but needs a few extra configuration information before it can become useful. For Bluetooth, I went the later route. Mainly because the missing address is such a generic problem that solving it in the core makes a lot more sense. The driver just tells the core that it has no address for this device and provides a custom callback to configure the address when provided. After that everything resumes as normal. However userspace gets informed when an unconfigured device gets added and at boot it can just query the list of unconfigured devices, or at runtime wait to be told there is a new unconfigured device that needs its attention. And then just provide the information. Once all information are present, the devices disappears as unconfigured and shows up as configured device ready for normal operation. https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/mgmt-api.txt#n2006 http://permalink.gmane.org/gmane.linux.bluez.kernel/50716 Can something similar be added to cfg80211 + nl80211. It bet it can, but that is up to Johannes to decide and someone to actually do the work and implement it. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/