* [ath3k] Support for Asus BT USB dongle (0cf3:3005)
From: Daniel Kamil Kozar @ 2013-10-02 17:59 UTC (permalink / raw)
To: linux-wireless
Hello,
The Bluetooth dongle installed inside my Asus K53SV laptop seems to be
unsupported. The USB VID:PID is 0cf3:3005, and it's identified by
lsusb as the following :
Bus 001 Device 006: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
However, I didn't see the VID:PID mentioned anywhere in the source of
ath3k. After adding the device's identifier to the source, thus
forcing it to be recognized as an "Atheros AR3011 with sflash
firmware", I got the following message from the driver :
ath3k: probe of 1-1.1:1.0 failed with error -32
How could I help with developing the support for this device?
Kind regards,
-dkk
^ permalink raw reply
* Re: [PATCH v2] mac80211: implement STA CSA for drivers using channel contexts
From: Johannes Berg @ 2013-10-02 16:20 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless
In-Reply-To: <1378044951-13682-1-git-send-email-arik@wizery.com>
On Sun, 2013-09-01 at 17:15 +0300, Arik Nemtsov wrote:
> Limit the current implementation to a single channel context used by
> a single vif, thereby avoiding multi-vif/channel complexities.
>
> Reuse the main function from AP CSA code, but move a portion out in
> order to fit the STA scenario.
>
> Add a new mac80211 HW flag so we don't break devices that don't support
> channel switch with channel-contexts. The new behavior will be opt-in.
Applied, sorry for the delay.
johannes
^ permalink raw reply
* Re: [PATCH 2/4] nl80211/cfg80211: enable DFS for IBSS mode
From: Johannes Berg @ 2013-10-02 16:07 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <20131002124006.GA23903@pandem0nium>
On Wed, 2013-10-02 at 14:40 +0200, Simon Wunderlich wrote:
> > > NL80211_ATTR_CONTROL_PORT_DFS attribute when joining the IBSS.
> >
> > I don't like that name, it makes no sense. This has nothing to do with
> > the port control (802.1X-style) at all.
>
> How about NL80211_ATTR_DFS_CAPABLE instead?
That seems also confusing, like a hardware capability or something...
Maybe rather "NL80211_ATTR_HANDLE_DFS" or something?
> Yeah, I should document this a little more: Userspace should react to
> radar events and apprioately switch the channel when this happens. As
> non-capable tools (like wpa_supplicant in it's current state) do not
> react on radar events but might select DFS channels when available, there
> might be non-conforming behaviour. Therefore I'm introducing this flag.
>
> Userspace programs are supposed to set this flag when they have channel
> management and radar avoidance/channel change functionality is implemented
> to unlock DFS channels.
I think we may we want some safeguard, e.g. only give the userspace a
second or so to react and tear down the IBSS otherwise? Even with
userspace that is capable of handling it, it could have crashed and the
IBSS will continue operating in that case since we don't tear down the
IBSS when it crashes. Or we could do that, require userspace to keep the
nl80211 socket open, but the timing seems easier?
> I can resend the patchset with some more documentation on this.
Thanks.
johannes
^ permalink raw reply
* pull-request: iwlwifi-fixes 2013-10-02
From: Johannes Berg @ 2013-10-02 16:04 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]
John,
Here are a few fixes for iwlwifi.
I have a fix for WoWLAN/D3, a PCIe device fix, we're removing a warning,
there's a fix for RF-kill while scanning (which goes together with a
mac80211 fix) and last but not least we have many new PCI IDs.
Let me know if there's any problem.
johannes
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git for-john
for you to fetch changes up to 5a3e9f7f8c8768b5f7df81100c684e4cd00a6eb5:
iwlwifi: mvm: call ieee80211_scan_completed when needed (2013-10-02 11:25:50 +0200)
----------------------------------------------------------------
Alexander Bondar (1):
iwlwifi: mvm: Disable uAPSD for D3 image
Emmanuel Grumbach (4):
iwlwifi: pcie: don't reset the TX queue counter
iwlwifi: don't WARN on host commands sent when firmware is dead
iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series
iwlwifi: mvm: call ieee80211_scan_completed when needed
Matti Gottlieb (1):
iwlwifi: pcie: add new SKUs for 7000 & 3160 NIC series
drivers/net/wireless/iwlwifi/iwl-6000.c | 6 +++++
drivers/net/wireless/iwlwifi/iwl-config.h | 1 +
drivers/net/wireless/iwlwifi/iwl-trans.h | 6 +++--
drivers/net/wireless/iwlwifi/mvm/power.c | 5 +++-
drivers/net/wireless/iwlwifi/mvm/scan.c | 12 ++++++++-
drivers/net/wireless/iwlwifi/pcie/drv.c | 42 +++++++++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/pcie/tx.c | 2 ++
7 files changed, 70 insertions(+), 4 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 13:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380718874.13329.17.camel@jlt4.sipsolutions.net>
I am testing some personal hostapd changes in order to add CAC/NOP
management using methods added by Simon
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Wed, 2013-10-02 at 14:52 +0200, Lorenzo Bianconi wrote:
>> I am not using latest mac80211/hostapd (in particular
>> compat-wireless-2013-04-16/hostapd-20130807) because I have to port
>> some personal stuff. In this scenario I was not able to establish an
>> AP/STA connection on DFS channel. Anyway I will update these packages.
>
> But that old hostapd doesn't support DFS to start with, does it? I'm
> confused.
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Johannes Berg @ 2013-10-02 13:01 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <CAA2SeNLFSN0tAyABk=MoFDxS6purc6Tgx6R-U5xhuRJZRCZ6ig@mail.gmail.com>
On Wed, 2013-10-02 at 14:52 +0200, Lorenzo Bianconi wrote:
> I am not using latest mac80211/hostapd (in particular
> compat-wireless-2013-04-16/hostapd-20130807) because I have to port
> some personal stuff. In this scenario I was not able to establish an
> AP/STA connection on DFS channel. Anyway I will update these packages.
But that old hostapd doesn't support DFS to start with, does it? I'm
confused.
johannes
^ permalink raw reply
* [PATCH] net: wireless: wl1251: update firmware path
From: Felipe Balbi @ 2013-10-02 13:00 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless, Linux Kernel Mailing List, Felipe Balbi
TI firmwares are located under ti-connectivity
directory. Update path to make sure driver can
find and load firmware blob.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/net/wireless/ti/wl1251/wl1251.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h b/drivers/net/wireless/ti/wl1251/wl1251.h
index fd02060..2c3bd1b 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -424,8 +424,8 @@ void wl1251_disable_interrupts(struct wl1251 *wl);
#define CHIP_ID_1271_PG10 (0x4030101)
#define CHIP_ID_1271_PG20 (0x4030111)
-#define WL1251_FW_NAME "wl1251-fw.bin"
-#define WL1251_NVS_NAME "wl1251-nvs.bin"
+#define WL1251_FW_NAME "ti-connectivity/wl1251-fw.bin"
+#define WL1251_NVS_NAME "ti-connectivity/wl1251-nvs.bin"
#define WL1251_POWER_ON_SLEEP 10 /* in milliseconds */
--
1.8.3.4.840.g6a90778
^ permalink raw reply related
* Re: [PATCH] ath10k: fix scheduling while atomic bug on config
From: Kalle Valo @ 2013-10-02 13:00 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQnQVE_YUrrtfFCeQSj4tmccbA9cG_ZMdHisx4C-mJfqkg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 2 October 2013 11:51, Michal Kazior <michal.kazior@tieto.com> wrote:
>> Recent WMI/HTC changes introduces this bug because
>> now WMI commands can sleep.
>>
>> Use appropriate interface iteration function.
>>
>> Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Self NACK.
>
> I've posted this too soon. This patch can lead to deadlocks on
> iflist_mtx in some cases.
Ok, thanks for letting me know. I'll drop the patch from my queue.
--
Kalle Valo
^ permalink raw reply
* [GIT PULL] firmware: wl1251 firmware binary
From: Felipe Balbi @ 2013-10-02 12:55 UTC (permalink / raw)
To: Felipe Balbi, dwmw2, ben
Cc: Luca Coelho, ben, Linux Kernel Mailing List, linux-wireless,
Pavel Machek
In-Reply-To: <20130925135943.GI10746@radagast>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
Hi,
here's a pull request for wl4 firmware. I'll send a patch for wl1251
driver updating firmware load path.
The following changes since commit b8ac7c7e27dcd13fa3c843aaf62457e9c57ea4db:
linux-firmware: Add Brocade FC/FCOE Adapter firmware files (2013-09-30 04:53:32 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware.git wilink4
for you to fetch changes up to d726804dbc8dad88587b6be17716714cd91ed86c:
ti-connectivity: add wl1251 firmware and license (2013-10-02 06:55:39 -0500)
----------------------------------------------------------------
Felipe Balbi (1):
ti-connectivity: add wl1251 firmware and license
LICENCE.wl1251 | 59 +++++++++++++++++++++++++++++++++++++++++
WHENCE | 18 +++++++++++++
ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes
ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes
4 files changed, 77 insertions(+)
create mode 100644 LICENCE.wl1251
create mode 100644 ti-connectivity/wl1251-fw.bin
create mode 100644 ti-connectivity/wl1251-nvs.bin
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 12:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380708715.13329.16.camel@jlt4.sipsolutions.net>
I am not using latest mac80211/hostapd (in particular
compat-wireless-2013-04-16/hostapd-20130807) because I have to port
some personal stuff. In this scenario I was not able to establish an
AP/STA connection on DFS channel. Anyway I will update these packages.
Lorenzo
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
>> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
>> is CAC checked and available calling cfg80211_secondary_chans_ok().
>> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
>> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
>> frames on DFS channels causing association failures.
>
> I don't see how this can cause association failures? Please explain.
> DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
> more.
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [PATCH 2/4] nl80211/cfg80211: enable DFS for IBSS mode
From: Simon Wunderlich @ 2013-10-02 12:40 UTC (permalink / raw)
To: Johannes Berg
Cc: Simon Wunderlich, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1380625757.14430.22.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Tue, Oct 01, 2013 at 01:09:17PM +0200, Johannes Berg wrote:
> On Tue, 2013-09-03 at 19:43 +0200, Simon Wunderlich wrote:
> > To use DFS in IBSS mode, userspace is required to react to radar events.
> > It can inform nl80211 that it is capable of doing so by adding a
> > NL80211_ATTR_CONTROL_PORT_DFS attribute when joining the IBSS.
>
> I don't like that name, it makes no sense. This has nothing to do with
> the port control (802.1X-style) at all.
>
How about NL80211_ATTR_DFS_CAPABLE instead?
> > If this attribute is supplied, DFS channels may be used if the driver
> > supports it. Support will be checked even if a channel without DFS will
> > be joined, as the channel might change later due to scan activity or
> > channel switch announcements.
>
> You also really should document *what* is required of userspace here.
> You're kinda saying this needs to be implemented, but not saying what
> needs to be done. I can't even tell - what does it really have to do?
Yeah, I should document this a little more: Userspace should react to
radar events and apprioately switch the channel when this happens. As
non-capable tools (like wpa_supplicant in it's current state) do not
react on radar events but might select DFS channels when available, there
might be non-conforming behaviour. Therefore I'm introducing this flag.
Userspace programs are supposed to set this flag when they have channel
management and radar avoidance/channel change functionality is implemented
to unlock DFS channels.
> Don't you implement most of it in patches 3 and 4 anyway in the kernel?
Nope, I don't.
I can resend the patchset with some more documentation on this.
Thanks,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH for-3.12 2/3] bcma: make bcma_core_pci_{up,down}() callable from atomic context
From: Hauke Mehrtens @ 2013-10-02 11:53 UTC (permalink / raw)
To: Arend van Spriel, John W. Linville
Cc: linux-wireless, stable, Tod Jackson, Joe Perches, Rafal Milecki
In-Reply-To: <1380103864-10447-3-git-send-email-arend@broadcom.com>
On 09/25/2013 12:11 PM, Arend van Spriel wrote:
> This patch removes the bcma_core_pci_power_save() call from
> the bcma_core_pci_{up,down}() functions as it tries to schedule
> thus requiring to call them from non-atomic context. The function
> bcma_core_pci_power_save() is now exported so the calling module
> can explicitly use it in non-atomic context. This fixes the
> 'scheduling while atomic' issue reported by Tod Jackson and
> Joe Perches.
>
> [ 13.210710] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
> [ 13.210718] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
> [ 13.210756] CPU: 2 PID: 1800 Comm: dhcpcd Not tainted 3.11.0-wl #1
> [ 13.210762] Hardware name: Alienware M11x R2/M11x R2, BIOS A04 11/23/2010
> [ 13.210767] ffff880177c92c40 ffff880170fd1948 ffffffff8169af5b 0000000000000007
> [ 13.210777] ffff880170fd1ab0 ffff880170fd1958 ffffffff81697ee2 ffff880170fd19d8
> [ 13.210785] ffffffff816a19f5 00000000000f4240 000000000000d080 ffff880170fd1fd8
> [ 13.210794] Call Trace:
> [ 13.210813] [<ffffffff8169af5b>] dump_stack+0x4f/0x84
> [ 13.210826] [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
> [ 13.210837] [<ffffffff816a19f5>] __schedule+0x6e5/0x810
> [ 13.210845] [<ffffffff816a1c34>] schedule+0x24/0x70
> [ 13.210855] [<ffffffff816a04fc>] schedule_hrtimeout_range_clock+0x10c/0x150
> [ 13.210867] [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
> [ 13.210877] [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
> [ 13.210887] [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
> [ 13.210897] [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
> [ 13.210910] [<ffffffffa00371af>] bcma_pcie_mdio_set_phy.isra.3+0x4f/0x80 [bcma]
> [ 13.210921] [<ffffffffa003729f>] bcma_pcie_mdio_write.isra.4+0xbf/0xd0 [bcma]
> [ 13.210932] [<ffffffffa0037498>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x18/0x30 [bcma]
> [ 13.210942] [<ffffffffa00374ee>] bcma_core_pci_power_save+0x3e/0x80 [bcma]
> [ 13.210953] [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
> [ 13.210975] [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
> [ 13.210989] [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
> [ 13.211003] [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340 [brcmsmac]
> [ 13.211020] [<ffffffff81600a12>] ? cfg80211_netdev_notifier_call+0xd2/0x5f0
> [ 13.211030] [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
> [ 13.211064] [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
> [ 13.211076] [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
> [ 13.211086] [<ffffffff81657b41>] ieee80211_open+0x71/0x80
> [ 13.211101] [<ffffffff81526267>] __dev_open+0x87/0xe0
> [ 13.211109] [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
> [ 13.211117] [<ffffffff815266a3>] dev_change_flags+0x23/0x70
> [ 13.211127] [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
> [ 13.211136] [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
> [ 13.211147] [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
> [ 13.211155] [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
> [ 13.211169] [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
> [ 13.211180] [<ffffffff8113f159>] ? ____fput+0x9/0x10
> [ 13.211198] [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
> [ 13.211202] [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
> [ 13.211208] [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b
> [ 13.211217] NOHZ: local_softirq_pending 202
>
> The issue was introduced in v3.11 kernel by following commit:
>
> commit aa51e598d04c6acf5477934cd6383f5a17ce9029
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date: Sat Aug 24 00:32:31 2013 +0200
>
> brcmsmac: use bcma PCIe up and down functions
>
> replace the calls to bcma_core_pci_extend_L1timer() by calls to the
> newly introduced bcma_core_pci_ip() and bcma_core_pci_down()
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> Cc: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> This fix has been discussed with Hauke Mehrtens [1] selection
> option 3) and is intended for v3.12.
>
> Ref:
> [1] http://mid.gmane.org/5239B12D.3040206@hauke-m.de
>
> Cc: <stable@vger.kernel.org> # 3.11.x
> Cc: Tod Jackson <tod.jackson@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Rafal Milecki <zajec5@gmail.com>
> Cc: Hauke Mehrtens <hauke@hauke-m.de>
> Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
> Signed-off-by: Arend van Spriel <arend@broadcom.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Hi,
This is a little late but I am ok with the brcmsmac patch and the bcma
patch, feel free to add my Acked-by. This should go into 3.12 and 3.13+.
Hauke
^ permalink raw reply
* Re: [PATCH v2] mac80211: implement STA CSA for drivers using channel contexts
From: Arik Nemtsov @ 2013-10-02 11:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfdy2VdnTa55YJMQHTc+bj-oBUuSb1rT0nKbLKK7BZrSjQ@mail.gmail.com>
On Sun, Sep 29, 2013 at 10:06 AM, Arik Nemtsov <arik@wizery.com> wrote:
> On Sun, Sep 1, 2013 at 5:15 PM, Arik Nemtsov <arik@wizery.com> wrote:
>> Limit the current implementation to a single channel context used by
>> a single vif, thereby avoiding multi-vif/channel complexities.
>>
>> Reuse the main function from AP CSA code, but move a portion out in
>> order to fit the STA scenario.
>>
>> Add a new mac80211 HW flag so we don't break devices that don't support
>> channel switch with channel-contexts. The new behavior will be opt-in.
>>
>> Signed-off-by: Arik Nemtsov <arik@wizery.com>
>
> Ping?
Ping 2 :)
(Just saw your email on the list urging pings)
Arik
^ permalink raw reply
* Re: [PATCH] ath10k: fix scheduling while atomic bug on config
From: Michal Kazior @ 2013-10-02 11:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380707467-30387-1-git-send-email-michal.kazior@tieto.com>
On 2 October 2013 11:51, Michal Kazior <michal.kazior@tieto.com> wrote:
> Recent WMI/HTC changes introduces this bug because
> now WMI commands can sleep.
>
> Use appropriate interface iteration function.
>
> Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Self NACK.
I've posted this too soon. This patch can lead to deadlocks on
iflist_mtx in some cases.
Michał
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Johannes Berg @ 2013-10-02 10:11 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <CAA2SeN+nhLU7vGDNLJCD=UrNRSFm5hT6HGEEhUqr1kAcMF3O-A@mail.gmail.com>
On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
> is CAC checked and available calling cfg80211_secondary_chans_ok().
> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
> frames on DFS channels causing association failures.
I don't see how this can cause association failures? Please explain.
DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
more.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380704100.13329.6.camel@jlt4.sipsolutions.net>
Before start beaconing cfg80211_reg_can_beacon() verifies the channel
is CAC checked and available calling cfg80211_secondary_chans_ok().
Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
frames on DFS channels causing association failures.
Lorenzo
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Mon, 2013-09-30 at 14:52 +0200, Lorenzo Bianconi wrote:
>> Allow management frame injection on DFS channels if the channel has been CAC
>> checked and is available
>
>> +++ b/net/mac80211/tx.c
>> @@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
>> * radar detection by itself. We can do that later by adding a
>> * monitor flag interfaces used for AP support.
>> */
>> - if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
>> - IEEE80211_CHAN_PASSIVE_SCAN)))
>> + if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
>> + IEEE80211_CHAN_NO_IBSS))) ||
>> + ((chan->flags & IEEE80211_CHAN_RADAR) &&
>> + chan->dfs_state != NL80211_DFS_AVAILABLE))
>
> This would be the only place where mac80211 is accessing
> chan->dfs_state, does that make sense? Why is it not needed elsewhere?
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* [PATCH] ath10k: fix scheduling while atomic bug on config
From: Michal Kazior @ 2013-10-02 9:51 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Recent WMI/HTC changes introduces this bug because
now WMI commands can sleep.
Use appropriate interface iteration function.
Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 8684e03..b65df84 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1935,9 +1935,8 @@ static void ath10k_config_ps(struct ath10k *ar)
memset(&ar_iter, 0, sizeof(struct ath10k_generic_iter));
ar_iter.ar = ar;
- ieee80211_iterate_active_interfaces_atomic(
- ar->hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_ps_iter, &ar_iter);
+ ieee80211_iterate_active_interfaces(ar->hw, IEEE80211_IFACE_ITER_NORMAL,
+ ath10k_ps_iter, &ar_iter);
if (ar_iter.ret)
ath10k_warn("failed to set ps config (%d)\n", ar_iter.ret);
@@ -2840,9 +2839,8 @@ static int ath10k_set_rts_threshold(struct ieee80211_hw *hw, u32 value)
ar_iter.ar = ar;
mutex_lock(&ar->conf_mutex);
- ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_set_rts_iter, &ar_iter);
+ ieee80211_iterate_active_interfaces(hw, IEEE80211_IFACE_ITER_NORMAL,
+ ath10k_set_rts_iter, &ar_iter);
mutex_unlock(&ar->conf_mutex);
return ar_iter.ret;
@@ -2881,9 +2879,8 @@ static int ath10k_set_frag_threshold(struct ieee80211_hw *hw, u32 value)
ar_iter.ar = ar;
mutex_lock(&ar->conf_mutex);
- ieee80211_iterate_active_interfaces_atomic(
- hw, IEEE80211_IFACE_ITER_NORMAL,
- ath10k_set_frag_iter, &ar_iter);
+ ieee80211_iterate_active_interfaces(hw, IEEE80211_IFACE_ITER_NORMAL,
+ ath10k_set_frag_iter, &ar_iter);
mutex_unlock(&ar->conf_mutex);
return ar_iter.ret;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] rt2x00: rt2800lib: fix RF registers for RT5390/RT5392
From: Kevin Lo @ 2013-10-02 9:46 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users
Update rf registers to use the same values that the MediaTek/Ralink
reference driver DPO_RT5572_LinuxSTA_2.6.1.3_20121022 uses.
References:
RF5390RegTable in chips/rt5390.c
RF5392RegTable in chips/rt5390.c
Tested on TP-Link TL-WN727N and D-Link DWA-140 Rev.b3 usb wifi dongles.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
---
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c
b/drivers/net/wireless/rt2x00/rt2800lib.c
index f414978..0bbd1b5 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6449,7 +6449,7 @@ static void rt2800_init_rfcsr_5390(struct
rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 28, 0x00);
rt2800_rfcsr_write(rt2x00dev, 29, 0x10);
- rt2800_rfcsr_write(rt2x00dev, 30, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 30, 0x10);
rt2800_rfcsr_write(rt2x00dev, 31, 0x80);
rt2800_rfcsr_write(rt2x00dev, 32, 0x80);
rt2800_rfcsr_write(rt2x00dev, 33, 0x00);
@@ -6487,7 +6487,7 @@ static void rt2800_init_rfcsr_5390(struct
rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 56, 0x22);
rt2800_rfcsr_write(rt2x00dev, 57, 0x80);
rt2800_rfcsr_write(rt2x00dev, 58, 0x7f);
- rt2800_rfcsr_write(rt2x00dev, 59, 0x63);
+ rt2800_rfcsr_write(rt2x00dev, 59, 0x8f);
rt2800_rfcsr_write(rt2x00dev, 60, 0x45);
if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390F))
@@ -6507,7 +6507,6 @@ static void rt2800_init_rfcsr_5392(struct
rt2x00_dev *rt2x00dev)
rt2800_rf_init_calibration(rt2x00dev, 2);
rt2800_rfcsr_write(rt2x00dev, 1, 0x17);
- rt2800_rfcsr_write(rt2x00dev, 2, 0x80);
rt2800_rfcsr_write(rt2x00dev, 3, 0x88);
rt2800_rfcsr_write(rt2x00dev, 5, 0x10);
rt2800_rfcsr_write(rt2x00dev, 6, 0xe0);
^ permalink raw reply related
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: Johannes Berg @ 2013-10-02 9:41 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
In-Reply-To: <1380531766-15384-1-git-send-email-johannes@sipsolutions.net>
On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> The merge b35c8097 seems to have lost commit eabc4ac5d,
> put the code back.
I'm rebasing my tree on -rc1, which actually includes the merge commit,
so it still makes sense for me to include this commit - I've done that
now. Sorry for the confusion.
johannes
^ permalink raw reply
* Re: iwlegacy: iwl4965 reload firmware issue.
From: Stanislaw Gruszka @ 2013-10-02 9:19 UTC (permalink / raw)
To: Matt Chen; +Cc: linux-wireless, kvoz123
In-Reply-To: <CALx5=V_voRtb_e=9BFhNmt7rLO4v5iQKdZ0NCyZATtYCOUh7JA@mail.gmail.com>
On Tue, Oct 01, 2013 at 04:17:44PM +0800, Matt Chen wrote:
> The restart path is through il_irq_handle_error(il). My question is if
> this is a firmware issue, driver issue or hardware issue ?
Most likely driver issue, microcode error usually mean that driver provide
wrong values to the firmware or differently abuse firmware work.
Stanislaw
^ permalink raw reply
* Re: [PATCH] rt2x00_pci: Fix interrupt handler name (visible at /proc/interrupts)
From: Stanislaw Gruszka @ 2013-10-02 9:16 UTC (permalink / raw)
To: Kirill Tkhai; +Cc: linux-wireless, ivdoorn, gwingerde, helmut.schaa
In-Reply-To: <459361380660046@web2g.yandex.ru>
On Wed, Oct 02, 2013 at 12:40:46AM +0400, Kirill Tkhai wrote:
> Currently driver name is wrong. PCI device address is visible at
> /proc/interrupts instead of the name:
>
> 43: 124 0 0 0 PCI-MSI-edge rtsx_pci
> 44: 384 0 0 0 PCI-MSI-edge snd_hda_intel
> 45: 25096 0 0 0 PCI-MSI-edge 0000:01:00.0
> ^^^^^^^^^^^^
>
> So, pass the right name. rt2x00_ops->name contains KBUILD_MODNAME
> and good for that, so pass it.
>
> Handler names will be "rt2500pci", "rt2500pci" etc.
Looks sane. I was afraid that is not possible to have two or more
interrupts with the same name, but that's not true.
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Stanislaw
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Johannes Berg @ 2013-10-02 9:08 UTC (permalink / raw)
To: Detlev Casanova; +Cc: Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <3913713.WUui18VufC@naboo>
On Sun, 2013-09-29 at 21:29 +0200, Detlev Casanova wrote:
> > So I'm not sure what's going on here, but I don't think NetworkManager
> > is the issue; it's likely in the supplicant's scanning code or in the
> > driver itself. NetworkManager asks the supplicant to scan with both the
> > wildcard SSID and any hidden-tagged SSID, and the wildcard SSID should
> > ensure that all available APs are found.
>
> Yes and the problem is most likely to be in the driver because it doesn't
> occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8 ("cfg80211: use
> DS or HT operation IEs to determine BSS channel")
Does it work on a newer kernel if you revert that commit? I really see
nothing wrong with that commit ...
Failing all else, since I can't reproduce the issue, can you please
compare the output of "iw list" before and after the failure (on the
failing kernel)? Maybe all channels are marked disabled or something?
But that really should've been the same behaviour before the patch too.
Also, tracing would be good (trace-cmd record -e cfg80211 -e mac80211,
compress trace.dat and send it to me)
johannes
^ permalink raw reply
* cfg80211/mac80211 merging done
From: Johannes Berg @ 2013-10-02 9:06 UTC (permalink / raw)
To: linux-wireless
Since I was travelling and then got sick during/after, it took me a
quite a while to get through my email.
I believe I've now gone through everything and merged or replied to
everything. If you expected a reply on a patch something and I haven't
gotten to it until now, I probably lost it so you should resend or ping
me.
johannes
^ permalink raw reply
* Re: [PATCH V4] cfg80211: vlan priority handling in WMM
From: Johannes Berg @ 2013-10-02 9:05 UTC (permalink / raw)
To: cedric.voncken; +Cc: linux-wireless
In-Reply-To: <1377518692-30084-1-git-send-email-cedric.voncken@acksys.fr>
On Mon, 2013-08-26 at 14:04 +0200, cedric.voncken@acksys.fr wrote:
> From: cedric Voncken <cedric.voncken@acksys.fr>
>
> If the VLAN tci is set in skb->vlan_tci use the priority field to determine the WMM priority.
Applied, with a linebreak in that commit log. Your (unnecessary) resend
of this also didn't even apply because it was line-wrapped in the patch.
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: Provide per channel maximum regulatory transmit power
From: Helmut Schaa @ 2013-10-02 9:04 UTC (permalink / raw)
To: Johannes Berg, Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <1380703470.13329.1.camel@jlt4.sipsolutions.net>
On Wed, Oct 2, 2013 at 10:44 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2013-10-02 at 09:43 +0200, Helmut Schaa wrote:
>> In some cases its not only required to know the maximum transmit power
>> the hw is capable of. Instead, userspace (hostapd) might want to know
>> the maximum transmit power as defined in the current regulatory domain
>> (for example for 802.11d country IEs).
>
> Why wouldn't it use (the equivalent of) "iw reg get" for that?
Might be the more sane approach.
I noticed that hostapd generates 11d IEs based on the channel list it
reads from the kernel.
Thus restricting STAs to the max tx power the hw is capable of. Just
adding the max regulatory
tx power looked like an easy solution :)
Jouni, would you be ok with using the kernels regulatory domain for
11d IEs in hostapd?
Thanks,
Helmut
^ 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