* Re: Question about iwl3945
From: Larry Finger @ 2011-01-06 22:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: wireless
In-Reply-To: <1294347881.25228.0.camel@jlt3.sipsolutions.net>
On 01/06/2011 03:04 PM, Johannes Berg wrote:
> On Thu, 2011-01-06 at 14:58 -0600, Larry Finger wrote:
>> Is there any reason why the Intel3495 wireless card using the iwl3945 driver
>> with kernel 2.6.34 does not work in AP mode using hostapd? The message is
>>
>> nl80211: Failed to set interface wlan0 into AP mode
>> nl80211 driver initialization failed.
>
> Neither 3945 nor 4965 can ever support AP mode due to firmware
> restrictions, sorry.
Thanks. Don't worry, I'm not trying to convert a $600 laptop into a $30 access
point! In fact, I already own 4 APs. A year ago, I wrote a howto for the
openSUSE forums, and someone is trying to follow my prescription. He had some
nasty things to say about the 3945 when I gave him the bad news. Unfortunately,
he will be buying another wifi card and not an AP.
Larry
^ permalink raw reply
* Re: [RFC PATCH 10/17] zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
From: Johannes Berg @ 2011-01-06 21:55 UTC (permalink / raw)
To: Christian Lamparter
Cc: Jussi Kivilinna, linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <201101062246.38932.chunkeey@googlemail.com>
On Thu, 2011-01-06 at 22:46 +0100, Christian Lamparter wrote:
> Ideally, you should assign a proper sequence # to beacon frames too.
> (802.11-2007 7.1.3.4.1)
>
> But as before, the long time between the upload and the actual beacon
> xmit by the hardware make things really difficult. If you just call
> "create_tx_desc_seq" right now, "theoretically" you have to buffer
> all management and other Non-QoS data frames until the beacon was sent.
>
> However, no one would do that :D. Either the hardware/firmware
> controls the sequence counter or it's simply not implemented
> (and nobody cares ;) ).
Yeah ... it turns out that nobody cares. It's probably easier/better to
actually send beacons with seqno 0 instead of trying to hack around it.
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index c47d7c0..f71ed31 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -225,6 +225,7 @@ struct ieee80211_if_ap {
> struct sk_buff_head ps_bc_buf;
> atomic_t num_sta_ps; /* number of stations in PS mode */
> int dtim_count;
> + bool dtim_bc_mc;
> };
>
> struct ieee80211_if_wds {
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 5950e3a..26b688b 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -2178,6 +2178,8 @@ static void ieee80211_beacon_add_tim(struct ieee80211_if_ap *bss,
> if (bss->dtim_count == 0 && !skb_queue_empty(&bss->ps_bc_buf))
> aid0 = 1;
>
> + bss->dtim_bc_mc = aid0 == 1;
> +
> if (have_bits) {
> /* Find largest even number N1 so that bits numbered 1 through
> * (N1 x 8) - 1 in the bitmap are 0 and number N2 so that bits
> @@ -2540,7 +2542,7 @@ ieee80211_get_buffered_bc(struct ieee80211_hw *hw,
> if (sdata->vif.type != NL80211_IFTYPE_AP || !beacon || !beacon->head)
> goto out;
>
> - if (bss->dtim_count != 0)
> + if (bss->dtim_count != 0 || !bss->dtim_bc_mc)
> goto out; /* send buffered bc/mc only after DTIM beacon */
Hmm, interesting. That makes some sense I guess. Luckily, I have
hardware offload for this (extra queue) so I don't have to worry about
it :-)
johannes
^ permalink raw reply
* Re: [RFC PATCH 13/17] zd1211rw: use stack for small cmd-buffers
From: Jussi Kivilinna @ 2011-01-06 21:53 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <1294340139.5021.8.camel@dcbw.foobar.com>
Quoting Dan Williams <dcbw@redhat.com>:
> On Wed, 2011-01-05 at 10:27 +0100, Johannes Berg wrote:
>> 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.
Oh, my reply to Johannes didn't go to list.
>
> It's almost certainly not valid. You'll get BUGs from the kernel in
> this case, though it'll still probably work.
Ok, will not use stack for urb transfer_buffers.
-Jussi
^ permalink raw reply
* Re: [RFC PATCH 10/17] zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
From: Christian Lamparter @ 2011-01-06 21:46 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110104234910.25309.19235.stgit@fate.lan>
On Wednesday 05 January 2011 00:49:10 Jussi Kivilinna wrote:
> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
> index aace010..a3c7e8f 100644
> --- a/drivers/net/wireless/zd1211rw/zd_mac.c
> +++ b/drivers/net/wireless/zd1211rw/zd_mac.c
> @@ -958,16 +958,46 @@ static int zd_op_config(struct ieee80211_hw *hw, u32 changed)
> return zd_chip_set_channel(&mac->chip, conf->channel->hw_value);
> }
>
> +static void zd_beacon_done(struct zd_mac *mac)
> +{
this is an interesting one...
Since zd_beacon_done also uploads the next beacon so long in advance,
there could be an equally long race between the outdated state of the
next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
which -in your case- was uploaded almost a beacon interval ago and
the xmit of ieee80211_get_buffered_bc *now*.
The dtim bc/mc bit might be not set, when a mc/bc arrived after the
beacon was uploaded, but before the "beacon done event" from the
hardware. So, dozing stations don't expect the broadcast traffic
and of course, they might miss it completely.
It's probably better to fix this in mac80211 (see the attached hack).
> + /*
> + * Send out buffered broad- and multicast frames.
> + */
> + while (!ieee80211_queue_stopped(mac->hw, 0)) {
> + skb = ieee80211_get_buffered_bc(mac->hw, mac->vif);
> + if (!skb)
> + break;
> + zd_op_tx(mac->hw, skb);
> + }
> +
> + /*
> + * Fetch next beacon so that tim_count is updated.
> + */
> + beacon = ieee80211_beacon_get(mac->hw, mac->vif);
> + if (!beacon)
> + return;
Ideally, you should assign a proper sequence # to beacon frames too.
(802.11-2007 7.1.3.4.1)
But as before, the long time between the upload and the actual beacon
xmit by the hardware make things really difficult. If you just call
"create_tx_desc_seq" right now, "theoretically" you have to buffer
all management and other Non-QoS data frames until the beacon was sent.
However, no one would do that :D. Either the hardware/firmware
controls the sequence counter or it's simply not implemented
(and nobody cares ;) ).
In fact, you could just as well drop "[09/17] zd1211rw: implement
seq_num for IEEE80211_TX_CTL_ASSIGN_SEQ"... unless of course, I'm
an idiot and there is a really clever way around these issues.
Regards,
Chr
---
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c47d7c0..f71ed31 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -225,6 +225,7 @@ struct ieee80211_if_ap {
struct sk_buff_head ps_bc_buf;
atomic_t num_sta_ps; /* number of stations in PS mode */
int dtim_count;
+ bool dtim_bc_mc;
};
struct ieee80211_if_wds {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5950e3a..26b688b 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2178,6 +2178,8 @@ static void ieee80211_beacon_add_tim(struct ieee80211_if_ap *bss,
if (bss->dtim_count == 0 && !skb_queue_empty(&bss->ps_bc_buf))
aid0 = 1;
+ bss->dtim_bc_mc = aid0 == 1;
+
if (have_bits) {
/* Find largest even number N1 so that bits numbered 1 through
* (N1 x 8) - 1 in the bitmap are 0 and number N2 so that bits
@@ -2540,7 +2542,7 @@ ieee80211_get_buffered_bc(struct ieee80211_hw *hw,
if (sdata->vif.type != NL80211_IFTYPE_AP || !beacon || !beacon->head)
goto out;
- if (bss->dtim_count != 0)
+ if (bss->dtim_count != 0 || !bss->dtim_bc_mc)
goto out; /* send buffered bc/mc only after DTIM beacon */
while (1) {
^ permalink raw reply related
* Re: [PATCH] compat-wireless linux-2.6.37.y, fix compile error for pm_qos_add_request()
From: Tim Gardner @ 2011-01-06 21:22 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof
In-Reply-To: <1294348725-31239-1-git-send-email-tim.gardner@canonical.com>
On 01/06/2011 02:18 PM, Tim Gardner wrote:
> rtg
> ----
git send-email clipped my annotation. It should have said:
"Compile tested against 2.6.32.25 and 2.6.35.8"
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* [PATCH] compat-wireless linux-2.6.37.y, fix compile error for pm_qos_add_request()
From: Tim Gardner @ 2011-01-06 21:18 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Tim Gardner
rtg
----
>From 927d0fb9413a2822c7465b4f2408b16acb24d7c5 Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Thu, 6 Jan 2011 12:07:37 -0700
Subject: [PATCH] compat-wireless: pm_qos_add_request() was changed for 2.6.35
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
patches/28-pm-qos-params.patch | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/patches/28-pm-qos-params.patch b/patches/28-pm-qos-params.patch
index efe3926..7c9dd9e 100644
--- a/patches/28-pm-qos-params.patch
+++ b/patches/28-pm-qos-params.patch
@@ -20,9 +20,9 @@ little wierd.
#define DRV_DESCRIPTION "Intel(R) PRO/Wireless 2100 Network Driver"
#define DRV_COPYRIGHT "Copyright(c) 2003-2006 Intel Corporation"
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
static struct pm_qos_request_list ipw2100_pm_qos_req;
-+#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
++#else
+static struct pm_qos_request_list *ipw2100_pm_qos_req;
+#endif
@@ -32,9 +32,9 @@ little wierd.
/* the ipw2100 hardware really doesn't want power management delays
* longer than 175usec
*/
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
pm_qos_update_request(&ipw2100_pm_qos_req, 175);
-+#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
++#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,34))
+ pm_qos_update_request(ipw2100_pm_qos_req, 175);
+#else
+ pm_qos_update_requirement(PM_QOS_CPU_DMA_LATENCY, "ipw2100", 175);
@@ -46,9 +46,9 @@ little wierd.
ipw2100_disable_interrupts(priv);
spin_unlock_irqrestore(&priv->low_lock, flags);
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
pm_qos_update_request(&ipw2100_pm_qos_req, PM_QOS_DEFAULT_VALUE);
-+#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
++#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,34))
+ pm_qos_update_request(ipw2100_pm_qos_req, PM_QOS_DEFAULT_VALUE);
+#else
+ pm_qos_update_requirement(PM_QOS_CPU_DMA_LATENCY, "ipw2100",
@@ -61,10 +61,10 @@ little wierd.
printk(KERN_INFO DRV_NAME ": %s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
printk(KERN_INFO DRV_NAME ": %s\n", DRV_COPYRIGHT);
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
pm_qos_add_request(&ipw2100_pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
PM_QOS_DEFAULT_VALUE);
-+#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
++#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,34))
+ ipw2100_pm_qos_req = pm_qos_add_request(PM_QOS_CPU_DMA_LATENCY,
+ PM_QOS_DEFAULT_VALUE);
+#else
@@ -78,9 +78,9 @@ little wierd.
&driver_attr_debug_level);
#endif
pci_unregister_driver(&ipw2100_pci_driver);
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
pm_qos_remove_request(&ipw2100_pm_qos_req);
-+#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
++#elif (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,34))
+ pm_qos_remove_request(ipw2100_pm_qos_req);
+#else
+ pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY, "ipw2100");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/4] some wireless doc updates
From: Johannes Berg @ 2011-01-06 21:36 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
Mostly stuff missed earlier, and then LED docs.
johannes
^ permalink raw reply
* [PATCH 4/4] mac80211: add doc short section on LED triggers
From: Johannes Berg @ 2011-01-06 21:36 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20110106213643.454994320@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Just create a section to collect the LED trigger
functions and add a very short description as to
what drivers should do.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Documentation/DocBook/80211.tmpl | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
--- wireless-testing.orig/Documentation/DocBook/80211.tmpl 2011-01-06 22:30:55.000000000 +0100
+++ wireless-testing/Documentation/DocBook/80211.tmpl 2011-01-06 22:33:25.000000000 +0100
@@ -285,10 +285,6 @@ MISSING
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
-!Finclude/net/mac80211.h ieee80211_get_tx_led_name
-!Finclude/net/mac80211.h ieee80211_get_rx_led_name
-!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
-!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
@@ -399,6 +395,23 @@ MISSING
</para>
</partintro>
+ <chapter id="led-support">
+ <title>LED support</title>
+ <para>
+ Mac80211 supports various ways of blinking LEDs. Wherever possible,
+ device LEDs should be exposed as LED class devices and hooked up to
+ the appropriate trigger, which will then be triggered appropriately
+ by mac80211.
+ </para>
+!Finclude/net/mac80211.h ieee80211_get_tx_led_name
+!Finclude/net/mac80211.h ieee80211_get_rx_led_name
+!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
+!Finclude/net/mac80211.h ieee80211_get_radio_led_name
+!Finclude/net/mac80211.h ieee80211_tpt_blink
+!Finclude/net/mac80211.h ieee80211_tpt_led_trigger_flags
+!Finclude/net/mac80211.h ieee80211_create_tpt_led_trigger
+ </chapter>
+
<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
^ permalink raw reply
* [PATCH 3/4] nl80211: add/fix mesh docs
From: Johannes Berg @ 2011-01-06 21:36 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20110106213643.454994320@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Some mesh attribute/command docs are missing or
have errors in the name so they don't match, fix
all of them.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/linux/nl80211.h | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
--- wireless-testing.orig/include/linux/nl80211.h 2011-01-06 22:21:07.000000000 +0100
+++ wireless-testing/include/linux/nl80211.h 2011-01-06 22:28:07.000000000 +0100
@@ -148,6 +148,10 @@
* @NL80211_CMD_SET_MPATH: Set mesh path attributes for mesh path to
* destination %NL80211_ATTR_MAC on the interface identified by
* %NL80211_ATTR_IFINDEX.
+ * @NL80211_CMD_NEW_MPATH: Create a new mesh path for the destination given by
+ * %NL80211_ATTR_MAC via %NL80211_ATTR_MPATH_NEXT_HOP.
+ * @NL80211_CMD_DEL_MPATH: Delete a mesh path to the destination given by
+ * %NL80211_ATTR_MAC.
* @NL80211_CMD_NEW_PATH: Add a mesh path with given attributes to the
* the interface identified by %NL80211_ATTR_IFINDEX.
* @NL80211_CMD_DEL_PATH: Remove a mesh path identified by %NL80211_ATTR_MAC
@@ -612,7 +616,7 @@ enum nl80211_commands {
* consisting of a nested array.
*
* @NL80211_ATTR_MESH_ID: mesh id (1-32 bytes).
- * @NL80211_ATTR_PLINK_ACTION: action to perform on the mesh peer link.
+ * @NL80211_ATTR_STA_PLINK_ACTION: action to perform on the mesh peer link.
* @NL80211_ATTR_MPATH_NEXT_HOP: MAC address of the next hop for a mesh path.
* @NL80211_ATTR_MPATH_INFO: information about a mesh_path, part of mesh path
* info given for %NL80211_CMD_GET_MPATH, nested attribute described at
@@ -879,7 +883,9 @@ enum nl80211_commands {
* See &enum nl80211_key_default_types.
*
* @NL80211_ATTR_MESH_SETUP: Optional mesh setup parameters. These cannot be
- * changed once the mesh is active.
+ * changed once the mesh is active.
+ * @NL80211_ATTR_MESH_CONFIG: Mesh configuration parameters, a nested attribute
+ * containing attributes from &enum nl80211_meshconf_params.
*
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -1225,8 +1231,6 @@ enum nl80211_rate_info {
* @NL80211_STA_INFO_INACTIVE_TIME: time since last activity (u32, msecs)
* @NL80211_STA_INFO_RX_BYTES: total received bytes (u32, from this station)
* @NL80211_STA_INFO_TX_BYTES: total transmitted bytes (u32, to this station)
- * @__NL80211_STA_INFO_AFTER_LAST: internal
- * @NL80211_STA_INFO_MAX: highest possible station info attribute
* @NL80211_STA_INFO_SIGNAL: signal strength of last received PPDU (u8, dBm)
* @NL80211_STA_INFO_TX_BITRATE: current unicast tx rate, nested attribute
* containing info as possible, see &enum nl80211_sta_info_txrate.
@@ -1236,6 +1240,11 @@ enum nl80211_rate_info {
* @NL80211_STA_INFO_TX_RETRIES: total retries (u32, to this station)
* @NL80211_STA_INFO_TX_FAILED: total failed packets (u32, to this station)
* @NL80211_STA_INFO_SIGNAL_AVG: signal strength average (u8, dBm)
+ * @NL80211_STA_INFO_LLID: the station's mesh LLID
+ * @NL80211_STA_INFO_PLID: the station's mesh PLID
+ * @NL80211_STA_INFO_PLINK_STATE: peer link state for the station
+ * @__NL80211_STA_INFO_AFTER_LAST: internal
+ * @NL80211_STA_INFO_MAX: highest possible station info attribute
*/
enum nl80211_sta_info {
__NL80211_STA_INFO_INVALID,
@@ -1626,7 +1635,7 @@ enum nl80211_mntr_flags {
* @NL80211_MESHCONF_HWMP_NET_DIAM_TRVS_TIME: The interval of time (in TUs)
* that it takes for an HWMP information element to propagate across the mesh
*
- * @NL80211_MESHCONF_ROOTMODE: whether root mode is enabled or not
+ * @NL80211_MESHCONF_HWMP_ROOTMODE: whether root mode is enabled or not
*
* @NL80211_MESHCONF_ELEMENT_TTL: specifies the value of TTL field set at a
* source mesh point for path selection elements.
@@ -1678,6 +1687,7 @@ enum nl80211_meshconf_params {
* element that vendors will use to identify the path selection methods and
* metrics in use.
*
+ * @NL80211_MESH_SETUP_ATTR_MAX: highest possible mesh setup attribute number
* @__NL80211_MESH_SETUP_ATTR_AFTER_LAST: Internal use
*/
enum nl80211_mesh_setup_params {
^ permalink raw reply
* [PATCH 2/4] cfg80211: add mesh join/leave callback docs
From: Johannes Berg @ 2011-01-06 21:36 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20110106213643.454994320@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
When I made the patch to add mesh join/leave I
didn't pay attention to docs because it was a
proof of concept, and then when we actually did
merge it I forgot -- add docs now.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 2 ++
1 file changed, 2 insertions(+)
--- wireless-testing.orig/include/net/cfg80211.h 2011-01-06 22:20:06.000000000 +0100
+++ wireless-testing/include/net/cfg80211.h 2011-01-06 22:20:41.000000000 +0100
@@ -1103,6 +1103,8 @@ struct cfg80211_pmksa {
* @change_mpath: change a given mesh path
* @get_mpath: get a mesh path for the given parameters
* @dump_mpath: dump mesh path callback -- resume dump at index @idx
+ * @join_mesh: join the mesh network with the specified parameters
+ * @leave_mesh: leave the current mesh network
*
* @get_mesh_config: Get the current mesh configuration
*
^ permalink raw reply
* [PATCH 1/4] mac80211: add missing docs for off-chan TX flag
From: Johannes Berg @ 2011-01-06 21:36 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20110106213643.454994320@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
The flag is IEEE80211_TX_CTL_TX_OFFCHAN and I had
added that in a previous patch but forgotten docs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 4 ++++
1 file changed, 4 insertions(+)
--- wireless-testing.orig/include/net/mac80211.h 2011-01-06 22:18:55.000000000 +0100
+++ wireless-testing/include/net/mac80211.h 2011-01-06 22:19:53.000000000 +0100
@@ -337,6 +337,10 @@ struct ieee80211_bss_conf {
* @IEEE80211_TX_CTL_LDPC: tells the driver to use LDPC for this frame
* @IEEE80211_TX_CTL_STBC: Enables Space-Time Block Coding (STBC) for this
* frame and selects the maximum number of streams that it can use.
+ * @IEEE80211_TX_CTL_TX_OFFCHAN: Marks this packet to be transmitted on
+ * the off-channel channel when a remain-on-channel offload is done
+ * in hardware -- normal packets still flow and are expected to be
+ * handled properly by the device.
*
* Note: If you have to add new flags to the enumeration, then don't
* forget to update %IEEE80211_TX_TEMPORARY_FLAGS when necessary.
^ permalink raw reply
* Re: [RFC v2] cfg80211: Add HT BSS attributes
From: Luis R. Rodriguez @ 2011-01-06 21:13 UTC (permalink / raw)
To: Sujith; +Cc: Johannes Berg, Jouni.Malinen, linux-wireless
In-Reply-To: <19749.32067.311517.479374@gargle.gargle.HOWL>
On Thu, Jan 6, 2011 at 12:28 AM, Sujith <m.sujith@gmail.com> 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.
>
> Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> ---
> v2: Initialize values and set the parameters in managed mode also.
Can you split this up into two patches, one for cfg80211 and another
for mac80211?
> 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;
> + }
> +
Also, if the values do not change why insist on the BSS_CHANGED_HT ?
Luis
^ permalink raw reply
* Re: Question about iwl3945
From: Johannes Berg @ 2011-01-06 21:04 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4D262CED.5070409@lwfinger.net>
On Thu, 2011-01-06 at 14:58 -0600, Larry Finger wrote:
> Is there any reason why the Intel3495 wireless card using the iwl3945 driver
> with kernel 2.6.34 does not work in AP mode using hostapd? The message is
>
> nl80211: Failed to set interface wlan0 into AP mode
> nl80211 driver initialization failed.
Neither 3945 nor 4965 can ever support AP mode due to firmware
restrictions, sorry.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] compat-wireless: use backported kfifo
From: Luis R. Rodriguez @ 2011-01-06 21:01 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1294334212-20530-2-git-send-email-hauke@hauke-m.de>
On Thu, Jan 6, 2011 at 9:16 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> Now compat contains a backport of the kfifo implementation and we do
> not have to patch the driver to use the old interface.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Sweet! Applied and pushed, thanks!
Luis
^ permalink raw reply
* Re: [PATCH 14/32] wireless/ipw2x00: use system_wq instead of dedicated workqueues
From: John W. Linville @ 2011-01-06 20:51 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel, linux-wireless
In-Reply-To: <1294062595-30097-15-git-send-email-tj@kernel.org>
On Mon, Jan 03, 2011 at 02:49:37PM +0100, Tejun Heo wrote:
> With cmwq, there's no reason to use separate workqueues in ipw2x00
> drivers. Drop them and use system_wq instead. All used work items
> are sync canceled on driver detach.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: "John W. Linville" <linville@tuxdriver.com>
> Cc: linux-wireless@vger.kernel.org
> ---
> Only compile tested. Please feel free to take it into the subsystem
> tree or simply ack - I'll route it through the wq tree.
ACK
--
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
* Question about iwl3945
From: Larry Finger @ 2011-01-06 20:58 UTC (permalink / raw)
To: wireless
Is there any reason why the Intel3495 wireless card using the iwl3945 driver
with kernel 2.6.34 does not work in AP mode using hostapd? The message is
nl80211: Failed to set interface wlan0 into AP mode
nl80211 driver initialization failed.
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] compat: backport kfifo
From: Luis R. Rodriguez @ 2011-01-06 20:45 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1294334198-20501-1-git-send-email-hauke@hauke-m.de>
On Thu, Jan 6, 2011 at 9:16 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> This is a copy of the hole kfifo implementation from a recent kernel
> version. When we ship this implementation we do not have to backport
> any kfifo related stuff any more.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Awesome stuff !! Just forgot the:
ifeq ($(CONFIG_COMPAT_KERNEL_36),y)
export CONFIG_COMPAT_KFIFO=m
endif #CONFIG_COMPAT_KERNEL_36
on the Makefile but I'll add it. Thanks!
Luis
^ permalink raw reply
* Odd behavior of ssb, b43, b43legacy, and b44
From: Larry Finger @ 2011-01-06 20:07 UTC (permalink / raw)
To: Michael Buesch; +Cc: b43-dev, wireless
Michael,
On one of my boxes, I have installed two PCI-format BCM43xx cards for testing.
One is a BCM4306 Rev. 3, which uses b43. The other is a BCM4303, which uses
b43legacy. The output of lspci -nn for these devices is
01:09.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g
Wireless LAN Controller [14e4:4320] (rev 03)
01:0a.0 Network controller [0280]: Broadcom Corporation BCM4303 802.11b Wireless
LAN Controller [14e4:4301] (rev 02)
Upon booting, I noticed the following messages in the log:
b44: b44.c:v2.0
b44: Invalid MAC address found in EEPROM
b44 ssb1:1: Problem fetching invariants of chip, aborting
b44: probe of ssb1:1 failed with error -22
As this box does not have a b44 installed, I wondered why this was happening.
When I unloaded all the drivers and used modprobe to load ssb, I found that b43,
b43legacy and b44 were all loaded. The console output is
finger@pam:~> lsmod | grep b4 <== none loaded
finger@pam:~> sudo modprobe -v ssb <== load ssb
insmod /lib/modules/2.6.37-wl+/kernel/drivers/ssb/ssb.ko
The above looks normal, but look at what is now resident!
finger@pam:~> lsmod | grep b4
b43legacy 115302 0
b44 28767 0
b43 174321 0
ssb 38157 3 b43legacy,b44,b43
mac80211 266240 2 b43legacy,b43
cfg80211 161930 3 b43legacy,b43,mac80211
Any idea why loading ssb should silently load b43legacy AND b44? Any ideas on
where to look?
Thanks,
Larry
^ permalink raw reply
* Re: ath9k ath_tx_complete_poll_work doesn't always run.
From: Ben Greear @ 2011-01-06 20:06 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <4D261E22.1090300@candelatech.com>
On 01/06/2011 11:55 AM, Ben Greear wrote:
> It seems that the ath_tx_complete_poll_work method is supposed to
> run every 1 second to check for stale xmit buffers.
>
> However, I noticed that sometimes it is stopped, perhaps
> because the mac80211 workqueue is flushed and ath9k
> doesn't know to re-setup the work.
>
> I am curious if anyone knows how this is *supposed* to
> function?
Hrm, this may be my fault..a bug in my attempt to
not do so much channel-change code when the channel
has not in fact changed...
I'll look some more..
Ben
>
> Thanks,
> Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Compat-wireless release for 2011-01-06 is baked
From: Compat-wireless cronjob account @ 2011-01-06 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
fc63933..07667d5 linux-2.6.37.y -> origin/linux-2.6.37.y
53f8e22..c46a7ef master -> origin/master
* [new tag] compat-wireless-2011-01-05 -> compat-wireless-2011-01-05
* [new tag] compat-wireless-v2.6.37-1 -> compat-wireless-v2.6.37-1
* [new tag] compat-wireless-v2.6.37-rc6-2 -> compat-wireless-v2.6.37-rc6-2
* [new tag] compat-wireless-v2.6.37-rc6-3 -> compat-wireless-v2.6.37-rc6-3
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat
d70640f..dcd6955 master -> origin/master
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
b616059..91493a5 history -> origin/history
+ dcd2e87...47ec851 master -> origin/master (forced update)
989d873..3c0eee3 stable -> origin/stable
* [new tag] next-20110106 -> next-20110106
* [new tag] v2.6.37 -> v2.6.37
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
/usr/bin/sha1sum: *.tar.bz2: No such file or directory
compat-wireless code metrics
781248 - Total upstream lines of code being pulled
^ permalink raw reply
* ath9k ath_tx_complete_poll_work doesn't always run.
From: Ben Greear @ 2011-01-06 19:55 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
It seems that the ath_tx_complete_poll_work method is supposed to
run every 1 second to check for stale xmit buffers.
However, I noticed that sometimes it is stopped, perhaps
because the mac80211 workqueue is flushed and ath9k
doesn't know to re-setup the work.
I am curious if anyone knows how this is *supposed* to
function?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-01-05
From: David Miller @ 2011-01-06 19:34 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110105215133.GA2369@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 5 Jan 2011 16:51:34 -0500
> Dave,
>
> Here is another big batch of updates intended for 2.6.38. It should
> be the last big one, but I still have a few patches in the queue that meet
> the posting date requirements and that might merit inclusion -- we'll
> see...
>
> Again, this is the usual batch of driver updates from all the major
> players. Also, mac80211 gets a little action. The bluetooth team makes
> a showing as well.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [RFC PATCH 13/17] zd1211rw: use stack for small cmd-buffers
From: Dan Williams @ 2011-01-06 18:55 UTC (permalink / raw)
To: Johannes Berg
Cc: Jussi Kivilinna, linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <1294219627.3590.0.camel@jlt3.sipsolutions.net>
On Wed, 2011-01-05 at 10:27 +0100, Johannes Berg wrote:
> 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.
It's almost certainly not valid. You'll get BUGs from the kernel in
this case, though it'll still probably work.
Dan
^ permalink raw reply
* Re: RTL8187L: Can only "enable" hw radio switch after Windows boot
From: Klaas De Craemer @ 2011-01-06 18:07 UTC (permalink / raw)
To: Larry Finger; +Cc: htl10, linux-wireless, Herton Ronaldo Krzesinski
In-Reply-To: <4CEC5D6B.4060401@lwfinger.net>
Would there be any progress on this? I'm still having the same issue
on humid days.
Klaas
On Wed, Nov 24, 2010 at 01:33, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 11/23/2010 03:06 PM, Klaas De Craemer wrote:
>>
>> Don't worry, I live in Belgium and temperatures in winter rarely get
>> below -10 °C. I might just jam an USB cup heater in the enclosure...
>>
>> If you think there is anything I can help you with, please let me
>> know. For now I'll try some more test variations to see if I can find
>> more clues.
>
> I got drivers for XP and Linux from the Alfa site. I selected the high-power
> version, which should match your device.
>
> I don't know what version is in the Windows version, but the Linux version has
> rtl8187_linux_26.1025.0328.2007, which is pretty old. I have
> rtl8187L_linux_26.1038.0626.2009, rtl8187L_linux_26.1039.0104.2010, and
> rtl8187L_linux_26.1040.0820.2010 on my disk. At this point, I'm not sure which
> version was used to generate the in-kernel Linux driver. Perhaps Herton
> remembers, but it had to be something about the 2007 time frame.
>
> I had to build a new Windows XP system in a virtual machine. The one I already
> had won't run on the machine I have now and the original is in the shop. Access
> to the new host is restricted to mornings.
>
> Larry
>
^ permalink raw reply
* [PATCH 2/2] compat-wireless: use backported kfifo
From: Hauke Mehrtens @ 2011-01-06 17:16 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
In-Reply-To: <1294334212-20530-1-git-send-email-hauke@hauke-m.de>
Now compat contains a backport of the kfifo implementation and we do
not have to patch the driver to use the old interface.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
config.mk | 4 +++
patches/19-kfifo.patch | 53 ------------------------------------------------
2 files changed, 4 insertions(+), 53 deletions(-)
delete mode 100644 patches/19-kfifo.patch
diff --git a/config.mk b/config.mk
index 1f95908..7a29d46 100644
--- a/config.mk
+++ b/config.mk
@@ -107,6 +107,10 @@ ifdef CONFIG_FW_LOADER
endif #CONFIG_FW_LOADER
endif #CONFIG_COMPAT_KERNEL_33
+ifdef CONFIG_COMPAT_KERNEL_36
+CONFIG_COMPAT_KFIFO=m
+endif #CONFIG_COMPAT_KERNEL_36
+
# Wireless subsystem stuff
CONFIG_MAC80211=m
diff --git a/patches/19-kfifo.patch b/patches/19-kfifo.patch
deleted file mode 100644
index d9d25ee..0000000
--- a/patches/19-kfifo.patch
+++ /dev/null
@@ -1,53 +0,0 @@
-These parts of the new generic kernel FIFO implementation (kfifo) can
-not be backported easily with defines in the compat module.
-
---- a/drivers/net/wireless/libertas/dev.h
-+++ b/drivers/net/wireless/libertas/dev.h
-@@ -121,7 +121,11 @@ struct lbs_private {
- u32 resp_len[2];
-
- /* Events sent from hardware to driver */
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33))
- struct kfifo event_fifo;
-+#else
-+ struct kfifo *event_fifo;
-+#endif
-
- /** thread to service interrupts */
- struct task_struct *main_thread;
---- a/drivers/net/wireless/libertas/main.c
-+++ b/drivers/net/wireless/libertas/main.c
-@@ -753,8 +753,14 @@ static int lbs_init_adapter(struct lbs_p
- priv->resp_len[0] = priv->resp_len[1] = 0;
-
- /* Create the event FIFO */
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33))
- ret = kfifo_alloc(&priv->event_fifo, sizeof(u32) * 16, GFP_KERNEL);
- if (ret) {
-+#else
-+ priv->event_fifo = kfifo_alloc(sizeof(u32) * 16, GFP_KERNEL, NULL);
-+ if (IS_ERR(priv->event_fifo)) {
-+ ret = -ENOMEM;
-+#endif
- lbs_pr_err("Out of memory allocating event FIFO buffer\n");
- goto out;
- }
---- a/drivers/net/wireless/rt2x00/rt2x00dev.c
-+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
-@@ -808,10 +808,16 @@ static int rt2x00lib_probe_hw(struct rt2
- * queues gets reported before we've got a chance to handle
- * them) 24*4=384 tx status reports need to be cached.
- */
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,33))
- status = kfifo_alloc(&rt2x00dev->txstatus_fifo, 512,
- GFP_KERNEL);
- if (status)
- return status;
-+#else
-+ rt2x00dev->txstatus_fifo = kfifo_alloc(512, GFP_KERNEL, NULL);
-+ if (IS_ERR(rt2x00dev->txstatus_fifo))
-+ return PTR_ERR(rt2x00dev->txstatus_fifo);
-+#endif
-
- /* tasklet for processing the tx status reports. */
- if (rt2x00dev->ops->lib->txstatus_tasklet)
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox