* [PATCH 6/9] [compat-2.6] Fix build with kernel < 2.6.27
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1255382358-20760-1-git-send-email-hauke@hauke-m.de>
iw_handler.h have changed in kernel 2.6.27.
For older kernel we need some extra backport code.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/compat-2.6.27.h | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/compat/compat-2.6.27.h b/compat/compat-2.6.27.h
index 2543482..8cc6c22 100644
--- a/compat/compat-2.6.27.h
+++ b/compat/compat-2.6.27.h
@@ -163,6 +163,26 @@ static inline void list_splice_tail_init(struct list_head *list,
extern unsigned int mmc_align_data_size(struct mmc_card *, unsigned int);
extern unsigned int sdio_align_size(struct sdio_func *func, unsigned int sz);
+/** Include iw_handler.h before we redefine some methods **/
+#include <net/iw_handler.h>
+
+#define iwe_stream_add_value(info, event, value, ends, iwe, event_len) iwe_stream_add_value(event, value, ends, iwe, event_len)
+#define iwe_stream_add_point(info, stream, ends, iwe, extra) iwe_stream_add_point(stream, ends, iwe, extra)
+#define iwe_stream_add_event(info, stream, ends, iwe, event_len) iwe_stream_add_event(stream, ends, iwe, event_len)
+
+/* Flags available in struct iw_request_info */
+#define IW_REQUEST_FLAG_COMPAT 0x0001 /* Compat ioctl call */
+
+static inline int iwe_stream_lcp_len(struct iw_request_info *info)
+{
+#ifdef CONFIG_COMPAT
+ if (info->flags & IW_REQUEST_FLAG_COMPAT)
+ return IW_EV_COMPAT_LCP_LEN;
+#endif
+ return IW_EV_LCP_LEN;
+}
+/** source: include/net/iw_handler.h **/
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27)) */
#endif /* LINUX_26_27_COMPAT_H */
--
1.6.2.1
^ permalink raw reply related
* [PATCH 5/9] [compat-2.6] Remove temporary fix
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1255382358-20760-1-git-send-email-hauke@hauke-m.de>
Remove temporary fix from 6dae19ce42f4f6424a37c25f9ec393c1b4bc5c32
it is now in John's tree
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/patches/01-netdev.patch | 35 -----------------------------------
1 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/compat/patches/01-netdev.patch b/compat/patches/01-netdev.patch
index a619a01..6ec1827 100644
--- a/compat/patches/01-netdev.patch
+++ b/compat/patches/01-netdev.patch
@@ -534,38 +534,3 @@ without creating a headache on maintenance of the pathes.
dev->destructor = free_netdev;
ether_setup(dev);
dev->tx_queue_len = 0;
-
-
-Remove this after John picks this up:
-
-From 8fe3f6159c61a7c88a2bd160e8281d62e3978bed Mon Sep 17 00:00:00 2001
-From: Luis R. Rodriguez <lrodriguez@atheros.com>
-Date: Thu, 8 Oct 2009 16:43:57 -0400
-Subject: [PATCH] libertas: remove double assignment of dev->netdev_ops
-
-This came in through the patch titled:
- libertas: first stab at cfg80211 support
-
-I only noticed it because it breaks compat-wireless :)
-
-Cc: Holger Schurig <hs4233@mail.mn-solutions.de>
-Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
----
- drivers/net/wireless/libertas/main.c | 1 -
- 1 files changed, 0 insertions(+), 1 deletions(-)
-
-diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
-index e6da1df..87bfd17 100644
---- a/drivers/net/wireless/libertas/main.c
-+++ b/drivers/net/wireless/libertas/main.c
-@@ -1276,7 +1276,6 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev)
- goto err_adapter;
- }
-
-- dev->netdev_ops = &lbs_netdev_ops;
- dev->ieee80211_ptr = wdev;
- dev->ml_priv = priv;
- SET_NETDEV_DEV(dev, dmdev);
---
-1.6.0.4
-
--
1.6.2.1
^ permalink raw reply related
* [PATCH 4/9] [compat-2.6] Fix compile bug with kernel 2.6.32
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1255382358-20760-1-git-send-email-hauke@hauke-m.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/patches/12-iw_handler-changes.patch | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/compat/patches/12-iw_handler-changes.patch b/compat/patches/12-iw_handler-changes.patch
index 50c9b1a..7a700b1 100644
--- a/compat/patches/12-iw_handler-changes.patch
+++ b/compat/patches/12-iw_handler-changes.patch
@@ -1,11 +1,14 @@
--- a/drivers/net/wireless/ipw2x00/ipw2100.c 2009-10-08 11:01:52.000000000 -0400
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c 2009-10-08 11:01:43.000000000 -0400
-@@ -6057,7 +6057,7 @@
+@@ -6057,7 +6057,11 @@
dev->ethtool_ops = &ipw2100_ethtool_ops;
dev->wireless_handlers = &ipw2100_wx_handler_def;
-- priv->wireless_data.libipw = priv->ieee;
++#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,31))
+ priv->wireless_data.libipw = priv->ieee;
++#else
+ priv->wireless_data.ieee80211 = (struct ieee80211_device *) priv->ieee;
++#endif
dev->wireless_data = &priv->wireless_data;
dev->watchdog_timeo = 3 * HZ;
dev->irq = 0;
--
1.6.2.1
^ permalink raw reply related
* [PATCH 3/9] [compat-2.6] Move trace headers
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1255382358-20760-1-git-send-email-hauke@hauke-m.de>
Move tracepoint headers into own patch file.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
| 19 -----------------
compat/patches/13-trace.patch | 35 +++++++++++++++++++++++++++++--
2 files changed, 32 insertions(+), 22 deletions(-)
--git a/compat/patches/06-header-changes.patch b/compat/patches/06-header-changes.patch
index b2e8fd8..ee0be7f 100644
--- a/compat/patches/06-header-changes.patch
+++ b/compat/patches/06-header-changes.patch
@@ -40,25 +40,6 @@ cases.
#include <linux/spi/spi.h>
#include <linux/spi/wl12xx.h>
---- a/net/mac80211/driver-trace.h 2009-08-18 16:19:34.574352433 -0700
-+++ b/net/mac80211/driver-trace.h 2009-08-18 16:19:35.694367614 -0700
-@@ -1,7 +1,9 @@
- #if !defined(__MAC80211_DRIVER_TRACE) || defined(TRACE_HEADER_MULTI_READ)
- #define __MAC80211_DRIVER_TRACE
-
-+#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,27))
- #include <linux/tracepoint.h>
-+#endif /* (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,27)) */
- #include <net/mac80211.h>
- #include "ieee80211_i.h"
-
-@@ -669,4 +671,6 @@ TRACE_EVENT(drv_ampdu_action,
- #define TRACE_INCLUDE_PATH .
- #undef TRACE_INCLUDE_FILE
- #define TRACE_INCLUDE_FILE driver-trace
-+#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30))
- #include <trace/define_trace.h>
-+#endif /* (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30)) */
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -21,6 +21,9 @@
diff --git a/compat/patches/13-trace.patch b/compat/patches/13-trace.patch
index c43e723..144cae5 100644
--- a/compat/patches/13-trace.patch
+++ b/compat/patches/13-trace.patch
@@ -4,12 +4,41 @@ in or compat headers.
[1] http://lxr.linux.no/#linux+v2.6.31/include/trace/define_trace.h
---- a/drivers/net/wireless/iwlwifi/iwl-devtrace.h 2009-10-08 16:21:09.000000000 -0400
-+++ b/drivers/net/wireless/iwlwifi/iwl-devtrace.h 2009-10-08 16:23:34.000000000 -0400
+--- a/drivers/net/wireless/iwlwifi/iwl-devtrace.h
++++ b/drivers/net/wireless/iwlwifi/iwl-devtrace.h
+@@ -1,7 +1,9 @@
+ #if !defined(__IWLWIFI_DEVICE_TRACE) || defined(TRACE_HEADER_MULTI_READ)
+ #define __IWLWIFI_DEVICE_TRACE
+
++#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,27))
+ #include <linux/tracepoint.h>
++#endif /* (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,27)) */
+ #include "iwl-dev.h"
+
+ #if !defined(CONFIG_IWLWIFI_DEVICE_TRACING) || defined(__CHECKER__)
@@ -175,4 +175,6 @@
#define TRACE_INCLUDE_PATH .
#undef TRACE_INCLUDE_FILE
#define TRACE_INCLUDE_FILE iwl-devtrace
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31))
++#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30))
#include <trace/define_trace.h>
+#endif
+--- a/net/mac80211/driver-trace.h 2009-08-18 16:19:34.574352433 -0700
++++ b/net/mac80211/driver-trace.h 2009-08-18 16:19:35.694367614 -0700
+@@ -1,7 +1,9 @@
+ #if !defined(__MAC80211_DRIVER_TRACE) || defined(TRACE_HEADER_MULTI_READ)
+ #define __MAC80211_DRIVER_TRACE
+
++#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,27))
+ #include <linux/tracepoint.h>
++#endif /* (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,27)) */
+ #include <net/mac80211.h>
+ #include "ieee80211_i.h"
+
+@@ -669,4 +671,6 @@ TRACE_EVENT(drv_ampdu_action,
+ #define TRACE_INCLUDE_PATH .
+ #undef TRACE_INCLUDE_FILE
+ #define TRACE_INCLUDE_FILE driver-trace
++#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30))
+ #include <trace/define_trace.h>
++#endif /* (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30)) */
--
1.6.2.1
^ permalink raw reply related
* [compat-stable] fix build with recent mainline kernel
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1255382358-20760-1-git-send-email-hauke@hauke-m.de>
DIV_ROUND_CLOSEST is needed by the b44 driver
refresh patch for rfkill
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/compat-2.6.29.h | 7 +++++++
compat/patches/03-rfkill.patch | 22 +++++++++++-----------
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/compat/compat-2.6.29.h b/compat/compat-2.6.29.h
index 8ea43cb..fc7d983 100644
--- a/compat/compat-2.6.29.h
+++ b/compat/compat-2.6.29.h
@@ -43,6 +43,13 @@ static inline struct sk_buff *skb_queue_prev(const struct sk_buff_head *list,
extern void usb_unpoison_anchored_urbs(struct usb_anchor *anchor);
+#define DIV_ROUND_CLOSEST(x, divisor)( \
+{ \
+ typeof(divisor) __divisor = divisor; \
+ (((x) + ((__divisor) / 2)) / (__divisor)); \
+} \
+)
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,29)) */
#endif /* LINUX_26_29_COMPAT_H */
diff --git a/compat/patches/03-rfkill.patch b/compat/patches/03-rfkill.patch
index dadcb9a..d7a7e7f 100644
--- a/compat/patches/03-rfkill.patch
+++ b/compat/patches/03-rfkill.patch
@@ -71,10 +71,10 @@ This would do the policing from within mac80211.
#include <linux/mutex.h>
-#include <linux/rfkill.h>
+#include <linux/rfkill_backport.h>
+ #include <linux/sched.h>
#include <linux/spinlock.h>
#include <linux/miscdevice.h>
- #include <linux/wait.h>
-@@ -61,7 +61,7 @@
+@@ -62,7 +62,7 @@
const struct rfkill_ops *ops;
void *data;
@@ -83,7 +83,7 @@ This would do the policing from within mac80211.
struct led_trigger led_trigger;
const char *ledtrigname;
#endif
-@@ -122,7 +122,7 @@
+@@ -123,7 +123,7 @@
static bool rfkill_epo_lock_active;
@@ -92,7 +92,7 @@ This would do the policing from within mac80211.
static void rfkill_led_trigger_event(struct rfkill *rfkill)
{
struct led_trigger *trigger;
-@@ -316,7 +316,7 @@
+@@ -317,7 +317,7 @@
rfkill_event(rfkill);
}
@@ -101,7 +101,7 @@ This would do the policing from within mac80211.
static atomic_t rfkill_input_disabled = ATOMIC_INIT(0);
/**
-@@ -776,7 +776,7 @@
+@@ -777,7 +777,7 @@
}
static struct class rfkill_class = {
@@ -110,7 +110,7 @@ This would do the policing from within mac80211.
.dev_release = rfkill_release,
.dev_attrs = rfkill_dev_attrs,
.dev_uevent = rfkill_dev_uevent,
-@@ -922,7 +922,7 @@
+@@ -923,7 +923,7 @@
if (!rfkill->persistent || rfkill_epo_lock_active) {
schedule_work(&rfkill->sync_work);
} else {
@@ -119,7 +119,7 @@ This would do the policing from within mac80211.
bool soft_blocked = !!(rfkill->state & RFKILL_BLOCK_SW);
if (!atomic_read(&rfkill_input_disabled))
-@@ -1150,7 +1150,7 @@
+@@ -1151,7 +1151,7 @@
list_for_each_entry_safe(ev, tmp, &data->events, list)
kfree(ev);
@@ -128,7 +128,7 @@ This would do the policing from within mac80211.
if (data->input_handler)
if (atomic_dec_return(&rfkill_input_disabled) == 0)
printk(KERN_DEBUG "rfkill: input handler enabled\n");
-@@ -1161,7 +1161,7 @@
+@@ -1162,7 +1162,7 @@
return 0;
}
@@ -137,7 +137,7 @@ This would do the policing from within mac80211.
static long rfkill_fop_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
-@@ -1193,7 +1193,7 @@
+@@ -1194,7 +1194,7 @@
.write = rfkill_fop_write,
.poll = rfkill_fop_poll,
.release = rfkill_fop_release,
@@ -146,7 +146,7 @@ This would do the policing from within mac80211.
.unlocked_ioctl = rfkill_fop_ioctl,
.compat_ioctl = rfkill_fop_ioctl,
#endif
-@@ -1223,7 +1223,7 @@
+@@ -1224,7 +1224,7 @@
goto out;
}
@@ -155,7 +155,7 @@ This would do the policing from within mac80211.
error = rfkill_handler_init();
if (error) {
misc_deregister(&rfkill_miscdev);
-@@ -1239,7 +1239,7 @@
+@@ -1240,7 +1240,7 @@
static void __exit rfkill_exit(void)
{
--
1.6.2.1
^ permalink raw reply related
* [PATCH 2/9] [compat-2.6 and compat-stable] Remove unused code
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1255382358-20760-1-git-send-email-hauke@hauke-m.de>
LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28) can not be true in
compat-2.6.28.h. The definitions are not needed in compat-wireless any
more. Removing this does not break compiling with mainline kernel 2.6.25
to 2.6.32
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/compat-2.6.28.h | 24 ------------------------
1 files changed, 0 insertions(+), 24 deletions(-)
diff --git a/compat/compat-2.6.28.h b/compat/compat-2.6.28.h
index 90d080c..dd223c6 100644
--- a/compat/compat-2.6.28.h
+++ b/compat/compat-2.6.28.h
@@ -146,22 +146,6 @@ static inline void skb_queue_splice_tail_init(struct sk_buff_head *list,
}
} /* From include/linux/skbuff.h */
-struct module;
-struct tracepoint;
-
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
-struct tracepoint {
- const char *name; /* Tracepoint name */
- int state; /* State. */
- void **funcs;
-} __attribute__((aligned(32))); /*
- * Aligned on 32 bytes because it is
- * globally visible and gcc happily
- * align these on the structure size.
- * Keep in sync with vmlinux.lds.h.
- */
-#endif
-
#ifndef DECLARE_TRACE
#define TP_PROTO(args...) args
@@ -181,17 +165,9 @@ struct tracepoint {
return -ENOSYS; \
}
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
-#define DEFINE_TRACE(name)
-#endif
#define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
#define EXPORT_TRACEPOINT_SYMBOL(name)
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
-static inline void tracepoint_update_probe_range(struct tracepoint *begin,
- struct tracepoint *end)
-{ }
-#endif
#endif
--
1.6.2.1
^ permalink raw reply related
* [PATCH 0/10] [compat-2.6 and compat-stable] Mostly build fixes
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens
This patch series is for compat-2.6 and compat-stable-2.6.32. I have
compiled compat-wireless against mainline kernel 2.6.25 to 2.6.32. This
was all done with Ubuntu 9.04. compat-wireless should still compile with
openSuse, but I have not tried it.
The compat-stable fixes are addressing some compile problems with older
kernel versions. I have not tested all supported kernels.
The last stable kernel was added later so the number does not match.
Hauke Mehrtens (10):
[compat-2.6 and compat-stable] Export round_jiffies_up again.
[compat-2.6 and compat-stable] Remove unused code
[compat-2.6] Move trace headers
[compat-2.6] Fix compile bug with kernel 2.6.32
[compat-2.6] Remove temporary fix
[compat-2.6] Fix build with kernel < 2.6.27
[compat-2.6] b44 fix
[compat-2.6] refresh patches
[compat-2.6] Add skb_add_rx_frag to backport.
[compat-stable] fix build with recent mainline kernel
compat/compat-2.6.27.h | 20 +++++
compat/compat-2.6.28.c | 12 +++-
compat/compat-2.6.28.h | 32 ++------
compat/patches/01-netdev.patch | 77 ++++++--------------
compat/patches/06-header-changes.patch | 19 -----
compat/patches/08-rename-iwl4965-config.patch | 2 +-
compat/patches/09-threaded-irq.patch | 4 +-
.../patches/10-add-wext-handlers-to-netdev.patch | 2 +-
compat/patches/12-iw_handler-changes.patch | 7 ++-
compat/patches/13-trace.patch | 35 ++++++++-
scripts/admin-update.sh | 2 +-
11 files changed, 101 insertions(+), 111 deletions(-)
^ permalink raw reply
* [PATCH 1/9] [compat-2.6 and compat-stable] Export round_jiffies_up again.
From: Hauke Mehrtens @ 2009-10-12 21:19 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, Hauke Mehrtens, larry.finger
In-Reply-To: <1255382358-20760-1-git-send-email-hauke@hauke-m.de>
The 2.6.27 mainline kernel does not export round_jiffies_up. It looks
like the openSuse kernel 2.6.27 does export this symbol. Rename the
compat symbol to not conflict with the openSuse kernel.
CC: larry.finger@gmail.com
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
compat/compat-2.6.28.c | 2 --
compat/compat-2.6.28.h | 5 +++++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/compat/compat-2.6.28.c b/compat/compat-2.6.28.c
index 613b009..33871a2 100644
--- a/compat/compat-2.6.28.c
+++ b/compat/compat-2.6.28.c
@@ -260,7 +260,6 @@ static unsigned long round_jiffies_common(unsigned long j, int cpu,
return j;
}
-#if 0
/**
* round_jiffies_up - function to round jiffies up to a full second
* @j: the time in (absolute) jiffies that should be rounded
@@ -275,6 +274,5 @@ unsigned long round_jiffies_up(unsigned long j)
return round_jiffies_common(j, raw_smp_processor_id(), true);
}
EXPORT_SYMBOL_GPL(round_jiffies_up);
-#endif
#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) */
diff --git a/compat/compat-2.6.28.h b/compat/compat-2.6.28.h
index 4e5a2ef..90d080c 100644
--- a/compat/compat-2.6.28.h
+++ b/compat/compat-2.6.28.h
@@ -195,6 +195,11 @@ static inline void tracepoint_update_probe_range(struct tracepoint *begin,
#endif
+/* openSuse includes round_jiffies_up in it's kernel 2.6.27.
+ * This is needed to prevent conflicts with the openSuse definition.
+ */
+#define round_jiffies_up backport_round_jiffies_up
+
unsigned long round_jiffies_up(unsigned long j);
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28)) */
--
1.6.2.1
^ permalink raw reply related
* Re: 2.6.31.[12] ath5k regression
From: Richard Zidlicky @ 2009-10-12 20:23 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20091011222142.M14763@bobcopeland.com>
On Sun, Oct 11, 2009 at 06:23:56PM -0400, Bob Copeland wrote:
> On Mon, 12 Oct 2009 00:00:02 +0200, Richard Zidlicky wrote:
> > so the results are same like before. The printk message came once only,
> > I will try to gather more debug info tomorrow.
>
> Meaning it works the same as with your change (replacing "chan != null"
> with "true") or it works the same as mainline, i.e. it fails?
it works like in mainline and fails.
Richard
^ permalink raw reply
* Re: [PATCH] b43: fix ieee80211_rx() context
From: David Miller @ 2009-10-12 20:08 UTC (permalink / raw)
To: linville; +Cc: kalle.valo, johannes, hidave.darkstar, linux-wireless
In-Reply-To: <20091012133835.GB27575@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 12 Oct 2009 09:38:36 -0400
> I'm not sure I see the difference between this and the rationale for
> having netif_rx_ni vs. an open-coded version of it? ieee80211_rx_ni
> seems like a small amount of code (could even be inline) that
> potentially avoids some stupid bugs...?
Sure, no problem, feel free to add ieee80211_rx_ni().
^ permalink raw reply
* Re: 2.6.32-rc4: Reported regressions 2.6.30 -> 2.6.31
From: Andrew Patterson @ 2009-10-12 19:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Andrew Morton, Linus Torvalds,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <56acieJJ2fF.A.nEB.Hzl0KB@chimera>
On Mon, 2009-10-12 at 00:41 +0200, Rafael J. Wysocki wrote:
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14309
> Subject : MCA on hp rx8640
> Submitter : Andrew Patterson <andrew.patterson@hp.com>
> Date : 2009-09-29 17:20 (13 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=db8be50c4307dac2b37305fc59c8dc0f978d09ea
> References : http://www.spinics.net/lists/linux-usb/msg22799.html
>
Linus fixed this one with d93a8f829fe1d2f3002f2c6ddb553d12db420412. It
also looks like a duplicate of
http://bugzilla.kernel.org/show_bug.cgi?id=14374
Thanks,
Andrew
--
Andrew Patterson
Hewlett-Packard
^ permalink raw reply
* Re: [PATCH 02/17 v2.6.32] iwl3945: update iwl3945_apm_init()
From: reinette chatre @ 2009-10-12 19:57 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Cahill, Ben M
In-Reply-To: <20091012185943.GC2794@tuxdriver.com>
Hi John,
On Mon, 2009-10-12 at 11:59 -0700, John W. Linville wrote:
> On Fri, Oct 09, 2009 at 01:20:18PM -0700, Reinette Chatre wrote:
> > From: Ben Cahill <ben.m.cahill@intel.com>
> >
> > Update iwl3945_apm_init() to set up device registers in sequence most recently
> > recommended by factory.
> >
> > Add resets for APMG interrupts and radio chip, formerly done only in
> > iwl3945_apm_reset(); moving them here assures that apm_init() will do
> > a complete job of preparing hardware not only after platform boot,
> > but also after apm_stop() has executed (due to rfkill, ifconfig down,
> > driver unload, etc.). This is in preparation to completely remove apm_reset().
> >
> > Add some comments.
> >
> > Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
> > Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
>
> Is this actually a regression? Can you provide a reference to the bug report?
This is something we discovered in the lab when we connected power
measurement tools to the device when the interface was down. In this
scenario the device is using a lot of power. This is not a regression
from the previous kernel version, it is something that was broken for a
while and only recently discovered.
Patches 2/17 and 3/17 address this issue and the above comment applies
to both.
We are still looking into issues related to this discovery and you may
see more fixes for this problem.
Reinette
^ permalink raw reply
* Re: [otus-devel] Fritz!WLAN USB-Stick N: Firmware ?
From: Joerg Albert @ 2009-10-12 19:18 UTC (permalink / raw)
To: Frank Schaefer; +Cc: otus-devel, linux-wireless@vger.kernel.org
In-Reply-To: <4AD328D5.3060905@gmx.net>
On 10/12/2009 03:02 PM, Frank Schaefer wrote:
> Hi,
>
> I 've got a Fritz!WLAN USB-Stick N (057c:8401) yesterday, and syslog
> tells me that the driver can't find the firmware-file
>
> usb 2-9: new high speed USB device using ehci_hcd and address 7
> usb 2-9: New USB device found, idVendor=057c, idProduct=8401
> usb 2-9: New USB device strings: Mfr=16, Product=32, SerialNumber=48
> usb 2-9: Product: FRITZ!WLAN USB Stick N
> usb 2-9: Manufacturer: AVM Berlin
> usb 2-9: SerialNumber: 001F3F048161
> usb 2-9: configuration #1 chosen from 1 choice
> usb 2-9: reset high speed USB device using ehci_hcd and address 7
> usb 2-9: firmware: requesting ar9170.fw
> usb 2-9: ar9170.fw firmware file not found, trying old firmware...
> usb 2-9: firmware: requesting ar9170-1.fw
> usb 2-9: file with init values not found.
> ar9170usb: probe of 2-9:1.0 failed with error -2
> usbcore: registered new interface driver ar9170usb
>
> I'm using kernel 2.6.31.2.
> Where can I get the firmware from and will it be included in the kernel
> in the future ?
For the AVM stick you need the one-stage firmware (opposite to the "old" two-stage one) from
http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw
as stated on the ar9170 driver's webpage (http://linuxwireless.org/en/users/Drivers/ar9170).
Check the md5sum after downloading.
I don't think it will ever be included into the kernel, rather into some Linux distribution package.
BTW, questions about the ar9170 driver are more likely to be answered on the linux-wireless mailing list, this one
is the list for the original driver made by Atheros.
HTH,
Joerg.
^ permalink raw reply
* Re: [PATCH 03/17 v2.6.32 and w-t] iwlwifi: turn off device when not used.
From: John W. Linville @ 2009-10-12 19:00 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linux-wireless, ipw3945-devel, Ben Cahill
In-Reply-To: <1255119634-3060-5-git-send-email-reinette.chatre@intel.com>
On Fri, Oct 09, 2009 at 01:20:20PM -0700, Reinette Chatre wrote:
> From: Ben Cahill <ben.m.cahill@intel.com>
>
> In some cases (e.g. when mac80211 calls iwl_mac_stop() for suspend or user
> no longer wants device active), device has not been going into low power state
> via __iwl_down(). apm_ops.reset() does not put device into low power state;
> instead it resets the device, then puts it into a powered-up state ready to be
> re-loaded with uCode and re-started. This has needlessly warmed up user's
> laptops and drained batteries.
>
> With current architecture in which mac80211 controls device up/down (including
> resetting device after firmware errors), there is no need for apm_ops.reset()
> any more; apm_ops.reset() is basically a combination of apm_ops.stop() and
> apm_ops.init().
>
> Instead, __iwl_down() now unconditionally places the device into a low-power
> state via apm_ops.stop(). Device may be re-started via __iwl_up() calling
> apm_ops.init() as soon as it may be needed (e.g. quickly for firmware errors),
> but in the meantime, device will stop wasting energy.
>
> Note that, even in this low power state, if driver re-enables interrupts,
> the device retains the ability to sense the hardware RF-KILL switch, and
> (except for 3945) interrupt the host when it changes.
>
> Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
It this a regression? Bug reference?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 02/17 v2.6.32] iwl3945: update iwl3945_apm_init()
From: John W. Linville @ 2009-10-12 18:59 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linux-wireless, ipw3945-devel, Ben Cahill
In-Reply-To: <1255119634-3060-3-git-send-email-reinette.chatre@intel.com>
On Fri, Oct 09, 2009 at 01:20:18PM -0700, Reinette Chatre wrote:
> From: Ben Cahill <ben.m.cahill@intel.com>
>
> Update iwl3945_apm_init() to set up device registers in sequence most recently
> recommended by factory.
>
> Add resets for APMG interrupts and radio chip, formerly done only in
> iwl3945_apm_reset(); moving them here assures that apm_init() will do
> a complete job of preparing hardware not only after platform boot,
> but also after apm_stop() has executed (due to rfkill, ifconfig down,
> driver unload, etc.). This is in preparation to completely remove apm_reset().
>
> Add some comments.
>
> Signed-off-by: Ben Cahill <ben.m.cahill@intel.com>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Is this actually a regression? Can you provide a reference to the bug report?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: RaLink 148f:3070 not working since upgrade from 2.6.30 to 2.6.31
From: Luis Correia @ 2009-10-12 18:46 UTC (permalink / raw)
To: Bráulio B O Bhavamitra; +Cc: linux-wireless
In-Reply-To: <1df1788c0910121117g5ad66013g95e2231fd983bb23@mail.gmail.com>
Hi,
2009/10/12 Bráulio B O Bhavamitra <brauliobo@gmail.com>:
> 2009/10/12 Bráulio B O Bhavamitra <brauliobo@gmail.com>
>>
>> 2009/10/12 John W. Linville <linville@tuxdriver.com>
>>>
>>> On Sun, Oct 11, 2009 at 09:18:24AM -0300, Bráulio B O Bhavamitra wrote:
>>> > Also in Ubuntu Karmic Beta (where the firmware is present) it doesn't
>>> > work (radio not working, can't find any access point)
>>> >
>>> > 2009/10/11 Bráulio B O Bhavamitra <brauliobo@gmail.com>:
>>> > > Since the upgrade from kernel 2.6.30 to 2.6.31 on archlinux the usb
>>> > > wireless from Ralink doesn't work anymore.
>>> > > Please ask for more info if necessary.
>>>
>>> This commit is post-2.6.30 (and pre-2.6.31):
>>>
>>> commit d53d9e67b55f6a9fc3f836c5c392eb41ce5676f4
>>> Author: Ivo van Doorn <IvDoorn@gmail.com>
>>> Date: Sun Apr 26 15:47:48 2009 +0200
>>>
>>> rt2x00: Implement support for rt2800usb
>>>
>>> Add support for the rt2800usb chipset.
>>>
>>> Current problems:
>>> * Cannot scan 11n AP's
>>> * No TX during first minute after association
>>> * Broken Hardware encryption
>>>
>>> Includes various patches from Mattias, Felix, Xose and Axel.
>>>
>>> Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
>>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>>> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
>>> Signed-off-by: Axel Kollhofer <rain_maker@root-forum.org>
>>> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
>>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>>
>>> That is the first time 148f:3070 is supported by the rt2x00 drivers.
>>> I have no idea what you were using up to 2.6.30...
>>
>> Ow, this is really strange.
>> I was using the ArchLinux's 2.6.30.6 kernel which is an almost vanilla kernel.
>> Very strange, I remember seeing it loading the <something>2870sta module and worked perfectly.
That's the driver in staging, known as crap.
It has nothing to do with the rt2x00 project.
Luis Correia
rt2x00 project admin
^ permalink raw reply
* Re: RaLink 148f:3070 not working since upgrade from 2.6.30 to 2.6.31
From: Bráulio B O Bhavamitra @ 2009-10-12 18:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1df1788c0910121112v13b5f16fy5b3b79dcd86e37d5@mail.gmail.com>
2009/10/12 Bráulio B O Bhavamitra <brauliobo@gmail.com>
>
> 2009/10/12 John W. Linville <linville@tuxdriver.com>
>>
>> On Sun, Oct 11, 2009 at 09:18:24AM -0300, Bráulio B O Bhavamitra wrote:
>> > Also in Ubuntu Karmic Beta (where the firmware is present) it doesn't
>> > work (radio not working, can't find any access point)
>> >
>> > 2009/10/11 Bráulio B O Bhavamitra <brauliobo@gmail.com>:
>> > > Since the upgrade from kernel 2.6.30 to 2.6.31 on archlinux the usb
>> > > wireless from Ralink doesn't work anymore.
>> > > Please ask for more info if necessary.
>>
>> This commit is post-2.6.30 (and pre-2.6.31):
>>
>> commit d53d9e67b55f6a9fc3f836c5c392eb41ce5676f4
>> Author: Ivo van Doorn <IvDoorn@gmail.com>
>> Date: Sun Apr 26 15:47:48 2009 +0200
>>
>> rt2x00: Implement support for rt2800usb
>>
>> Add support for the rt2800usb chipset.
>>
>> Current problems:
>> * Cannot scan 11n AP's
>> * No TX during first minute after association
>> * Broken Hardware encryption
>>
>> Includes various patches from Mattias, Felix, Xose and Axel.
>>
>> Signed-off-by: Mattias Nissler <mattias.nissler@gmx.de>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
>> Signed-off-by: Axel Kollhofer <rain_maker@root-forum.org>
>> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> That is the first time 148f:3070 is supported by the rt2x00 drivers.
>> I have no idea what you were using up to 2.6.30...
>
> Ow, this is really strange.
> I was using the ArchLinux's 2.6.30.6 kernel which is an almost vanilla kernel.
> Very strange, I remember seeing it loading the <something>2870sta module and worked perfectly.
>>
>> John
>> --
>> John W. Linville Someday the world will need a hero, and you
>> linville@tuxdriver.com might be all we have. Be ready.
>
^ permalink raw reply
* Re: Bleeding Edge does not compile (was Re: Bleeding Edge b43 dated since 30 of september no longer working & today does not even compile.)
From: Riffer @ 2009-10-12 18:03 UTC (permalink / raw)
To: Florian Fainelli; +Cc: linux-wireless
In-Reply-To: <200910121309.47401.florian@openwrt.org>
Florian Fainelli wrote:
> I got the same compilation failure here, the code in ath5k/base.c looks
> perfectly fine though.
The problem has been fixed in "compat-wireless-2009-10-09".
This package works as good as my previous favorite for "b43" named
"compat-wireless-2009-09-16". In addition it seems to be a little more
stable regarding connecting on system startup.
Thanks to whoever has fixed that! :-)
--
Riffer
^ permalink raw reply
* Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)
From: James Bottomley @ 2009-10-12 15:43 UTC (permalink / raw)
To: Greg KH
Cc: Ingo Molnar, Linus Torvalds, Theodore Tso, Andrew Morton,
linux-scsi, linux-kernel, Jing Huang, netdev, linux-wireless
In-Reply-To: <20091012150911.GB1656@suse.de>
On Mon, 2009-10-12 at 08:09 -0700, Greg KH wrote:
> adding David Miller and the wireless developers who had this idea as
> well...
>
> On Mon, Oct 12, 2009 at 04:54:53PM +0200, Ingo Molnar wrote:
> > I think your interpretation is arbitrary - where did you get that ABI
> > rule from? I'm sure it cannot be from any of the drivers/staging/
> > discussions on lkml, i've followed them quite closely. If 'has a messy
> > ABI' was the only requirement for drivers/staging/ then we could move
> > 90% of drivers/staging/ into drivers/ straight away - and that would be
> > counter-productive IMHO.
>
> I agree with this, and the other points you raised that I snipped out.
>
> > Sidenote, in fact i think we should expand on that: drivers/staging/
> > should be used in the _other_ direction as well - to un-upstream stale
> > drivers that are abandoned and unused, in a gradual fashion. 'git mv' is
> > cheap.
>
> Ok, this is about the 3rd or 4th time I've heard this, from totally
> different people lately. It seems that I'm the only one that has the
> ability to drop drivers out of the kernel tree, which is a funny
> situation :)
>
> In thinking about this a lot more, I don't really mind it. If people
> want to push stuff out of "real" places in the kernel, into
> drivers/staging/ and give the original authors and maintainers notice
> about what is going on, _and_ provide a TODO file for what needs to
> happen to get the code back into the main portion of the kernel tree,
> then I'll be happy to help out with this and manage it.
>
> I think a 6-9 month window (basically 3 kernel releases) should be
> sufficient time to have a driver that has been in drivers/staging/ be
> cleaned up enough to move back into the main kernel tree. If not, it
> could be easily dropped.
>
> Any objections to this?
Not as an optional tool to use when necessary.
If you want to make this a mandatory path for old drivers, then, I think
it's far too rigid, yes. There's a huge amount of danger to changing
working drivers simply on grounds of code cleanup and that danger
increases exponentially as they get older and the hardware gets rarer.
Look at what happened to the initio driver in 2008 for instance. That
was cleaned up by Alan Cox, no mean expert in the field, with the
assistance of a tester with the actual card, so basically a textbook
operation. However, a bug crept in during this process that wasn't
spotted by the tester. When it was spotted (bug report ~6 months later)
the original tester wasn't available and code inspection across the
cleanup was very hard. Fortunately, the reporter was motivated to track
down and patch the driver, so it worked out all right in the end, but a
lot of bug reporters aren't so capable (or so motivated). Plus most
clean up patches for old hardware tend only to be compile tested, so the
potential for bugs is far greater.
James
> > Basically, drivers/staging/ gives us an excellent opportunity to
> > _increase_ the quality of drivers by applying stronger upstream
> > inclusion filters, without having to hurt users/developers in the
> > process. We just have to start using it that way as well.
>
> I totally agree. And so far, it does seem to be working well for this.
> A number of companies have used it to successfully get their code into
> the main kernel, as well as driving them to clean up their code better
> to keep it from having to go into the staging tree.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)
From: Ingo Molnar @ 2009-10-12 15:42 UTC (permalink / raw)
To: Greg KH
Cc: James Bottomley, Linus Torvalds, Theodore Tso, Andrew Morton,
linux-scsi, linux-kernel, Jing Huang, netdev, linux-wireless
In-Reply-To: <20091012150911.GB1656@suse.de>
* Greg KH <gregkh@suse.de> wrote:
> > Sidenote, in fact i think we should expand on that: drivers/staging/
> > should be used in the _other_ direction as well - to un-upstream
> > stale drivers that are abandoned and unused, in a gradual fashion.
> > 'git mv' is cheap.
>
> Ok, this is about the 3rd or 4th time I've heard this, from totally
> different people lately. [...]
Heh. I guess i had a good crystal ball on that then - i raised that
issue in my very first comments on drivers/staging/, 2.5 years ago - see
the "Linux Kernel developer statement about closed source code" thread,
where i wrote:
| - We must accept open-source drivers (which are license-compatible
| with the kernel) for new hardware the moment they are offered. No
| ifs and when. No whining about quality, style, security, re-use,
| non-reuse, obsolete APIs, overlapping functionality, the already
| busy merge schedule of a maintainer or whatever other thing can come
| up on lkml.
|
| We can create arbitrary quarantine mechanisms we wish to use:
| CONFIG_REALLY_BROKEN. We could even create drivers/staging/ as a
| temporary staging area for drivers.
|
| What we cannot do is to _deny_ the distribution channel and exclude
| users. The moment we do that (and we still do that in way too many
| areas of the kernel) we have lost the availability race.
[...]
| If it's not maintained actively(sc) (i.e. it's a fire-and-forget
| driver) then it can get marked BROKEN with time, and can get removed
| as well.
Hm, i think i even gave drivers/staging/ its name?
> [...] It seems that I'm the only one that has the ability to drop
> drivers out of the kernel tree, which is a funny situation :)
You are the only one who has the ability to send a warning shot towards
drivers _without hurting users_, and by moving it into the focus of a
team of cleanup oriented developers.
I think that's an important distinction ;-)
> In thinking about this a lot more, I don't really mind it. If people
> want to push stuff out of "real" places in the kernel, into
> drivers/staging/ and give the original authors and maintainers notice
> about what is going on, _and_ provide a TODO file for what needs to
> happen to get the code back into the main portion of the kernel tree,
> then I'll be happy to help out with this and manage it.
>
> I think a 6-9 month window (basically 3 kernel releases) should be
> sufficient time to have a driver that has been in drivers/staging/ be
> cleaned up enough to move back into the main kernel tree. If not, it
> could be easily dropped.
>
> Any objections to this?
Sounds excellent to me!
> > Basically, drivers/staging/ gives us an excellent opportunity to
> > _increase_ the quality of drivers by applying stronger upstream
> > inclusion filters, without having to hurt users/developers in the
> > process. We just have to start using it that way as well.
>
> I totally agree. And so far, it does seem to be working well for
> this. A number of companies have used it to successfully get their
> code into the main kernel, as well as driving them to clean up their
> code better to keep it from having to go into the staging tree.
Yeah. I think we were hurting from an under-estimated trust problem:
driver authors couldnt trust _us maintainers_ to follow through with
upstreaming. drivers/staging/ improved that IMHO.
I.e. the old process of upstreaming drivers was too arbitrary, incurred
big latencies and was dependent on the whims of maintainers. I.e. new
developers got exposed to some of the worst social aspects of a
distributed development process.
Now there's basically a single (and friendly! ;-) upstreaming channel
that people (yet-)unfamilar with Linux practices can standardize on.
This reduces the pressure on maintainers and also creates a reference
point for upstreaming honesty - which is almost unconditionally good i
think.
Ingo
^ permalink raw reply
* Moving drivers into staging (was Re: [GIT PULL] SCSI fixes for 2.6.32-rc3)
From: Greg KH @ 2009-10-12 15:09 UTC (permalink / raw)
To: Ingo Molnar
Cc: James Bottomley, Linus Torvalds, Theodore Tso, Andrew Morton,
linux-scsi, linux-kernel, Jing Huang, netdev, linux-wireless
In-Reply-To: <20091012145453.GD4565@elte.hu>
adding David Miller and the wireless developers who had this idea as
well...
On Mon, Oct 12, 2009 at 04:54:53PM +0200, Ingo Molnar wrote:
> I think your interpretation is arbitrary - where did you get that ABI
> rule from? I'm sure it cannot be from any of the drivers/staging/
> discussions on lkml, i've followed them quite closely. If 'has a messy
> ABI' was the only requirement for drivers/staging/ then we could move
> 90% of drivers/staging/ into drivers/ straight away - and that would be
> counter-productive IMHO.
I agree with this, and the other points you raised that I snipped out.
> Sidenote, in fact i think we should expand on that: drivers/staging/
> should be used in the _other_ direction as well - to un-upstream stale
> drivers that are abandoned and unused, in a gradual fashion. 'git mv' is
> cheap.
Ok, this is about the 3rd or 4th time I've heard this, from totally
different people lately. It seems that I'm the only one that has the
ability to drop drivers out of the kernel tree, which is a funny
situation :)
In thinking about this a lot more, I don't really mind it. If people
want to push stuff out of "real" places in the kernel, into
drivers/staging/ and give the original authors and maintainers notice
about what is going on, _and_ provide a TODO file for what needs to
happen to get the code back into the main portion of the kernel tree,
then I'll be happy to help out with this and manage it.
I think a 6-9 month window (basically 3 kernel releases) should be
sufficient time to have a driver that has been in drivers/staging/ be
cleaned up enough to move back into the main kernel tree. If not, it
could be easily dropped.
Any objections to this?
> Basically, drivers/staging/ gives us an excellent opportunity to
> _increase_ the quality of drivers by applying stronger upstream
> inclusion filters, without having to hurt users/developers in the
> process. We just have to start using it that way as well.
I totally agree. And so far, it does seem to be working well for this.
A number of companies have used it to successfully get their code into
the main kernel, as well as driving them to clean up their code better
to keep it from having to go into the staging tree.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] crda: Cosmetic fix for udev path
From: Tim Gardner @ 2009-10-12 15:02 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 184 bytes --]
Luis,
This patch is against
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git. It fixes
some complaints about an extra '/'.
rtg
--
Tim Gardner tim.gardner@canonical.com
[-- Attachment #2: 0001-Cosmetic-fix-for-udev-path.patch --]
[-- Type: text/x-patch, Size: 911 bytes --]
>From 31a08704192dee87ee592f70988ee7806c37523a Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Mon, 12 Oct 2009 08:53:31 -0600
Subject: [PATCH] crda: Cosmetic fix for udev path
BugLink: http://bugs.launchpad.net/bugs/340995
SBINDIR already has a trailing '/', so its not needed
in the udev rule.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
udev/regulatory.rules | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/udev/regulatory.rules b/udev/regulatory.rules
index 5588ed7..3d6add8 100644
--- a/udev/regulatory.rules
+++ b/udev/regulatory.rules
@@ -2,4 +2,4 @@
# For more information see:
# http://wireless.kernel.org/en/developers/Regulatory/CRDA
-KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="$(SBINDIR)/crda"
+KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="$(SBINDIR)crda"
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH V3] iwlwifi: use paged Rx
From: Stanislaw Gruszka @ 2009-10-12 14:20 UTC (permalink / raw)
To: Zhu Yi; +Cc: linville, linux-wireless
In-Reply-To: <1255079985-17282-1-git-send-email-yi.zhu@intel.com>
On Fri, Oct 09, 2009 at 05:19:45PM +0800, Zhu Yi wrote:
> This switches the iwlwifi driver to use paged skb from linear skb for Rx
> buffer. So that it relieves some Rx buffer allocation pressure for the
> memory subsystem. Currently iwlwifi (4K for 3945) requests 8K bytes for
> Rx buffer. Due to the trailing skb_shared_info in the skb->data,
> alloc_skb() will do the next order allocation, which is 16K bytes. This
> is suboptimal and more likely to fail when the system is under memory
> usage pressure. Switching to paged Rx skb lets us allocate the RXB
> directly by alloc_pages(), so that only order 1 allocation is required.
[snip]
> Finally, mac80211 doesn't support paged Rx yet. So we linearize the skb
> for all the management frames and software decryption or defragmentation
> required data frames before handed to mac80211. For all the other frames,
> we __pskb_pull_tail 64 bytes in the linear area of the skb for mac80211
> to handle them properly.
This seems to be big overhead, but since there is no way to avoid it ...
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> ---
> V2: fix 3945 problem and linearize skb for fragemented frames
> V3: fix a 3945 pci_unmap_page bug
>
> drivers/net/wireless/iwlwifi/iwl-3945.c | 67 ++++++++++-----
> drivers/net/wireless/iwlwifi/iwl-4965.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl-5000.c | 4 +-
> drivers/net/wireless/iwlwifi/iwl-agn.c | 42 ++++-----
> drivers/net/wireless/iwlwifi/iwl-commands.h | 10 ++
> drivers/net/wireless/iwlwifi/iwl-core.c | 13 ++--
> drivers/net/wireless/iwlwifi/iwl-core.h | 2 +-
> drivers/net/wireless/iwlwifi/iwl-dev.h | 27 ++++--
> drivers/net/wireless/iwlwifi/iwl-hcmd.c | 21 ++----
> drivers/net/wireless/iwlwifi/iwl-rx.c | 122 +++++++++++++++++----------
> drivers/net/wireless/iwlwifi/iwl-scan.c | 20 ++--
> drivers/net/wireless/iwlwifi/iwl-spectrum.c | 2 +-
> drivers/net/wireless/iwlwifi/iwl-sta.c | 62 +++++--------
> drivers/net/wireless/iwlwifi/iwl-tx.c | 10 +-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 120 +++++++++++++-------------
> 15 files changed, 284 insertions(+), 240 deletions(-)
[snip]
> @@ -543,14 +543,17 @@ static void iwl3945_pass_packet_to_mac80211(struct iwl_priv *priv,
> struct iwl_rx_mem_buffer *rxb,
> struct ieee80211_rx_status *stats)
> {
> - struct iwl_rx_packet *pkt = (struct iwl_rx_packet *)rxb->skb->data;
> + struct iwl_rx_packet *pkt = rxb_addr(rxb);
> struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)IWL_RX_DATA(pkt);
> struct iwl3945_rx_frame_hdr *rx_hdr = IWL_RX_HDR(pkt);
> struct iwl3945_rx_frame_end *rx_end = IWL_RX_END(pkt);
> - short len = le16_to_cpu(rx_hdr->len);
> + u16 len = le16_to_cpu(rx_hdr->len);
> + struct sk_buff *skb;
> + int ret;
>
> /* We received data from the HW, so stop the watchdog */
> - if (unlikely((len + IWL39_RX_FRAME_SIZE) > skb_tailroom(rxb->skb))) {
> + if (unlikely(len + IWL39_RX_FRAME_SIZE >
> + PAGE_SIZE << priv->hw_params.rx_page_order)) {
> IWL_DEBUG_DROP(priv, "Corruption detected!\n");
> return;
> }
> @@ -562,20 +565,45 @@ static void iwl3945_pass_packet_to_mac80211(struct iwl_priv *priv,
> return;
> }
>
> - skb_reserve(rxb->skb, (void *)rx_hdr->payload - (void *)pkt);
> - /* Set the size of the skb to the size of the frame */
> - skb_put(rxb->skb, le16_to_cpu(rx_hdr->len));
> + skb = alloc_skb(IWL_LINK_HDR_MAX, GFP_ATOMIC);
> + if (!skb) {
> + IWL_ERR(priv, "alloc_skb failed\n");
> + return;
> + }
If we know that we need to linearize we can alloc as big skb as needed,
otherwise skb_linearize() need to do reallocation.
Can we also remove IWL_LINK_HDR_MAX and do __pskb_pull_tail based on
real header(s) size ?
Or.
If we decide to do alloc_skb(IWL_LINK_HDR_MAX, gfp_flags) can this be
done together with skb_add_rx_frag() in iwl_rx_allocate(), to offload
this interrupt context ?
> if (!iwl3945_mod_params.sw_crypto)
> iwl_set_decrypted_flag(priv,
> - (struct ieee80211_hdr *)rxb->skb->data,
> + (struct ieee80211_hdr *)rxb_addr(rxb),
> le32_to_cpu(rx_end->status), stats);
>
> + skb_add_rx_frag(skb, 0, rxb->page,
> + (void *)rx_hdr->payload - (void *)pkt, len);
> +
> + /* mac80211 currently doesn't support paged SKB. Convert it to
> + * linear SKB for management frame and data frame requires
> + * software decryption or software defragementation. */
> + if (ieee80211_is_mgmt(hdr->frame_control) ||
> + ieee80211_has_protected(hdr->frame_control) ||
> + ieee80211_has_morefrags(hdr->frame_control) ||
> + le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_FRAG)
Minor optimization:
hdr->seq_ctrl & cpu_to_le16(IEEE80211_SCTL_FRAG)
> + ret = skb_linearize(skb);
> + else
> + ret = __pskb_pull_tail(skb, min_t(u16, IWL_LINK_HDR_MAX, len)) ?
> + 0 : -ENOMEM;
> +
> + if (ret) {
> + kfree_skb(skb);
> + goto out;
> + }
> +
> iwl_update_stats(priv, false, hdr->frame_control, len);
>
> - memcpy(IEEE80211_SKB_RXCB(rxb->skb), stats, sizeof(*stats));
> - ieee80211_rx_irqsafe(priv->hw, rxb->skb);
> - rxb->skb = NULL;
> + memcpy(IEEE80211_SKB_RXCB(skb), stats, sizeof(*stats));
> + ieee80211_rx(priv->hw, skb);
> +
> + out:
> + priv->alloc_rxb_page--;
> + rxb->page = NULL;
> }
[snip]
> struct iwl_rx_mem_buffer {
> - dma_addr_t real_dma_addr;
> - dma_addr_t aligned_dma_addr;
> - struct sk_buff *skb;
> + dma_addr_t page_dma;
> + struct page *page;
> struct list_head list;
> };
>
> +#define rxb_addr(r) page_address(r->page)
Since we mostly use pointer, perhaps better would be save address of page
in iwl_rx_mem_buffer, and use virt_to_page where struct page is needed.
[snip]
> @@ -252,29 +252,34 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority)
>
> if (rxq->free_count > RX_LOW_WATERMARK)
> priority |= __GFP_NOWARN;
> - /* Alloc a new receive buffer */
> - skb = alloc_skb(priv->hw_params.rx_buf_size + 256,
> - priority);
>
> - if (!skb) {
> + if (priv->hw_params.rx_page_order > 0)
> + priority |= __GFP_COMP;
> +
> + /* Alloc a new receive buffer */
> + page = alloc_pages(priority, priv->hw_params.rx_page_order);
> + if (!page) {
> if (net_ratelimit())
> - IWL_DEBUG_INFO(priv, "Failed to allocate SKB buffer.\n");
> + IWL_DEBUG_INFO(priv, "alloc_pages failed, "
> + "order: %d\n",
> + priv->hw_params.rx_page_order);
> +
> if ((rxq->free_count <= RX_LOW_WATERMARK) &&
> net_ratelimit())
> - IWL_CRIT(priv, "Failed to allocate SKB buffer with %s. Only %u free buffers remaining.\n",
> + IWL_CRIT(priv, "Failed to alloc_pages with %s. Only %u free buffers remaining.\n",
> priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL",
priority can not be equal GFP_ATOMIC if was or'ed with __GFP_COMP or __GFP_NOWARN
Cheers
Stanislaw
^ permalink raw reply
* Re: WARNING: slow-path
From: Holger Schurig @ 2009-10-12 14:02 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-wireless
In-Reply-To: <1255352906.30919.11.camel@macbook.infradead.org>
> What happens if you make that last argument NULL instead of
> passing 'dummy' back to it? That makes cfg80211_send_deauth()
> magically do different things w.r.t. locking.
That worked, thanks.
> Johannes, this is _evil_:
It's not only _evil_, it's also undocumented. I was just
following include/net/cfg80211.h. There is no kernel-doc in the
comments for "cookie", neither in
[struct cfg80211_ops:]
int (*deauth)(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_deauth_request *req,
void *cookie);
nor in
void cfg80211_send_deauth(struct net_device *dev, const u8 *buf, size_t len,
void *cookie);
so I automatically assumed that I have to provide the "cookie" I
got in my deauth()-handler to cfg80211_send_deauth().
/me says "I can haz a cookie?"
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: 802.11: Throughput optimization beyond rate selection
From: John W. Linville @ 2009-10-12 13:59 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless
In-Reply-To: <487238.22616.qm@web51405.mail.re2.yahoo.com>
On Mon, Oct 12, 2009 at 02:28:07AM -0700, Joerg Pommnitz wrote:
> Hello all,
> the throughput achieved over a wireless 802.11 network depends on more than the
> rate selection. Other parameters are fragmentation threshold, RTS threshold
> and the retry limits. Are you aware of a "unified throughput optimization" algorithm
> that tries to optimize the whole parameter set instead of just the data rate?
No, do tell...post code as well... :-)
--
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
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