* [PATCH 2/3] ath9k: use nohwcrypt in ath_common structure
From: John W. Linville @ 2011-01-05 19:22 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel, ath9k-devel, John W. Linville
In-Reply-To: <1294255328-14322-1-git-send-email-linville@tuxdriver.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/init.c | 5 +++--
drivers/net/wireless/ath/ath9k/main.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index fcc087c..0e97352 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -664,7 +664,6 @@ static inline void ath_read_cachesize(struct ath_common *common, int *csz)
}
extern struct ieee80211_ops ath9k_ops;
-extern int modparam_nohwcrypt;
extern int led_blink;
extern int ath9k_pm_qos_value;
extern bool is_ath9k_unloaded;
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index b6643b5..9aafd29 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -29,7 +29,7 @@ static unsigned int ath9k_debug = ATH_DBG_DEFAULT;
module_param_named(debug, ath9k_debug, uint, 0);
MODULE_PARM_DESC(debug, "Debugging mask");
-int modparam_nohwcrypt;
+static int modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption");
@@ -552,6 +552,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
common->priv = sc;
common->debug_mask = ath9k_debug;
common->btcoex_enabled = ath9k_btcoex_enable == 1;
+ common->nohwcrypt = modparam_nohwcrypt;
spin_lock_init(&common->cc_lock);
spin_lock_init(&sc->wiphy_lock);
@@ -653,7 +654,7 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
- if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || modparam_nohwcrypt)
+ if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || common->nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
hw->wiphy->interface_modes =
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index a818e4f..b2149ee 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1829,7 +1829,7 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
int ret = 0;
- if (modparam_nohwcrypt)
+ if (common->nohwcrypt)
return -ENOSPC;
mutex_lock(&sc->mutex);
--
1.7.3.4
^ permalink raw reply related
* [PATCH] ath9k: correct MODULE_PARM_DESC parameters for force_new_ani
From: John W. Linville @ 2011-01-05 19:15 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
index fdb5a83..f8a7771 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c
@@ -22,7 +22,7 @@
int modparam_force_new_ani;
module_param_named(force_new_ani, modparam_force_new_ani, int, 0444);
-MODULE_PARM_DESC(nohwcrypt, "Force new ANI for AR5008, AR9001, AR9002");
+MODULE_PARM_DESC(force_new_ani, "Force new ANI for AR5008, AR9001, AR9002");
/* General hardware code for the A5008/AR9001/AR9002 hadware families */
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] ath9k: qualify global modparam_nohwcrypt variable
From: John W. Linville @ 2011-01-05 19:23 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel
In-Reply-To: <1294238357-4624-1-git-send-email-linville@tuxdriver.com>
I believe I would prefer the version I just sent, that moves nohwcrypt to ath_common...
John
On Wed, Jan 05, 2011 at 09:39:17AM -0500, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
> drivers/net/wireless/ath/ath9k/init.c | 6 +++---
> drivers/net/wireless/ath/ath9k/main.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
> index fcc087c..3681caf5 100644
> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
> @@ -664,7 +664,7 @@ static inline void ath_read_cachesize(struct ath_common *common, int *csz)
> }
>
> extern struct ieee80211_ops ath9k_ops;
> -extern int modparam_nohwcrypt;
> +extern int ath9k_modparam_nohwcrypt;
> extern int led_blink;
> extern int ath9k_pm_qos_value;
> extern bool is_ath9k_unloaded;
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index b6643b5..767d8b8 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -29,8 +29,8 @@ static unsigned int ath9k_debug = ATH_DBG_DEFAULT;
> module_param_named(debug, ath9k_debug, uint, 0);
> MODULE_PARM_DESC(debug, "Debugging mask");
>
> -int modparam_nohwcrypt;
> -module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
> +int ath9k_modparam_nohwcrypt;
> +module_param_named(nohwcrypt, ath9k_modparam_nohwcrypt, int, 0444);
> MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption");
>
> int led_blink;
> @@ -653,7 +653,7 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
> hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
>
> - if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || modparam_nohwcrypt)
> + if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || ath9k_modparam_nohwcrypt)
> hw->flags |= IEEE80211_HW_MFP_CAPABLE;
>
> hw->wiphy->interface_modes =
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index a818e4f..f90a6ca 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -1829,7 +1829,7 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
> struct ath_common *common = ath9k_hw_common(sc->sc_ah);
> int ret = 0;
>
> - if (modparam_nohwcrypt)
> + if (ath9k_modparam_nohwcrypt)
> return -ENOSPC;
>
> mutex_lock(&sc->mutex);
> --
> 1.7.3.4
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] ath5k: qualify global modparam_nohwcrypt variable
From: John W. Linville @ 2011-01-05 19:24 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel
In-Reply-To: <1294238399-4701-1-git-send-email-linville@tuxdriver.com>
I believe I would prefer the version I just sent, that moves nohwcrypt to ath_common...
John
On Wed, Jan 05, 2011 at 09:39:59AM -0500, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/ath/ath5k/base.c | 4 ++--
> drivers/net/wireless/ath/ath5k/mac80211-ops.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
> index fce9a98..019a74d 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -61,8 +61,8 @@
> #include "debug.h"
> #include "ani.h"
>
> -int modparam_nohwcrypt;
> -module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
> +int ath5k_modparam_nohwcrypt;
> +module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
> MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
>
> static int modparam_all_channels;
> diff --git a/drivers/net/wireless/ath/ath5k/mac80211-ops.c b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
> index de257a3..d76d68c 100644
> --- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
> +++ b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
> @@ -46,7 +46,7 @@
> #include "base.h"
> #include "reg.h"
>
> -extern int modparam_nohwcrypt;
> +extern int ath5k_modparam_nohwcrypt;
>
> /* functions used from base.c */
> void set_beacon_filter(struct ieee80211_hw *hw, bool enable);
> @@ -485,7 +485,7 @@ ath5k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
> struct ath_common *common = ath5k_hw_common(ah);
> int ret = 0;
>
> - if (modparam_nohwcrypt)
> + if (ath5k_modparam_nohwcrypt)
> return -EOPNOTSUPP;
>
> switch (key->cipher) {
> --
> 1.7.3.4
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 0/8] wireless: DFS region support
From: John W. Linville @ 2011-01-05 18:30 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Kathy Giori, Amod Bodas, David Quan,
Michael Green, linux-wireless@vger.kernel.org
In-Reply-To: <20110105182838.GC10391@tux>
On Wed, Jan 05, 2011 at 10:28:38AM -0800, Luis R. Rodriguez wrote:
> On Tue, Jan 04, 2011 at 10:49:28AM -0800, John W. Linville wrote:
> > On Mon, Dec 20, 2010 at 12:02:26PM -0500, Luis R. Rodriguez wrote:
> > > This series has a list of changes to kernel and userspace to start addressing
> > > DFS region support. I've cheated and figured out a way to alter the current
> > > regulatory database in such a way that it remains backwards compatible with
> > > older databases so that no new CRDAs are required and we don't have to provide
> > > two releases for old kernels and newer kernels for wireless-regdb updates.
> > >
> > > In the end we end up passing the DFS region to the drivers. In terms of our DFS
> > > development roadmap this covers parts I and II as promissed that I would take care
> > > of by tomorrow, and leaves open now the chance for developers to start working
> > > on part III: "Where do we stuff DFS parameters for each region":
> > >
> > > http://wireless.kernel.org/en/developers/DFS
> > >
> > > In tomorrow's meeting we can cover who is going to work on part III. People who
> > > want to work on part III can start using these patches on their systems.
> > >
> > > John, lets wait to merge these until Wednesday, I post these in patch form as I
> > > think they are ready but tomorrow's discussions may push us to alter this a
> > > bit, not sure. I will also review what we have done here with Michael Green so
> > > he is on the same page.
> >
> > Well, now there has been plenty of time to reflect...comments? :-)
>
> I'll reduce the number of bits to 8 instead of 16 for the DFS regions, I'll also
> try to schedule a call with Michael to finalize his review on this and then I'll
> respin and submit again.
Well, since Linus released 2.6.37 yesterday there is now no great hurry...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 0/8] wireless: DFS region support
From: Luis R. Rodriguez @ 2011-01-05 18:28 UTC (permalink / raw)
To: John W. Linville
Cc: Luis Rodriguez, Kathy Giori, Amod Bodas, David Quan,
Michael Green, linux-wireless@vger.kernel.org
In-Reply-To: <20110104184928.GA13239@tuxdriver.com>
On Tue, Jan 04, 2011 at 10:49:28AM -0800, John W. Linville wrote:
> On Mon, Dec 20, 2010 at 12:02:26PM -0500, Luis R. Rodriguez wrote:
> > This series has a list of changes to kernel and userspace to start addressing
> > DFS region support. I've cheated and figured out a way to alter the current
> > regulatory database in such a way that it remains backwards compatible with
> > older databases so that no new CRDAs are required and we don't have to provide
> > two releases for old kernels and newer kernels for wireless-regdb updates.
> >
> > In the end we end up passing the DFS region to the drivers. In terms of our DFS
> > development roadmap this covers parts I and II as promissed that I would take care
> > of by tomorrow, and leaves open now the chance for developers to start working
> > on part III: "Where do we stuff DFS parameters for each region":
> >
> > http://wireless.kernel.org/en/developers/DFS
> >
> > In tomorrow's meeting we can cover who is going to work on part III. People who
> > want to work on part III can start using these patches on their systems.
> >
> > John, lets wait to merge these until Wednesday, I post these in patch form as I
> > think they are ready but tomorrow's discussions may push us to alter this a
> > bit, not sure. I will also review what we have done here with Michael Green so
> > he is on the same page.
>
> Well, now there has been plenty of time to reflect...comments? :-)
I'll reduce the number of bits to 8 instead of 16 for the DFS regions, I'll also
try to schedule a call with Michael to finalize his review on this and then I'll
respin and submit again.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Luis R. Rodriguez @ 2011-01-05 18:26 UTC (permalink / raw)
To: Paul Stewart
Cc: Luis Rodriguez, Johannes Berg, Amod Bodas,
linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTikDP_uF_jGh5bNyMv17VoZB=9u-SrdWRUQ15gRb@mail.gmail.com>
On Tue, Jan 04, 2011 at 02:29:53PM -0800, Paul Stewart wrote:
> On Tue, Jan 4, 2011 at 10:19 AM, Paul Stewart <pstew@google.com> wrote:
> > On Thu, Dec 16, 2010 at 9:44 AM, Luis R. Rodriguez
> > <lrodriguez@atheros.com> wrote:
> >> Try this:
> >
> > Happy new year. I've tried this patch, and the system continues to
> > suspend and resume successfully (i.e, the fix from the earlier patches
> > continues to alleviate the original problem), however the system
> > continues to be "deaf" to beacons at resume time if the system
> > suspends and resumes while associated. You don't need a ChromeOS
> > system to reproduce this issue. Just associate to the network and
> > suspend/resume. On resume the system believes it should be
> > associated, but then the beacon loss timer kicks in and we
> > disassociate, since we are never successful in receiving a response.
>
> Whoops. I didn't apply that change correctly. Actually, I think this
> change works. I think I may have spotted a couple of unrelated
> anomalies I'll trace down and address separately.
Great, I think this patch got sucked up already, I'll check.
Luis
^ permalink raw reply
* Re: [PATCH] ath9k: Show some live tx-queue values in debugfs.
From: Ben Greear @ 2011-01-05 17:48 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel
In-Reply-To: <1291744549-7646-1-git-send-email-greearb@candelatech.com>
On 12/07/2010 09:55 AM, greearb@candelatech.com wrote:
> From: Ben Greear<greearb@candelatech.com>
>
> I thought this might help track down stuck queues, etc.
Any comments on this one? Seems it was never picked up...
Thanks,
Ben
>
> Signed-off-by: Ben Greear<greearb@candelatech.com>
> ---
> :100644 100644 3586c43... 5075faa... M drivers/net/wireless/ath/ath9k/debug.c
> drivers/net/wireless/ath/ath9k/debug.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
> index 3586c43..5075faa 100644
> --- a/drivers/net/wireless/ath/ath9k/debug.c
> +++ b/drivers/net/wireless/ath/ath9k/debug.c
> @@ -589,6 +589,16 @@ static const struct file_operations fops_wiphy = {
> sc->debug.stats.txstats[WME_AC_VO].elem); \
> } while(0)
>
> +#define PRX(str, elem) \
> +do { \
> + len += snprintf(buf + len, size - len, \
> + "%s%13u%11u%10u%10u\n", str, \
> + (unsigned int)(sc->tx.txq[WME_AC_BE].elem), \
> + (unsigned int)(sc->tx.txq[WME_AC_BK].elem), \
> + (unsigned int)(sc->tx.txq[WME_AC_VI].elem), \
> + (unsigned int)(sc->tx.txq[WME_AC_VO].elem)); \
> +} while(0)
> +
> static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
> size_t count, loff_t *ppos)
> {
> @@ -619,6 +629,12 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
> PR("TX-Pkts-All: ", tx_pkts_all);
> PR("TX-Bytes-All: ", tx_bytes_all);
>
> + PRX("axq-qnum: ", axq_qnum);
> + PRX("axq-depth: ", axq_depth);
> + PRX("axq-stopped ", stopped);
> + PRX("tx-in-progress ", axq_tx_inprogress);
> + PRX("pending-frames ", pending_frames);
> +
> if (len> size)
> len = size;
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC] cfg80211: Add HT BSS attributes
From: Sujith @ 2011-01-05 16:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sujith, Jouni.Malinen, linux-wireless
In-Reply-To: <1294243398.3590.12.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Wed, 2011-01-05 at 21:17 +0530, Sujith wrote:
>
> > @@ -227,6 +227,8 @@ enum ieee80211_bss_change {
> > * example.
> > * @ht_operation_mode: HT operation mode (like in &struct ieee80211_ht_info).
> > * This field is only valid when the channel type is one of the HT types.
> > + * @ht_capab: HT capabilities (as in &struct ieee80211_ht_cap).
> > + * @ht_param: Operational HT parameters (as in &struct ieee80211_ht_info).
> > * @cqm_rssi_thold: Connection quality monitor RSSI threshold, a zero value
> > * implies disabled
> > * @cqm_rssi_hyst: Connection quality monitor RSSI hysteresis
>
> Err, also, how are these expected to have any effect?
Will send a v2 ...
Sujith
^ permalink raw reply
* Re: [RFC] cfg80211: Add HT BSS attributes
From: Sujith @ 2011-01-05 16:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sujith, Jouni.Malinen, linux-wireless
In-Reply-To: <1294243338.3590.11.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Wed, 2011-01-05 at 21:17 +0530, Sujith wrote:
> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> >
> > Add two new per-BSS attributes to allow configuration of
> > HT capabilites and operational parameters by hostapd.
>
> Looks fine, but
>
> > @@ -2597,6 +2597,12 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
> > if (info->attrs[NL80211_ATTR_BSS_HT_OPMODE])
> > params.ht_opmode =
> > nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_OPMODE]);
> > + if (info->attrs[NL80211_ATTR_BSS_HT_CAPAB])
> > + params.ht_capab =
> > + nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_CAPAB]);
> > + if (info->attrs[NL80211_ATTR_BSS_HT_PARAM])
> > + params.ht_param =
> > + nla_get_u8(info->attrs[NL80211_ATTR_BSS_HT_PARAM]);
> >
> > if (!rdev->ops->change_bss)
> > return -EOPNOTSUPP;
>
> This appears to be missing a -1 initialisation?
Will fix.
Sujith
^ permalink raw reply
* Re: [RFC] cfg80211: Add HT BSS attributes
From: Johannes Berg @ 2011-01-05 16:03 UTC (permalink / raw)
To: Sujith; +Cc: Jouni.Malinen, linux-wireless
In-Reply-To: <19748.37551.23627.698571@gargle.gargle.HOWL>
On Wed, 2011-01-05 at 21:17 +0530, Sujith wrote:
> @@ -227,6 +227,8 @@ enum ieee80211_bss_change {
> * example.
> * @ht_operation_mode: HT operation mode (like in &struct ieee80211_ht_info).
> * This field is only valid when the channel type is one of the HT types.
> + * @ht_capab: HT capabilities (as in &struct ieee80211_ht_cap).
> + * @ht_param: Operational HT parameters (as in &struct ieee80211_ht_info).
> * @cqm_rssi_thold: Connection quality monitor RSSI threshold, a zero value
> * implies disabled
> * @cqm_rssi_hyst: Connection quality monitor RSSI hysteresis
Err, also, how are these expected to have any effect?
johannes
^ permalink raw reply
* Re: [RFC] cfg80211: Add HT BSS attributes
From: Johannes Berg @ 2011-01-05 16:02 UTC (permalink / raw)
To: Sujith; +Cc: Jouni.Malinen, linux-wireless
In-Reply-To: <19748.37551.23627.698571@gargle.gargle.HOWL>
On Wed, 2011-01-05 at 21:17 +0530, Sujith wrote:
> From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
>
> Add two new per-BSS attributes to allow configuration of
> HT capabilites and operational parameters by hostapd.
Looks fine, but
> @@ -2597,6 +2597,12 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
> if (info->attrs[NL80211_ATTR_BSS_HT_OPMODE])
> params.ht_opmode =
> nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_OPMODE]);
> + if (info->attrs[NL80211_ATTR_BSS_HT_CAPAB])
> + params.ht_capab =
> + nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_CAPAB]);
> + if (info->attrs[NL80211_ATTR_BSS_HT_PARAM])
> + params.ht_param =
> + nla_get_u8(info->attrs[NL80211_ATTR_BSS_HT_PARAM]);
>
> if (!rdev->ops->change_bss)
> return -EOPNOTSUPP;
This appears to be missing a -1 initialisation?
johannes
^ permalink raw reply
* [RFC] cfg80211: Add HT BSS attributes
From: Sujith @ 2011-01-05 15:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jouni.Malinen, linux-wireless
From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
Add two new per-BSS attributes to allow configuration of
HT capabilites and operational parameters by hostapd.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
---
include/linux/nl80211.h | 6 ++++++
include/net/cfg80211.h | 6 ++++++
include/net/mac80211.h | 4 ++++
net/mac80211/cfg.c | 15 +++++++++++++++
net/wireless/nl80211.c | 6 ++++++
5 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index 2b89b71..94c7dde 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -881,6 +881,9 @@ enum nl80211_commands {
* @NL80211_ATTR_MESH_SETUP: Optional mesh setup parameters. These cannot be
* changed once the mesh is active.
*
+ * @NL80211_ATTR_BSS_HT_CAPAB: HT Capabilities for a BSS.
+ * @NL80211_ATTR_BSS_HT_PARAM: Current operational HT parameters.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1068,6 +1071,9 @@ enum nl80211_attrs {
NL80211_ATTR_WIPHY_ANTENNA_AVAIL_TX,
NL80211_ATTR_WIPHY_ANTENNA_AVAIL_RX,
+ NL80211_ATTR_BSS_HT_CAPAB,
+ NL80211_ATTR_BSS_HT_PARAM,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bcc9f44..67a2351 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -607,6 +607,10 @@ struct mpath_info {
* @ap_isolate: do not forward packets between connected stations
* @ht_opmode: HT Operation mode
* (u16 = opmode, -1 = do not change)
+ * @ht_capab: HT capabilities
+ * (u16 = capabilties, -1 = do not change)
+ * @ht_param: HT Operating parameters
+ * (u8 = parameters, -1 = do not change)
*/
struct bss_parameters {
int use_cts_prot;
@@ -616,6 +620,8 @@ struct bss_parameters {
u8 basic_rates_len;
int ap_isolate;
int ht_opmode;
+ int ht_capab;
+ int ht_param;
};
/*
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5b3fd5a..a7efd18 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -227,6 +227,8 @@ enum ieee80211_bss_change {
* example.
* @ht_operation_mode: HT operation mode (like in &struct ieee80211_ht_info).
* This field is only valid when the channel type is one of the HT types.
+ * @ht_capab: HT capabilities (as in &struct ieee80211_ht_cap).
+ * @ht_param: Operational HT parameters (as in &struct ieee80211_ht_info).
* @cqm_rssi_thold: Connection quality monitor RSSI threshold, a zero value
* implies disabled
* @cqm_rssi_hyst: Connection quality monitor RSSI hysteresis
@@ -261,6 +263,8 @@ struct ieee80211_bss_conf {
u32 basic_rates;
int mcast_rate[IEEE80211_NUM_BANDS];
u16 ht_operation_mode;
+ u16 ht_capab;
+ u8 ht_param;
s32 cqm_rssi_thold;
u32 cqm_rssi_hyst;
enum nl80211_channel_type channel_type;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 4bc8a92..f10c92b 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1172,6 +1172,21 @@ static int ieee80211_change_bss(struct wiphy *wiphy,
changed |= BSS_CHANGED_HT;
}
+ if (params->ht_capab >= 0) {
+ struct ieee80211_local *local = wiphy_priv(wiphy);
+ struct ieee80211_supported_band *sband =
+ wiphy->bands[local->oper_channel->band];
+
+ sdata->vif.bss_conf.ht_capab =
+ (u16) (params->ht_capab & sband->ht_cap.cap);
+ changed |= BSS_CHANGED_HT;
+ }
+
+ if (params->ht_param >= 0) {
+ sdata->vif.bss_conf.ht_param = (u8) params->ht_param;
+ changed |= BSS_CHANGED_HT;
+ }
+
ieee80211_bss_info_change_notify(sdata, changed);
return 0;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9b62710..69b0051 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2597,6 +2597,12 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_BSS_HT_OPMODE])
params.ht_opmode =
nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_OPMODE]);
+ if (info->attrs[NL80211_ATTR_BSS_HT_CAPAB])
+ params.ht_capab =
+ nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_CAPAB]);
+ if (info->attrs[NL80211_ATTR_BSS_HT_PARAM])
+ params.ht_param =
+ nla_get_u8(info->attrs[NL80211_ATTR_BSS_HT_PARAM]);
if (!rdev->ops->change_bss)
return -EOPNOTSUPP;
--
1.7.3.4
^ permalink raw reply related
* [PATCH] ath5k: qualify global modparam_nohwcrypt variable
From: John W. Linville @ 2011-01-05 14:39 UTC (permalink / raw)
To: linux-wireless; +Cc: ath5k-devel, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath5k/base.c | 4 ++--
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index fce9a98..019a74d 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -61,8 +61,8 @@
#include "debug.h"
#include "ani.h"
-int modparam_nohwcrypt;
-module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO);
+int ath5k_modparam_nohwcrypt;
+module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
static int modparam_all_channels;
diff --git a/drivers/net/wireless/ath/ath5k/mac80211-ops.c b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
index de257a3..d76d68c 100644
--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+++ b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
@@ -46,7 +46,7 @@
#include "base.h"
#include "reg.h"
-extern int modparam_nohwcrypt;
+extern int ath5k_modparam_nohwcrypt;
/* functions used from base.c */
void set_beacon_filter(struct ieee80211_hw *hw, bool enable);
@@ -485,7 +485,7 @@ ath5k_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
struct ath_common *common = ath5k_hw_common(ah);
int ret = 0;
- if (modparam_nohwcrypt)
+ if (ath5k_modparam_nohwcrypt)
return -EOPNOTSUPP;
switch (key->cipher) {
--
1.7.3.4
^ permalink raw reply related
* [PATCH] ath9k: qualify global modparam_nohwcrypt variable
From: John W. Linville @ 2011-01-05 14:39 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/init.c | 6 +++---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index fcc087c..3681caf5 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -664,7 +664,7 @@ static inline void ath_read_cachesize(struct ath_common *common, int *csz)
}
extern struct ieee80211_ops ath9k_ops;
-extern int modparam_nohwcrypt;
+extern int ath9k_modparam_nohwcrypt;
extern int led_blink;
extern int ath9k_pm_qos_value;
extern bool is_ath9k_unloaded;
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index b6643b5..767d8b8 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -29,8 +29,8 @@ static unsigned int ath9k_debug = ATH_DBG_DEFAULT;
module_param_named(debug, ath9k_debug, uint, 0);
MODULE_PARM_DESC(debug, "Debugging mask");
-int modparam_nohwcrypt;
-module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
+int ath9k_modparam_nohwcrypt;
+module_param_named(nohwcrypt, ath9k_modparam_nohwcrypt, int, 0444);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption");
int led_blink;
@@ -653,7 +653,7 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
- if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || modparam_nohwcrypt)
+ if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || ath9k_modparam_nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
hw->wiphy->interface_modes =
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index a818e4f..f90a6ca 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1829,7 +1829,7 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
int ret = 0;
- if (modparam_nohwcrypt)
+ if (ath9k_modparam_nohwcrypt)
return -ENOSPC;
mutex_lock(&sc->mutex);
--
1.7.3.4
^ permalink raw reply related
* Re: About clocks in the carl9170 firmware
From: Ignacy Gawedzki @ 2011-01-05 14:19 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTi=WQwx5hOxeGweFOLVtpss54NZsRyV0tkBqf4CP@mail.gmail.com>
On Wed, Jan 05, 2011 at 08:57:14AM -0500, thus spake Brian Prodoehl:
> On Wed, Jan 5, 2011 at 6:13 AM, Ignacy Gawedzki <i@lri.fr> wrote:
> > Hi,
> >
> > A few months ago, Christian Lamparter suggested to me the use of
> > get_clock_counter() in the carl9170 firmware code for time measurement
> > purposes.
> >
> > I just got back to that, after a long period of other things to do instead.
> >
> > According to the results of a few tests I've been running yesterday, it looks
> > that this clock is 44Mhz, not 40Mhz, nor 80Mhz.
>
> I have seen the same thing. In 802.11g mode, that clock counter runs
> at 44MHz. There are rumors that this changes with operating mode.
> Its easy to believe that it would run at 80MHz in turbo (40MHz
> channel-width) mode. But, I haven't tested that, and can only say
> that I've seen that clock counter run at 44MHz as well.
That would make sense indeed.
>
> > According to Christian, the clock source, as accessed through
> > get_clock_counter() is stable and does not depend on calls to clock_set().
> > This is further corroborated by the definition and use of the
> > AR9170_TICKS_PER_MICROSECOND *constant* in timer.h. But still, how comes that
> > constant is 80 then?
>
> Does anything in the firmware really rely on that constant being
> right? I'm more familiar with ar9170usb and the open firmware for
> that, where the constants were also wrong, but nothing used them
> except for some delay functions, for which the accuracy wasn't
> critical.
AFAICT, the delay functions are used during initialization and AGC
calibration. I have no idea whether the accuracy is critical or not in these
parts.
In any case, there is room for developing an accurate clock, assuming that it
always changes on request of the firmware and never by itself. I'll give it a
try and test whether it breaks everything or not. =)
--
I used to have a sig, but I've stopped smoking now.
^ permalink raw reply
* Re: wl12xx maintainer's email address will change
From: Luciano Coelho @ 2011-01-05 14:04 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20110105135905.GB2337@tuxdriver.com>
On Wed, 2011-01-05 at 14:59 +0100, John W. Linville wrote:
> On Wed, Jan 05, 2011 at 12:12:03PM +0200, Luciano Coelho wrote:
> > On Fri, 2010-12-31 at 09:05 +0100, Luciano Coelho wrote:
> > > Hi,
> > >
> > > Sorry for the spam for those who are not working with wl12xx.
> > >
> > > Today is the last day when my current email address
> > > (luciano.coelho@nokia.com) is valid. So please send all requests or
> > > questions that are supposed to reach me to the linux-wireless mailing
> > > list, so I can still read them.
> > >
> > > My new email address will be available by the beginning of next week.
> >
> > Okay, now my new email address is available. I'll send a patch to fix
> > the MAINTAINERS information shortly.
> >
> > The new email address is coelho@ti.com, please use that one when
> > submitting patches from now on.
>
> I suppose that we can safely presume that your new employer is happy
> with your wl12xx maintainer duties... :-)
Yes, probably happier than my previous one! At least now it feels like
I'm in the right place (for wl12xx maintainership, that is). :)
> Congrats!
Thanks!
--
Cheers,
Luca.
^ permalink raw reply
* Re: wl12xx maintainer's email address will change
From: John W. Linville @ 2011-01-05 13:59 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1294222323.14110.53.camel@pimenta>
On Wed, Jan 05, 2011 at 12:12:03PM +0200, Luciano Coelho wrote:
> On Fri, 2010-12-31 at 09:05 +0100, Luciano Coelho wrote:
> > Hi,
> >
> > Sorry for the spam for those who are not working with wl12xx.
> >
> > Today is the last day when my current email address
> > (luciano.coelho@nokia.com) is valid. So please send all requests or
> > questions that are supposed to reach me to the linux-wireless mailing
> > list, so I can still read them.
> >
> > My new email address will be available by the beginning of next week.
>
> Okay, now my new email address is available. I'll send a patch to fix
> the MAINTAINERS information shortly.
>
> The new email address is coelho@ti.com, please use that one when
> submitting patches from now on.
I suppose that we can safely presume that your new employer is happy
with your wl12xx maintainer duties... :-)
Congrats!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: About clocks in the carl9170 firmware
From: Brian Prodoehl @ 2011-01-05 13:57 UTC (permalink / raw)
To: Ignacy Gawedzki, linux-wireless
In-Reply-To: <20110105111314.GA23794@zenon.in.qult.net>
On Wed, Jan 5, 2011 at 6:13 AM, Ignacy Gawedzki <i@lri.fr> wrote:
> Hi,
>
> A few months ago, Christian Lamparter suggested to me the use of
> get_clock_counter() in the carl9170 firmware code for time measurement
> purposes.
>
> I just got back to that, after a long period of other things to do instead.
>
> According to the results of a few tests I've been running yesterday, it looks
> that this clock is 44Mhz, not 40Mhz, nor 80Mhz.
I have seen the same thing. In 802.11g mode, that clock counter runs
at 44MHz. There are rumors that this changes with operating mode.
Its easy to believe that it would run at 80MHz in turbo (40MHz
channel-width) mode. But, I haven't tested that, and can only say
that I've seen that clock counter run at 44MHz as well.
> According to Christian, the clock source, as accessed through
> get_clock_counter() is stable and does not depend on calls to clock_set().
> This is further corroborated by the definition and use of the
> AR9170_TICKS_PER_MICROSECOND *constant* in timer.h. But still, how comes that
> constant is 80 then?
Does anything in the firmware really rely on that constant being
right? I'm more familiar with ar9170usb and the open firmware for
that, where the constants were also wrong, but nothing used them
except for some delay functions, for which the accuracy wasn't
critical.
> I'm obviously missing something here. I would be really thankful to anybody
> who could explain how these clocks/timers work and how they are supposed to be
> used.
>
> Thanks,
>
> Ignacy
-Brian
^ permalink raw reply
* About clocks in the carl9170 firmware
From: Ignacy Gawedzki @ 2011-01-05 11:13 UTC (permalink / raw)
To: linux-wireless
Hi,
A few months ago, Christian Lamparter suggested to me the use of
get_clock_counter() in the carl9170 firmware code for time measurement
purposes.
I just got back to that, after a long period of other things to do instead.
According to the results of a few tests I've been running yesterday, it looks
that this clock is 44Mhz, not 40Mhz, nor 80Mhz.
According to Christian, the clock source, as accessed through
get_clock_counter() is stable and does not depend on calls to clock_set().
This is further corroborated by the definition and use of the
AR9170_TICKS_PER_MICROSECOND *constant* in timer.h. But still, how comes that
constant is 80 then?
I'm obviously missing something here. I would be really thankful to anybody
who could explain how these clocks/timers work and how they are supposed to be
used.
Thanks,
Ignacy
--
I have not lost my mind, it's backed up on disk somewhere.
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Wolfgang Kufner @ 2011-01-05 10:32 UTC (permalink / raw)
To: Aleksandar Milivojevic
Cc: Luis Correia, Luis R. Rodriguez, linux-wireless, users
In-Reply-To: <AANLkTimCsvR2zBfS+oCudhcUz68qPJhXM9-eu1L-FWHp@mail.gmail.com>
Hi Aleksandar,
On Wed, Jan 5, 2011 at 7:57 AM, Aleksandar Milivojevic
<alex@milivojevic.org> wrote:
> On Tue, Jan 4, 2011 at 2:31 PM, Wolfgang Kufner
> <wolfgang.kufner@gmail.com> wrote:
>> Maybe a fix for this issue is already in compat-wireless.
>
> Might be. I'll try compiling linux-next and see if it helps (could be
> few days, I need to setup this box for the task first).
>
There is no need to compile linux-next. Just compile the latest
bleeding edge compat-wireless tarball from
http://wireless.kernel.org/en/users/Download. It is only 4MB in size
and reflects the latest on the linux-next.git tree and takes only a
few minutes to compile.
HTH,
Wolfgang
^ permalink raw reply
* Re: wl12xx maintainer's email address will change
From: Luciano Coelho @ 2011-01-05 10:12 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1293782724.15791.14.camel@powerslave>
On Fri, 2010-12-31 at 09:05 +0100, Luciano Coelho wrote:
> Hi,
>
> Sorry for the spam for those who are not working with wl12xx.
>
> Today is the last day when my current email address
> (luciano.coelho@nokia.com) is valid. So please send all requests or
> questions that are supposed to reach me to the linux-wireless mailing
> list, so I can still read them.
>
> My new email address will be available by the beginning of next week.
Okay, now my new email address is available. I'll send a patch to fix
the MAINTAINERS information shortly.
The new email address is coelho@ti.com, please use that one when
submitting patches from now on.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC PATCH 13/17] zd1211rw: use stack for small cmd-buffers
From: Johannes Berg @ 2011-01-05 9:27 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110104234935.25309.7558.stgit@fate.lan>
On Wed, 2011-01-05 at 01:49 +0200, Jussi Kivilinna wrote:
> Use stack for allocing small < 64 byte arrays.
I don't think this is valid -- DMA memory can't be from the stack.
johannes
^ permalink raw reply
* Re: (rt61pci/hostapd) no packet activity when encryption is enabled and interface is bridged
From: C Anthony Risinger @ 2011-01-05 8:00 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless
In-Reply-To: <201101041936.47573.helmut.schaa@googlemail.com>
On Tue, Jan 4, 2011 at 12:36 PM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Am Dienstag, 4. Januar 2011 schrieb C Anthony Risinger:
>> On Mon, Jan 3, 2011 at 10:30 PM, C Anthony Risinger <anthony@extof.me> wrote:
>> >
>> > problem summary: an rt61pci driven card does not seem to allow any
>> > packets to enter/exit it's bridge ONLY WHEN ENCRYPTION is enabled;
>> > without it, everything works perfectly.
>>
>> hmmmmm....
>>
>> it would seem:
>>
>> options rt61pci nohwcrypt=1
>>
>> solves the problem. what does this mean? do i have a bad chip?
>
> I don't think so. Might be related to [1].
i think you might have called it (did not verify)! i built
compat-wireless 12/26/2010 and i am now able to use the hwencrypt
option. thanks!
> [1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=fa8b4b22d543b4052602b0c86065150613ed19e8
C Anthony
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Aleksandar Milivojevic @ 2011-01-05 6:57 UTC (permalink / raw)
To: Wolfgang Kufner; +Cc: Luis Correia, Luis R. Rodriguez, linux-wireless, users
In-Reply-To: <AANLkTin0W1_Tjr1zj0D0U+VeBpoGFRmB9iCdOfnMB-nR@mail.gmail.com>
On Tue, Jan 4, 2011 at 2:31 PM, Wolfgang Kufner
<wolfgang.kufner@gmail.com> wrote:
> Hi Aleksandar,
>
> I know just about nothing about regulatory domains but I think it
> might be good to try with a current compat-wireless next. I notice
> that the these log lines:
>
> "cfg80211: Received country IE:"
> "cfg80211: We intersect both of these and get:"
>
> do not exist in linux-next anymore since this commit:
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=4f366c5dabcb936dd5754a35188bd699181fe1ce
>
> Maybe a fix for this issue is already in compat-wireless.
Might be. I'll try compiling linux-next and see if it helps (could be
few days, I need to setup this box for the task first).
In the mean-time I played with things a bit.
I've created /etc/modprobe.d/cfg80211 as follows:
options cfg80211 ieee80211_regdom=US
This seems to have set user preference so that enabled frequencies are
set correctly initially (and also instead of switching to "world" (00)
when it looses connection to my AP, now it switches to US instead).
Next, I installed the "iw" tool, and it showed interesting results.
When connected to my Apple wireless router (5GHz WiFi-a/n network), I
get:
# iw reg get
country 98:
(5170 - 5250 @ 40), (3, 17)
(5735 - 5835 @ 40), (3, 30)
The log files show switching from US to 98 and back to US, but output
of iw reg get always claims country is 98 with above two frequency
ranges.
On the other hand, if I connect to my Linksys router (2.4GHz WiFi-b/g
network), there's no mention in log files about any switching between
regulatory domains, and output of iw reg get shows country correctly
set to US:
# iw reg get
country US:
(2402 - 2472 @ 40), (3, 27)
(5170 - 5250 @ 40), (3, 17)
(5250 - 5330 @ 40), (3, 20), DFS
(5490 - 5600 @ 40), (3, 20), DFS
(5650 - 5710 @ 40), (3, 20), DFS
(5735 - 5835 @ 40), (3, 30)
However, after several minutes, the connection to my Linksys WiFi
router fails again with nothing useful logged, the green LED on
WUSB600N wireless adapter goes off permanently, and attempt to connect
to any network (either of my two WiFi networks) fails. NetworkManager
still shows list of all networks (on both 2.4GHz and 5GHz bands), and
output of iw reg get still shows country set to US and all frequencies
listed for US as per above.
^ 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