* Re: Compat-wireless release for 2010-06-15v2 is baked
From: Luis R. Rodriguez @ 2010-06-16 1:17 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: Hauke Mehrtens
In-Reply-To: <AANLkTik49vfTI7UHzCOGJRXdAYJN9fLmwS-xNcHeBcAu@mail.gmail.com>
On Tue, Jun 15, 2010 at 5:41 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Ok if you don't see any more of these daily please kick me or Haukes.
> Both of us should have access to fix pushing these out now from orbit.
> The backup in case orbit goes down is:
>
> http://wireless.kernel.org/download/compat-wireless-2.6/
Here's another idea. If I'm on vacation or whatever, those who have
access to orbit could just flip a switch and change the git URL to
point to some other git tree to be used as base. Then to aid companies
who want to set up their own repository in case they need more timely
mannered releases based on pending patches you can use this:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-user.git
This is the same setup as what we have at orbit, it mimics the user
environment at Orbit, so all you need is an account and space and to
set up a cronjob (read the README). If you find bugs/enhancement to
the scripts just post 'em too.
For those that can wait on me I guess Orbit will do :)
Luis
^ permalink raw reply
* [PATCH] ipw2200: Enable LED by default
From: Leann Ogasawara @ 2010-06-16 0:55 UTC (permalink / raw)
To: reinette.chatre, ilw; +Cc: linux-wireless, TJ
Hi All,
As documented in 2005 in Documentation/networking/README.ipw2200, "The
LED code has been reported to hang some systems when running ifconfig
and is therefore disabled by default." We've however been carrying the
following patch in our Ubuntu kernel for quite some time which enables
the ipw2200 LED by default. This was a result of numerous user
requests. We've seen no subsequent bug reports of systems hanging due
to the the LED code being enabled by default. I'd therefore like to
propose the following patch to enable the LED by default. This patch
was originally authored by TJ. I apologize in advance that I do not
have TJ's full first and last name for provenance.
Thanks,
Leann
>From 315246037a0edab4d626de6ccb68c73d3fe61ce3 Mon Sep 17 00:00:00 2001
From: ubuntu@tjworld.net <ubuntu@tjworld.net>
Date: Mon, 23 Mar 2009 20:29:28 +0000
Subject: [PATCH] ipw2200: Enable LED by default
BugLink: http://bugs.launchpad.net/bugs/21367
Enable LED by default and update the MODULE_PARM_DESC. The original
reason for defaulting to disabled was documented in 2005 and noted, "The
LED code has been reported to hang some systems when running ifconfig
and is therefore disabled by default." This no longer appears
applicable and users have been requesting this be enabled for several
years.
Originally-by: TJ <ubuntu@tjworld.net>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
---
Documentation/networking/README.ipw2200 | 2 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
index 80c7285..e4d3267 100644
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -171,7 +171,7 @@ Where the supported parameter are:
led
Can be used to turn on experimental LED code.
- 0 = Off, 1 = On. Default is 0.
+ 0 = Off, 1 = On. Default is 1.
mode
Can be used to set the default mode of the adapter.
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 3aa3bb1..0805569 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -96,7 +96,7 @@ static int network_mode = 0;
static u32 ipw_debug_level;
static int associate;
static int auto_create = 1;
-static int led_support = 0;
+static int led_support = 1;
static int disable = 0;
static int bt_coexist = 0;
static int hwcrypto = 0;
@@ -12083,7 +12083,7 @@ module_param(auto_create, int, 0444);
MODULE_PARM_DESC(auto_create, "auto create adhoc network (default on)");
module_param_named(led, led_support, int, 0444);
-MODULE_PARM_DESC(led, "enable led control on some systems (default 0 off)");
+MODULE_PARM_DESC(led, "enable led control on some systems (default 1 on)");
module_param(debug, int, 0444);
MODULE_PARM_DESC(debug, "debug output mask");
--
1.7.0.4
^ permalink raw reply related
* Re: Compat-wireless release for 2010-06-15v2 is baked
From: Luis R. Rodriguez @ 2010-06-16 0:41 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: Hauke Mehrtens
In-Reply-To: <20100616003813.77B0E42E2C@repository3.localdomain>
Ok if you don't see any more of these daily please kick me or Haukes.
Both of us should have access to fix pushing these out now from orbit.
The backup in case orbit goes down is:
http://wireless.kernel.org/download/compat-wireless-2.6/
Luis
On Tue, Jun 15, 2010 at 5:38 PM, Compat-wireless cronjob account
<compat@orbit-lab.org> wrote:
>
> compat-wireless code metrics
>
> 498409 - Total upstream lines of code being pulled
> 1398 - backport code changes
> 1167 - backport code additions
> 231 - backport code deletions
> 5748 - backport from compat module
> 7146 - total backport code
> 1.4338 - % of code consists of backport work
> 13 - Code changes posted but not yet merged
> 8 - Code additions posted but not yet merged
> 5 - Code deletions posted but not yet merged
> 0.0026 - % of code not yet merged
> 1218 - Crap changes not yet posted
> 1179 - Crap additions not yet merged
> 39 - Crap deletions not yet posted
> 0.2444 - % of crap code
>
> Base tree: linux-next.git
> Base tree version: next-20100615
> compat-wireless release: compat-wireless-2010-06-10-11-gd1c4956
> --
> 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
>
^ permalink raw reply
* Compat-wireless release for 2010-06-15v2 is baked
From: Compat-wireless cronjob account @ 2010-06-16 0:38 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
compat-wireless code metrics
498409 - Total upstream lines of code being pulled
1398 - backport code changes
1167 - backport code additions
231 - backport code deletions
5748 - backport from compat module
7146 - total backport code
1.4338 - % of code consists of backport work
13 - Code changes posted but not yet merged
8 - Code additions posted but not yet merged
5 - Code deletions posted but not yet merged
0.0026 - % of code not yet merged
1218 - Crap changes not yet posted
1179 - Crap additions not yet merged
39 - Crap deletions not yet posted
0.2444 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100615
compat-wireless release: compat-wireless-2010-06-10-11-gd1c4956
^ permalink raw reply
* Compat-wireless release for 2010-06-15 is baked
From: Compat-wireless cronjob account @ 2010-06-16 0:35 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
make: gcc: Command not found
make: Entering directory `/usr/src/linux-headers-2.6.31-14-server'
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
/usr/src/linux-headers-2.6.31-14-server/arch/x86/Makefile:80: stack protector enabled but no compiler support
make[1]: gcc: Command not found
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
make: gcc: Command not found
make: Entering directory `/usr/src/linux-headers-2.6.31-14-server'
/usr/src/linux-headers-2.6.31-14-server/arch/x86/Makefile:80: stack protector enabled but no compiler support
make[1]: gcc: Command not found
make: gcc: Command not found
make: Entering directory `/usr/src/linux-headers-2.6.31-14-server'
/usr/src/linux-headers-2.6.31-14-server/arch/x86/Makefile:80: stack protector enabled but no compiler support
make[1]: gcc: Command not found
compat-wireless code metrics
498409 - Total upstream lines of code being pulled
1398 - backport code changes
1167 - backport code additions
231 - backport code deletions
5748 - backport from compat module
7146 - total backport code
1.4338 - % of code consists of backport work
13 - Code changes posted but not yet merged
8 - Code additions posted but not yet merged
5 - Code deletions posted but not yet merged
0.0026 - % of code not yet merged
1218 - Crap changes not yet posted
1179 - Crap additions not yet merged
39 - Crap deletions not yet posted
0.2444 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100615
compat-wireless release: compat-wireless-2010-06-10-11-gd1c4956
^ permalink raw reply
* Re: [PATCH] compat: backport lockdep_assert_held
From: Luis R. Rodriguez @ 2010-06-15 23:53 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1276635464-27982-1-git-send-email-hauke@hauke-m.de>
On Tue, Jun 15, 2010 at 1:57 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
applied, thanks!
Luis
^ permalink raw reply
* Re: [PATCH] compat-wireless: refresh patches:
From: Luis R. Rodriguez @ 2010-06-15 23:53 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1276635395-27923-1-git-send-email-hauke@hauke-m.de>
On Tue, Jun 15, 2010 at 1:56 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> make the patches apply against recent linux-next.
applied!
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
>
> Luis please remove all patches from linux-next-pending, because they are in
> linux-next now.
Done, thanks a lot!
Luis
^ permalink raw reply
* [PATCH v2] p54usb: Comment out duplicate Medion MD40900 device id
From: Leann Ogasawara @ 2010-06-15 23:39 UTC (permalink / raw)
To: John W. Linville; +Cc: Larry Finger, linux-wireless, Ben Collins
In-Reply-To: <20100615194610.GB2415@tuxdriver.com>
On Tue, 2010-06-15 at 15:46 -0400, John W. Linville wrote:
> On Tue, Jun 15, 2010 at 10:59:05AM -0700, Leann Ogasawara wrote:
> > On Mon, 2010-06-14 at 14:55 -0400, John W. Linville wrote:
>
> > > So, I guess you are concerned about the groupings because of the
> > > different firmwares or something like that? Perhaps a comment that
> > > says "this could be a version 2 device" is just as handy? Since the
> > > driver prints the name of the firmware it wants, is there any real
> > > need for grouping the IDs?
> > >
> > > OTOH, is there any actual harm from the duplicate entry? It "seems"
> > > wrong to me too, but I guess it does no harm...?
> >
> > I don't believe there is any harm from the duplicate entry, it just
> > seemed unnecessary.
> >
> > > Leann and/or Ben, was this just tidying-up? I'm guessing there wasn't
> > > an actual bug involved?
> >
> > Indeed, this was just a patch we'd been carrying to tidy things up.
> > There was no actual bug involved. I'd be happy to send a v2 of the
> > patch which comments out the duplicate entry and adds a note as to why.
> > Or I'd be fine just leaving the code as is and we'll drop the patch
> > we're carrying locally in Ubuntu.
>
> FWIW, I like the 'comment-out and add a note' option.
Here's the 'comment-out and add a note' option. Let me know if you'd
prefer a different style formatting etc.
Thanks,
Leann
>From 5d1b6029ffc0eb770cd34f7dd1a910451c0cda4d Mon Sep 17 00:00:00 2001
From: Leann Ogasawara <leann.ogasawara@canonical.com>
Date: Tue, 15 Jun 2010 14:01:51 -0700
Subject: [PATCH] p54usb: Comment out duplicate Medion MD40900 device id
The Medion MD40900 device id [0x0cde, 0x0006] is defined twice.
Comment out the duplicate.
Originally-by: Ben Collins <ben.collins@ubuntu.com>
Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
---
drivers/net/wireless/p54/p54usb.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 7307325..2d8d03d 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -69,7 +69,8 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x0915, 0x2002)}, /* Cohiba Proto board */
{USB_DEVICE(0x0baf, 0x0118)}, /* U.S. Robotics U5 802.11g Adapter*/
{USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
- {USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
+ /* {USB_DEVICE(0x0cde, 0x0006)}, * Medion MD40900 already listed above,
+ * just noting it here for clarity */
{USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
{USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
{USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
--
1.7.0.4
^ permalink raw reply related
* Pending stable patches for 802.11 sent
From: Luis R. Rodriguez @ 2010-06-15 22:43 UTC (permalink / raw)
To: Greg KH, stable; +Cc: linux-wireless, John W. Linville
As per this list:
http://wireless.kernel.org/en/developers/stable-pending
we have sent all pending patches. Vivek sent the respective port for
"ath9k: Avoid corrupt frames being forwarded to mac80211" for 2.6.32,
2.6.33 and 2.6.34. This last one was split into two patches one for
2.6.33 and 2.6.34, and the other backport for 2.6.32.
I am not aware of any other pending patches, if anyone is please peg
them to the wiki list for tacking purposes.
Luis
^ permalink raw reply
* [PATCH 2.6.32..2.6.33] ath5k: drop warning on jumbo frames
From: Luis R. Rodriguez @ 2010-06-15 22:35 UTC (permalink / raw)
To: stable, greg; +Cc: linux-wireless, Luis R. Rodriguez, John W. Linville
commit 9637e516d16a58b13f6098cfe899e22963132be3 upstream.
Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.
Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.
This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.
Cc: stable@kernel.org
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Greg, here's a stable ath5k patch which required some manual
backport. The backported was needed since the sc->stats.rxerr_jumbo
counter was not available until 2.6.34 and it was used on the upstream
commit. This goes only compile tested against 2.6.32.y and 2.6.33.y.
drivers/net/wireless/ath/ath5k/base.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 6313788..9846e8b 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1818,11 +1818,6 @@ ath5k_tasklet_rx(unsigned long data)
return;
}
- if (unlikely(rs.rs_more)) {
- ATH5K_WARN(sc, "unsupported jumbo\n");
- goto next;
- }
-
if (unlikely(rs.rs_status)) {
if (rs.rs_status & AR5K_RXERR_PHY)
goto next;
@@ -1852,6 +1847,8 @@ ath5k_tasklet_rx(unsigned long data)
sc->opmode != NL80211_IFTYPE_MONITOR)
goto next;
}
+ if (unlikely(rs.rs_more))
+ goto next;
accept:
next_skb = ath5k_rx_skb_alloc(sc, &next_skb_addr);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2.6.32.y] ath9k: re-enable ps by default for new single chip families
From: Luis R. Rodriguez @ 2010-06-15 22:19 UTC (permalink / raw)
To: stable, greg
Cc: linux-wireless, Luis R. Rodriguez, Peter Stuge, Justin P. Mattock,
Kristoffer Ericson, John W. Linville
commit 14acdde6e527950f66c084dbf19bad6fbfcaeedc upstream.
The newer single chip hardware family of chipsets have not been
experiencing issues with power saving set by default with recent
fixes merged (even into stable). The remaining issues are only
reported with AR5416 and since enabling PS by default can increase
power savings considerably best to take advantage of that feature
as this has been tested properly.
For more details on this issue see the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=14267
We leave AR5416 with PS disabled by default, that seems to require
some more work.
Cc: stable@kernel.org
Cc: Peter Stuge <peter@stuge.se>
Cc: Justin P. Mattock <justinmattock@gmail.com>
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Greg, this is the long promised backport of the patch titled
"ath9k: re-enable ps by default for new single chip families" backported
down to 2.6.32.y. This just goes test compiled. Manual backport
was required from the upstream Linus patch since the flag
WIPHY_FLAG_PS_ON_BY_DEFAULT was not used back on 2.6.32 so instead
we use the equivalent hw->wiphy->ps_default bool.
Apologies for the delay, was just stuck with other stuff.
I'll remove this from the stable pending list for 802.11 [1] once
this gets sucked in.
[1] http://wireless.kernel.org/en/developers/stable-pending
drivers/net/wireless/ath/ath9k/main.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 15eb245..dba27b7 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1538,6 +1538,8 @@ bad_no_ah:
void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
{
+ struct ath_hw *ah = sc->sc_ah;
+
hw->flags = IEEE80211_HW_RX_INCLUDES_FCS |
IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING |
IEEE80211_HW_SIGNAL_DBM |
@@ -1556,7 +1558,10 @@ void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
BIT(NL80211_IFTYPE_ADHOC) |
BIT(NL80211_IFTYPE_MESH_POINT);
- hw->wiphy->ps_default = false;
+ if (AR_SREV_5416(ah))
+ hw->wiphy->ps_default = false;
+ else
+ hw->wiphy->ps_default = true;
hw->queues = 4;
hw->max_rates = 4;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] compat: backport lockdep_assert_held
From: Hauke Mehrtens @ 2010-06-15 20:57 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.32.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.32.h b/include/linux/compat-2.6.32.h
index 3a41bd6..321a89a 100644
--- a/include/linux/compat-2.6.32.h
+++ b/include/linux/compat-2.6.32.h
@@ -94,6 +94,8 @@ struct dev_pm_ops name = { \
#define dev_to_sdio_func(d) container_of(d, struct sdio_func, dev)
+#define lockdep_assert_held(l) do { } while (0)
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32)) */
#endif /* LINUX_26_32_COMPAT_H */
--
1.7.0.4
^ permalink raw reply related
* [PATCH] compat-wireless: refresh patches:
From: Hauke Mehrtens @ 2010-06-15 20:56 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
make the patches apply against recent linux-next.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
Luis please remove all patches from linux-next-pending, because they are in
linux-next now.
patches/01-netdev.patch | 16 +++++---------
patches/03-rfkill.patch | 2 +-
patches/04-netns.patch | 2 +-
patches/08-rename-iwl4965-config.patch | 2 +-
patches/15-symbol-export-conflicts.patch | 2 +-
patches/17-netdev-queue.patch | 4 +-
patches/20-pcidev.patch | 2 +-
patches/22-multiqueue.patch | 4 +-
patches/25-multicast-list_head.patch | 32 +++++++++++++++---------------
9 files changed, 31 insertions(+), 35 deletions(-)
diff --git a/patches/01-netdev.patch b/patches/01-netdev.patch
index daa75b7..98cb477 100644
--- a/patches/01-netdev.patch
+++ b/patches/01-netdev.patch
@@ -45,7 +45,7 @@ without creating a headache on maintenance of the pathes.
retval = rndis_set_oid(usbdev, OID_GEN_CURRENT_PACKET_FILTER, &tmp,
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
-@@ -713,10 +713,16 @@ static const struct net_device_ops ieee8
+@@ -697,7 +697,12 @@ static const struct net_device_ops ieee8
static void ieee80211_if_setup(struct net_device *dev)
{
ether_setup(dev);
@@ -59,11 +59,7 @@ without creating a headache on maintenance of the pathes.
dev->destructor = free_netdev;
}
-+
- /*
- * Helper function to initialise an interface to a specific type.
- */
-@@ -728,7 +734,7 @@ static void ieee80211_setup_sdata(struct
+@@ -842,7 +847,7 @@ static void ieee80211_setup_sdata(struct
/* and set some type-dependent values */
sdata->vif.type = type;
@@ -72,7 +68,7 @@ without creating a headache on maintenance of the pathes.
sdata->wdev.iftype = type;
/* only monitor differs */
-@@ -751,7 +757,7 @@ static void ieee80211_setup_sdata(struct
+@@ -868,7 +873,7 @@ static void ieee80211_setup_sdata(struct
break;
case NL80211_IFTYPE_MONITOR:
sdata->dev->type = ARPHRD_IEEE80211_RADIOTAP;
@@ -81,7 +77,7 @@ without creating a headache on maintenance of the pathes.
sdata->u.mntr_flags = MONITOR_FLAG_CONTROL |
MONITOR_FLAG_OTHER_BSS;
break;
-@@ -932,6 +938,8 @@ int ieee80211_if_add(struct ieee80211_lo
+@@ -1049,6 +1054,8 @@ int ieee80211_if_add(struct ieee80211_lo
return -ENOMEM;
dev_net_set(ndev, wiphy_net(local->hw.wiphy));
@@ -90,7 +86,7 @@ without creating a headache on maintenance of the pathes.
ndev->needed_headroom = local->tx_headroom +
4*6 /* four MAC addresses */
+ 2 + 2 + 2 + 2 /* ctl, dur, seq, qos */
-@@ -940,6 +948,7 @@ int ieee80211_if_add(struct ieee80211_lo
+@@ -1057,6 +1064,7 @@ int ieee80211_if_add(struct ieee80211_lo
- ETH_HLEN /* ethernet hard_header_len */
+ IEEE80211_ENCRYPT_HEADROOM;
ndev->needed_tailroom = IEEE80211_ENCRYPT_TAILROOM;
@@ -98,7 +94,7 @@ without creating a headache on maintenance of the pathes.
ret = dev_alloc_name(ndev, ndev->name);
if (ret < 0)
-@@ -985,6 +994,10 @@ int ieee80211_if_add(struct ieee80211_lo
+@@ -1105,6 +1113,10 @@ int ieee80211_if_add(struct ieee80211_lo
if (ret)
goto fail;
diff --git a/patches/03-rfkill.patch b/patches/03-rfkill.patch
index fed0382..c7c242b 100644
--- a/patches/03-rfkill.patch
+++ b/patches/03-rfkill.patch
@@ -208,7 +208,7 @@ This would do the policing from within mac80211.
#include <net/cfg80211.h>
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
-@@ -2168,7 +2168,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw
+@@ -2171,7 +2171,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw
pCap->hw_caps |= ATH9K_HW_CAP_ENHANCEDPM;
diff --git a/patches/04-netns.patch b/patches/04-netns.patch
index 84deeab..d685f18 100644
--- a/patches/04-netns.patch
+++ b/patches/04-netns.patch
@@ -16,7 +16,7 @@ files...
};
/* internal helper: get rdev and dev */
-@@ -4294,7 +4296,9 @@ static int nl80211_wiphy_netns(struct sk
+@@ -4343,7 +4345,9 @@ static int nl80211_wiphy_netns(struct sk
err = cfg80211_switch_netns(rdev, net);
out_put_net:
diff --git a/patches/08-rename-iwl4965-config.patch b/patches/08-rename-iwl4965-config.patch
index 969227b..1329994 100644
--- a/patches/08-rename-iwl4965-config.patch
+++ b/patches/08-rename-iwl4965-config.patch
@@ -16,7 +16,7 @@ CONFIG_IWL4965 has to be set to y, to build correctly.
iwlagn-$(CONFIG_IWL5000) += iwl-1000.o
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
-@@ -4072,10 +4072,10 @@ static void __devexit iwl_pci_remove(str
+@@ -4080,10 +4080,10 @@ static void __devexit iwl_pci_remove(str
/* Hardware specific file defines the PCI IDs table for that hardware module */
static DEFINE_PCI_DEVICE_TABLE(iwl_hw_card_ids) = {
diff --git a/patches/15-symbol-export-conflicts.patch b/patches/15-symbol-export-conflicts.patch
index 10eb4f0..49d9b18 100644
--- a/patches/15-symbol-export-conflicts.patch
+++ b/patches/15-symbol-export-conflicts.patch
@@ -3,7 +3,7 @@ To avoid conflicts with the other export we rename our.
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
-@@ -2629,7 +2629,12 @@ void ieee80211_rx(struct ieee80211_hw *h
+@@ -2661,7 +2661,12 @@ void ieee80211_rx(struct ieee80211_hw *h
drop:
kfree_skb(skb);
}
diff --git a/patches/17-netdev-queue.patch b/patches/17-netdev-queue.patch
index 2389f22..1bbd079 100644
--- a/patches/17-netdev-queue.patch
+++ b/patches/17-netdev-queue.patch
@@ -14,7 +14,7 @@ The patch that introduced this on mac80211 was:
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
-@@ -1034,6 +1034,7 @@ void ieee80211_if_remove(struct ieee8021
+@@ -1153,6 +1153,7 @@ void ieee80211_if_remove(struct ieee8021
* Remove all interfaces, may only be called at hardware unregistration
* time because it doesn't do RCU-safe list removals.
*/
@@ -22,7 +22,7 @@ The patch that introduced this on mac80211 was:
void ieee80211_remove_interfaces(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata, *tmp;
-@@ -1050,6 +1051,22 @@ void ieee80211_remove_interfaces(struct
+@@ -1169,6 +1170,22 @@ void ieee80211_remove_interfaces(struct
mutex_unlock(&local->iflist_mtx);
unregister_netdevice_many(&unreg_list);
}
diff --git a/patches/20-pcidev.patch b/patches/20-pcidev.patch
index cb7f1ca..e892dcc 100644
--- a/patches/20-pcidev.patch
+++ b/patches/20-pcidev.patch
@@ -4,7 +4,7 @@ compat_is_pcie() when needed.
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
-@@ -79,7 +79,11 @@ static void ath_pci_bt_coex_prep(struct
+@@ -80,7 +80,11 @@ static void ath_pci_bt_coex_prep(struct
struct pci_dev *pdev = to_pci_dev(sc->dev);
u8 aspm;
diff --git a/patches/22-multiqueue.patch b/patches/22-multiqueue.patch
index c377355..24ac885 100644
--- a/patches/22-multiqueue.patch
+++ b/patches/22-multiqueue.patch
@@ -96,7 +96,7 @@ queue by using skb_set_queue_mapping(skb, 0) through ieee80211_tx_skb()
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
-@@ -1571,6 +1571,10 @@ static void ieee80211_xmit(struct ieee80
+@@ -1604,6 +1604,10 @@ static void ieee80211_xmit(struct ieee80
return;
}
@@ -107,7 +107,7 @@ queue by using skb_set_queue_mapping(skb, 0) through ieee80211_tx_skb()
ieee80211_set_qos_hdr(local, skb);
ieee80211_tx(sdata, skb, false);
rcu_read_unlock();
-@@ -2040,8 +2044,15 @@ void ieee80211_tx_pending(unsigned long
+@@ -2073,8 +2077,15 @@ void ieee80211_tx_pending(unsigned long
if (skb_queue_empty(&local->pending[i]))
list_for_each_entry_rcu(sdata, &local->interfaces, list)
diff --git a/patches/25-multicast-list_head.patch b/patches/25-multicast-list_head.patch
index 5fbc1eb..aed1ccb 100644
--- a/patches/25-multicast-list_head.patch
+++ b/patches/25-multicast-list_head.patch
@@ -576,9 +576,9 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
return hash.low | ((u64)hash.high << 32);
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
-@@ -1682,7 +1682,11 @@ struct ieee80211_ops {
- struct ieee80211_vif *vif,
- struct in_ifaddr *ifa_list);
+@@ -1689,7 +1689,11 @@ struct ieee80211_ops {
+ struct ieee80211_bss_conf *info,
+ u32 changed);
u64 (*prepare_multicast)(struct ieee80211_hw *hw,
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
struct netdev_hw_addr_list *mc_list);
@@ -606,7 +606,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
}
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
-@@ -101,14 +101,28 @@ static inline int drv_configure_arp_filt
+@@ -90,14 +90,28 @@ static inline void drv_bss_info_changed(
}
static inline u64 drv_prepare_multicast(struct ieee80211_local *local,
@@ -619,6 +619,12 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
{
u64 ret = 0;
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
+ trace_drv_prepare_multicast(local, mc_list->count);
++#else
++ trace_drv_prepare_multicast(local, mc_count);
++#endif
+
if (local->ops->prepare_multicast)
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
ret = local->ops->prepare_multicast(&local->hw, mc_list);
@@ -627,17 +633,11 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
+ mc_list);
+#endif
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
- trace_drv_prepare_multicast(local, mc_list->count, ret);
-+#else
-+ trace_drv_prepare_multicast(local, mc_count, ret);
-+#endif
+ trace_drv_return_u64(local, ret);
- return ret;
- }
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
-@@ -665,7 +665,12 @@ struct ieee80211_local {
+@@ -668,7 +668,12 @@ struct ieee80211_local {
struct work_struct recalc_smps;
/* aggregated multicast list */
@@ -652,7 +652,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
-@@ -403,7 +403,12 @@ static int ieee80211_stop(struct net_dev
+@@ -390,7 +390,12 @@ static int ieee80211_stop(struct net_dev
netif_addr_lock_bh(dev);
spin_lock_bh(&local->filter_lock);
@@ -665,7 +665,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
spin_unlock_bh(&local->filter_lock);
netif_addr_unlock_bh(dev);
-@@ -586,7 +591,12 @@ static void ieee80211_set_multicast_list
+@@ -570,7 +575,12 @@ static void ieee80211_set_multicast_list
sdata->flags ^= IEEE80211_SDATA_PROMISC;
}
spin_lock_bh(&local->filter_lock);
@@ -680,7 +680,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
}
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
-@@ -71,7 +71,11 @@ void ieee80211_configure_filter(struct i
+@@ -72,7 +72,11 @@ void ieee80211_configure_filter(struct i
spin_lock_bh(&local->filter_lock);
changed_flags = local->filter_flags ^ new_flags;
@@ -692,7 +692,7 @@ This also backport commit 2f787b0b76bf5de2eaa3ca3a29d89123ae03c856
spin_unlock_bh(&local->filter_lock);
/* be a bit nasty */
-@@ -447,9 +451,11 @@ struct ieee80211_hw *ieee80211_alloc_hw(
+@@ -448,9 +452,11 @@ struct ieee80211_hw *ieee80211_alloc_hw(
local->uapsd_max_sp_len = IEEE80211_DEFAULT_MAX_SP_LEN;
INIT_LIST_HEAD(&local->interfaces);
--
1.7.0.4
^ permalink raw reply related
* Re: radiotap rate no longer supported in mac80211?
From: Pavel Roskin @ 2010-06-15 20:18 UTC (permalink / raw)
To: Steve deRosier; +Cc: linux-wireless
In-Reply-To: <AANLkTileP2BMsZUsA-NigDcmVcAmXn6KNw0R1vMzSgYw@mail.gmail.com>
On Mon, 2010-06-14 at 15:18 -0700, Steve deRosier wrote:
> I'm trying to support per-packet setting of rate on a packet injection
> via the radiotap header. In an earlier version of mac80211 (around
> 2.6.26), there was code in __ieee80211_parse_tx_radiotap (in
> net/mac80211/tx.c) to support the use of the the rate element from the
> radiotap header. In current versions of wireless-testing, most of the
> code here has been removed and only the flags are parsed.
>
> I want to return the IEEE80211_RADIOTAP_RATE portion of this function
> in order to support this. So the questions:
> 1. Why were all fields other than IEEE80211_RADIOTAP_FLAGS removed?
> 2. Would it be OK for me to prepare and submit a patch to restore the
> rate functionality?
I posted a patch that would add rate and retry flags:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/47441
I didn't see any interest in the patch. Perhaps injecting packets at a
specific rate in not particularly needed.
Also, the patch is somewhat inelegant because of the requirement to
specify the rate when the retry count is specified.
mac80211 has an array of rates with corresponding retry counts. The
radiotap standard has one rate and one retry count. This doesn't map
well to the mac80211 approach. Supporting the retry count without the
rate would require some tricky logic, and I don't know if anyone needs
that.
I don't feel good about pushing a patch that makes the code more complex
without knowing the use case.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] p54usb: Remove duplicate Medion MD40900 device id
From: John W. Linville @ 2010-06-15 19:46 UTC (permalink / raw)
To: Leann Ogasawara; +Cc: Larry Finger, flamingice, linux-wireless, Ben Collins
In-Reply-To: <1276624745.6127.61.camel@emiko>
On Tue, Jun 15, 2010 at 10:59:05AM -0700, Leann Ogasawara wrote:
> On Mon, 2010-06-14 at 14:55 -0400, John W. Linville wrote:
> > So, I guess you are concerned about the groupings because of the
> > different firmwares or something like that? Perhaps a comment that
> > says "this could be a version 2 device" is just as handy? Since the
> > driver prints the name of the firmware it wants, is there any real
> > need for grouping the IDs?
> >
> > OTOH, is there any actual harm from the duplicate entry? It "seems"
> > wrong to me too, but I guess it does no harm...?
>
> I don't believe there is any harm from the duplicate entry, it just
> seemed unnecessary.
>
> > Leann and/or Ben, was this just tidying-up? I'm guessing there wasn't
> > an actual bug involved?
>
> Indeed, this was just a patch we'd been carrying to tidy things up.
> There was no actual bug involved. I'd be happy to send a v2 of the
> patch which comments out the duplicate entry and adds a note as to why.
> Or I'd be fine just leaving the code as is and we'll drop the patch
> we're carrying locally in Ubuntu.
FWIW, I like the 'comment-out and add a note' option.
Thanks!
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] ath9k: Modify LED blinking pattern during wifi activity.
From: John W. Linville @ 2010-06-15 19:51 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linux-wireless
In-Reply-To: <1276579217-6837-1-git-send-email-vnatarajan@atheros.com>
On Tue, Jun 15, 2010 at 10:50:17AM +0530, Vivek Natarajan wrote:
> Some vendors require the LED to be ON always irrespective of any
> radio activity. Introducing a module parameter to enable this,
> so that one can choose between always on or led blink during
> activity.
>
> Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Any particular reason the always-on behaviour is the default?
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] p54usb: Remove duplicate Medion MD40900 device id
From: Leann Ogasawara @ 2010-06-15 17:59 UTC (permalink / raw)
To: John W. Linville; +Cc: Larry Finger, flamingice, linux-wireless, Ben Collins
In-Reply-To: <20100614185549.GB2216@tuxdriver.com>
On Mon, 2010-06-14 at 14:55 -0400, John W. Linville wrote:
> On Thu, Jun 10, 2010 at 06:23:19PM -0500, Larry Finger wrote:
> > On 06/10/2010 05:28 PM, Leann Ogasawara wrote:
> > > The Medion MD40900 device id [0x0cde, 0x0006] is defined twice. Remove
> > > the duplicate.
> > >
> > > Originally-by: Ben Collins <ben.collins@ubuntu.com>
> > > Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
> > > ---
> > > drivers/net/wireless/p54/p54usb.c | 1 -
> > > 1 files changed, 0 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
> > > index 7307325..d6d8713 100644
> > > --- a/drivers/net/wireless/p54/p54usb.c
> > > +++ b/drivers/net/wireless/p54/p54usb.c
> > > @@ -69,7 +69,6 @@ static struct usb_device_id p54u_table[] __devinitdata = {
> > > {USB_DEVICE(0x0915, 0x2002)}, /* Cohiba Proto board */
> > > {USB_DEVICE(0x0baf, 0x0118)}, /* U.S. Robotics U5 802.11g Adapter*/
> > > {USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
> > > - {USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
> > > {USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
> > > {USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
> > > {USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
> >
> > Do you know for certain that this device is a Version 1 chip, and for
> > that reason, you are removing it from the version 2 list?
> >
> > If not, NACK.
>
> So, I guess you are concerned about the groupings because of the
> different firmwares or something like that? Perhaps a comment that
> says "this could be a version 2 device" is just as handy? Since the
> driver prints the name of the firmware it wants, is there any real
> need for grouping the IDs?
>
> OTOH, is there any actual harm from the duplicate entry? It "seems"
> wrong to me too, but I guess it does no harm...?
I don't believe there is any harm from the duplicate entry, it just
seemed unnecessary.
> Leann and/or Ben, was this just tidying-up? I'm guessing there wasn't
> an actual bug involved?
Indeed, this was just a patch we'd been carrying to tidy things up.
There was no actual bug involved. I'd be happy to send a v2 of the
patch which comments out the duplicate entry and adds a note as to why.
Or I'd be fine just leaving the code as is and we'll drop the patch
we're carrying locally in Ubuntu.
Thanks,
Leann
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: Gábor Stefanik @ 2010-06-15 17:40 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Kouhei Sutou, Stephen Chen, David Quan, linux-wireless,
Michael Green
In-Reply-To: <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
On Sun, Jun 13, 2010 at 10:23 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Note: this e-mail is on a public mailing list!
>
> On Sat, Jun 12, 2010 at 10:52 PM, Kouhei Sutou <kou@clear-code.com> wrote:
>> Hi,
>>
>> I'm using PLANEX GW-US54GXS (2019:5303) and it works with
>> the attached patch. Could you consider to merge the attached
>> patch?
>>
>> Problem: GW-US54GXS uses zd1211rw but zd1211rw doesn't have
>> a regulatory domain reported by GW-US54GXS (0x49).
>>
>> Solutions:
>>
>> (1) add a new regulatory domain (0x49). Here is a patch to
>> use the approach:
>
> Stephen, David, does 0x49 map to JP for zd1211 ? Are there other ones?
> Here is our list so far:
>
> #define ZD_REGDOMAIN_FCC 0x10
> #define ZD_REGDOMAIN_IC 0x20
> #define ZD_REGDOMAIN_ETSI 0x30
> #define ZD_REGDOMAIN_SPAIN 0x31
> #define ZD_REGDOMAIN_FRANCE 0x32
> #define ZD_REGDOMAIN_JAPAN_ADD 0x40
> #define ZD_REGDOMAIN_JAPAN 0x41
>
> This is what they map to:
>
> static struct zd_reg_alpha2_map reg_alpha2_map[] = {
> { ZD_REGDOMAIN_FCC, "US" },
> { ZD_REGDOMAIN_IC, "CA" },
> { ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
Note: This one is causing me problems here in Hungary, as it keeps
resetting my regdomain to Germany. I believe we should implement
allowing the user to choose regdomain in this case, but allowing only
regdomains in ETSI.
> { ZD_REGDOMAIN_JAPAN, "JP" },
> { ZD_REGDOMAIN_JAPAN_ADD, "JP" },
> { ZD_REGDOMAIN_SPAIN, "ES" },
> { ZD_REGDOMAIN_FRANCE, "FR" },
> };
>
> Kouhei, if no regulatory domain is found, instead we should world
> roam, we cannot allow letting the user change regulatory domains at
> their whim. We can, however let them choose one to help compliance,
> but you can only help compliance once you know your actual regulatory
> domain.
>
> Luis
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: Luis R. Rodriguez @ 2010-06-15 15:22 UTC (permalink / raw)
To: Kouhei Sutou; +Cc: Stephen.Chen, David.Quan, linux-wireless, Michael.Green
In-Reply-To: <20100615.232558.867740727379709943.kou@clear-code.com>
On Tue, Jun 15, 2010 at 7:25 AM, Kouhei Sutou <kou@clear-code.com> wrote:
> Hi,
>
> In <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
> "Re: [PATCH] zd1211rw: ignore unknown regulatory domain." on Sun, 13 Jun 2010 13:23:20 -0700,
> "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>
>>> I'm using PLANEX GW-US54GXS (2019:5303) and it works with
>>> the attached patch. Could you consider to merge the attached
>>> patch?
>>>
>>> Problem: GW-US54GXS uses zd1211rw but zd1211rw doesn't have
>>> a regulatory domain reported by GW-US54GXS (0x49).
>>>
>>> Solutions:
>>>
>>> (1) add a new regulatory domain (0x49). Here is a patch to
>>> use the approach:
>>
>> Stephen, David, does 0x49 map to JP for zd1211 ? Are there other ones?
>> Here is our list so far:
> ...
>> Kouhei, if no regulatory domain is found, instead we should world
>> roam, we cannot allow letting the user change regulatory domains at
>> their whim. We can, however let them choose one to help compliance,
>> but you can only help compliance once you know your actual regulatory
>> domain.
>
> Luis, thanks for your input.
> It seems that we can't use GW-US54GXS until 0x49 regulatory
> domain is registered to zd1211rw. Is it right?
>
> If it is right, what I can do for GW-US54GXS? Should I wait
> a response from Stephen and/or David?
We spoke and 0x49 - > JP is ok, can you send a patch for that?
Luis
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Kalle Valo @ 2010-06-15 14:26 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, Sebastian Smolorz, linux-wireless,
Marcel Holtmann
In-Reply-To: <1276609006.3648.233.camel@jlt3.sipsolutions.net>
On 15 June 2010 16:36, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
>> On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
>> > the at76c50x-usb driver fails to authenticate with an AP.
>
> We need more information on how it fails.
I debugged this a long time ago. The problem is that firmware's
CMD_JOIN only works if bssid is correct one. I remember trying
ff:ff:ff:ff:ff:ff, but that didn't work for some reason. The join
command needs to be sent before association, otherwise transmission
won't work at all. And if I use a random bssid the firmware will
filter the replies. But I tested this a long time ago, I might
remember something wrong.
I was thinking a hack which would get bssid from association frames
and then send CMD_JOIN, before the association frame. IMHO no need to
change mac80211 because of this old hardware.
Kalle
^ permalink raw reply
* Re: [PATCH] zd1211rw: ignore unknown regulatory domain.
From: Kouhei Sutou @ 2010-06-15 14:25 UTC (permalink / raw)
To: mcgrof; +Cc: Stephen.Chen, David.Quan, linux-wireless, Michael.Green
In-Reply-To: <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
Hi,
In <AANLkTinEMAQu33Tlv81-Cdx9fLZK-a-7uJlbAo7te2_w@mail.gmail.com>
"Re: [PATCH] zd1211rw: ignore unknown regulatory domain." on Sun, 13 Jun 2010 13:23:20 -0700,
"Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
>> I'm using PLANEX GW-US54GXS (2019:5303) and it works with
>> the attached patch. Could you consider to merge the attached
>> patch?
>>
>> Problem: GW-US54GXS uses zd1211rw but zd1211rw doesn't have
>> a regulatory domain reported by GW-US54GXS (0x49).
>>
>> Solutions:
>>
>> (1) add a new regulatory domain (0x49). Here is a patch to
>> use the approach:
>
> Stephen, David, does 0x49 map to JP for zd1211 ? Are there other ones?
> Here is our list so far:
...
> Kouhei, if no regulatory domain is found, instead we should world
> roam, we cannot allow letting the user change regulatory domains at
> their whim. We can, however let them choose one to help compliance,
> but you can only help compliance once you know your actual regulatory
> domain.
Luis, thanks for your input.
It seems that we can't use GW-US54GXS until 0x49 regulatory
domain is registered to zd1211rw. Is it right?
If it is right, what I can do for GW-US54GXS? Should I wait
a response from Stephen and/or David?
Thanks,
--
kou
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Johannes Berg @ 2010-06-15 14:21 UTC (permalink / raw)
To: Sebastian Smolorz
Cc: John W. Linville, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <201006151611.56061.Sebastian.Smolorz@gmx.de>
On Tue, 2010-06-15 at 16:11 +0200, Sebastian Smolorz wrote:
> Johannes Berg wrote:
> > On Tue, 2010-06-15 at 15:49 +0200, Sebastian Smolorz wrote:
> > > Johannes Berg wrote:
> > > > On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> > > > > On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > > > > > Hi,
> > > > > >
> > > > > > the at76c50x-usb driver fails to authenticate with an AP.
> > > >
> > > > We need more information on how it fails.
> > >
> > > The problem is that the following if-statement is never true:
> Hm, for me it works. Alternatively:
> http://lxr.free-electrons.com/source/drivers/net/wireless/at76c50x-usb.c#L1986
That works. However, that if statement _will_ be true?
I suppose at76 has some issue where it won't send out frames before
knowing the BSSID?
johannes
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Sebastian Smolorz @ 2010-06-15 14:11 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <1276610211.3648.234.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Tue, 2010-06-15 at 15:49 +0200, Sebastian Smolorz wrote:
> > Johannes Berg wrote:
> > > On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> > > > On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > > > > Hi,
> > > > >
> > > > > the at76c50x-usb driver fails to authenticate with an AP.
> > >
> > > We need more information on how it fails.
> >
> > The problem is that the following if-statement is never true:
> >
> > http://lxr.linux.no/#linux+v2.6.34/drivers/net/wireless/at76c50x-usb.c#L1986
>
> That link doesn't work.
Hm, for me it works. Alternatively:
http://lxr.free-electrons.com/source/drivers/net/wireless/at76c50x-usb.c#L1986
Anyway, it is line 1986 in drivers/net/wireless/at76c50x-usb.c, kernel version 2.6.34.
--
Sebastian
^ permalink raw reply
* Re: [RFC] Changes in mac80211 to make at76c50x-usb working again
From: Johannes Berg @ 2010-06-15 13:56 UTC (permalink / raw)
To: Sebastian Smolorz
Cc: John W. Linville, kalle.valo, linux-wireless, Marcel Holtmann
In-Reply-To: <201006151549.41963.Sebastian.Smolorz@gmx.de>
On Tue, 2010-06-15 at 15:49 +0200, Sebastian Smolorz wrote:
> Johannes Berg wrote:
> > On Tue, 2010-06-15 at 09:26 -0400, John W. Linville wrote:
> > > On Tue, Jun 15, 2010 at 02:16:36PM +0200, Sebastian Smolorz wrote:
> > > > Hi,
> > > >
> > > > the at76c50x-usb driver fails to authenticate with an AP.
> >
> > We need more information on how it fails.
>
> The problem is that the following if-statement is never true:
>
> http://lxr.linux.no/#linux+v2.6.34/drivers/net/wireless/at76c50x-usb.c#L1986
That link doesn't work.
johannes
^ permalink raw reply
* Re: [PATCH 1/3] Libertas: cfg80211 support
From: Holger Schurig @ 2010-06-15 13:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: dkiran, linux-wireless
In-Reply-To: <1276519238.3926.20.camel@jlt3.sipsolutions.net>
I'm o.k. with being mentioned in the commit log message.
After all, I *intended* that someone picks this up and continued to work on
it, while I'm off to other projects due to my job. That makes me only able to
work in an on-and-off style with kernel stuff.
^ 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