* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Johannes Berg @ 2013-07-31 6:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Ben Greear, Paul Stewart, Felix Fietkau,
Jouni Malinen
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On Tue, 2013-07-30 at 17:53 -0700, Luis R. Rodriguez wrote:
> Folks,
>
> Back in 2009 Intel had put out a wifi-test tree [0] but that seems
> deprecated now. The git tree at least is gone. Can someone confirm if
> that's dead?
It is indeed dead.
> We later had Google present at the 2010 San Francisco
> wireless summit [1] their test infrastructure using autotest. Last I
> checked that stuff was not merged back upstream to autotest.
I don't think that's upstream, but it's certainly available as open
source from chromium.
> Can
> someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
> internal testing infrastructures that obviously are not open.
hwsim is really orthogonal here - it's a test driver to allow testing in
e.g. virtual machine environments as opposed to a real
testbed/screenroom, but it obviously doesn't provide any test
infrastructure.
johannes
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Johannes Berg @ 2013-07-31 6:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <20130730224809.GN17130@pogo>
On Tue, 2013-07-30 at 15:48 -0700, Luis R. Rodriguez wrote:
> Neat. Perhaps we need something that we can share with 802.11 or other
> hardare I highly doubt we're the only ones patching ROM. Don't we even
> patch up core CPUs? I'm wondering if firmware_class could be expanded to
> support serialized ROM patching. The biggest hurdle I see with splititng
> ROM patching from a single firmware is serializing that, addressing
> revision dependencies and of course kernel dependencies.
I don't really see what you're trying to get it so I arbitrarily picked
this ...
I think "ROM patching" like in BT and 802.11 are two completely
different things. In BT at least you have a common transport to the
device, a more-or-less common command set (HCI) etc. None of that exists
for wireless (today) so trying to find common ground between firmware
(patches) for different 802.11 hardware seems completely futile?
johannes
^ permalink raw reply
* Re: [PATCH 15/30] iwlwifi: mvm: reprobe device on firmware error during restart
From: Johannes Berg @ 2013-07-31 6:47 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEcZX8u5Fcsf7mbbso9O0krhLVgzdT9Ay8dxsv_T+_SOhQ@mail.gmail.com>
On Wed, 2013-07-31 at 00:56 +0300, Eliad Peller wrote:
> > + reprobe = kzalloc(sizeof(*reprobe), GFP_ATOMIC);
> > + if (!reprobe)
> > + return;
>
> missing module_put() :)
Doh, good catch. All the more reason to respin this pull request.
johannes
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2013-07-26
From: Johannes Berg @ 2013-07-31 6:48 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1374827327-3464-1-git-send-email-johannes@sipsolutions.net>
On Fri, 2013-07-26 at 10:28 +0200, Johannes Berg wrote:
> John,
>
> First -next pull request for iwlwifi.
I'll respin this, Eliad noticed one bug and we also found one.
johannes
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2013-07-26
From: Sedat Dilek @ 2013-07-31 6:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1375253292.8289.6.camel@jlt4.sipsolutions.net>
On Wed, Jul 31, 2013 at 8:48 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2013-07-26 at 10:28 +0200, Johannes Berg wrote:
>> John,
>>
>> First -next pull request for iwlwifi.
>
> I'll respin this, Eliad noticed one bug and we also found one.
>
BTW, johill which kill-bug-spray do you prefer?
It seems to be very effective... if it kills also real (alive) bugs
it's double-good.
- Sedat -
> johannes
>
> --
> 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: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-07-31 6:52 UTC (permalink / raw)
To: Christian Lamparter
Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless
In-Reply-To: <6066029.JHY9cn8Gkh@blech>
Am 28.07.2013 22:41, schrieb Christian Lamparter:
> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
>>> Am 28.07.2013 13:38, schrieb Christian Lamparter:
>>>
>>>>>>
>>>>>> Anyway, I tried the -next branch.
>>>>>>
>>>>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
>>>>>> Author: Oleksij Rempel <linux@rempel-privat.de>
>>>>>> Date: Wed Jul 24 10:26:18 2013 +0200
>>>>>>
>>>>>> k2_fw_usb_api: workaround for EP4 bug.
>>>>>>
>>>>>> but still, the device won't show up after autosuspend.
>>>>>
>>>>> Hm... firmware probably didn't rebooted before suspend. Did interface
>>>>> was up, before autosuspend? If no, you need latest wireles-testing -
>>>>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
>>>>> before rmmod.
>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>>>>
>>>> Furthermore, I did the same test with one of the ehci-only ports
>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
>>>> came back after autosuspend there.
>>>
>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
>>> work here :( Suddenly i have no more ideas.
>>>
>>> Sarah, it's your turn now.
>>
>> Christian,
>> can you please provide some more info about your xhci controller. I'll
>> try to get me same.
>
> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
> same setup will be difficult. However, since the uPD720200 was/is
> very popular, it should be very easy to find one. [It's probably
> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
> got a free 1x-pcie port you should be good.]
>
> Here's the lspci summary:
>
> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
> Subsystem: Hewlett-Packard Company Device [103c:1657]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 19
> Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: <access denied>
> Kernel driver in use: xhci_hcd
>
Thx... i purchased on random on ebay, will see what i get.
I know now why carl9170 don't triggering this bug. Carl uses EP4 as
Interrupt with packet size 64. ath9k-htc initially have EP4=Intr,
Interval=1, but will reconfigure it to Bulk, Interval=0.
It mean, before usb suspend EP4=Bulk, Interval=0 and after resume
EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may
be interval stay 0, and xhci will overfill usb buffer on adapter - at
least it looks so.
--
Regards,
Oleksij
^ permalink raw reply
* AP changed bandwidth, new config is ... changed bandwidth in a way we can't support - disconnect - why? (intel advanced-n 6250)
From: Arkadiusz Miskiewicz @ 2013-07-31 6:55 UTC (permalink / raw)
To: linux-wireless; +Cc: ilw
Hi.
What could be going on with WRT160NL access point, stock firmware that
my linux (3.10.4) with Intel Corporation Centrino Advanced-N + WiMAX 6250 [Kilmer Peak] (rev 2c)
cannot even connect? The same happened with my earlier Intel 5350 wifi card.
It basically reports:
[79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
[79477.496072] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
(note I have two wrt160nl here and problem happens with both)
Any hints on why "we can't support" configuration issued by this (common) AP?
[79474.704167] eth1: authenticate with 68:7f:74:06:b3:1b
[79474.708354] eth1: send auth to 68:7f:74:06:b3:1b (try 1/3)
[79474.710051] eth1: authenticated
[79474.712304] eth1: associate with 68:7f:74:06:b3:1b (try 1/3)
[79474.735808] eth1: RX AssocResp from 68:7f:74:06:b3:1b (capab=0x431 status=0 aid=1)
[79474.739952] eth1: associated
[79474.834786] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
[79474.834791] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
[79474.877910] cfg80211: Calling CRDA to update world regulatory domain
[79474.880204] cfg80211: World regulatory domain updated:
[79474.880208] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79474.880210] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880213] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880215] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[79474.880217] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880219] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880581] cfg80211: Calling CRDA for country: PL
[79474.884514] cfg80211: Regulatory domain changed to country: PL
[79474.884517] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79474.884520] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79474.884522] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79474.884524] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79474.884526] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[79474.884528] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[79477.468073] eth1: authenticate with 68:7f:74:06:b3:1b
[79477.472240] eth1: send auth to 68:7f:74:06:b3:1b (try 1/3)
[79477.473923] eth1: authenticated
[79477.476176] eth1: associate with 68:7f:74:06:b3:1b (try 1/3)
[79477.480118] eth1: RX AssocResp from 68:7f:74:06:b3:1b (capab=0x431 status=0 aid=1)
[79477.484355] eth1: associated
[79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
[79477.496072] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
[79477.506470] eth1: deauthenticating from 68:7f:74:06:b3:1b by local choice (reason=1)
[79477.506598] cfg80211: Calling CRDA to update world regulatory domain
[79477.512546] cfg80211: World regulatory domain updated:
[79477.512550] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79477.512553] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512556] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512558] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[79477.512560] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512562] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512884] cfg80211: Calling CRDA for country: PL
[79477.516800] cfg80211: Regulatory domain changed to country: PL
[79477.516803] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79477.516806] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79477.516808] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79477.516810] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79477.516812] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[79477.516814] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[79480.234322] eth1: authenticate with 68:7f:74:06:b6:75
[79480.234333] eth1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[79480.238466] eth1: send auth to 68:7f:74:06:b6:75 (try 1/3)
[79480.304305] eth1: send auth to 68:7f:74:06:b6:75 (try 2/3)
[79480.325316] eth1: send auth to 68:7f:74:06:b6:75 (try 3/3)
[79480.352770] eth1: authentication with 68:7f:74:06:b6:75 timed out
[79483.409516] eth1: authenticate with 68:7f:74:06:b6:75
[79483.409527] eth1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[79483.411562] eth1: direct probe to 68:7f:74:06:b6:75 (try 1/3)
[79483.612029] eth1: direct probe to 68:7f:74:06:b6:75 (try 2/3)
[79483.816045] eth1: direct probe to 68:7f:74:06:b6:75 (try 3/3)
[79484.020039] eth1: authentication with 68:7f:74:06:b6:75 timed out
--
Arkadiusz Miśkiewicz, arekm / maven.pl
^ permalink raw reply
* [PATCH 1/2] rtlwifi: rtl8192cu: fix function declaration header
From: Mark Schulte @ 2013-07-31 7:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry.Finger, Mark Schulte
Move rtl92cu_update_hal_rate_tbl declartion to hw.h to correspond with function
definition in hw.c
Signed-off-by: Mark Schulte <schultetwin@gmail.com>
---
drivers/net/wireless/rtlwifi/rtl8192cu/hw.h | 3 +++
drivers/net/wireless/rtlwifi/rtl8192cu/sw.h | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
index 8e3ec1e..0f7812e 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
@@ -109,5 +109,8 @@ void rtl92c_set_fw_joinbss_report_cmd(struct ieee80211_hw *hw, u8 mstatus);
void rtl92c_fill_h2c_cmd(struct ieee80211_hw *hw,
u8 element_id, u32 cmd_len, u8 *p_cmdbuffer);
bool rtl92cu_phy_mac_config(struct ieee80211_hw *hw);
+void rtl92cu_update_hal_rate_tbl(struct ieee80211_hw *hw,
+ struct ieee80211_sta *sta,
+ u8 rssi_level);
#endif
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
index 262e1e4..a1310ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
@@ -49,8 +49,5 @@ bool rtl92cu_phy_set_rf_power_state(struct ieee80211_hw *hw,
u32 rtl92cu_phy_query_rf_reg(struct ieee80211_hw *hw,
enum radio_path rfpath, u32 regaddr, u32 bitmask);
void rtl92cu_phy_set_bw_mode_callback(struct ieee80211_hw *hw);
-void rtl92cu_update_hal_rate_tbl(struct ieee80211_hw *hw,
- struct ieee80211_sta *sta,
- u8 rssi_level);
#endif
--
1.8.3.3
^ permalink raw reply related
* [PATCH 2/2] rtlwifi: sparse warnings: cast to restricted type
From: Mark Schulte @ 2013-07-31 7:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry.Finger, Mark Schulte
In-Reply-To: <1375254507-26154-1-git-send-email-schultetwin@gmail.com>
Adding type casts to suppress sparse warnings:
* warning: cast to restricted __le32/__le16
Signed-off-by: Mark Schulte <schultetwin@gmail.com>
---
drivers/net/wireless/rtlwifi/ps.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index 298b615..f646b75 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -688,7 +688,7 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void *data,
find_p2p_ie = true;
/*to find noa ie*/
while (ie + 1 < end) {
- noa_len = READEF2BYTE(&ie[1]);
+ noa_len = READEF2BYTE((__le16 *)&ie[1]);
if (ie + 3 + ie[1] > end)
return;
@@ -717,13 +717,13 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void *data,
READEF1BYTE(ie+index);
index += 1;
p2pinfo->noa_duration[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_interval[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_start_time[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
}
@@ -780,7 +780,7 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw, void *data,
RT_TRACE(rtlpriv, COMP_FW, DBG_LOUD, "action frame find P2P IE.\n");
/*to find noa ie*/
while (ie + 1 < end) {
- noa_len = READEF2BYTE(&ie[1]);
+ noa_len = READEF2BYTE((__le16 *)&ie[1]);
if (ie + 3 + ie[1] > end)
return;
@@ -809,13 +809,13 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw, void *data,
READEF1BYTE(ie+index);
index += 1;
p2pinfo->noa_duration[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_interval[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_start_time[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
}
--
1.8.3.3
^ permalink raw reply related
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Jouni Malinen @ 2013-07-31 7:25 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Ben Greear, Paul Stewart, Felix Fietkau
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On Tue, Jul 30, 2013 at 05:53:31PM -0700, Luis R. Rodriguez wrote:
> AFAICT mac80211_hwism should and likely already is used for a slew of
> core API changes / tests. Addressing testing using that shoud
> hopefully address tons of testings and find a lot of issues. We'd then
> just need vendors to replicate behaviour on top of their drivers. The
> core test stuff though still needs to be available.
I have automated tests running mainly from wpa_supplicant/hostapd
regression testing view point on top of mac80211_hwsim. The test cases
are in hostap.git:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=tests/hwsim;hb=HEAD
These tests are run automatically on all hostap.git commits in a simple
Buildbot setup: http://buildbot.w1.fi:8010/
There's currently 51 test cases covering relatively large set of basic
functionality (and various corner cases, too). I'm hoping to extend this
to cover all common use cases and lot of protocol conformance testing
for that matter. In addition, I use this for development time testing,
so new tests show up at the same time with new functionality.
These tests are currently run on top of a single cfg80211/mac80211
version that I'm updating manually every now and then. I have found
regressions on those components, too, and not just
wpa_supplicant/hostapd, so it would sound useful to get this running
automatically on cfg80211/mac80211 snapshots, too, to get faster reports
on regressions. My buildbot.w1.fi server is a very low-end virtual
server, so it won't be able to do this, but if someone has a bit more
beefier server available, it would be straightforward to extend this
type of Buildbot setup to trigger both on hostap.git and
wireless-testing.git commits to run the tests. The server would need to
be able to run kvm and build kernel.
Obviously mac80211_hwsim tests won't cover everything, but so far, I've
been quite happy with the coverage it can give for testing
wpa_supplicant, hostapd, cfg80211, and mac80211.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-31 7:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <1375253182.8289.3.camel@jlt4.sipsolutions.net>
On Tue, Jul 30, 2013 at 11:46 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2013-07-30 at 15:48 -0700, Luis R. Rodriguez wrote:
>
>> Neat. Perhaps we need something that we can share with 802.11 or other
>> hardare I highly doubt we're the only ones patching ROM. Don't we even
>> patch up core CPUs? I'm wondering if firmware_class could be expanded to
>> support serialized ROM patching. The biggest hurdle I see with splititng
>> ROM patching from a single firmware is serializing that, addressing
>> revision dependencies and of course kernel dependencies.
>
> I don't really see what you're trying to get it so I arbitrarily picked
> this ...
>
> I think "ROM patching" like in BT and 802.11 are two completely
> different things. In BT at least you have a common transport to the
> device, a more-or-less common command set (HCI) etc.
Sure.
> None of that exists
> for wireless (today) so trying to find common ground between firmware
> (patches) for different 802.11 hardware seems completely futile?
So long as we can gaurantee mobile drivers get fw updated as much as
is really needed in the industry great.
Luis
^ permalink raw reply
* Re: [PATCH 3.11] nl80211: fix another nl80211_fam.attrbuf race
From: Johannes Berg @ 2013-07-31 8:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Hutchings
In-Reply-To: <1375216722-31194-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2013-07-30 at 22:38 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This is similar to the race Linus had reported, but in this case
> it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy
> index in cb->args[0] as it is and thus parses the message over
> and over again instead of just once because 0 is the first valid
> wiphy index. Similar code in nl80211_testmode_dump() correctly
> offsets the wiphy_index by 1, do that here as well.
Applied.
johannes
^ permalink raw reply
* [PATCH 3.11] mac80211: don't wait for TX status forever
From: Johannes Berg @ 2013-07-31 8:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
TX status notification can get lost, or the frames could
get stuck on the queue, so don't wait for the callback
from the driver forever and instead time out after half
a second.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index fa19828..8a02018 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,10 +31,12 @@
#include "led.h"
#define IEEE80211_AUTH_TIMEOUT (HZ / 5)
+#define IEEE80211_AUTH_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_AUTH_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_AUTH_WAIT_ASSOC (HZ * 5)
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
+#define IEEE80211_ASSOC_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_ASSOC_MAX_TRIES 3
@@ -3412,10 +3414,13 @@ static int ieee80211_probe_auth(struct ieee80211_sub_if_data *sdata)
if (tx_flags == 0) {
auth_data->timeout = jiffies + IEEE80211_AUTH_TIMEOUT;
- ifmgd->auth_data->timeout_started = true;
+ auth_data->timeout_started = true;
run_again(sdata, auth_data->timeout);
} else {
- auth_data->timeout_started = false;
+ auth_data->timeout =
+ round_jiffies_up(jiffies + IEEE80211_AUTH_TIMEOUT_LONG);
+ auth_data->timeout_started = true;
+ run_again(sdata, auth_data->timeout);
}
return 0;
@@ -3452,7 +3457,11 @@ static int ieee80211_do_assoc(struct ieee80211_sub_if_data *sdata)
assoc_data->timeout_started = true;
run_again(sdata, assoc_data->timeout);
} else {
- assoc_data->timeout_started = false;
+ assoc_data->timeout =
+ round_jiffies_up(jiffies +
+ IEEE80211_ASSOC_TIMEOUT_LONG);
+ assoc_data->timeout_started = true;
+ run_again(sdata, assoc_data->timeout);
}
return 0;
--
1.8.0
^ permalink raw reply related
* [PATCH v3] ath10k: implement get_survey()
From: Michal Kazior @ 2013-07-31 8:32 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375081712-9697-1-git-send-email-michal.kazior@tieto.com>
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>
---
v3:
* fix warning print format
* bail out on invalid frequency earlier
* use temp vars for improved readability
* document survey stats vars are protected by data_lock
* use FIXME: instead of XXX:
v2: Do not sum up channel time. Each time a
channel is visited stats for that channel are
overwritten. This makes the behaviour
more consistent with ath9k.
drivers/net/wireless/ath/ath10k/core.h | 7 +++
drivers/net/wireless/ath/ath10k/mac.c | 36 +++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 75 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 5 +++
4 files changed, 122 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index ff42bb7..e4bba56 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
@@ -375,6 +376,12 @@ struct ath10k {
struct work_struct restart_work;
+ /* cycle count is reported twice for each visited channel during scan.
+ * access protected by data_lock */
+ 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 344ad27..9598646 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 1cbcb2e..55f90c7 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -390,9 +390,82 @@ 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;
+ struct survey_info *survey;
+ u32 err_code, freq, cmd_flags, noise_floor, rx_clear_count, cycle_count;
+ int idx;
+
+ ev = (struct wmi_chan_info_event *)skb->data;
+
+ err_code = __le32_to_cpu(ev->err_code);
+ freq = __le32_to_cpu(ev->freq);
+ cmd_flags = __le32_to_cpu(ev->cmd_flags);
+ noise_floor = __le32_to_cpu(ev->noise_floor);
+ rx_clear_count = __le32_to_cpu(ev->rx_clear_count);
+ cycle_count = __le32_to_cpu(ev->cycle_count);
+
+ 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",
+ err_code, freq, cmd_flags, noise_floor, rx_clear_count,
+ cycle_count);
+
+ spin_lock_bh(&ar->data_lock);
+
+ if (!ar->scan.in_progress) {
+ ath10k_warn("chan info event without a scan request?\n");
+ goto exit;
+ }
+
+ idx = freq_to_idx(ar, freq);
+ if (idx >= ARRAY_SIZE(ar->survey)) {
+ ath10k_warn("chan info: invalid frequency %d (idx %d out of bounds)\n",
+ freq, idx);
+ goto exit;
+ }
+
+ if (cmd_flags & WMI_CHAN_INFO_FLAG_COMPLETE) {
+ /* 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 */
+
+ cycle_count -= ar->survey_last_cycle_count;
+ rx_clear_count -= ar->survey_last_rx_clear_count;
+
+ survey = &ar->survey[idx];
+ survey->channel_time = WMI_CHAN_INFO_MSEC(cycle_count);
+ survey->channel_time_rx = WMI_CHAN_INFO_MSEC(rx_clear_count);
+ survey->noise = noise_floor;
+ survey->filled = SURVEY_INFO_CHANNEL_TIME |
+ SURVEY_INFO_CHANNEL_TIME_RX |
+ SURVEY_INFO_NOISE_DBM;
+ }
+
+ ar->survey_last_rx_clear_count = rx_clear_count;
+ ar->survey_last_cycle_count = 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..2c5a4f8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2931,6 +2931,11 @@ struct wmi_chan_info_event {
__le32 cycle_count;
} __packed;
+#define WMI_CHAN_INFO_FLAG_COMPLETE BIT(0)
+
+/* FIXME: empirically extrapolated */
+#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595)
+
/* 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
* Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Arend van Spriel @ 2013-07-31 8:39 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless, John W. Linville, John Greene
In-Reply-To: <bug-989269-351310-C5h8dsuOxB@bugzilla.redhat.com>
Hi Felix,
How are things in OpenWRT. I wanted to ask you something regarding a
defect I am looking at. Since kernel 3.9 several reports have been made
about a kernel panic in brcmsmac, ie. a divide-by-zero error.
Debugging the issue shows we end up with a rate with MCS index 110,
which is, well, impossible. As brcmsmac gets the rate info from
minstrel_ht I was wondering if we have an intergration issue here. I saw
around April patches about new API which may have been in the 3.9 time
frame and something subtly changed things for brcmsmac.
Regards,
Arend
-------- Original Message --------
Subject: [Bug 989269] Connecting to WLAN causes kernel panic
Date: Wed, 31 Jul 2013 08:11:41 +0000
From: <bugzilla@redhat.com>
To: <fedora-kernel-wireless-brcm80211@fedoraproject.org>
https://bugzilla.redhat.com/show_bug.cgi?id=989269
--- Comment #13 from Arend van Spriel <arend@broadcom.com> ---
(In reply to Chris from comment #12)
> Created attachment 780839 [details]
> dmesg | grep brcms when connecting to WLAN after patch 2
>
> During gathering this data I connected to the internet, was sitting for a
> while and then walked through a corridor in my university, so that the
> computer was connecting to different routers. Sat down there for
> significantly longer time. At the end I reconnected and disconnected.
> It seems to work stable, without any problems, but I haven't tried to use
> the connection for something heavier.
Thanks for the data. I observed two values that are invalid. ratespec
value 0
is invalid and the driver selects 1Mbps rate to do the calculation. The
other
value 134217838 is what triggers the divide-by-zero. The ratespec value is:
ratespec: 0x800006E
RATE 110 (rate value [unit: 500Kbps or MCS index])
MIMORATE 1 (RATE field represents MIMO MCS index)
This does not make sense, because MCS index can only go up to 32. I suspect
this should not be a mimo rate, but 54Mbps. Looking further how we end up in
this situation.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH 0/2] ath10k: implement checksum offloading
From: Michal Kazior @ 2013-07-31 8:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This patchset adds tx and rx checksum offloading
to ath10k driver.
I don't have any hard numbers but I did observe a
consistently sligthly better performance on AP135
+ ath10k. Nothing ground breaking though.
Michal Kazior (2):
ath10k: implement rx checksum offloading
ath10k: implement tx checksum offloading
drivers/net/wireless/ath/ath10k/htt_rx.c | 40 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
3 files changed, 44 insertions(+)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/2] ath10k: implement rx checksum offloading
From: Michal Kazior @ 2013-07-31 8:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260477-17030-1-git-send-email-michal.kazior@tieto.com>
HW supports L3/L4 rx checksum offloading.
This should reduce CPU load and improve
performance on slow host machines.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 40 ++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 04f08d9..e784c40 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -804,6 +804,37 @@ static bool ath10k_htt_rx_has_fcs_err(struct sk_buff *skb)
return false;
}
+static int ath10k_htt_rx_get_csum_state(struct sk_buff *skb)
+{
+ struct htt_rx_desc *rxd;
+ u32 flags, info;
+ bool is_ip4, is_ip6;
+ bool is_tcp, is_udp;
+ bool ip_csum_ok, tcpudp_csum_ok;
+
+ rxd = (void *)skb->data - sizeof(*rxd);
+ flags = __le32_to_cpu(rxd->attention.flags);
+ info = __le32_to_cpu(rxd->msdu_start.info1);
+
+ is_ip4 = !!(info & RX_MSDU_START_INFO1_IPV4_PROTO);
+ is_ip6 = !!(info & RX_MSDU_START_INFO1_IPV6_PROTO);
+ is_tcp = !!(info & RX_MSDU_START_INFO1_TCP_PROTO);
+ is_udp = !!(info & RX_MSDU_START_INFO1_UDP_PROTO);
+ ip_csum_ok = !(flags & RX_ATTENTION_FLAGS_IP_CHKSUM_FAIL);
+ tcpudp_csum_ok = !(flags & RX_ATTENTION_FLAGS_TCP_UDP_CHKSUM_FAIL);
+
+ if (!is_ip4 && !is_ip6)
+ return CHECKSUM_NONE;
+ if (!is_tcp && !is_udp)
+ return CHECKSUM_NONE;
+ if (!ip_csum_ok)
+ return CHECKSUM_NONE;
+ if (!tcpudp_csum_ok)
+ return CHECKSUM_NONE;
+
+ return CHECKSUM_UNNECESSARY;
+}
+
static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
struct htt_rx_indication *rx)
{
@@ -815,6 +846,7 @@ static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
u8 *fw_desc;
int i, j;
int ret;
+ int ip_summed;
memset(&info, 0, sizeof(info));
@@ -889,6 +921,11 @@ static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
continue;
}
+ /* The skb is not yet processed and it may be
+ * reallocated. Since the offload is in the original
+ * skb extract the checksum now and assign it later */
+ ip_summed = ath10k_htt_rx_get_csum_state(msdu_head);
+
info.skb = msdu_head;
info.fcs_err = ath10k_htt_rx_has_fcs_err(msdu_head);
info.signal = ATH10K_DEFAULT_NOISE_FLOOR;
@@ -914,6 +951,8 @@ static void ath10k_htt_rx_handler(struct ath10k_htt *htt,
if (ath10k_htt_rx_hdr_is_amsdu((void *)info.skb->data))
ath10k_dbg(ATH10K_DBG_HTT, "htt mpdu is amsdu\n");
+ info.skb->ip_summed = ip_summed;
+
ath10k_dbg_dump(ATH10K_DBG_HTT_DUMP, NULL, "htt mpdu: ",
info.skb->data, info.skb->len);
ath10k_process_rx(htt->ar, &info);
@@ -980,6 +1019,7 @@ static void ath10k_htt_rx_frag_handler(struct ath10k_htt *htt,
info.status = HTT_RX_IND_MPDU_STATUS_OK;
info.encrypt_type = MS(__le32_to_cpu(rxd->mpdu_start.info0),
RX_MPDU_START_INFO0_ENCRYPT_TYPE);
+ info.skb->ip_summed = ath10k_htt_rx_get_csum_state(info.skb);
if (tkip_mic_err) {
ath10k_warn("tkip mic error\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ath10k: implement tx checksum offloading
From: Michal Kazior @ 2013-07-31 8:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260477-17030-1-git-send-email-michal.kazior@tieto.com>
HW supports L3/L4 tx checksum offloading.
This should reduce CPU load and improve
performance on slow host machines.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index dc3f3e8..656c254 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -465,6 +465,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff *msdu)
flags1 = 0;
flags1 |= SM((u16)vdev_id, HTT_DATA_TX_DESC_FLAGS1_VDEV_ID);
flags1 |= SM((u16)tid, HTT_DATA_TX_DESC_FLAGS1_EXT_TID);
+ flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L3_OFFLOAD;
+ flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L4_OFFLOAD;
frags_paddr = ATH10K_SKB_CB(txfrag)->paddr;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 344ad27..5784337 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3309,6 +3309,8 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
ar->hw->wiphy->n_iface_combinations = 1;
+ ar->hw->netdev_features = NETIF_F_HW_CSUM;
+
ret = ath_regd_init(&ar->ath_common.regulatory, ar->hw->wiphy,
ath10k_reg_notifier);
if (ret) {
--
1.7.9.5
^ permalink raw reply related
* Re: AP changed bandwidth, new config is ... changed bandwidth in a way we can't support - disconnect - why? (intel advanced-n 6250)
From: Johannes Berg @ 2013-07-31 8:50 UTC (permalink / raw)
To: Arkadiusz Miskiewicz, Andy Isaacson; +Cc: linux-wireless, ilw
In-Reply-To: <201307310855.28080.a.miskiewicz@gmail.com>
On Wed, 2013-07-31 at 08:55 +0200, Arkadiusz Miskiewicz wrote:
> It basically reports:
> [79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
> [79477.496072] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
>
> (note I have two wrt160nl here and problem happens with both)
>
> Any hints on why "we can't support" configuration issued by this (common) AP?
As far as I can tell, it seems to be an AP bug, but I had no idea this
was so common.
Testing with hostapd, I can switch bandwidth between 20 and 40 MHz just
fine, and it only prints "new config is ..." and then carries on.
Since you seem to be able to reproduce this easily, can you run tcpdump
with the beacon info?
sudo iw wlan0 interface add moni0 type monitor flags none
sudo ip link set moni0 up
sudo tcpdump -i moni0 -s0 -w /tmp/dump
and then wait for the problem to occur and send me (privately) the dump
file (best compressed)?
There's also a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=981445
johannes
^ permalink raw reply
* [PATCH 0/5] ath10k: fixes
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This is a batch up of a few fixes for ath10k
driver I had in my queue for some time now.
Michal Kazior (5):
ath10k: prevent using invalid ringbuffer indexes
ath10k: make sure to use passive scan when n_ssids is 0
ath10k: advertise more conservative intf combinations
ath10k: zero arvif memory on add_interface()
ath10k: fix failpath in MSI-X setup
drivers/net/wireless/ath/ath10k/ce.c | 5 +++++
drivers/net/wireless/ath/ath10k/mac.c | 16 +++++++++++++---
drivers/net/wireless/ath/ath10k/pci.c | 7 ++++++-
3 files changed, 24 insertions(+), 4 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 2/5] ath10k: make sure to use passive scan when n_ssids is 0
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
Normally user specifies broadcast ssid for
scanning. If the user wants to do a passive scan
it does not pass any ssids.
The patch makes sure we ath10k tells firmware to
not send anything at all in case it decides no
ssids equals broadcast ssid.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 344ad27..1ea386e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2338,6 +2338,8 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
arg.ssids[i].len = req->ssids[i].ssid_len;
arg.ssids[i].ssid = req->ssids[i].ssid;
}
+ } else {
+ arg.scan_ctrl_flags |= WMI_SCAN_FLAG_PASSIVE;
}
if (req->n_channels) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/5] ath10k: prevent using invalid ringbuffer indexes
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
If the device is removed and hotplug fails
ioread32() will return 0xFFFFFFFF. In that case
reading ringbuffer during device bringup led to
out-of-bounds addressing of a ringbuffer array
that in turn led to a paging failure.
This could be reproduced by the following:
* boot without acpi/prevent hotplug from working
* insert and manually detect (pci rescan) the device
* remove the device physically
* load ath10k driver
* kernel crashed
Ringbuffer index reading is now protected by using
an appropriate mask to prevent addressing an
invalid array index.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index b407929..f8b969f 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -637,6 +637,7 @@ static int ath10k_ce_completed_send_next_nolock(struct ce_state *ce_state,
ath10k_pci_wake(ar);
src_ring->hw_index =
ath10k_ce_src_ring_read_index_get(ar, ctrl_addr);
+ src_ring->hw_index &= nentries_mask;
ath10k_pci_sleep(ar);
}
read_index = src_ring->hw_index;
@@ -950,10 +951,12 @@ static int ath10k_ce_init_src_ring(struct ath10k *ar,
ath10k_pci_wake(ar);
src_ring->sw_index = ath10k_ce_src_ring_read_index_get(ar, ctrl_addr);
+ src_ring->sw_index &= src_ring->nentries_mask;
src_ring->hw_index = src_ring->sw_index;
src_ring->write_index =
ath10k_ce_src_ring_write_index_get(ar, ctrl_addr);
+ src_ring->write_index &= src_ring->nentries_mask;
ath10k_pci_sleep(ar);
src_ring->per_transfer_context = (void **)ptr;
@@ -1035,8 +1038,10 @@ static int ath10k_ce_init_dest_ring(struct ath10k *ar,
ath10k_pci_wake(ar);
dest_ring->sw_index = ath10k_ce_dest_ring_read_index_get(ar, ctrl_addr);
+ dest_ring->sw_index &= dest_ring->nentries_mask;
dest_ring->write_index =
ath10k_ce_dest_ring_write_index_get(ar, ctrl_addr);
+ dest_ring->write_index &= dest_ring->nentries_mask;
ath10k_pci_sleep(ar);
dest_ring->per_transfer_context = (void **)ptr;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] ath10k: advertise more conservative intf combinations
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
Apparently the available firmware has a limit of
handling 7 APs, 3 GOs or 8 STAs. This is based on
empirical tests and it is still possible some
combinations may crash the firmware.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 1ea386e..6a130c5 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3078,9 +3078,15 @@ static const struct ieee80211_iface_limit ath10k_if_limits[] = {
.max = 8,
.types = BIT(NL80211_IFTYPE_STATION)
| BIT(NL80211_IFTYPE_P2P_CLIENT)
- | BIT(NL80211_IFTYPE_P2P_GO)
- | BIT(NL80211_IFTYPE_AP)
- }
+ },
+ {
+ .max = 3,
+ .types = BIT(NL80211_IFTYPE_P2P_GO)
+ },
+ {
+ .max = 7,
+ .types = BIT(NL80211_IFTYPE_AP)
+ },
};
static const struct ieee80211_iface_combination ath10k_if_comb = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] ath10k: zero arvif memory on add_interface()
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
The private memory area in vif provided by
mac80211 isn't guaranteed to be zeroed.
This patch should fix issues when switching
between STA and AP interface types.
The tim_bitmap could become polluted by STA bssid
field (since it's a union), wep_keys array
could also become polluted with invalid pointers
and probably much more.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6a130c5..1aa5a39 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1925,6 +1925,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
mutex_lock(&ar->conf_mutex);
+ memset(arvif, 0, sizeof(*arvif));
+
arvif->ar = ar;
arvif->vif = vif;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/5] ath10k: fix failpath in MSI-X setup
From: Michal Kazior @ 2013-07-31 8:55 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375260915-22500-1-git-send-email-michal.kazior@tieto.com>
pci_disable_msi() must be called if the initial
request_irq() fails.
Also add a warning message so it's possible to
distinguish request_irq() failure and
pci_enable_msi() failure.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index c71b488..d95439b 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1990,8 +1990,13 @@ static int ath10k_pci_start_intr_msix(struct ath10k *ar, int num)
ret = request_irq(ar_pci->pdev->irq + MSI_ASSIGN_FW,
ath10k_pci_msi_fw_handler,
IRQF_SHARED, "ath10k_pci", ar);
- if (ret)
+ if (ret) {
+ ath10k_warn("request_irq(%d) failed %d\n",
+ ar_pci->pdev->irq + MSI_ASSIGN_FW, ret);
+
+ pci_disable_msi(ar_pci->pdev);
return ret;
+ }
for (i = MSI_ASSIGN_CE_INITIAL; i <= MSI_ASSIGN_CE_MAX; i++) {
ret = request_irq(ar_pci->pdev->irq + i,
--
1.7.9.5
^ permalink raw reply related
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