* Re: [PATCH 0/2] beacon measurement (beacon filtering disable)
From: Johannes Berg @ 2013-07-26 8:03 UTC (permalink / raw)
To: Kalle Valo, emmanuel.grumbach; +Cc: linux-wireless
In-Reply-To: <87oba1yggl.fsf@purkki.adurom.net>
On Wed, 2013-07-17 at 07:10 +0300, Kalle Valo wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
> > We have beacon filtering (to reduce host wakeups) in our device,
> > but for some measurement/debug purposes we need to turn it off.
>
> TBH I'm not really fond of this. I'm not really sure what's the use
> case but first this sounded a like a factory test for me, not something
> which a regular user would want to do.
Yeah, in a way that's true. FWIW, we could also connect it to testmode
and not worry about it for upstream, but it seemed that others might
want/need similar functionality.
> Can't we connect this to power save? When disabling power save we could
> also disable beacon filtering and would not need a separate command.
I'm not so sure that's a good idea. While superficially beacon filtering
is related to saving power, it's really a different thing - it's about
CPU/host power while powersave is about device power (RX chains etc.)
Connecting them, in particular where disabling beacon filtering isn't
even supported by all devices, doesn't really seem like a good idea,
particularly not for any tool that would require such functionality.
johannes
^ permalink raw reply
* Re: Updates to wireless-regdb review - vendor namespaces and VHT80
From: Johannes Berg @ 2013-07-26 7:59 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, wireless-regdb@lists.infradead.org
In-Reply-To: <CAB=NE6V_PKG2UBSLPRhziUDcFzFi8uOJNiNzoPNaK0oU7rmZuQ@mail.gmail.com>
On Tue, 2013-07-02 at 17:38 -0700, Luis R. Rodriguez wrote:
> I'd like to propose a middle ground to also address another issue I've
> noticed. Vendors can disagree and in order to give vendors a warm
> fuzzy on ability to ensure their data is interpreted and provide the
> ability to offload down to wireless-regdb even more interpretations
> I'd like to propose the idea of embracing vendor namespaces within
> wireless-regdb / crda / the kernel. The way I'd envision this is
> '/sbin/crda US OUI' is passed upon a regulatory hint and in turn CRDA
> will read the namespace for the OUI passed in regulatory.bin. Then at
> our wireless summit kumbaya and with the development / enhancements of
> intersect.c and union.c (not yet developed) we'd work on generalizing
> the data. This would also allow vendors to supply their own rules
> without the high bar that we are setting which so far has proven very
> difficult to met.
I'm not really fully convinced, but let's discuss at the summit.
Wasn't the point of the regdb and documentation etc. also that the users
can trust it? It seems to me that if you're building a generic system
you wouldn't really want different regulatory interpretations. And if
you think for some special system (say a tablet) you need a different
database, you'll probably hand-roll one specifically for that system
anyway.
> In the meantime, while that gets developed, I'd still like to supply
> patches to enable VHT80 for a few countries without hopefully such
> high bar for documentation as I cannot get this information.
I've also been sitting on the patch "regulatory: enable channels 52-64
and 100-144 for world roaming" ...
johannes
^ permalink raw reply
* RE: [PATCH] mwifiex: Add missing endian conversion.
From: Bing Zhao @ 2013-07-26 4:34 UTC (permalink / raw)
To: Tomasz Moń, linville@tuxdriver.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1374558169-6888-1-git-send-email-desowin@gmail.com>
SGkgSm9obiwNCg0KPiBCb3RoIHR5cGUgYW5kIHBrdF9sZW4gdmFyaWFibGVzIGFyZSBpbiBob3N0
IGVuZGlhbiBhbmQgdGhlc2Ugc2hvdWxkIGJlIGluDQo+IExpdHRsZSBFbmRpYW4gaW4gdGhlIHBh
eWxvYWQuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBUb21hc3ogTW/FhCA8ZGVzb3dpbkBnbWFpbC5j
b20+DQo+IEFja2VkLWJ5OiBCaW5nIFpoYW8gPGJ6aGFvQG1hcnZlbGwuY29tPg0KDQpDYzogPHN0
YWJsZUB2Z2VyLmtlcm5lbC5vcmc+DQoNCkNvdWxkIHlvdSBwbGVhc2UgYXBwbHkgdGhpcyBwYXRj
aCB0byB3aXJlbGVzcy5naXQgZm9yIDMuMTE/DQoNClRoYW5rcywNCkJpbmcNCg0KPiAtLS0NCj4g
IGRyaXZlcnMvbmV0L3dpcmVsZXNzL213aWZpZXgvc2Rpby5jIHwgNCArKy0tDQo+ICAxIGZpbGUg
Y2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAyIGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdp
dCBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL213aWZpZXgvc2Rpby5jIGIvZHJpdmVycy9uZXQvd2ly
ZWxlc3MvbXdpZmlleC9zZGlvLmMNCj4gaW5kZXggNWVlNWVkMC4uYzlmM2VjZiAxMDA2NDQNCj4g
LS0tIGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvbXdpZmlleC9zZGlvLmMNCj4gKysrIGIvZHJpdmVy
cy9uZXQvd2lyZWxlc3MvbXdpZmlleC9zZGlvLmMNCj4gQEAgLTE2MjUsOCArMTYyNSw4IEBAIHN0
YXRpYyBpbnQgbXdpZmlleF9zZGlvX2hvc3RfdG9fY2FyZChzdHJ1Y3QgbXdpZmlleF9hZGFwdGVy
ICphZGFwdGVyLA0KPiAgCS8qIEFsbG9jYXRlIGJ1ZmZlciBhbmQgY29weSBwYXlsb2FkICovDQo+
ICAJYmxrX3NpemUgPSBNV0lGSUVYX1NESU9fQkxPQ0tfU0laRTsNCj4gIAlidWZfYmxvY2tfbGVu
ID0gKHBrdF9sZW4gKyBibGtfc2l6ZSAtIDEpIC8gYmxrX3NpemU7DQo+IC0JKih1MTYgKikgJnBh
eWxvYWRbMF0gPSAodTE2KSBwa3RfbGVuOw0KPiAtCSoodTE2ICopICZwYXlsb2FkWzJdID0gdHlw
ZTsNCj4gKwkqKF9fbGUxNiAqKSZwYXlsb2FkWzBdID0gY3B1X3RvX2xlMTYoKHUxNilwa3RfbGVu
KTsNCj4gKwkqKF9fbGUxNiAqKSZwYXlsb2FkWzJdID0gY3B1X3RvX2xlMTYodHlwZSk7DQo+IA0K
PiAgCS8qDQo+ICAJICogVGhpcyBpcyBTRElPIHNwZWNpZmljIGhlYWRlcg0KPiAtLQ0KPiAxLjgu
My5tc3lzZ2l0LjANCg0K
^ permalink raw reply
* RE: [PATCH 18/21] mwifiex: handle driver initialization error paths
From: Bing Zhao @ 2013-07-26 4:25 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org, Amitkumar Karwar, Avinash Patil,
Yogesh Powar, Nishant Sarmukadam, Frank Huang
In-Reply-To: <20130724190250.GG2385@tuxdriver.com>
Hi John,
> > 18/21 and 19/21 depend on this patch:
> >
> > commit 232fde062e0a2cc52e8e18a50cda361b4ba88f34
> > Author: Daniel Drake <dsd@laptop.org>
> > Date: Sat Jul 13 10:57:10 2013 -0400
> >
> > mwifiex: fix IRQ enable/disable
> >
> > which is in wireless.git and wireless-testing.git currently.
> >
> >
> > We can apply 18 and 19 later after commit 232fde0 is merged back to wireless-next.git.
> > (I will send you a reminder to merge these two patches once commit 232fde0 is in -next tree.)
> >
> > Thanks,
> > Bing
>
> OK, thanks for checking!
As the commit 232fde0 has been merged to wireless-next you may apply 18/21 and 19/21 now.
Thanks,
Bing
^ permalink raw reply
* Re: authsae, 'ath9k nohwcrypt=1' & AR9100
From: Yeoh Chun-Yeow @ 2013-07-25 22:56 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
This patch is to solve the problem for the open mesh to avoid older
chipset filters out certain frame required for mesh. Without this
patch, I am not too sure whether the secure mesh will work.
---
Chun-Yeow
^ permalink raw reply
* [PATCH] brcmfmac: inform cfg80211 about disconnect when device is unplugged
From: Arend van Spriel @ 2013-07-25 21:01 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Arend van Spriel, Ben Greear
When the brcmfmac device is physically removed cfg80211 gives a
warning upon unregistering the net device (see below).
[23052.390197] WARNING: CPU: 0 PID: 30 at net/wireless/core.c:937 cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]()
[23052.400843] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) pl2303 usbserial binfmt_misc snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event lpc_ich snd_seq snd_timer snd_seq_device snd psmouse mfd_core serio_raw soundcore snd_page_alloc intel_ips dell_laptop dell_wmi sparse_keymap dcdbas nouveau ttm drm_kms_helper drm i2c_algo_bit mxm_wmi ahci libahci sdhci_pci firewire_ohci firewire_core sdhci crc_itu_t mmc_core intel_agp intel_gtt e1000e ptp pps_core agpgart video [last unloaded: brcmfmac]
[23052.452987] CPU: 0 PID: 30 Comm: khubd Tainted: G O 3.11.0-rc1-wl-testing-lockdep-00002-g41cc093-dirty #1
[23052.463480] Hardware name: Dell Inc. Latitude E6410/07XJP9, BIOS A07 02/15/2011
[23052.470852] 00000000 00000000 f4efdc18 c1522e3d f845bed2 f4efdc48 c103fbe4 c16a9254
[23052.478762] 00000000 0000001e f845bed2 000003a9 f841da44 f841da44 f3790004 f25539c0
[23052.486741] e2700200 f4efdc58 c103fc22 00000009 00000000 f4efdcc0 f841da44 00000002
[23052.494712] Call Trace:
[23052.497165] [<c1522e3d>] dump_stack+0x4b/0x66
[23052.501685] [<c103fbe4>] warn_slowpath_common+0x84/0xa0
[23052.507085] [<f841da44>] ? cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]
[23052.514542] [<f841da44>] ? cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]
[23052.521981] [<c103fc22>] warn_slowpath_null+0x22/0x30
[23052.527191] [<f841da44>] cfg80211_netdev_notifier_call+0x164/0x600 [cfg80211]
[23052.534494] [<c150abe8>] ? packet_notifier+0xc8/0x1d0
[23052.539703] [<c150abfc>] ? packet_notifier+0xdc/0x1d0
[23052.544880] [<c150ab20>] ? packet_seq_stop+0x30/0x30
[23052.550002] [<c152d655>] notifier_call_chain+0x45/0x60
[23052.555298] [<c106839f>] raw_notifier_call_chain+0x1f/0x30
[23052.560963] [<c143c693>] call_netdevice_notifiers_info+0x33/0x70
[23052.567153] [<c1459869>] ? qdisc_destroy+0x99/0xb0
[23052.572116] [<c143c6e3>] call_netdevice_notifiers+0x13/0x20
[23052.577861] [<c143df93>] rollback_registered_many+0xf3/0x1d0
[23052.583687] [<c1524cfc>] ? mutex_lock_nested+0x25c/0x350
[23052.589150] [<c143e0f4>] rollback_registered+0x24/0x40
[23052.594445] [<c143e15f>] unregister_netdevice_queue+0x4f/0xb0
[23052.600344] [<c143e299>] unregister_netdev+0x19/0x30
[23052.605484] [<f865b38f>] brcmf_del_if+0xbf/0x160 [brcmfmac]
[23052.611223] [<f865b7ae>] brcmf_detach+0x5e/0xd0 [brcmfmac]
[23052.616881] [<f8667413>] brcmf_usb_disconnect+0x63/0xa0 [brcmfmac]
[23052.623217] [<c13e09aa>] usb_unbind_interface+0x4a/0x180
When the device is physically connected the driver sends a disassoc
command to the device and response triggers the driver to inform cfg80211
about it. However, with the device removed the disassoc command fails.
This patch adds a call to cfg80211_disconnected() when that command fails.
The warning was added by commit below and also cleans up, but better
doing it in the driver if only to get rid of the warning.
commit f9bef3df52fe61067e4c1c6cfb2037cb6b259a6a
Author: Ben Greear <greearb@candelatech.com>
Date: Wed Jun 19 14:06:26 2013 -0700
wireless: check for dangling wdev->current_bss pointer
Cc: Ben Greear <greearb@candelatech.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
Hi John,
One more fix for the wireless repository, which happens when unloading
the brcmfmac driver or unplug the device while being connected.
Regards,
Arend
---
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 277b37a..7fa71f7 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -1093,8 +1093,11 @@ static void brcmf_link_down(struct brcmf_cfg80211_vif *vif)
brcmf_dbg(INFO, "Call WLC_DISASSOC to stop excess roaming\n ");
err = brcmf_fil_cmd_data_set(vif->ifp,
BRCMF_C_DISASSOC, NULL, 0);
- if (err)
+ if (err) {
brcmf_err("WLC_DISASSOC failed (%d)\n", err);
+ cfg80211_disconnected(vif->wdev.netdev, 0,
+ NULL, 0, GFP_KERNEL);
+ }
clear_bit(BRCMF_VIF_STATUS_CONNECTED, &vif->sme_state);
}
clear_bit(BRCMF_VIF_STATUS_CONNECTING, &vif->sme_state);
--
1.7.10.4
^ permalink raw reply related
* Re: TP-LINK wireless USB adapter don't work.
From: Oleksij Rempel @ 2013-07-25 18:08 UTC (permalink / raw)
To: atar; +Cc: linux-wireless
In-Reply-To: <op.w0sd9ujye4gg2u@xp>
Am 25.07.2013 18:47, schrieb atar:
> aHi there!!
>
> I've a TP-LINK USB wireless adapter with model number TL-WN722N. When I
> plug it in to one of the USB slots in my PC, its LED diode isn't
> flashing (although under WIN XP it is flashing) and I cannot use it.
> from the messages of the 'dmesg' command it seems that the kernel detect
> it, but I unable to use it because it doesn't appear on the wicd window
> of available interfaces.
>
> My Linux distro is Debian squeeze with kernel 2.6.32-5-686.
>
> What should I do in order to solve this problem?
It is ath9k-htc based adapter. Please update your kernel and use latest
firmware. I think Debian squeeze do not provided this firmware, so you
should install it manually.
--
Regards,
Oleksij
^ permalink raw reply
* TP-LINK wireless USB adapter don't work.
From: atar @ 2013-07-25 16:47 UTC (permalink / raw)
To: linux-wireless
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-8859-8-i; format=flowed; delsp=yes, Size: 531 bytes --]
aHi there!!
I've a TP-LINK USB wireless adapter with model number TL-WN722N. When I
plug it in to one of the USB slots in my PC, its LED diode isn't flashing
(although under WIN XP it is flashing) and I cannot use it. from the
messages of the 'dmesg' command it seems that the kernel detect it, but I
unable to use it because it doesn't appear on the wicd window of available
interfaces.
My Linux distro is Debian squeeze with kernel 2.6.32-5-686.
What should I do in order to solve this problem?
Thanks in advance!!
^ permalink raw reply
* Re: pull request: bluetooth 2013-07-25
From: Gustavo Padovan @ 2013-07-25 15:01 UTC (permalink / raw)
To: linville, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20130725130552.GE9913@joana>
Hi John,
* Gustavo Padovan <gustavo@padovan.org> [2013-07-25 14:05:54 +0100]:
> Hi John,
>
> A few fixes and devices ID additions for 3.11:
>
> * There are 3 new ath3k device ids
> * Fixed stack memory usage in ath3k.
> * Fixed the init process of BlueFRITZ! devices, they were failing to init
> due to an unsupported command we sent.
> * Fixed wrong use of PTR_ERR in btusb code that was preventing intel devices
> to work properly
> * Fixed race codition between hci_register_dev() and hci_dev_open() that
> could cause a NULL pointer dereference.
Marcel just raised the comment that we need to add more information to
the BlueFRITZ! fixes so I'm steping back with it. So just ignore it for
now.
Gustavo
^ permalink raw reply
* Re: hung task while plugging in cfg80211
From: Jeff Layton @ 2013-07-25 14:51 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, linville, netdev, Thomas Graf, Stephen Hemminger,
rjones, Marcel Holtmann
In-Reply-To: <20130724095911.GA1637@redhat.com>
On Wed, 24 Jul 2013 11:59:12 +0200
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Fri, Jul 12, 2013 at 07:49:11AM -0400, Jeff Layton wrote:
> > I updated the kernel on my rawhide KVM guest, and noticed that the
> > ethernet interface wasn't coming up at all. While poking around, I saw
> > this stack trace pop up:
> >
> > Jul 12 07:29:25 rawhide kernel: [ 241.156196] INFO: task modprobe:501 blocked for more than 120 seconds.
> > Jul 12 07:29:25 rawhide kernel: [ 241.157222] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > Jul 12 07:29:25 rawhide kernel: [ 241.158379] modprobe D ffff880118c526e0 4584 501 500 0x00000080
> > Jul 12 07:29:25 rawhide kernel: [ 241.159458] ffff8800d10c3ba8 0000000000000046 00000000001d5300 ffff8800d10c3fd8
> > Jul 12 07:29:25 rawhide kernel: [ 241.160644] ffff8800d10c3fd8 00000000001d5300 ffff8800d2ae4dc0 ffff8800d2ae4dc0
> > Jul 12 07:29:25 rawhide kernel: [ 241.161875] ffffffff81d0bfa0 ffffffff81d0bfa8 ffffffff00000000 ffffffff81d0bff0
> > Jul 12 07:29:25 rawhide kernel: [ 241.163096] Call Trace:
> > Jul 12 07:29:25 rawhide kernel: [ 241.163460] [<ffffffff817377e9>] schedule+0x29/0x70
> > Jul 12 07:29:25 rawhide kernel: [ 241.164235] [<ffffffff817392ad>] rwsem_down_write_failed+0xed/0x1a0
> > Jul 12 07:29:25 rawhide kernel: [ 241.165489] [<ffffffff810bb600>] ? update_cpu_load_active+0xb0/0xb0
> > Jul 12 07:29:25 rawhide kernel: [ 241.166267] [<ffffffff8137d503>] call_rwsem_down_write_failed+0x13/0x20
> > Jul 12 07:29:25 rawhide kernel: [ 241.166760] [<ffffffff81736aad>] ? down_write+0x9d/0xb2
> > Jul 12 07:29:25 rawhide kernel: [ 241.167189] [<ffffffff8162d975>] ? genl_lock_all+0x15/0x30
> > Jul 12 07:29:25 rawhide kernel: [ 241.167603] [<ffffffff8162d975>] genl_lock_all+0x15/0x30
>
> I reproduced that on qemu-kvm with rawhide LiveCD. Below more
> information gathered using sysrq:
>
> (qemu) [ 2458.110724] SysRq : Show Locks Held
> [ 2458.111347]
> [ 2458.111347] Showing all locks held in the system:
> [ 2458.111347] 1 lock held by NetworkManager/582:
> [ 2458.111347] #0: (cb_lock){++++++}, at: [<ffffffff8162bc79>] genl_rcv+0x19/0x40
> [ 2458.111347] 1 lock held by modprobe/603:
> [ 2458.111347] #0: (cb_lock){++++++}, at: [<ffffffff8162baa5>] genl_lock_all+0x15/0x30
> [ 2458.111347]
> [ 2458.111347] =============================================
> [ 2458.111347]
>
> (qemu) sendkey alt-sysrq-w
> (qemu) [ 2461.579457] SysRq : Show Blocked State
> [ 2461.580103] task PC stack pid father
> [ 2461.580103] NetworkManager D ffff880034b84500 4040 582 1 0x00000080
> [ 2461.580103] ffff8800197ff720 0000000000000046 00000000001d5340 ffff8800197fffd8
> [ 2461.580103] ffff8800197fffd8 00000000001d5340 ffff880019631700 7fffffffffffffff
> [ 2461.580103] ffff8800197ff880 ffff8800197ff878 ffff880019631700 ffff880019631700
> [ 2461.580103] Call Trace:
> [ 2461.580103] [<ffffffff817355f9>] schedule+0x29/0x70
> [ 2461.580103] [<ffffffff81731ad1>] schedule_timeout+0x1c1/0x360
> [ 2461.580103] [<ffffffff810e69eb>] ? mark_held_locks+0xbb/0x140
> [ 2461.580103] [<ffffffff817377ac>] ? _raw_spin_unlock_irq+0x2c/0x50
> [ 2461.580103] [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [ 2461.580103] [<ffffffff81736398>] wait_for_completion_killable+0xe8/0x170
> [ 2461.580103] [<ffffffff810b7fa0>] ? wake_up_state+0x20/0x20
> [ 2461.580103] [<ffffffff81095825>] call_usermodehelper_exec+0x1a5/0x210
> [ 2461.580103] [<ffffffff817362ed>] ? wait_for_completion_killable+0x3d/0x170
> [ 2461.580103] [<ffffffff81095cc3>] __request_module+0x1b3/0x370
> [ 2461.580103] [<ffffffff810e6b6d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
> [ 2461.580103] [<ffffffff8162c5c9>] ctrl_getfamily+0x159/0x190
> [ 2461.580103] [<ffffffff8162d8a4>] genl_family_rcv_msg+0x1f4/0x2e0
> [ 2461.580103] [<ffffffff8162d990>] ? genl_family_rcv_msg+0x2e0/0x2e0
> [ 2461.580103] [<ffffffff8162da1e>] genl_rcv_msg+0x8e/0xd0
> [ 2461.580103] [<ffffffff8162b729>] netlink_rcv_skb+0xa9/0xc0
> [ 2461.580103] [<ffffffff8162bc88>] genl_rcv+0x28/0x40
> [ 2461.580103] [<ffffffff8162ad6d>] netlink_unicast+0xdd/0x190
> [ 2461.580103] [<ffffffff8162b149>] netlink_sendmsg+0x329/0x750
> [ 2461.580103] [<ffffffff815db849>] sock_sendmsg+0x99/0xd0
> [ 2461.580103] [<ffffffff810bb58f>] ? local_clock+0x5f/0x70
> [ 2461.580103] [<ffffffff810e96e8>] ? lock_release_non_nested+0x308/0x350
> [ 2461.580103] [<ffffffff815dbc6e>] ___sys_sendmsg+0x39e/0x3b0
> [ 2461.580103] [<ffffffff810565af>] ? kvm_clock_read+0x2f/0x50
> [ 2461.580103] [<ffffffff810218b9>] ? sched_clock+0x9/0x10
> [ 2461.580103] [<ffffffff810bb2bd>] ? sched_clock_local+0x1d/0x80
> [ 2461.580103] [<ffffffff810bb448>] ? sched_clock_cpu+0xa8/0x100
> [ 2461.580103] [<ffffffff810e33ad>] ? trace_hardirqs_off+0xd/0x10
> [ 2461.580103] [<ffffffff810bb58f>] ? local_clock+0x5f/0x70
> [ 2461.580103] [<ffffffff810e3f7f>] ? lock_release_holdtime.part.28+0xf/0x1a0
> [ 2461.580103] [<ffffffff8120fec9>] ? fget_light+0xf9/0x510
> [ 2461.580103] [<ffffffff8120fe0c>] ? fget_light+0x3c/0x510
> [ 2461.580103] [<ffffffff815dd1d2>] __sys_sendmsg+0x42/0x80
> [ 2461.580103] [<ffffffff815dd222>] SyS_sendmsg+0x12/0x20
> [ 2461.580103] [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b
> [ 2461.580103] modprobe D ffff88000f2c8000 4632 603 602 0x00000080
> [ 2461.580103] ffff88000f04fba8 0000000000000046 00000000001d5340 ffff88000f04ffd8
> [ 2461.580103] ffff88000f04ffd8 00000000001d5340 ffff8800377d4500 ffff8800377d4500
> [ 2461.580103] ffffffff81d0b260 ffffffff81d0b268 ffffffff00000000 ffffffff81d0b2b0
> [ 2461.580103] Call Trace:
> [ 2461.580103] [<ffffffff817355f9>] schedule+0x29/0x70
> [ 2461.580103] [<ffffffff81736d4d>] rwsem_down_write_failed+0xed/0x1a0
> [ 2461.580103] [<ffffffff810bb200>] ? update_cpu_load_active+0x10/0xb0
> [ 2461.580103] [<ffffffff8137b473>] call_rwsem_down_write_failed+0x13/0x20
> [ 2461.580103] [<ffffffff8173492d>] ? down_write+0x9d/0xb2
> [ 2461.580103] [<ffffffff8162baa5>] ? genl_lock_all+0x15/0x30
> [ 2461.580103] [<ffffffff8162baa5>] genl_lock_all+0x15/0x30
> [ 2461.580103] [<ffffffff8162cbb3>] genl_register_family+0x53/0x1f0
> [ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
> [ 2461.580103] [<ffffffff8162d650>] genl_register_family_with_ops+0x20/0x80
> [ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
> [ 2461.580103] [<ffffffffa017fe84>] nl80211_init+0x24/0xf0 [cfg80211]
> [ 2461.580103] [<ffffffffa01dc000>] ? 0xffffffffa01dbfff
> [ 2461.580103] [<ffffffffa01dc043>] cfg80211_init+0x43/0xdb [cfg80211]
> [ 2461.580103] [<ffffffff810020fa>] do_one_initcall+0xfa/0x1b0
> [ 2461.580103] [<ffffffff8105cb93>] ? set_memory_nx+0x43/0x50
> [ 2461.580103] [<ffffffff810f75af>] load_module+0x1c6f/0x27f0
> [ 2461.580103] [<ffffffff810f2c90>] ? store_uevent+0x40/0x40
> [ 2461.580103] [<ffffffff810f82c6>] SyS_finit_module+0x86/0xb0
> [ 2461.580103] [<ffffffff81741ad9>] system_call_fastpath+0x16/0x1b
> [ 2461.580103] Sched Debug Version: v0.10, 3.11.0-0.rc1.git4.1.fc20.x86_64 #1
>
> So call user space to load cfg80211 module (alias
> net-pf-16-proto-16-family-nl80211) from ctrl_getfamily() with read taken
> cb_lock semaphore. That deadlock in modprobe process in
> genl_register_family() when try to down_write cb_lock.
>
> This is consequence of commit:
>
> commit fb4e156886ce6e8309e912d8b370d192330d19d3
> Author: Marcel Holtmann <marcel@holtmann.org>
> Date: Sun Apr 28 16:22:06 2013 -0700
>
> nl80211: Add generic netlink module alias for cfg80211/nl80211
>
> I prepared a possible fix for that (patch below), but I'm not sure if it
> do right thing, it can cause other oddity, please test (with
> CONFIG_LOCKDEP compiled). I think I would prefer rather remove
> autoloading genetlink modules from kernel or use just one lock
> in instead of two cb_lock & genl_mutex .
>
> Stanislaw
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 2fd6dbe..1076fe1 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -877,8 +877,10 @@ static int ctrl_getfamily(struct sk_buff *skb, struct genl_info *info)
> #ifdef CONFIG_MODULES
> if (res == NULL) {
> genl_unlock();
> + up_read(&cb_lock);
> request_module("net-pf-%d-proto-%d-family-%s",
> PF_NETLINK, NETLINK_GENERIC, name);
> + down_read(&cb_lock);
> genl_lock();
> res = genl_family_find_byname(name);
> }
The patch above fixes the problem for me. I'll leave it to others to
decide whether it's the best approach.
Thanks!
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply
* pull request: bluetooth 2013-07-25
From: Gustavo Padovan @ 2013-07-25 13:05 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
Hi John,
A few fixes and devices ID additions for 3.11:
* There are 3 new ath3k device ids
* Fixed stack memory usage in ath3k.
* Fixed the init process of BlueFRITZ! devices, they were failing to init
due to an unsupported command we sent.
* Fixed wrong use of PTR_ERR in btusb code that was preventing intel devices
to work properly
* Fixed race codition between hci_register_dev() and hci_dev_open() that
could cause a NULL pointer dereference.
Please pull or let me know of any issues. Thanks.
Gustavo
--
The following changes since commit 57bf74407bd501b0599568a3112fc16395b575d9:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth (2013-06-24 13:53:15 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth for-upstream
for you to fetch changes up to 352c3b276ca7e2df479cd0b9b87d227f14efb20a:
Bluetooth: Fix race between hci_register_dev() and hci_dev_open() (2013-07-25 13:55:59 +0100)
----------------------------------------------------------------
AceLan Kao (1):
Bluetooth: Add support for Atheros [0cf3:3121]
Adam Lee (1):
Bluetooth: fix wrong use of PTR_ERR() in btusb
Gustavo Padovan (1):
Bluetooth: Fix race between hci_register_dev() and hci_dev_open()
Johan Hedberg (1):
Bluetooth: Fix HCI init for BlueFRITZ! devices
Stanislaw Gruszka (1):
Bluetooth: ath3k: don't use stack memory for DMA
Sujith Manoharan (1):
Bluetooth: ath3k: Add support for ID 0x13d3/0x3402
Thomas Loo (1):
Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]
drivers/bluetooth/ath3k.c | 44 +++++++++++++++++++++++++++++++++++---------
drivers/bluetooth/btusb.c | 17 ++++++++++-------
net/bluetooth/hci_core.c | 16 ++++++++--------
3 files changed, 53 insertions(+), 24 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* How to read WiFi radio frequency.
From: KATSUMI masanori @ 2013-07-25 12:02 UTC (permalink / raw)
To: linux-wireless
I am trying to make p2p software with the current device as the group
owner.
I would like to acquire the channel that GO started, from normal user(NOT
root).
How can I get this information?
^ permalink raw reply
* AR5008 "Failed to stop TX DMA"
From: Sergei Antonov @ 2013-07-25 11:18 UTC (permalink / raw)
To: linux-wireless
Hello!
I use "Atheros Communications Inc. AR5008 Wireless Network Adapter
(rev 01)" PCI card.
The following messages appear in my console approx. once in a minute.
cfg80211: Calling CRDA to update world regulatory domain
ath: phy0: Failed to stop TX DMA, queues=0x001!
wlan0: authenticate with 00:15:af:xx:xx:xx
wlan0: send auth to 00:15:af:xx:xx:xx (try 1/3)
wlan0: authenticated
ath9k 0000:03:06.0 wlan0: disabling HT as WMM/QoS is not supported by the AP
ath9k 0000:03:06.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP
wlan0: associate with 00:15:af:xx:xx:xx (try 1/3)
wlan0: RX AssocResp from 00:15:af:xx:xx:xx (capab=0x411 status=0 aid=3)
wlan0: associated
The connection to WPA access point works, although SSH freezes
regulary for several seconds.
I'm running an x86_64 kernel version 3.10.2. But earlier versions had
the same problem too.
Please, help me to fix that.
^ permalink raw reply
* [PATCH] ath10k: implement get_survey()
From: Michal Kazior @ 2013-07-25 11:06 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
This implements a limited subset of what can be
reported in the survey dump.
This can be used for assessing approximate channel
load, e.g. for automatic channel selection.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.h | 6 +++
drivers/net/wireless/ath/ath10k/mac.c | 36 +++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 68 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 3 ++
4 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 9f21ecb..e1cd1e7 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -38,6 +38,7 @@
#define ATH10K_SCAN_ID 0
#define WMI_READY_TIMEOUT (5 * HZ)
#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
+#define ATH10K_NUM_CHANS 38
/* Antenna noise floor */
#define ATH10K_DEFAULT_NOISE_FLOOR -95
@@ -374,6 +375,11 @@ struct ath10k {
struct work_struct restart_work;
+ /* cycle count is reported twice for each visited channel during scan */
+ u32 survey_last_rx_clear_count;
+ u32 survey_last_cycle_count;
+ struct survey_info survey[ATH10K_NUM_CHANS];
+
#ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
#endif
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d0a7761..5d4ce96 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2934,6 +2934,41 @@ static void ath10k_restart_complete(struct ieee80211_hw *hw)
mutex_unlock(&ar->conf_mutex);
}
+static int ath10k_get_survey(struct ieee80211_hw *hw, int idx,
+ struct survey_info *survey)
+{
+ struct ath10k *ar = hw->priv;
+ struct ieee80211_supported_band *sband;
+ struct survey_info *ar_survey = &ar->survey[idx];
+ int ret = 0;
+
+ mutex_lock(&ar->conf_mutex);
+
+ sband = hw->wiphy->bands[IEEE80211_BAND_2GHZ];
+ if (sband && idx >= sband->n_channels) {
+ idx -= sband->n_channels;
+ sband = NULL;
+ }
+
+ if (!sband)
+ sband = hw->wiphy->bands[IEEE80211_BAND_5GHZ];
+
+ if (!sband || idx >= sband->n_channels) {
+ ret = -ENOENT;
+ goto exit;
+ }
+
+ spin_lock_bh(&ar->data_lock);
+ memcpy(survey, ar_survey, sizeof(*survey));
+ spin_unlock_bh(&ar->data_lock);
+
+ survey->channel = &sband->channels[idx];
+
+exit:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_tx,
.start = ath10k_start,
@@ -2955,6 +2990,7 @@ static const struct ieee80211_ops ath10k_ops = {
.flush = ath10k_flush,
.tx_last_beacon = ath10k_tx_last_beacon,
.restart_complete = ath10k_restart_complete,
+ .get_survey = ath10k_get_survey,
#ifdef CONFIG_PM
.suspend = ath10k_suspend,
.resume = ath10k_resume,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 5e42460..cb59235 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -390,9 +390,75 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
return 0;
}
+static int freq_to_idx(struct ath10k *ar, int freq)
+{
+ struct ieee80211_supported_band *sband;
+ int band, ch, idx = 0;
+
+ for (band = IEEE80211_BAND_2GHZ; band < IEEE80211_NUM_BANDS; band++) {
+ sband = ar->hw->wiphy->bands[band];
+ if (!sband)
+ continue;
+
+ for (ch = 0; ch < sband->n_channels; ch++, idx++)
+ if (sband->channels[ch].center_freq == freq)
+ goto exit;
+ }
+
+exit:
+ return idx;
+}
+
static void ath10k_wmi_event_chan_info(struct ath10k *ar, struct sk_buff *skb)
{
- ath10k_dbg(ATH10K_DBG_WMI, "WMI_CHAN_INFO_EVENTID\n");
+ struct wmi_chan_info_event *ev;
+ int idx;
+
+ spin_lock_bh(&ar->data_lock);
+
+ ev = (struct wmi_chan_info_event *)skb->data;
+ ath10k_dbg(ATH10K_DBG_WMI,
+ "chan info: err_code:%d freq:%d cmd_flags:%d noise_floor:%d rx_clear_count:%d cycle_count:%d\n",
+ __le32_to_cpu(ev->err_code),
+ __le32_to_cpu(ev->freq),
+ __le32_to_cpu(ev->cmd_flags),
+ __le32_to_cpu(ev->noise_floor),
+ __le32_to_cpu(ev->rx_clear_count),
+ __le32_to_cpu(ev->cycle_count));
+
+ if (!ar->scan.in_progress) {
+ ath10k_warn("chan info event without a scan request?\n");
+ goto exit;
+ }
+
+ if (__le32_to_cpu(ev->cmd_flags) & WMI_CHAN_INFO_FLAG_COMPLETE) {
+ idx = freq_to_idx(ar, __le32_to_cpu(ev->freq));
+ if (idx >= ARRAY_SIZE(ar->survey)) {
+ ath10k_warn("chan info: invalid frequency %d (idx %d out of bounds)\n",
+ __le32_to_cpu(ev->freq), idx);
+ } else {
+ /* During scanning chan info is reported twice for each
+ * visited channel. The reported cycle count is global
+ * and per-channel cycle count must be calculated */
+
+ ar->survey[idx].channel_time += WMI_CHAN_INFO_MSEC(
+ __le32_to_cpu(ev->cycle_count) -
+ ar->survey_last_cycle_count);
+ ar->survey[idx].channel_time_rx += WMI_CHAN_INFO_MSEC(
+ __le32_to_cpu(ev->rx_clear_count) -
+ ar->survey_last_rx_clear_count);
+ ar->survey[idx].noise = __le32_to_cpu(ev->noise_floor);
+ ar->survey[idx].filled = SURVEY_INFO_CHANNEL_TIME |
+ SURVEY_INFO_CHANNEL_TIME_RX |
+ SURVEY_INFO_NOISE_DBM;
+ }
+ }
+
+ ar->survey_last_rx_clear_count = __le32_to_cpu(ev->rx_clear_count);
+ ar->survey_last_cycle_count = __le32_to_cpu(ev->cycle_count);
+
+exit:
+ spin_unlock_bh(&ar->data_lock);
}
static void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index da3b2bc..4acff47 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2931,6 +2931,9 @@ struct wmi_chan_info_event {
__le32 cycle_count;
} __packed;
+#define WMI_CHAN_INFO_FLAG_COMPLETE BIT(0)
+#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595) /* XXX: empirically extrapolated */
+
/* Beacon filter wmi command info */
#define BCN_FLT_MAX_SUPPORTED_IES 256
#define BCN_FLT_MAX_ELEMS_IE_LIST (BCN_FLT_MAX_SUPPORTED_IES / 32)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] mac80211: use oneshot blink API for LED triggers
From: Fabio Baltieri @ 2013-07-25 10:00 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, linux-wireless, netdev, linux-kernel,
Fabio Baltieri
Change mac80211 LED trigger code to use the generic
led_trigger_blink_oneshot() API for transmit and receive activity
indication.
This gives a better feedback to the user, as with the new API each
activity event results in a visible blink, while a constant traffic
results in a continuous blink at constant rate.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
---
Changes from v1:
- fixed some wrong indentations
net/mac80211/ieee80211_i.h | 1 -
net/mac80211/led.c | 19 +++++++------------
net/mac80211/led.h | 2 +-
net/mac80211/status.c | 2 +-
net/mac80211/tx.c | 1 -
5 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 8412a30..1178139 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1063,7 +1063,6 @@ struct ieee80211_local {
u32 dot11TransmittedFrameCount;
#ifdef CONFIG_MAC80211_LEDS
- int tx_led_counter, rx_led_counter;
struct led_trigger *tx_led, *rx_led, *assoc_led, *radio_led;
struct tpt_led_trigger *tpt_led_trigger;
char tx_led_name[32], rx_led_name[32],
diff --git a/net/mac80211/led.c b/net/mac80211/led.c
index bcffa69..e2b8364 100644
--- a/net/mac80211/led.c
+++ b/net/mac80211/led.c
@@ -12,27 +12,22 @@
#include <linux/export.h>
#include "led.h"
+#define MAC80211_BLINK_DELAY 50 /* ms */
+
void ieee80211_led_rx(struct ieee80211_local *local)
{
+ unsigned long led_delay = MAC80211_BLINK_DELAY;
if (unlikely(!local->rx_led))
return;
- if (local->rx_led_counter++ % 2 == 0)
- led_trigger_event(local->rx_led, LED_OFF);
- else
- led_trigger_event(local->rx_led, LED_FULL);
+ led_trigger_blink_oneshot(local->rx_led, &led_delay, &led_delay, 0);
}
-/* q is 1 if a packet was enqueued, 0 if it has been transmitted */
-void ieee80211_led_tx(struct ieee80211_local *local, int q)
+void ieee80211_led_tx(struct ieee80211_local *local)
{
+ unsigned long led_delay = MAC80211_BLINK_DELAY;
if (unlikely(!local->tx_led))
return;
- /* not sure how this is supposed to work ... */
- local->tx_led_counter += 2*q-1;
- if (local->tx_led_counter % 2 == 0)
- led_trigger_event(local->tx_led, LED_OFF);
- else
- led_trigger_event(local->tx_led, LED_FULL);
+ led_trigger_blink_oneshot(local->tx_led, &led_delay, &led_delay, 0);
}
void ieee80211_led_assoc(struct ieee80211_local *local, bool associated)
diff --git a/net/mac80211/led.h b/net/mac80211/led.h
index e0275d9..6ca2f29 100644
--- a/net/mac80211/led.h
+++ b/net/mac80211/led.h
@@ -13,7 +13,7 @@
#ifdef CONFIG_MAC80211_LEDS
void ieee80211_led_rx(struct ieee80211_local *local);
-void ieee80211_led_tx(struct ieee80211_local *local, int q);
+void ieee80211_led_tx(struct ieee80211_local *local);
void ieee80211_led_assoc(struct ieee80211_local *local,
bool associated);
void ieee80211_led_radio(struct ieee80211_local *local,
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 4343920..e3c889b 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -557,7 +557,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
rcu_read_unlock();
- ieee80211_led_tx(local, 0);
+ ieee80211_led_tx(local);
/* SNMP counters
* Fragments are passed to low-level drivers as separate skbs, so these
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 4105d0c..6c4e60d 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1281,7 +1281,6 @@ static bool __ieee80211_tx(struct ieee80211_local *local,
txpending);
ieee80211_tpt_led_trig_tx(local, fc, led_len);
- ieee80211_led_tx(local, 1);
WARN_ON_ONCE(!skb_queue_empty(skbs));
--
1.8.2
^ permalink raw reply related
* Re: [PATCH] mac80211: use oneshot blink API for LED triggers
From: Fabio Baltieri @ 2013-07-25 9:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1374739101.8827.7.camel@jlt4.sipsolutions.net>
On Thu, Jul 25, 2013 at 09:58:21AM +0200, Johannes Berg wrote:
> > So, are you definitely rejecting this patch or should I fix indentation
> > and send a v2?
>
> I think I'll take it, I kinda hope nobody will really care much about it
> but the behaviour looks better and the code is simpler, so ... :)
Good enough... I'll send the v2 then. :-)
Thanks,
Fabio
--
Fabio Baltieri
^ permalink raw reply
* Re: [PATCH] mac80211: use oneshot blink API for LED triggers
From: Johannes Berg @ 2013-07-25 7:58 UTC (permalink / raw)
To: Fabio Baltieri; +Cc: John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130724085337.GA7096@balto.lan>
On Wed, 2013-07-24 at 10:53 +0200, Fabio Baltieri wrote:
> On Wed, Jul 24, 2013 at 10:14:25AM +0200, Johannes Berg wrote:
> > On Wed, 2013-07-24 at 02:09 +0200, Fabio Baltieri wrote:
> > > Changes mac80211 LED trigger code to use the generic
> > > led_trigger_blink_oneshot() API for transmit and receive activity
> > > indication.
> > >
> > > This gives a better feedback to the user, as with the new API each
> > > activity event results in a visible blink, while a constant traffic
> > > results in a continuous blink at constant rate.
> >
> > This seems a little pointless since our throughput-based trigger can do
> > very similar (but somewhat better) behaviour? Maybe that should just be
> > the default instead, with some sane default setup values?
>
> Ok but that requires driver specific support and it's only implemented
> on a subset of currently available drivers.
Not necessarily, it's just done that way because we expected everyone to
have their own idea of what the blink speeds should be, possibly even
depending on the maximum speed the hardware can do etc.
> This at least makes the basic tx/rx indication capability a better.
Fair enough.
> > (Regardless of that, you also have indentation problems in your patch)
>
> Ok, I guess you are referring to the this:
>
> + led_trigger_blink_oneshot(local->tx_led,
> + &led_delay, &led_delay, 0);
Yes, that was the place I noticed, didn't check more closely.
> So, are you definitely rejecting this patch or should I fix indentation
> and send a v2?
I think I'll take it, I kinda hope nobody will really care much about it
but the behaviour looks better and the code is simpler, so ... :)
johannes
^ permalink raw reply
* Re: [PATCH 1/2] regulatory: use correct regulatory initiator on wiphy register
From: Johannes Berg @ 2013-07-25 7:53 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1374413809-26005-1-git-send-email-arik@wizery.com>
On Sun, 2013-07-21 at 16:36 +0300, Arik Nemtsov wrote:
> The current regdomain was not always set by the core. This causes
> cards with a custom regulatory domain to ignore user initiated changes
> if done before the card was registered.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH 33/36] net: rfkill: convert class code to use dev_groups
From: Johannes Berg @ 2013-07-25 7:52 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, John W. Linville, linux-wireless, netdev
In-Reply-To: <1374703539-9705-34-git-send-email-gregkh@linuxfoundation.org>
On Wed, 2013-07-24 at 15:05 -0700, Greg Kroah-Hartman wrote:
> The dev_attrs field of struct class is going away soon, dev_groups
> should be used instead. This converts the rfkill class code to use the
> correct field.
>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>
> Johnannes, feel free to take this through your tree, or ACK it and I can
> take it through mine.
Looks good to me, go ahead and take it, we're not going to modify this
code.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
johannes
^ permalink raw reply
* Re: [PATCH 32/36] net: wireless: convert class code to use dev_groups
From: Johannes Berg @ 2013-07-25 7:50 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, John W. Linville, linux-wireless, netdev
In-Reply-To: <1374703539-9705-33-git-send-email-gregkh@linuxfoundation.org>
On Wed, 2013-07-24 at 15:05 -0700, Greg Kroah-Hartman wrote:
> The dev_attrs field of struct class is going away soon, dev_groups
> should be used instead. This converts the networking wireless class
> code to use the correct field.
>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: John W. Linville <linville@tuxdriver.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>
> John, feel free to take this through your tree, or ACK it and I can take
> it through mine.
It's cfg80211 so it should be me, but I don't expect any conflicts so
please take it.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
johannes
^ permalink raw reply
* Re: pull request: wireless 2013-07-24
From: David Miller @ 2013-07-25 7:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130724180400.GF2385@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 24 Jul 2013 14:04:01 -0400
> This is another batch of fixes intended for the 3.11 stream. FWIW,
> this is the first request with fixes from the mac80211 and iwlwifi
> trees as well.
Pulled, thanks John.
^ permalink raw reply
* [PATCH 33/36] net: rfkill: convert class code to use dev_groups
From: Greg Kroah-Hartman @ 2013-07-24 22:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, Johannes Berg, John W. Linville,
linux-wireless, netdev
In-Reply-To: <1374703539-9705-1-git-send-email-gregkh@linuxfoundation.org>
The dev_attrs field of struct class is going away soon, dev_groups
should be used instead. This converts the rfkill class code to use the
correct field.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Johnannes, feel free to take this through your tree, or ACK it and I can
take it through mine.
net/rfkill/core.c | 90 +++++++++++++++++++++++++------------------------------
1 file changed, 41 insertions(+), 49 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 1cec5e4f..1bacc107 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -576,14 +576,14 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool hw)
}
EXPORT_SYMBOL(rfkill_set_states);
-static ssize_t rfkill_name_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t name_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct rfkill *rfkill = to_rfkill(dev);
return sprintf(buf, "%s\n", rfkill->name);
}
+static DEVICE_ATTR_RO(name);
static const char *rfkill_get_type_str(enum rfkill_type type)
{
@@ -611,54 +611,52 @@ static const char *rfkill_get_type_str(enum rfkill_type type)
}
}
-static ssize_t rfkill_type_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t type_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct rfkill *rfkill = to_rfkill(dev);
return sprintf(buf, "%s\n", rfkill_get_type_str(rfkill->type));
}
+static DEVICE_ATTR_RO(type);
-static ssize_t rfkill_idx_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t index_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct rfkill *rfkill = to_rfkill(dev);
return sprintf(buf, "%d\n", rfkill->idx);
}
+static DEVICE_ATTR_RO(index);
-static ssize_t rfkill_persistent_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t persistent_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct rfkill *rfkill = to_rfkill(dev);
return sprintf(buf, "%d\n", rfkill->persistent);
}
+static DEVICE_ATTR_RO(persistent);
-static ssize_t rfkill_hard_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t hard_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct rfkill *rfkill = to_rfkill(dev);
return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_HW) ? 1 : 0 );
}
+static DEVICE_ATTR_RO(hard);
-static ssize_t rfkill_soft_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t soft_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct rfkill *rfkill = to_rfkill(dev);
return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_SW) ? 1 : 0 );
}
-static ssize_t rfkill_soft_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t soft_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
{
struct rfkill *rfkill = to_rfkill(dev);
unsigned long state;
@@ -680,6 +678,7 @@ static ssize_t rfkill_soft_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(soft);
static u8 user_state_from_blocked(unsigned long state)
{
@@ -691,18 +690,16 @@ static u8 user_state_from_blocked(unsigned long state)
return RFKILL_USER_STATE_UNBLOCKED;
}
-static ssize_t rfkill_state_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t state_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct rfkill *rfkill = to_rfkill(dev);
return sprintf(buf, "%d\n", user_state_from_blocked(rfkill->state));
}
-static ssize_t rfkill_state_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t state_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
{
struct rfkill *rfkill = to_rfkill(dev);
unsigned long state;
@@ -725,32 +722,27 @@ static ssize_t rfkill_state_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(state);
-static ssize_t rfkill_claim_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t claim_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
return sprintf(buf, "%d\n", 0);
}
-
-static ssize_t rfkill_claim_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
- return -EOPNOTSUPP;
-}
-
-static struct device_attribute rfkill_dev_attrs[] = {
- __ATTR(name, S_IRUGO, rfkill_name_show, NULL),
- __ATTR(type, S_IRUGO, rfkill_type_show, NULL),
- __ATTR(index, S_IRUGO, rfkill_idx_show, NULL),
- __ATTR(persistent, S_IRUGO, rfkill_persistent_show, NULL),
- __ATTR(state, S_IRUGO|S_IWUSR, rfkill_state_show, rfkill_state_store),
- __ATTR(claim, S_IRUGO|S_IWUSR, rfkill_claim_show, rfkill_claim_store),
- __ATTR(soft, S_IRUGO|S_IWUSR, rfkill_soft_show, rfkill_soft_store),
- __ATTR(hard, S_IRUGO, rfkill_hard_show, NULL),
- __ATTR_NULL
+static DEVICE_ATTR_RO(claim);
+
+static struct attribute *rfkill_dev_attrs[] = {
+ &dev_attr_name.attr,
+ &dev_attr_type.attr,
+ &dev_attr_index.attr,
+ &dev_attr_persistent.attr,
+ &dev_attr_state.attr,
+ &dev_attr_claim.attr,
+ &dev_attr_soft.attr,
+ &dev_attr_hard.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(rfkill_dev);
static void rfkill_release(struct device *dev)
{
@@ -830,7 +822,7 @@ static int rfkill_resume(struct device *dev)
static struct class rfkill_class = {
.name = "rfkill",
.dev_release = rfkill_release,
- .dev_attrs = rfkill_dev_attrs,
+ .dev_groups = rfkill_dev_groups,
.dev_uevent = rfkill_dev_uevent,
.suspend = rfkill_suspend,
.resume = rfkill_resume,
--
1.8.3.rc0.20.gb99dd2e
^ permalink raw reply related
* [PATCH 32/36] net: wireless: convert class code to use dev_groups
From: Greg Kroah-Hartman @ 2013-07-24 22:05 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, Johannes Berg, John W. Linville,
linux-wireless, netdev
In-Reply-To: <1374703539-9705-1-git-send-email-gregkh@linuxfoundation.org>
The dev_attrs field of struct class is going away soon, dev_groups
should be used instead. This converts the networking wireless class
code to use the correct field.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
John, feel free to take this through your tree, or ACK it and I can take
it through mine.
net/wireless/sysfs.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/net/wireless/sysfs.c b/net/wireless/sysfs.c
index a23253e0..9ee6bc1a 100644
--- a/net/wireless/sysfs.c
+++ b/net/wireless/sysfs.c
@@ -30,7 +30,8 @@ static ssize_t name ## _show(struct device *dev, \
char *buf) \
{ \
return sprintf(buf, fmt "\n", dev_to_rdev(dev)->member); \
-}
+} \
+static DEVICE_ATTR_RO(name)
SHOW_FMT(index, "%d", wiphy_idx);
SHOW_FMT(macaddress, "%pM", wiphy.perm_addr);
@@ -42,7 +43,7 @@ static ssize_t name_show(struct device *dev,
struct wiphy *wiphy = &dev_to_rdev(dev)->wiphy;
return sprintf(buf, "%s\n", dev_name(&wiphy->dev));
}
-
+static DEVICE_ATTR_RO(name);
static ssize_t addresses_show(struct device *dev,
struct device_attribute *attr,
@@ -60,15 +61,17 @@ static ssize_t addresses_show(struct device *dev,
return buf - start;
}
-
-static struct device_attribute ieee80211_dev_attrs[] = {
- __ATTR_RO(index),
- __ATTR_RO(macaddress),
- __ATTR_RO(address_mask),
- __ATTR_RO(addresses),
- __ATTR_RO(name),
- {}
+static DEVICE_ATTR_RO(addresses);
+
+static struct attribute *ieee80211_attrs[] = {
+ &dev_attr_index.attr,
+ &dev_attr_macaddress.attr,
+ &dev_attr_address_mask.attr,
+ &dev_attr_addresses.attr,
+ &dev_attr_name.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(ieee80211);
static void wiphy_dev_release(struct device *dev)
{
@@ -146,7 +149,7 @@ struct class ieee80211_class = {
.name = "ieee80211",
.owner = THIS_MODULE,
.dev_release = wiphy_dev_release,
- .dev_attrs = ieee80211_dev_attrs,
+ .dev_groups = ieee80211_groups,
.dev_uevent = wiphy_uevent,
#ifdef CONFIG_PM
.suspend = wiphy_suspend,
--
1.8.3.rc0.20.gb99dd2e
^ permalink raw reply related
* Re: interested in py80211?
From: Arend van Spriel @ 2013-07-24 21:06 UTC (permalink / raw)
To: Will Hawkins; +Cc: Johannes Berg, linux-wireless, Thomas Graf
In-Reply-To: <51EFF8FC.8070101@opentechinstitute.org>
On 07/24/2013 05:55 PM, Will Hawkins wrote:
> Thanks for posting about this effort. I would be very interested in
> helping out on development. I will stay up-to-date on things via your
> github page. Otherwise, please continue to keep the list updated on your
> progress.
Thanks, Will
Based on feedback from Johannes I have taken a bit different approach. I
submitted some patches to libnl adding the SWIG api for python there.
Thomas took those patches recently. So the idea is to do the rest of the
nl80211 specific stuff in Python. I am looking into pycparser as I would
like to extract certain code fragments from nl80211.[ch] so keeping
py80211 in sync with nl80211 can be automated.
Regards,
Arend
> On 07/12/2013 09:32 AM, Arend van Spriel wrote:
>> On 07/12/13 10:02, Johannes Berg wrote:
>>> Yep, I'd totally be interested. Not that I don't have enough things on
>>> my plate already ;-)
>>>
>>> On Wed, 2013-07-03 at 22:57 +0200, Arend van Spriel wrote:
>>>> A common say in Linux arena is "when you have an itch, just scratch it".
>>>
>>> :-)
>>>
>>>> My itch is that tools like ifconfig and iw are great, but in an
>>>> automated test environment it kind of sucks to parse output, which is
>>>> confirmed by blurb from iw: "Do NOT screenscrape this tool, we don't
>>>> consider its output stable.".
>>>
>>> Heh, yeah ...
>>>
>>>> Ever since my first contact with Python I tend to favor it over other
>>>> scripting alternatives so I decided to scratch my itch with that and
>>>> another old acquaintance called SWIG. With those I went to create
>>>> py80211. A first attempt was to have SWIG create a wrapper API directly
>>>> exposing the libnl-3 API, but that did not feel comfortable in a
>>>> scripting environment. So the level of abstraction is a bit higher. It
>>>> is just in a kick-off state (eg. can only send u32 attributes), but I
>>>> decided to push it to github anyway.
>>>
>>> Another approach might be exposing the libnl APIs and then build a
>>> higher-level library in python. Have you considered that? That might
>>> make it useful to other users of netlink as well, while keeping a 'nice'
>>> nl80211 API?
>>
>> I am still at that fork in the road and not sure about it. The libnl
>> project itself already has libnl stuff exposed in a python lib being the
>> core api and route. So I could go and add genl support to that and build
>> the high-level python library from there.
>>
>> Regards,
>> Arend
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: IBSS-RSN support for BCM4313
From: Arend van Spriel @ 2013-07-24 20:57 UTC (permalink / raw)
To: Jordan McCarthy; +Cc: linux-wireless
In-Reply-To: <51EFC944.40502@opentechinstitute.org>
On 07/24/2013 02:32 PM, Jordan McCarthy wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Linux wireless folk,
> I am a developer at a non-profit working on a wireless mesh networking
> platform, and we've just discovered that we have a fleet of netbooks
> with the Broadcom 4313 chipset, one that does not work particularly well
> (and sometimes not at all) in ad-hoc mode.
For certain variants of that chipset the brcmsmac driver does not
perform well regardless the mode it is in. So could you provide some
more details on the bcm4313 chipset. Can you provide contents from
/sys/kernel/debug/brcmsmac/bcma*/hardware (if that is the correct path).
Regards,
Arend
^ 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