* [PATCH 1/5] ath: fix logic on ath_reg_apply_active_scan_flags()
From: Luis R. Rodriguez @ 2013-10-21 17:14 UTC (permalink / raw)
To: linville, johannes
Cc: linux-wireless, janusz.dziedzic, smihir, tushnimb,
Luis R. Rodriguez
In-Reply-To: <1382375691-25476-1-git-send-email-mcgrof@do-not-panic.com>
The existing logic removes the passive scan flag from
channels 12 and 13 when a regulatory hint coming from
something other than a country IE has been passed. This
is incorrect, the original intention was to ensure we
always have passive scan enabled for these two channels
for a specific set of custom world regulatory domains.
Cc: smihir@qti.qualcomm.com
Cc: tushnimb@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
drivers/net/wireless/ath/regd.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index c00687e..1b4a532 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -255,16 +255,16 @@ ath_reg_apply_active_scan_flags(struct wiphy *wiphy,
return;
/*
- * If no country IE has been received always enable active scan
- * on these channels. This is only done for specific regulatory SKUs
+ * If no country IE has been received always enable passive scan
+ * and no-ibss on these channels. This is only done for specific
+ * regulatory SKUs.
*/
if (initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE) {
ch = &sband->channels[11]; /* CH 12 */
- if (ch->flags & IEEE80211_CHAN_PASSIVE_SCAN)
- ch->flags &= ~IEEE80211_CHAN_PASSIVE_SCAN;
+ ch->flags |= IEEE80211_CHAN_PASSIVE_SCAN;
+
ch = &sband->channels[12]; /* CH 13 */
- if (ch->flags & IEEE80211_CHAN_PASSIVE_SCAN)
- ch->flags &= ~IEEE80211_CHAN_PASSIVE_SCAN;
+ ch->flags |= IEEE80211_CHAN_PASSIVE_SCAN;
return;
}
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 0/5] ath: simplify radar / beaconing flag settings
From: Luis R. Rodriguez @ 2013-10-21 17:14 UTC (permalink / raw)
To: linville, johannes
Cc: linux-wireless, janusz.dziedzic, smihir, tushnimb,
Luis R. Rodriguez
John, Johannes,
these patches start cleaning up the flag usage through the reg-notifier
but the main motiviation here as to help clarify the case in which
DFS is supported and we don't need to apply some paranoid flags. I've
determined its best to clean this up on cfg80211 (unifying flags)
and deal with the DFS case in cfg80211 as well (I add the documentation,
but expect Januz to send a respective change later for DFS).
Given that the later patches cfg80211 / other drivers I'll let you
guys decide what tree these bubble up through.
This series simplifies the flag application setup. Just a heads up I
noticed that broadcom and rtl drivers share a lot of this code so
eventually we may want to just export these and share them somehow.
Luis R. Rodriguez (5):
ath: fix logic on ath_reg_apply_active_scan_flags()
ath: clean up ath_reg_apply_active_scan_flags()
ath: rename ath_reg_apply_active_scan_flags() to
ath_reg_apply_ir_flags()
ath: simplify ath_reg_apply_beaconing_flags()
ath: move the channel for ath_reg_apply_beaconing_flags() into helper
drivers/net/wireless/ath/regd.c | 174 ++++++++++++++++++++++------------------
1 file changed, 94 insertions(+), 80 deletions(-)
--
1.8.4.rc3
^ permalink raw reply
* [PATCH 1/5] ath: fix logic on ath_reg_apply_active_scan_flags()
From: Luis R. Rodriguez @ 2013-10-21 17:14 UTC (permalink / raw)
To: linville, johannes
Cc: linux-wireless, janusz.dziedzic, smihir, tushnimb,
Luis R. Rodriguez
In-Reply-To: <1382375664-25417-1-git-send-email-mcgrof@do-not-panic.com>
The existing logic removes the passive scan flag from
channels 12 and 13 when a regulatory hint coming from
something other than a country IE has been passed. This
is incorrect, the original intention was to ensure we
always have passive scan enabled for these two channels
for a specific set of custom world regulatory domains.
Cc: smihir@qti.qualcomm.com
Cc: tushnimb@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
drivers/net/wireless/ath/regd.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index c00687e..1b4a532 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -255,16 +255,16 @@ ath_reg_apply_active_scan_flags(struct wiphy *wiphy,
return;
/*
- * If no country IE has been received always enable active scan
- * on these channels. This is only done for specific regulatory SKUs
+ * If no country IE has been received always enable passive scan
+ * and no-ibss on these channels. This is only done for specific
+ * regulatory SKUs.
*/
if (initiator != NL80211_REGDOM_SET_BY_COUNTRY_IE) {
ch = &sband->channels[11]; /* CH 12 */
- if (ch->flags & IEEE80211_CHAN_PASSIVE_SCAN)
- ch->flags &= ~IEEE80211_CHAN_PASSIVE_SCAN;
+ ch->flags |= IEEE80211_CHAN_PASSIVE_SCAN;
+
ch = &sband->channels[12]; /* CH 13 */
- if (ch->flags & IEEE80211_CHAN_PASSIVE_SCAN)
- ch->flags &= ~IEEE80211_CHAN_PASSIVE_SCAN;
+ ch->flags |= IEEE80211_CHAN_PASSIVE_SCAN;
return;
}
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH 0/5] ath: simplify radar / beaconing flag settings
From: Luis R. Rodriguez @ 2013-10-21 17:14 UTC (permalink / raw)
To: linville, johannes
Cc: linux-wireless, janusz.dziedzic, smihir, tushnimb,
Luis R. Rodriguez
John, Johannes,
these patches start cleaning up the flag usage through the reg-notifier
but the main motiviation here as to help clarify the case in which
DFS is supported and we don't need to apply some paranoid flags. I've
determined its best to clean this up on cfg80211 (unifying flags)
and deal with the DFS case in cfg80211 as well (I add the documentation,
but expect Januz to send a respective change later for DFS).
Given that the later patches cfg80211 / other drivers I'll let you
guys decide what tree these bubble up through.
This series simplifies the flag application setup. Just a heads up I
noticed that broadcom and rtl drivers share a lot of this code so
eventually we may want to just export these and share them somehow.
Luis R. Rodriguez (5):
ath: fix logic on ath_reg_apply_active_scan_flags()
ath: clean up ath_reg_apply_active_scan_flags()
ath: rename ath_reg_apply_active_scan_flags() to
ath_reg_apply_ir_flags()
ath: simplify ath_reg_apply_beaconing_flags()
ath: move the channel for ath_reg_apply_beaconing_flags() into helper
drivers/net/wireless/ath/regd.c | 174 ++++++++++++++++++++++------------------
1 file changed, 94 insertions(+), 80 deletions(-)
--
1.8.4.rc3
^ permalink raw reply
* Re: [PATCH] cfg80211: fix nl80211.h documentation for DFS enum states
From: Johannes Berg @ 2013-10-21 17:04 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1382374934-24188-1-git-send-email-mcgrof@do-not-panic.com>
On Mon, 2013-10-21 at 19:02 +0200, Luis R. Rodriguez wrote:
> The names are prefixed incorrectly on the documentation.
You already sent me this patch, and I applied it, I believe?
johannes
^ permalink raw reply
* [PATCH] cfg80211: fix nl80211.h documentation for DFS enum states
From: Luis R. Rodriguez @ 2013-10-21 17:02 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luis R. Rodriguez
The names are prefixed incorrectly on the documentation.
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
include/uapi/linux/nl80211.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 71b519f..6ab79ea 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3860,11 +3860,11 @@ enum nl80211_radar_event {
*
* Channel states used by the DFS code.
*
- * @IEEE80211_DFS_USABLE: The channel can be used, but channel availability
+ * @NL80211_DFS_USABLE: The channel can be used, but channel availability
* check (CAC) must be performed before using it for AP or IBSS.
- * @IEEE80211_DFS_UNAVAILABLE: A radar has been detected on this channel, it
+ * @NL80211_DFS_UNAVAILABLE: A radar has been detected on this channel, it
* is therefore marked as not available.
- * @IEEE80211_DFS_AVAILABLE: The channel has been CAC checked and is available.
+ * @NL80211_DFS_AVAILABLE: The channel has been CAC checked and is available.
*/
enum nl80211_dfs_state {
--
1.8.4.rc3
^ permalink raw reply related
* Re: rtl8187 AP/Master mode
From: Larry Finger @ 2013-10-21 16:20 UTC (permalink / raw)
To: Mark Moes, linux-wireless@vger.kernel.org
In-Reply-To: <DUB119-W4825EB1294BF48BA2BAAB39E010@phx.gbl>
On 10/21/2013 06:21 AM, Mark Moes wrote:
> Hi,
>
>
> I was wondering if there's any work being done on the AP/Master mode implementation of the rtl8187 chip as listed here: http://wireless.kernel.org/en/users/Drivers/rtl8187
>
> If not, could anyone give a guesstimate of how much work is needed to write the code for this functionality?
The RTL8187L chip does not implement QoS queuing. It might work in an AP, but it
would certainly fall over with a heavy load. The RTL8187B might work better.
When you add the fact that the internal workings of these chips are unpublished
and unknown to us, implementing either AP or Master mode would likely be difficult.
It is impossible to guesstimate the time required. All that I can tell you is
that adapting this driver to work with either of these two modes is very low on
my priority list.
Larry
^ permalink raw reply
* French regulatory domain change request
From: Jean-Pierre Tosoni @ 2013-10-21 15:05 UTC (permalink / raw)
To: linux-wireless, wireless-regdb
Hello all,
The current description for France in regdb.txt is :
country FR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 80), (N/A, 20)
(5250 - 5330 @ 80), (N/A, 20), DFS
(5490 - 5710 @ 80), (N/A, 27), DFS
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR
Following this paper http://www.arcep.fr/uploads/tx_gsavis/08-0568.pdf
" Décision n° 2008-0568" issued by the ARCEP (French Electronic
communications and Postoffice Regulation Authority) in the year 2008,
1) the frequencies 5150-5350 MHz are limited to INDOOR use.
(see page 5: "Dans la bande de fréquences*5150-5350* MHz, les WAS/RLAN sont
limités à une *utilisation intérieure* ...")
2) the limits of the frequency band is ~20MHz greater for all frequency
values (5150 vs. 5170, 5350 vs. 5330, 5470 vs. 5490, 5725 vs. 5710)
So IMHO the description for France should read:
country FR: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20)
# ref: ARCEP 08-0568
http://www.arcep.fr/uploads/tx_gsavis/08-0568.pdf
(5150 - 5250 @ 80), (N/A, 20), NO-OUTDOOR
(5250 - 5350 @ 80), (N/A, 20), NO-OUTDOOR, DFS
(5470 - 5725 @ 80), (N/A, 27), DFS
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR
By the way, this looks very like the description for Germany (DE) now!
Regards,
Jean-Pierre
^ permalink raw reply
* Re: Active scanning on DFS channels
From: Kalle Valo @ 2013-10-21 14:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Lorenzo Bianconi, linux-wireless, Johannes Berg, Simon Wunderlich
In-Reply-To: <CAB=NE6U94K_KvhcPUvPL+S25Nw5J1Y300ASADa7C6-J_pBEW3A@mail.gmail.com>
"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
> On Mon, Oct 21, 2013 at 8:19 AM, Kalle Valo <kvalo@adurom.com> wrote:
>> "Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
>>
>>>> Should we perform
>>>> passive scan on radar channel setting new state to SCAN_DECISION and
>>>> not to SCAN_SEND_PROBE in ieee80211_scan_state_set_channel()?
>>>
>>> There's a few thing we need to do and I'm working on it.
>>>
>>> 1) no-ibss and passive-scan flags should be merged to a no-ir flag
>>
>> For me IR always reminds of infrared, so the name no-ir is a bit vague
>> to me :)
>
> Any recommendations? I'm just lazy.
no-sta-tx sounds dumb, but I can't think of anything better. Sorry.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: add error handling to ath10k_pci_wait()
From: Kalle Valo @ 2013-10-21 14:19 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20131017083615.31028.25088.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> ath10k_pci_wait() didn't notify any errors to callers, it
> just printed a warning so add proper error handling.
>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Applied, I just changed the commit log to this:
commit f3782744c9b50edf94d28e37a937ff84f267dfab
Author: Kalle Valo <kvalo@qca.qualcomm.com>
Date: Thu Oct 17 11:36:15 2013 +0300
ath10k: add error handling to ath10k_pci_wait()
ath10k_pci_wait() didn't notify any errors to callers, it
just printed a warning so add proper error handling. This fixes
a crash Ben reported:
ath10k: MSI-X interrupt handling (8 intrs)
ath10k: Unable to wakeup target
ath10k: target took longer 5000 us to wake up (awake count 1)
ath10k: Failed to get pcie state addr: -16
ath10k: early firmware event indicated
BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
IP: [<ffffffffa06ae46c>] ath10k_ce_completed_send_next+0x47/0x122 [ath10k_pci]
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/8] ath10k: fixes 2013-10-15
From: Kalle Valo @ 2013-10-21 14:15 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20131016134503.25095.8044.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> This is Michal's patchset which he said:
>
> This is a bunch of fixes I've had queued up for
> some time now. I was reluctant to send them without some additional checks
> and because some of the fixes are not ideal. At least we can get a discussion
> going if anything raises any serious concern.
>
> For v2 I added one patch myself, modified "ath10k: fix device initialization
> routine" to use ath10k_pci_write32() style of wrappers and fixed long line warnings
> from checkpatch.
>
> ---
>
> Kalle Valo (1):
> ath10k: implement ath10k_pci_soc_read/write32()
>
> Michal Kazior (7):
> ath10k: prevent starting monitor without a vdev
> ath10k: add sanity checks for monitor management
> ath10k: fix endianess in prints
> ath10k: fix NSS reporting in RX
> ath10k: fix NULL deref upon early FW crash
> ath10k: fix FW crashes on heavy TX on 10.1.389 AP FW
These patches applied.
> ath10k: fix device initialization routine
I dropped this patch for now, because of some of the warm reset issues.
We need to investigate more.
--
Kalle Valo
^ permalink raw reply
* pull-request: mac80211 2013-10-21
From: Johannes Berg @ 2013-10-21 13:10 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
John,
Unfortunately we have yet more fixes for mac80211.
I have two DFS fixes (ath9k already supports DFS) and a fix for a
pointer race.
Let me know if there's any problem.
johannes
The following changes since commit 095d81cee742fc31e1218077ca6ca8f0df07c613:
mac80211: disable WMM with invalid parameters (2013-10-17 15:38:22 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
for you to fetch changes up to bbe09bbcf4454e826e3fb08e87d81f32c0030658:
cfg80211: update dfs_state_entered upon dfs_state change (2013-10-21 14:50:27 +0200)
----------------------------------------------------------------
Johannes Berg (1):
cfg80211: fix scheduled scan pointer access
Michal Kazior (2):
cfg80211: fix DFS channel recovery timeout
cfg80211: update dfs_state_entered upon dfs_state change
net/wireless/mlme.c | 6 ++++--
net/wireless/scan.c | 4 ++--
2 files changed, 6 insertions(+), 4 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* pull-request: mac80211-next 2013-10-21
From: Johannes Berg @ 2013-10-21 13:08 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 4677 bytes --]
Now with build fixes for !MESH and a channel switch parsing fix.
In this round for mac80211-next I have:
* mesh channel switch support
* a CCM rewrite, using potential hardware offloads
* SMPS for AP mode
* RF-kill GPIO driver updates to make it usable as an ACPI driver
* regulatory improvements
* documentation fixes
* DFS for IBSS mode
* and a few small other fixes/improvements
Let me know if there's any problem.
johannes
The following changes since commit 7578d57520f51093f590d68e16965e2714e69747:
mac80211: implement STA CSA for drivers using channel contexts (2013-10-02 18:18:23 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git for-john
for you to fetch changes up to cf867bc30d9af3c2cdbf876224f400a81606eebe:
nl80211: fix channel switch parsing (2013-10-21 14:36:56 +0200)
----------------------------------------------------------------
Andrei Otcheretianski (1):
nl80211: fix channel switch parsing
Ard Biesheuvel (1):
mac80211: port CCMP to cryptoapi's CCM driver
Chun-Yeow Yeoh (5):
mac80211: refactor the parsing of chan switch ie
mac80211: process the CSA frame for mesh accordingly
{nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
{nl,cfg,mac}80211: implement mesh channel switch userspace API
mac80211: process mesh channel switching using beacon
Emmanuel Grumbach (1):
mac80211: implement SMPS for AP
Felix Fietkau (1):
mac80211: add ieee80211_tx_prepare_skb() helper function
Heikki Krogerus (5):
net: rfkill: gpio: convert to resource managed allocation
net: rfkill: gpio: clean up clock handling
net: rfkill: gpio: spinlock-safe GPIO access
net: rfkill: gpio: prepare for DT and ACPI support
net: rfkill: gpio: add ACPI support
Johannes Berg (2):
mac80211: add missing IEEE80211_HW_SUPPORTS_HT_CCK_RATES docs
cfg80211: fix docbook references
Luis R. Rodriguez (5):
cfg80211: fix nl80211.h documentation for DFS enum states
cfg80211: rename regulatory_hint_11d() to regulatory_hint_country_ie()
cfg80211: enable regulatory hints for strict custom settings
cfg80211: simplify strict custom alpha2 regdomain check
cfg80211: export reg_initiator_name()
Marco Porsch (1):
mac80211: fixes for mesh powersave logic
Michal Kazior (1):
mac80211: fix uninitialized variable
Seth Forshee (1):
mac80211: Remove check for offchannel state when waking netdev queues
Simon Wunderlich (2):
nl80211/cfg80211: enable DFS for IBSS mode
mac80211: enable DFS for IBSS mode
Sunil Dutt (1):
cfg80211: pass station supported channel and oper class info
Documentation/DocBook/80211.tmpl | 4 +-
include/linux/ieee80211.h | 20 +++
include/net/cfg80211.h | 23 +++
include/net/mac80211.h | 18 +++
include/uapi/linux/nl80211.h | 27 +++-
net/mac80211/Kconfig | 12 ++
net/mac80211/aes_ccm.c | 169 ++++++++--------------
net/mac80211/aes_ccm.h | 14 +-
net/mac80211/cfg.c | 142 +++++++++++++++++-
net/mac80211/debug.h | 10 ++
net/mac80211/debugfs_netdev.c | 25 ++--
net/mac80211/ht.c | 41 ++++--
net/mac80211/ibss.c | 116 +++++++--------
net/mac80211/ieee80211_i.h | 50 +++++--
net/mac80211/iface.c | 2 +
net/mac80211/key.h | 2 +-
net/mac80211/mesh.c | 302 ++++++++++++++++++++++++++++++++++++++-
net/mac80211/mesh_plink.c | 3 +-
net/mac80211/mesh_ps.c | 33 +++--
net/mac80211/mlme.c | 34 +++--
net/mac80211/rx.c | 5 +-
net/mac80211/spectmgmt.c | 33 +++--
net/mac80211/sta_info.c | 72 ++++++++++
net/mac80211/sta_info.h | 5 +
net/mac80211/status.c | 31 ++--
net/mac80211/tx.c | 45 ++++++
net/mac80211/util.c | 124 +++++++++++++++-
net/mac80211/wpa.c | 44 +++---
net/rfkill/Kconfig | 2 +-
net/rfkill/rfkill-gpio.c | 211 +++++++++++++--------------
net/wireless/chan.c | 3 +-
net/wireless/ibss.c | 24 +++-
net/wireless/nl80211.c | 62 +++++++-
net/wireless/reg.c | 39 +++--
net/wireless/reg.h | 4 +-
net/wireless/sme.c | 4 +-
net/wireless/util.c | 14 +-
37 files changed, 1306 insertions(+), 463 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: NetworkManager not listing access points
From: Johannes Berg @ 2013-10-21 13:06 UTC (permalink / raw)
To: Will Hawkins
Cc: Detlev Casanova, Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <52600E1A.6070806@opentechinstitute.org>
On Thu, 2013-10-17 at 12:19 -0400, Will Hawkins wrote:
> Not to clog up the channel, but I was running into exactly the same
> problem. I expected to see the problem somewhere in the kernel, etc. I
> turned on debugging and kernel tracing and saw nothing. The fix for me
> is almost identical to the fix that Detlev first described.
>
> However, the problem for me was somewhere else entirely. The access
> point was sending out malformed beacon messages that kept it from
> showing up.
Any idea how they were malformed? Was there a bad DS IE or so?
johannes
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: fix DFS channel recovery timeout
From: Johannes Berg @ 2013-10-21 13:04 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless
In-Reply-To: <1382034072-13541-1-git-send-email-michal.kazior@tieto.com>
On Thu, 2013-10-17 at 11:21 -0700, Michal Kazior wrote:
> The timeout was not properly converted from msecs
> to jiffies. As a result channel transition to
> NL80211_DFS_USABLE was delayed depending on
> CONFIG_HZ configuration, e.g. HZ=100 would delay
> the NOP from 30 minutes to 300 minutes.
Applied both, but I think getting into 3.12 might be hard.
johannes
^ permalink raw reply
* Re: Active scanning on DFS channels
From: Luis R. Rodriguez @ 2013-10-21 12:51 UTC (permalink / raw)
To: Kalle Valo
Cc: Lorenzo Bianconi, linux-wireless, Johannes Berg, Simon Wunderlich
In-Reply-To: <87wql7tac9.fsf@purkki.adurom.net>
On Mon, Oct 21, 2013 at 8:19 AM, Kalle Valo <kvalo@adurom.com> wrote:
> "Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
>
>>> Should we perform
>>> passive scan on radar channel setting new state to SCAN_DECISION and
>>> not to SCAN_SEND_PROBE in ieee80211_scan_state_set_channel()?
>>
>> There's a few thing we need to do and I'm working on it.
>>
>> 1) no-ibss and passive-scan flags should be merged to a no-ir flag
>
> For me IR always reminds of infrared, so the name no-ir is a bit vague
> to me :)
Any recommendations? I'm just lazy.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: document IEEE80211_HW_SUPPORTS_HT_CCK_RATES
From: Michael Opdenacker @ 2013-10-21 11:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1382350961.14310.42.camel@jlt4.sipsolutions.net>
Hi Johannes,
On 10/21/2013 12:22 PM, Johannes Berg wrote:
> On Sun, 2013-10-20 at 08:45 +0200, Michael Opdenacker wrote:
>> This patch documents the IEEE80211_HW_SUPPORTS_HT_CCK_RATES flag
>> in ieee80211_hw_flags.
>>
>> Without this, you get countless warnings in "make htmldocs".
> I already have an equivalent patch with correct documentation :)
Great! Then let's use your patch :)
Thanks,
Michael.
--
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098
^ permalink raw reply
* Re: [PATCH 00/23 v2] cleanup: introduce br/netdev/netif/wiphy_<foo>_ratelimited() and use them to simplify code
From: Kefeng Wang @ 2013-10-21 11:26 UTC (permalink / raw)
To: Joe Perches; +Cc: linux-kernel, netfilter, netdev, linux-wireless
In-Reply-To: <1382069482.22110.164.camel@joe-AO722>
On 10/18 12:11, Joe Perches wrote:
> (resending to lists only because of multiple X's in the subject line)
>
> On Fri, 2013-10-18 at 11:52 +0800, Kefeng Wang wrote:
>> v1-v2:
>>
>> Introduce macro br/netdev/netif/wiphy_XXX_ratelimited() according
>> to Joe Perches's advice. The macros are similar to net_XXX_ratelimited()
>> which is more clarifying than net_ratelimited_function(), then use them
>> to simplify code.
>
> There are some conceptual differences between these
> implementations and other <foo>_ratelimited uses.
>
> For every other subsystem but net, there is a per-location
> struct ratelimit_state.
yes, but I think I just changed net subsystem. Macro DEFINE_RATELIMIT_STATE used
DEFAULT_RATELIMIT_INTERVAL and DEFAULT_RATELIMIT_BURST, so what do you think?
Could anyone give me some advises ?
> Here you've made the global net_ratelimit_state replace all
> of these individual structs so there is some new interaction.
>
> Dunno if that's good or bad.
>
>
>
>
>
^ permalink raw reply
* rtl8187 AP/Master mode
From: Mark Moes @ 2013-10-21 11:21 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <DUB119-W4654D1E1A8377FA92B6E049E010@phx.gbl>
Hi,
I was wondering if there's any work being done on the AP/Master mode implementation of the rtl8187 chip as listed here: http://wireless.kernel.org/en/users/Drivers/rtl8187
If not, could anyone give a guesstimate of how much work is needed to write the code for this functionality?
Mark
^ permalink raw reply
* Re: [PATCH] mac80211: fix uninitialized variable
From: Johannes Berg @ 2013-10-21 10:26 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless
In-Reply-To: <1382133420-1545-1-git-send-email-michal.kazior@tieto.com>
On Fri, 2013-10-18 at 14:57 -0700, Michal Kazior wrote:
> CSA completion could call in a driver
> bss_info_changed() with a garbled `changed` flag
> leading to all sorts of problems.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: document IEEE80211_HW_SUPPORTS_HT_CCK_RATES
From: Johannes Berg @ 2013-10-21 10:22 UTC (permalink / raw)
To: Michael Opdenacker; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1382251529-22540-1-git-send-email-michael.opdenacker@free-electrons.com>
On Sun, 2013-10-20 at 08:45 +0200, Michael Opdenacker wrote:
> This patch documents the IEEE80211_HW_SUPPORTS_HT_CCK_RATES flag
> in ieee80211_hw_flags.
>
> Without this, you get countless warnings in "make htmldocs".
I already have an equivalent patch with correct documentation :)
johannes
^ permalink raw reply
* [PATCH 3.12] cfg80211: fix scheduled scan pointer access
From: Johannes Berg @ 2013-10-21 9:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Since rdev->sched_scan_req is dereferenced outside the
lock protecting it, this might be done at the wrong
time, causing crashes. Move the dereference to where
it should be - inside the RTNL locked section.
Cc: stable@vger.kernel.org [3.8+]
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/scan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index eeb7148..d4397eb 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -254,10 +254,10 @@ void __cfg80211_sched_scan_results(struct work_struct *wk)
rdev = container_of(wk, struct cfg80211_registered_device,
sched_scan_results_wk);
- request = rdev->sched_scan_req;
-
rtnl_lock();
+ request = rdev->sched_scan_req;
+
/* we don't have sched_scan_req anymore if the scan is stopping */
if (request) {
if (request->flags & NL80211_SCAN_FLAG_FLUSH) {
--
1.8.4.rc3
^ permalink raw reply related
* Re: WIFI USB-Stick for P2P
From: David Herrmann @ 2013-10-21 8:29 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: Alexander Müller, linux-wireless@vger.kernel.org
In-Reply-To: <525316EF.6070102@rempel-privat.de>
Hi
On Mon, Oct 7, 2013 at 10:17 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> Am 07.10.2013 11:08, schrieb Alexander Müller:
>> Hello linux-wireless,
>>
>> I'm wondering if there is a list of usb wifi devices having a good and stable p2p support for wifi direct. We are currently using an AVM Fritz wifi stick that is supported by the carl9170 driver, but it is experiencing random failures and stalls which require a hardware reset. The p2p howto page at http://wireless.kernel.org/en/developers/p2p/howto suggests that there may be other devices and drivers supporting p2p, but I haven't figured out exactly which devices work best.
>>
>> Can you give me a hint?
>
> You can try ath9k_htc based device. It should be able to support P2P,
> but right now i was not able to transfer any data. p2p_find and
> p2p_connect seems to work.
>
> If you wont to do some more testing with ath9k_htc, please contact me.
If anyone else is trying this, I was able to transfer data between my
Android device and a linux host:
Android device is a Nexus 4. To wait for connections, go to
Settings->Wifi->Wifi-Direct
On the linux host, I used "Sony UWABR100", a ath9k_htc dual-band
(2.4/5Ghz) USB pluggable device. As kernel I used 3.12-rc3.
At least wpa_supplicant-2.0 is needed. As config-file I used:
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
device_name=my-device-name
device_type=1-0050F204-1
Then run wpa_supplicant via:
wpa_supplicant -Dnl80211 -c /path/to/p2p.conf -i wlan0 -dt
This information is also available here:
http://wireless.kernel.org/en/developers/p2p/howto
To connect your device, run "wpa_cli" on the host. Use "p2p_find" and
wait for your android device to be detected. Then run "p2p_connect
<android-mac> pbc" to connect via WPS-PBC. After a few seconds the
android device shows a pop-up where you need to press "Accept".
This will give you a new interface p2p-wlan0-0 (or similar). If you're
the GO, you need to assign an IP address and start a dhcp-daemon (I
used udhcpd). Otherwise, Android disconnects after a short timeout
(about 5s). Once the dhcpd is running, the android device acquires an
IP address and you can start communication. The IP network is fully
set up.
I hope this helps!
David
Some links I found useful:
http://processors.wiki.ti.com/index.php/OMAP_Wireless_Connectivity_NLCP_WiFi_Direct_Configuration_Scripts
http://svn.dd-wrt.com/browser/src/router/hostapd-wps/wpa_supplicant/README-P2P?rev=16495
http://developer.android.com/guide/topics/connectivity/wifip2p.html
^ permalink raw reply
* [PATCH] rt2x00: rt2800lib: Update BBP register initialization for RT53xx
From: Kevin Lo @ 2013-10-21 7:38 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users
Update bbp register initialization for RT53xx chips to match with the
latest MediaTek/Ralink driver.
Based on: NICInitRT5390BbpRegisters()
From: DPO_RT5572_LinuxSTA_2.6.1.3_20121022/chips/rt5390.c
Signed-off-by: Kevin Lo <kevlo.org>
---
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c5738f1..eae635a 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -5462,15 +5462,14 @@ static void rt2800_init_bbp_53xx(struct rt2x00_dev *rt2x00dev)
rt2800_bbp_write(rt2x00dev, 68, 0x0b);
- rt2800_bbp_write(rt2x00dev, 69, 0x12);
+ rt2800_bbp_write(rt2x00dev, 69, 0x0d);
+ rt2800_bbp_write(rt2x00dev, 70, 0x06);
rt2800_bbp_write(rt2x00dev, 73, 0x13);
rt2800_bbp_write(rt2x00dev, 75, 0x46);
rt2800_bbp_write(rt2x00dev, 76, 0x28);
rt2800_bbp_write(rt2x00dev, 77, 0x59);
- rt2800_bbp_write(rt2x00dev, 70, 0x0a);
-
rt2800_bbp_write(rt2x00dev, 79, 0x13);
rt2800_bbp_write(rt2x00dev, 80, 0x05);
rt2800_bbp_write(rt2x00dev, 81, 0x33);
@@ -5513,6 +5512,7 @@ static void rt2800_init_bbp_53xx(struct rt2x00_dev *rt2x00dev)
if (rt2x00_rt(rt2x00dev, RT5392)) {
rt2800_bbp_write(rt2x00dev, 134, 0xd0);
rt2800_bbp_write(rt2x00dev, 135, 0xf6);
+ rt2800_bbp_write(rt2x00dev, 148, 0x84);
}
rt2800_disable_unused_dac_adc(rt2x00dev);
^ permalink raw reply related
* Re: [PATCH 1/2] ath10k: remove P2P from supported interface modes for 10.X FW
From: Bartosz Markowski @ 2013-10-21 6:52 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless@vger.kernel.org
In-Reply-To: <87mwm3uoep.fsf@kamboji.qca.qualcomm.com>
On 21 October 2013 08:30, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Bartosz Markowski <bartosz.markowski@tieto.com> writes:
>
>> FW 10.X does not support P2P, stop advertising it to mac80211.
>>
>> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
>
> [...]
>
>> @@ -3478,7 +3504,11 @@ int ath10k_mac_register(struct ath10k *ar)
>> */
>> ar->hw->queues = 4;
>>
>> - ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
>> + if (test_bit(ATH10K_FW_FEATURE_WMI_10X, ar->fw_features))
>> + ar->hw->wiphy->iface_combinations = &ath10k_10x_if_comb;
>> + else
>> + ar->hw->wiphy->iface_combinations = &ath10k_if_comb;
>
> I think it would be better to have a separate feature flag for this,
> like NO_P2P or something like that. Just in case we want to disable P2P
> in other firmware branches.
Make sense. I will change this.
--
Bartosz
^ 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