* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Gertjan van Wingerde @ 2010-07-16 7:18 UTC (permalink / raw)
To: Helmut Schaa
Cc: Bartlomiej Zolnierkiewicz, Felix Fietkau, John W. Linville,
Ivo Van Doorn, Christoph Egger, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <AANLkTilqoYMMKYJT-YYbEzdnytUSYa0EylEiJ4x5xXXH@mail.gmail.com>
On 07/16/10 08:57, Helmut Schaa wrote:
> On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com <mailto:bzolnier@gmail.com>> wrote:
>
> On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
> > On 2010-07-14 3:15 PM, John W. Linville wrote:
> > > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> > >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com <mailto:luis.f.correia@gmail.com>> wrote:
> > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>> wrote:
> > >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> > >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> > >> >> so all Code depending on that can't ever be selected and, if there's
> > >> >> no plan to add these options, should be cleaned up
> > >> >>
> > >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>>
> > >> >
> > >> > NAK,
> > >> >
> > >> > this is not dead code, it is needed for the Ralink System-on-Chip
> > >> > Platform devices.
> > >> >
> > >> > While I can't fix Kconfig errors and the current KConfig file may be
> > >> > wrong, this code cannot and will not be deleted.
> > >>
> > >> When the config option was introduced, the config options RALINK_RT288X and
> > >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
> > >>
> > >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> > >> isn't dead but actually in use.
> > >
> > > Perhaps Helmut and Felix can send us the missing code?
> > The missing code is a MIPS platform port, which is currently being
> > maintained in OpenWrt, but is not ready for upstream submission yet.
> > I'm not working on this code at the moment, but I think it will be
> > submitted once it's ready.
>
> People are using automatic scripts to catch unused config options nowadays
> so the issue is quite likely to come back again sooner or later..
>
> Would it be possible to improve situation somehow till the missing parts
> get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
> situation to Kconfig (if the config option itself really cannot be removed)
> until all code is ready etc.?
>
>
> Or we could just remove RT2800PCI_SOC completely and build the soc specific
> parts always as part of rt2800pci. I mean it's not much code, just the platform
> driver stuff and the eeprom access.
>
I'm not sure if that is feasible. Sure, we can reduce the usage of the variable by
unconditionally compiling in the generic SOC code, but we should not unconditionally
register the SOC platform device, which is currently also under the scope of this
Kconfig variable.
---
Gertjan.
^ permalink raw reply
* what's the status of ATHEROS_AR71XX config variable?
From: Robert P. J. Day @ 2010-07-16 8:43 UTC (permalink / raw)
To: linux-wireless, ath9k-devel
from drivers/net/wireless/ath/ath9k/Makefile:
ath9k-$(CONFIG_ATHEROS_AR71XX) += ahb.o
but there is no such config variable. so i'm thinking *something*
should be removed.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Top-notch, inexpensive online Linux/OSS/kernel courses
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: yogeshp @ 2010-07-16 9:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Pradeep Nemavat, Nishant Sarmukadam, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTiljhQpDh_20zEf8HjYnk82BpUi4Gctu9G90aqpS@mail.gmail.com>
Hi Luis,
Please see inline comments
Luis R. Rodriguez wrote:
> On Thu, Jul 15, 2010 at 6:18 AM, yogeshp <yogeshp@marvell.com> wrote:
>> BA window size for a successful BA setup is not made available to the driver by
>> mac80211. The patch below gets the BA window size from addba response and
>> indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
> But why do you want that? Your patch and commit log do not mention why
> you need this.
BA window size from ADDBA response defines how many outstanding MPDUs are allowed for the BA stream by recipient. Since ADDBA response is processed in mac80211 stack, mac80211 should communicate the BA window size to driver (and may be from driver it is further communicated to firmware/hardware) to control the number of outstanding MPDUs while transmitting MPDUs for the stream.
> When I compile mac80211 with your patch it fails compilation
I do not see this compilation error, I think the patch did not apply cleanly. I will send out another patch without extra white spaces that should solve the compilation issue. If the change is fine, we can then send patches to fix the compilation issues for other drivers too.
Thanks
Yogesh
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Helmut Schaa @ 2010-07-16 10:08 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Bartlomiej Zolnierkiewicz, Felix Fietkau, John W. Linville,
Ivo Van Doorn, Christoph Egger, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <4C4007CD.2070504@gmail.com>
On Fri, Jul 16, 2010 at 9:18 AM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
>
> On 07/16/10 08:57, Helmut Schaa wrote:
> > On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com <mailto:bzolnier@gmail.com>> wrote:
> >
> > On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
> > > On 2010-07-14 3:15 PM, John W. Linville wrote:
> > > > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> > > >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com <mailto:luis.f.correia@gmail.com>> wrote:
> > > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>> wrote:
> > > >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> > > >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> > > >> >> so all Code depending on that can't ever be selected and, if there's
> > > >> >> no plan to add these options, should be cleaned up
> > > >> >>
> > > >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>>
> > > >> >
> > > >> > NAK,
> > > >> >
> > > >> > this is not dead code, it is needed for the Ralink System-on-Chip
> > > >> > Platform devices.
> > > >> >
> > > >> > While I can't fix Kconfig errors and the current KConfig file may be
> > > >> > wrong, this code cannot and will not be deleted.
> > > >>
> > > >> When the config option was introduced, the config options RALINK_RT288X and
> > > >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
> > > >>
> > > >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> > > >> isn't dead but actually in use.
> > > >
> > > > Perhaps Helmut and Felix can send us the missing code?
> > > The missing code is a MIPS platform port, which is currently being
> > > maintained in OpenWrt, but is not ready for upstream submission yet.
> > > I'm not working on this code at the moment, but I think it will be
> > > submitted once it's ready.
> >
> > People are using automatic scripts to catch unused config options nowadays
> > so the issue is quite likely to come back again sooner or later..
> >
> > Would it be possible to improve situation somehow till the missing parts
> > get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
> > situation to Kconfig (if the config option itself really cannot be removed)
> > until all code is ready etc.?
> >
> >
> > Or we could just remove RT2800PCI_SOC completely and build the soc specific
> > parts always as part of rt2800pci. I mean it's not much code, just the platform
> > driver stuff and the eeprom access.
> >
>
> I'm not sure if that is feasible. Sure, we can reduce the usage of the variable by
> unconditionally compiling in the generic SOC code, but we should not unconditionally
> register the SOC platform device, which is currently also under the scope of this
> Kconfig variable.
Ehm, no, the platform device is not registered in rt2800pci at all,
it's just the platform
driver that gets registered there. The platform device will be
registered in the according
board init code (that only resides in openwrt at the moment).
Helmut
^ permalink raw reply
* Re: what's the status of ATHEROS_AR71XX config variable?
From: Felix Fietkau @ 2010-07-16 10:45 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: linux-wireless, ath9k-devel, Gabor Juhos
In-Reply-To: <alpine.DEB.2.00.1007160440530.13924@lynx>
On 2010-07-16 10:43 AM, Robert P. J. Day wrote:
>
> from drivers/net/wireless/ath/ath9k/Makefile:
>
> ath9k-$(CONFIG_ATHEROS_AR71XX) += ahb.o
>
> but there is no such config variable. so i'm thinking *something*
> should be removed.
The platform port for AR71xx hasn't been submitted upstream yet. But the
code in ahb.c is actively being used in OpenWrt.
I don't know what the status on submitting the code to linux-mips is,
but I've Cc'd Gabor, he should know ;)
- Felix
^ permalink raw reply
* Re: what's the status of ATHEROS_AR71XX config variable?
From: Robert P. J. Day @ 2010-07-16 10:57 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, ath9k-devel, Gabor Juhos
In-Reply-To: <4C403859.70201@openwrt.org>
On Fri, 16 Jul 2010, Felix Fietkau wrote:
> On 2010-07-16 10:43 AM, Robert P. J. Day wrote:
> >
> > from drivers/net/wireless/ath/ath9k/Makefile:
> >
> > ath9k-$(CONFIG_ATHEROS_AR71XX) += ahb.o
> >
> > but there is no such config variable. so i'm thinking *something*
> > should be removed.
> The platform port for AR71xx hasn't been submitted upstream yet. But
> the code in ahb.c is actively being used in OpenWrt.
>
> I don't know what the status on submitting the code to linux-mips
> is, but I've Cc'd Gabor, he should know ;)
ok. i wasn't passing judgment one way or the other, just making an
observation that the mainstream kernel doesn't define that config
variable. you can take it from here.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Top-notch, inexpensive online Linux/OSS/kernel courses
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* [PATCH] mac80211: skip HT parsing if HW does not support HT
From: Christian Lamparter @ 2010-07-16 11:01 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, John W Linville
In-Reply-To: <4C3E311B.7070402@openwrt.org>
This patch will also fix the odd freeze which occurred
when minstrel_ht connects to an 802.11n network with
legacy hardware.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
John,
As you know Felix has favored the alternative.
Therefore, can you please ignore
[PATCH] minstrel_ht: fix freeze with legacy hardware
and use this one instead?
Regards,
Chr
---
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index be928ef..9d101fb 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -29,7 +29,7 @@ void ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_supported_band *sband,
memset(ht_cap, 0, sizeof(*ht_cap));
- if (!ht_cap_ie)
+ if (!ht_cap_ie || !sband->ht_cap.ht_supported)
return;
ht_cap->ht_supported = true;
^ permalink raw reply related
* [RFC] mac80211: move QoS-enable to BSS info
From: Johannes Berg @ 2010-07-16 11:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Stanislaw Gruszka
Ever since
commit e1b3ec1a2a336c328c336cfa5485a5f0484cc90d
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date: Mon Mar 29 12:18:34 2010 +0200
mac80211: explicitly disable/enable QoS
mac80211 is telling drivers, in particular
iwlwifi, whether QoS is enabled or not.
However, this is only relevant for station mode,
since only then will any device send nullfunc
frames and need to know whether they should be
QoS frames or not. In other modes, there are
(currently) no frames the device is supposed to
send.
When you now consider virtual interfaces, it
becomes apparent that the current mechanism is
inadequate since it enables/disables QoS on a
global scale, where for nullfunc frames it has
to be on a per-interface scale.
Due to the above considerations, we can change
the way mac80211 advertises the QoS state to
drivers to only ever advertise it as "off" in
station mode, and make it a per-BSS setting.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Stanislaw, can you please test this? I have no legacy APs that really
don't understand QoS frames. I suppose I could use a sniffer but maybe
it's easier for you to just test with the AP you have?
drivers/net/wireless/iwlwifi/iwl-core.c | 18 +++++++++---------
include/net/mac80211.h | 11 +++++------
net/mac80211/cfg.c | 4 ----
net/mac80211/mlme.c | 11 ++++++-----
net/mac80211/util.c | 7 ++++---
5 files changed, 24 insertions(+), 27 deletions(-)
--- wireless-testing.orig/include/net/mac80211.h 2010-07-16 11:44:49.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-07-16 13:22:38.000000000 +0200
@@ -147,6 +147,8 @@ struct ieee80211_low_level_stats {
* @BSS_CHANGED_CQM: Connection quality monitor config changed
* @BSS_CHANGED_IBSS: IBSS join status changed
* @BSS_CHANGED_ARP_FILTER: Hardware ARP filter address list or state changed.
+ * @BSS_CHANGED_QOS: QoS for this association was enabled/disabled. Note
+ * that it is only ever disabled for station mode.
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -162,6 +164,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_CQM = 1<<10,
BSS_CHANGED_IBSS = 1<<11,
BSS_CHANGED_ARP_FILTER = 1<<12,
+ BSS_CHANGED_QOS = 1<<13,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -217,6 +220,7 @@ enum ieee80211_bss_change {
* filter ARP queries based on the @arp_addr_list, if disabled, the
* hardware must not perform any ARP filtering. Note, that the filter will
* be enabled also in promiscuous mode.
+ * @qos: This is a QoS-enabled BSS.
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -240,6 +244,7 @@ struct ieee80211_bss_conf {
__be32 arp_addr_list[IEEE80211_BSS_ARP_ADDR_LIST_LEN];
u8 arp_addr_cnt;
bool arp_filter_enabled;
+ bool qos;
};
/**
@@ -620,15 +625,11 @@ struct ieee80211_rx_status {
* may turn the device off as much as possible. Typically, this flag will
* be set when an interface is set UP but not associated or scanning, but
* it can also be unset in that case when monitor interfaces are active.
- * @IEEE80211_CONF_QOS: Enable 802.11e QoS also know as WMM (Wireless
- * Multimedia). On some drivers (iwlwifi is one of know) we have
- * to enable/disable QoS explicitly.
*/
enum ieee80211_conf_flags {
IEEE80211_CONF_MONITOR = (1<<0),
IEEE80211_CONF_PS = (1<<1),
IEEE80211_CONF_IDLE = (1<<2),
- IEEE80211_CONF_QOS = (1<<3),
};
@@ -643,7 +644,6 @@ enum ieee80211_conf_flags {
* @IEEE80211_CONF_CHANGE_RETRY_LIMITS: retry limits changed
* @IEEE80211_CONF_CHANGE_IDLE: Idle flag changed
* @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
- * @IEEE80211_CONF_CHANGE_QOS: Quality of service was enabled or disabled
*/
enum ieee80211_conf_changed {
IEEE80211_CONF_CHANGE_SMPS = BIT(1),
@@ -654,7 +654,6 @@ enum ieee80211_conf_changed {
IEEE80211_CONF_CHANGE_CHANNEL = BIT(6),
IEEE80211_CONF_CHANGE_RETRY_LIMITS = BIT(7),
IEEE80211_CONF_CHANGE_IDLE = BIT(8),
- IEEE80211_CONF_CHANGE_QOS = BIT(9),
};
/**
--- wireless-testing.orig/net/mac80211/cfg.c 2010-07-16 13:16:46.000000000 +0200
+++ wireless-testing/net/mac80211/cfg.c 2010-07-16 13:17:23.000000000 +0200
@@ -1154,10 +1154,6 @@ static int ieee80211_set_txq_params(stru
return -EINVAL;
}
- /* enable WMM or activate new settings */
- local->hw.conf.flags |= IEEE80211_CONF_QOS;
- drv_config(local, IEEE80211_CONF_CHANGE_QOS);
-
return 0;
}
--- wireless-testing.orig/net/mac80211/mlme.c 2010-07-16 13:16:46.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2010-07-16 13:23:52.000000000 +0200
@@ -698,10 +698,11 @@ void ieee80211_dynamic_ps_timer(unsigned
/* MLME */
static void ieee80211_sta_wmm_params(struct ieee80211_local *local,
- struct ieee80211_if_managed *ifmgd,
+ struct ieee80211_sub_if_data *sdata,
u8 *wmm_param, size_t wmm_param_len)
{
struct ieee80211_tx_queue_params params;
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
size_t left;
int count;
u8 *pos, uapsd_queues = 0;
@@ -790,8 +791,8 @@ static void ieee80211_sta_wmm_params(str
}
/* enable WMM or activate new settings */
- local->hw.conf.flags |= IEEE80211_CONF_QOS;
- drv_config(local, IEEE80211_CONF_CHANGE_QOS);
+ sdata->vif.bss_conf.qos = true;
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_QOS);
}
static u32 ieee80211_handle_bss_capability(struct ieee80211_sub_if_data *sdata,
@@ -1325,7 +1326,7 @@ static bool ieee80211_assoc_success(stru
}
if (elems.wmm_param)
- ieee80211_sta_wmm_params(local, ifmgd, elems.wmm_param,
+ ieee80211_sta_wmm_params(local, sdata, elems.wmm_param,
elems.wmm_param_len);
else
ieee80211_set_wmm_default(sdata);
@@ -1597,7 +1598,7 @@ static void ieee80211_rx_mgmt_beacon(str
ieee80211_rx_bss_info(sdata, mgmt, len, rx_status, &elems,
true);
- ieee80211_sta_wmm_params(local, ifmgd, elems.wmm_param,
+ ieee80211_sta_wmm_params(local, sdata, elems.wmm_param,
elems.wmm_param_len);
}
--- wireless-testing.orig/net/mac80211/util.c 2010-07-16 13:16:46.000000000 +0200
+++ wireless-testing/net/mac80211/util.c 2010-07-16 13:24:30.000000000 +0200
@@ -803,8 +803,8 @@ void ieee80211_set_wmm_default(struct ie
/* after reinitialize QoS TX queues setting to default,
* disable QoS at all */
- local->hw.conf.flags &= ~IEEE80211_CONF_QOS;
- drv_config(local, IEEE80211_CONF_CHANGE_QOS);
+ sdata->vif.bss_conf.qos = sdata->vif.type != NL80211_IFTYPE_STATION;
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_QOS);
}
void ieee80211_sta_def_wmm_params(struct ieee80211_sub_if_data *sdata,
@@ -1161,7 +1161,8 @@ int ieee80211_reconfig(struct ieee80211_
BSS_CHANGED_BASIC_RATES |
BSS_CHANGED_BEACON_INT |
BSS_CHANGED_BSSID |
- BSS_CHANGED_CQM;
+ BSS_CHANGED_CQM |
+ BSS_CHANGED_QOS;
switch (sdata->vif.type) {
case NL80211_IFTYPE_STATION:
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.c 2010-07-16 13:25:42.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.c 2010-07-16 13:27:49.000000000 +0200
@@ -1763,6 +1763,15 @@ void iwl_bss_info_changed(struct ieee802
mutex_lock(&priv->mutex);
+ if (changes & BSS_CHANGED_QOS) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
+ priv->qos_data.qos_active = bss_conf->qos;
+ iwl_update_qos(priv);
+ spin_unlock_irqrestore(&priv->lock, flags);
+ }
+
if (changes & BSS_CHANGED_BEACON && vif->type == NL80211_IFTYPE_AP) {
dev_kfree_skb(priv->ibss_beacon);
priv->ibss_beacon = ieee80211_beacon_get(hw, vif);
@@ -2138,15 +2147,6 @@ int iwl_mac_config(struct ieee80211_hw *
iwl_set_tx_power(priv, conf->power_level, false);
}
- if (changed & IEEE80211_CONF_CHANGE_QOS) {
- bool qos_active = !!(conf->flags & IEEE80211_CONF_QOS);
-
- spin_lock_irqsave(&priv->lock, flags);
- priv->qos_data.qos_active = qos_active;
- iwl_update_qos(priv);
- spin_unlock_irqrestore(&priv->lock, flags);
- }
-
if (!iwl_is_ready(priv)) {
IWL_DEBUG_MAC80211(priv, "leave - not ready\n");
goto out;
^ permalink raw reply
* Re: [RFC] mac80211: move QoS-enable to BSS info
From: Stanislaw Gruszka @ 2010-07-16 13:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1279280060.3938.23.camel@jlt3.sipsolutions.net>
On Fri, 16 Jul 2010 13:34:20 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:
> Stanislaw, can you please test this? I have no legacy APs that really
> don't understand QoS frames. I suppose I could use a sniffer but maybe
> it's easier for you to just test with the AP you have?
I will test next week, right now I do not have hardware handy.
Stanislaw
^ permalink raw reply
* Re: rfkill failure in 2.6.35-rc3+
From: Andrew Lutomirski @ 2010-07-16 14:59 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org, ilw@linux.intel.com
In-Reply-To: <1277999967.4197.92.camel@rchatre-DESK>
I haven't been able to reproduce this, so I haven't tried unloading
the platform driver. I will if it happens again, though.
--Andy
On Thu, Jul 1, 2010 at 11:59 AM, reinette chatre
<reinette.chatre@intel.com> wrote:
> On Wed, 2010-06-30 at 19:59 -0700, Andrew Lutomirski wrote:
>> I just toggled rfkill on and back off on my X200s (WiFi Link 5350, rev
>> 0x24) and the link didn't come up. Toggling rfkill again didn't fix
>> it, but rmmod + modprobe did.
>>
>> dmesg said:
>>
>> [13629.424869] iwlagn 0000:03:00.0: RF_KILL bit toggled to disable radio.
>> [13629.432761] iwlagn 0000:03:00.0: Not sending command - RF KILL
>> [13629.432771] iwlagn 0000:03:00.0: Error sending REPLY_RXON:
>> enqueue_hcmd failed: -5
>> [13629.432778] iwlagn 0000:03:00.0: Error setting new RXON (-5)
>> [13631.268646] iwlagn 0000:03:00.0: RF_KILL bit toggled to enable radio.
>> [13631.311232] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [13675.710821] iwlagn 0000:03:00.0: RF_KILL bit toggled to disable radio.
>> [13675.713438] iwlagn 0000:03:00.0: Not sending command - RF KILL
>> [13675.713448] iwlagn 0000:03:00.0: Error sending REPLY_RXON:
>> enqueue_hcmd failed: -5
>> [13675.713455] iwlagn 0000:03:00.0: Error setting new RXON (-5)
>> [13683.090789] iwlagn 0000:03:00.0: RF_KILL bit toggled to enable radio.
>> [13683.145267] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>>
>> This is 2.6.35-rc3+ with firmware 8.24.2.12. I've never seen this before.
>
> Recently we have seen a few issues with rfkill state changes not being
> seen by the driver. In all cases it was "resolved" by unloading (or not
> loading from the beginning via blacklisting) of the platform driver. Can
> you try that?
>
> Reinette
>
>
>
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Gertjan van Wingerde @ 2010-07-16 15:46 UTC (permalink / raw)
To: Helmut Schaa
Cc: Bartlomiej Zolnierkiewicz, Felix Fietkau, John W. Linville,
Ivo Van Doorn, Christoph Egger, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <AANLkTik8M0gNipi_rwVJYbmo_3FfdHs-H4H_XDgTcbhI@mail.gmail.com>
On 07/16/10 12:08, Helmut Schaa wrote:
> On Fri, Jul 16, 2010 at 9:18 AM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>>
>> On 07/16/10 08:57, Helmut Schaa wrote:
>>> On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com <mailto:bzolnier@gmail.com>> wrote:
>>>
>>> On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
>>> > On 2010-07-14 3:15 PM, John W. Linville wrote:
>>> > > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
>>> > >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com <mailto:luis.f.correia@gmail.com>> wrote:
>>> > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>> wrote:
>>> > >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
>>> > >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
>>> > >> >> so all Code depending on that can't ever be selected and, if there's
>>> > >> >> no plan to add these options, should be cleaned up
>>> > >> >>
>>> > >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>>
>>> > >> >
>>> > >> > NAK,
>>> > >> >
>>> > >> > this is not dead code, it is needed for the Ralink System-on-Chip
>>> > >> > Platform devices.
>>> > >> >
>>> > >> > While I can't fix Kconfig errors and the current KConfig file may be
>>> > >> > wrong, this code cannot and will not be deleted.
>>> > >>
>>> > >> When the config option was introduced, the config options RALINK_RT288X and
>>> > >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
>>> > >>
>>> > >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
>>> > >> isn't dead but actually in use.
>>> > >
>>> > > Perhaps Helmut and Felix can send us the missing code?
>>> > The missing code is a MIPS platform port, which is currently being
>>> > maintained in OpenWrt, but is not ready for upstream submission yet.
>>> > I'm not working on this code at the moment, but I think it will be
>>> > submitted once it's ready.
>>>
>>> People are using automatic scripts to catch unused config options nowadays
>>> so the issue is quite likely to come back again sooner or later..
>>>
>>> Would it be possible to improve situation somehow till the missing parts
>>> get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
>>> situation to Kconfig (if the config option itself really cannot be removed)
>>> until all code is ready etc.?
>>>
>>>
>>> Or we could just remove RT2800PCI_SOC completely and build the soc specific
>>> parts always as part of rt2800pci. I mean it's not much code, just the platform
>>> driver stuff and the eeprom access.
>>>
>>
>> I'm not sure if that is feasible. Sure, we can reduce the usage of the variable by
>> unconditionally compiling in the generic SOC code, but we should not unconditionally
>> register the SOC platform device, which is currently also under the scope of this
>> Kconfig variable.
>
> Ehm, no, the platform device is not registered in rt2800pci at all,
> it's just the platform
> driver that gets registered there. The platform device will be
> registered in the according
> board init code (that only resides in openwrt at the moment).
>
OK. Didn't know that. Sounds good then.
However, I've tried this in my local tree, and now compilation fails on the x86 platform
due to a missing KSEG1ADDR macro. How do you suggest to handle the potentially missing
macro?
---
Gertjan.
^ permalink raw reply
* [PATCH] rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()
From: Stephen Boyd @ 2010-07-16 16:50 UTC (permalink / raw)
To: users; +Cc: Ivo van Doorn, John W. Linville, linux-wireless, netdev,
linux-kernel
The rt2x00dev->intf_work workqueue is never initialized when a driver is
probed for a non-existent device (in this case rt2500usb). On such a
path we call rt2x00lib_remove_dev() to free any resources initialized
during the probe before we use INIT_WORK to initialize the workqueue.
This causes lockdep to get confused since the lock used in the workqueue
hasn't been initialized yet but is now being acquired during
cancel_work_sync() called by rt2x00lib_remove_dev().
Fix this by initializing the workqueue first before we attempt to probe
the device. This should make lockdep happy and avoid breaking any
assumptions about how the library cleans up after a probe fails.
phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
Call Trace:
[<ffffffff8105fe59>] register_lock_class+0x152/0x31f
[<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111
[<ffffffff81061bde>] __lock_acquire+0xce/0xcf4
[<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf
[<ffffffff81492aef>] ? _raw_spin_unlock_irqrestore+0x33/0x41
[<ffffffff810628d5>] lock_acquire+0xd1/0xf7
[<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
[<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e
[<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
[<ffffffff8104f136>] cancel_work_sync+0xb/0xd
[<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
[<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
[<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52
[<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb]
[<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
[<ffffffff813468bd>] usb_probe_interface+0x151/0x19e
[<ffffffff812ea08e>] driver_probe_device+0xa7/0x136
[<ffffffff812ea167>] __driver_attach+0x4a/0x66
[<ffffffff812ea11d>] ? __driver_attach+0x0/0x66
[<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89
[<ffffffff812e9efd>] driver_attach+0x19/0x1b
[<ffffffff812e9b64>] bus_add_driver+0xb4/0x204
[<ffffffff812ea41b>] driver_register+0x98/0x109
[<ffffffff813465dd>] usb_register_driver+0xb2/0x173
[<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb]
[<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb]
[<ffffffff81000203>] do_one_initcall+0x6d/0x17a
[<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0
[<ffffffff8100296b>] system_call_fastpath+0x16/0x1b
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00dev.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 3ae468c..f20d3ee 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -854,6 +854,11 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
BIT(NL80211_IFTYPE_WDS);
/*
+ * Initialize configuration work.
+ */
+ INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
+
+ /*
* Let the driver probe the device to detect the capabilities.
*/
retval = rt2x00dev->ops->lib->probe_hw(rt2x00dev);
@@ -863,11 +868,6 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
}
/*
- * Initialize configuration work.
- */
- INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
-
- /*
* Allocate queue array.
*/
retval = rt2x00queue_allocate(rt2x00dev);
--
1.7.2.rc2.10.g637ab
^ permalink raw reply related
* Re: [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: Luis R. Rodriguez @ 2010-07-16 17:12 UTC (permalink / raw)
To: yogeshp
Cc: Pradeep Nemavat, Nishant Sarmukadam, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <4C402360.5050502@marvell.com>
On Fri, Jul 16, 2010 at 2:16 AM, yogeshp <yogeshp@marvell.com> wrote:
> Hi Luis,
> Please see inline comments
>
> Luis R. Rodriguez wrote:
>> On Thu, Jul 15, 2010 at 6:18 AM, yogeshp <yogeshp@marvell.com> wrote:
>>> BA window size for a successful BA setup is not made available to the driver by
>>> mac80211. The patch below gets the BA window size from addba response and
>>> indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
>
>> But why do you want that? Your patch and commit log do not mention why
>> you need this.
> BA window size from ADDBA response defines how many outstanding MPDUs are allowed for the BA stream by recipient. Since ADDBA response is processed in mac80211 stack, mac80211 should communicate the BA window size to driver (and may be from driver it is further communicated to firmware/hardware) to control the number of outstanding MPDUs while transmitting MPDUs for the stream.
What driver requires this? Your patch does all these changes but do
not show any secondary patch of a user, so the patch is pointless
right now.
>> When I compile mac80211 with your patch it fails compilation
> I do not see this compilation error, I think the patch did not apply cleanly. I will send out another patch without extra white spaces that should solve the compilation issue. If the change is fine, we can then send patches to fix the compilation issues for other drivers too.
>
..
Luis
^ permalink raw reply
* Re: what's the status of ATHEROS_AR71XX config variable?
From: Luis R. Rodriguez @ 2010-07-16 17:14 UTC (permalink / raw)
To: Felix Fietkau
Cc: Robert P. J. Day, linux-wireless, ath9k-devel, Gabor Juhos,
linux-mips
In-Reply-To: <4C403859.70201@openwrt.org>
On Fri, Jul 16, 2010 at 3:45 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2010-07-16 10:43 AM, Robert P. J. Day wrote:
>>
>> from drivers/net/wireless/ath/ath9k/Makefile:
>>
>> ath9k-$(CONFIG_ATHEROS_AR71XX) += ahb.o
>>
>> but there is no such config variable. so i'm thinking *something*
>> should be removed.
> The platform port for AR71xx hasn't been submitted upstream yet. But the
> code in ahb.c is actively being used in OpenWrt.
>
> I don't know what the status on submitting the code to linux-mips is,
> but I've Cc'd Gabor, he should know ;)
If its actively being supporting and tested, why not submit it now?
Any particular large pending blockers?
Luis
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Helmut Schaa @ 2010-07-16 17:44 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Bartlomiej Zolnierkiewicz, Felix Fietkau, John W. Linville,
Ivo Van Doorn, Christoph Egger, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <4C407ED4.6000002@gmail.com>
Am Freitag 16 Juli 2010 schrieb Gertjan van Wingerde:
> On 07/16/10 12:08, Helmut Schaa wrote:
> > On Fri, Jul 16, 2010 at 9:18 AM, Gertjan van Wingerde
> > <gwingerde@gmail.com> wrote:
> >>
> >> On 07/16/10 08:57, Helmut Schaa wrote:
> >>> On Thu, Jul 15, 2010 at 10:41 AM, Bartlomiej Zolnierkiewicz <bzolnier@gmail.com <mailto:bzolnier@gmail.com>> wrote:
> >>>
> >>> On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
> >>> > On 2010-07-14 3:15 PM, John W. Linville wrote:
> >>> > > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> >>> > >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com <mailto:luis.f.correia@gmail.com>> wrote:
> >>> > >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>> wrote:
> >>> > >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >>> > >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >>> > >> >> so all Code depending on that can't ever be selected and, if there's
> >>> > >> >> no plan to add these options, should be cleaned up
> >>> > >> >>
> >>> > >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de <mailto:siccegge@cs.fau.de>>
> >>> > >> >
> >>> > >> > NAK,
> >>> > >> >
> >>> > >> > this is not dead code, it is needed for the Ralink System-on-Chip
> >>> > >> > Platform devices.
> >>> > >> >
> >>> > >> > While I can't fix Kconfig errors and the current KConfig file may be
> >>> > >> > wrong, this code cannot and will not be deleted.
> >>> > >>
> >>> > >> When the config option was introduced, the config options RALINK_RT288X and
> >>> > >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
> >>> > >>
> >>> > >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> >>> > >> isn't dead but actually in use.
> >>> > >
> >>> > > Perhaps Helmut and Felix can send us the missing code?
> >>> > The missing code is a MIPS platform port, which is currently being
> >>> > maintained in OpenWrt, but is not ready for upstream submission yet.
> >>> > I'm not working on this code at the moment, but I think it will be
> >>> > submitted once it's ready.
> >>>
> >>> People are using automatic scripts to catch unused config options nowadays
> >>> so the issue is quite likely to come back again sooner or later..
> >>>
> >>> Would it be possible to improve situation somehow till the missing parts
> >>> get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
> >>> situation to Kconfig (if the config option itself really cannot be removed)
> >>> until all code is ready etc.?
> >>>
> >>>
> >>> Or we could just remove RT2800PCI_SOC completely and build the soc specific
> >>> parts always as part of rt2800pci. I mean it's not much code, just the platform
> >>> driver stuff and the eeprom access.
> >>>
> >>
> >> I'm not sure if that is feasible. Sure, we can reduce the usage of the variable by
> >> unconditionally compiling in the generic SOC code, but we should not unconditionally
> >> register the SOC platform device, which is currently also under the scope of this
> >> Kconfig variable.
> >
> > Ehm, no, the platform device is not registered in rt2800pci at all,
> > it's just the platform
> > driver that gets registered there. The platform device will be
> > registered in the according
> > board init code (that only resides in openwrt at the moment).
> >
>
> OK. Didn't know that. Sounds good then.
>
> However, I've tried this in my local tree, and now compilation fails on the x86 platform
> due to a missing KSEG1ADDR macro. How do you suggest to handle the potentially missing
> macro?
We can convert it to an ioremap call, that should be available on all platforms.
Helmut
^ permalink raw reply
* Re: [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: Helmut Schaa @ 2010-07-16 18:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: yogeshp, Pradeep Nemavat, Nishant Sarmukadam,
linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTim2fLLZfD5xrUtioY5mZaF-PgLwrVlMHQHwsL41@mail.gmail.com>
Am Freitag 16 Juli 2010 schrieb Luis R. Rodriguez:
> On Fri, Jul 16, 2010 at 2:16 AM, yogeshp <yogeshp@marvell.com> wrote:
> > Hi Luis,
> > Please see inline comments
> >
> > Luis R. Rodriguez wrote:
> >> On Thu, Jul 15, 2010 at 6:18 AM, yogeshp <yogeshp@marvell.com> wrote:
> >>> BA window size for a successful BA setup is not made available to the driver by
> >>> mac80211. The patch below gets the BA window size from addba response and
> >>> indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
> >
> >> But why do you want that? Your patch and commit log do not mention why
> >> you need this.
> > BA window size from ADDBA response defines how many outstanding MPDUs are allowed for the BA stream by recipient. Since ADDBA response is processed in mac80211 stack, mac80211 should communicate the BA window size to driver (and may be from driver it is further communicated to firmware/hardware) to control the number of outstanding MPDUs while transmitting MPDUs for the stream.
>
> What driver requires this? Your patch does all these changes but do
> not show any secondary patch of a user, so the patch is pointless
> right now.
JFI, rt2800 would also need the BA windows size in its tx path (not only once
but in every tx descriptor). So maybe it would even make sense to move it to
the ieee80211_sta structure? That way rt2800 could also benefit from that
change.
Using the approach as implemented in this patch we would have to store the
value for each STA on our own in rt2x00 although mac80211 has it already
in its own structures.
Just my 2 cents ...
Helmut
^ permalink raw reply
* Compat-wireless release for 2010-07-16 is baked
From: Compat-wireless cronjob account @ 2010-07-16 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
4ebcc6c..0442f68 wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
bc3e7ea..91f06bd history -> origin/history
+ 732f7b0...c221ef7 master -> origin/master (forced update)
1c5474a..2f7989e stable -> origin/stable
* [new tag] next-20100716 -> next-20100716
compat-wireless code metrics
494061 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5766 - backport from compat module
7213 - total backport code
1.4599 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2465 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100716
compat-wireless release: compat-wireless-2010-07-13-3-g1a05138
^ permalink raw reply
* Re: wl1271 firmware
From: Pazzo Da Legare @ 2010-07-16 21:41 UTC (permalink / raw)
To: Levi, Shahar, Logan Gunthorpe, Luciano Coelho,
linux-wireless@vger.kernel.org
In-Reply-To: <AC090B9732AB2B4DB7FF476E907FE660010685F34E@dnce02.ent.ti.com>
Dear Shahar,
Thank you for your help and the news. Could you please indicate a link
when available?
Pz
2010/7/11, Levi, Shahar <shahar_levi@ti.com>:
>> -----Original Message-----
>> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] On Behalf Of Logan Gunthorpe
>> Sent: Saturday, July 10, 2010 3:20 AM
>> To: Luciano Coelho
>> Cc: linux-wireless@vger.kernel.org
>> Subject: RE: wl1271 firmware
>>
>> Hi Everyone,
>>
>> I too am working with a WL1271 module and have just today got it
>> connected to an Atmel ARM9 development kit (AT91SAM9G45-EKES). So far it
>> appears to work but I have been gated by the firmware and NVS file issues.
>>
>> I have a firmware binary, but it seems to be a newer version
>> (6.1.3.01.5) than what you are using. Does anyone have any idea if this
>> version will work? It seems to be the only one available on TI's
>> website. Additionally, our device manufacturer has been hesitant to
>> provide any support because we are on an unsupported platform and opted
>> to use the open source driver. Are there any other ways to obtain an
>> older version of the firmware?
>>
>> The NVS file is another problem. TI's website has instructions to use a
>> cryptic tool that appears to come with their driver package. There is no
>> source for this tool and for obvious reasons would not work for us.
>>
>> Anyway, I'd like to help in anyway I can. I've taken a look at the
>> twilan.ini file and I see the commonality with wl1271_ini.h. It would be
>> relatively easy to write a tool that parses the INI file and generates
>> the common part of the NVS file. However, I'd have no idea how to
>> generate the device specific calibration or the few fields missing from
>> the INI file.
>>
>> Thanks,
>>
>> Logan
>>
>
> Hi Logan,
> I am pushing to get access to the correct FW and NVS files version in TI
> web. I believe the community wills nave access of those files this week.
> Regarding the tool to generate the NVS file in the correct format, I will
> check that and reply.
> Regards,
> Shahar
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Inviato dal mio dispositivo mobile
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-16 23:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: Florian Klink, linux-wireless@vger.kernel.org
On Wed, 14 Jul 2010 10:44:21 -0700, "Guy, Wey-Yi"
<wey-yi.w.guy@intel.com> wrote:
> Hi Florian,
>
> On Wed, 2010-07-14 at 10:36 -0700, Johannes Berg wrote:
>> On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
>> > Johannes,
>> >
>> > On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
>> > > Hi,
>> > >
>> > > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
>> > > You can get it here: http://pastebin.com/Q6eCdPZR
>> >
>> > >
>> > >
>> > based on the log sent by Florian, I did not see bss_info_change with
>> > current BSSID from mac80211. any thought?
>> >
>> > I am expected to see something like this,
>> >
>> > [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
>> > 0xFD
>> > [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
>> > 00:25:9c:d0:9f:e1
>> > [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
>>
>> That'd only happen _after_ association, not before, and assoc fails
>> here.
>>
> Could you try different channel instead of channel 12 to see if the
> problem still there?
>
> Thanks
> Wey
>>
Hi,
very strange, now I can't reproduce the problem anymore, association
works with channel 12 and other ones, too!
I have no idea why it's now working...
Could this commit affect any link tolerance/timeouts, because I was
able to bisect the problem?
Florian
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Guy, Wey-Yi @ 2010-07-16 23:49 UTC (permalink / raw)
To: Florian Klink; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <a10a4c76a95e1b3694489f0447967b94@imap.flokli.de>
Hi Florian,
On Fri, 2010-07-16 at 16:22 -0700, Florian Klink wrote:
> On Wed, 14 Jul 2010 10:44:21 -0700, "Guy, Wey-Yi"
> <wey-yi.w.guy@intel.com> wrote:
> > Hi Florian,
> >
> > On Wed, 2010-07-14 at 10:36 -0700, Johannes Berg wrote:
> >> On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
> >> > Johannes,
> >> >
> >> > On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
> >> > > Hi,
> >> > >
> >> > > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
> >> > > You can get it here: http://pastebin.com/Q6eCdPZR
> >> >
> >> > >
> >> > >
> >> > based on the log sent by Florian, I did not see bss_info_change with
> >> > current BSSID from mac80211. any thought?
> >> >
> >> > I am expected to see something like this,
> >> >
> >> > [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
> >> > 0xFD
> >> > [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
> >> > 00:25:9c:d0:9f:e1
> >> > [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
> >>
> >> That'd only happen _after_ association, not before, and assoc fails
> >> here.
> >>
> > Could you try different channel instead of channel 12 to see if the
> > problem still there?
> >
> > Thanks
> > Wey
> >>
>
>
> Hi,
>
> very strange, now I can't reproduce the problem anymore, association
> works with channel 12 and other ones, too!
> I have no idea why it's now working...
>
> Could this commit affect any link tolerance/timeouts, because I was
> able to bisect the problem?
>
Not sure what happen, but please do let us know if you see the problem
pop up again. I do not think this patch should affect the link
tolerance.
Thanks
Wey
>
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-16 23:48 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Johannes Berg, linux-wireless, Florian Klink
In-Reply-To: <1279324150.8881.12.camel@wwguy-huron>
On Fri, 16 Jul 2010 16:49:10 -0700, "Guy, Wey-Yi"
<wey-yi.w.guy@intel.com> wrote:
> Hi Florian,
>
> On Fri, 2010-07-16 at 16:22 -0700, Florian Klink wrote:
>> On Wed, 14 Jul 2010 10:44:21 -0700, "Guy, Wey-Yi"
>> <wey-yi.w.guy@intel.com> wrote:
>> > Hi Florian,
>> >
>> > On Wed, 2010-07-14 at 10:36 -0700, Johannes Berg wrote:
>> >> On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
>> >> > Johannes,
>> >> >
>> >> > On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
>> >> > > Hi,
>> >> > >
>> >> > > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
>> >> > > You can get it here: http://pastebin.com/Q6eCdPZR
>> >> >
>> >> > >
>> >> > >
>> >> > based on the log sent by Florian, I did not see bss_info_change with
>> >> > current BSSID from mac80211. any thought?
>> >> >
>> >> > I am expected to see something like this,
>> >> >
>> >> > [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
>> >> > 0xFD
>> >> > [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
>> >> > 00:25:9c:d0:9f:e1
>> >> > [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
>> >>
>> >> That'd only happen _after_ association, not before, and assoc fails
>> >> here.
>> >>
>> > Could you try different channel instead of channel 12 to see if the
>> > problem still there?
>> >
>> > Thanks
>> > Wey
>> >>
>>
>>
>> Hi,
>>
>> very strange, now I can't reproduce the problem anymore, association
>> works with channel 12 and other ones, too!
>> I have no idea why it's now working...
>>
>> Could this commit affect any link tolerance/timeouts, because I was
>> able to bisect the problem?
>>
> Not sure what happen, but please do let us know if you see the problem
> pop up again. I do not think this patch should affect the link
> tolerance.
>
> Thanks
> Wey
>>
Hi,
okay, but thanks for your time anyway...
:-)
Florian
^ permalink raw reply
* [RFC] cfg80211: fix race between sysfs and cfg80211
From: Maxime Bizon @ 2010-07-17 3:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
device_add() is called before adding the phy to the cfg80211 device
list.
So if a userspace program uses sysfs uevents to detect new phy
devices, and queries nl80211 to get phy info, it can get ENODEV even
though the phy exists in sysfs.
An easy workaround is to hold the cfg80211 mutex until the phy is
present both in sysfs and cfg80211 device list.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
---
net/wireless/core.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6ac70c1..8952ec4 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -472,15 +472,19 @@ int wiphy_register(struct wiphy *wiphy)
/* check and set up bitrates */
ieee80211_set_bitrate_flags(wiphy);
+ mutex_lock(&cfg80211_mutex);
+
res = device_add(&rdev->wiphy.dev);
- if (res)
+ if (res) {
+ mutex_unlock(&cfg80211_mutex);
return res;
+ }
res = rfkill_register(rdev->rfkill);
- if (res)
+ if (res) {
+ mutex_unlock(&cfg80211_mutex);
goto out_rm_dev;
-
- mutex_lock(&cfg80211_mutex);
+ }
/* set up regulatory info */
wiphy_update_regulatory(wiphy, NL80211_REGDOM_SET_BY_CORE);
--
1.7.1
--
Maxime
^ permalink raw reply related
* RTL8180L is hitting WARN_ON in net/wireless/scan.c:575
From: Pauli Nieminen @ 2010-07-17 7:30 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm testing 2.6.35-rc4+, I have problem that warning is spamming dmesg
when I have my wifi on. Actual problem caused y that problem is that I
can't scan/connect to any network with 2.6.35.
When I looked the code in warning it might be related to problem that
my wifi reports all signal strength to be 175 or 178 (if I remember
correctly). I'm now using 2.6.35 so I can't check the reported values
from scan results.
lspci:
00:09.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8180L 802.11b MAC [10ec:8180] (rev 20)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC [10ec:8180]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1000 [size=256]
Region 1: Memory at d0004800 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
Kernel driver in use: rtl8180
code line:
if (WARN_ON(wiphy->signal_type == CFG80211_SIGNAL_TYPE_UNSPEC &&
(signal < 0 || signal > 100)))
dmesg:
[ 953.750722] WARNING: at net/wireless/scan.c:575
cfg80211_inform_bss_frame+0x55/0x128 [cfg80211]()
[ 953.750726] Hardware name: Aspire 1350
[ 953.750729] Modules linked in: powernow_k7 cpufreq_userspace
cpufreq_powersave cpufreq_conservative cpufreq_stats parport_pc ppdev
lp parport binfmt_misc fuse ext2 ext4 jbd2 crc16 radeon ttm
drm_kms_helper drm netconsole configfs i2c_algo_bit dm_crypt dm_mod
snd_via82xx snd_via82xx_modem gameport snd_ac97_codec ac97_bus
snd_pcm_oss snd_mixer_oss snd_pcm snd_mpu401_uart arc4 snd_seq_midi
ecb snd_rawmidi rtl8180 snd_seq_midi_event mac80211 i2c_viapro
eeprom_93cx6 i2c_core pcmcia snd_seq via_ircc snd_timer snd_seq_device
yenta_socket cfg80211 psmouse pcmcia_rsrc snd irda tpm_tis video
pcspkr processor evdev pcmcia_core serio_raw battery output button
container ac tpm soundcore tpm_bios shpchp rfkill pci_hotplug
snd_page_alloc crc_ccitt ext3 jbd mbcache usbhid sg hid sr_mod sd_mod
cdrom crc_t10dif ata_generic pata_via libata uhci_hcd ehci_hcd usbcore
scsi_mod firewire_ohci floppy thermal via_rhine firewire_core
thermal_sys mii crc_itu_t nls_base [last unloaded: scsi_wait_scan]
[ 953.750817] Pid: 0, comm: swapper Tainted: G W 2.6.35-rc4+ #46
[ 953.750820] Call Trace:
[ 953.750828] [<c102f795>] ? warn_slowpath_common+0x6a/0x7b
[ 953.750839] [<e0e4564f>] ? cfg80211_inform_bss_frame+0x55/0x128 [cfg80211]
[ 953.750846] [<c102f7b3>] ? warn_slowpath_null+0xd/0x10
[ 953.750857] [<e0e4564f>] ? cfg80211_inform_bss_frame+0x55/0x128 [cfg80211]
[ 953.750870] [<e112c487>] ? ieee80211_bss_info_update+0x4a/0x13f [mac80211]
[ 953.750883] [<e112c683>] ? ieee80211_scan_rx+0xfa/0x130 [mac80211]
[ 953.750899] [<e1137dff>] ?
ieee80211_invoke_rx_handlers+0x67/0x166e [mac80211]
[ 953.750905] [<c10079a9>] ? sched_clock+0x9/0xd
[ 953.750911] [<c10471cf>] ? sched_clock_local+0x17/0x11e
[ 953.750920] [<c10454a7>] ? hrtimer_forward+0x10f/0x123
[ 953.750934] [<e11374c2>] ? prepare_for_handlers+0x22/0x25d [mac80211]
[ 953.750948] [<e1139b3f>] ? ieee80211_rx+0x739/0x796 [mac80211]
[ 953.750960] [<e1129444>] ? ieee80211_tasklet_handler+0x48/0xca [mac80211]
[ 953.750967] [<c10339c0>] ? tasklet_action+0x60/0xa4
[ 953.750972] [<c1034425>] ? __do_softirq+0xb1/0x156
[ 953.750977] [<c10344f8>] ? do_softirq+0x2e/0x38
[ 953.750982] [<c10345f6>] ? irq_exit+0x26/0x58
[ 953.750987] [<c10044b2>] ? do_IRQ+0x7d/0x8e
[ 953.750993] [<c10034b0>] ? common_interrupt+0x30/0x38
[ 953.751001] [<e0ecc1a9>] ? acpi_idle_enter_simple+0xef/0x129 [processor]
[ 953.751007] [<c11cce49>] ? cpuidle_idle_call+0x69/0xc0
[ 953.751013] [<c1002202>] ? cpu_idle+0x95/0xaf
[ 953.751018] [<c13bc8c2>] ? start_kernel+0x33a/0x33f
[ 953.751022] ---[ end trace 931bbdec61de23bf ]---
Pauli
^ permalink raw reply
* Re: [PATCH] rt2x00: Fix lockdep warning in rt2x00lib_probe_dev()
From: Ivo Van Doorn @ 2010-07-17 10:08 UTC (permalink / raw)
To: Stephen Boyd
Cc: users, John W. Linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1279299010-4723-1-git-send-email-bebarino@gmail.com>
On Fri, Jul 16, 2010 at 6:50 PM, Stephen Boyd <bebarino@gmail.com> wrote:
> The rt2x00dev->intf_work workqueue is never initialized when a driver is
> probed for a non-existent device (in this case rt2500usb). On such a
> path we call rt2x00lib_remove_dev() to free any resources initialized
> during the probe before we use INIT_WORK to initialize the workqueue.
> This causes lockdep to get confused since the lock used in the workqueue
> hasn't been initialized yet but is now being acquired during
> cancel_work_sync() called by rt2x00lib_remove_dev().
>
> Fix this by initializing the workqueue first before we attempt to probe
> the device. This should make lockdep happy and avoid breaking any
> assumptions about how the library cleans up after a probe fails.
>
> phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
> Call Trace:
> [<ffffffff8105fe59>] register_lock_class+0x152/0x31f
> [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111
> [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4
> [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf
> [<ffffffff81492aef>] ? _raw_spin_unlock_irqrestore+0x33/0x41
> [<ffffffff810628d5>] lock_acquire+0xd1/0xf7
> [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
> [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e
> [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
> [<ffffffff8104f136>] cancel_work_sync+0xb/0xd
> [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
> [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
> [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52
> [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb]
> [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
> [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e
> [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136
> [<ffffffff812ea167>] __driver_attach+0x4a/0x66
> [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66
> [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89
> [<ffffffff812e9efd>] driver_attach+0x19/0x1b
> [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204
> [<ffffffff812ea41b>] driver_register+0x98/0x109
> [<ffffffff813465dd>] usb_register_driver+0xb2/0x173
> [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb]
> [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb]
> [<ffffffff81000203>] do_one_initcall+0x6d/0x17a
> [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0
> [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* RE: wl1271 firmware
From: Levi, Shahar @ 2010-07-17 12:20 UTC (permalink / raw)
To: Pazzo Da Legare
Cc: linux-wireless@vger.kernel.org, Logan Gunthorpe, Luciano Coelho
In-Reply-To: <AANLkTilHNKeRZX5CMplyriTo2hTPBrz_z1_Zpwoy3SZx@mail.gmail.com>
> -----Original Message-----
> From: Pazzo Da Legare [mailto:pazzodalegare@gmail.com]
> Sent: Saturday, July 17, 2010 12:41 AM
> To: Levi, Shahar; Logan Gunthorpe; Luciano Coelho; linux-
> wireless@vger.kernel.org
> Subject: Re: wl1271 firmware
>
> Dear Shahar,
> Thank you for your help and the news. Could you please indicate a link
> when available?
> Pz
>
Hi Pazzo,
I am still pushing the legal stuff to make it happened. I hope to close that in a few days.
Regards,
Shahar
^ 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