* pull-request: iwlwifi-fixes 2013-06-05
From: Johannes Berg @ 2013-06-05 7:02 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
Hi,
Here's another one ... I guess the fixes stream never ends, but on the
plus side they're getting smaller.
I picked up Nikolay's patch for the chain noise calibration bug that
seems to have been there forever, a fix from Emmanuel for setting TX
flags on BAR frames and a fix of my own to avoid printing
request_module() errors if the kernel isn't even modular.
Please pull.
Thanks,
johannes
The following changes since commit a87783699b23395c46bbeeb5d28f6db24897bf26:
iwlwifi: dvm: fix zero LQ CMD sending avoidance (2013-05-27 11:33:57 +0200)
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 2edc6ec6330c7906f4dbd7f5da71be8989efc5a3:
iwlwifi: mvm: correctly set the flags for BAR (2013-06-04 13:14:30 +0200)
----------------------------------------------------------------
Emmanuel Grumbach (1):
iwlwifi: mvm: correctly set the flags for BAR
Johannes Berg (1):
iwlwifi: don't print module loading error if not modular
Nikolay Martynov (1):
iwlwifi: dvm: fix chain noise calibration
drivers/net/wireless/iwlwifi/dvm/rxon.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 2 ++
drivers/net/wireless/iwlwifi/mvm/tx.c | 3 ++-
3 files changed, 5 insertions(+), 2 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* pull-request: iwlwifi-next 2013-06-05
From: Johannes Berg @ 2013-06-05 7:08 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 3198 bytes --]
Hi,
And just like the fixes for old code never end, also the fixes for new
code :-) But I also have some new features. I also had to merge
wireless-next to get a cfg80211 change that the D3 test feature depends
on.
Here I mostly have various fixes for AP/GO mode, Bluetooth coexistence
and power save modes. The only new thing is the introduction of "D3
test" mode, accessible through debugfs for D3 firmware debugging.
Please pull.
Thanks,
johannes
The following changes since commit a910e4a94f6923c8c988565525f017f687bf7205:
cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets (2013-05-29 15:26:40 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git for-john
for you to fetch changes up to fded313ec045024d4f769ce6b3e41fe343c167b0:
iwlwifi: mvm: don't request SMPS on non-STA iface (2013-06-05 09:06:13 +0200)
----------------------------------------------------------------
Alexander Bondar (2):
iwlwifi: mvm: Change location of vif_count verification for PM
iwlwifi: mvm: enable PM always in unassociated mode
Emmanuel Grumbach (7):
iwlwifi: mvm: fix the LUT for BT Coex
iwlwifi: mvm: limit the length of the AMPDU when BT is running
iwlwifi: mvm: don't start BA agreement when BT is active
iwlwifi: mvm: don't enable MIMO when BT is active
iwlwifi: mvm: reorder Rx handler for performance purposes
iwlwifi: mvm: correctly configure MCAST in AP mode
iwlwifi: mvm: fix MCAST in AP mode
Eran Harary (1):
iwlwifi: don't return -ERFKILL if SEND_IF_RFKILL is set
Eytan Lifshitz (1):
iwlwifi: mvm: don't request SMPS on non-STA iface
Ilan Peer (1):
iwlwifi: mvm: Fix quota command settings
Johannes Berg (2):
Merge remote-tracking branch 'wireless-next/master' into iwlwifi-next
iwlwifi: mvm: implement D3 testing
drivers/net/wireless/iwlwifi/dvm/mac80211.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 14 +--
drivers/net/wireless/iwlwifi/mvm/bt-coex.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/d3.c | 149 ++++++++++++++++++++++++--
drivers/net/wireless/iwlwifi/mvm/debugfs.c | 1 +
drivers/net/wireless/iwlwifi/mvm/fw-api-mac.h | 8 +-
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 6 +-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 35 ++----
drivers/net/wireless/iwlwifi/mvm/mvm.h | 4 +
drivers/net/wireless/iwlwifi/mvm/ops.c | 9 +-
drivers/net/wireless/iwlwifi/mvm/phy-ctxt.c | 3 +-
drivers/net/wireless/iwlwifi/mvm/power.c | 13 +++
drivers/net/wireless/iwlwifi/mvm/quota.c | 25 +++--
drivers/net/wireless/iwlwifi/mvm/rs.c | 115 +++++++++++++++++++-
drivers/net/wireless/iwlwifi/mvm/rs.h | 12 +++
drivers/net/wireless/iwlwifi/mvm/tt.c | 3 +
drivers/net/wireless/iwlwifi/mvm/tx.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/utils.c | 10 ++
drivers/net/wireless/iwlwifi/pcie/trans.c | 19 +++-
drivers/net/wireless/iwlwifi/pcie/tx.c | 3 +-
20 files changed, 371 insertions(+), 66 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Vladimir Kondratiev @ 2013-06-05 7:10 UTC (permalink / raw)
To: Jouni Malinen
Cc: Johannes Berg, Peer, Ilan, linux-wireless@vger.kernel.org,
Rodriguez, Luis, John W . Linville
In-Reply-To: <20130604183023.GB6172@jouni.qca.qualcomm.com>
On Tuesday, June 04, 2013 09:30:23 PM Jouni Malinen wrote:
> On Tue, Jun 04, 2013 at 07:47:20PM +0300, Vladimir Kondratiev wrote:
> > I am a bit confused. I supposed that if devices A and B (not in a group yet)
> > try to discover each other, it works like the following
> >
> > A ---- probe-req ---> B (now B knows A)
> > A <--- probe-resp ---- B (now A knows B)
>
> This depends on what exactly you mean with "discover". Sure, it is known
> that there is a P2P peer in the environment if a Probe Request frame
> with P2P IE is received from it. However, that does not necessarily mean
> we know enough of that peer to initiate new P2P operations.
>
> > But if device is discovered by probe-resp only, it mean this should be
> >
> > A ---- probe-req ---> B
> > A <--- probe-resp ---- B (now A knows B)
> > A <--- probe-req ---- B
> > A ---- probe-resp ---> B (now B knows A)
>
> Probe Response frames include more information about the peer and that
> allows wpa_supplicant to complete the peer entry. This is the point when
> the peer is fully known and indicated to upper layers. The Probe Request
> frame RX case is just used internally within wpa_supplicant. (For
> completeness, number of other frames, i.e., P2P Action frames, can also
> complete the P2P peer entry, so this does not need to be Probe
> Response).
Thanks for clarification. So, I see that wpa_s wants all probe responses and
may want either all or selected probes, depending on the driver's capability
(NL80211_FEATURE_P2P_PROBE_RESP_OFFLOAD) and its own reasons.
Then, I think it would be appropriate to say following in the comment for
start_p2p_find (no code changes, it is only expectations for the friver behavior):
---cut---
While performing P2P discovery, driver should report all received
probe-request and probe-response frames via cfg80211_rx_mgmt,
accordingly to the rx mgmt filter, as set by mgmt_frame_register().
When reporting probes, driver/firmware may do its best to filter out
probes that would not be replied with probe-resp accordingly to the
P2P rules for active device configuration.
---cut---
This makes possible for wpa_s to choose exact configuration, and good
power saving is possible provided firmware answer probes.
Comments?
Thanks, Vladimir
^ permalink raw reply
* [PATCH] mac80211: Use suitable semantics for beacon availability indication
From: Johannes Berg @ 2013-06-05 7:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Alexander Bondar
From: Alexander Bondar <alexander.bondar@intel.com>
Currently beacon availability upon association is marked by have_beacon
flag of assoc_data structure that becomes unavailable when association
completes. However beacon availability indication is required also after
association to inform a driver. Currently dtim_period parameter is used
for this purpose. Move have_beacon flag to another structure, persistant
throughout a interface's life cycle. Use suitable sematics for beacon
availability indication.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
[fix another instance of BSS_CHANGED_DTIM_PERIOD in docs]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +-
include/net/mac80211.h | 8 ++++----
net/mac80211/ieee80211_i.h | 3 ++-
net/mac80211/mlme.c | 20 +++++++++++---------
net/mac80211/util.c | 5 +++--
5 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index b807dda..c942eb0 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -785,7 +785,7 @@ static void iwl_mvm_bss_info_changed_station(struct iwl_mvm *mvm,
if (ret)
IWL_ERR(mvm, "failed to update quotas\n");
}
- } else if (changes & BSS_CHANGED_DTIM_PERIOD) {
+ } else if (changes & BSS_CHANGED_BEACON_INFO) {
/*
* We received a beacon _after_ association so
* remove the session protection.
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cb37f82..a405a7a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -217,8 +217,8 @@ struct ieee80211_chanctx_conf {
* @BSS_CHANGED_TXPOWER: TX power setting changed for this interface
* @BSS_CHANGED_P2P_PS: P2P powersave settings (CTWindow, opportunistic PS)
* changed (currently only in P2P client mode, GO mode will be later)
- * @BSS_CHANGED_DTIM_PERIOD: the DTIM period value was changed (set when
- * it becomes valid, managed mode only)
+ * @BSS_CHANGED_BEACON_INFO: Data from the AP's beacon became available:
+ * currently dtim_period only is under consideration.
* @BSS_CHANGED_BANDWIDTH: The bandwidth used by this interface changed,
* note that this is only called when it changes after the channel
* context had been assigned.
@@ -244,7 +244,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_PS = 1<<17,
BSS_CHANGED_TXPOWER = 1<<18,
BSS_CHANGED_P2P_PS = 1<<19,
- BSS_CHANGED_DTIM_PERIOD = 1<<20,
+ BSS_CHANGED_BEACON_INFO = 1<<20,
BSS_CHANGED_BANDWIDTH = 1<<21,
/* when adding here, make sure to change ieee80211_reconfig */
@@ -288,7 +288,7 @@ enum ieee80211_rssi_event {
* IEEE80211_HW_2GHZ_SHORT_SLOT_INCAPABLE hardware flag
* @dtim_period: num of beacons before the next DTIM, for beaconing,
* valid in station mode only if after the driver was notified
- * with the %BSS_CHANGED_DTIM_PERIOD flag, will be non-zero then.
+ * with the %BSS_CHANGED_BEACON_INFO flag, will be non-zero then.
* @sync_tsf: last beacon's/probe response's TSF timestamp (could be old
* as it may have been received during scanning long ago). If the
* HW flag %IEEE80211_HW_TIMING_BEACON_ONLY is set, then this can
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 9eed6f1..7a6f1a0 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -366,7 +366,7 @@ struct ieee80211_mgd_assoc_data {
u8 ssid_len;
u8 supp_rates_len;
bool wmm, uapsd;
- bool have_beacon, need_beacon;
+ bool need_beacon;
bool synced;
bool timeout_started;
@@ -404,6 +404,7 @@ struct ieee80211_if_managed {
bool powersave; /* powersave requested for this iface */
bool broken_ap; /* AP is broken -- turn off powersave */
+ bool have_beacon;
u8 dtim_period;
enum ieee80211_smps_mode req_smps, /* requested smps mode */
driver_smps_mode; /* smps mode request */
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index aa5cd2e..ad9bb9e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1360,7 +1360,7 @@ static bool ieee80211_powersave_allowed(struct ieee80211_sub_if_data *sdata)
IEEE80211_STA_CONNECTION_POLL))
return false;
- if (!sdata->vif.bss_conf.dtim_period)
+ if (!mgd->have_beacon)
return false;
rcu_read_lock();
@@ -1771,7 +1771,7 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
ieee80211_led_assoc(local, 1);
- if (sdata->u.mgd.assoc_data->have_beacon) {
+ if (sdata->u.mgd.have_beacon) {
/*
* If the AP is buggy we may get here with no DTIM period
* known, so assume it's 1 which is the only safe assumption
@@ -1779,7 +1779,7 @@ static void ieee80211_set_associated(struct ieee80211_sub_if_data *sdata,
* probably just won't work at all.
*/
bss_conf->dtim_period = sdata->u.mgd.dtim_period ?: 1;
- bss_info_changed |= BSS_CHANGED_DTIM_PERIOD;
+ bss_info_changed |= BSS_CHANGED_BEACON_INFO;
} else {
bss_conf->dtim_period = 0;
}
@@ -1903,6 +1903,7 @@ static void ieee80211_set_disassoc(struct ieee80211_sub_if_data *sdata,
del_timer_sync(&sdata->u.mgd.chswitch_timer);
sdata->vif.bss_conf.dtim_period = 0;
+ ifmgd->have_beacon = false;
ifmgd->flags = 0;
ieee80211_vif_release_channel(sdata);
@@ -2877,7 +2878,7 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
const struct ieee80211_tim_ie *tim_ie = elems.tim;
ifmgd->dtim_period = tim_ie->dtim_period;
}
- ifmgd->assoc_data->have_beacon = true;
+ ifmgd->have_beacon = true;
ifmgd->assoc_data->need_beacon = false;
if (local->hw.flags & IEEE80211_HW_TIMING_BEACON_ONLY) {
sdata->vif.bss_conf.sync_tsf =
@@ -3059,7 +3060,7 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
* If we haven't had a beacon before, tell the driver about the
* DTIM period (and beacon timing if desired) now.
*/
- if (!bss_conf->dtim_period) {
+ if (!ifmgd->have_beacon) {
/* a few bogus AP send dtim_period = 0 or no TIM IE */
if (elems.tim)
bss_conf->dtim_period = elems.tim->dtim_period ?: 1;
@@ -3078,7 +3079,8 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
sdata->vif.bss_conf.sync_dtim_count = 0;
}
- changed |= BSS_CHANGED_DTIM_PERIOD;
+ changed |= BSS_CHANGED_BEACON_INFO;
+ ifmgd->have_beacon = true;
mutex_lock(&local->iflist_mtx);
ieee80211_recalc_ps(local, -1);
@@ -3424,8 +3426,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
if (ifmgd->assoc_data && ifmgd->assoc_data->timeout_started &&
time_after(jiffies, ifmgd->assoc_data->timeout)) {
- if ((ifmgd->assoc_data->need_beacon &&
- !ifmgd->assoc_data->have_beacon) ||
+ if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
ieee80211_do_assoc(sdata)) {
u8 bssid[ETH_ALEN];
@@ -4193,6 +4194,7 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data *sdata,
ifmgd->assoc_data = assoc_data;
ifmgd->dtim_period = 0;
+ ifmgd->have_beacon = false;
err = ieee80211_prep_connection(sdata, req->bss, true);
if (err)
@@ -4224,7 +4226,7 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data *sdata,
ifmgd->dtim_period = tim->dtim_period;
dtim_count = tim->dtim_count;
}
- assoc_data->have_beacon = true;
+ ifmgd->have_beacon = true;
assoc_data->timeout = jiffies;
assoc_data->timeout_started = true;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 89a8377..5a6c135 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1584,8 +1584,9 @@ int ieee80211_reconfig(struct ieee80211_local *local)
BSS_CHANGED_ARP_FILTER |
BSS_CHANGED_PS;
- if (sdata->u.mgd.dtim_period)
- changed |= BSS_CHANGED_DTIM_PERIOD;
+ /* Re-send beacon info report to the driver */
+ if (sdata->u.mgd.have_beacon)
+ changed |= BSS_CHANGED_BEACON_INFO;
sdata_lock(sdata);
ieee80211_bss_info_change_notify(sdata, changed);
--
1.8.0
^ permalink raw reply related
* Re: [ath9k-devel] 4.9GHz and 5.8GHz regulatory entries?
From: Adrian Chadd @ 2013-06-05 7:21 UTC (permalink / raw)
To: Josef Semler; +Cc: linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <CAPsaeQOe0O56whfn1cUvjz46WS7A=6qRh0eu5C2QhO70o7d9Ug@mail.gmail.com>
What's the FCC rules for 5.8ghz atm?
adrian
On 4 June 2013 21:41, Josef Semler <josef.semler@gmail.com> wrote:
> Hi Adrian,
> I've done a modification for 5.8 ghz and some outdoor tests usin
> ubnt-hardware.
> Joe
>
> Am Mittwoch, 5. Juni 2013 schrieb Adrian Chadd :
>>
>> Hi all,
>>
>> I'm hacking at the support needed for 4.9 and 5.8GHz NICs in FreeBSD.
>> Well, there's support for them (and they work!) but I'm doing up some
>> regulatory entries for them.
>>
>> So, has anyone looked at adding 4.9 and 5.8GHz regulatory domain
>> entries to db.txt in Linux, for regulatory domains that allow them to
>> be used unlicenced?
>>
>> Thanks,
>>
>>
>>
>> Adrian
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel@lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-06-05 7:46 UTC (permalink / raw)
To: Malinen, Jouni
Cc: qca_vkondrat, Peer, Ilan, linux-wireless@vger.kernel.org,
Rodriguez, Luis, John W . Linville
In-Reply-To: <8887AA04B7EC49479420AE48C5F94A930EF6C0AA@NASANEXD02D.na.qualcomm.com>
On Tue, 2013-06-04 at 14:35 +0000, Malinen, Jouni wrote:
> In general, I'd agree. However, I would like to get information of any
> peer device being in active PBC mode. This would require either getting
> those Probe Request frames
I think I like that alternative better :-)
I know I wouldn't find it quickly ... can you be more specific about
what "being in active PBC mode" means? Is that easily detectable?
I'm thinking we should just document this (and be as specific about it
as we can) in the documentation for the offload feature.
johannes
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-06-05 7:53 UTC (permalink / raw)
To: Vladimir Kondratiev
Cc: Jouni Malinen, Peer, Ilan, linux-wireless@vger.kernel.org,
Rodriguez, Luis, John W . Linville
In-Reply-To: <2109265.XIVW7kjjZK@lx-vladimir>
On Wed, 2013-06-05 at 10:10 +0300, Vladimir Kondratiev wrote:
> Then, I think it would be appropriate to say following in the comment for
> start_p2p_find (no code changes, it is only expectations for the friver behavior):
>
> While performing P2P discovery, driver should report all received
> probe-request and probe-response frames via cfg80211_rx_mgmt,
> accordingly to the rx mgmt filter, as set by mgmt_frame_register().
Well, realistically there will be a frame registration for probe
requests, so stating that is kinda pointless, but OK.
> When reporting probes, driver/firmware may do its best to filter out
> probes that would not be replied with probe-resp accordingly to the
> P2P rules for active device configuration.
This I think should be more specific. "[W]ould not be replied" is
clearly one step, but in an environment where you actually want to
offload the P2P probe responses that is pretty much useless. I'd rather
say something like:
---
When probe response offload it supported, the device should not report
probe requests to the host that it already responded to. It must report
(and therefore not respond to) probe requests that indicate the sending
device is in active PBC mode (specifically, <...add more details...>).
It may also drop invalid or malformed probe requests or ones that would
not be replied to for other reasons.
---
I think this would be a reasonable tradeoff. It means that if a probe
request is actually reported, wpa_supplicant must reply to it, and we
don't have to get into the business of having to decide whether or not
it needs to respond.
Alternatively, we could specify that the device _must_ respond if
offload is supported, and then report it.
However, we need to clearly specify this so that we don't get two
responses, one from the device and one from wpa_s. If there's no way to
specify this, we need to introduce a "reply already sent" flag into the
frame reporting.
johannes
^ permalink raw reply
* [PATCH] brcmsmac: disable power-save related functions
From: Arend van Spriel @ 2013-06-05 7:59 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, David Miller, Arend van Spriel
This patch fixes a regression introduced by:
commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sun Mar 24 01:45:52 2013 +0100
brcmsmac: remove brcms_bss_cfg->associated
The regression behaviour is described in:
http://www.spinics.net/lists/linux-wireless/msg107474.html
Before the mentioned commit the return value of
the function brcms_c_ps_allowed() was always false,
which is desired behaviour as power-save is not
supported at the moment. Therefor, the function is
changed to just return false instead of simply
reverting the mentioned commit.
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
Sorry, John
Hope the revised commit message has all the needed
information now. Without this patch brcmsmac is
useless for anyone using it in station mode.
Gr. AvS
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/main.c b/drivers/net/wireless/brcm80211/brcmsmac/main.c
index 28e7aee..9fd6f2f 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/main.c
@@ -3074,21 +3074,8 @@ static void brcms_b_antsel_set(struct brcms_hardware *wlc_hw, u32 antsel_avail)
*/
static bool brcms_c_ps_allowed(struct brcms_c_info *wlc)
{
- /* disallow PS when one of the following global conditions meets */
- if (!wlc->pub->associated)
- return false;
-
- /* disallow PS when one of these meets when not scanning */
- if (wlc->filter_flags & FIF_PROMISC_IN_BSS)
- return false;
-
- if (wlc->bsscfg->type == BRCMS_TYPE_AP)
- return false;
-
- if (wlc->bsscfg->type == BRCMS_TYPE_ADHOC)
- return false;
-
- return true;
+ /* not supporting PS so always return false for now */
+ return false;
}
static void brcms_c_statsupd(struct brcms_c_info *wlc)
--
1.7.10.4
^ permalink raw reply related
* Re: cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets
From: Kalle Valo @ 2013-06-05 8:06 UTC (permalink / raw)
To: Solomon Peachy; +Cc: Dan Carpenter, linux-wireless
In-Reply-To: <20130604134340.GA3813@shaftnet.org>
Solomon Peachy <pizza@shaftnet.org> writes:
> On Tue, Jun 04, 2013 at 06:09:55AM -0700, Dan Carpenter wrote:
>> The patch a910e4a94f69: "cw1200: add driver for the ST-E CW1100 &
>> CW1200 WLAN chipsets" from May 24, 2013, has poor input validation
>> so the user could write to arbitrary memory.
>
>> Also I think this API looks like things which should be done with
>> normal ioctls. This driver only lets you load the firmware using a
>> very ugly custom debugfs interface?
>
> No, this is a debugging interface designed to interact with the
> vendor-supplied testing tool and the passthrough API it requires. The
> vendor tool controls the device init sequence, including special
> engineering firmware.
>
> Support for the ETF hooks is optional, and even if compiled in has to be
> explicitly enabled with a module parameter.
>
[...]
>
> I'll try to robustify this rather ugly interface as much as possible.
We have nl80211 testmode interface for just stuff like this. I recommend
using that instead of debugfs.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Arend van Spriel @ 2013-06-05 8:10 UTC (permalink / raw)
To: Johannes Berg
Cc: Malinen, Jouni, qca_vkondrat, Peer, Ilan,
linux-wireless@vger.kernel.org, Rodriguez, Luis,
John W . Linville
In-Reply-To: <1370418378.8920.12.camel@jlt4.sipsolutions.net>
On 06/05/2013 09:46 AM, Johannes Berg wrote:
> On Tue, 2013-06-04 at 14:35 +0000, Malinen, Jouni wrote:
>
>> In general, I'd agree. However, I would like to get information of any
>> peer device being in active PBC mode. This would require either getting
>> those Probe Request frames
>
> I think I like that alternative better :-)
>
> I know I wouldn't find it quickly ... can you be more specific about
> what "being in active PBC mode" means? Is that easily detectable?
>
> I'm thinking we should just document this (and be as specific about it
> as we can) in the documentation for the offload feature.
Remark from the sideline. One of the motivations for the P2P find
offload (when done on the device) is that the host can sleep, right? So
how/when does wpa_s want these Probe Request frames. After the
driver/device completed the find?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] iwlegacy: fix error return code in il3945_pci_probe()
From: Stanislaw Gruszka @ 2013-06-05 8:13 UTC (permalink / raw)
To: Wei Yongjun; +Cc: linville, yongjun_wei, linux-wireless
In-Reply-To: <CAPgLHd8XdFPQ+HUq085qmge66dhMxJurrZ2Uwut4w6Pfh_sqhA@mail.gmail.com>
On Wed, Jun 05, 2013 at 10:16:33AM +0800, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fix to return a negative error code in the il3945_hw_set_hw_params() error
> handling case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Jouni Malinen @ 2013-06-05 8:12 UTC (permalink / raw)
To: Johannes Berg
Cc: qca_vkondrat, Peer, Ilan, linux-wireless@vger.kernel.org,
Rodriguez, Luis, John W . Linville
In-Reply-To: <1370418378.8920.12.camel@jlt4.sipsolutions.net>
On Wed, Jun 05, 2013 at 09:46:18AM +0200, Johannes Berg wrote:
> I know I wouldn't find it quickly ... can you be more specific about
> what "being in active PBC mode" means? Is that easily detectable?
Having Device Password ID attribute in the WSC element set to 4
(PushButton) in Probe Request frames (or Probe Response and Beacon
frames in case of AP/GO).
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Johannes Berg @ 2013-06-05 8:18 UTC (permalink / raw)
To: Arend van Spriel
Cc: Malinen, Jouni, qca_vkondrat, Peer, Ilan,
linux-wireless@vger.kernel.org, Rodriguez, Luis,
John W . Linville
In-Reply-To: <51AEF266.3050005@broadcom.com>
On Wed, 2013-06-05 at 10:10 +0200, Arend van Spriel wrote:
> On 06/05/2013 09:46 AM, Johannes Berg wrote:
> > On Tue, 2013-06-04 at 14:35 +0000, Malinen, Jouni wrote:
> >
> >> In general, I'd agree. However, I would like to get information of any
> >> peer device being in active PBC mode. This would require either getting
> >> those Probe Request frames
> >
> > I think I like that alternative better :-)
> >
> > I know I wouldn't find it quickly ... can you be more specific about
> > what "being in active PBC mode" means? Is that easily detectable?
> >
> > I'm thinking we should just document this (and be as specific about it
> > as we can) in the documentation for the offload feature.
>
> Remark from the sideline. One of the motivations for the P2P find
> offload (when done on the device) is that the host can sleep, right? So
> how/when does wpa_s want these Probe Request frames. After the
> driver/device completed the find?
I don't think the device can really _sleep_ during this time, but it
allows reducing CPU wakeups. If you really wanted to sleep then you'd
have to buffer at least some information and have some sort of wakeup
trigger. That'll probably be done eventually, but it's not the rationale
here I think.
The way I see it, this patch allows being discoverable and discovering
other peers with much less impact on CPU usage.
The next step would be P2P-listen offload, which is more interesting for
being discoverable, and should also have probe request offload similar
to what we're discussing here.
johannes
^ permalink raw reply
* Re: [PATCH] brcmsmac: disable power-save related functions
From: Kalle Valo @ 2013-06-05 8:28 UTC (permalink / raw)
To: Arend van Spriel; +Cc: John W. Linville, linux-wireless, David Miller
In-Reply-To: <1370419185-3977-1-git-send-email-arend@broadcom.com>
"Arend van Spriel" <arend@broadcom.com> writes:
> This patch fixes a regression introduced by:
>
> commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date: Sun Mar 24 01:45:52 2013 +0100
>
> brcmsmac: remove brcms_bss_cfg->associated
>
> The regression behaviour is described in:
>
> http://www.spinics.net/lists/linux-wireless/msg107474.html
The link is not a very reliable reference, it can die anytime and
there's no way to know what message it refers to. Stating the message id
would better. And the best would be to copy the full text to the commit
log, it's only few lines anyway.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v8] cfg80211: P2P find phase offload
From: Arend van Spriel @ 2013-06-05 8:38 UTC (permalink / raw)
To: Johannes Berg
Cc: Malinen, Jouni, qca_vkondrat, Peer, Ilan,
linux-wireless@vger.kernel.org, Rodriguez, Luis,
John W . Linville
In-Reply-To: <1370420283.8920.21.camel@jlt4.sipsolutions.net>
On 06/05/2013 10:18 AM, Johannes Berg wrote:
> On Wed, 2013-06-05 at 10:10 +0200, Arend van Spriel wrote:
>> On 06/05/2013 09:46 AM, Johannes Berg wrote:
>>> On Tue, 2013-06-04 at 14:35 +0000, Malinen, Jouni wrote:
>>>
>>>> In general, I'd agree. However, I would like to get information of any
>>>> peer device being in active PBC mode. This would require either getting
>>>> those Probe Request frames
>>>
>>> I think I like that alternative better :-)
>>>
>>> I know I wouldn't find it quickly ... can you be more specific about
>>> what "being in active PBC mode" means? Is that easily detectable?
>>>
>>> I'm thinking we should just document this (and be as specific about it
>>> as we can) in the documentation for the offload feature.
>>
>> Remark from the sideline. One of the motivations for the P2P find
>> offload (when done on the device) is that the host can sleep, right? So
>> how/when does wpa_s want these Probe Request frames. After the
>> driver/device completed the find?
>
> I don't think the device can really _sleep_ during this time, but it
> allows reducing CPU wakeups. If you really wanted to sleep then you'd
> have to buffer at least some information and have some sort of wakeup
> trigger. That'll probably be done eventually, but it's not the rationale
> here I think.
Right. Indeed meant CPU wakeups.
> The way I see it, this patch allows being discoverable and discovering
> other peers with much less impact on CPU usage.
>
> The next step would be P2P-listen offload, which is more interesting for
> being discoverable, and should also have probe request offload similar
> to what we're discussing here.
Ah, I thought that was included. The WFA spec is a bit confusing using
terms 'phases' and 'states'. There is a SCAN phase and a FIND phase.
During the FIND phase a device can be in SEARCH or LISTEN state. I know
it is all terminology, but I was confused. At least the commit message
seems to imply both states are offloaded.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] brcmsmac: disable power-save related functions
From: Kalle Valo @ 2013-06-05 8:44 UTC (permalink / raw)
To: Arend van Spriel; +Cc: John W. Linville, linux-wireless, David Miller
In-Reply-To: <878v2p3qst.fsf@purkki.adurom.net>
Kalle Valo <kvalo@adurom.com> writes:
> "Arend van Spriel" <arend@broadcom.com> writes:
>
>> This patch fixes a regression introduced by:
>>
>> commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
>> Author: Hauke Mehrtens <hauke@hauke-m.de>
>> Date: Sun Mar 24 01:45:52 2013 +0100
>>
>> brcmsmac: remove brcms_bss_cfg->associated
>>
>> The regression behaviour is described in:
>>
>> http://www.spinics.net/lists/linux-wireless/msg107474.html
>
> The link is not a very reliable reference, it can die anytime and
> there's no way to know what message it refers to. Stating the message id
> would better. And the best would be to copy the full text to the commit
> log, it's only few lines anyway.
Johannes gave a handy tip. Gmane has a service which uses message ids:
http://mid.gmane.org/5197DC4F.7030503@broadcom.com
If the link or service dies, one can find the email with the message id
visible from the link.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] brcmsmac: disable power-save related functions
From: Arend van Spriel @ 2013-06-05 8:46 UTC (permalink / raw)
To: Kalle Valo; +Cc: John W. Linville, linux-wireless, David Miller
In-Reply-To: <874ndd3q20.fsf@purkki.adurom.net>
On 06/05/2013 10:44 AM, Kalle Valo wrote:
> Kalle Valo <kvalo@adurom.com> writes:
>
>> "Arend van Spriel" <arend@broadcom.com> writes:
>>
>>> This patch fixes a regression introduced by:
>>>
>>> commit 6da3b6c48d79da96a36c2632053cf4f53bf48fb2
>>> Author: Hauke Mehrtens <hauke@hauke-m.de>
>>> Date: Sun Mar 24 01:45:52 2013 +0100
>>>
>>> brcmsmac: remove brcms_bss_cfg->associated
>>>
>>> The regression behaviour is described in:
>>>
>>> http://www.spinics.net/lists/linux-wireless/msg107474.html
>>
>> The link is not a very reliable reference, it can die anytime and
>> there's no way to know what message it refers to. Stating the message id
>> would better. And the best would be to copy the full text to the commit
>> log, it's only few lines anyway.
>
> Johannes gave a handy tip. Gmane has a service which uses message ids:
>
> http://mid.gmane.org/5197DC4F.7030503@broadcom.com
>
> If the link or service dies, one can find the email with the message id
> visible from the link.
>
What if gmane dies ;-)
Gr. AvS
^ permalink raw reply
* Re: [PATCH] ath9k_htc: fix skb_under_panic error
From: Helmut Schaa @ 2013-06-05 8:54 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1370371064-6903-1-git-send-email-linux@rempel-privat.de>
Hi,
On Tue, Jun 4, 2013 at 8:37 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
> This error seems to be really rare, and we do not know real couse of it.
> But, in any case, we should check size of head before reducing it.
We had a similar issue in rt2x00 quite some time ago.
In general mac80211 should always reserve enough headroom as requested by
the driver in hw->extra_tx_headroom. However, there is a chance that a frame is
send to the driver again (see ieee80211_handle_filtered_frame). But if the frame
payload (or head) was moved due to padding and was not restored before calling
ieee80211_tx_status by the driver the second trip through the driver has reduced
headroom and could lead to such an error.
Quickly checking ath9k_htc it seems as if ath9k_htc_tx adds some padding
but ath9k_htc_tx_process does not remove the padding when passing the frame
back to mac80211.
Helmut
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Kalle Valo @ 2013-06-05 9:47 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: Johannes Berg, linux-wireless, Antonio Quartulli
In-Reply-To: <1370241587-2609-1-git-send-email-ordex@autistici.org>
Antonio Quartulli <ordex@autistici.org> writes:
> From: Antonio Quartulli <antonio@open-mesh.com>
>
> Users may want to send a frame on the current channel
> without specifying it.
>
> Make mgmt_tx pass a NULL channel to mac80211 if none has
> been specified by the user.
>
> Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
Why? And what users are we talking about here? It would be nice if the
commit log would give some context here for use who nothing about this
patch. "Users may want" is not very informative :)
--
Kalle Valo
^ permalink raw reply
* Re: ath6kl_mgmt_tx with NULL chan
From: Kalle Valo @ 2013-06-05 9:57 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Nicolas Cavallari, Johannes Berg, linux-wireless,
Antonio Quartulli, ath6kl-devel
In-Reply-To: <20130603171430.GE1226@ritirata.org>
Antonio Quartulli <ordex@autistici.org> writes:
> On Mon, Jun 03, 2013 at 05:04:08PM +0200, Nicolas Cavallari wrote:
>> On 03/06/2013 16:59, Johannes Berg wrote:
>> > On Mon, 2013-06-03 at 08:39 +0200, Antonio Quartulli wrote:
>> >> From: Antonio Quartulli <antonio@open-mesh.com>
>> >>
>> >> Users may want to send a frame on the current channel
>> >> without specifying it.
>> >>
>> >> Make mgmt_tx pass a NULL channel to mac80211 if none has
>> >> been specified by the user.
>> >
>> > cfg80211 isn't just a mac80211 frontend ... ;-)
>> >
>> > Also, as Nicolas said, ath6kl_mgmt_tx() will crash after this patch if
>> > it's called in AP mode w/o a channel, so you need to think about that.
>>
>> It will crash unconditionally. All ath6kl_mgmt_tx()'s code paths access
>> chan->center_freq at some point.
>
> Hello Nicolas,
> I'm also CCing Kalle Valo since get_maintainer.pl told me he is the guy for
> these kind of questions :-)
>
> I'm looking at ath6kl_mgmt_tx() in ath6kl/cfg80211.c and I've seen that the
> currently "configured" frequency can be obtained by reading the
> ath6kl_vif->ch_hint field.
>
> But, is this correct?
I did a quick look. To me using ch_hint looks correct.
> I couldn't see any real relation between the ch_hint field and the
> real frequency (probably because a lot of logic is hidden to the
> driver). I could only understand that the ch_hint field stores the
> frequency passed as parameter during the connection, but I have found
> no guarantee that this is the really used one.
Can you be more specific, please?
To me it looks that ch_hint is used both with ath6kl_wmi_reconnect_cmd()
and ath6kl_wmi_connect_cmd() commands, which both are used to connect to
a network. I don't see any other variables used for specifying the
frequency to the firmware. But I could just be blind...
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Antonio Quartulli @ 2013-06-05 9:53 UTC (permalink / raw)
To: Kalle Valo
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <877gi8khyi.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]
On Wed, Jun 05, 2013 at 02:47:01AM -0700, Kalle Valo wrote:
> Antonio Quartulli <ordex@autistici.org> writes:
>
> > From: Antonio Quartulli <antonio@open-mesh.com>
> >
> > Users may want to send a frame on the current channel
> > without specifying it.
> >
> > Make mgmt_tx pass a NULL channel to mac80211 if none has
> > been specified by the user.
> >
> > Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
>
> Why? And what users are we talking about here? It would be nice if the
> commit log would give some context here for use who nothing about this
> patch. "Users may want" is not very informative :)
Hello Kalle,
thanks for your feedback.
Sure, I can change the commit log.
However, I already wrote a couple of (userspace) applications which wanted to
send a message on the current channel and the only way to do it was to first get
the current channel and then pass it when sending a CMD_FRAME via nl80211. Of
course this approach is just a bit racy :-)
Moreover, I'm currently working on improving IBSS/RSN support in wpa_supplicant
and sending frames on the current channel is needed.
Do you think it is worth mentioning userspace applications like wpa_s in the
kernel commit message?
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Kalle Valo @ 2013-06-05 10:05 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <20130605095311.GA2349@open-mesh.com>
Antonio Quartulli <antonio@open-mesh.com> writes:
> On Wed, Jun 05, 2013 at 02:47:01AM -0700, Kalle Valo wrote:
>> Antonio Quartulli <ordex@autistici.org> writes:
>>
>> > From: Antonio Quartulli <antonio@open-mesh.com>
>> >
>> > Users may want to send a frame on the current channel
>> > without specifying it.
>> >
>> > Make mgmt_tx pass a NULL channel to mac80211 if none has
>> > been specified by the user.
>> >
>> > Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
>>
>> Why? And what users are we talking about here? It would be nice if the
>> commit log would give some context here for use who nothing about this
>> patch. "Users may want" is not very informative :)
>
> Hello Kalle,
> thanks for your feedback.
>
> Sure, I can change the commit log.
>
> However, I already wrote a couple of (userspace) applications which wanted to
> send a message on the current channel and the only way to do it was to first get
> the current channel and then pass it when sending a CMD_FRAME via nl80211. Of
> course this approach is just a bit racy :-)
>
> Moreover, I'm currently working on improving IBSS/RSN support in wpa_supplicant
> and sending frames on the current channel is needed.
>
> Do you think it is worth mentioning userspace applications like wpa_s in the
> kernel commit message?
I don't know what others think, but to me it is. It makes it easier to
understand why the change is made. And also do we really need the change
or not.
--
Kalle Valo
^ permalink raw reply
* Re: ath6kl_mgmt_tx with NULL chan
From: Antonio Quartulli @ 2013-06-05 10:03 UTC (permalink / raw)
To: Kalle Valo
Cc: Antonio Quartulli, Nicolas Cavallari, Johannes Berg,
linux-wireless@vger.kernel.org, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <8738swkhho.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]
On Wed, Jun 05, 2013 at 02:57:07AM -0700, Kalle Valo wrote:
> Antonio Quartulli <ordex@autistici.org> writes:
>
> > On Mon, Jun 03, 2013 at 05:04:08PM +0200, Nicolas Cavallari wrote:
> >> On 03/06/2013 16:59, Johannes Berg wrote:
> >> > On Mon, 2013-06-03 at 08:39 +0200, Antonio Quartulli wrote:
> >> >> From: Antonio Quartulli <antonio@open-mesh.com>
> >> >>
> >> >> Users may want to send a frame on the current channel
> >> >> without specifying it.
> >> >>
> >> >> Make mgmt_tx pass a NULL channel to mac80211 if none has
> >> >> been specified by the user.
> >> >
> >> > cfg80211 isn't just a mac80211 frontend ... ;-)
> >> >
> >> > Also, as Nicolas said, ath6kl_mgmt_tx() will crash after this patch if
> >> > it's called in AP mode w/o a channel, so you need to think about that.
> >>
> >> It will crash unconditionally. All ath6kl_mgmt_tx()'s code paths access
> >> chan->center_freq at some point.
> >
> > Hello Nicolas,
> > I'm also CCing Kalle Valo since get_maintainer.pl told me he is the guy for
> > these kind of questions :-)
> >
> > I'm looking at ath6kl_mgmt_tx() in ath6kl/cfg80211.c and I've seen that the
> > currently "configured" frequency can be obtained by reading the
> > ath6kl_vif->ch_hint field.
> >
> > But, is this correct?
>
> I did a quick look. To me using ch_hint looks correct.
>
> > I couldn't see any real relation between the ch_hint field and the
> > real frequency (probably because a lot of logic is hidden to the
> > driver). I could only understand that the ch_hint field stores the
> > frequency passed as parameter during the connection, but I have found
> > no guarantee that this is the really used one.
>
> Can you be more specific, please?
>
> To me it looks that ch_hint is used both with ath6kl_wmi_reconnect_cmd()
> and ath6kl_wmi_connect_cmd() commands, which both are used to connect to
> a network. I don't see any other variables used for specifying the
> frequency to the firmware. But I could just be blind...
I agree with your analysis. My doubt came from the fact that I don't know what
the firmware does and I was wondering whether it could ignore the channel passed
as argument on connect for some reason.
Actually the doubt was raised due to the variable name "ch_HINT".
But you are the ath6k expert :-) Therefore I guess this can work.
Thanks a lot!
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] nl80211: allow sending CMD_FRAME without specifying any frequency
From: Antonio Quartulli @ 2013-06-05 10:08 UTC (permalink / raw)
To: Kalle Valo
Cc: Antonio Quartulli, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <87y5aoj2ji.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
On Wed, Jun 05, 2013 at 03:05:21AM -0700, Kalle Valo wrote:
> Antonio Quartulli <antonio@open-mesh.com> writes:
>
> > On Wed, Jun 05, 2013 at 02:47:01AM -0700, Kalle Valo wrote:
> >> Antonio Quartulli <ordex@autistici.org> writes:
> >>
> >> > From: Antonio Quartulli <antonio@open-mesh.com>
> >> >
> >> > Users may want to send a frame on the current channel
> >> > without specifying it.
> >> >
> >> > Make mgmt_tx pass a NULL channel to mac80211 if none has
> >> > been specified by the user.
> >> >
> >> > Signed-off-by: Antonio Quartulli <antonio@open-mesh.com>
> >>
> >> Why? And what users are we talking about here? It would be nice if the
> >> commit log would give some context here for use who nothing about this
> >> patch. "Users may want" is not very informative :)
> >
> > Hello Kalle,
> > thanks for your feedback.
> >
> > Sure, I can change the commit log.
> >
> > However, I already wrote a couple of (userspace) applications which wanted to
> > send a message on the current channel and the only way to do it was to first get
> > the current channel and then pass it when sending a CMD_FRAME via nl80211. Of
> > course this approach is just a bit racy :-)
> >
> > Moreover, I'm currently working on improving IBSS/RSN support in wpa_supplicant
> > and sending frames on the current channel is needed.
> >
> > Do you think it is worth mentioning userspace applications like wpa_s in the
> > kernel commit message?
>
> I don't know what others think, but to me it is. It makes it easier to
> understand why the change is made. And also do we really need the change
> or not.
Oky. Then I'll change the commit message and add these details in the next
version.
Thanks!
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: ath6kl_mgmt_tx with NULL chan
From: Kalle Valo @ 2013-06-05 10:15 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Antonio Quartulli, Nicolas Cavallari, Johannes Berg,
linux-wireless@vger.kernel.org, ath6kl-devel@qca.qualcomm.com
In-Reply-To: <20130605100332.GB2349@open-mesh.com>
Antonio Quartulli <antonio@open-mesh.com> writes:
> On Wed, Jun 05, 2013 at 02:57:07AM -0700, Kalle Valo wrote:
>> Antonio Quartulli <ordex@autistici.org> writes:
>>
>> > I'm looking at ath6kl_mgmt_tx() in ath6kl/cfg80211.c and I've seen that the
>> > currently "configured" frequency can be obtained by reading the
>> > ath6kl_vif->ch_hint field.
>> >
>> > But, is this correct?
>>
>> I did a quick look. To me using ch_hint looks correct.
>>
>> > I couldn't see any real relation between the ch_hint field and the
>> > real frequency (probably because a lot of logic is hidden to the
>> > driver). I could only understand that the ch_hint field stores the
>> > frequency passed as parameter during the connection, but I have found
>> > no guarantee that this is the really used one.
>>
>> Can you be more specific, please?
>>
>> To me it looks that ch_hint is used both with ath6kl_wmi_reconnect_cmd()
>> and ath6kl_wmi_connect_cmd() commands, which both are used to connect to
>> a network. I don't see any other variables used for specifying the
>> frequency to the firmware. But I could just be blind...
>
> I agree with your analysis. My doubt came from the fact that I don't know what
> the firmware does and I was wondering whether it could ignore the channel passed
> as argument on connect for some reason.
It might do that, I'm not involved with the firmware development.
> Actually the doubt was raised due to the variable name "ch_HINT".
Yeah, the name is really misleading. But that's still legacy from the
pre-cleanup driver, so I wouldn't worry about that too much.
> But you are the ath6k expert :-) Therefore I guess this can work.
It should but you never know :)
But when modifying that code, please add a check to make sure that
channel 0 is not used by accident.
--
Kalle Valo
^ 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