Linux wireless drivers development
 help / color / mirror / Atom feed
* [PATCH 1/2] net: introduce NETDEV_POST_INIT notifier
From: Johannes Berg @ 2009-09-28  8:21 UTC (permalink / raw)
  To: netdev; +Cc: linux-wireless, Hugh Dickins

For various purposes including a wireless extensions
bugfix, we need to hook into the netdev creation before
before netdev_register_kobject(). This will also ease
doing the dev type assignment that Marcel was working
on for cfg80211 drivers w/o touching them all.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
I decided that it doesn't make a lot of sense to be after ndo_init but
before the other name/... checks.

 include/linux/notifier.h |    1 +
 net/core/dev.c           |    5 +++++
 2 files changed, 6 insertions(+)

--- wireless-testing.orig/include/linux/notifier.h	2009-09-28 10:14:54.000000000 +0200
+++ wireless-testing/include/linux/notifier.h	2009-09-28 10:16:07.000000000 +0200
@@ -201,6 +201,7 @@ static inline int notifier_to_errno(int 
 #define NETDEV_PRE_UP		0x000D
 #define NETDEV_BONDING_OLDTYPE  0x000E
 #define NETDEV_BONDING_NEWTYPE  0x000F
+#define NETDEV_POST_INIT	0x0010
 
 #define SYS_DOWN	0x0001	/* Notify of system down */
 #define SYS_RESTART	SYS_DOWN
--- wireless-testing.orig/net/core/dev.c	2009-09-28 10:14:54.000000000 +0200
+++ wireless-testing/net/core/dev.c	2009-09-28 10:20:46.000000000 +0200
@@ -4785,6 +4785,11 @@ int register_netdevice(struct net_device
 	if (dev->features & NETIF_F_SG)
 		dev->features |= NETIF_F_GSO;
 
+	ret = call_netdevice_notifiers(NETDEV_POST_INIT, dev);
+	ret = notifier_to_errno(ret);
+	if (ret)
+		goto err_uninit;
+
 	netdev_initialize_kobject(dev);
 	ret = netdev_register_kobject(dev);
 	if (ret)



^ permalink raw reply

* Re: Massive packet loss with ath9k, AR9280, hostapd in 802.11n mode
From: Luis R. Rodriguez @ 2009-09-28  8:17 UTC (permalink / raw)
  To: Holger Schurig; +Cc: Rene Mayrhofer, Bob Copeland, linux-wireless
In-Reply-To: <200909280956.23887.hs4233@mail.mn-solutions.de>

On Mon, Sep 28, 2009 at 12:56 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
>> [ 1698.498801] ath: EEPROM regdomain: 0x0
>>
>> Does this indicate that the EEPROM is locked to country code
>> 0x0 (whatever that is, probably US)? "iw reg" doesn't seem to
>> change anything:
>
> Yep, that's the case.
>
> However, "iw XXX reg set XX" should *STILL* change some things,

For atheros cards 'iw reg set XX' will help compliance further, it
will never enable new channels.

> Regarding the wrong info in your EEPROM: check the README file
> from ath_info (svn co
> http://madwifi-project.org/svn/ath_info/trunk).
>
> I currently have the feeling, that about 50% of all WLAN cards
> bought in Germany have a "wrong" EEPROM country. Maybe importers
> simply don't care about this.

The regulatory domain on most cards actually ship with a world
regulatory domain, if they ship with a different country regulatory
domain that is up to the manufacturer not Atheros, but most likely
they are actually not incorrect. When you do have more channels than
you are supposed you can restrict this further with 'iw reg set' but
enabling new channels is not something that is that easy from a
regulatory perspective which is why this is not something that is
done. A manufacturer typically tests only the channels enabled on
their regulatory domain and programs the EEPROM with CTL information
for those settings, not for other regulatory domains. Modifying the
EEPROM is something up to manufacturers to do under current testing
scenarios and due to current legislation, this is not supported nor it
is intended to be.

If world roaming we provide world roaming enhancements to help with
the default passive scan an no beaconing on some channels. This
currently consists of lifting passive scan flags and no-beaconing
flags from channels you see APs on. This should increase the time it
takes to scan for your AP after the first time or for other APs on
that channel. It also means you can start hostapd or adhoc on these
channels.

  Luis

^ permalink raw reply

* Re: Massive packet loss with ath9k, AR9280, hostapd in 802.11n mode
From: Rene Mayrhofer @ 2009-09-28  8:07 UTC (permalink / raw)
  To: Holger Schurig; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <200909280956.23887.hs4233@mail.mn-solutions.de>

Am Montag, 28. September 2009 09:56:23 schrieb Holger Schurig:
> Oh, and what I'm not yet getting: how can a wrong country setting
> lead to so much packet-loss?

I don't think these two are connected - the erroneous country setting is 
probably just the reason why I can't try the 5GHz band and thus can't verify 
if the packet loss occurs there as well.
Thanks for your explanations - I will try to get CRDA and regdb running and 
will try again with the 5GHz band.


One other thing comes to mind: this 802.11n card has two antenna connectors, 
and both are actually connected to pigtails (which are probably not mounted in 
correct distance according to wavelenght, but that shouldn't cause packet 
loss). However, it might be possible that one of the antennas has a poor 
connection, is misaligned with the clients, or whatever. What I couldn't find 
in ath9k is an option for user-controlled antenna diversity (comparable to 
madwifi). How can I selectively disable antenna usage and/or set them for RX or 
TX mode only?

best regards,
Rene

^ permalink raw reply

* Re: Massive packet loss with ath9k, AR9280, hostapd in 802.11n mode
From: Holger Schurig @ 2009-09-28  7:56 UTC (permalink / raw)
  To: Rene Mayrhofer; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <200909252329.01897.rene.mayrhofer@gibraltar.at>

> [ 1698.498801] ath: EEPROM regdomain: 0x0                                                                                             
> 
> Does this indicate that the EEPROM is locked to country code
> 0x0 (whatever that is, probably US)? "iw reg" doesn't seem to
> change anything: 

Yep, that's the case.

However, "iw XXX reg set XX" should *STILL* change some things, 
so I guess that crda/regdb isn't still correctly installed. And 
you should still see something in your "dmesg" output. Hey, 
even "COUNTRY=AT crda" should change/produce something, e.g. 
check "dmesg" and "iw list".

However, I've now switched my kernel to no longer include

> [ 1686.542910] cfg80211: Using static regulatory domain info

You probably should either use CRDA ("the new way") or some 
static reg info in your kernel. I personally opted for CRDA, as 
this gives me more correct channel settings.


Regarding the wrong info in your EEPROM: check the README file 
from ath_info (svn co 
http://madwifi-project.org/svn/ath_info/trunk).

I currently have the feeling, that about 50% of all WLAN cards 
bought in Germany have a "wrong" EEPROM country. Maybe importers 
simply don't care about this.



Oh, and what I'm not yet getting: how can a wrong country setting 
lead to so much packet-loss?

^ permalink raw reply

* Re: [PATCH 2/2] cfg80211: fix wireless handlers assignment
From: Johannes Berg @ 2009-09-28  7:54 UTC (permalink / raw)
  To: Hugh Dickins; +Cc: netdev, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909272237190.4098@sister.anvils>

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Sun, 2009-09-27 at 22:50 +0100, Hugh Dickins wrote:
> On Sun, 27 Sep 2009, Hugh Dickins wrote:
> > 
> > I've experimented by moving your NETDEV_PRE_INIT hunk later in the
> > sequence, just before the netdev_initialize_kobject(dev) (so I also
> > changed the "goto out" to "goto err_uninit"): both* machines then boot
> > correctly, and this mail leaves me wirelessly.
> > 
> > I'll now experiment to see how early I can move that hunk.
> 
> Both machines boot (and do wireless) correctly with your NETDEV_PRE_INIT
> hunk placed just after the ndo_init block, instead of just before where
> you placed it.  That's i386 kernels on both.
> 
> But curiouser and curiouser... the laptop can do 64-bit, so I built
> my 64-bit kernel, and went through the motions to reproduce the
> early boot crash with the patch as you had it: but the x86_64 kernel
> boots (and does wireless) correctly with the NETDEV_PRE_INIT hunk
> just where you placed it, before the ndo_init block.
> 
> Perhaps there's a difference in the 32- and 64-bit startup sequence
> with respect to notifiers; or perhaps your change tickles another bug.
> I don't know, I'm turning off now.

Interesting, thanks for taking the time to test. I'll post an updated
patchset that calls it POST_INIT and moves it to there.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* Re: [ath5k-devel] Fw: Cannot register at bugzilla (bugreport added) [ ath5k bugreport ]
From: Holger Schurig @ 2009-09-28  7:42 UTC (permalink / raw)
  To: ath5k-devel
  Cc: Florian Mickler, Hans-J. Ullrich, Jiri Slaby, linux-wireless,
	John W. Linville, netdev
In-Reply-To: <20090925191524.7b2b228c@schatten>

> There are already other reports of this problem in discussion 
forums.
> It seems, the old madwifi-driver works better with dhcp - so 
people say.

I cannot second that. For me, ath5k works perfectly with DHCP,
with WEXT ("iwconfig") and NL80211 ("iw") and with
wpa_supplicant.

DHCP was NEVER an issue.

-- 
http://www.holgerschurig.de

^ permalink raw reply

* Re: [PATCH 2/2] cfg80211: fix wireless handlers assignment
From: Johannes Berg @ 2009-09-28  7:41 UTC (permalink / raw)
  To: Hugh Dickins; +Cc: netdev, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909272139280.4061@sister.anvils>

[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]

On Sun, 2009-09-27 at 21:58 +0100, Hugh Dickins wrote:

> This 2/2 patch does indeed work: many thanks.  But...

... it won't fix anything by itself.

> > This should fix the regression Hugh reported (of course requires the
> > other patch which unfortunately I forgot to CC you, Hugh, I'll send you
> > a copy in private).
> 
> ... the 1/2 patch has a couple of problems.
> 
> The trivial problem is that include/linux/notifier.h in Linus's git has
> #define NETDEV_PRE_UP		0x000D
> #define NETDEV_BONDING_OLDTYPE  0x000E
> #define NETDEV_BONDING_NEWTYPE  0x000F
> 
> So it rejects the patch you posted: I changed it to add
> #define NETDEV_PRE_INIT		0x0010
> just after the NETDEV_BONDING_NEWTYPE line.

Right, that's fixable, I was evidently working against the wrong tree.

> The more serious problem is that it stops both my machines from booting,
> too early for framebuffer to show any messages, but vga=normal shows a
> long stacktrace scrolling offscreen, with some notifier stuff in there.

Ahrg. That's strange.

> I've experimented by moving your NETDEV_PRE_INIT hunk later in the
> sequence, just before the netdev_initialize_kobject(dev) (so I also
> changed the "goto out" to "goto err_uninit"): both* machines then boot
> correctly, and this mail leaves me wirelessly.
> 
> I'll now experiment to see how early I can move that hunk.

Interesting. Thanks for that; must be some notifier that doesn't expect
to be run. For all I care, it can be right before the kobject stuff, so
maybe that makes more sense as it's a fairly last-minute fix now. Of
course then it should be POST_INIT or PRE_REGISTER I suppose.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* Re: [PATCH]: nl80211: report age of scan results
From: Holger Schurig @ 2009-09-28  7:14 UTC (permalink / raw)
  To: Jouni Malinen; +Cc: John Linville, linux-wireless, Johannes Berg
In-Reply-To: <20090926081438.GA20788@jm.kir.nu>

On Saturday 26 September 2009 10:14:38 Jouni Malinen wrote:
> This would depend on your use case.. I would have preferred
> absolute time since it allows the application to filter out
> entries that were not updated after the last scan request,
> i.e., to figure out which entries were found based on the last
> scan request (or well, based on frames received during this
> time). 

Oh, we can still easily change that to an absolute time, if you 
prefer. It's not yet upstream, AFAIK.



With the current patch, I'll still ignore scan results with an 
age > 3 seconds. To make a decision about "which AP should I use 
next", I don't need to know if the result was from this scan 
request, or from the one before, or from a shell script doing

   while true; do 
     iw xxx scan trigger freq 2412 essid SOME_AP
     sleep 0.5
   done

-- 
http://www.holgerschurig.de

^ permalink raw reply

* [PATCH] atheros: define a common priv struct
From: Luis R. Rodriguez @ 2009-09-28  6:54 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, devel, ath9k-devel, Luis R. Rodriguez

hw code should never use private driver data, but
sometimes we need a backpointer so just stuff it on
the common ath struct.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---

With this and some changes to ath9k_htc we can now start
talking to the target on ar9271. I'll synch up ath9k_htc
git tree with these changes, if you compile your kernel
with all pending patches + this one you should be able
to start playing with ath9k_htc -- oh and a new firmware
was needed, seems I had a dud firmware file. I'll update
that soon also on the athfw2lnx.git tree:

git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/athfw2lnx.git

 drivers/net/wireless/ath/ath.h         |    1 +
 drivers/net/wireless/ath/ath9k/debug.c |    7 +++--
 drivers/net/wireless/ath/ath9k/hw.h    |    1 -
 drivers/net/wireless/ath/ath9k/main.c  |   37 +++++++++++++++++++------------
 drivers/net/wireless/ath/ath9k/pci.c   |    9 ++-----
 5 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index e0341fe..b6cd752 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -56,6 +56,7 @@ struct ath_bus_ops {
 
 struct ath_common {
 	void *ah;
+	void *priv;
 	struct ieee80211_hw *hw;
 	int debug_mask;
 
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 352914c..25ae88e 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -562,8 +562,8 @@ static const struct file_operations fops_xmit = {
 
 int ath9k_init_debug(struct ath_hw *ah)
 {
-	struct ath_softc *sc = ah->ah_sc;
-	struct ath_common *common = ath9k_hw_common(sc->sc_ah);
+	struct ath_common *common = ath9k_hw_common(ah);
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 
 	common->debug_mask = ath9k_debug;
 
@@ -620,7 +620,8 @@ err:
 
 void ath9k_exit_debug(struct ath_hw *ah)
 {
-	struct ath_softc *sc = ah->ah_sc;
+	struct ath_common *common = ath9k_hw_common(ah);
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 
 	debugfs_remove(sc->debug.debugfs_xmit);
 	debugfs_remove(sc->debug.debugfs_wiphy);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index f782c1a..cdaec52 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -450,7 +450,6 @@ struct ath_gen_timer_table {
 
 struct ath_hw {
 	struct ieee80211_hw *hw;
-	struct ath_softc *ah_sc;
 	struct ath_common common;
 	struct ath9k_hw_version hw_version;
 	struct ath9k_ops_config config;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 2278dcb..86374ad 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1438,17 +1438,22 @@ static void ath9k_gen_timer_start(struct ath_hw *ah,
 				  u32 timer_next,
 				  u32 timer_period)
 {
+	struct ath_common *common = ath9k_hw_common(ah);
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
+
 	ath9k_hw_gen_timer_start(ah, timer, timer_next, timer_period);
 
-	if ((ah->ah_sc->imask & ATH9K_INT_GENTIMER) == 0) {
+	if ((sc->imask & ATH9K_INT_GENTIMER) == 0) {
 		ath9k_hw_set_interrupts(ah, 0);
-		ah->ah_sc->imask |= ATH9K_INT_GENTIMER;
-		ath9k_hw_set_interrupts(ah, ah->ah_sc->imask);
+		sc->imask |= ATH9K_INT_GENTIMER;
+		ath9k_hw_set_interrupts(ah, sc->imask);
 	}
 }
 
 static void ath9k_gen_timer_stop(struct ath_hw *ah, struct ath_gen_timer *timer)
 {
+	struct ath_common *common = ath9k_hw_common(ah);
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 	struct ath_gen_timer_table *timer_table = &ah->hw_gen_timers;
 
 	ath9k_hw_gen_timer_stop(ah, timer);
@@ -1456,8 +1461,8 @@ static void ath9k_gen_timer_stop(struct ath_hw *ah, struct ath_gen_timer *timer)
 	/* if no timer is enabled, turn off interrupt mask */
 	if (timer_table->timer_mask.val == 0) {
 		ath9k_hw_set_interrupts(ah, 0);
-		ah->ah_sc->imask &= ~ATH9K_INT_GENTIMER;
-		ath9k_hw_set_interrupts(ah, ah->ah_sc->imask);
+		sc->imask &= ~ATH9K_INT_GENTIMER;
+		ath9k_hw_set_interrupts(ah, sc->imask);
 	}
 }
 
@@ -1554,28 +1559,32 @@ static int ath_init_btcoex_timer(struct ath_softc *sc)
 static void ath9k_iowrite32(void *hw_priv, u32 val, u32 reg_offset)
 {
 	struct ath_hw *ah = (struct ath_hw *) hw_priv;
+	struct ath_common *common = ath9k_hw_common(ah);
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 
 	if (ah->config.serialize_regmode == SER_REG_MODE_ON) {
 		unsigned long flags;
-		spin_lock_irqsave(&ah->ah_sc->sc_serial_rw, flags);
-		iowrite32(val, ah->ah_sc->mem + reg_offset);
-		spin_unlock_irqrestore(&ah->ah_sc->sc_serial_rw, flags);
+		spin_lock_irqsave(&sc->sc_serial_rw, flags);
+		iowrite32(val, sc->mem + reg_offset);
+		spin_unlock_irqrestore(&sc->sc_serial_rw, flags);
 	} else
-		iowrite32(val, ah->ah_sc->mem + reg_offset);
+		iowrite32(val, sc->mem + reg_offset);
 }
 
 static unsigned int ath9k_ioread32(void *hw_priv, u32 reg_offset)
 {
 	struct ath_hw *ah = (struct ath_hw *) hw_priv;
+	struct ath_common *common = ath9k_hw_common(ah);
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 	u32 val;
 
 	if (ah->config.serialize_regmode == SER_REG_MODE_ON) {
 		unsigned long flags;
-		spin_lock_irqsave(&ah->ah_sc->sc_serial_rw, flags);
-		val = ioread32(ah->ah_sc->mem + reg_offset);
-		spin_unlock_irqrestore(&ah->ah_sc->sc_serial_rw, flags);
+		spin_lock_irqsave(&sc->sc_serial_rw, flags);
+		val = ioread32(sc->mem + reg_offset);
+		spin_unlock_irqrestore(&sc->sc_serial_rw, flags);
 	} else
-		val = ioread32(ah->ah_sc->mem + reg_offset);
+		val = ioread32(sc->mem + reg_offset);
 	return val;
 }
 
@@ -1618,7 +1627,6 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
 		goto bad_no_ah;
 	}
 
-	ah->ah_sc = sc;
 	ah->hw_version.devid = devid;
 	ah->hw_version.subsysid = subsysid;
 	sc->sc_ah = ah;
@@ -1628,6 +1636,7 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
 	common->bus_ops = bus_ops;
 	common->ah = ah;
 	common->hw = sc->hw;
+	common->priv = sc;
 
 	/*
 	 * Cache line size is used to size and align various
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index b2a45ce..63059b6 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -33,8 +33,7 @@ static struct pci_device_id ath_pci_id_table[] __devinitdata = {
 /* return bus cachesize in 4B word units */
 static void ath_pci_read_cachesize(struct ath_common *common, int *csz)
 {
-	struct ath_hw *ah = (struct ath_hw *) common->ah;
-	struct ath_softc *sc = ah->ah_sc;
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 	u8 u8tmp;
 
 	pci_read_config_byte(to_pci_dev(sc->dev), PCI_CACHE_LINE_SIZE, &u8tmp);
@@ -52,8 +51,7 @@ static void ath_pci_read_cachesize(struct ath_common *common, int *csz)
 
 static void ath_pci_cleanup(struct ath_common *common)
 {
-	struct ath_hw *ah = (struct ath_hw *) common->ah;
-	struct ath_softc *sc = ah->ah_sc;
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 	struct pci_dev *pdev = to_pci_dev(sc->dev);
 
 	pci_iounmap(pdev, sc->mem);
@@ -86,8 +84,7 @@ static bool ath_pci_eeprom_read(struct ath_common *common, u32 off, u16 *data)
  */
 static void ath_pci_bt_coex_prep(struct ath_common *common)
 {
-	struct ath_hw *ah = (struct ath_hw *) common->ah;
-	struct ath_softc *sc = ah->ah_sc;
+	struct ath_softc *sc = (struct ath_softc *) common->priv;
 	struct pci_dev *pdev = to_pci_dev(sc->dev);
 	u8 aspm;
 
-- 
1.6.3.3


^ permalink raw reply related

* Re: [PATCH 2/2] cfg80211: fix wireless handlers assignment
From: Hugh Dickins @ 2009-09-27 21:50 UTC (permalink / raw)
  To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909272139280.4061@sister.anvils>

On Sun, 27 Sep 2009, Hugh Dickins wrote:
> 
> I've experimented by moving your NETDEV_PRE_INIT hunk later in the
> sequence, just before the netdev_initialize_kobject(dev) (so I also
> changed the "goto out" to "goto err_uninit"): both* machines then boot
> correctly, and this mail leaves me wirelessly.
> 
> I'll now experiment to see how early I can move that hunk.

Both machines boot (and do wireless) correctly with your NETDEV_PRE_INIT
hunk placed just after the ndo_init block, instead of just before where
you placed it.  That's i386 kernels on both.

But curiouser and curiouser... the laptop can do 64-bit, so I built
my 64-bit kernel, and went through the motions to reproduce the
early boot crash with the patch as you had it: but the x86_64 kernel
boots (and does wireless) correctly with the NETDEV_PRE_INIT hunk
just where you placed it, before the ndo_init block.

Perhaps there's a difference in the 32- and 64-bit startup sequence
with respect to notifiers; or perhaps your change tickles another bug.
I don't know, I'm turning off now.

Hugh

^ permalink raw reply

* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-27 21:02 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Clyde McPherson, Hauke Mehrtens, Tim Gardner, linux-wireless,
	bcm43xx-dev
In-Reply-To: <43e72e890909271250g2936947fj314aad65e10d9788@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6239 bytes --]

On Sun, Sep 27, 2009 at 12:50:19PM -0700, Luis R. Rodriguez wrote:
> On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
> >
> >
> >> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> >>
> >>>
> >>> Bryan Wu wrote:
> >>>
> >>>>
> >>>> Mauro Di Domenico wrote:
> >>>>
> >>>>>
> >>>>> Hi,
> >>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
> >>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
> >>>>> machine with kernel version 2.6.30-6.
> >>>>>
> >>>>> During the boot I experience this problem:
> >>>>>
> >>>>> $ dmesg|egrep "b43|ssb"
> >>>>>
> >>>>> [    2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
> >>>>> low) -> IRQ 17
> >>>>> [    2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
> >>>>> [    2.544344] ssb: Sonics Silicon Backplane found on PCI device
> >>>>> 0000:06:00.0
> >>>>> [    6.968981] b43: disagrees about version of symbol
> >>>>> ssb_device_is_enabled
> >>>>> [    6.968986] b43: Unknown symbol ssb_device_is_enabled
> >>>>> [    6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
> >>>>> [    6.969407] b43: disagrees about version of symbol
> >>>>> ssb_pcicore_dev_irqvecs_enable
> >>>>> [    6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
> >>>>> .....
> >>>>> ....
> >>>>> ...
> >>>>>
> >>>>>
> >>>>
> >>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
> >>>> have
> >>>> no time to take a deeper look.
> >>>>
> >>>> Thanks
> >>>>
> >>>
> >>> Hi,
> >>>
> >>> I had the same problem with the ssb module and compat-wireless in ubuntu
> >>> 9.04. The problem is that the ssb module is integrated into the
> >>> initramfs image. The version out of the initramfs image is loaded on
> >>> startup and not the version of compat-wireless. Running "sudo
> >>> update-initramfs -u" after installing compat-wireless and restaing the
> >>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
> >>> form default initramfs image or compat-wireless should update the image
> >>> with the install command. At least the compat-wireless documentation
> >>> needs an update.
> >>>
> >>> Hauke
> >>>
> >>> (adding Luis and linux-wireless list)
> >>>
> >>
> >> Tim, do you guys update the initramfs upon installation of lbm? If a
> >> user does not use lbm and uses compat-wireless I suppose we need to do
> >> something similar.
> >>
> >>  Luis
> >> _______________________________________________
> >> Bcm43xx-dev mailing list
> >> Bcm43xx-dev@lists.berlios.de
> >> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
> >>
> >
> > All:
> > I have a large group that uses the ssb module along with the Broadcom 4318,
> > in a CF form factor. If the CF card is inserted before boot, and the ssb
> > module is not in the initrd process, the laptops lock up and do not become
> > operational. The solution to this problem is/was adding the ssb.ko to the
> > initrd process. So I agree with Luis on this, the ssb module will have to be
> > added/updated to the initrd process. As for PCI operations, I don't know,
> > but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
> > am testing new releases of b43, I run "update-initramfs -u" to update the
> > ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
> > modprobe them back in. - This saves a reboot)
> 
> But why is ssb, b43, b44 needed upon early boot?

OK the reason seems to be netboot. Yeah the only fix for distros who want
this on the initramfs is to update it after a compat-wireless package is
installed. I suppose we can add a hook to compat-wireless for each distro.
I'm only familiar with Ubuntu way of doing this so if people are interested
in other distros you'll need to point/test how to do this on there.

Please try this patch against compat-wireless: (also attached)

>From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Date: Sun, 27 Sep 2009 13:58:22 -0700
Subject: [PATCH] Add scripts/update-initramfs and use it

Some distributions may ship b44 and ssb on the initramfs for
netboot. To help with this we need to update the initrafms
for those distributions.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 Makefile                 |    1 +
 scripts/update-initramfs |   33 +++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 0 deletions(-)
 create mode 100755 scripts/update-initramfs

diff --git a/Makefile b/Makefile
index ab97de0..c7333a2 100644
--- a/Makefile
+++ b/Makefile
@@ -65,6 +65,7 @@ install: uninstall install-modules install-scripts
 install-modules: modules
 	$(MAKE) -C $(KLIB_BUILD) M=$(PWD) $(KMODDIR_ARG) $(KMODPATH_ARG) \
 		modules_install
+	@./scripts/update-initramfs
 
 install-scripts:
 	@# All the scripts we can use
diff --git a/scripts/update-initramfs b/scripts/update-initramfs
new file mode 100755
index 0000000..412d885
--- /dev/null
+++ b/scripts/update-initramfs
@@ -0,0 +1,33 @@
+#!/bin/bash
+# Copyright 2009        Luis R. Rodriguez <mcgrof@gmail.com>
+#
+# Since we provide ssb, the Ethernet module b44 some people may
+# rely on it to netboot, so update the initrafms for each
+# distribution.
+#
+# Note that in the future people may want to wireless-boot
+# so this will help with that as well.
+
+LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
+
+KLIB=/lib/modules/2.6.31-wl/build
+ver=$(echo $KLIB | awk -F "/lib/modules/" '{print $2}' | awk -F"/" '{print $1}')
+dir=/boot/
+
+case $LSB_RED_ID in
+"Ubuntu")
+	echo "Updating Ubuntu's initramfs for $ver under $dir ..."
+	mkinitramfs -o $dir/initrd.img-$ver $ver
+	echo "Will now run update-grub to ensure grub will find the new initramfs ..."
+	update-grub
+	;;
+*)
+	echo "Warning:"
+	echo "You may or may not need to update your initframfs, you should if"
+	echo "any of the modules installed are part of your initramfs. To add"
+	echo "support for your distribution to do this automatically send a"
+	echo "patch against $0. If your distribution does not require this"
+	echo "send a patch against the '/usr/bin/lsb_release -i -s': $LSB_RED_ID"
+	echo "tag for your distribution to avoid this warning."
+        ;;
+esac
-- 
1.6.3.3


[-- Attachment #2: add-update-initrafms.patch --]
[-- Type: text/plain, Size: 2363 bytes --]

>From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Date: Sun, 27 Sep 2009 13:58:22 -0700
Subject: [PATCH] Add scripts/update-initramfs and use it

Some distributions may ship b44 and ssb on the initramfs for
netboot. To help with this we need to update the initrafms
for those distributions.

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 Makefile                 |    1 +
 scripts/update-initramfs |   33 +++++++++++++++++++++++++++++++++
 2 files changed, 34 insertions(+), 0 deletions(-)
 create mode 100755 scripts/update-initramfs

diff --git a/Makefile b/Makefile
index ab97de0..c7333a2 100644
--- a/Makefile
+++ b/Makefile
@@ -65,6 +65,7 @@ install: uninstall install-modules install-scripts
 install-modules: modules
 	$(MAKE) -C $(KLIB_BUILD) M=$(PWD) $(KMODDIR_ARG) $(KMODPATH_ARG) \
 		modules_install
+	@./scripts/update-initramfs
 
 install-scripts:
 	@# All the scripts we can use
diff --git a/scripts/update-initramfs b/scripts/update-initramfs
new file mode 100755
index 0000000..412d885
--- /dev/null
+++ b/scripts/update-initramfs
@@ -0,0 +1,33 @@
+#!/bin/bash
+# Copyright 2009        Luis R. Rodriguez <mcgrof@gmail.com>
+#
+# Since we provide ssb, the Ethernet module b44 some people may
+# rely on it to netboot, so update the initrafms for each
+# distribution.
+#
+# Note that in the future people may want to wireless-boot
+# so this will help with that as well.
+
+LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
+
+KLIB=/lib/modules/2.6.31-wl/build
+ver=$(echo $KLIB | awk -F "/lib/modules/" '{print $2}' | awk -F"/" '{print $1}')
+dir=/boot/
+
+case $LSB_RED_ID in
+"Ubuntu")
+	echo "Updating Ubuntu's initramfs for $ver under $dir ..."
+	mkinitramfs -o $dir/initrd.img-$ver $ver
+	echo "Will now run update-grub to ensure grub will find the new initramfs ..."
+	update-grub
+	;;
+*)
+	echo "Warning:"
+	echo "You may or may not need to update your initframfs, you should if"
+	echo "any of the modules installed are part of your initramfs. To add"
+	echo "support for your distribution to do this automatically send a"
+	echo "patch against $0. If your distribution does not require this"
+	echo "send a patch against the '/usr/bin/lsb_release -i -s': $LSB_RED_ID"
+	echo "tag for your distribution to avoid this warning."
+        ;;
+esac
-- 
1.6.3.3


^ permalink raw reply related

* Re: [PATCH 2/2] cfg80211: fix wireless handlers assignment
From: Hugh Dickins @ 2009-09-27 20:58 UTC (permalink / raw)
  To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <1254076075.6583.6.camel@johannes.local>

On Sun, 27 Sep 2009, Johannes Berg wrote:

> The point we assign dev->wireless_handlers at is too
> late, we need to do that before netdev_register_kobject()
> gets called, so use the new NETDEV_PRE_INIT notifier.
> The result of adding wireless_handlers too late is the
> disappearance of /sys/class/net/wlan0/wireless which a
> bunch of distro scripts still require.
> 
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

This 2/2 patch does indeed work: many thanks.  But...

> ---
> This should fix the regression Hugh reported (of course requires the
> other patch which unfortunately I forgot to CC you, Hugh, I'll send you
> a copy in private).

... the 1/2 patch has a couple of problems.

The trivial problem is that include/linux/notifier.h in Linus's git has
#define NETDEV_PRE_UP		0x000D
#define NETDEV_BONDING_OLDTYPE  0x000E
#define NETDEV_BONDING_NEWTYPE  0x000F

So it rejects the patch you posted: I changed it to add
#define NETDEV_PRE_INIT		0x0010
just after the NETDEV_BONDING_NEWTYPE line.

The more serious problem is that it stops both my machines from booting,
too early for framebuffer to show any messages, but vga=normal shows a
long stacktrace scrolling offscreen, with some notifier stuff in there.

I've experimented by moving your NETDEV_PRE_INIT hunk later in the
sequence, just before the netdev_initialize_kobject(dev) (so I also
changed the "goto out" to "goto err_uninit"): both* machines then boot
correctly, and this mail leaves me wirelessly.

I'll now experiment to see how early I can move that hunk.

Hugh

* I wrote that hoping the Aspire One build would complete soon,
but it's still going: assume it's fine unless I say otherwise.

^ permalink raw reply

* Re: [PATCH 2/2] cfg80211: fix wireless handlers assignment
From: Luis R. Rodriguez @ 2009-09-27 20:30 UTC (permalink / raw)
  To: Johannes Berg; +Cc: netdev, linux-wireless, Hugh Dickins
In-Reply-To: <1254076075.6583.6.camel@johannes.local>

On Sun, Sep 27, 2009 at 11:27 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> The point we assign dev->wireless_handlers at is too
> late, we need to do that before netdev_register_kobject()
> gets called, so use the new NETDEV_PRE_INIT notifier.
> The result of adding wireless_handlers too late is the
> disappearance of /sys/class/net/wlan0/wireless which a
> bunch of distro scripts still require.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> This should fix the regression Hugh reported (of course requires the
> other patch which unfortunately I forgot to CC you, Hugh, I'll send you
> a copy in private).

Are these stable fixes?

  Luis

^ permalink raw reply

* Re: [PATCH 1/2] net: introduce NETDEV_PRE_INIT notifier
From: Marcel Holtmann @ 2009-09-27 20:11 UTC (permalink / raw)
  To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <1254075999.6583.4.camel@johannes.local>

Hi Johannes,

> For various purposes including a wireless extensions
> bugfix, we need to hook into the netdev creation at
> a point before netdev_register_kobject(). It seems
> more generic, however, to have it even earlier. This
> will also ease doing the dev type assignment that
> Marcel was working on generically.

you are beating me to it. I can only second that this is a good idea for
the dev type assignment. Once Dave acks this I can sent a rebased patch
for the dev type stuff for WiFi.

Regards

Marcel



^ permalink raw reply

* Re: zd1211rw on ppc (iBook G4)
From: Hin-Tak Leung @ 2009-09-27 20:08 UTC (permalink / raw)
  To: Leonardo H. Souza Hamada; +Cc: linux-wireless
In-Reply-To: <4ABFB98F.3060307@ufra.edu.br>

On Sun, Sep 27, 2009 at 8:14 PM, Leonardo H. Souza Hamada
<leonardo.hamada@ufra.edu.br> wrote:
> Hin-Tak Leung wrote:
>>
>> I found that one of the patches -
>> 0004-forward-port-of-an-old-patch-from-the-internet.patch - is buggy,
>> and breaks USB 2.0 host... wanna undo that and have another go?
>> (that's also the one that adds the 'read failed after 5 attempts",
>> etc).
>> --
>> 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
>>
>
> OK,
>
> Undid the 0004-forward-port-of-an-old-patch-from-the-internet.patch patch.
>
> The vendor driver seems to work fine now.
>
> dmesg:
> usb 1-2: new high speed USB device using ehci_hcd and address 3
> usb 1-2: New USB device found, idVendor=0411, idProduct=00da
> usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=0
> usb 1-2: Product: USB2.0 WLAN
> usb 1-2: Manufacturer: Buffalo
> usb 1-2: configuration #1 chosen from 1 choice
>
>  _____     ____    _    ____
> |__  /   _|  _ \  / \  / ___|
>  / / | | | | | |/ _ \ \___ \
>  / /| |_| | |_| / ___ \ ___) |
> /____\__, |____/_/   \_\____/
>     |___/
> ZD1211B - version 3.0.0.56
> vendor_id = 0411
> product_id = 00da
> USB 2.0 Host
> Release Ver = 4810
> EEPORM Ver = 4810
> Finsih download Firmware. Ready to reboot
> PA type: 0
> PHYNEWLayout = 1
> Airoha AL2230S_RF
> OverWrite CR47 = 0x19
> zd1205_config: EEP(HWFeature)=0x110
> AllowedChannel = 00013fff
> Region:73
> usbcore: registered new interface driver zd1211b
> zd1205_notify_disjoin_event
> ADDRCONF(NETDEV_UP): ath0: link is not ready
>
>
>
> lsusb:
> Bus 001 Device 003: ID 0411:00da MelCo., Inc. WLI-U2-KG54L
>
>
> lsmod:
> Module                  Size  Used by
> zd1211b               500924  0
>
>
>
> Thanks,
>
> Leonardo
> --
> 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
>

Thanks for letting me know - I had a better thought at that (or
rather, a big bundle where it came from) - It probably worked around
some bug in 2.22 which has since been fixed. I haven't heard from the
person where this came from why he did what he did, but just as well,
I guess. It served a purpose during the 2.22 period.

^ permalink raw reply

* Re: [LTP] Support of WIFI and W-LAN test cases in LTP
From: Luis R. Rodriguez @ 2009-09-27 19:52 UTC (permalink / raw)
  To: subrata
  Cc: Georgy Berdyshev, ltp-list, Jouni Malinen,
	linux-wireless@vger.kernel.org, John W. Linville, rahul Baliyan,
	Luis Carlos Cobo, Johannes Berg, Jouni.Malinen
In-Reply-To: <1254075355.10457.32.camel@subratamodak.linux.ibm.com>

On Sun, Sep 27, 2009 at 11:15 AM, Subrata Modak
<subrata@linux.vnet.ibm.com> wrote:
> On Sun, 2009-09-13 at 18:46 +0530, Subrata Modak wrote:
>> Hi Georgy,
>>
>> On Thu, 2009-06-25 at 14:40 +0530, Subrata Modak wrote:
>> > On Tue, 2009-06-23 at 19:08 -0300, Georgy Berdyshev wrote:
>> > > Hi,
>> > >
>> > > Luis did already mention that the idea is to contribute things back to
>> > > LTP or have LTP use it.
>> >
>>
>> Any headway towards Code contribution to LTP ?
>
> Ping.

The GSoC student fell off from the face of the earth without even
notice so the project was never finished. The project is up for grabs
for anyone now to implement.

  Luis

^ permalink raw reply

* Re: A problem loading ssb module
From: Luis R. Rodriguez @ 2009-09-27 19:50 UTC (permalink / raw)
  To: Clyde McPherson; +Cc: Hauke Mehrtens, Tim Gardner, linux-wireless, bcm43xx-dev
In-Reply-To: <4ABF8184.9060904@verizon.net>

On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
>
>
>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>
>>>
>>> Bryan Wu wrote:
>>>
>>>>
>>>> Mauro Di Domenico wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>>> machine with kernel version 2.6.30-6.
>>>>>
>>>>> During the boot I experience this problem:
>>>>>
>>>>> $ dmesg|egrep "b43|ssb"
>>>>>
>>>>> [    2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>>>> low) -> IRQ 17
>>>>> [    2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>>>> [    2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>>> 0000:06:00.0
>>>>> [    6.968981] b43: disagrees about version of symbol
>>>>> ssb_device_is_enabled
>>>>> [    6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>>> [    6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>>> [    6.969407] b43: disagrees about version of symbol
>>>>> ssb_pcicore_dev_irqvecs_enable
>>>>> [    6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>>> .....
>>>>> ....
>>>>> ...
>>>>>
>>>>>
>>>>
>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>>>> have
>>>> no time to take a deeper look.
>>>>
>>>> Thanks
>>>>
>>>
>>> Hi,
>>>
>>> I had the same problem with the ssb module and compat-wireless in ubuntu
>>> 9.04. The problem is that the ssb module is integrated into the
>>> initramfs image. The version out of the initramfs image is loaded on
>>> startup and not the version of compat-wireless. Running "sudo
>>> update-initramfs -u" after installing compat-wireless and restaing the
>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>>> form default initramfs image or compat-wireless should update the image
>>> with the install command. At least the compat-wireless documentation
>>> needs an update.
>>>
>>> Hauke
>>>
>>> (adding Luis and linux-wireless list)
>>>
>>
>> Tim, do you guys update the initramfs upon installation of lbm? If a
>> user does not use lbm and uses compat-wireless I suppose we need to do
>> something similar.
>>
>>  Luis
>> _______________________________________________
>> Bcm43xx-dev mailing list
>> Bcm43xx-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>>
>
> All:
> I have a large group that uses the ssb module along with the Broadcom 4318,
> in a CF form factor. If the CF card is inserted before boot, and the ssb
> module is not in the initrd process, the laptops lock up and do not become
> operational. The solution to this problem is/was adding the ssb.ko to the
> initrd process. So I agree with Luis on this, the ssb module will have to be
> added/updated to the initrd process. As for PCI operations, I don't know,
> but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
> am testing new releases of b43, I run "update-initramfs -u" to update the
> ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
> modprobe them back in. - This saves a reboot)

But why is ssb, b43, b44 needed upon early boot?

  Luis

^ permalink raw reply

* Re: zd1211rw on ppc (iBook G4)
From: Leonardo H. Souza Hamada @ 2009-09-27 19:14 UTC (permalink / raw)
  To: linux-wireless
In-Reply-To: <3ace41890909221750h7c4beee8ob0ec31fb0657b3fd@mail.gmail.com>

Hin-Tak Leung wrote:
>
> I found that one of the patches -
> 0004-forward-port-of-an-old-patch-from-the-internet.patch - is buggy,
> and breaks USB 2.0 host... wanna undo that and have another go?
> (that's also the one that adds the 'read failed after 5 attempts",
> etc).
> --
> 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
>   

OK,

Undid the 0004-forward-port-of-an-old-patch-from-the-internet.patch patch.

The vendor driver seems to work fine now.

dmesg:
usb 1-2: new high speed USB device using ehci_hcd and address 3
usb 1-2: New USB device found, idVendor=0411, idProduct=00da
usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=0
usb 1-2: Product: USB2.0 WLAN
usb 1-2: Manufacturer: Buffalo
usb 1-2: configuration #1 chosen from 1 choice

 _____     ____    _    ____
|__  /   _|  _ \  / \  / ___|
  / / | | | | | |/ _ \ \___ \
 / /| |_| | |_| / ___ \ ___) |
/____\__, |____/_/   \_\____/
     |___/
ZD1211B - version 3.0.0.56
vendor_id = 0411
product_id = 00da
USB 2.0 Host
Release Ver = 4810
EEPORM Ver = 4810
Finsih download Firmware. Ready to reboot
PA type: 0
PHYNEWLayout = 1
Airoha AL2230S_RF
OverWrite CR47 = 0x19
zd1205_config: EEP(HWFeature)=0x110
AllowedChannel = 00013fff
Region:73
usbcore: registered new interface driver zd1211b
zd1205_notify_disjoin_event
ADDRCONF(NETDEV_UP): ath0: link is not ready



lsusb:
Bus 001 Device 003: ID 0411:00da MelCo., Inc. WLI-U2-KG54L


lsmod:
Module                  Size  Used by
zd1211b               500924  0



Thanks,

Leonardo

^ permalink raw reply

* Re: [bisected] Wireless regression in 2.6.32-git
From: Johannes Berg @ 2009-09-27 18:46 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Hugh Dickins, netdev, linux-kernel, linux-wireless
In-Reply-To: <20090927204548.3ee3768f@infradead.org>

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

On Sun, 2009-09-27 at 20:45 +0200, Arjan van de Ven wrote:

> > Subject: cfg80211: don't set privacy w/o key
> > 
> > When wpa_supplicant is used to connect to open networks,
> > it causes the wdev->wext.keys to point to key memory, but
> > that key memory is all empty. Only use privacy when there
> > is a default key to be used.
> 
> 
> indeed it does
> 
> can we get this into mainline soon ?

John's on his way home I suppose.

johannes


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* Re: [bisected] Wireless regression in 2.6.32-git
From: Arjan van de Ven @ 2009-09-27 18:45 UTC (permalink / raw)
  To: Hugh Dickins; +Cc: Johannes Berg, netdev, linux-kernel, linux-wireless
In-Reply-To: <Pine.LNX.4.64.0909271708210.8927@sister.anvils>

On Sun, 27 Sep 2009 17:14:04 +0100 (BST)
Hugh Dickins <hugh.dickins@tiscali.co.uk> wrote:

> On Sun, 27 Sep 2009, Arjan van de Ven wrote:
> > 
> > With todays git my laptop fails to associate with my access point.
> > Bisection points to the commit below, and reverting this one commit
> > on the HEAD of tree also fixes the issue, so I'm pretty confident
> > that this commit is to blame.
> > 
> > I have a 4965 wifi card in my laptop, and the network I'm trying to
> > connect to has no encryption. I'm running Fedora 11 as OS.
> > 
> > I would like to kindly request for this commit to be reverted until
> > a more permanent solution is found (I'm happy to test any patches)..
> > 
> > 94f85853324e02c3a32bc3101f090dc9a3f512b4 is first bad commit
> > commit 94f85853324e02c3a32bc3101f090dc9a3f512b4
> > Author: Johannes Berg <johannes@sipsolutions.net>
> > Date:   Thu Sep 17 17:15:31 2009 -0700
> > 
> >     cfg80211: don't overwrite privacy setting
> >     
> >     When cfg80211 is instructed to connect, it always
> >     uses the default WEP key for the privacy setting,
> >     which clearly is wrong when using wpa_supplicant.
> >     Don't overwrite the setting, and rely on it being
> >     false when wpa_supplicant is not running, instead
> >     set it to true when we have keys.
> >     
> >     Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> >     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > 
> > :040000 040000 27fb46273e88eefee373699eb7e3f2923ac0886b
> > 9518ee3e52c8320613cc5eee5ac54aabf082432f M	net
> 
> I've a different problem with wireless that Johannes is investigating
> for me on linux-wireless; but here's a patch that he pointed me to
> along the way, didn't help my issue but I expect it will help yours...
> 
> 
> Subject: cfg80211: don't set privacy w/o key
> 
> When wpa_supplicant is used to connect to open networks,
> it causes the wdev->wext.keys to point to key memory, but
> that key memory is all empty. Only use privacy when there
> is a default key to be used.


indeed it does

can we get this into mainline soon ?

^ permalink raw reply

* [PATCH 2/2] cfg80211: fix wireless handlers assignment
From: Johannes Berg @ 2009-09-27 18:27 UTC (permalink / raw)
  To: netdev; +Cc: linux-wireless, Hugh Dickins

The point we assign dev->wireless_handlers at is too
late, we need to do that before netdev_register_kobject()
gets called, so use the new NETDEV_PRE_INIT notifier.
The result of adding wireless_handlers too late is the
disappearance of /sys/class/net/wlan0/wireless which a
bunch of distro scripts still require.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
This should fix the regression Hugh reported (of course requires the
other patch which unfortunately I forgot to CC you, Hugh, I'll send you
a copy in private).

 net/wireless/core.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- wireless-testing.orig/net/wireless/core.c	2009-09-27 15:12:20.000000000 +0200
+++ wireless-testing/net/wireless/core.c	2009-09-27 15:12:54.000000000 +0200
@@ -641,6 +641,12 @@ static int cfg80211_netdev_notifier_call
 	WARN_ON(wdev->iftype == NL80211_IFTYPE_UNSPECIFIED);
 
 	switch (state) {
+	case NETDEV_PRE_INIT:
+#ifdef CONFIG_WIRELESS_EXT
+		if (!dev->wireless_handlers)
+			dev->wireless_handlers = &cfg80211_wext_handler;
+#endif
+		break;
 	case NETDEV_REGISTER:
 		/*
 		 * NB: cannot take rdev->mtx here because this may be
@@ -666,8 +672,6 @@ static int cfg80211_netdev_notifier_call
 		wdev->sme_state = CFG80211_SME_IDLE;
 		mutex_unlock(&rdev->devlist_mtx);
 #ifdef CONFIG_WIRELESS_EXT
-		if (!dev->wireless_handlers)
-			dev->wireless_handlers = &cfg80211_wext_handler;
 		wdev->wext.default_key = -1;
 		wdev->wext.default_mgmt_key = -1;
 		wdev->wext.connect.auth_type = NL80211_AUTHTYPE_AUTOMATIC;



^ permalink raw reply

* Re: [PATCH v2] mac80211: Fix [re]association power saving issue on AP side
From: Johannes Berg @ 2009-09-27 13:07 UTC (permalink / raw)
  To: Jouni Malinen; +Cc: Igor Perminov, John W. Linville, linux-wireless
In-Reply-To: <20090926183446.GA10898@jm.kir.nu>

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Sat, 2009-09-26 at 21:34 +0300, Jouni Malinen wrote:
> On Tue, Sep 22, 2009 at 12:25:44AM +0400, Igor Perminov wrote:
> 
> > At the step 4 the AP "remembers" the STA and considers it is still in
> > the PS state, so the AP buffers frames, which it has to send to the STA.
> > But the STA isn't actually in the PS state and so it neither checks
> > TIM bits nor reports to the AP that it isn't power saving.
> > Because of that authentication/[re]association fails.
> > 
> > To fix authentication/[re]association stage of this issue, Auth, Assoc
> > Resp and Reassoc Resp frames are transmitted disregarding of STA's power
> > saving state.
> 
> That looks fine to me and should be applied.

Alright, I'll take back my NACK then, just thought it'd be easier to do
the cleanup in the same patch but I can also do it separately.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* [PATCH 1/2] net: introduce NETDEV_PRE_INIT notifier
From: Johannes Berg @ 2009-09-27 18:26 UTC (permalink / raw)
  To: netdev; +Cc: linux-wireless

For various purposes including a wireless extensions
bugfix, we need to hook into the netdev creation at
a point before netdev_register_kobject(). It seems
more generic, however, to have it even earlier. This
will also ease doing the dev type assignment that
Marcel was working on generically.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 include/linux/notifier.h |    1 +
 net/core/dev.c           |    5 +++++
 2 files changed, 6 insertions(+)

--- wireless-testing.orig/include/linux/notifier.h	2009-09-27 15:09:10.000000000 +0200
+++ wireless-testing/include/linux/notifier.h	2009-09-27 15:10:19.000000000 +0200
@@ -199,6 +199,7 @@ static inline int notifier_to_errno(int 
 #define NETDEV_FEAT_CHANGE	0x000B
 #define NETDEV_BONDING_FAILOVER 0x000C
 #define NETDEV_PRE_UP		0x000D
+#define NETDEV_PRE_INIT		0x000E
 
 #define SYS_DOWN	0x0001	/* Notify of system down */
 #define SYS_RESTART	SYS_DOWN
--- wireless-testing.orig/net/core/dev.c	2009-09-27 15:09:56.000000000 +0200
+++ wireless-testing/net/core/dev.c	2009-09-27 15:11:40.000000000 +0200
@@ -4734,6 +4734,11 @@ int register_netdevice(struct net_device
 
 	dev->iflink = -1;
 
+	ret = call_netdevice_notifiers(NETDEV_PRE_INIT, dev);
+	ret = notifier_to_errno(ret);
+	if (ret)
+		goto out;
+
 	/* Init, if this function is available */
 	if (dev->netdev_ops->ndo_init) {
 		ret = dev->netdev_ops->ndo_init(dev);



^ permalink raw reply

* Re: [LTP] Support of WIFI and W-LAN test cases in LTP
From: Subrata Modak @ 2009-09-27 18:15 UTC (permalink / raw)
  To: Georgy Berdyshev
  Cc: ltp-list, Luis R. Rodriguez, Jouni Malinen,
	linux-wireless@vger.kernel.org, John W. Linville, rahul Baliyan,
	Luis Carlos Cobo, Johannes Berg, Jouni.Malinen
In-Reply-To: <1252847807.5357.36.camel@subratamodak.linux.ibm.com>

On Sun, 2009-09-13 at 18:46 +0530, Subrata Modak wrote: 
> Hi Georgy,
> 
> On Thu, 2009-06-25 at 14:40 +0530, Subrata Modak wrote: 
> > On Tue, 2009-06-23 at 19:08 -0300, Georgy Berdyshev wrote: 
> > > Hi,
> > > 
> > > Luis did already mention that the idea is to contribute things back to
> > > LTP or have LTP use it.
> > 
> 
> Any headway towards Code contribution to LTP ?

Ping.

> 
> Regards--
> Subrata
> 
> > Great to hear that again. I was trying to figure out the status of that
> > work ? When is it expected to complete, any idea ?
> > 
> > Regards--
> > Subrata
> > 
> > > In case that there is some work going on, I would like to merge those
> > > tests also into my project
> > > and later on extend the work with LTP.
> > > 
> > > In any case, feel free to contact me.
> > > 
> > > Regards, Georgy
> > > 
> > > On Tue, Jun 23, 2009 at 12:31 PM, Luis R.
> > > Rodriguez<lrodriguez@atheros.com> wrote:
> > > > On Tue, Jun 23, 2009 at 7:48 AM, Subrata
> > > > Modak<subrata@linux.vnet.ibm.com> wrote:
> > > >> On Thu, 2009-03-19 at 12:30 +0530, Subrata Modak wrote:
> > > >>> On Wed, 2009-03-18 at 12:42 -0700, Luis R. Rodriguez wrote:
> > > >>> > On Mon, Mar 16, 2009 at 11:55 PM, Subrata Modak
> > > >>> > <subrata@linux.vnet.ibm.com> wrote:
> > > >>> > > Hi Rahul,
> > > >>> > >
> > > >>> > > On Fri, 2009-03-13 at 22:17 +0530, Subrata Modak wrote:
> > > >>> > >> Hi,
> > > >>> > >>
> > > >>> > >> On Fri, 2009-03-13 at 19:02 +0530, rahul Baliyan wrote:
> > > >>> > >> > Hi,
> > > >>> > >> >
> > > >>> > >> > Pl.  confirm if LTP contains the test cases of W-LAN and WI-FI.
> > > >>> > >>
> > > >>> > >> Nope. We do not have till now. However, we initiated some discussion
> > > >>> > >> some 6 months back in the same mailing list regarding Wireless Mesh
> > > >>> > >> Netwoking tests. Please follow the following thread:
> > > >>> > >>
> > > >>> > >> http://marc.info/?t=121969812900007&r=1&w=2&n=4,
> > > >>> > >>
> > > >>> > >> There are some tests already avilable. We need somebody to volunteer to
> > > >>> > >> bring them to some shape so that they can be automated and then
> > > >>> > >> integrated inside LTP. Would you be ready to do that ?
> > > >>> > >
> > > >>> > > Would you like to take up my proposal ?
> > > >>> >
> > > >>> > BTW I've stashed a Linux wireless testing entry in the Linux
> > > >>> > Foundation GSoC, hopefully that can be merged back into LTP.
> > > >>> >
> > > >>> > https://www.linuxfoundation.org/en/Google_Summer_of_Code_2009#Automation_of_testing_using_mac80211_hwsim_and_Orbit
> > > >>>
> > > >>
> > > >> Hi,
> > > >>
> > > >> Is somebody working on this, and still interested to contribute the same
> > > >> to LTP ?
> > > >
> > > > Yes, the idea is to hopefully contribute it back to LTP. Or have LTP
> > > > use it. I've added Georgy, the student working on this project.
> > > >
> > > >  Luis
> > > >
> > > 
> > > 
> > > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Ltp-list mailing list
> > Ltp-list@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ltp-list
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


^ permalink raw reply

* Re: [bisected] Wireless regression in 2.6.32-git
From: Hugh Dickins @ 2009-09-27 16:14 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Johannes Berg, netdev, linux-kernel, linux-wireless
In-Reply-To: <20090927151855.29efcc53@infradead.org>

On Sun, 27 Sep 2009, Arjan van de Ven wrote:
> 
> With todays git my laptop fails to associate with my access point.
> Bisection points to the commit below, and reverting this one commit on
> the HEAD of tree also fixes the issue, so I'm pretty confident that this
> commit is to blame.
> 
> I have a 4965 wifi card in my laptop, and the network I'm trying to
> connect to has no encryption. I'm running Fedora 11 as OS.
> 
> I would like to kindly request for this commit to be reverted until a
> more permanent solution is found (I'm happy to test any patches)..
> 
> 94f85853324e02c3a32bc3101f090dc9a3f512b4 is first bad commit
> commit 94f85853324e02c3a32bc3101f090dc9a3f512b4
> Author: Johannes Berg <johannes@sipsolutions.net>
> Date:   Thu Sep 17 17:15:31 2009 -0700
> 
>     cfg80211: don't overwrite privacy setting
>     
>     When cfg80211 is instructed to connect, it always
>     uses the default WEP key for the privacy setting,
>     which clearly is wrong when using wpa_supplicant.
>     Don't overwrite the setting, and rely on it being
>     false when wpa_supplicant is not running, instead
>     set it to true when we have keys.
>     
>     Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> :040000 040000 27fb46273e88eefee373699eb7e3f2923ac0886b
> 9518ee3e52c8320613cc5eee5ac54aabf082432f M	net

I've a different problem with wireless that Johannes is investigating
for me on linux-wireless; but here's a patch that he pointed me to
along the way, didn't help my issue but I expect it will help yours...


Subject: cfg80211: don't set privacy w/o key

When wpa_supplicant is used to connect to open networks,
it causes the wdev->wext.keys to point to key memory, but
that key memory is all empty. Only use privacy when there
is a default key to be used.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 net/wireless/wext-sme.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- wireless-testing.orig/net/wireless/wext-sme.c	2009-09-24 08:51:14.000000000 +0200
+++ wireless-testing/net/wireless/wext-sme.c	2009-09-24 08:57:01.000000000 +0200
@@ -30,7 +30,8 @@ int cfg80211_mgd_wext_connect(struct cfg
 	if (wdev->wext.keys) {
 		wdev->wext.keys->def = wdev->wext.default_key;
 		wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
-		wdev->wext.connect.privacy = true;
+		if (wdev->wext.default_key != -1)
+			wdev->wext.connect.privacy = true;
 	}
 
 	if (!wdev->wext.connect.ssid_len)

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox