Please pull 'upstream' branch of wireless-2.6

Please pull 'upstream' branch of wireless-2.6

[John W. Linville]

The following changes since commit fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
  Malcolm Parsons:
        uclinux: use PER_LINUX_32BIT in binfmt_flat

are found in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream

Daniel Drake:
      bcm43xx: use softmac-suggested TX rate
      bcm43xx: enable shared key authentication

Eric Sesterhenn:
      skb used after passing to netif_rx in net/ieee80211/ieee80211_rx.c

Faidon Liambotis:
      Add two PLX device IDs

Hong Liu:
      ieee80211: fix not allocating IV+ICV space when usingencryption in ieee80211_tx_frame

Horms:
      CONFIG_WIRELESS_EXT is neccessary after all

John W. Linville:
      softmac: fix build-break from 881ee6999d66c8fc903b429b73bbe6045b38c549

Joseph Jezak:
      SoftMAC: Prevent multiple authentication attempts on the same network
      SoftMAC: Add network to ieee80211softmac_call_events when associate times out

Larry Finger:
      Convert bcm43xx-softmac to use the ieee80211_is_valid_channel routine
      2.6.17 missing a call to ieee80211softmac_capabilities from ieee80211softmac_assoc_req

Michael Buesch:
      bcm43xx: suspend MAC while executing long pwork
      bcm43xx: workaround init_board vs. IRQ race

 drivers/net/wireless/bcm43xx/bcm43xx.h         |    2 +
 drivers/net/wireless/bcm43xx/bcm43xx_main.c    |   82 +++++++++++++++---------
 drivers/net/wireless/bcm43xx/bcm43xx_main.h    |   24 -------
 drivers/net/wireless/bcm43xx/bcm43xx_radio.c   |    7 +-
 drivers/net/wireless/bcm43xx/bcm43xx_wx.c      |    2 -
 drivers/net/wireless/bcm43xx/bcm43xx_xmit.c    |    5 +
 drivers/net/wireless/hostap/hostap_plx.c       |    2 +
 include/net/ieee80211softmac.h                 |    1 
 net/ieee80211/ieee80211_rx.c                   |    4 +
 net/ieee80211/ieee80211_tx.c                   |   15 +++-
 net/ieee80211/softmac/ieee80211softmac_assoc.c |   31 +++++++--
 net/ieee80211/softmac/ieee80211softmac_auth.c  |    4 +
 net/ieee80211/softmac/ieee80211softmac_io.c    |    3 +
 net/ieee80211/softmac/ieee80211softmac_wx.c    |   36 ++++++++++-
 14 files changed, 139 insertions(+), 79 deletions(-)

diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h b/drivers/net/wireless/bcm43xx/bcm43xx.h
index d8f917c..d5e10e2 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -722,6 +722,8 @@ #endif
 	u32 irq_savedstate;
 	/* Link Quality calculation context. */
 	struct bcm43xx_noise_calculation noisecalc;
+	/* if > 0 MAC is suspended. if == 0 MAC is enabled. */
+	int mac_suspended;
 
 	/* Threshold values. */
 	//TODO: The RTS thr has to be _used_. Currently, it is only set via WX.
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index 085d785..af97755 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1885,6 +1885,15 @@ static irqreturn_t bcm43xx_interrupt_han
 
 	spin_lock(&bcm->irq_lock);
 
+	/* Only accept IRQs, if we are initialized properly.
+	 * This avoids an RX race while initializing.
+	 * We should probably not enable IRQs before we are initialized
+	 * completely, but some careful work is needed to fix this. I think it
+	 * is best to stay with this cheap workaround for now... .
+	 */
+	if (unlikely(bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED))
+		goto out;
+
 	reason = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
 	if (reason == 0xffffffff) {
 		/* irq not for us (shared irq) */
@@ -1906,19 +1915,11 @@ static irqreturn_t bcm43xx_interrupt_han
 
 	bcm43xx_interrupt_ack(bcm, reason);
 
-	/* Only accept IRQs, if we are initialized properly.
-	 * This avoids an RX race while initializing.
-	 * We should probably not enable IRQs before we are initialized
-	 * completely, but some careful work is needed to fix this. I think it
-	 * is best to stay with this cheap workaround for now... .
-	 */
-	if (likely(bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED)) {
-		/* disable all IRQs. They are enabled again in the bottom half. */
-		bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
-		/* save the reason code and call our bottom half. */
-		bcm->irq_reason = reason;
-		tasklet_schedule(&bcm->isr_tasklet);
-	}
+	/* disable all IRQs. They are enabled again in the bottom half. */
+	bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
+	/* save the reason code and call our bottom half. */
+	bcm->irq_reason = reason;
+	tasklet_schedule(&bcm->isr_tasklet);
 
 out:
 	mmiowb();
@@ -2297,13 +2298,17 @@ static int bcm43xx_gpio_cleanup(struct b
 /* http://bcm-specs.sipsolutions.net/EnableMac */
 void bcm43xx_mac_enable(struct bcm43xx_private *bcm)
 {
-	bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
-	                bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
-			| BCM43xx_SBF_MAC_ENABLED);
-	bcm43xx_write32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON, BCM43xx_IRQ_READY);
-	bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD); /* dummy read */
-	bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
-	bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
+	bcm->mac_suspended--;
+	assert(bcm->mac_suspended >= 0);
+	if (bcm->mac_suspended == 0) {
+		bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
+		                bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
+				| BCM43xx_SBF_MAC_ENABLED);
+		bcm43xx_write32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON, BCM43xx_IRQ_READY);
+		bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD); /* dummy read */
+		bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
+		bcm43xx_power_saving_ctl_bits(bcm, -1, -1);
+	}
 }
 
 /* http://bcm-specs.sipsolutions.net/SuspendMAC */
@@ -2312,18 +2317,23 @@ void bcm43xx_mac_suspend(struct bcm43xx_
 	int i;
 	u32 tmp;
 
-	bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
-	bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
-	                bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
-			& ~BCM43xx_SBF_MAC_ENABLED);
-	bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
-	for (i = 100000; i; i--) {
-		tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
-		if (tmp & BCM43xx_IRQ_READY)
-			return;
-		udelay(10);
+	assert(bcm->mac_suspended >= 0);
+	if (bcm->mac_suspended == 0) {
+		bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
+		bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
+		                bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
+				& ~BCM43xx_SBF_MAC_ENABLED);
+		bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
+		for (i = 100000; i; i--) {
+			tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
+			if (tmp & BCM43xx_IRQ_READY)
+				goto out;
+			udelay(10);
+		}
+		printkl(KERN_ERR PFX "MAC suspend failed\n");
 	}
-	printkl(KERN_ERR PFX "MAC suspend failed\n");
+out:
+	bcm->mac_suspended++;
 }
 
 void bcm43xx_set_iwmode(struct bcm43xx_private *bcm,
@@ -3181,8 +3191,10 @@ static void bcm43xx_periodic_work_handle
 		/* Periodic work will take a long time, so we want it to
 		 * be preemtible.
 		 */
-		bcm43xx_lock_irqonly(bcm, flags);
 		netif_stop_queue(bcm->net_dev);
+		synchronize_net();
+		bcm43xx_lock_irqonly(bcm, flags);
+		bcm43xx_mac_suspend(bcm);
 		if (bcm43xx_using_pio(bcm))
 			bcm43xx_pio_freeze_txqueues(bcm);
 		savedirqs = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
@@ -3205,6 +3217,7 @@ static void bcm43xx_periodic_work_handle
 			bcm43xx_interrupt_enable(bcm, savedirqs);
 			if (bcm43xx_using_pio(bcm))
 				bcm43xx_pio_thaw_txqueues(bcm);
+			bcm43xx_mac_enable(bcm);
 		}
 		netif_wake_queue(bcm->net_dev);
 		mmiowb();
@@ -3661,6 +3674,10 @@ static void bcm43xx_ieee80211_set_securi
 		secinfo->encrypt = sec->encrypt;
 		dprintk(", .encrypt = %d", sec->encrypt);
 	}
+	if (sec->flags & SEC_AUTH_MODE) {
+		secinfo->auth_mode = sec->auth_mode;
+		dprintk(", .auth_mode = %d\n", sec->auth_mode);
+	}
 	dprintk("\n");
 	if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED &&
 	    !bcm->ieee->host_encrypt) {
@@ -3776,6 +3793,7 @@ static int bcm43xx_init_private(struct b
 	bcm->softmac->set_channel = bcm43xx_ieee80211_set_chan;
 
 	bcm->irq_savedstate = BCM43xx_IRQ_INITIAL;
+	bcm->mac_suspended = 1;
 	bcm->pci_dev = pci_dev;
 	bcm->net_dev = net_dev;
 	bcm->bad_frames_preempt = modparam_bad_frames_preempt;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.h b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
index 30a202b..1164936 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
@@ -112,30 +112,6 @@ int bcm43xx_channel_to_freq(struct bcm43
 	return bcm43xx_channel_to_freq_bg(channel);
 }
 
-/* Lightweight function to check if a channel number is valid.
- * Note that this does _NOT_ check for geographical restrictions!
- */
-static inline
-int bcm43xx_is_valid_channel_a(u8 channel)
-{
-	return (channel >= IEEE80211_52GHZ_MIN_CHANNEL
-	       && channel <= IEEE80211_52GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel_bg(u8 channel)
-{
-	return (channel >= IEEE80211_24GHZ_MIN_CHANNEL
-	       && channel <= IEEE80211_24GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel(struct bcm43xx_private *bcm,
-			     u8 channel)
-{
-	if (bcm43xx_current_phy(bcm)->type == BCM43xx_PHYTYPE_A)
-		return bcm43xx_is_valid_channel_a(channel);
-	return bcm43xx_is_valid_channel_bg(channel);
-}
-
 void bcm43xx_tsf_read(struct bcm43xx_private *bcm, u64 *tsf);
 void bcm43xx_tsf_write(struct bcm43xx_private *bcm, u64 tsf);
 
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
index af5c0bf..bb9c484 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1594,11 +1594,11 @@ int bcm43xx_radio_selectchannel(struct b
 	u16 r8, tmp;
 	u16 freq;
 
+	if (!ieee80211_is_valid_channel(bcm->ieee, channel))
+		return -EINVAL;
 	if ((radio->manufact == 0x17F) &&
 	    (radio->version == 0x2060) &&
 	    (radio->revision == 1)) {
-		if (channel > 200)
-			return -EINVAL;
 		freq = channel2freq_a(channel);
 
 		r8 = bcm43xx_radio_read16(bcm, 0x0008);
@@ -1651,9 +1651,6 @@ int bcm43xx_radio_selectchannel(struct b
 		TODO();	//TODO:	TSSI2dbm workaround
 		bcm43xx_phy_xmitpower(bcm);//FIXME correct?
 	} else {
-		if ((channel < 1) || (channel > 14))
-			return -EINVAL;
-
 		if (synthetic_pu_workaround)
 			bcm43xx_synth_pu_workaround(bcm, channel);
 
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index c35cb3a..5c36e29 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -119,7 +119,7 @@ static int bcm43xx_wx_set_channelfreq(st
 		channel = bcm43xx_freq_to_channel(bcm, data->freq.m);
 		freq = data->freq.m;
 	}
-	if (!bcm43xx_is_valid_channel(bcm, channel))
+	if (!ieee80211_is_valid_channel(bcm->ieee, channel))
 		goto out_unlock;
 	if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) {
 		//ieee80211softmac_disassoc(softmac, $REASON);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c b/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
index d8ece28..6dbd855 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -296,11 +296,14 @@ void bcm43xx_generate_txhdr(struct bcm43
 	u16 control = 0;
 	u16 wsec_rate = 0;
 	u16 encrypt_frame;
+	const u16 ftype = WLAN_FC_GET_TYPE(le16_to_cpu(wireless_header->frame_ctl));
+	const int is_mgt = (ftype == IEEE80211_FTYPE_MGMT);
 
 	/* Now construct the TX header. */
 	memset(txhdr, 0, sizeof(*txhdr));
 
-	bitrate = bcm->softmac->txrates.default_rate;
+	bitrate = ieee80211softmac_suggest_txrate(bcm->softmac,
+		is_multicast_ether_addr(wireless_header->addr1), is_mgt);
 	ofdm_modulation = !(ieee80211_is_cck_rate(bitrate));
 	fallback_bitrate = bcm43xx_calc_fallback_rate(bitrate);
 	fallback_ofdm_modulation = !(ieee80211_is_cck_rate(fallback_bitrate));
diff --git a/drivers/net/wireless/hostap/hostap_plx.c b/drivers/net/wireless/hostap/hostap_plx.c
index edaaa94..39c545e 100644
--- a/drivers/net/wireless/hostap/hostap_plx.c
+++ b/drivers/net/wireless/hostap/hostap_plx.c
@@ -67,10 +67,12 @@ static struct pci_device_id prism2_plx_i
 	PLXDEV(0x10b7, 0x7770, "3Com AirConnect PCI 777A"),
 	PLXDEV(0x111a, 0x1023, "Siemens SpeedStream SS1023"),
 	PLXDEV(0x126c, 0x8030, "Nortel emobility"),
+	PLXDEV(0x1562, 0x0001, "Symbol LA-4123"),
 	PLXDEV(0x1385, 0x4100, "Netgear MA301"),
 	PLXDEV(0x15e8, 0x0130, "National Datacomm NCP130 (PLX9052)"),
 	PLXDEV(0x15e8, 0x0131, "National Datacomm NCP130 (TMD7160)"),
 	PLXDEV(0x1638, 0x1100, "Eumitcom WL11000"),
+	PLXDEV(0x16ab, 0x1100, "Global Sun Tech GL24110P"),
 	PLXDEV(0x16ab, 0x1101, "Global Sun Tech GL24110P (?)"),
 	PLXDEV(0x16ab, 0x1102, "Linksys WPC11 with WDT11"),
 	PLXDEV(0x16ab, 0x1103, "Longshine 8031"),
diff --git a/include/net/ieee80211softmac.h b/include/net/ieee80211softmac.h
index 7a483ab..00ad810 100644
--- a/include/net/ieee80211softmac.h
+++ b/include/net/ieee80211softmac.h
@@ -104,6 +104,7 @@ struct ieee80211softmac_assoc_info {
 	 */
 	u8 static_essid:1,
 	   associating:1,
+	   assoc_wait:1,
 	   bssvalid:1,
 	   bssfixed:1;
 
diff --git a/net/ieee80211/ieee80211_rx.c b/net/ieee80211/ieee80211_rx.c
index 2bf567f..b2fabbb 100644
--- a/net/ieee80211/ieee80211_rx.c
+++ b/net/ieee80211/ieee80211_rx.c
@@ -369,6 +369,7 @@ #endif
 
 	/* Put this code here so that we avoid duplicating it in all
 	 * Rx paths. - Jean II */
+#ifdef CONFIG_WIRELESS_EXT
 #ifdef IW_WIRELESS_SPY		/* defined in iw_handler.h */
 	/* If spy monitoring on */
 	if (ieee->spy_data.spy_number > 0) {
@@ -397,15 +398,16 @@ #ifdef IW_WIRELESS_SPY		/* defined in iw
 		wireless_spy_update(ieee->dev, hdr->addr2, &wstats);
 	}
 #endif				/* IW_WIRELESS_SPY */
+#endif				/* CONFIG_WIRELESS_EXT */
 
 #ifdef NOT_YET
 	hostap_update_rx_stats(local->ap, hdr, rx_stats);
 #endif
 
 	if (ieee->iw_mode == IW_MODE_MONITOR) {
-		ieee80211_monitor_rx(ieee, skb, rx_stats);
 		stats->rx_packets++;
 		stats->rx_bytes += skb->len;
+		ieee80211_monitor_rx(ieee, skb, rx_stats);
 		return 1;
 	}
 
diff --git a/net/ieee80211/ieee80211_tx.c b/net/ieee80211/ieee80211_tx.c
index 6a5de1b..e63bf77 100644
--- a/net/ieee80211/ieee80211_tx.c
+++ b/net/ieee80211/ieee80211_tx.c
@@ -563,10 +563,13 @@ int ieee80211_tx_frame(struct ieee80211_
 	struct net_device_stats *stats = &ieee->stats;
 	struct sk_buff *skb_frag;
 	int priority = -1;
+	int fraglen = total_len;
+	int headroom = ieee->tx_headroom;
+	struct ieee80211_crypt_data *crypt = ieee->crypt[ieee->tx_keyidx];
 
 	spin_lock_irqsave(&ieee->lock, flags);
 
-	if (encrypt_mpdu && !ieee->sec.encrypt)
+	if (encrypt_mpdu && (!ieee->sec.encrypt || !crypt))
 		encrypt_mpdu = 0;
 
 	/* If there is no driver handler to take the TXB, dont' bother
@@ -582,20 +585,24 @@ int ieee80211_tx_frame(struct ieee80211_
 		goto success;
 	}
 
-	if (encrypt_mpdu)
+	if (encrypt_mpdu) {
 		frame->frame_ctl |= cpu_to_le16(IEEE80211_FCTL_PROTECTED);
+		fraglen += crypt->ops->extra_mpdu_prefix_len +
+			   crypt->ops->extra_mpdu_postfix_len;
+		headroom += crypt->ops->extra_mpdu_prefix_len;
+	}
 
 	/* When we allocate the TXB we allocate enough space for the reserve
 	 * and full fragment bytes (bytes_per_frag doesn't include prefix,
 	 * postfix, header, FCS, etc.) */
-	txb = ieee80211_alloc_txb(1, total_len, ieee->tx_headroom, GFP_ATOMIC);
+	txb = ieee80211_alloc_txb(1, fraglen, headroom, GFP_ATOMIC);
 	if (unlikely(!txb)) {
 		printk(KERN_WARNING "%s: Could not allocate TXB\n",
 		       ieee->dev->name);
 		goto failed;
 	}
 	txb->encrypted = 0;
-	txb->payload_size = total_len;
+	txb->payload_size = fraglen;
 
 	skb_frag = txb->fragments[0];
 
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index 5e9a906..44215ce 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -47,9 +47,7 @@ ieee80211softmac_assoc(struct ieee80211s
 	
 	dprintk(KERN_INFO PFX "sent association request!\n");
 
-	/* Change the state to associating */
 	spin_lock_irqsave(&mac->lock, flags);
-	mac->associnfo.associating = 1;
 	mac->associated = 0; /* just to make sure */
 
 	/* Set a timer for timeout */
@@ -63,6 +61,7 @@ void
 ieee80211softmac_assoc_timeout(void *d)
 {
 	struct ieee80211softmac_device *mac = (struct ieee80211softmac_device *)d;
+	struct ieee80211softmac_network *n;
 	unsigned long flags;
 
 	spin_lock_irqsave(&mac->lock, flags);
@@ -75,11 +74,12 @@ ieee80211softmac_assoc_timeout(void *d)
 	mac->associnfo.associating = 0;
 	mac->associnfo.bssvalid = 0;
 	mac->associated = 0;
+
+	n = ieee80211softmac_get_network_by_bssid_locked(mac, mac->associnfo.bssid);
 	spin_unlock_irqrestore(&mac->lock, flags);
 
 	dprintk(KERN_INFO PFX "assoc request timed out!\n");
-	/* FIXME: we need to know the network here. that requires a bit of restructuring */
-	ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, NULL);
+	ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, n);
 }
 
 void
@@ -203,6 +203,10 @@ ieee80211softmac_assoc_work(void *d)
 	if (mac->associated)
 		ieee80211softmac_send_disassoc_req(mac, WLAN_REASON_DISASSOC_STA_HAS_LEFT);
 
+	spin_lock_irqsave(&mac->lock, flags);
+	mac->associnfo.associating = 1;
+	spin_unlock_irqrestore(&mac->lock, flags);
+
 	/* try to find the requested network in our list, if we found one already */
 	if (bssvalid || mac->associnfo.bssfixed)
 		found = ieee80211softmac_get_network_by_bssid(mac, mac->associnfo.bssid);	
@@ -295,19 +299,32 @@ ieee80211softmac_assoc_work(void *d)
 	memcpy(mac->associnfo.associate_essid.data, found->essid.data, IW_ESSID_MAX_SIZE + 1);
 	
 	/* we found a network! authenticate (if necessary) and associate to it. */
-	if (!found->authenticated) {
+	if (found->authenticating) {
+		dprintk(KERN_INFO PFX "Already requested authentication, waiting...\n");
+		if(!mac->associnfo.assoc_wait) {
+			mac->associnfo.assoc_wait = 1;
+			ieee80211softmac_notify_internal(mac, IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify_auth, NULL, GFP_KERNEL);
+		}
+		return;
+	}
+	if (!found->authenticated && !found->authenticating) {
 		/* This relies on the fact that _auth_req only queues the work,
 		 * otherwise adding the notification would be racy. */
 		if (!ieee80211softmac_auth_req(mac, found)) {
-			dprintk(KERN_INFO PFX "cannot associate without being authenticated, requested authentication\n");
-			ieee80211softmac_notify_internal(mac, IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify_auth, NULL, GFP_KERNEL);
+			if(!mac->associnfo.assoc_wait) {
+				dprintk(KERN_INFO PFX "Cannot associate without being authenticated, requested authentication\n");
+				mac->associnfo.assoc_wait = 1;
+				ieee80211softmac_notify_internal(mac, IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify_auth, NULL, GFP_KERNEL);
+			}
 		} else {
 			printkl(KERN_WARNING PFX "Not authenticated, but requesting authentication failed. Giving up to associate\n");
+			mac->associnfo.assoc_wait = 0;
 			ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_FAILED, found);
 		}
 		return;
 	}
 	/* finally! now we can start associating */
+	mac->associnfo.assoc_wait = 0;
 	ieee80211softmac_assoc(mac, found);
 }
 
diff --git a/net/ieee80211/softmac/ieee80211softmac_auth.c b/net/ieee80211/softmac/ieee80211softmac_auth.c
index 90b8484..ebc33ca 100644
--- a/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ b/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -36,8 +36,9 @@ ieee80211softmac_auth_req(struct ieee802
 	struct ieee80211softmac_auth_queue_item *auth;
 	unsigned long flags;
 	
-	if (net->authenticating)
+	if (net->authenticating || net->authenticated)
 		return 0;
+	net->authenticating = 1;
 
 	/* Add the network if it's not already added */
 	ieee80211softmac_add_network(mac, net);
@@ -92,7 +93,6 @@ ieee80211softmac_auth_queue(void *data)
 			return;
 		}
 		net->authenticated = 0;
-		net->authenticating = 1;
 		/* add a timeout call so we eventually give up waiting for an auth reply */
 		schedule_delayed_work(&auth->work, IEEE80211SOFTMAC_AUTH_TIMEOUT);
 		auth->retry--;
diff --git a/net/ieee80211/softmac/ieee80211softmac_io.c b/net/ieee80211/softmac/ieee80211softmac_io.c
index 0954161..8cc8b20 100644
--- a/net/ieee80211/softmac/ieee80211softmac_io.c
+++ b/net/ieee80211/softmac/ieee80211softmac_io.c
@@ -229,6 +229,9 @@ ieee80211softmac_assoc_req(struct ieee80
 		return 0;
 	ieee80211softmac_hdr_3addr(mac, &((*pkt)->header), IEEE80211_STYPE_ASSOC_REQ, net->bssid, net->bssid);
 
+	/* Fill in the capabilities */
+	(*pkt)->capability = ieee80211softmac_capabilities(mac, net);
+
 	/* Fill in Listen Interval (?) */
 	(*pkt)->listen_interval = cpu_to_le16(10);
 	
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 0e65ff4..75320b6 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -70,12 +70,44 @@ ieee80211softmac_wx_set_essid(struct net
 			      char *extra)
 {
 	struct ieee80211softmac_device *sm = ieee80211_priv(net_dev);
+	struct ieee80211softmac_network *n;
+	struct ieee80211softmac_auth_queue_item *authptr;
 	int length = 0;
 	unsigned long flags;
-	
+
+	/* Check if we're already associating to this or another network
+	 * If it's another network, cancel and start over with our new network
+	 * If it's our network, ignore the change, we're already doing it!
+	 */
+	if((sm->associnfo.associating || sm->associated) &&
+	   (data->essid.flags && data->essid.length && extra)) {
+		/* Get the associating network */
+		n = ieee80211softmac_get_network_by_bssid(sm, sm->associnfo.bssid);
+		if(n && n->essid.len == (data->essid.length - 1) &&
+		   !memcmp(n->essid.data, extra, n->essid.len)) {
+			dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
+				MAC_ARG(sm->associnfo.bssid));
+			return 0;
+		} else {
+			dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
+			spin_lock_irqsave(&sm->lock,flags);
+			/* Cancel assoc work */
+			cancel_delayed_work(&sm->associnfo.work);
+			/* We don't have to do this, but it's a little cleaner */
+			list_for_each_entry(authptr, &sm->auth_queue, list)
+				cancel_delayed_work(&authptr->work);
+			sm->associnfo.bssvalid = 0;
+			sm->associnfo.bssfixed = 0;
+			spin_unlock_irqrestore(&sm->lock,flags);
+			flush_scheduled_work();
+		}
+	}
+
+
 	spin_lock_irqsave(&sm->lock, flags);
-	
+
 	sm->associnfo.static_essid = 0;
+	sm->associnfo.assoc_wait = 0;
 
 	if (data->essid.flags && data->essid.length && extra /*required?*/) {
 		length = min(data->essid.length - 1, IW_ESSID_MAX_SIZE);
-- 
John W. Linville
linville@tuxdriver.com

Re: Please pull 'upstream' branch of wireless-2.6

[Jeff Garzik]

John W. Linville wrote:
> +	assert(bcm->mac_suspended >= 0);
> +	if (bcm->mac_suspended == 0) {
> +		bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
> +		bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
> +		                bcm43xx_read32(bcm, BCM43xx_MMIO_STATUS_BITFIELD)
> +				& ~BCM43xx_SBF_MAC_ENABLED);
> +		bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy read */
> +		for (i = 100000; i; i--) {
> +			tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
> +			if (tmp & BCM43xx_IRQ_READY)
> +				goto out;
> +			udelay(10);
> +		}
> +		printkl(KERN_ERR PFX "MAC suspend failed\n");
>  	}


NAK this super-long delay...  should be done in a workqueue, looks like?

ACK everything else.

	Jeff

Re: Please pull 'upstream' branch of wireless-2.6

[Larry Finger]

Jeff Garzik wrote:
> John W. Linville wrote:
>> +    assert(bcm->mac_suspended >= 0);
>> +    if (bcm->mac_suspended == 0) {
>> +        bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
>> +        bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
>> +                        bcm43xx_read32(bcm, 
>> BCM43xx_MMIO_STATUS_BITFIELD)
>> +                & ~BCM43xx_SBF_MAC_ENABLED);
>> +        bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy 
>> read */
>> +        for (i = 100000; i; i--) {
>> +            tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
>> +            if (tmp & BCM43xx_IRQ_READY)
>> +                goto out;
>> +            udelay(10);
>> +        }
>> +        printkl(KERN_ERR PFX "MAC suspend failed\n");
>>      }
> 
> 
> NAK this super-long delay...  should be done in a workqueue, looks like?
> 
> ACK everything else.
> 

That delay was set to try to accommodate my interface when it refused to suspend the MAC, which 
resulted in transmit errors. That problem has since been cured by reworking the periodic work 
handlers - thus such a long delay should not be needed. The original spec from the clean-room group 
was a delay loop of 1000. I'm currently testing that value now. If it passes the test, would a for 
(i=1000; i; i--) be acceptable?

Larry

Re: Please pull 'upstream' branch of wireless-2.6

[Jeff Garzik]

Larry Finger wrote:
> Jeff Garzik wrote:
>> John W. Linville wrote:
>>> +    assert(bcm->mac_suspended >= 0);
>>> +    if (bcm->mac_suspended == 0) {
>>> +        bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
>>> +        bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
>>> +                        bcm43xx_read32(bcm, 
>>> BCM43xx_MMIO_STATUS_BITFIELD)
>>> +                & ~BCM43xx_SBF_MAC_ENABLED);
>>> +        bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy 
>>> read */
>>> +        for (i = 100000; i; i--) {
>>> +            tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
>>> +            if (tmp & BCM43xx_IRQ_READY)
>>> +                goto out;
>>> +            udelay(10);
>>> +        }
>>> +        printkl(KERN_ERR PFX "MAC suspend failed\n");
>>>      }
>>
>>
>> NAK this super-long delay...  should be done in a workqueue, looks like?
>>
>> ACK everything else.
>>
> 
> That delay was set to try to accommodate my interface when it refused to 
> suspend the MAC, which resulted in transmit errors. That problem has 
> since been cured by reworking the periodic work handlers - thus such a 
> long delay should not be needed. The original spec from the clean-room 
> group was a delay loop of 1000. I'm currently testing that value now. If 
> it passes the test, would a for (i=1000; i; i--) be acceptable?

That's acceptable, yes, but it sounds like the problem has since been cured?

	Jeff

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 04:27, Larry Finger wrote:
> Jeff Garzik wrote:
> > John W. Linville wrote:
> >> +    assert(bcm->mac_suspended >= 0);
> >> +    if (bcm->mac_suspended == 0) {
> >> +        bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
> >> +        bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
> >> +                        bcm43xx_read32(bcm, 
> >> BCM43xx_MMIO_STATUS_BITFIELD)
> >> +                & ~BCM43xx_SBF_MAC_ENABLED);
> >> +        bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy 
> >> read */
> >> +        for (i = 100000; i; i--) {
> >> +            tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
> >> +            if (tmp & BCM43xx_IRQ_READY)
> >> +                goto out;
> >> +            udelay(10);
> >> +        }
> >> +        printkl(KERN_ERR PFX "MAC suspend failed\n");
> >>      }
> > 
> > 
> > NAK this super-long delay...  should be done in a workqueue, looks like?
> > 
> > ACK everything else.
> > 
> 
> That delay was set to try to accommodate my interface when it refused to suspend the MAC, which 
> resulted in transmit errors. That problem has since been cured by reworking the periodic work 
> handlers - thus such a long delay should not be needed. The original spec from the clean-room group 
> was a delay loop of 1000. I'm currently testing that value now. If it passes the test, would a for 
> (i=1000; i; i--) be acceptable?

Short: Don't touch it. Fullstop.

Long: The delay will _never_ be exhausted. Actually the for-counter
is only there to not lock up the machine, if there is a Bug in the
driver. (__much__ easier debugging).
The loop will only iterate a few times, typically.
Actually, _if_ we want to change something, we should do this:

for (i = 1000000; i; i--) {
	...
	udelay(1);
}

(max loop multiplied by 10, delay value divided by 10).
This will shorten the whole delay by a few usecs (up to 10).
I will send a patch for this, if it is desired.

But lowering the loop counter value is NACKed by me,
because it simply does not make sense.

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Jeff Garzik]

Michael Buesch wrote:
> On Tuesday 27 June 2006 04:27, Larry Finger wrote:
>> Jeff Garzik wrote:
>>> John W. Linville wrote:
>>>> +    assert(bcm->mac_suspended >= 0);
>>>> +    if (bcm->mac_suspended == 0) {
>>>> +        bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
>>>> +        bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
>>>> +                        bcm43xx_read32(bcm, 
>>>> BCM43xx_MMIO_STATUS_BITFIELD)
>>>> +                & ~BCM43xx_SBF_MAC_ENABLED);
>>>> +        bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy 
>>>> read */
>>>> +        for (i = 100000; i; i--) {
>>>> +            tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
>>>> +            if (tmp & BCM43xx_IRQ_READY)
>>>> +                goto out;
>>>> +            udelay(10);
>>>> +        }
>>>> +        printkl(KERN_ERR PFX "MAC suspend failed\n");
>>>>      }
>>>
>>> NAK this super-long delay...  should be done in a workqueue, looks like?
>>>
>>> ACK everything else.
>>>
>> That delay was set to try to accommodate my interface when it refused to suspend the MAC, which 
>> resulted in transmit errors. That problem has since been cured by reworking the periodic work 
>> handlers - thus such a long delay should not be needed. The original spec from the clean-room group 
>> was a delay loop of 1000. I'm currently testing that value now. If it passes the test, would a for 
>> (i=1000; i; i--) be acceptable?
> 
> Short: Don't touch it. Fullstop.
> 
> Long: The delay will _never_ be exhausted. Actually the for-counter
> is only there to not lock up the machine, if there is a Bug in the
> driver. (__much__ easier debugging).
> The loop will only iterate a few times, typically.
> Actually, _if_ we want to change something, we should do this:
> 
> for (i = 1000000; i; i--) {
> 	...
> 	udelay(1);
> }
> 
> (max loop multiplied by 10, delay value divided by 10).
> This will shorten the whole delay by a few usecs (up to 10).
> I will send a patch for this, if it is desired.
> 
> But lowering the loop counter value is NACKed by me,
> because it simply does not make sense.


My overriding concern was that this type of loop spins the CPU at 100% 
until the hardware condition is satisfied, which starves all other 
kernel work on that CPU, and is very unfriendly to power consumption 
(though I believe monitor/mwait/cpu_relax helps on x86).

Overall, bcm43xx is _really really bad_ about this sort of thing.  Just 
grepping for udelay in bcm43xx_radio.c shows some of the worst 
offenders.  bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel() 
both look like candidates for using msleep() rather than udelay().

	Jeff

Re: Please pull 'upstream' branch of wireless-2.6

[Larry Finger]

Jeff Garzik wrote:
> Michael Buesch wrote:
>>
>> Short: Don't touch it. Fullstop.
>>
>> Long: The delay will _never_ be exhausted. Actually the for-counter
>> is only there to not lock up the machine, if there is a Bug in the
>> driver. (__much__ easier debugging).
>> The loop will only iterate a few times, typically.
>> Actually, _if_ we want to change something, we should do this:
>>
>> for (i = 1000000; i; i--) {
>>     ...
>>     udelay(1);
>> }
>>
>> (max loop multiplied by 10, delay value divided by 10).
>> This will shorten the whole delay by a few usecs (up to 10).
>> I will send a patch for this, if it is desired.
>>
>> But lowering the loop counter value is NACKed by me,
>> because it simply does not make sense.
> 
> 
> My overriding concern was that this type of loop spins the CPU at 100% 
> until the hardware condition is satisfied, which starves all other 
> kernel work on that CPU, and is very unfriendly to power consumption 
> (though I believe monitor/mwait/cpu_relax helps on x86).
> 
> Overall, bcm43xx is _really really bad_ about this sort of thing.  Just 
> grepping for udelay in bcm43xx_radio.c shows some of the worst 
> offenders.  bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel() 
> both look like candidates for using msleep() rather than udelay().

It is not my place to get into the middle of this discussion; however, my interface has been pinging 
my AP for over 12 hours with the loop counter starting at 1000. I get the usual log entries for the 
hourly TKIP changes, but no MAC suspend failures.

Larry

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 04:27, Larry Finger wrote:
> >> Jeff Garzik wrote:
> >>> John W. Linville wrote:
> >>>> +    assert(bcm->mac_suspended >= 0);
> >>>> +    if (bcm->mac_suspended == 0) {
> >>>> +        bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
> >>>> +        bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
> >>>> +                        bcm43xx_read32(bcm, 
> >>>> BCM43xx_MMIO_STATUS_BITFIELD)
> >>>> +                & ~BCM43xx_SBF_MAC_ENABLED);
> >>>> +        bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy 
> >>>> read */
> >>>> +        for (i = 100000; i; i--) {
> >>>> +            tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
> >>>> +            if (tmp & BCM43xx_IRQ_READY)
> >>>> +                goto out;
> >>>> +            udelay(10);
> >>>> +        }
> >>>> +        printkl(KERN_ERR PFX "MAC suspend failed\n");
> >>>>      }
> >>>
> >>> NAK this super-long delay...  should be done in a workqueue, looks like?
> >>>
> >>> ACK everything else.
> >>>
> >> That delay was set to try to accommodate my interface when it refused to suspend the MAC, which 
> >> resulted in transmit errors. That problem has since been cured by reworking the periodic work 
> >> handlers - thus such a long delay should not be needed. The original spec from the clean-room group 
> >> was a delay loop of 1000. I'm currently testing that value now. If it passes the test, would a for 
> >> (i=1000; i; i--) be acceptable?
> > 
> > Short: Don't touch it. Fullstop.
> > 
> > Long: The delay will _never_ be exhausted. Actually the for-counter
> > is only there to not lock up the machine, if there is a Bug in the
> > driver. (__much__ easier debugging).
> > The loop will only iterate a few times, typically.
> > Actually, _if_ we want to change something, we should do this:
> > 
> > for (i = 1000000; i; i--) {
> > 	...
> > 	udelay(1);
> > }
> > 
> > (max loop multiplied by 10, delay value divided by 10).
> > This will shorten the whole delay by a few usecs (up to 10).
> > I will send a patch for this, if it is desired.
> > 
> > But lowering the loop counter value is NACKed by me,
> > because it simply does not make sense.
> 
> 
> My overriding concern was that this type of loop spins the CPU at 100% 
> until the hardware condition is satisfied, which starves all other 
> kernel work on that CPU, and is very unfriendly to power consumption 
> (though I believe monitor/mwait/cpu_relax helps on x86).
> 
> Overall, bcm43xx is _really really bad_ about this sort of thing.  Just 
> grepping for udelay in bcm43xx_radio.c shows some of the worst 
> offenders.  bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel() 
> both look like candidates for using msleep() rather than udelay().

This is _all_ at initialization time.
select_channel.... How often do you select a channel?

I recently reworked the periodically exectuted workhandlers,
so that they are preemptible.

mac_suspend():
It is always called in atomic context with IRQs disabled.
We need to wait for the device here to signal "OK, MAC is down
now and you can count on it". This takes a few usecs. I guess
it sends out all queued packets, or whatever. We don't know
really.
I can actually measure how long it takes, if you really desire
it.
We _need_ to wait there. It is something like synchronize_irq(), or
whatever. It is a synchronizing function and we need it to be
synchronizing.
And I don't think it is worth the pain to insert a preemption
point there (or doing even fancier things with workqueues and
completions).

Overall, I don't think bcm43xx is still so bad at
wasting CPU. Maybe we should still insert some voluntary
preemption points, if the bcm43xx user does not run a fully
preemptible kernel. But if a fully preemptible kernel is run,
I think it is all OK.

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Jeff Garzik]

Michael Buesch wrote:
> On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
>> Overall, bcm43xx is _really really bad_ about this sort of thing.  Just 
>> grepping for udelay in bcm43xx_radio.c shows some of the worst 
>> offenders.  bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel() 
>> both look like candidates for using msleep() rather than udelay().
> 
> This is _all_ at initialization time.
> select_channel.... How often do you select a channel?

That question is irrelevant, because you have no idea what -else- is 
going on in the system, at the point when bcm43xx chooses to spin the 
CPU heavily.

Initialization time means you are definitely not in a hot path, and can 
therefore sleep.


> I recently reworked the periodically exectuted workhandlers,
> so that they are preemptible.

Major classes of users run their kernels without preempt.  Please don't 
depend on that to avoid bad behavior.


> mac_suspend():
> It is always called in atomic context with IRQs disabled.
> We need to wait for the device here to signal "OK, MAC is down
> now and you can count on it". This takes a few usecs. I guess
> it sends out all queued packets, or whatever. We don't know
> really.
> I can actually measure how long it takes, if you really desire
> it.
> We _need_ to wait there. It is something like synchronize_irq(), or
> whatever. It is a synchronizing function and we need it to be
> synchronizing.
> And I don't think it is worth the pain to insert a preemption
> point there (or doing even fancier things with workqueues and
> completions).
> 
> Overall, I don't think bcm43xx is still so bad at
> wasting CPU. Maybe we should still insert some voluntary
> preemption points, if the bcm43xx user does not run a fully
> preemptible kernel. But if a fully preemptible kernel is run,
> I think it is all OK.

Never assume a preemptible kernel will clean up problems for you :)

	Jeff

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 18:10, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> >> Overall, bcm43xx is _really really bad_ about this sort of thing.  Just 
> >> grepping for udelay in bcm43xx_radio.c shows some of the worst 
> >> offenders.  bcm43xx_radio_init2060() and bcm43xx_radio_selectchannel() 
> >> both look like candidates for using msleep() rather than udelay().
> > 
> > This is _all_ at initialization time.
> > select_channel.... How often do you select a channel?
> 
> That question is irrelevant, because you have no idea what -else- is 
> going on in the system, at the point when bcm43xx chooses to spin the 
> CPU heavily.
> 
> Initialization time means you are definitely not in a hot path, and can 
> therefore sleep.

Ok, again:
If you are running a preemptible kernel (I am doing a patch for the
non-preemptible case), everything is _already_ fine.
We are not spinning long times with locks held or IRQs disabled.
I already fixed that.

And no, I don't really care for initialization time.
I am not going to potentially break the driver to remove
1ms of wasted CPU on ifconfig up.
In fact, initialization is and always was done lockless.
So we should be fine there, too, actually.

We don't know why these delays are there all. And we never will.
But as this are all some measuring an calibration routines,
they surely have some purpose. We don't know if longer delays
in some places may have ill effects. Making the whole thing
preemptible (as I am doing / have done) surely has its potential
to break the driver.

I prefer correct operation over an unnoticable 1ms CPU hog.

> > I recently reworked the periodically exectuted workhandlers,
> > so that they are preemptible.
> 
> Major classes of users run their kernels without preempt.  Please don't 
> depend on that to avoid bad behavior.

I am doing a patch atm.
I will add voluntary preemption points, if the kernel is not preemptible.

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 16:11, Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 04:27, Larry Finger wrote:
> >> Jeff Garzik wrote:
> >>> John W. Linville wrote:
> >>>> +    assert(bcm->mac_suspended >= 0);
> >>>> +    if (bcm->mac_suspended == 0) {
> >>>> +        bcm43xx_power_saving_ctl_bits(bcm, -1, 1);
> >>>> +        bcm43xx_write32(bcm, BCM43xx_MMIO_STATUS_BITFIELD,
> >>>> +                        bcm43xx_read32(bcm, 
> >>>> BCM43xx_MMIO_STATUS_BITFIELD)
> >>>> +                & ~BCM43xx_SBF_MAC_ENABLED);
> >>>> +        bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON); /* dummy 
> >>>> read */
> >>>> +        for (i = 100000; i; i--) {
> >>>> +            tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
> >>>> +            if (tmp & BCM43xx_IRQ_READY)
> >>>> +                goto out;
> >>>> +            udelay(10);
> >>>> +        }
> >>>> +        printkl(KERN_ERR PFX "MAC suspend failed\n");
> >>>>      }
> >>>
> >>> NAK this super-long delay...  should be done in a workqueue, looks like?
> >>>
> >>> ACK everything else.
> >>>
> >> That delay was set to try to accommodate my interface when it refused to suspend the MAC, which 
> >> resulted in transmit errors. That problem has since been cured by reworking the periodic work 
> >> handlers - thus such a long delay should not be needed. The original spec from the clean-room group 
> >> was a delay loop of 1000. I'm currently testing that value now. If it passes the test, would a for 
> >> (i=1000; i; i--) be acceptable?
> > 
> > Short: Don't touch it. Fullstop.
> > 
> > Long: The delay will _never_ be exhausted. Actually the for-counter
> > is only there to not lock up the machine, if there is a Bug in the
> > driver. (__much__ easier debugging).
> > The loop will only iterate a few times, typically.
> > Actually, _if_ we want to change something, we should do this:
> > 
> > for (i = 1000000; i; i--) {
> > 	...
> > 	udelay(1);
> > }
> > 
> > (max loop multiplied by 10, delay value divided by 10).
> > This will shorten the whole delay by a few usecs (up to 10).
> > I will send a patch for this, if it is desired.
> > 
> > But lowering the loop counter value is NACKed by me,
> > because it simply does not make sense.
> 
> 
> My overriding concern was that this type of loop spins the CPU at 100% 
> until the hardware condition is satisfied, which starves all other 
> kernel work on that CPU, and is very unfriendly to power consumption 
> (though I believe monitor/mwait/cpu_relax helps on x86).

Ok, I did a testrun. Here's the result:

[   68.711243] bcm43xx_d80211: Chip ID 0x4306, rev 0x3
[   68.712662] bcm43xx_d80211: Number of cores: 5
[   68.714023] bcm43xx_d80211: Core 0: ID 0x800, rev 0x4, vendor 0x4243, enabled
[   68.715536] bcm43xx_d80211: Core 1: ID 0x812, rev 0x5, vendor 0x4243, disabled
[   68.717062] bcm43xx_d80211: Core 2: ID 0x80d, rev 0x2, vendor 0x4243, enabled
[   68.718575] bcm43xx_d80211: Core 3: ID 0x807, rev 0x2, vendor 0x4243, disabled
[   68.720089] bcm43xx_d80211: Core 4: ID 0x804, rev 0x9, vendor 0x4243, enabled
[   68.724897] bcm43xx_d80211: PHY connected
[   68.726154] bcm43xx_d80211: Detected PHY: Version: 2, Type 2, Revision 2
[   68.727638] bcm43xx_d80211: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
[   68.729232] bcm43xx_d80211: Radio turned off
[   68.730512] bcm43xx_d80211: Radio turned off
[   68.745153] wmaster0: Selected rate control algorithm 'simple'
[   69.853876] bcm43xx_d80211: Virtual interface added (type: 0x00000002, ID: 7, MAC: 00:11:24:a0:de:8b)
[   69.861872] bcm43xx_d80211: PHY connected
[   70.000713] bcm43xx_d80211: Radio turned on
[   70.190153] bcm43xx_d80211: Chip initialized
[   70.192051] bcm43xx_d80211: DMA initialized
[   70.193987] bcm43xx_d80211: 80211 cores initialized
[   70.195550] bcm43xx_d80211: Keys cleared
[   70.212565] wmaster0: Does not support passive scan, disabled
[   70.252321] bcm43xx_d80211: mac_suspend() took 1 loops == 10 usec
[   70.542160] NET: Registered protocol family 17
[   70.692256] sta0: starting scan
[   70.702234] HW CONFIG: channel=1 freq=2412 phymode=3
[   70.762225] HW CONFIG: channel=2 freq=2417 phymode=3
[   70.822227] HW CONFIG: channel=3 freq=2422 phymode=3
[   70.882225] HW CONFIG: channel=4 freq=2427 phymode=3
[   70.942225] HW CONFIG: channel=5 freq=2432 phymode=3
[   71.002285] HW CONFIG: channel=6 freq=2437 phymode=3
[   71.062229] HW CONFIG: channel=7 freq=2442 phymode=3
[   71.122230] HW CONFIG: channel=8 freq=2447 phymode=3
[   71.182239] HW CONFIG: channel=9 freq=2452 phymode=3
[   71.242226] HW CONFIG: channel=10 freq=2457 phymode=3
[   71.302226] HW CONFIG: channel=11 freq=2462 phymode=3
[   71.512225] HW CONFIG: channel=1 freq=2412 phymode=3
[   71.520066] sta0: scan completed
[   71.523437] HW CONFIG: channel=6 freq=2437 phymode=3
[   71.531600] sta0: Initial auth_alg=0
[   71.531806] sta0: authenticate with AP 00:90:4c:60:04:00
[   71.533279] sta0: RX authentication from 00:90:4c:60:04:00 (alg=0 transaction=2 status=0)
[   71.533292] sta0: authenticated
[   71.533301] sta0: associate with AP 00:90:4c:60:04:00
[   71.536264] sta0: RX AssocResp from 00:90:4c:60:04:00 (capab=0x411 status=0 aid=1)
[   71.536276] sta0: associated
[   71.536352] wmaster0: Added STA 00:90:4c:60:04:00
[  130.292251] bcm43xx_d80211: mac_suspend() took 1 loops == 10 usec
[  190.322251] bcm43xx_d80211: mac_suspend() took 1 loops == 10 usec
[  250.362252] bcm43xx_d80211: mac_suspend() took 0 loops == 0 usec
[  310.392278] bcm43xx_d80211: mac_suspend() took 1 loops == 10 usec

So, I will submit a patch to lower the udelay(10) to udelay(1)
and we can close the discussion? ;)

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Jeff Garzik]

Michael Buesch wrote:
> So, I will submit a patch to lower the udelay(10) to udelay(1)
> and we can close the discussion? ;)

No, that totally avoids my point.  Your "otherwise idle machine" test is 
probably nowhere near worst case in the field, for loops that can 
potentially lock the CPU for a long time upon hardware fault.  And then 
there are the huge delays in specific functions that I pointed out...

	Jeff

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> Michael Buesch wrote:
> > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > and we can close the discussion? ;)
> 
> No, that totally avoids my point.  Your "otherwise idle machine" test is 
> probably nowhere near worst case in the field, for loops that can 
> potentially lock the CPU for a long time upon hardware fault.  And then 
> there are the huge delays in specific functions that I pointed out...

wtf are you requesting from me?
1) I proved you that the loop does only spin _once_ or even _less_.
2) If the hardware is faulty, the user must replace it.
   Because, if the hardware is faulty, it can crash the whole
   machine anyway, obviously.

3) There is no "huge delay". I proved it with my logs.
   -> No CPU hog => Nothing to fix.

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[John W. Linville]

On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
> On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> > Michael Buesch wrote:
> > > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > > and we can close the discussion? ;)
> > 
> > No, that totally avoids my point.  Your "otherwise idle machine" test is 
> > probably nowhere near worst case in the field, for loops that can 
> > potentially lock the CPU for a long time upon hardware fault.  And then 
> > there are the huge delays in specific functions that I pointed out...
> 
> wtf are you requesting from me?
> 1) I proved you that the loop does only spin _once_ or even _less_.
> 2) If the hardware is faulty, the user must replace it.
>    Because, if the hardware is faulty, it can crash the whole
>    machine anyway, obviously.
> 
> 3) There is no "huge delay". I proved it with my logs.
>    -> No CPU hog => Nothing to fix.

Michael,

I think Jeff's concern is that by using udelay you are busy-waiting.
And, the for loop limit of 100000 means you could freeze the kernel
for up to a whole second.  Granted that this won't happen very often
and in the grand scheme of things a second isn't all _that_ long,
but still it would be better to avoid a delay like that -- a second
could be the time it takes to avoid a meltdown at the nuclear power
plant. :-)

Could you not use msleep instead of udelay (and scale the for loop
appropriately)?  What would be the problem with that?  It would get
rid of the busy waiting.

To be fair, this code was already in the driver and was only being
moved by this patch.  Still, what better time to fix it than now? :-)

I'll go ahead and reshuffle wireless-2.6 to drop this patch.  A new
patch that passes muster w/ Jeff will be most welcome! :-)

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 21:33, John W. Linville wrote:
> On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
> > On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
> > > Michael Buesch wrote:
> > > > So, I will submit a patch to lower the udelay(10) to udelay(1)
> > > > and we can close the discussion? ;)
> > > 
> > > No, that totally avoids my point.  Your "otherwise idle machine" test is 
> > > probably nowhere near worst case in the field, for loops that can 
> > > potentially lock the CPU for a long time upon hardware fault.  And then 
> > > there are the huge delays in specific functions that I pointed out...
> > 
> > wtf are you requesting from me?
> > 1) I proved you that the loop does only spin _once_ or even _less_.
> > 2) If the hardware is faulty, the user must replace it.
> >    Because, if the hardware is faulty, it can crash the whole
> >    machine anyway, obviously.
> > 
> > 3) There is no "huge delay". I proved it with my logs.
> >    -> No CPU hog => Nothing to fix.
> 
> Michael,
> 
> I think Jeff's concern is that by using udelay you are busy-waiting.
> And, the for loop limit of 100000 means you could freeze the kernel
> for up to a whole second.  Granted that this won't happen very often

s/very often/ever/

It won't happen, as long as the driver is not buggy, or the device
is hardware broken. So, if it happens, something has to be fixed.
In fact, it did happen _never_ for me.
If it triggers, the device does not work _at all_ anyway.

> and in the grand scheme of things a second isn't all _that_ long,
> but still it would be better to avoid a delay like that -- a second
> could be the time it takes to avoid a meltdown at the nuclear power
> plant. :-)
> 
> Could you not use msleep instead of udelay (and scale the for loop
> appropriately)?  What would be the problem with that?  It would get
> rid of the busy waiting.

Becauses it horribly _increases_ the delay.
We "spin" for _at most_ 10 usecs here. Please always remember that.
We are talking about a 10 usec delay here. And I already sent a
patch to even reduce this to under 10 usec.

> To be fair, this code was already in the driver and was only being
> moved by this patch.  Still, what better time to fix it than now? :-)

If it ain't broken, don't fix it.

> I'll go ahead and reshuffle wireless-2.6 to drop this patch.  A new
> patch that passes muster w/ Jeff will be most welcome! :-)

A new patch won't appear, as there is no problem with this
delay.
Please don't drop anything and apply the following patch on top
of it:

--

Microoptimization:
This reduces the udelay in bcm43xx_mac_suspend.

Signed-off-by: Michael Buesch <mb@bu3sch.de>

Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c	2006-06-27 17:47:24.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c	2006-06-27 17:53:29.000000000 +0200
@@ -2328,7 +2328,7 @@
 			tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
 			if (tmp & BCM43xx_IRQ_READY)
 				goto out;
-			udelay(10);
+			udelay(1);
 		}
 		printkl(KERN_ERR PFX "MAC suspend failed\n");
 	}


-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Larry Finger]

Michael Buesch wrote:
> On Tuesday 27 June 2006 21:33, John W. Linville wrote:
>> On Tue, Jun 27, 2006 at 06:31:01PM +0200, Michael Buesch wrote:
>>> On Tuesday 27 June 2006 18:12, Jeff Garzik wrote:
>>>> Michael Buesch wrote:
>>>>> So, I will submit a patch to lower the udelay(10) to udelay(1)
>>>>> and we can close the discussion? ;)
>>>> No, that totally avoids my point.  Your "otherwise idle machine" test is 
>>>> probably nowhere near worst case in the field, for loops that can 
>>>> potentially lock the CPU for a long time upon hardware fault.  And then 
>>>> there are the huge delays in specific functions that I pointed out...
>>> wtf are you requesting from me?
>>> 1) I proved you that the loop does only spin _once_ or even _less_.
>>> 2) If the hardware is faulty, the user must replace it.
>>>    Because, if the hardware is faulty, it can crash the whole
>>>    machine anyway, obviously.
>>>
>>> 3) There is no "huge delay". I proved it with my logs.
>>>    -> No CPU hog => Nothing to fix.
>> Michael,
>>
>> I think Jeff's concern is that by using udelay you are busy-waiting.
>> And, the for loop limit of 100000 means you could freeze the kernel
>> for up to a whole second.  Granted that this won't happen very often
> 
> s/very often/ever/
> 
> It won't happen, as long as the driver is not buggy, or the device
> is hardware broken. So, if it happens, something has to be fixed.
> In fact, it did happen _never_ for me.
> If it triggers, the device does not work _at all_ anyway.
> 
>> and in the grand scheme of things a second isn't all _that_ long,
>> but still it would be better to avoid a delay like that -- a second
>> could be the time it takes to avoid a meltdown at the nuclear power
>> plant. :-)
>>
>> Could you not use msleep instead of udelay (and scale the for loop
>> appropriately)?  What would be the problem with that?  It would get
>> rid of the busy waiting.
> 
> Becauses it horribly _increases_ the delay.
> We "spin" for _at most_ 10 usecs here. Please always remember that.
> We are talking about a 10 usec delay here. And I already sent a
> patch to even reduce this to under 10 usec.
> 
>> To be fair, this code was already in the driver and was only being
>> moved by this patch.  Still, what better time to fix it than now? :-)
> 
> If it ain't broken, don't fix it.
> 
>> I'll go ahead and reshuffle wireless-2.6 to drop this patch.  A new
>> patch that passes muster w/ Jeff will be most welcome! :-)
> 
> A new patch won't appear, as there is no problem with this
> delay.
> Please don't drop anything and apply the following patch on top
> of it:

John,

I would like to find a diplomatic solution to this impasse between Michael and Jeff, which is why 
I'm writing to you privately. Michael is correct in that the loop in question will not usually delay 
long; however, on some hardware it takes longer than on his. On mine, I have seen delays as long as 
550 usec. In any case, I think that the following code fragment would work and pass Jeff's criticism:

for (i=5000; i; i--) {
	..........
	usleep(1);
}

This would make the worst-case delay be 5 msec, but would provide a cushion of 10X the longest I 
have seen and should be safe.

Do you have any suggestions on what should be done next?

Larry

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 22:06, Larry Finger wrote:
> John,
> 
> I would like to find a diplomatic solution to this impasse between Michael and Jeff, which is why 
> I'm writing to you privately. Michael is correct in that the loop in question will not usually delay 

private?

> long; however, on some hardware it takes longer than on his. On mine, I have seen delays as long as 
> 550 usec.

What's the chip?

> In any case, I think that the following code fragment would work and pass Jeff's criticism: 
> 
> for (i=5000; i; i--) {
> 	..........
> 	usleep(1);

usleep? Can't find that in my kernel tree.
In fact, I think the lowest possible sleep time
depends on HZ and is 1msec on 1000HZ.

Additionally, we are holding a spinlock at this time, so it is
not as easy as simply replacing udelay() by some sleeping function.

> This would make the worst-case delay be 5 msec, but would provide a cushion of 10X the longest I 
> have seen and should be safe.
> 
> Do you have any suggestions on what should be done next?

Leave it as is and find out why it takes so long for your strange card. ;)

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Larry Finger]

Michael Buesch wrote:
> On Tuesday 27 June 2006 22:06, Larry Finger wrote:
>> John,
>>
>> I would like to find a diplomatic solution to this impasse between Michael and Jeff, which is why 
>> I'm writing to you privately. Michael is correct in that the loop in question will not usually delay 
> 
> private?

I meant it to be private, but screwed up.

>> long; however, on some hardware it takes longer than on his. On mine, I have seen delays as long as 
>> 550 usec.
> 
> What's the chip?

bcm43xx: Chip ID 0x4306, rev 0x2
bcm43xx: Number of cores: 6
bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled
bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled
bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled
bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled
bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled
bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled
bcm43xx: Ignoring additional 802.11 core.
bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1
bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)

>> In any case, I think that the following code fragment would work and pass Jeff's criticism: 
>>
>> for (i=5000; i; i--) {
>> 	..........
>> 	usleep(1);
> 
> usleep? Can't find that in my kernel tree.
> In fact, I think the lowest possible sleep time
> depends on HZ and is 1msec on 1000HZ.

I meant udelay, of course.

> Additionally, we are holding a spinlock at this time, so it is
> not as easy as simply replacing udelay() by some sleeping function.

I know that.

>> This would make the worst-case delay be 5 msec, but would provide a cushion of 10X the longest I 
>> have seen and should be safe.
>>
>> Do you have any suggestions on what should be done next?
> 
> Leave it as is and find out why it takes so long for your strange card. ;)

I once offered you my second, duplicate card for testing, but never heard back. Do you have any 
ideas regarding diagnostics to see why it takes so long? Remember, this card used to time-out on the 
1 second delay before the periodic work was restructured.

Larry

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Tuesday 27 June 2006 22:37, Larry Finger wrote:
> Michael Buesch wrote:
> > On Tuesday 27 June 2006 22:06, Larry Finger wrote:
> >> John,
> >>
> >> I would like to find a diplomatic solution to this impasse between Michael and Jeff, which is why 
> >> I'm writing to you privately. Michael is correct in that the loop in question will not usually delay 
> > 
> > private?
> 
> I meant it to be private, but screwed up.
> 
> >> long; however, on some hardware it takes longer than on his. On mine, I have seen delays as long as 
> >> 550 usec.
> > 
> > What's the chip?
> 
> bcm43xx: Chip ID 0x4306, rev 0x2
> bcm43xx: Number of cores: 6
> bcm43xx: Core 0: ID 0x800, rev 0x2, vendor 0x4243, enabled
> bcm43xx: Core 1: ID 0x812, rev 0x4, vendor 0x4243, disabled
> bcm43xx: Core 2: ID 0x80d, rev 0x1, vendor 0x4243, enabled
> bcm43xx: Core 3: ID 0x807, rev 0x1, vendor 0x4243, disabled
> bcm43xx: Core 4: ID 0x804, rev 0x7, vendor 0x4243, enabled
> bcm43xx: Core 5: ID 0x812, rev 0x4, vendor 0x4243, disabled
> bcm43xx: Ignoring additional 802.11 core.
> bcm43xx: Detected PHY: Version: 1, Type 2, Revision 1
> bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)

It appears to be an older card. There are quite some
special codepaths for this, I think.

> >> This would make the worst-case delay be 5 msec, but would provide a cushion of 10X the longest I 
> >> have seen and should be safe.
> >>
> >> Do you have any suggestions on what should be done next?
> > 
> > Leave it as is and find out why it takes so long for your strange card. ;)
> 
> I once offered you my second, duplicate card for testing, but never heard back. Do you have any 
> ideas regarding diagnostics to see why it takes so long? Remember, this card used to time-out on the 
> 1 second delay before the periodic work was restructured.

Well, we did not want to have the card, because at this point
it did not make sense. We all have 4306 cards.
But now it appears that this card seems to have some special
things (because it is older than ours).

Well, how to debug.
We are waiting for the IRQ Reason register there.
Actually, we are waiting for the "no IRQ pending, but READY signal"
state. Your card does not completely (?) clear the bits after MAC
shutdown. So very helpful would be to print out in the loop the
value. We know, that the card generates silly IRQs, that we did
not ask for. That may happen here, too. So it _may_ help to
mask out unwanted IRQs before the if-check. But I would first
like to see a log of the reason-value on each iteration until it succeeds.

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Larry Finger]

Michael Buesch wrote:
> 
> It appears to be an older card. There are quite some
> special codepaths for this, I think.

Yes, I bought this card before the G specifications were finalized.

> Well, we did not want to have the card, because at this point
> it did not make sense. We all have 4306 cards.
> But now it appears that this card seems to have some special
> things (because it is older than ours).
> 
> Well, how to debug.
> We are waiting for the IRQ Reason register there.
> Actually, we are waiting for the "no IRQ pending, but READY signal"
> state. Your card does not completely (?) clear the bits after MAC
> shutdown. So very helpful would be to print out in the loop the
> value. We know, that the card generates silly IRQs, that we did
> not ask for. That may happen here, too. So it _may_ help to
> mask out unwanted IRQs before the if-check. But I would first
> like to see a log of the reason-value on each iteration until it succeeds.

First of all, I have a udelay(1) in the wait loop. I have also moved the udelay to the top of the 
loop. For the past 12 hours, I have been printing the delay time for the cases where it took more 
than 2 passes through the loop. There have been single instances of 3 and 4 usec; otherwise the 
delay is much longer, with the largest delay at 750 usec. The long delays are always found during 
scanning, associating, and authenticating. I use WPA with wpa_supplicant.

Since adding the dump of IRQ reason, every case that took more than 1 pass through the loop has had 
an IRQ reason of 0x0580 for every pass in the loop. Your idea about the silly IRQ's seems to be 
right. I'll let you know if I get any results that are different.

One other little problem. If I do an ifdown/ifup sequence without unloading the bcm43xx module, I 
get a failure of the assert(bcm->mac_suspended >= 0) at the beginning of bcm43xx_mac_suspend.

Larry

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Wednesday 28 June 2006 18:04, Larry Finger wrote:
> Michael Buesch wrote:
> > 
> > It appears to be an older card. There are quite some
> > special codepaths for this, I think.
> 
> Yes, I bought this card before the G specifications were finalized.

Oh, very interresting. I did not know that these old cards
were pre-standard.

> For the past 12 hours, I have been printing the delay time for the cases where it took more  
> than 2 passes through the loop. There have been single instances of 3 and 4 usec; otherwise the 
> delay is much longer, with the largest delay at 750 usec. The long delays are always found during 
> scanning, associating, and authenticating. I use WPA with wpa_supplicant.

Oh, well. Forget it all.
I remembered the code wrong.
At the moment I looked at the code and it has the opposite semantics.
It loops to wait for the READY bit to appear.

Well, I would say your old device simply takes this long
to disable and there is no bug.

Oh, well...

> One other little problem. If I do an ifdown/ifup sequence without unloading the bcm43xx module, I 
> get a failure of the assert(bcm->mac_suspended >= 0) at the beginning of bcm43xx_mac_suspend.

Unrelated known bug.
I will do a patch, soon.

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Larry Finger]

Michael Buesch wrote:
> On Wednesday 28 June 2006 18:04, Larry Finger wrote:
> 
> Oh, well. Forget it all.
> I remembered the code wrong.
> At the moment I looked at the code and it has the opposite semantics.
> It loops to wait for the READY bit to appear.
> 
> Well, I would say your old device simply takes this long
> to disable and there is no bug.
> 
> Oh, well...

So the conclusion is that my card is really slow. As mine is likely to be the worst of the lot, I 
propose the following structure for the loop in question:

                 for (i = 10000; i; i--) {
                         tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
                         if (tmp & BCM43xx_IRQ_READY) {
                                 if (i < 9998)
                                         printkl(KERN_INFO PFX "MAC suspend delay %d usec, IRQ_REASON "
                                                 "0x%08x\n", 10000-i, tmp & ~BCM43xx_IRQ_READY);
                                 goto out;
                         }
                         udelay(1);
                 }
                 printkl(KERN_ERR PFX "MAC suspend failed\n");

My maximum delay (so far) is 796 usec, thus this loop gives me a safety factor of more than 10, but 
it should satisfy Jeff and let this patch in question be accepted. Of course, the 'if (i < 9998)' 
statement with the printkl is optional. BTW, as you suspected, the IRQ_REASON value is still at 
0x580 when the READY bit is set.

Thanks for the help,

Larry

Re: Please pull 'upstream' branch of wireless-2.6

[Michael Buesch]

On Wednesday 28 June 2006 19:32, Larry Finger wrote:
> Michael Buesch wrote:
> > On Wednesday 28 June 2006 18:04, Larry Finger wrote:
> > 
> > Oh, well. Forget it all.
> > I remembered the code wrong.
> > At the moment I looked at the code and it has the opposite semantics.
> > It loops to wait for the READY bit to appear.
> > 
> > Well, I would say your old device simply takes this long
> > to disable and there is no bug.
> > 
> > Oh, well...
> 
> So the conclusion is that my card is really slow. As mine is likely to be the worst of the lot, I 
> propose the following structure for the loop in question:
> 
>                  for (i = 10000; i; i--) {
>                          tmp = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
>                          if (tmp & BCM43xx_IRQ_READY) {
>                                  if (i < 9998)
>                                          printkl(KERN_INFO PFX "MAC suspend delay %d usec, IRQ_REASON "
>                                                  "0x%08x\n", 10000-i, tmp & ~BCM43xx_IRQ_READY);
>                                  goto out;
>                          }
>                          udelay(1);
>                  }
>                  printkl(KERN_ERR PFX "MAC suspend failed\n");
> 
> My maximum delay (so far) is 796 usec, thus this loop gives me a safety factor of more than 10, but 
> it should satisfy Jeff and let this patch in question be accepted.

Ok, I will send a patch to lower the limit to 10000 usec.
This won't do _any_ good (or bad), but well... If everybody likes
placebos, I will add it to the driver.

It's a bit complicated for me to say why your card takes 800usec
to suspend MAC. And additionally it is not really possible for
me to try to find a way making the card respond earlier (if possible)
remotely through you. ;)

How problematic might a 800usec delay with IRQs disabled be?

> Of course, the 'if (i < 9998)'  
> statement with the printkl is optional.

It is to be removed. ;)

-- 
Greetings Michael.

Re: Please pull 'upstream' branch of wireless-2.6

[Joseph Jezak]

> No, that totally avoids my point.  Your "otherwise idle machine" test is
> probably nowhere near worst case in the field, for loops that can
> potentially lock the CPU for a long time upon hardware fault.  And then
> there are the huge delays in specific functions that I pointed out...
> 
>     Jeff

The problem is that these are the delays used in the original driver
that we've been writing the specs from.  We don't know what they're
for or why they're so long.  We don't know if reducing the delay
will cause issues on some hardware and work fine on others.  Without
the actual specs from Broadcom, it's hard to say what's excessive
and what's not and whether changing it will break the driver.

-Joe

Please pull 'upstream' branch of wireless-2.6 (revised)

[John W. Linville]

On Mon, Jun 26, 2006 at 05:25:52PM -0400, John W. Linville wrote:

> Michael Buesch:
>       bcm43xx: suspend MAC while executing long pwork

The above patch ruffled some feathers on netdev.  In the interest of
moving things along, I have pulled that patch out of wireless-2.6.
I expect it will be back soon, probably with some additional changes
to satisfy concerns raised on the mailing list.

NOTE: While I was mucking around, I pulled a bunch of patches from
the master branch out into driver-specific branches for adm8211,
prism54usb, tiacx, and zd1211rw.  Then I rebuilt the master branch
by pulling from the driver branches.  This is intended to ease the
merging of individual drivers upstream (e.g. zd1211rw and maybe tiacx
in the near future).

Those working off my upstream branch or off Linus' tree should be
unaffected.  Anyone who works off my master branch may need to rebase,
especially if they want me to be able to pull from them (due to dirty
history).  I apologize for the hassle and appreciate your cooperation!

Thanks,

John
---

The following changes since commit fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
  Malcolm Parsons:
        uclinux: use PER_LINUX_32BIT in binfmt_flat

are found in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream

Daniel Drake:
      bcm43xx: use softmac-suggested TX rate
      bcm43xx: enable shared key authentication

Eric Sesterhenn:
      skb used after passing to netif_rx in net/ieee80211/ieee80211_rx.c

Faidon Liambotis:
      Add two PLX device IDs

Hong Liu:
      ieee80211: fix not allocating IV+ICV space when usingencryption in ieee80211_tx_frame

Horms:
      CONFIG_WIRELESS_EXT is neccessary after all

John W. Linville:
      softmac: fix build-break from 881ee6999d66c8fc903b429b73bbe6045b38c549

Joseph Jezak:
      SoftMAC: Prevent multiple authentication attempts on the same network
      SoftMAC: Add network to ieee80211softmac_call_events when associate times out

Larry Finger:
      Convert bcm43xx-softmac to use the ieee80211_is_valid_channel routine
      2.6.17 missing a call to ieee80211softmac_capabilities from ieee80211softmac_assoc_req

Michael Buesch:
      bcm43xx: workaround init_board vs. IRQ race

 drivers/net/wireless/bcm43xx/bcm43xx_main.c    |   31 ++++++++++++---------
 drivers/net/wireless/bcm43xx/bcm43xx_main.h    |   24 ----------------
 drivers/net/wireless/bcm43xx/bcm43xx_radio.c   |    7 +----
 drivers/net/wireless/bcm43xx/bcm43xx_wx.c      |    2 +
 drivers/net/wireless/bcm43xx/bcm43xx_xmit.c    |    5 +++
 drivers/net/wireless/hostap/hostap_plx.c       |    2 +
 include/net/ieee80211softmac.h                 |    1 +
 net/ieee80211/ieee80211_rx.c                   |    4 ++-
 net/ieee80211/ieee80211_tx.c                   |   15 +++++++---
 net/ieee80211/softmac/ieee80211softmac_assoc.c |   31 ++++++++++++++++-----
 net/ieee80211/softmac/ieee80211softmac_auth.c  |    4 +--
 net/ieee80211/softmac/ieee80211softmac_io.c    |    3 ++
 net/ieee80211/softmac/ieee80211softmac_wx.c    |   36 +++++++++++++++++++++++-
 13 files changed, 105 insertions(+), 60 deletions(-)

diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index 085d785..1cd47c5 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1885,6 +1885,15 @@ static irqreturn_t bcm43xx_interrupt_han
 
 	spin_lock(&bcm->irq_lock);
 
+	/* Only accept IRQs, if we are initialized properly.
+	 * This avoids an RX race while initializing.
+	 * We should probably not enable IRQs before we are initialized
+	 * completely, but some careful work is needed to fix this. I think it
+	 * is best to stay with this cheap workaround for now... .
+	 */
+	if (unlikely(bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED))
+		goto out;
+
 	reason = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
 	if (reason == 0xffffffff) {
 		/* irq not for us (shared irq) */
@@ -1906,19 +1915,11 @@ static irqreturn_t bcm43xx_interrupt_han
 
 	bcm43xx_interrupt_ack(bcm, reason);
 
-	/* Only accept IRQs, if we are initialized properly.
-	 * This avoids an RX race while initializing.
-	 * We should probably not enable IRQs before we are initialized
-	 * completely, but some careful work is needed to fix this. I think it
-	 * is best to stay with this cheap workaround for now... .
-	 */
-	if (likely(bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED)) {
-		/* disable all IRQs. They are enabled again in the bottom half. */
-		bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
-		/* save the reason code and call our bottom half. */
-		bcm->irq_reason = reason;
-		tasklet_schedule(&bcm->isr_tasklet);
-	}
+	/* disable all IRQs. They are enabled again in the bottom half. */
+	bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
+	/* save the reason code and call our bottom half. */
+	bcm->irq_reason = reason;
+	tasklet_schedule(&bcm->isr_tasklet);
 
 out:
 	mmiowb();
@@ -3661,6 +3662,10 @@ static void bcm43xx_ieee80211_set_securi
 		secinfo->encrypt = sec->encrypt;
 		dprintk(", .encrypt = %d", sec->encrypt);
 	}
+	if (sec->flags & SEC_AUTH_MODE) {
+		secinfo->auth_mode = sec->auth_mode;
+		dprintk(", .auth_mode = %d\n", sec->auth_mode);
+	}
 	dprintk("\n");
 	if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED &&
 	    !bcm->ieee->host_encrypt) {
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.h b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
index 30a202b..1164936 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.h
@@ -112,30 +112,6 @@ int bcm43xx_channel_to_freq(struct bcm43
 	return bcm43xx_channel_to_freq_bg(channel);
 }
 
-/* Lightweight function to check if a channel number is valid.
- * Note that this does _NOT_ check for geographical restrictions!
- */
-static inline
-int bcm43xx_is_valid_channel_a(u8 channel)
-{
-	return (channel >= IEEE80211_52GHZ_MIN_CHANNEL
-	       && channel <= IEEE80211_52GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel_bg(u8 channel)
-{
-	return (channel >= IEEE80211_24GHZ_MIN_CHANNEL
-	       && channel <= IEEE80211_24GHZ_MAX_CHANNEL);
-}
-static inline
-int bcm43xx_is_valid_channel(struct bcm43xx_private *bcm,
-			     u8 channel)
-{
-	if (bcm43xx_current_phy(bcm)->type == BCM43xx_PHYTYPE_A)
-		return bcm43xx_is_valid_channel_a(channel);
-	return bcm43xx_is_valid_channel_bg(channel);
-}
-
 void bcm43xx_tsf_read(struct bcm43xx_private *bcm, u64 *tsf);
 void bcm43xx_tsf_write(struct bcm43xx_private *bcm, u64 tsf);
 
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
index af5c0bf..bb9c484 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_radio.c
@@ -1594,11 +1594,11 @@ int bcm43xx_radio_selectchannel(struct b
 	u16 r8, tmp;
 	u16 freq;
 
+	if (!ieee80211_is_valid_channel(bcm->ieee, channel))
+		return -EINVAL;
 	if ((radio->manufact == 0x17F) &&
 	    (radio->version == 0x2060) &&
 	    (radio->revision == 1)) {
-		if (channel > 200)
-			return -EINVAL;
 		freq = channel2freq_a(channel);
 
 		r8 = bcm43xx_radio_read16(bcm, 0x0008);
@@ -1651,9 +1651,6 @@ int bcm43xx_radio_selectchannel(struct b
 		TODO();	//TODO:	TSSI2dbm workaround
 		bcm43xx_phy_xmitpower(bcm);//FIXME correct?
 	} else {
-		if ((channel < 1) || (channel > 14))
-			return -EINVAL;
-
 		if (synthetic_pu_workaround)
 			bcm43xx_synth_pu_workaround(bcm, channel);
 
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index c35cb3a..5c36e29 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -119,7 +119,7 @@ static int bcm43xx_wx_set_channelfreq(st
 		channel = bcm43xx_freq_to_channel(bcm, data->freq.m);
 		freq = data->freq.m;
 	}
-	if (!bcm43xx_is_valid_channel(bcm, channel))
+	if (!ieee80211_is_valid_channel(bcm->ieee, channel))
 		goto out_unlock;
 	if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED) {
 		//ieee80211softmac_disassoc(softmac, $REASON);
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c b/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
index d8ece28..6dbd855 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -296,11 +296,14 @@ void bcm43xx_generate_txhdr(struct bcm43
 	u16 control = 0;
 	u16 wsec_rate = 0;
 	u16 encrypt_frame;
+	const u16 ftype = WLAN_FC_GET_TYPE(le16_to_cpu(wireless_header->frame_ctl));
+	const int is_mgt = (ftype == IEEE80211_FTYPE_MGMT);
 
 	/* Now construct the TX header. */
 	memset(txhdr, 0, sizeof(*txhdr));
 
-	bitrate = bcm->softmac->txrates.default_rate;
+	bitrate = ieee80211softmac_suggest_txrate(bcm->softmac,
+		is_multicast_ether_addr(wireless_header->addr1), is_mgt);
 	ofdm_modulation = !(ieee80211_is_cck_rate(bitrate));
 	fallback_bitrate = bcm43xx_calc_fallback_rate(bitrate);
 	fallback_ofdm_modulation = !(ieee80211_is_cck_rate(fallback_bitrate));
diff --git a/drivers/net/wireless/hostap/hostap_plx.c b/drivers/net/wireless/hostap/hostap_plx.c
index edaaa94..39c545e 100644
--- a/drivers/net/wireless/hostap/hostap_plx.c
+++ b/drivers/net/wireless/hostap/hostap_plx.c
@@ -67,10 +67,12 @@ static struct pci_device_id prism2_plx_i
 	PLXDEV(0x10b7, 0x7770, "3Com AirConnect PCI 777A"),
 	PLXDEV(0x111a, 0x1023, "Siemens SpeedStream SS1023"),
 	PLXDEV(0x126c, 0x8030, "Nortel emobility"),
+	PLXDEV(0x1562, 0x0001, "Symbol LA-4123"),
 	PLXDEV(0x1385, 0x4100, "Netgear MA301"),
 	PLXDEV(0x15e8, 0x0130, "National Datacomm NCP130 (PLX9052)"),
 	PLXDEV(0x15e8, 0x0131, "National Datacomm NCP130 (TMD7160)"),
 	PLXDEV(0x1638, 0x1100, "Eumitcom WL11000"),
+	PLXDEV(0x16ab, 0x1100, "Global Sun Tech GL24110P"),
 	PLXDEV(0x16ab, 0x1101, "Global Sun Tech GL24110P (?)"),
 	PLXDEV(0x16ab, 0x1102, "Linksys WPC11 with WDT11"),
 	PLXDEV(0x16ab, 0x1103, "Longshine 8031"),
diff --git a/include/net/ieee80211softmac.h b/include/net/ieee80211softmac.h
index 7a483ab..00ad810 100644
--- a/include/net/ieee80211softmac.h
+++ b/include/net/ieee80211softmac.h
@@ -104,6 +104,7 @@ struct ieee80211softmac_assoc_info {
 	 */
 	u8 static_essid:1,
 	   associating:1,
+	   assoc_wait:1,
 	   bssvalid:1,
 	   bssfixed:1;
 
diff --git a/net/ieee80211/ieee80211_rx.c b/net/ieee80211/ieee80211_rx.c
index 2bf567f..b2fabbb 100644
--- a/net/ieee80211/ieee80211_rx.c
+++ b/net/ieee80211/ieee80211_rx.c
@@ -369,6 +369,7 @@ #endif
 
 	/* Put this code here so that we avoid duplicating it in all
 	 * Rx paths. - Jean II */
+#ifdef CONFIG_WIRELESS_EXT
 #ifdef IW_WIRELESS_SPY		/* defined in iw_handler.h */
 	/* If spy monitoring on */
 	if (ieee->spy_data.spy_number > 0) {
@@ -397,15 +398,16 @@ #ifdef IW_WIRELESS_SPY		/* defined in iw
 		wireless_spy_update(ieee->dev, hdr->addr2, &wstats);
 	}
 #endif				/* IW_WIRELESS_SPY */
+#endif				/* CONFIG_WIRELESS_EXT */
 
 #ifdef NOT_YET
 	hostap_update_rx_stats(local->ap, hdr, rx_stats);
 #endif
 
 	if (ieee->iw_mode == IW_MODE_MONITOR) {
-		ieee80211_monitor_rx(ieee, skb, rx_stats);
 		stats->rx_packets++;
 		stats->rx_bytes += skb->len;
+		ieee80211_monitor_rx(ieee, skb, rx_stats);
 		return 1;
 	}
 
diff --git a/net/ieee80211/ieee80211_tx.c b/net/ieee80211/ieee80211_tx.c
index 6a5de1b..e63bf77 100644
--- a/net/ieee80211/ieee80211_tx.c
+++ b/net/ieee80211/ieee80211_tx.c
@@ -563,10 +563,13 @@ int ieee80211_tx_frame(struct ieee80211_
 	struct net_device_stats *stats = &ieee->stats;
 	struct sk_buff *skb_frag;
 	int priority = -1;
+	int fraglen = total_len;
+	int headroom = ieee->tx_headroom;
+	struct ieee80211_crypt_data *crypt = ieee->crypt[ieee->tx_keyidx];
 
 	spin_lock_irqsave(&ieee->lock, flags);
 
-	if (encrypt_mpdu && !ieee->sec.encrypt)
+	if (encrypt_mpdu && (!ieee->sec.encrypt || !crypt))
 		encrypt_mpdu = 0;
 
 	/* If there is no driver handler to take the TXB, dont' bother
@@ -582,20 +585,24 @@ int ieee80211_tx_frame(struct ieee80211_
 		goto success;
 	}
 
-	if (encrypt_mpdu)
+	if (encrypt_mpdu) {
 		frame->frame_ctl |= cpu_to_le16(IEEE80211_FCTL_PROTECTED);
+		fraglen += crypt->ops->extra_mpdu_prefix_len +
+			   crypt->ops->extra_mpdu_postfix_len;
+		headroom += crypt->ops->extra_mpdu_prefix_len;
+	}
 
 	/* When we allocate the TXB we allocate enough space for the reserve
 	 * and full fragment bytes (bytes_per_frag doesn't include prefix,
 	 * postfix, header, FCS, etc.) */
-	txb = ieee80211_alloc_txb(1, total_len, ieee->tx_headroom, GFP_ATOMIC);
+	txb = ieee80211_alloc_txb(1, fraglen, headroom, GFP_ATOMIC);
 	if (unlikely(!txb)) {
 		printk(KERN_WARNING "%s: Could not allocate TXB\n",
 		       ieee->dev->name);
 		goto failed;
 	}
 	txb->encrypted = 0;
-	txb->payload_size = total_len;
+	txb->payload_size = fraglen;
 
 	skb_frag = txb->fragments[0];
 
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index 5e9a906..44215ce 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -47,9 +47,7 @@ ieee80211softmac_assoc(struct ieee80211s
 	
 	dprintk(KERN_INFO PFX "sent association request!\n");
 
-	/* Change the state to associating */
 	spin_lock_irqsave(&mac->lock, flags);
-	mac->associnfo.associating = 1;
 	mac->associated = 0; /* just to make sure */
 
 	/* Set a timer for timeout */
@@ -63,6 +61,7 @@ void
 ieee80211softmac_assoc_timeout(void *d)
 {
 	struct ieee80211softmac_device *mac = (struct ieee80211softmac_device *)d;
+	struct ieee80211softmac_network *n;
 	unsigned long flags;
 
 	spin_lock_irqsave(&mac->lock, flags);
@@ -75,11 +74,12 @@ ieee80211softmac_assoc_timeout(void *d)
 	mac->associnfo.associating = 0;
 	mac->associnfo.bssvalid = 0;
 	mac->associated = 0;
+
+	n = ieee80211softmac_get_network_by_bssid_locked(mac, mac->associnfo.bssid);
 	spin_unlock_irqrestore(&mac->lock, flags);
 
 	dprintk(KERN_INFO PFX "assoc request timed out!\n");
-	/* FIXME: we need to know the network here. that requires a bit of restructuring */
-	ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, NULL);
+	ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_TIMEOUT, n);
 }
 
 void
@@ -203,6 +203,10 @@ ieee80211softmac_assoc_work(void *d)
 	if (mac->associated)
 		ieee80211softmac_send_disassoc_req(mac, WLAN_REASON_DISASSOC_STA_HAS_LEFT);
 
+	spin_lock_irqsave(&mac->lock, flags);
+	mac->associnfo.associating = 1;
+	spin_unlock_irqrestore(&mac->lock, flags);
+
 	/* try to find the requested network in our list, if we found one already */
 	if (bssvalid || mac->associnfo.bssfixed)
 		found = ieee80211softmac_get_network_by_bssid(mac, mac->associnfo.bssid);	
@@ -295,19 +299,32 @@ ieee80211softmac_assoc_work(void *d)
 	memcpy(mac->associnfo.associate_essid.data, found->essid.data, IW_ESSID_MAX_SIZE + 1);
 	
 	/* we found a network! authenticate (if necessary) and associate to it. */
-	if (!found->authenticated) {
+	if (found->authenticating) {
+		dprintk(KERN_INFO PFX "Already requested authentication, waiting...\n");
+		if(!mac->associnfo.assoc_wait) {
+			mac->associnfo.assoc_wait = 1;
+			ieee80211softmac_notify_internal(mac, IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify_auth, NULL, GFP_KERNEL);
+		}
+		return;
+	}
+	if (!found->authenticated && !found->authenticating) {
 		/* This relies on the fact that _auth_req only queues the work,
 		 * otherwise adding the notification would be racy. */
 		if (!ieee80211softmac_auth_req(mac, found)) {
-			dprintk(KERN_INFO PFX "cannot associate without being authenticated, requested authentication\n");
-			ieee80211softmac_notify_internal(mac, IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify_auth, NULL, GFP_KERNEL);
+			if(!mac->associnfo.assoc_wait) {
+				dprintk(KERN_INFO PFX "Cannot associate without being authenticated, requested authentication\n");
+				mac->associnfo.assoc_wait = 1;
+				ieee80211softmac_notify_internal(mac, IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify_auth, NULL, GFP_KERNEL);
+			}
 		} else {
 			printkl(KERN_WARNING PFX "Not authenticated, but requesting authentication failed. Giving up to associate\n");
+			mac->associnfo.assoc_wait = 0;
 			ieee80211softmac_call_events(mac, IEEE80211SOFTMAC_EVENT_ASSOCIATE_FAILED, found);
 		}
 		return;
 	}
 	/* finally! now we can start associating */
+	mac->associnfo.assoc_wait = 0;
 	ieee80211softmac_assoc(mac, found);
 }
 
diff --git a/net/ieee80211/softmac/ieee80211softmac_auth.c b/net/ieee80211/softmac/ieee80211softmac_auth.c
index 90b8484..ebc33ca 100644
--- a/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ b/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -36,8 +36,9 @@ ieee80211softmac_auth_req(struct ieee802
 	struct ieee80211softmac_auth_queue_item *auth;
 	unsigned long flags;
 	
-	if (net->authenticating)
+	if (net->authenticating || net->authenticated)
 		return 0;
+	net->authenticating = 1;
 
 	/* Add the network if it's not already added */
 	ieee80211softmac_add_network(mac, net);
@@ -92,7 +93,6 @@ ieee80211softmac_auth_queue(void *data)
 			return;
 		}
 		net->authenticated = 0;
-		net->authenticating = 1;
 		/* add a timeout call so we eventually give up waiting for an auth reply */
 		schedule_delayed_work(&auth->work, IEEE80211SOFTMAC_AUTH_TIMEOUT);
 		auth->retry--;
diff --git a/net/ieee80211/softmac/ieee80211softmac_io.c b/net/ieee80211/softmac/ieee80211softmac_io.c
index 0954161..8cc8b20 100644
--- a/net/ieee80211/softmac/ieee80211softmac_io.c
+++ b/net/ieee80211/softmac/ieee80211softmac_io.c
@@ -229,6 +229,9 @@ ieee80211softmac_assoc_req(struct ieee80
 		return 0;
 	ieee80211softmac_hdr_3addr(mac, &((*pkt)->header), IEEE80211_STYPE_ASSOC_REQ, net->bssid, net->bssid);
 
+	/* Fill in the capabilities */
+	(*pkt)->capability = ieee80211softmac_capabilities(mac, net);
+
 	/* Fill in Listen Interval (?) */
 	(*pkt)->listen_interval = cpu_to_le16(10);
 	
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 0e65ff4..75320b6 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -70,12 +70,44 @@ ieee80211softmac_wx_set_essid(struct net
 			      char *extra)
 {
 	struct ieee80211softmac_device *sm = ieee80211_priv(net_dev);
+	struct ieee80211softmac_network *n;
+	struct ieee80211softmac_auth_queue_item *authptr;
 	int length = 0;
 	unsigned long flags;
-	
+
+	/* Check if we're already associating to this or another network
+	 * If it's another network, cancel and start over with our new network
+	 * If it's our network, ignore the change, we're already doing it!
+	 */
+	if((sm->associnfo.associating || sm->associated) &&
+	   (data->essid.flags && data->essid.length && extra)) {
+		/* Get the associating network */
+		n = ieee80211softmac_get_network_by_bssid(sm, sm->associnfo.bssid);
+		if(n && n->essid.len == (data->essid.length - 1) &&
+		   !memcmp(n->essid.data, extra, n->essid.len)) {
+			dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
+				MAC_ARG(sm->associnfo.bssid));
+			return 0;
+		} else {
+			dprintk(KERN_INFO PFX "Canceling existing associate request!\n");
+			spin_lock_irqsave(&sm->lock,flags);
+			/* Cancel assoc work */
+			cancel_delayed_work(&sm->associnfo.work);
+			/* We don't have to do this, but it's a little cleaner */
+			list_for_each_entry(authptr, &sm->auth_queue, list)
+				cancel_delayed_work(&authptr->work);
+			sm->associnfo.bssvalid = 0;
+			sm->associnfo.bssfixed = 0;
+			spin_unlock_irqrestore(&sm->lock,flags);
+			flush_scheduled_work();
+		}
+	}
+
+
 	spin_lock_irqsave(&sm->lock, flags);
-	
+
 	sm->associnfo.static_essid = 0;
+	sm->associnfo.assoc_wait = 0;
 
 	if (data->essid.flags && data->essid.length && extra /*required?*/) {
 		length = min(data->essid.length - 1, IW_ESSID_MAX_SIZE);
-- 
John W. Linville
linville@tuxdriver.com

Please pull 'zd1211rw' branch of wireless-2.6 (new driver)

[John W. Linville]

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

For easier review, a tarball of drivers/net/wireless/zd1211rw is available here:

	http://www.kernel.org/pub/linux/kernel/people/linville/zd1211rw.tar.gz

>From Daniel's initial zd1211rw changelog:

    [PATCH] ZyDAS ZD1211 USB-WLAN driver

    There are 60+ USB wifi adapters available on the market based on the ZyDAS
    ZD1211 chip.

    Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
    data operations are coordinated by the device driver. The ZD1211 chip sits
    alongside an RF transceiver which is also controlled by the driver. Our driver
    currently supports 2 RF types, we know of one other available in a few marketed
    products which we will be supporting soon.

    Our driver also supports the newer revision of ZD1211, called ZD1211B. The
    initialization and RF operations are slightly different for the new revision,
    but the main difference is 802.11e support. Our driver does not support the
    QoS features yet, but we think we know how to use them.

    This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
    ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
    up to them. Additionally, the firmware is redistributable and they have
    provided device specs.

    This driver has been written primarily by Ulrich Kunitz and myself. Graham
    Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
    developers of ieee80211 and softmac have made our lives so much easier- thanks

    We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite

    If there is enough time for review, we would like to aim for inclusion in
    2.6.18. The driver works nicely as a STA, and can connect to both open and
    encrypted networks (we are using software-based encryption for now). We will
    work towards supporting more advanced features in the future (ad-hoc, master
    mode, 802.11a, ...).

Please review!

Thanks,

John

---

The following changes since commit 70a332b048e4d90635dfa47fc5d91cf87b5cc3a5:
  John W. Linville:
        softmac: fix build-break from 881ee6999d66c8fc903b429b73bbe6045b38c549

are found in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git zd1211rw

Daniel Drake:
      ZyDAS ZD1211 USB-WLAN driver
      zd1211rw: disable TX queue during stop

 drivers/net/wireless/Kconfig                 |    1 
 drivers/net/wireless/Makefile                |    1 
 drivers/net/wireless/zd1211rw/Kconfig        |   19 
 drivers/net/wireless/zd1211rw/Makefile       |   11 
 drivers/net/wireless/zd1211rw/zd_chip.c      | 1615 ++++++++++++++++++++++++++
 drivers/net/wireless/zd1211rw/zd_chip.h      |  825 +++++++++++++
 drivers/net/wireless/zd1211rw/zd_def.h       |   48 +
 drivers/net/wireless/zd1211rw/zd_ieee80211.c |  191 +++
 drivers/net/wireless/zd1211rw/zd_ieee80211.h |   85 +
 drivers/net/wireless/zd1211rw/zd_mac.c       | 1057 +++++++++++++++++
 drivers/net/wireless/zd1211rw/zd_mac.h       |  190 +++
 drivers/net/wireless/zd1211rw/zd_netdev.c    |  267 ++++
 drivers/net/wireless/zd1211rw/zd_netdev.h    |   45 +
 drivers/net/wireless/zd1211rw/zd_rf.c        |  151 ++
 drivers/net/wireless/zd1211rw/zd_rf.h        |   82 +
 drivers/net/wireless/zd1211rw/zd_rf_al2230.c |  308 +++++
 drivers/net/wireless/zd1211rw/zd_rf_rf2959.c |  279 ++++
 drivers/net/wireless/zd1211rw/zd_types.h     |   71 +
 drivers/net/wireless/zd1211rw/zd_usb.c       | 1316 +++++++++++++++++++++
 drivers/net/wireless/zd1211rw/zd_usb.h       |  240 ++++
 drivers/net/wireless/zd1211rw/zd_util.c      |   82 +
 drivers/net/wireless/zd1211rw/zd_util.h      |   29 
 22 files changed, 6913 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/wireless/zd1211rw/Kconfig
 create mode 100644 drivers/net/wireless/zd1211rw/Makefile
 create mode 100644 drivers/net/wireless/zd1211rw/zd_chip.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_chip.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_def.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_ieee80211.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_ieee80211.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_mac.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_mac.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_netdev.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_netdev.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_rf.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_rf.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_rf_al2230.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_rf_rf2959.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_types.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_usb.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_usb.h
 create mode 100644 drivers/net/wireless/zd1211rw/zd_util.c
 create mode 100644 drivers/net/wireless/zd1211rw/zd_util.h

Full (history-free) patch attached as zd1211rw.patch.bz2
-- 
John W. Linville
linville@tuxdriver.com

[-- Attachment #2: zd1211rw.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 36554 bytes --]

Re: Please pull 'zd1211rw' branch of wireless-2.6 (new driver)

[Jeff Garzik]

John W. Linville wrote:
> For easier review, a tarball of drivers/net/wireless/zd1211rw is available here:
> 
> 	http://www.kernel.org/pub/linux/kernel/people/linville/zd1211rw.tar.gz
> 
>>From Daniel's initial zd1211rw changelog:
> 
>     [PATCH] ZyDAS ZD1211 USB-WLAN driver
> 
>     There are 60+ USB wifi adapters available on the market based on the ZyDAS
>     ZD1211 chip.
> 
>     Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
>     data operations are coordinated by the device driver. The ZD1211 chip sits
>     alongside an RF transceiver which is also controlled by the driver. Our driver
>     currently supports 2 RF types, we know of one other available in a few marketed
>     products which we will be supporting soon.
> 
>     Our driver also supports the newer revision of ZD1211, called ZD1211B. The
>     initialization and RF operations are slightly different for the new revision,
>     but the main difference is 802.11e support. Our driver does not support the
>     QoS features yet, but we think we know how to use them.
> 
>     This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
>     ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
>     up to them. Additionally, the firmware is redistributable and they have
>     provided device specs.
> 
>     This driver has been written primarily by Ulrich Kunitz and myself. Graham
>     Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
>     developers of ieee80211 and softmac have made our lives so much easier- thanks
> 
>     We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite
> 
>     If there is enough time for review, we would like to aim for inclusion in
>     2.6.18. The driver works nicely as a STA, and can connect to both open and
>     encrypted networks (we are using software-based encryption for now). We will
>     work towards supporting more advanced features in the future (ad-hoc, master
>     mode, 802.11a, ...).
> 
> Please review!
> 
> Thanks,
> 
> John
> 
> ---
> 
> The following changes since commit 70a332b048e4d90635dfa47fc5d91cf87b5cc3a5:
>   John W. Linville:
>         softmac: fix build-break from 881ee6999d66c8fc903b429b73bbe6045b38c549
> 
> are found in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git zd1211rw

pulled, though I would like to see the debug facilities cleaned up

Re: Please pull 'upstream' branch of wireless-2.6 (revised)

[Jeff Garzik]

John W. Linville wrote:
> On Mon, Jun 26, 2006 at 05:25:52PM -0400, John W. Linville wrote:
> 
>> Michael Buesch:
>>       bcm43xx: suspend MAC while executing long pwork
> 
> The above patch ruffled some feathers on netdev.  In the interest of
> moving things along, I have pulled that patch out of wireless-2.6.
> I expect it will be back soon, probably with some additional changes
> to satisfy concerns raised on the mailing list.
> 
> NOTE: While I was mucking around, I pulled a bunch of patches from
> the master branch out into driver-specific branches for adm8211,
> prism54usb, tiacx, and zd1211rw.  Then I rebuilt the master branch
> by pulling from the driver branches.  This is intended to ease the
> merging of individual drivers upstream (e.g. zd1211rw and maybe tiacx
> in the near future).
> 
> Those working off my upstream branch or off Linus' tree should be
> unaffected.  Anyone who works off my master branch may need to rebase,
> especially if they want me to be able to pull from them (due to dirty
> history).  I apologize for the hassle and appreciate your cooperation!
> 
> Thanks,
> 
> John
> ---
> 
> The following changes since commit fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
>   Malcolm Parsons:
>         uclinux: use PER_LINUX_32BIT in binfmt_flat
> 
> are found in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream

nothing pulled?

Re: Please pull 'upstream' branch of wireless-2.6 (revised)

[John W. Linville]

On Fri, Jun 30, 2006 at 12:31:00PM -0400, Jeff Garzik wrote:

> >The following changes since commit 
> >fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
> >  Malcolm Parsons:
> >        uclinux: use PER_LINUX_32BIT in binfmt_flat
> >
> >are found in the git repository at:
> >
> >  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git 
> >  upstream
> 
> nothing pulled?

Odd, the changes seem to be there...did you happen to pull zd1211rw
first?  I based that branch off the HEAD of the upstream branch.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Please pull 'upstream' branch of wireless-2.6 (revised)

[John W. Linville]

On Fri, Jun 30, 2006 at 03:27:02PM -0400, John W. Linville wrote:
> On Fri, Jun 30, 2006 at 12:31:00PM -0400, Jeff Garzik wrote:
> 
> > >The following changes since commit 
> > >fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
> > >  Malcolm Parsons:
> > >        uclinux: use PER_LINUX_32BIT in binfmt_flat
> > >
> > >are found in the git repository at:
> > >
> > >  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git 
> > >  upstream
> > 
> > nothing pulled?
> 
> Odd, the changes seem to be there...did you happen to pull zd1211rw
> first?  I based that branch off the HEAD of the upstream branch.

Just to be sure, I re-cloned the netdev-2.6 tree from kernel.org and
did pulls from the 'upstream' branch of wireless-2.6.  Everything
seemed to work as expected.

Do you have this commit?

	70a332b048e4d90635dfa47fc5d91cf87b5cc3a5

That is the latest one in my upstream branch.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: Please pull 'upstream' branch of wireless-2.6 (revised)

[Jeff Garzik]

John W. Linville wrote:
> On Fri, Jun 30, 2006 at 12:31:00PM -0400, Jeff Garzik wrote:
> 
>>> The following changes since commit 
>>> fcc18e83e1f6fd9fa6b333735bf0fcd530655511:
>>>  Malcolm Parsons:
>>>        uclinux: use PER_LINUX_32BIT in binfmt_flat
>>>
>>> are found in the git repository at:
>>>
>>>  git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git 
>>>  upstream
>> nothing pulled?
> 
> Odd, the changes seem to be there...did you happen to pull zd1211rw
> first?  I based that branch off the HEAD of the upstream branch.

Sorry to cause more trouble, but...  In a moment of thoughtless action, 
I rebased netdev#upstream, which has the obvious ripple effects :/

	Jeff