From: Kalle Valo <kvalo@codeaurora.org>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Michal Kazior <michal.kazior@tieto.com>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
Aaro Koskinen <aaro.koskinen@iki.fi>,
Tony Lindgren <tony@atomide.com>,
"linux-wireless" <linux-wireless@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
linux-kernel@vger.kernel.org,
"Luis R. Rodriguez" <mcgrof@kernel.org>
Subject: Re: wl1251 & mac address & calibration data
Date: Thu, 15 Dec 2016 10:18:44 +0200 [thread overview]
Message-ID: <87d1gtli57.fsf@purkki.adurom.net> (raw)
In-Reply-To: <201611241935.32796@pali> ("Pali \=\?utf-8\?Q\?Roh\=C3\=A1r\=22's\?\= message of "Thu, 24 Nov 2016 19:35:32 +0100")
(Adding Luis because he has been working on request_firmware() lately)
Pali Rohár <pali.rohar@gmail.com> writes:
>> > So no, there is no argument against... request_firmware() in
>> > fallback mode with userspace helper is by design blocking and
>> > waiting for userspace. But waiting for some change in DTS in
>> > kernel is just nonsense.
>>
>> I would just mark the wlan device with status = "disabled" and
>> enable it in the overlay together with adding the NVS & MAC info.
>
> So if you think that this solution make sense, we can wait what net
> wireless maintainers say about it...
>
> For me it looks like that solution can be:
>
> extending request_firmware() to use only userspace helper
I haven't followed the discussion very closely but this is my preference
what drivers should do:
1) First the driver should do try to get the calibration data and mac
address from the device tree.
2) If they are not in DT the driver should retrieve the calibration data
with request_firmware(). BUT with an option for user space to
implement that with a helper script so that the data can be created
dynamically, which I believe openwrt does with ath10k calibration
data right now.
> and load mac address also via request_firmware() either by appending it
> into NVS data or via separate call
I'm not really fan of the idea providing permanent mac address through
request_firmware(). For example, how to handle multiple devices on the
same host, would there be a need for some kind of bus ids encoded to the
filename? And what about devices with multiple mac addresses?
I wish there would be a better way than request_firmware() to provide
the permanent mac addresses from user space (if device tree is not
available), I just don't know what that could be :) But if we would
start to use request_firmware() for this at least there should be a
wider concensus about that and it should be properly documented, just
like the device tree bindings.
--
Kalle Valo
next prev parent reply other threads:[~2016-12-15 8:18 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 17:20 Pali Rohár
2016-11-21 15:51 ` Pali Rohár
2016-11-22 15:22 ` Michal Kazior
2016-11-22 15:31 ` Pali Rohár
2016-11-22 16:14 ` Michal Kazior
2016-11-22 17:05 ` Pali Rohár
2016-11-23 8:24 ` Arend Van Spriel
2016-11-23 22:23 ` Pavel Machek
2016-11-23 22:39 ` Pali Rohár
2016-11-24 7:51 ` Pavel Machek
2016-11-24 8:33 ` Pali Rohár
2016-11-24 15:13 ` Sebastian Reichel
2016-11-24 15:20 ` Pali Rohár
2016-11-24 15:31 ` Ivaylo Dimitrov
2016-11-24 16:08 ` Sebastian Reichel
2016-11-24 16:49 ` Pali Rohár
2016-11-24 18:11 ` Sebastian Reichel
2016-11-24 18:35 ` Pali Rohár
2016-12-15 8:18 ` Kalle Valo [this message]
2016-12-15 15:33 ` Pali Rohár
2016-12-15 20:12 ` Arend Van Spriel
2016-12-16 2:03 ` Luis R. Rodriguez
2016-12-16 7:25 ` Daniel Wagner
2016-12-16 10:40 ` Pali Rohár
2016-12-18 10:49 ` Arend Van Spriel
2016-12-18 11:04 ` Pali Rohár
2016-12-18 11:54 ` Arend Van Spriel
2016-12-18 12:09 ` Pali Rohár
2016-12-18 20:08 ` Arend Van Spriel
2016-12-20 11:47 ` Kalle Valo
2016-12-20 16:56 ` Tony Lindgren
2016-12-20 17:06 ` Pali Rohár
2016-12-20 17:11 ` Kalle Valo
2016-12-20 17:21 ` Tony Lindgren
2017-01-12 8:50 ` Pavel Machek
2016-12-16 10:35 ` Pali Rohár
2016-12-16 10:26 ` Pali Rohár
2016-11-24 18:46 ` Aaro Koskinen
2016-11-26 17:17 ` Pavel Machek
2016-11-26 17:20 ` Pali Rohár
2016-12-05 23:51 ` Tony Lindgren
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=87d1gtli57.fsf@purkki.adurom.net \
--to=kvalo@codeaurora.org \
--cc=aaro.koskinen@iki.fi \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=michal.kazior@tieto.com \
--cc=netdev@vger.kernel.org \
--cc=pali.rohar@gmail.com \
--cc=pavel@ucw.cz \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®