* Re: [PATCH v3] rfkill: Add rfkill-any LED trigger
From: Johannes Berg @ 2017-01-02 11:12 UTC (permalink / raw)
To: Michał Kępień, David S . Miller
Cc: Михаил Кринкин,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20161221084533.27006-1-kernel@kempniu.pl>
> - Handle the global mutex properly when rfkill_set_{hw,sw}_state()
> or
> rfkill_set_states() is called from within an rfkill callback. v2
> always tried to lock the global mutex in such a case, which led
> to a
> deadlock when an rfkill driver called one of the above functions
> from its query or set_block callback. This is solved by defining
> a
> new bitfield, RFKILL_BLOCK_SW_HASLOCK, which is set before the
> above
> callbacks are invoked and cleared afterwards; the functions
> listed
> above use this bitfield to tell rfkill_any_led_trigger_event()
> whether the global mutex is currently held or not.
> RFKILL_BLOCK_SW_SETCALL cannot be reused for this purpose as
> setting
> it before invoking the query callback would cause any calls to
> rfkill_set_sw_state() made from within that callback to work on
> RFKILL_BLOCK_SW_PREV instead of RFKILL_BLOCK_SW and thus change
> the
> way rfkill_set_block() behaves.
I'm not super happy with this conditional locking - can't we instead
defer the necessary work to a workqueue, or so, for purposes of the
LED?
johannes
^ permalink raw reply
* RE: [PATCH] mac80211: Fix addition of mesh configuration element
From: Peer, Ilan @ 2017-01-02 11:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, masashi.honma@gmail.com
In-Reply-To: <1483354796.4596.9.camel@sipsolutions.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWls
dG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0NCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDAy
LCAyMDE3IDEzOjAwDQo+IFRvOiBQZWVyLCBJbGFuIDxpbGFuLnBlZXJAaW50ZWwuY29tPg0KPiBD
YzogbGludXgtd2lyZWxlc3NAdmdlci5rZXJuZWwub3JnOyBtYXNhc2hpLmhvbm1hQGdtYWlsLmNv
bQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIXSBtYWM4MDIxMTogRml4IGFkZGl0aW9uIG9mIG1lc2gg
Y29uZmlndXJhdGlvbiBlbGVtZW50DQo+IA0KPiBPbiBNb24sIDIwMTYtMTItMjYgYXQgMTg6MTcg
KzAyMDAsIElsYW4gUGVlciB3cm90ZToNCj4gPiBUaGUgY29kZSB3YXMgc2V0dGluZyB0aGUgY2Fw
YWJpbGl0aWVzIGJ5dGUgdG8gemVybywgYWZ0ZXIgaXQgd2FzDQo+ID4gYWxyZWFkeSBwcm9wZXJs
eSBzZXQgcHJldmlvdXNseS4gRml4IGl0Lg0KPiA+DQo+ID4gVGhlIGJ1ZyB3YXMgZm91bmQgd2hp
bGUgZGVidWdnaW5nIGh3c2ltIG1lc2ggdGVzdHMgZmFpbHVyZXMgdGhhdA0KPiA+IGhhcHBlbmVk
IGluIGNvbW1pdCA3NmY0M2I0IChtYWM4MDIxMTogUmVtb3ZlIGludmFsaWQgZmxhZyBvcGVyYXRp
b25zDQo+ID4gaW4gbWVzaCBUU0Ygc3luY2hyb25pemF0aW9uKS4NCj4gPg0KPiBBcHBsaWVkLCB0
aGFua3MuDQo+IA0KPiBXaGVuIHlvdSBoYXZlIHRoZSBjb21taXQgYWxyZWFkeSwgcGxlYXNlIGFk
ZCBhIEZpeGVzIHRhZywgYW5kIGFsc28gdXNlDQo+IDEyIGhleCBkaWdpdHMgdG8gYWJicmV2aWF0
ZSBTSEExcyBwbGVhc2UuIChJJ3ZlIGRvbmUgdGhhdCBub3cpDQo+IA0KDQpTdXJlLiBUaGFua3Mu
DQoNCklsYW4uDQo=
^ permalink raw reply
* Re: [PATCH] cfg80211: Random local address for Public Action frame exchange
From: Johannes Berg @ 2017-01-02 11:28 UTC (permalink / raw)
To: IgorMitsyanko, jouni; +Cc: linux-wireless, vamsin
In-Reply-To: <cf228384-c98e-737e-3ba6-6c18e988210c@quantenna.com>
On Fri, 2016-12-30 at 22:55 +0300, IgorMitsyanko wrote:
>
> > The driver needs to configure receive behavior to accept frames to
> > the
> > specified random address during the time the frame exchange is
> > pending
> > and such frames need to be acknowledged similarly to frames sent to
> > the
> > local permanent address when this random address functionality is
> > not
> > used.
>
> A (probably) silly question: how wireless drivers are supposed to use
> SA
> in a frame? I think drivers are not concerned about source address,
> they
> simply pass whatever there is already set by userspace in
> cfg80211_mgmt_tx_params::buf into air on Tx.
> And on Rx, they filter frames based on receiver address/BSSID, pass
> it
> to upper layers and do not care what address is in DA (it is handled
> by
> upper layers).
They do care about the DA in RX, since - as the commit message states -
"such frames need to be acknowledged [...]"
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Random local address for Public Action frame exchange
From: Johannes Berg @ 2017-01-02 11:34 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1482266379-9723-1-git-send-email-jouni@qca.qualcomm.com>
> + * @random_sa: indicates whether the source address is randomized.
> When this is
> + * true, the driver needs to transmit the management frame
> using the
> + * address specified in the SA field (Address 2) in the
> buffer and the
> + * driver needs to receive and acknowledge the response frame
> to this
> + * address instead of its permanent MAC address.
> */
> struct cfg80211_mgmt_tx_params {
> struct ieee80211_channel *chan;
>
Is this really of much value to the driver - rather than comparing the
addresses?
> + * @NL80211_ATTR_MGMT_TX_RANDOM_SA: A flag attribute indicating
> whether the
> + * source address is randomized in frames sent using
> %NL80211_CMD_FRAME.
> + * If this flag is not set, the source address field is
> verified to match
> + * local MAC address. Random SA can be used only with Public
> Action frames
> + * (e.g., GAS/ANQP).
Likewise here, is this really of much value?
Or is the intent to make sure that userspace *really* intended things
to be randomized, and didn't just have a bug?
What I mean is more like this: if the driver supports "random SA", that
basically means it supports "arbitrary SA". The driver could thus
(unconditionally even, or after comparing to the iface address)
configure the RX filters appropriately.
Therefore, the only thing that would really be needed is the nl80211
extended feature flag to bypass the address check in
cfg80211_mlme_mgmt_tx().
What extra value do we get from having the "yes I really did intend it
to be random" attribute?
johannes
^ permalink raw reply
* [PATCH v3] rfkill: Add rfkill-any LED trigger
From: Mike Krinkin @ 2017-01-02 11:47 UTC (permalink / raw)
To: Michał Kępień
Cc: Johannes Berg, David S . Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20161221084533.27006-1-kernel@kempniu.pl>
On Wed, Dec 21, 2016 at 09:45:33AM +0100, Michał Kępień wrote:
> Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill-any,
> which may be useful on laptops with a single "radio LED" and multiple
> radio transmitters. The trigger is meant to turn a LED on whenever
> there is at least one radio transmitter active and turn it off
> otherwise.
>
> This requires taking rfkill_global_mutex before calling
> rfkill_set_block() in rfkill_resume(): since
> rfkill_any_led_trigger_event(true) is called from rfkill_set_block()
> unconditionally, each caller of the latter needs to take care of locking
> rfkill_global_mutex.
>
> Signed-off-by: Michał Kępień <kernel@kempniu.pl>
> ---
> Jonathan, I refrained from resending patch 1/2 from v2 as part of this
> series as it is currently applied in mac80211-next/master along with
> Arnd's fix. Please let me know if you would like me to handle this
> differently.
>
> Mike, could you please test whether this version works fine on your
> machine? Thanks!
Sorry for the delay, patch works fine for me.
>
> Changes from v2:
>
> - Handle the global mutex properly when rfkill_set_{hw,sw}_state() or
> rfkill_set_states() is called from within an rfkill callback. v2
> always tried to lock the global mutex in such a case, which led to a
> deadlock when an rfkill driver called one of the above functions
> from its query or set_block callback. This is solved by defining a
> new bitfield, RFKILL_BLOCK_SW_HASLOCK, which is set before the above
> callbacks are invoked and cleared afterwards; the functions listed
> above use this bitfield to tell rfkill_any_led_trigger_event()
> whether the global mutex is currently held or not.
> RFKILL_BLOCK_SW_SETCALL cannot be reused for this purpose as setting
> it before invoking the query callback would cause any calls to
> rfkill_set_sw_state() made from within that callback to work on
> RFKILL_BLOCK_SW_PREV instead of RFKILL_BLOCK_SW and thus change the
> way rfkill_set_block() behaves.
>
> - As rfkill_any_led_trigger_event() now takes a boolean argument which
> tells it whether the global mutex was already taken by the caller,
> all calls to __rfkill_any_led_trigger_event() outside
> rfkill_any_led_trigger_event() have been replaced with calls to
> rfkill_any_led_trigger_event(true).
>
> net/rfkill/core.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 86 insertions(+), 4 deletions(-)
>
> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> index afa4f71b4c7b..688eac7b97ef 100644
> --- a/net/rfkill/core.c
> +++ b/net/rfkill/core.c
> @@ -44,6 +44,7 @@
> #define RFKILL_BLOCK_ANY (RFKILL_BLOCK_HW |\
> RFKILL_BLOCK_SW |\
> RFKILL_BLOCK_SW_PREV)
> +#define RFKILL_BLOCK_SW_HASLOCK BIT(30)
> #define RFKILL_BLOCK_SW_SETCALL BIT(31)
>
> struct rfkill {
> @@ -176,6 +177,51 @@ static void rfkill_led_trigger_unregister(struct rfkill *rfkill)
> {
> led_trigger_unregister(&rfkill->led_trigger);
> }
> +
> +static struct led_trigger rfkill_any_led_trigger;
> +
> +static void __rfkill_any_led_trigger_event(void)
> +{
> + enum led_brightness brightness = LED_OFF;
> + struct rfkill *rfkill;
> +
> + list_for_each_entry(rfkill, &rfkill_list, node) {
> + if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
> + brightness = LED_FULL;
> + break;
> + }
> + }
> +
> + led_trigger_event(&rfkill_any_led_trigger, brightness);
> +}
> +
> +static void rfkill_any_led_trigger_event(bool global_locked)
> +{
> + if (global_locked) {
> + __rfkill_any_led_trigger_event();
> + } else {
> + mutex_lock(&rfkill_global_mutex);
> + __rfkill_any_led_trigger_event();
> + mutex_unlock(&rfkill_global_mutex);
> + }
> +}
> +
> +static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
> +{
> + rfkill_any_led_trigger_event(false);
> +}
> +
> +static int rfkill_any_led_trigger_register(void)
> +{
> + rfkill_any_led_trigger.name = "rfkill-any";
> + rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
> + return led_trigger_register(&rfkill_any_led_trigger);
> +}
> +
> +static void rfkill_any_led_trigger_unregister(void)
> +{
> + led_trigger_unregister(&rfkill_any_led_trigger);
> +}
> #else
> static void rfkill_led_trigger_event(struct rfkill *rfkill)
> {
> @@ -189,6 +235,19 @@ static inline int rfkill_led_trigger_register(struct rfkill *rfkill)
> static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
> {
> }
> +
> +static void rfkill_any_led_trigger_event(bool global_locked)
> +{
> +}
> +
> +static int rfkill_any_led_trigger_register(void)
> +{
> + return 0;
> +}
> +
> +static void rfkill_any_led_trigger_unregister(void)
> +{
> +}
> #endif /* CONFIG_RFKILL_LEDS */
>
> static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
> @@ -253,6 +312,10 @@ static void rfkill_set_block(struct rfkill *rfkill, bool blocked)
> if (unlikely(rfkill->dev.power.power_state.event & PM_EVENT_SLEEP))
> return;
>
> + spin_lock_irqsave(&rfkill->lock, flags);
> + rfkill->state |= RFKILL_BLOCK_SW_HASLOCK;
> + spin_unlock_irqrestore(&rfkill->lock, flags);
> +
> /*
> * Some platforms (...!) generate input events which affect the
> * _hard_ kill state -- whenever something tries to change the
> @@ -292,11 +355,13 @@ static void rfkill_set_block(struct rfkill *rfkill, bool blocked)
> rfkill->state &= ~RFKILL_BLOCK_SW;
> }
> rfkill->state &= ~RFKILL_BLOCK_SW_SETCALL;
> + rfkill->state &= ~RFKILL_BLOCK_SW_HASLOCK;
> rfkill->state &= ~RFKILL_BLOCK_SW_PREV;
> curr = rfkill->state & RFKILL_BLOCK_SW;
> spin_unlock_irqrestore(&rfkill->lock, flags);
>
> rfkill_led_trigger_event(rfkill);
> + rfkill_any_led_trigger_event(true);
>
> if (prev != curr)
> rfkill_event(rfkill);
> @@ -463,7 +528,7 @@ bool rfkill_get_global_sw_state(const enum rfkill_type type)
> bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
> {
> unsigned long flags;
> - bool ret, prev;
> + bool ret, prev, global_locked;
>
> BUG_ON(!rfkill);
>
> @@ -474,9 +539,11 @@ bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked)
> else
> rfkill->state &= ~RFKILL_BLOCK_HW;
> ret = !!(rfkill->state & RFKILL_BLOCK_ANY);
> + global_locked = !!(rfkill->state & RFKILL_BLOCK_SW_HASLOCK);
> spin_unlock_irqrestore(&rfkill->lock, flags);
>
> rfkill_led_trigger_event(rfkill);
> + rfkill_any_led_trigger_event(global_locked);
>
> if (rfkill->registered && prev != blocked)
> schedule_work(&rfkill->uevent_work);
> @@ -502,7 +569,7 @@ static void __rfkill_set_sw_state(struct rfkill *rfkill, bool blocked)
> bool rfkill_set_sw_state(struct rfkill *rfkill, bool blocked)
> {
> unsigned long flags;
> - bool prev, hwblock;
> + bool prev, hwblock, global_locked;
>
> BUG_ON(!rfkill);
>
> @@ -511,6 +578,7 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool blocked)
> __rfkill_set_sw_state(rfkill, blocked);
> hwblock = !!(rfkill->state & RFKILL_BLOCK_HW);
> blocked = blocked || hwblock;
> + global_locked = !!(rfkill->state & RFKILL_BLOCK_SW_HASLOCK);
> spin_unlock_irqrestore(&rfkill->lock, flags);
>
> if (!rfkill->registered)
> @@ -520,6 +588,7 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool blocked)
> schedule_work(&rfkill->uevent_work);
>
> rfkill_led_trigger_event(rfkill);
> + rfkill_any_led_trigger_event(global_locked);
>
> return blocked;
> }
> @@ -542,7 +611,7 @@ EXPORT_SYMBOL(rfkill_init_sw_state);
> void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
> {
> unsigned long flags;
> - bool swprev, hwprev;
> + bool swprev, hwprev, global_locked;
>
> BUG_ON(!rfkill);
>
> @@ -559,6 +628,7 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
> rfkill->state |= RFKILL_BLOCK_HW;
> else
> rfkill->state &= ~RFKILL_BLOCK_HW;
> + global_locked = !!(rfkill->state & RFKILL_BLOCK_SW_HASLOCK);
>
> spin_unlock_irqrestore(&rfkill->lock, flags);
>
> @@ -569,6 +639,7 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
> schedule_work(&rfkill->uevent_work);
>
> rfkill_led_trigger_event(rfkill);
> + rfkill_any_led_trigger_event(global_locked);
> }
> }
> EXPORT_SYMBOL(rfkill_set_states);
> @@ -812,8 +883,10 @@ static int rfkill_resume(struct device *dev)
> rfkill->suspended = false;
>
> if (!rfkill->persistent) {
> + mutex_lock(&rfkill_global_mutex);
> cur = !!(rfkill->state & RFKILL_BLOCK_SW);
> rfkill_set_block(rfkill, cur);
> + mutex_unlock(&rfkill_global_mutex);
> }
>
> if (rfkill->ops->poll && !rfkill->polling_paused)
> @@ -985,6 +1058,7 @@ int __must_check rfkill_register(struct rfkill *rfkill)
> #endif
> }
>
> + rfkill_any_led_trigger_event(true);
> rfkill_send_events(rfkill, RFKILL_OP_ADD);
>
> mutex_unlock(&rfkill_global_mutex);
> @@ -1017,6 +1091,7 @@ void rfkill_unregister(struct rfkill *rfkill)
> mutex_lock(&rfkill_global_mutex);
> rfkill_send_events(rfkill, RFKILL_OP_DEL);
> list_del_init(&rfkill->node);
> + rfkill_any_led_trigger_event(true);
> mutex_unlock(&rfkill_global_mutex);
>
> rfkill_led_trigger_unregister(rfkill);
> @@ -1269,6 +1344,10 @@ static int __init rfkill_init(void)
> if (error)
> goto error_misc;
>
> + error = rfkill_any_led_trigger_register();
> + if (error)
> + goto error_led_trigger;
> +
> #ifdef CONFIG_RFKILL_INPUT
> error = rfkill_handler_init();
> if (error)
> @@ -1279,8 +1358,10 @@ static int __init rfkill_init(void)
>
> #ifdef CONFIG_RFKILL_INPUT
> error_input:
> - misc_deregister(&rfkill_miscdev);
> + rfkill_any_led_trigger_unregister();
> #endif
> +error_led_trigger:
> + misc_deregister(&rfkill_miscdev);
> error_misc:
> class_unregister(&rfkill_class);
> error_class:
> @@ -1293,6 +1374,7 @@ static void __exit rfkill_exit(void)
> #ifdef CONFIG_RFKILL_INPUT
> rfkill_handler_exit();
> #endif
> + rfkill_any_led_trigger_unregister();
> misc_deregister(&rfkill_miscdev);
> class_unregister(&rfkill_class);
> }
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH v3] rfkill: Add rfkill-any LED trigger
From: Johannes Berg @ 2017-01-02 12:21 UTC (permalink / raw)
To: Michał Kępień, David S . Miller
Cc: Михаил Кринкин,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1483355533.4596.11.camel@sipsolutions.net>
> I'm not super happy with this conditional locking - can't we instead
> defer the necessary work to a workqueue, or so, for purposes of the
> LED?
Actually, since you can sleep in here, and do various other things like
scheduling etc. this can't even be correct as is - one thread might be
in the probe and another might also attempt to do some operations that
require the lock but now don't take it.
johannes
^ permalink raw reply
* Re: [PATCH v3] rfkill: Add rfkill-any LED trigger
From: Johannes Berg @ 2017-01-02 12:52 UTC (permalink / raw)
To: Michał Kępień, David S . Miller
Cc: Михаил Кринкин,
linux-wireless, netdev, linux-kernel
In-Reply-To: <1483359705.21014.0.camel@sipsolutions.net>
On Mon, 2017-01-02 at 13:21 +0100, Johannes Berg wrote:
> > I'm not super happy with this conditional locking - can't we
> > instead
> > defer the necessary work to a workqueue, or so, for purposes of the
> > LED?
>
> Actually, since you can sleep in here, and do various other things
> like scheduling etc. this can't even be correct as is - one thread
> might be in the probe and another might also attempt to do some
> operations that require the lock but now don't take it.
Additionally, this doesn't address the "can be called in any context"
part, only the "even from within rfkill callbacks" part. It's clearly
still not safe to call this from any context that is not allowed to
sleep, for example.
johannes
^ permalink raw reply
* Installing driver for Ubuntu 16.04 Intel® Wireless WiFi Link 4965AGN
From: info @ 2017-01-02 13:11 UTC (permalink / raw)
To: linux-wireless; +Cc: ilw
Dear Sirs,
Which of the below drivers should I install for my Lenovo 3000 V200?
I am runing Ubuntu 16.04
Intel® Wireless WiFi Link 4965AGN
2.6.24+ iwlwifi-4965-ucode-4.44.14.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.15.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.17.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.1.18.tgz
2.6.24+ iwlwifi-4965-ucode-4.44.1.20.tgz
2.6.24+ iwlwifi-4965-ucode-228.57.1.21.tgz
2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.21.tgz
2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.23.tgz
2.6.28+ (?) iwlwifi-4965-ucode-228.61.2.24.tgz
Ans how shoudl I proceed for intalling the right driver?
Thank you
Leopoldo Soria
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-01-02
From: Kalle Valo @ 2017-01-02 13:20 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
first pull request for 4.11. The tree is based on 4.9 but that shouldn't
be a problem, at least my test pull to net-next worked ok. I'll fast
forward my trees after you have pulled this.
Please let me know if you have any problems.
Kalle
The following changes since commit adc176c5472214971d77c1a61c83db9b01e9cdc7:
ipv6 addrconf: Implemented enhanced DAD (RFC7527) (2016-12-03 23:21:37 -0=
500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next=
.git tags/wireless-drivers-next-for-davem-2017-01-02
for you to fetch changes up to e16e558e83ed848f5dac3931dc7549d7a3090f7e:
rtlwifi: fix spelling mistake: "encrypiton" -> "encryption" (2017-01-01 2=
0:54:33 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 4.11
The most notable change here is the inclusion of airtime fairness
scheduling to ath9k. It prevents slow clients from hogging all the
airtime and unfairly slowing down faster clients.
Otherwise smaller changes and cleanup.
Major changes:
ath9k
* cleanup eeprom endian handling
* add airtime fairness scheduling
ath10k
* fix issues for new QCA9377 firmware version
* support dev_coredump() for firmware crash dump
* enable channel 169 on 5 GHz band
----------------------------------------------------------------
Alexey Khoroshilov (1):
adm80211: add checks for dma mapping errors
Amitkumar Karwar (3):
mwifiex: sdio: fix use after free issue for save_adapter
mwifiex: change width of MAC control variable
mwifiex: Enable dynamic bandwidth signalling
Andrew Lutomirski (1):
orinoco: Use shash instead of ahash for MIC calculations
Arun Khandavalli (1):
ath10k: support dev_coredump for crash dump
Bartosz Markowski (5):
ath10k: fix IRAM banks number for QCA9377
ath10k: override CE5 config for QCA9377
ath10k: decrease num of peers support
ath10k: set CTS protection VDEV param only if VDEV is up
ath10k: add debug trace to rts/cts set function
Bhumika Goyal (1):
libertas: constify cfg80211_ops structures
Christian Lamparter (1):
ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
Colin Ian King (4):
rtlwifi: fix spelling mistake: "contry" -> "country"
brcmfmac: fix spelling mistakes on "Ivalid"
wlcore: fix spelling mistake in wl1271_warning
rtlwifi: fix spelling mistake: "encrypiton" -> "encryption"
Dan Carpenter (2):
mwifiex: clean up some messy indenting
adm80211: return an error if adm8211_alloc_rings() fails
Johannes Berg (1):
iwlegacy: make il3945_mac_ops __ro_after_init
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Larry Finger (14):
rtlwifi: Replace local debug macro RT_ASSERT
rtlwifi: Remove RT_TRACE messages that use DBG_EMERG
rtlwifi: rtl8821ae: Remove all instances of DBG_EMERG
rtlwifi: rtl8723be: Remove all instances of DBG_EMERG
rtlwifi: rtl8723ae: Remove all instances of DBG_EMERG
rtlwifi: rtl8192ee: Remove all instances of DBG_EMERG
rtlwifi: rtl8723-common: Remove all instances of DBG_EMERG
rtlwifi: rtl8192se: Remove all instances of DBG_EMERG
rtlwifi: rtl8192de: Remove all instances of DBG_EMERG
rtlwifi: rtl8192cu: Remove all instances of DBG_EMERG
rtlwifi: rtl8192ce: Remove all instances of DBG_EMERG
rtlwifi: rtl8192c-common: Remove all instances of DBG_EMERG
rtlwifi: rtl8188ee: Remove all instances of DBG_EMERG
rtlwifi: Remove some redundant code
Martin Blumenstingl (7):
ath9k: Add a #define for the EEPROM "eepmisc" endianness bit
ath9k: indicate that the AR9003 EEPROM template values are little end=
ian
ath9k: Add an eeprom_ops callback for retrieving the eepmisc value
ath9k: replace eeprom_param EEP_MINOR_REV with get_eeprom_rev
ath9k: consistently use get_eeprom_rev(ah)
ath9k: Make the EEPROM swapping check use the eepmisc register
ath9k: define all EEPROM fields in Little Endian format
Mohammed Shafi Shajakhan (3):
ath10k: Avoid potential page alloc BUG_ON in tx free path
ath10k: Remove passing unused argument for ath10k_mac_tx
ath10k: enable advertising support for channel 169, 5Ghz
Ping-Ke Shih (1):
rtlwifi: Fix alignment issues
Ryan Hsu (3):
ath10k: fix incorrect txpower set by P2P_DEVICE interface
ath10k: recal the txpower when removing interface
ath10k: ignore configuring the incorrect board_id
Stanislaw Gruszka (11):
rt2800: make rx ampdu_factor depend on number of rx chains
rt2800: don't set ht parameters for non-aggregated frames
rt2800: set minimum MPDU and PSDU lengths to sane values
rt2800: set MAX_PSDU len according to remote STAs capabilities
rt2800: rename adjust_freq_offset function
rt2800: warn if doing VCO recalibration for unknow RF chip
rt2800: perform VCO recalibration for RF5592 chip
rt2x00: merge agc and vco works with link tuner
rt2800: replace mdelay by usleep on vco calibration.
rt2800: replace msleep() with usleep_range() on channel switch
rt2x00: add mutex to synchronize config and link tuner
Toke H=C3=B8iland-J=C3=B8rgensen (2):
ath9k: Introduce airtime fairness scheduling between stations
ath9k: Turn ath_txq_lock/unlock() into static inlines.
drivers/net/wireless/admtek/adm8211.c | 27 ++-
drivers/net/wireless/ath/ath10k/core.c | 11 +-
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 43 ++++-
drivers/net/wireless/ath/ath10k/debug.h | 8 +
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 +
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 73 ++++++--
drivers/net/wireless/ath/ath10k/pci.c | 4 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 12 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 21 ++-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 4 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 36 +++-
drivers/net/wireless/ath/ath9k/channel.c | 14 +-
drivers/net/wireless/ath/ath9k/debug.c | 3 +
drivers/net/wireless/ath/ath9k/debug.h | 13 ++
drivers/net/wireless/ath/ath9k/debug_sta.c | 54 ++++++
drivers/net/wireless/ath/ath9k/eeprom.c | 42 +++--
drivers/net/wireless/ath/ath9k/eeprom.h | 85 +++++----
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 137 ++++++--------
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 129 ++++++-------
drivers/net/wireless/ath/ath9k/eeprom_def.c | 163 ++++++++---------
drivers/net/wireless/ath/ath9k/init.c | 2 +
drivers/net/wireless/ath/ath9k/main.c | 6 +-
drivers/net/wireless/ath/ath9k/recv.c | 65 +++++++
drivers/net/wireless/ath/ath9k/xmit.c | 192 +++++++++++++---=
----
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +-
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 20 +-
drivers/net/wireless/intersil/orinoco/mic.c | 44 +++--
drivers/net/wireless/intersil/orinoco/mic.h | 3 +-
drivers/net/wireless/intersil/orinoco/orinoco.h | 4 +-
drivers/net/wireless/marvell/libertas/cfg.c | 2 +-
drivers/net/wireless/marvell/mwifiex/fw.h | 19 +-
drivers/net/wireless/marvell/mwifiex/init.c | 3 +-
drivers/net/wireless/marvell/mwifiex/main.h | 2 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 +
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 8 +-
drivers/net/wireless/ralink/rt2x00/rt2800.h | 2 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 79 ++++++--
drivers/net/wireless/ralink/rt2x00/rt2800lib.h | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 6 +-
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 7 +-
drivers/net/wireless/ralink/rt2x00/rt2x00lib.h | 31 +---
drivers/net/wireless/ralink/rt2x00/rt2x00link.c | 132 ++++----------
drivers/net/wireless/ralink/rt2x00/rt2x00mac.c | 8 +-
drivers/net/wireless/ralink/rt2x00/rt2x00queue.c | 12 +-
drivers/net/wireless/realtek/rtlwifi/base.c | 15 +-
drivers/net/wireless/realtek/rtlwifi/cam.c | 14 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 31 ++--
drivers/net/wireless/realtek/rtlwifi/debug.h | 16 +-
drivers/net/wireless/realtek/rtlwifi/efuse.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 48 ++---
drivers/net/wireless/realtek/rtlwifi/ps.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/rc.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 44 ++---
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 33 ++--
.../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 35 ++--
.../net/wireless/realtek/rtlwifi/rtl8188ee/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 8 +-
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 46 ++---
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 28 +--
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 39 ++--
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 35 ++--
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 12 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 34 ++--
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 35 ++--
.../net/wireless/realtek/rtlwifi/rtl8192de/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 45 +++--
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 10 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 40 +---
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 39 ++--
.../net/wireless/realtek/rtlwifi/rtl8192ee/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.c | 46 ++---
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 43 ++---
.../net/wireless/realtek/rtlwifi/rtl8192se/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 45 ++---
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 21 +--
.../net/wireless/realtek/rtlwifi/rtl8723ae/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 31 ++--
.../net/wireless/realtek/rtlwifi/rtl8723ae/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/fw.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 18 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/led.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 33 ++--
.../net/wireless/realtek/rtlwifi/rtl8723be/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 14 +-
.../realtek/rtlwifi/rtl8723com/fw_common.c | 26 +--
.../realtek/rtlwifi/rtl8723com/phy_common.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 28 +--
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 33 ++--
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 54 +++---
.../net/wireless/realtek/rtlwifi/rtl8821ae/rf.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 14 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 20 +-
drivers/net/wireless/realtek/rtlwifi/usb.c | 48 ++---
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
123 files changed, 1487 insertions(+), 1421 deletions(-)
^ permalink raw reply
* [PATCH V2 1/3] cfg80211: allow passing struct device in the wiphy_new call
From: Rafał Miłecki @ 2017-01-02 13:27 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
So far wiphy's device had to be set using separated set_wiphy_dev call.
Most drivers were doing this right after calling wiphy_new anyway so
this just simplifies the code a bit.
The real advantage of this however is having access to struct dev during
early wiphy init. This allows e.g. reading extra DT info thanks to
of_node reference. It's important for things that may happen before
wiphy_register like custom regulatory.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: This is a new patch, wasn't used in V1
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 7 ++-----
drivers/net/wireless/ath/ath6kl/cfg80211.h | 2 +-
drivers/net/wireless/ath/ath6kl/core.c | 2 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 3 +--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +--
drivers/net/wireless/intel/ipw2x00/libipw_module.c | 2 +-
drivers/net/wireless/intersil/orinoco/cfg.c | 2 --
drivers/net/wireless/intersil/orinoco/main.c | 2 +-
drivers/net/wireless/marvell/libertas/cfg.c | 3 ++-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 +---
drivers/net/wireless/rndis_wlan.c | 5 ++---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 9 ++++-----
drivers/staging/wlan-ng/cfg80211.c | 3 +--
include/net/cfg80211.h | 9 +++++----
net/mac80211/main.c | 3 ++-
net/wireless/core.c | 6 ++++--
16 files changed, 29 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index b7fe0af..0f9f7e7 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3870,9 +3870,6 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
wiphy->max_remain_on_channel_duration = 5000;
- /* set device pointer for wiphy */
- set_wiphy_dev(wiphy, ar->dev);
-
wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_ADHOC) |
BIT(NL80211_IFTYPE_AP);
@@ -4004,13 +4001,13 @@ void ath6kl_cfg80211_cleanup(struct ath6kl *ar)
ar->wiphy_registered = false;
}
-struct ath6kl *ath6kl_cfg80211_create(void)
+struct ath6kl *ath6kl_cfg80211_create(struct device *dev)
{
struct ath6kl *ar;
struct wiphy *wiphy;
/* create a new wiphy for use with cfg80211 */
- wiphy = wiphy_new(&ath6kl_cfg80211_ops, sizeof(struct ath6kl));
+ wiphy = wiphy_new(dev, &ath6kl_cfg80211_ops, sizeof(struct ath6kl));
if (!wiphy) {
ath6kl_err("couldn't allocate wiphy device\n");
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.h b/drivers/net/wireless/ath/ath6kl/cfg80211.h
index 5aa57a7..994ba2c 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.h
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.h
@@ -60,7 +60,7 @@ void ath6kl_cfg80211_stop_all(struct ath6kl *ar);
int ath6kl_cfg80211_init(struct ath6kl *ar);
void ath6kl_cfg80211_cleanup(struct ath6kl *ar);
-struct ath6kl *ath6kl_cfg80211_create(void);
+struct ath6kl *ath6kl_cfg80211_create(struct device *dev);
void ath6kl_cfg80211_destroy(struct ath6kl *ar);
#endif /* ATH6KL_CFG80211_H */
diff --git a/drivers/net/wireless/ath/ath6kl/core.c b/drivers/net/wireless/ath/ath6kl/core.c
index ebb9f16..d3f3822 100644
--- a/drivers/net/wireless/ath/ath6kl/core.c
+++ b/drivers/net/wireless/ath/ath6kl/core.c
@@ -267,7 +267,7 @@ struct ath6kl *ath6kl_core_create(struct device *dev)
struct ath6kl *ar;
u8 ctr;
- ar = ath6kl_cfg80211_create();
+ ar = ath6kl_cfg80211_create(dev);
if (!ar)
return NULL;
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c b/drivers/net/wireless/ath/wil6210/cfg80211.c
index 6aa3ff4..ce4d7d4 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -1575,14 +1575,13 @@ struct wireless_dev *wil_cfg80211_init(struct device *dev)
if (!wdev)
return ERR_PTR(-ENOMEM);
- wdev->wiphy = wiphy_new(&wil_cfg80211_ops,
+ wdev->wiphy = wiphy_new(dev, &wil_cfg80211_ops,
sizeof(struct wil6210_priv));
if (!wdev->wiphy) {
rc = -ENOMEM;
goto out;
}
- set_wiphy_dev(wdev->wiphy, dev);
wil_wiphy_init(wdev->wiphy);
return wdev;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..29cb1e9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6779,13 +6779,12 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_WOWL_GTK))
ops->set_rekey_data = brcmf_cfg80211_set_rekey_data;
#endif
- wiphy = wiphy_new(ops, sizeof(struct brcmf_cfg80211_info));
+ wiphy = wiphy_new(busdev, ops, sizeof(struct brcmf_cfg80211_info));
if (!wiphy) {
brcmf_err("Could not allocate wiphy device\n");
return NULL;
}
memcpy(wiphy->perm_addr, drvr->mac, ETH_ALEN);
- set_wiphy_dev(wiphy, busdev);
cfg = wiphy_priv(wiphy);
cfg->wiphy = wiphy;
diff --git a/drivers/net/wireless/intel/ipw2x00/libipw_module.c b/drivers/net/wireless/intel/ipw2x00/libipw_module.c
index 2332075..555ef56 100644
--- a/drivers/net/wireless/intel/ipw2x00/libipw_module.c
+++ b/drivers/net/wireless/intel/ipw2x00/libipw_module.c
@@ -135,7 +135,7 @@ struct net_device *alloc_libipw(int sizeof_priv, int monitor)
ieee->dev = dev;
if (!monitor) {
- ieee->wdev.wiphy = wiphy_new(&libipw_config_ops, 0);
+ ieee->wdev.wiphy = wiphy_new(NULL, &libipw_config_ops, 0);
if (!ieee->wdev.wiphy) {
LIBIPW_ERROR("Unable to allocate wiphy.\n");
goto failed_free_netdev;
diff --git a/drivers/net/wireless/intersil/orinoco/cfg.c b/drivers/net/wireless/intersil/orinoco/cfg.c
index 7aa4706..5848fd6 100644
--- a/drivers/net/wireless/intersil/orinoco/cfg.c
+++ b/drivers/net/wireless/intersil/orinoco/cfg.c
@@ -26,8 +26,6 @@ void orinoco_wiphy_init(struct wiphy *wiphy)
struct orinoco_private *priv = wiphy_priv(wiphy);
wiphy->privid = orinoco_wiphy_privid;
-
- set_wiphy_dev(wiphy, priv->dev);
}
/* Called after firmware is initialised */
diff --git a/drivers/net/wireless/intersil/orinoco/main.c b/drivers/net/wireless/intersil/orinoco/main.c
index 9d96b7c..3465ea6 100644
--- a/drivers/net/wireless/intersil/orinoco/main.c
+++ b/drivers/net/wireless/intersil/orinoco/main.c
@@ -2178,7 +2178,7 @@ struct orinoco_private
* NOTE: We only support a single virtual interface
* but this may change when monitor mode is added
*/
- wiphy = wiphy_new(&orinoco_cfg_ops,
+ wiphy = wiphy_new(device, &orinoco_cfg_ops,
sizeof(struct orinoco_private) + sizeof_card);
if (!wiphy)
return NULL;
diff --git a/drivers/net/wireless/marvell/libertas/cfg.c b/drivers/net/wireless/marvell/libertas/cfg.c
index 7ff2efa..f87d279 100644
--- a/drivers/net/wireless/marvell/libertas/cfg.c
+++ b/drivers/net/wireless/marvell/libertas/cfg.c
@@ -2120,7 +2120,8 @@ struct wireless_dev *lbs_cfg_alloc(struct device *dev)
if (!wdev)
return ERR_PTR(-ENOMEM);
- wdev->wiphy = wiphy_new(&lbs_cfg80211_ops, sizeof(struct lbs_private));
+ wdev->wiphy = wiphy_new(dev, &lbs_cfg80211_ops,
+ sizeof(struct lbs_private));
if (!wdev->wiphy) {
dev_err(dev, "cannot allocate wiphy\n");
ret = -ENOMEM;
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 1e3bd43..d92a649 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -4232,7 +4232,7 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
u32 thr, retry;
/* create a new wiphy for use with cfg80211 */
- wiphy = wiphy_new(&mwifiex_cfg80211_ops,
+ wiphy = wiphy_new(priv->adapter->dev, &mwifiex_cfg80211_ops,
sizeof(struct mwifiex_adapter *));
if (!wiphy) {
mwifiex_dbg(adapter, ERROR,
@@ -4328,8 +4328,6 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
wdev_priv = wiphy_priv(wiphy);
*(unsigned long *)wdev_priv = (unsigned long)adapter;
- set_wiphy_dev(wiphy, priv->adapter->dev);
-
ret = wiphy_register(wiphy);
if (ret < 0) {
mwifiex_dbg(adapter, ERROR,
diff --git a/drivers/net/wireless/rndis_wlan.c b/drivers/net/wireless/rndis_wlan.c
index 603c904..6535f26 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -3408,7 +3408,8 @@ static int rndis_wlan_bind(struct usbnet *usbdev, struct usb_interface *intf)
* NOTE: We only support a single virtual interface, so wiphy
* and wireless_dev are somewhat synonymous for this device.
*/
- wiphy = wiphy_new(&rndis_config_ops, sizeof(struct rndis_wlan_private));
+ wiphy = wiphy_new(&usbdev->udev->dev, &rndis_config_ops,
+ sizeof(struct rndis_wlan_private));
if (!wiphy)
return -ENOMEM;
@@ -3486,8 +3487,6 @@ static int rndis_wlan_bind(struct usbnet *usbdev, struct usb_interface *intf)
wiphy->cipher_suites = priv->cipher_suites;
wiphy->n_cipher_suites = ARRAY_SIZE(rndis_cipher_suites);
- set_wiphy_dev(wiphy, &usbdev->udev->dev);
-
if (wiphy_register(wiphy)) {
retval = -ENODEV;
goto fail;
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 60d8b05..dd87557 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -2243,7 +2243,7 @@ static const struct cfg80211_ops wilc_cfg80211_ops = {
};
-static struct wireless_dev *WILC_WFI_CfgAlloc(void)
+static struct wireless_dev *WILC_WFI_CfgAlloc(struct device *dev)
{
struct wireless_dev *wdev;
@@ -2251,7 +2251,8 @@ static struct wireless_dev *WILC_WFI_CfgAlloc(void)
if (!wdev)
goto _fail_;
- wdev->wiphy = wiphy_new(&wilc_cfg80211_ops, sizeof(struct wilc_priv));
+ wdev->wiphy = wiphy_new(dev, &wilc_cfg80211_ops,
+ sizeof(struct wilc_priv));
if (!wdev->wiphy)
goto _fail_mem_;
@@ -2277,7 +2278,7 @@ struct wireless_dev *wilc_create_wiphy(struct net_device *net, struct device *de
struct wireless_dev *wdev;
s32 s32Error = 0;
- wdev = WILC_WFI_CfgAlloc();
+ wdev = WILC_WFI_CfgAlloc(dev);
if (!wdev) {
netdev_err(net, "wiphy new allocate failed\n");
return NULL;
@@ -2302,8 +2303,6 @@ struct wireless_dev *wilc_create_wiphy(struct net_device *net, struct device *de
wdev->wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
wdev->iftype = NL80211_IFTYPE_STATION;
- set_wiphy_dev(wdev->wiphy, dev);
-
s32Error = wiphy_register(wdev->wiphy);
if (s32Error)
netdev_err(net, "Cannot register wiphy device\n");
diff --git a/drivers/staging/wlan-ng/cfg80211.c b/drivers/staging/wlan-ng/cfg80211.c
index 182b2d5..444b7fc 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -694,7 +694,7 @@ static struct wiphy *wlan_create_wiphy(struct device *dev, struct wlandevice *wl
struct wiphy *wiphy;
struct prism2_wiphy_private *priv;
- wiphy = wiphy_new(&prism2_usb_cfg_ops, sizeof(*priv));
+ wiphy = wiphy_new(dev, &prism2_usb_cfg_ops, sizeof(*priv));
if (!wiphy)
return NULL;
@@ -710,7 +710,6 @@ static struct wiphy *wlan_create_wiphy(struct device *dev, struct wlandevice *wl
priv->band.ht_cap.ht_supported = false;
wiphy->bands[NL80211_BAND_2GHZ] = &priv->band;
- set_wiphy_dev(wiphy, dev);
wiphy->privid = prism2_wiphy_privid;
wiphy->max_scan_ssids = 1;
wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ca2ac1c..e952cca 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3730,8 +3730,8 @@ static inline const char *wiphy_name(const struct wiphy *wiphy)
* Return: A pointer to the new wiphy. This pointer must be
* assigned to each netdev's ieee80211_ptr for proper operation.
*/
-struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
- const char *requested_name);
+struct wiphy *wiphy_new_nm(struct device *dev, const struct cfg80211_ops *ops,
+ int sizeof_priv, const char *requested_name);
/**
* wiphy_new - create a new wiphy for use with cfg80211
@@ -3745,10 +3745,11 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
* Return: A pointer to the new wiphy. This pointer must be
* assigned to each netdev's ieee80211_ptr for proper operation.
*/
-static inline struct wiphy *wiphy_new(const struct cfg80211_ops *ops,
+static inline struct wiphy *wiphy_new(struct device *dev,
+ const struct cfg80211_ops *ops,
int sizeof_priv)
{
- return wiphy_new_nm(ops, sizeof_priv, NULL);
+ return wiphy_new_nm(dev, ops, sizeof_priv, NULL);
}
/**
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 1822c77..a0f780f 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -524,7 +524,8 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t priv_data_len,
*/
priv_size = ALIGN(sizeof(*local), NETDEV_ALIGN) + priv_data_len;
- wiphy = wiphy_new_nm(&mac80211_config_ops, priv_size, requested_name);
+ wiphy = wiphy_new_nm(NULL, &mac80211_config_ops, priv_size,
+ requested_name);
if (!wiphy)
return NULL;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 158c59e..398922a 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -359,8 +359,8 @@ static void cfg80211_sched_scan_stop_wk(struct work_struct *work)
/* exported functions */
-struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
- const char *requested_name)
+struct wiphy *wiphy_new_nm(struct device *dev, const struct cfg80211_ops *ops,
+ int sizeof_priv, const char *requested_name)
{
static atomic_t wiphy_counter = ATOMIC_INIT(0);
@@ -404,6 +404,8 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
/* atomic_inc_return makes it start at 1, make it start at 0 */
rdev->wiphy_idx--;
+ set_wiphy_dev(&rdev->wiphy, dev);
+
/* give it a proper name */
if (requested_name && requested_name[0]) {
int rv;
--
2.10.1
^ permalink raw reply related
* [PATCH V2 2/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-02 13:27 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree, Rafał Miłecki
In-Reply-To: <20170102132747.3491-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by Felx.
Make description implementation agnostic as pointed by Arend.
Rename node to wifi as suggested by Martin.
---
.../devicetree/bindings/net/wireless/ieee80211.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
new file mode 100644
index 0000000..658c721
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
@@ -0,0 +1,18 @@
+Common IEEE 802.11 properties
+
+This provides documentation of common properties that are valid for all wireless
+devices.
+
+Optional properties:
+ - ieee80211-freq-limit : list of supported frequency ranges in KHz
+
+Example:
+
+pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ wifi@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ ieee80211-freq-limit = <2402000 2432000>,
+ <2432000 2462000>;
+ };
+};
--
2.10.1
^ permalink raw reply related
* [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-02 13:27 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree, Rafał Miłecki
In-Reply-To: <20170102132747.3491-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
It allows specifying hardware limitations of supported channels. This
may be useful for specifying single band devices or devices that support
only some part of the whole band.
This can be useful for some tri-band routers that have separated radios
for lower and higher part of 5 GHz band.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
V2: Put main code in core.c as it isn't strictly part of regulatory - pointed
by Arend.
Update to support ieee80211-freq-limit (new property).
---
include/net/cfg80211.h | 6 +++
net/wireless/core.c | 110 +++++++++++++++++++++++++++++++++++++++++++++++++
net/wireless/core.h | 2 +
net/wireless/reg.c | 8 +++-
net/wireless/reg.h | 2 +
5 files changed, 126 insertions(+), 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e952cca..6609c39 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3515,6 +3515,9 @@ struct wiphy_iftype_ext_capab {
* attribute indices defined in &enum nl80211_bss_select_attr.
*
* @cookie_counter: unique generic cookie counter, used to identify objects.
+ *
+ * @n_freq_limits: number of frequency limits
+ * @freq_limits: array of extra frequency limits
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -3646,6 +3649,9 @@ struct wiphy {
u64 cookie_counter;
+ unsigned int n_freq_limits;
+ struct ieee80211_freq_range *freq_limits;
+
char priv[0] __aligned(NETDEV_ALIGN);
};
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 398922a..c2a5c81 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -87,6 +87,113 @@ struct wiphy *wiphy_idx_to_wiphy(int wiphy_idx)
return &rdev->wiphy;
}
+static int wiphy_freq_limits_init(struct wiphy *wiphy)
+{
+ struct device *dev = wiphy_dev(wiphy);
+ struct device_node *np;
+ struct property *prop;
+ const __be32 *p;
+ int i;
+ int err = 0;
+
+ if (wiphy->n_freq_limits)
+ return 0;
+
+ if (!dev)
+ return 0;
+ np = dev->of_node;
+ if (!np)
+ return 0;
+
+ prop = of_find_property(np, "ieee80211-freq-limit", &i);
+ if (!prop)
+ return 0;
+
+ i = i / sizeof(u32);
+ if (i % 2) {
+ dev_err(dev, "ieee80211-freq-limit wrong value");
+ return -EPROTO;
+ }
+ wiphy->n_freq_limits = i / 2;
+
+ wiphy->freq_limits = kzalloc(wiphy->n_freq_limits * sizeof(*wiphy->freq_limits),
+ GFP_KERNEL);
+ if (!wiphy->freq_limits) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ p = NULL;
+ for (i = 0; i < wiphy->n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &wiphy->freq_limits[i];
+
+ p = of_prop_next_u32(prop, p, &limit->start_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ p = of_prop_next_u32(prop, p, &limit->end_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out;
+ }
+ }
+
+out:
+ if (err) {
+ dev_err(dev, "Failed to get limits: %d\n", err);
+ kfree(wiphy->freq_limits);
+ wiphy->n_freq_limits = 0;
+ }
+ return err;
+}
+
+static bool wiphy_freq_limits_valid_chan(struct wiphy *wiphy,
+ struct ieee80211_channel *chan)
+{
+ u32 bw = MHZ_TO_KHZ(20);
+ int i;
+
+ for (i = 0; i < wiphy->n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &wiphy->freq_limits[i];
+
+ if (reg_does_bw_fit(limit, MHZ_TO_KHZ(chan->center_freq), bw))
+ return true;
+ }
+
+ return false;
+}
+
+void wiphy_freq_limits_apply(struct wiphy *wiphy)
+{
+ enum nl80211_band band;
+ int i;
+
+ if (!wiphy->n_freq_limits)
+ return;
+
+ for (band = 0; band < NUM_NL80211_BANDS; band++) {
+ struct ieee80211_supported_band *sband = wiphy->bands[band];
+
+ if (!sband)
+ continue;
+
+ for (i = 0; i < sband->n_channels; i++) {
+ struct ieee80211_channel *chan = &sband->channels[i];
+
+ if (chan->flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
+ if (!wiphy_freq_limits_valid_chan(wiphy, chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->flags |= IEEE80211_CHAN_DISABLED;
+ }
+ }
+ }
+}
+
static int cfg80211_dev_check_name(struct cfg80211_registered_device *rdev,
const char *newname)
{
@@ -481,6 +588,8 @@ struct wiphy *wiphy_new_nm(struct device *dev, const struct cfg80211_ops *ops,
init_waitqueue_head(&rdev->dev_wait);
+ wiphy_freq_limits_init(&rdev->wiphy);
+
/*
* Initialize wiphy parameters to IEEE 802.11 MIB default values.
* Fragmentation and RTS threshold are disabled by default with the
@@ -942,6 +1051,7 @@ void cfg80211_dev_free(struct cfg80211_registered_device *rdev)
void wiphy_free(struct wiphy *wiphy)
{
+ kfree(wiphy->freq_limits);
put_device(&wiphy->dev);
}
EXPORT_SYMBOL(wiphy_free);
diff --git a/net/wireless/core.h b/net/wireless/core.h
index af6e023..ce94f82 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -271,6 +271,8 @@ struct cfg80211_iface_destroy {
u32 nlportid;
};
+void wiphy_freq_limits_apply(struct wiphy *wiphy);
+
void cfg80211_destroy_ifaces(struct cfg80211_registered_device *rdev);
/* free object */
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..cb5a264 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -748,8 +748,8 @@ static bool is_valid_rd(const struct ieee80211_regdomain *rd)
return true;
}
-static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
- u32 center_freq_khz, u32 bw_khz)
+bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz)
{
u32 start_freq_khz, end_freq_khz;
@@ -1693,6 +1693,8 @@ static void wiphy_update_regulatory(struct wiphy *wiphy,
for (band = 0; band < NUM_NL80211_BANDS; band++)
handle_band(wiphy, initiator, wiphy->bands[band]);
+ wiphy_freq_limits_apply(wiphy);
+
reg_process_beacons(wiphy);
reg_process_ht_flags(wiphy);
reg_call_notifier(wiphy, lr);
@@ -1800,6 +1802,8 @@ void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
bands_set++;
}
+ wiphy_freq_limits_apply(wiphy);
+
/*
* no point in calling this if it won't have any effect
* on your device's supported bands.
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index f6ced31..90eddc3 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -25,6 +25,8 @@ extern const struct ieee80211_regdomain __rcu *cfg80211_regdomain;
bool reg_is_valid_request(const char *alpha2);
bool is_world_regdom(const char *alpha2);
+bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz);
bool reg_supported_dfs_region(enum nl80211_dfs_regions dfs_region);
enum nl80211_dfs_regions reg_get_dfs_region(struct wiphy *wiphy);
--
2.10.1
^ permalink raw reply related
* Re: [PATCH V2 1/3] cfg80211: allow passing struct device in the wiphy_new call
From: Johannes Berg @ 2017-01-02 13:38 UTC (permalink / raw)
To: Rafał Miłecki, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree, Rafał Miłecki
In-Reply-To: <20170102132747.3491-1-zajec5@gmail.com>
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -3730,8 +3730,8 @@ static inline const char *wiphy_name(const
> struct wiphy *wiphy)
> * Return: A pointer to the new wiphy. This pointer must be
> * assigned to each netdev's ieee80211_ptr for proper operation.
> */
> -struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int
> sizeof_priv,
> - const char *requested_name);
> +struct wiphy *wiphy_new_nm(struct device *dev, const struct
> cfg80211_ops *ops,
> + int sizeof_priv, const char
> *requested_name);
This is obviously missing documentation updates.
> */
> -static inline struct wiphy *wiphy_new(const struct cfg80211_ops
> *ops,
> +static inline struct wiphy *wiphy_new(struct device *dev,
> + const struct cfg80211_ops
> *ops,
Ditto.
It looks like you practically removed all users of set_wiphy_dev(), why
not do that completely and remove that entirely?
johannes
^ permalink raw reply
* Re: [PATCH V2 2/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Johannes Berg @ 2017-01-02 13:49 UTC (permalink / raw)
To: Rafał Miłecki, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree, Rafał Miłecki
In-Reply-To: <20170102132747.3491-2-zajec5@gmail.com>
> +pcie@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + wifi@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + ieee80211-freq-limit = <2402000 2432000>,
> + <2432000 2462000>;
> + };
> +};
Syntactically, that might be a good example, but semantically it
doesn't really make sense to have those ranges that have a common
endpoint?
johannes
^ permalink raw reply
* Re: [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Johannes Berg @ 2017-01-02 14:04 UTC (permalink / raw)
To: Rafał Miłecki, linux-wireless
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree, Rafał Miłecki
In-Reply-To: <20170102132747.3491-3-zajec5@gmail.com>
> + prop = of_find_property(np, "ieee80211-freq-limit", &i);
> + if (!prop)
> + return 0;
> +
> + i = i / sizeof(u32);
What if it's not even a multiple of sizeof(u32)? Shouldn't you check
that, in case it's completely bogus?
> + if (i % 2) {
> + dev_err(dev, "ieee80211-freq-limit wrong value");
say "wrong format" perhaps? we don't care (much) above the values.
> + return -EPROTO;
> + }
> + wiphy->n_freq_limits = i / 2;
I don't like this use of the 'i' variable - use something like
'len[gth]' instead?
> + wiphy->freq_limits = kzalloc(wiphy->n_freq_limits *
> sizeof(*wiphy->freq_limits),
> + GFP_KERNEL);
> + if (!wiphy->freq_limits) {
> + err = -ENOMEM;
> + goto out;
> + }
> +
> + p = NULL;
> + for (i = 0; i < wiphy->n_freq_limits; i++) {
> + struct ieee80211_freq_range *limit = &wiphy-
> >freq_limits[i];
> +
> + p = of_prop_next_u32(prop, p, &limit-
> >start_freq_khz);
> + if (!p) {
> + err = -EINVAL;
> + goto out;
> + }
> +
> + p = of_prop_next_u32(prop, p, &limit->end_freq_khz);
> + if (!p) {
> + err = -EINVAL;
> + goto out;
> + }
> + }
You should also reject nonsense like empty ranges, or ranges with a
higher beginning than end, etc. I think
put
return 0;
here.
> +out:
> + if (err) {
then you can make that a pure "error" label and remove the "if (err)"
check.
> +void wiphy_freq_limits_apply(struct wiphy *wiphy)
I don't see any point in having this here rather than in reg.c, which
is the only user.
> + if (!wiphy_freq_limits_valid_chan(wiphy,
> chan)) {
> + pr_debug("Disabling freq %d MHz as
> it's out of OF limits\n",
> + chan->center_freq);
> + chan->flags |= IEEE80211_CHAN_DISABLED;
This seems wrong.
The sband and channels can be static data and be shared across
different wiphys for the same driver. If the driver has custom
regulatory etc. then this can't work, but that's up to the driver. OF
data is handled here though, so if OF data for one device disables a
channel, this would also cause the channel to be disabled for another
device, if the data is shared.
To avoid this, you'd have to have drivers that never share it - but you
can't really guarantee that at this level.
In order to fix that, you probably need to memdup the sband/channel
structs during wiphy registration. Then, if you set it up the right
way, you can actually simply edit them according to the OF data
directly there, so that *orig_flags* (rather than just flags) already
gets the DISABLED bit - and that allows you to get rid of the reg.c
hooks entirely since it'll look the same to reg.c independent of the
driver or the OF stuff doing this.
That can actually be inefficient though, since drivers may already have
copied the channel data somewhere and then you copy it again since you
can't know.
Perhaps a better approach would be to not combine this with wiphy
registration, but require drivers that may use this to call a new
helper function *before* wiphy registration (and *after* calling
set_wiphy_dev()), like e.g.
ieee80211_read_of_data(wiphy);
You can then also make this an inline when OF is not configured in
(something which you haven't really taken into account now, you should
have used dev_of_node() too instead of dev->of_node)
Yes, this would mean that it doesn't automatically get applied to
arbitrary drivers, but it seems unlikely that arbitrary drivers like
realtek USB would suddenly get OF node entries ... so that's not
necessarily a bad thing.
In the documentation for this function you could then document that it
will modify flags, and as such must not be called when the sband and
channel data is shared, getting rid of the waste/complexity of the copy
you otherwise have to make in cfg80211.
johannes
^ permalink raw reply
* Re: [PATCH V2 1/3] cfg80211: allow passing struct device in the wiphy_new call
From: Rafał Miłecki @ 2017-01-02 14:05 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Martin Blumenstingl,
Felix Fietkau, Arend van Spriel, Arnd Bergmann,
devicetree@vger.kernel.org, Rafał Miłecki
In-Reply-To: <1483364298.21014.3.camel@sipsolutions.net>
On 2 January 2017 at 14:38, Johannes Berg <johannes@sipsolutions.net> wrote=
:
>
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -3730,8 +3730,8 @@ static inline const char *wiphy_name(const
>> struct wiphy *wiphy)
>> * Return: A pointer to the new wiphy. This pointer must be
>> * assigned to each netdev's ieee80211_ptr for proper operation.
>> */
>> -struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int
>> sizeof_priv,
>> - const char *requested_name);
>> +struct wiphy *wiphy_new_nm(struct device *dev, const struct
>> cfg80211_ops *ops,
>> + int sizeof_priv, const char
>> *requested_name);
>
> This is obviously missing documentation updates.
>
>> */
>> -static inline struct wiphy *wiphy_new(const struct cfg80211_ops
>> *ops,
>> +static inline struct wiphy *wiphy_new(struct device *dev,
>> + const struct cfg80211_ops
>> *ops,
>
> Ditto.
>
> It looks like you practically removed all users of set_wiphy_dev(), why
> not do that completely and remove that entirely?
There are 2 users left:
1) ipw2x00 - I missed that one
2) mac80211 - it's a big one as it's used in SET_IEEE80211_DEV
I was planning to work on mac80211 drivers later. This will require
similar modification of ieee80211_alloc_hw.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: Installing driver for Ubuntu 16.04 Intel(R) Wireless WiFi Link 4965AGN
From: Sedat Dilek @ 2017-01-02 14:06 UTC (permalink / raw)
To: info; +Cc: linux-wireless, ilw
On Mon, Jan 2, 2017 at 2:11 PM, <info@leopoldosoria.com> wrote:
> Dear Sirs,
> Which of the below drivers should I install for my Lenovo 3000 V200?
> I am runing Ubuntu 16.04
>
> Intel=C2=AE Wireless WiFi Link 4965AGN
> 2.6.24+ iwlwifi-4965-ucode-4.44.14.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.15.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.17.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.1.18.tgz
> 2.6.24+ iwlwifi-4965-ucode-4.44.1.20.tgz
> 2.6.24+ iwlwifi-4965-ucode-228.57.1.21.tgz
> 2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.21.tgz
> 2.6.28+ (?) iwlwifi-4965-ucode-228.57.2.23.tgz
> 2.6.28+ (?) iwlwifi-4965-ucode-228.61.2.24.tgz
>
> Ans how shoudl I proceed for intalling the right driver?
>
> Thank you
>
[ What about the Ladies, Sir :-)? ]
Happy new 2017!
You need the linux-firmware [1] package.
Normally, Ubuntu/xenial should ship it.
Check if you have...
/lib/firmware/iwlwifi-4965-2.ucode
...file.
Not sure why you are asking or what is not working.
AFAICS, Ubuntu should have some nice wikis explaining a WLAN setup.
A good strategy will always be to consult your distro's help before asking =
here.
[3] as a gift.
Regards,
- Sedat -
[1] http://packages.ubuntu.com/xenial/linux-firmware
[2] http://packages.ubuntu.com/xenial/all/linux-firmware/filelist
[3] http://www.catb.org/~esr/faqs/smart-questions.html
^ permalink raw reply
* Re: [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-02 14:09 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Martin Blumenstingl,
Felix Fietkau, Arend van Spriel, Arnd Bergmann,
devicetree@vger.kernel.org, Rafał Miłecki
In-Reply-To: <1483365844.21014.6.camel@sipsolutions.net>
On 2 January 2017 at 15:04, Johannes Berg <johannes@sipsolutions.net> wrote=
:
>> + prop =3D of_find_property(np, "ieee80211-freq-limit", &i);
>> + if (!prop)
>> + return 0;
>> +
>> + i =3D i / sizeof(u32);
>
> What if it's not even a multiple of sizeof(u32)? Shouldn't you check
> that, in case it's completely bogus?
>
>> + if (i % 2) {
>> + dev_err(dev, "ieee80211-freq-limit wrong value");
>
> say "wrong format" perhaps? we don't care (much) above the values.
>
>> + return -EPROTO;
>> + }
>> + wiphy->n_freq_limits =3D i / 2;
>
> I don't like this use of the 'i' variable - use something like
> 'len[gth]' instead?
>
>> + wiphy->freq_limits =3D kzalloc(wiphy->n_freq_limits *
>> sizeof(*wiphy->freq_limits),
>> + GFP_KERNEL);
>> + if (!wiphy->freq_limits) {
>> + err =3D -ENOMEM;
>> + goto out;
>> + }
>> +
>> + p =3D NULL;
>> + for (i =3D 0; i < wiphy->n_freq_limits; i++) {
>> + struct ieee80211_freq_range *limit =3D &wiphy-
>> >freq_limits[i];
>> +
>> + p =3D of_prop_next_u32(prop, p, &limit-
>> >start_freq_khz);
>> + if (!p) {
>> + err =3D -EINVAL;
>> + goto out;
>> + }
>> +
>> + p =3D of_prop_next_u32(prop, p, &limit->end_freq_khz);
>> + if (!p) {
>> + err =3D -EINVAL;
>> + goto out;
>> + }
>> + }
>
> You should also reject nonsense like empty ranges, or ranges with a
> higher beginning than end, etc. I think
>
>
> put
>
> return 0;
>
> here.
>
>> +out:
>> + if (err) {
>
> then you can make that a pure "error" label and remove the "if (err)"
> check.
>
>> +void wiphy_freq_limits_apply(struct wiphy *wiphy)
>
> I don't see any point in having this here rather than in reg.c, which
> is the only user.
>
>> + if (!wiphy_freq_limits_valid_chan(wiphy,
>> chan)) {
>> + pr_debug("Disabling freq %d MHz as
>> it's out of OF limits\n",
>> + chan->center_freq);
>> + chan->flags |=3D IEEE80211_CHAN_DISABLED;
>
> This seems wrong.
>
> The sband and channels can be static data and be shared across
> different wiphys for the same driver. If the driver has custom
> regulatory etc. then this can't work, but that's up to the driver. OF
> data is handled here though, so if OF data for one device disables a
> channel, this would also cause the channel to be disabled for another
> device, if the data is shared.
>
> To avoid this, you'd have to have drivers that never share it - but you
> can't really guarantee that at this level.
>
> In order to fix that, you probably need to memdup the sband/channel
> structs during wiphy registration. Then, if you set it up the right
> way, you can actually simply edit them according to the OF data
> directly there, so that *orig_flags* (rather than just flags) already
> gets the DISABLED bit - and that allows you to get rid of the reg.c
> hooks entirely since it'll look the same to reg.c independent of the
> driver or the OF stuff doing this.
>
>
> That can actually be inefficient though, since drivers may already have
> copied the channel data somewhere and then you copy it again since you
> can't know.
>
> Perhaps a better approach would be to not combine this with wiphy
> registration, but require drivers that may use this to call a new
> helper function *before* wiphy registration (and *after* calling
> set_wiphy_dev()), like e.g.
>
> ieee80211_read_of_data(wiphy);
>
> You can then also make this an inline when OF is not configured in
> (something which you haven't really taken into account now, you should
> have used dev_of_node() too instead of dev->of_node)
>
> Yes, this would mean that it doesn't automatically get applied to
> arbitrary drivers, but it seems unlikely that arbitrary drivers like
> realtek USB would suddenly get OF node entries ... so that's not
> necessarily a bad thing.
>
> In the documentation for this function you could then document that it
> will modify flags, and as such must not be called when the sband and
> channel data is shared, getting rid of the waste/complexity of the copy
> you otherwise have to make in cfg80211.
Thank you, I appreciate your review a lot, I'll work on this according
to your comments!
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH V2 1/3] cfg80211: allow passing struct device in the wiphy_new call
From: Johannes Berg @ 2017-01-02 14:10 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless@vger.kernel.org, Martin Blumenstingl,
Felix Fietkau, Arend van Spriel, Arnd Bergmann,
devicetree@vger.kernel.org, Rafał Miłecki
In-Reply-To: <CACna6rzc2hk2xosd54eZVSUCtqgtT5E2vii24rgWBV96PR1W7A@mail.gmail.com>
> 2) mac80211 - it's a big one as it's used in SET_IEEE80211_DEV
>
> I was planning to work on mac80211 drivers later. This will require
> similar modification of ieee80211_alloc_hw.
Ah, ok, thanks for the explanation.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Random local address for Public Action frame exchange
From: IgorMitsyanko @ 2017-01-02 14:29 UTC (permalink / raw)
To: Johannes Berg, jouni; +Cc: linux-wireless, vamsin
In-Reply-To: <1483356523.4596.12.camel@sipsolutions.net>
On 01/02/2017 02:28 PM, Johannes Berg wrote:
> On Fri, 2016-12-30 at 22:55 +0300, IgorMitsyanko wrote:
>>> The driver needs to configure receive behavior to accept frames to
>>> the
>>> specified random address during the time the frame exchange is
>>> pending
>>> and such frames need to be acknowledged similarly to frames sent to
>>> the
>>> local permanent address when this random address functionality is
>>> not
>>> used.
>> A (probably) silly question: how wireless drivers are supposed to use
>> SA
>> in a frame? I think drivers are not concerned about source address,
>> they
>> simply pass whatever there is already set by userspace in
>> cfg80211_mgmt_tx_params::buf into air on Tx.
>> And on Rx, they filter frames based on receiver address/BSSID, pass
>> it
>> to upper layers and do not care what address is in DA (it is handled
>> by
>> upper layers).
> They do care about the DA in RX, since - as the commit message states -
> "such frames need to be acknowledged [...]"
Acknowledgment is done for transmitter<->receiver addresses,
not for source<->destination?
Patch talks about source address randomization, but I guess it actually
meant transmitter address (basically dynamic BSSID config?). Maybe naming
should be changed in the patch.
For NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA_CONNECTED case,
I wonder if HW can be configured to not filter-out multiple BSSIDs or
the idea
is that while random_sa frame is pending for ACK, HW will drop all
frames destined
for initially configured BSSID?
>
> johannes
>
^ permalink raw reply
* Re: [PATCH] cfg80211: Random local address for Public Action frame exchange
From: Johannes Berg @ 2017-01-02 14:33 UTC (permalink / raw)
To: IgorMitsyanko, jouni; +Cc: linux-wireless, vamsin
In-Reply-To: <c7eaea82-a5be-d047-c67a-ce9e58b4b65f@quantenna.com>
> Acknowledgment is done for transmitter<->receiver addresses,
> not for source<->destination?
Well, these are management frames, there either are no SA/DA or they're
identical to RA/TA, depending on how you want to look at it. Typically
it does get called SA/DA too then.
> Patch talks about source address randomization, but I guess it
> actually
> meant transmitter address (basically dynamic BSSID config?). Maybe
> naming should be changed in the patch.
Yes, I suppose TA might be a tad more accurate.
BSSID is another (unrelated) address.
> For NL80211_EXT_FEATURE_MGMT_TX_RANDOM_SA_CONNECTED case,
> I wonder if HW can be configured to not filter-out multiple BSSIDs
> or
> the idea
> is that while random_sa frame is pending for ACK, HW will drop all
> frames destined
> for initially configured BSSID?
Again, BSSID is unrelated (unless you're restricting yourself to the AP
STA case where BSSID == local MAC address).
And no, traffic would not be permitted to be dropped in this case, IMO
johannes
^ permalink raw reply
* pull-request: mac80211 2017-01-02
From: Johannes Berg @ 2017-01-02 14:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Happy New Year :-)
Even though I was out for around two weeks, only a single fix came in,
I guess everyone else was also out. But if people were out, then they
won't be sending fixes soon again I suppose, and if they weren't out
they haven't sent more fixes, so I decided to send this one to you now.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit eb7903bb83cc1db31a9124d4cc8a1bddebe26e33:
Merge branch 'l2tp-socket-lookup-fixes' (2017-01-01 22:07:25 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-01-02
for you to fetch changes up to 35f432a03e41d3bf08c51ede917f94e2288fbe8c:
mac80211: initialize fast-xmit 'info' later (2017-01-02 11:28:25 +0100)
----------------------------------------------------------------
A single fix to avoid loading an skb->cb pointer too early.
----------------------------------------------------------------
Johannes Berg (1):
mac80211: initialize fast-xmit 'info' later
net/mac80211/tx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
From: Johannes Berg @ 2017-01-02 14:57 UTC (permalink / raw)
To: Rob Herring, Paul Cercueil
Cc: David S . Miller, Mark Rutland, netdev, devicetree, linux-kernel,
linux-wireless, Maarten ter Huurne
In-Reply-To: <20161109182612.i4rnsdxulk5ghemz@rob-hp-laptop>
> My understanding is it is generally felt that using the regulator
> enable GPIO commonly found on WiFi chips for rfkill is an abuse of
> rfkill as it is more that just an RF disable. From a DT standpoint,
> this seems like creating a binding for what a Linux driver wants.
> Instead, I think this should be either a GPIO or GPIO regulator and
> the driver for the WiFi chip should decide whether or not to register
> that as an rfkill driver.
Sadly, there are two ways to use rfkill right now:
1) the more common, and correct, way of having rfkill be a control tied
to a specific wireless interface (wifi, BT, FM, GPS, NFC, ...), to both
report the hardware button state that might be tied to it, and to
control - centrally - the software state.
2) the platform way, which some ACPI based platforms do, which register
an rfkill instance, which often allows controlling in software the
hardware line that then toggles the hardware rfkill on the WiFi NIC.
It's not clear to me what this patch is trying to achieve. It seems a
bit like something else entirely, which would be using it to toggle the
power for a wifi device? I agree that doesn't seem appropriate, and
instead the driver could bind to the regulator and disable it when wifi
gets disabled (by rfkill or simply by taking all interfaces down.)
In fact, given that there are no in-tree users, I'm tempted to remove
the rfkill-regulator entirely. Thoughts?
johannes
^ permalink raw reply
* [PATCH] rfkill: remove rfkill-regulator
From: Johannes Berg @ 2017-01-02 15:01 UTC (permalink / raw)
To: linux-wireless
Cc: netdev, Guiming Zhuo, Antonio Ospite, Paul Cercueil, Rob Herring,
Maarten ter Huurne, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There are no users of this ("vrfkill") in the tree, so it's just
dead code - remove it.
This also isn't really how rfkill is supposed to be used - it's
intended as a signalling mechanism to/from the device, which the
driver (and partially cfg80211) will handle - having a separate
rfkill instance for a regulator is confusing, the driver should
use the regulator instead to turn off the device when requested.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/linux/rfkill-regulator.h | 48 ------------
net/rfkill/Kconfig | 11 ---
net/rfkill/Makefile | 1 -
net/rfkill/rfkill-regulator.c | 154 ---------------------------------------
4 files changed, 214 deletions(-)
delete mode 100644 include/linux/rfkill-regulator.h
delete mode 100644 net/rfkill/rfkill-regulator.c
diff --git a/include/linux/rfkill-regulator.h b/include/linux/rfkill-regulator.h
deleted file mode 100644
index aca36bc83315..000000000000
--- a/include/linux/rfkill-regulator.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * rfkill-regulator.c - Regulator consumer driver for rfkill
- *
- * Copyright (C) 2009 Guiming Zhuo <gmzhuo@gmail.com>
- * Copyright (C) 2011 Antonio Ospite <ospite@studenti.unina.it>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#ifndef __LINUX_RFKILL_REGULATOR_H
-#define __LINUX_RFKILL_REGULATOR_H
-
-/*
- * Use "vrfkill" as supply id when declaring the regulator consumer:
- *
- * static struct regulator_consumer_supply pcap_regulator_V6_consumers [] = {
- * { .dev_name = "rfkill-regulator.0", .supply = "vrfkill" },
- * };
- *
- * If you have several regulator driven rfkill, you can append a numerical id to
- * .dev_name as done above, and use the same id when declaring the platform
- * device:
- *
- * static struct rfkill_regulator_platform_data ezx_rfkill_bt_data = {
- * .name = "ezx-bluetooth",
- * .type = RFKILL_TYPE_BLUETOOTH,
- * };
- *
- * static struct platform_device a910_rfkill = {
- * .name = "rfkill-regulator",
- * .id = 0,
- * .dev = {
- * .platform_data = &ezx_rfkill_bt_data,
- * },
- * };
- */
-
-#include <linux/rfkill.h>
-
-struct rfkill_regulator_platform_data {
- char *name; /* the name for the rfkill switch */
- enum rfkill_type type; /* the type as specified in rfkill.h */
-};
-
-#endif /* __LINUX_RFKILL_REGULATOR_H */
diff --git a/net/rfkill/Kconfig b/net/rfkill/Kconfig
index 868f1ad0415a..060600b03fad 100644
--- a/net/rfkill/Kconfig
+++ b/net/rfkill/Kconfig
@@ -23,17 +23,6 @@ config RFKILL_INPUT
depends on INPUT = y || RFKILL = INPUT
default y if !EXPERT
-config RFKILL_REGULATOR
- tristate "Generic rfkill regulator driver"
- depends on RFKILL || !RFKILL
- depends on REGULATOR
- help
- This options enable controlling radio transmitters connected to
- voltage regulator using the regulator framework.
-
- To compile this driver as a module, choose M here: the module will
- be called rfkill-regulator.
-
config RFKILL_GPIO
tristate "GPIO RFKILL driver"
depends on RFKILL
diff --git a/net/rfkill/Makefile b/net/rfkill/Makefile
index 311768783f4a..87a80aded0b3 100644
--- a/net/rfkill/Makefile
+++ b/net/rfkill/Makefile
@@ -5,5 +5,4 @@
rfkill-y += core.o
rfkill-$(CONFIG_RFKILL_INPUT) += input.o
obj-$(CONFIG_RFKILL) += rfkill.o
-obj-$(CONFIG_RFKILL_REGULATOR) += rfkill-regulator.o
obj-$(CONFIG_RFKILL_GPIO) += rfkill-gpio.o
diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
deleted file mode 100644
index 50cd26a48e87..000000000000
--- a/net/rfkill/rfkill-regulator.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * rfkill-regulator.c - Regulator consumer driver for rfkill
- *
- * Copyright (C) 2009 Guiming Zhuo <gmzhuo@gmail.com>
- * Copyright (C) 2011 Antonio Ospite <ospite@studenti.unina.it>
- *
- * Implementation inspired by leds-regulator driver.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- */
-
-#include <linux/module.h>
-#include <linux/err.h>
-#include <linux/slab.h>
-#include <linux/platform_device.h>
-#include <linux/regulator/consumer.h>
-#include <linux/rfkill.h>
-#include <linux/rfkill-regulator.h>
-
-struct rfkill_regulator_data {
- struct rfkill *rf_kill;
- bool reg_enabled;
-
- struct regulator *vcc;
-};
-
-static int rfkill_regulator_set_block(void *data, bool blocked)
-{
- struct rfkill_regulator_data *rfkill_data = data;
- int ret = 0;
-
- pr_debug("%s: blocked: %d\n", __func__, blocked);
-
- if (blocked) {
- if (rfkill_data->reg_enabled) {
- regulator_disable(rfkill_data->vcc);
- rfkill_data->reg_enabled = false;
- }
- } else {
- if (!rfkill_data->reg_enabled) {
- ret = regulator_enable(rfkill_data->vcc);
- if (!ret)
- rfkill_data->reg_enabled = true;
- }
- }
-
- pr_debug("%s: regulator_is_enabled after set_block: %d\n", __func__,
- regulator_is_enabled(rfkill_data->vcc));
-
- return ret;
-}
-
-static struct rfkill_ops rfkill_regulator_ops = {
- .set_block = rfkill_regulator_set_block,
-};
-
-static int rfkill_regulator_probe(struct platform_device *pdev)
-{
- struct rfkill_regulator_platform_data *pdata = pdev->dev.platform_data;
- struct rfkill_regulator_data *rfkill_data;
- struct regulator *vcc;
- struct rfkill *rf_kill;
- int ret = 0;
-
- if (pdata == NULL) {
- dev_err(&pdev->dev, "no platform data\n");
- return -ENODEV;
- }
-
- if (pdata->name == NULL || pdata->type == 0) {
- dev_err(&pdev->dev, "invalid name or type in platform data\n");
- return -EINVAL;
- }
-
- vcc = regulator_get_exclusive(&pdev->dev, "vrfkill");
- if (IS_ERR(vcc)) {
- dev_err(&pdev->dev, "Cannot get vcc for %s\n", pdata->name);
- ret = PTR_ERR(vcc);
- goto out;
- }
-
- rfkill_data = kzalloc(sizeof(*rfkill_data), GFP_KERNEL);
- if (rfkill_data == NULL) {
- ret = -ENOMEM;
- goto err_data_alloc;
- }
-
- rf_kill = rfkill_alloc(pdata->name, &pdev->dev,
- pdata->type,
- &rfkill_regulator_ops, rfkill_data);
- if (rf_kill == NULL) {
- ret = -ENOMEM;
- goto err_rfkill_alloc;
- }
-
- if (regulator_is_enabled(vcc)) {
- dev_dbg(&pdev->dev, "Regulator already enabled\n");
- rfkill_data->reg_enabled = true;
- }
- rfkill_data->vcc = vcc;
- rfkill_data->rf_kill = rf_kill;
-
- ret = rfkill_register(rf_kill);
- if (ret) {
- dev_err(&pdev->dev, "Cannot register rfkill device\n");
- goto err_rfkill_register;
- }
-
- platform_set_drvdata(pdev, rfkill_data);
- dev_info(&pdev->dev, "%s initialized\n", pdata->name);
-
- return 0;
-
-err_rfkill_register:
- rfkill_destroy(rf_kill);
-err_rfkill_alloc:
- kfree(rfkill_data);
-err_data_alloc:
- regulator_put(vcc);
-out:
- return ret;
-}
-
-static int rfkill_regulator_remove(struct platform_device *pdev)
-{
- struct rfkill_regulator_data *rfkill_data = platform_get_drvdata(pdev);
- struct rfkill *rf_kill = rfkill_data->rf_kill;
-
- rfkill_unregister(rf_kill);
- rfkill_destroy(rf_kill);
- regulator_put(rfkill_data->vcc);
- kfree(rfkill_data);
-
- return 0;
-}
-
-static struct platform_driver rfkill_regulator_driver = {
- .probe = rfkill_regulator_probe,
- .remove = rfkill_regulator_remove,
- .driver = {
- .name = "rfkill-regulator",
- },
-};
-
-module_platform_driver(rfkill_regulator_driver);
-
-MODULE_AUTHOR("Guiming Zhuo <gmzhuo@gmail.com>");
-MODULE_AUTHOR("Antonio Ospite <ospite@studenti.unina.it>");
-MODULE_DESCRIPTION("Regulator consumer driver for rfkill");
-MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:rfkill-regulator");
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] rfkill: remove rfkill-regulator
From: Johannes Berg @ 2017-01-02 15:03 UTC (permalink / raw)
To: linux-wireless
Cc: netdev, Guiming Zhuo, Antonio Ospite, Paul Cercueil, Rob Herring,
Maarten ter Huurne
In-Reply-To: <20170102150157.26745-1-johannes@sipsolutions.net>
On Mon, 2017-01-02 at 16:01 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There are no users of this ("vrfkill") in the tree, so it's just
> dead code - remove it.
>
> This also isn't really how rfkill is supposed to be used - it's
> intended as a signalling mechanism to/from the device, which the
> driver (and partially cfg80211) will handle - having a separate
> rfkill instance for a regulator is confusing, the driver should
> use the regulator instead to turn off the device when requested.
OTOH, the rfkill-gpio is essentially the same thing, and it *does* get
used - by ACPI even, to control a GPS chip. And I'm not even sure that
there's a clear place to put this since there probably aren't any GPS
drivers?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox