Re: Please pull 'fixes-davem' branch of wireless-2.6
On Tuesday 16 October 2007 22:31:46 John W. Linville wrote: Bill Moss (1): mac80211: honor IW_SCAN_THIS_ESSID in siwscan ioctl Where did this patch come from? The original patch looked nothing like this, and this patch changes the behavior of siwscan incorrectly. If the interface is not STA, IBSS, or AP, scanning should not be permitted. This patch allows scanning on any interface if a SSID is specified. NACK. -Michael Wu signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ieee80211_if_set_type: make check for master dev more explicit
On Thursday 04 October 2007 19:02, John W. Linville wrote: Alright...better? Yup, thanks. The problem is caused by ieee80211_if_set_type checking for a non-zero hard_start_xmit pointer value in order to avoid changing that value for master devices. The fix is to make that check more explicitly linked to master devices rather than simply checking if the value has been previously set. CC: Daniel Drake [EMAIL PROTECTED] Signed-off-by: John W. Linville [EMAIL PROTECTED] Acked-by: Michael Wu [EMAIL PROTECTED] -Michael Wu pgpq0GOLj4M4L.pgp Description: PGP signature
Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
On Thursday 04 October 2007 07:33, Daniel Drake wrote: Fix this by unsetting the hard_start_xmit handler in ieee80211_if_reinit. It will then be reinitialised to the default (ieee80211_subif_start_xmit) in ieee80211_if_set_type. Well.. this kinda sucks, but we can clean up the logic here later. + BUG_ON(netif_running(dev)); This will never happen, so there's no point. ACK with that bit removed. Thanks, -Michael Wu pgp8tWf3hoFjQ.pgp Description: PGP signature
Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
On Thursday 04 October 2007 11:06, Michael Buesch wrote: The reason why BUG_ON exists is to catch bugs that happen, although they Should Never Happen (tm) ;) This is just paranoia. There's plenty of other BUG_ONs which we use to catch bugs caused by drivers doing silly things. We can verify that this condition will never occur within the mac80211 layer, so there's no need to have it. The only thing this can catch is someone deciding to manually invoke dev-uninit, which only the unregister code should be doing. -Michael Wu pgpdJwtzOzO1V.pgp Description: PGP signature
Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
On Thursday 04 October 2007 11:54, Stephen Hemminger wrote: Playing with the function pointer is a awkward way to do this. Shouldn't the state management flags be used instead (dormant, running, stop/wake)... I am concerned about races and dereferencing the NULL ptr. This is all under RTNL and the pointer is only modified while the interface is down. -Michael Wu pgpshSQvult93.pgp Description: PGP signature
Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
On Thursday 04 October 2007 11:19, John W. Linville wrote: The reason why BUG_ON exists is to catch bugs that happen, although they Should Never Happen (tm) ;) Precisely. No really, this bug will never happen. This is function is merely a helper function which is called from interface removal code (where the interface *has* to be down) or from changing the interface type (which ensures that the interface is down first). There are an unlimited number of bugs which Should Never Happen. That doesn't mean we should start adding BUG_ONs for every single one of them. That gives some sort of protection against cosmic rays flipping bits, but down here on earth, it's bloat. -Michael Wu pgpvLIbudqBzS.pgp Description: PGP signature
Re: [PATCH] mac80211: Fix TX after monitor interface is converted to managed
On Thursday 04 October 2007 14:15, John W. Linville wrote: Falling back on bloat as an argument against a BUG_ON in a configuration path seems a bit weak. :-) Seems strong to me. Bloat slows me down and distracts me from what code really needs to do. Bloat is an indication that one does not understand what the code really needs to do. Programming with assertions (and BUG_ON is a form of that) is generally a good practice. Almost any book or other source on good programming practices will agree. Yes, it can be overdone. But I don't really think that is the case here, since the check is relatively inexpensive and the consequence should it ever *somehow* happen could be a something wierd (crash, corruption, etc) w/o any other indication of what occured. A line has to be drawn somewhere. There's about a billion places where we can add checks like this because if an assumption should ever break, the code will break into pieces. However, we don't, and there's no reason to do so here other than to needlessly add code just because it makes you feel safer. -Michael Wu pgpHBxhRxxDdA.pgp Description: PGP signature
Re: [PATCH] ieee80211_if_set_type: make check for master dev more explicit
On Thursday 04 October 2007 14:09, John W. Linville wrote: diff --git a/net/mac80211/ieee80211_iface.c b/net/mac80211/ieee80211_iface.c index be7e77f..6607b80 100644 --- a/net/mac80211/ieee80211_iface.c +++ b/net/mac80211/ieee80211_iface.c @@ -106,7 +106,7 @@ void ieee80211_if_set_type(struct net_device *dev, int type) * which already has a hard_start_xmit routine assigned * which must not be changed. */ - if (!dev-hard_start_xmit) + if (dev-type != ARPHRD_IEEE80211) The standard way of checking for the master device is dev == sdata-local-mdev wme.c doesn't quite follow this but that code needs to die anyway. This does look nicer than the other patch. -Michael Wu pgpN7ucTU8vgB.pgp Description: PGP signature
Re: Please pull 'adm8211' branch of wireless-2.6
On Saturday 15 September 2007 09:22, John W. Linville wrote: It is reverse-engineered and still has more magic initialization numbers than I'd like, but overall I think it would be better to have this upstream than not. Not entirely accurate, as ADMtek released specs (publically downloadable, no NDA), released their Linux driver source (under GPL), sent hardware samples, and offered an engineer's help a few months after the first release of the adm8211 driver. -Michael Wu pgpwvD8Xe1LEr.pgp Description: PGP signature
Re: Please pull 'adm8211' branch of wireless-2.6
(Host Control and Status Registers) */
+struct adm8211_csr {
[snip]
+} __attribute__ ((packed));
attributed(packed) is unneccesary here, and its use results in
sub-optimal code
How? Doesn't this just turn into a bunch of offsets?
enums are preferred. they do not disappear at the cpp stage, and confer
type information.
I'd rather not.
+#define ADM8211_IDLE_RX() \
+do {
\
+ if (priv-nar ADM8211_NAR_SR) { \
+ ADM8211_CSR_WRITE(NAR, priv-nar ~ADM8211_NAR_SR);\
+ ADM8211_CSR_READ(NAR); \
+ mdelay(20); \
+ } \
+} while (0)
should be msleep() AFAICS
Nope, this can be called in atomic context. Admittedly, 20 ms delay is
ridiculously long.. I'll find a better way to handle this.
use of tab to separate type and name greatly enhances readability.
look at many other net drivers, to see the positive effects
Sure, will do.
Thanks,
-Michael Wu
pgpOaX1OsRMry.pgp
Description: PGP signature
Re: Please pull 'adm8211' branch of wireless-2.6
On Saturday 15 September 2007 20:56, Jeff Garzik wrote:
+ if (flags IFF_PROMISC)
+ dev-flags |= IEEE80211_HW_RX_INCLUDES_FCS;
+ else
+ dev-flags = ~IEEE80211_HW_RX_INCLUDES_FCS;
why does promisc dictate inclusion of FCS?
Because that's the way the hardware works.
Why not always include it, regardless of promisc?
I really do mean that's how the hardware works. If you turn on the promisc bit
in the hardware (which IFF_PROMISC causes), it starts including the FCS, but
if the bit is not set, the FCS is not included in frames.
+ } while (count++ 20);
NAK -- talk about back to the past.
It's bogus to loop in the interrupt handler, then loop again in both RX
and TX paths. You are getting close to reinventing the wheel here.
Use NAPI rather than doing such a loop.
This is old interrupt handler code from Jouni's original driver. I never
bothered to replace it with the simpler designs used in newer drivers
I've worked on.
Also - mac80211 drivers have no access to NAPI.
Not true as of net-2.6.24.
Huh? How does a driver use NAPI if it can't pass a struct net_device?
+/* CSR (Host Control and Status Registers) */
+struct adm8211_csr {
[snip]
+} __attribute__ ((packed));
attributed(packed) is unneccesary here, and its use results in
sub-optimal code
How? Doesn't this just turn into a bunch of offsets?
It depends on how its used in the code.
I don't think I'm using it in a way that would make a difference.
enums are preferred. they do not disappear at the cpp stage, and confer
type information.
I'd rather not.
Elaboration?
What form of debugging are you talking about? I don't see how it makes a
difference for debugging. The type checking provided by enums won't make a
difference for my code - any problems with using the wrong register bits in
the wrong place is obvious due to the prefixes. I don't really see how enum
type checking is even effective at all without annotations and casts all over
the place.
Thanks,
-Michael Wu
pgpKxv01TUAxV.pgp
Description: PGP signature
Re: Please pull 'adm8211' branch of wireless-2.6
On Sunday 16 September 2007 00:50, David Miller wrote: From: Michael Wu [EMAIL PROTECTED] Date: Sun, 16 Sep 2007 00:47:40 -0400 Huh? How does a driver use NAPI if it can't pass a struct net_device? It is now managed by a struct napi_struct which you can embed into any object you like. NAPI is now totally disconnected from the network device structure. This was necessary for proper support of multi-queue cards. Ah, very nice. -Michael Wu pgpFVD7ZOn1In.pgp Description: PGP signature
Re: Panic in ieee_80211_ibss_add_sta when trying to join ad-hoc network (rt2500pci)
On Tuesday 15 May 2007 13:12, John W. Linville wrote:\ Patch below...does this work better? Looks like upstream needs it too... ACK. Looks like I forgot to set sdata after removing the code that set it. Thanks, -Michael Wu pgpG4koPmIL63.pgp Description: PGP signature
Re: Please pull 'upstream-rtl8187' branch of wireless-2.6
RTL818X_INT_BEACON (1 13) +#define RTL818X_INT_TIME_OUT (1 14) +#define RTL818X_INT_TX_FO (1 15) + __le32 TX_CONF; +#define RTL818X_TX_CONF_LOOPBACK_MAC (1 17) +#define RTL818X_TX_CONF_NO_ICV (1 19) +#define RTL818X_TX_CONF_DISCW (1 20) +#define RTL818X_TX_CONF_R8180_ABCD (2 25) +#define RTL818X_TX_CONF_R8180_F(3 25) +#define RTL818X_TX_CONF_R8185_ABC (4 25) +#define RTL818X_TX_CONF_R8185_D(5 25) +#define RTL818X_TX_CONF_HWVER_MASK (7 25) +#define RTL818X_TX_CONF_CW_MIN (1 31) + __le32 RX_CONF; +#define RTL818X_RX_CONF_MONITOR(1 0) +#define RTL818X_RX_CONF_NICMAC (1 1) +#define RTL818X_RX_CONF_MULTICAST (1 2) +#define RTL818X_RX_CONF_BROADCAST (1 3) +#define RTL818X_RX_CONF_DATA (1 18) +#define RTL818X_RX_CONF_CTRL (1 19) +#define RTL818X_RX_CONF_MGMT (1 20) +#define RTL818X_RX_CONF_BSSID (1 23) +#define RTL818X_RX_CONF_RX_AUTORESETPHY(1 28) +#define RTL818X_RX_CONF_ONLYERLPKT (1 31) + __le32 INT_TIMEOUT; + __le32 TBDA; + u8 EEPROM_CMD; +#define RTL818X_EEPROM_CMD_READ(1 0) +#define RTL818X_EEPROM_CMD_WRITE (1 1) +#define RTL818X_EEPROM_CMD_CK (1 2) +#define RTL818X_EEPROM_CMD_CS (1 3) +#define RTL818X_EEPROM_CMD_NORMAL (0 6) +#define RTL818X_EEPROM_CMD_LOAD(1 6) +#define RTL818X_EEPROM_CMD_PROGRAM (2 6) +#define RTL818X_EEPROM_CMD_CONFIG (3 6) + u8 CONFIG0; + u8 CONFIG1; + u8 CONFIG2; + __le32 ANAPARAM; + u8 MSR; +#define RTL818X_MSR_NO_LINK(0 2) +#define RTL818X_MSR_ADHOC (1 2) +#define RTL818X_MSR_INFRA (2 2) + u8 CONFIG3; +#define RTL818X_CONFIG3_ANAPARAM_WRITE (1 6) + u8 CONFIG4; +#define RTL818X_CONFIG4_POWEROFF (1 6) +#define RTL818X_CONFIG4_VCOOFF (1 7) + u8 TESTR; + u8 reserved_9[2]; + __le16 PGSELECT; + __le32 ANAPARAM2; + u8 reserved_10[12]; + __le16 BEACON_INTERVAL; + __le16 ATIM_WND; + __le16 BEACON_INTERVAL_TIME; + __le16 ATIMTR_INTERVAL; + u8 reserved_11[4]; + u8 PHY[4]; + __le16 RFPinsOutput; + __le16 RFPinsEnable; + __le16 RFPinsSelect; + __le16 RFPinsInput; + __le32 RF_PARA; + __le32 RF_TIMING; + u8 GP_ENABLE; + u8 GPIO; + u8 reserved_12[10]; + u8 TX_AGC_CTL; +#define RTL818X_TX_AGC_CTL_PERPACKET_GAIN_SHIFT(1 0) +#define RTL818X_TX_AGC_CTL_PERPACKET_ANTSEL_SHIFT (1 1) +#define RTL818X_TX_AGC_CTL_FEEDBACK_ANT(1 2) + u8 TX_GAIN_CCK; + u8 TX_GAIN_OFDM; + u8 TX_ANTENNA; + u8 reserved_13[16]; + u8 WPA_CONF; + u8 reserved_14[3]; + u8 SIFS; + u8 DIFS; + u8 SLOT; + u8 reserved_15[5]; + u8 CW_CONF; +#define RTL818X_CW_CONF_PERPACKET_CW_SHIFT (1 0) +#define RTL818X_CW_CONF_PERPACKET_RETRY_SHIFT (1 1) + u8 CW_VAL; + u8 RATE_FALLBACK; + u8 reserved_16[25]; + u8 CONFIG5; + u8 TX_DMA_POLLING; + u8 reserved_17[2]; + __le16 CWR; + u8 RETRY_CTR; + u8 reserved_18[5]; + __le32 RDSAR; + u8 reserved_19[18]; + u16 TALLY_CNT; + u8 TALLY_SEL; +} __attribute__((packed)); enums have more visibility to the compiler and debugging tools enums don't have the same kind of typechecking this has. -Michael Wu pgpAX8vfG7Nic.pgp Description: PGP signature
Re: Please pull 'upstream-rtl8187' branch of wireless-2.6
On Thursday 10 May 2007 00:21, Jeff Garzik wrote:
Michael Wu wrote:
On Wednesday 09 May 2007 19:12, Jeff Garzik wrote:
John W. Linville wrote:
+static inline void eeprom_93cx6_pulse_high(struct eeprom_93cx6
*eeprom) +{
+ eeprom-reg_data_clock = 1;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static inline void eeprom_93cx6_pulse_low(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 0;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
udelay-after-write normally indicates a PCI posting bug (or USB bus
delay bug)
Things may go bad if we try to bitbang the eeprom too fast.
You are misunderstanding the point here.
I was not asking why you needed the delay. I was making an assertion
about the unreliable nature of such delays.
Sending a register write to a device is vastly different from knowing
that the write has been received and processed by the device.
On a PCI bus, this is called PCI write posting, where writes can be
delayed and/or combined with other writes. There is a similar concept
with USB, because you are dealing with packets going to and from a USB
device.
You fundamentally cannot assume that the write has arrived at the device
by the time the CPU is executing the next C statement (udelay) on the host.
The normal procedure for PCI is to issue a read, which thereby
guarantees that any writes have been flushed to the device. I presume
the same technique works with USB, but do not know for certain.
Ah, I see what you're talking about.
All register writes on rtl8187 are blocking. We know they've reached the
device once the function returns.
I suppose there is a problem with the eeprom code not documenting the
assumption that the write posted before returning.
Regardless of any symbol issues, if it works without it, then remove it,
because it is pointless code. All pointless code should be removed.
But nonetheless, for any magic number registers that remain, give them
named constants that approximate their use as best as you can tell.
Well, I really don't know what this stuff does, so the best names would end up
being something like RTL818X_INIT_MAGIC_REGISTER_1 and so on.
I'll ask Realtek instead.
This seems an invalid use of skb-cb. Don't use skb-cb.
The driver owns these rx skbs, so it owns skb-cb. Why not?
Wrong. It no longer owns the skbs once it passes them to the stack.
Those skbs have not been passed up to the stack. They're empty skbs waiting
for incoming frames. Any skbs that are passed up to the stack are unlinked
from this list first.
+++ b/drivers/net/wireless/rtl818x.h
@@ -0,0 +1,212 @@
+#ifndef RTL818X_H
+#define RTL818X_H
+
+struct rtl818x_csr {
+ u8 MAC[6];
+ u8 reserved_0[2];
+ __le32 MAR[2];
+ u8 RX_FIFO_COUNT;
+ u8 reserved_1;
+ u8 TX_FIFO_COUNT;
+ u8 BQREQ;
+ u8 reserved_2[4];
+ __le32 TSFT[2];
+ __le32 TLPDA;
+ __le32 TNPDA;
+ __le32 THPDA;
+ __le16 BRSR;
+ u8 BSSID[6];
+ u8 RESP_RATE;
+ u8 EIFS;
+ u8 reserved_3[1];
+ u8 CMD;
+#define RTL818X_CMD_TX_ENABLE(1 2)
+#define RTL818X_CMD_RX_ENABLE(1 3)
+#define RTL818X_CMD_RESET(1 4)
+ u8 reserved_4[4];
+ __le16 INT_MASK;
+ __le16 INT_STATUS;
+#define RTL818X_INT_RX_OK(1 0)
+#define RTL818X_INT_RX_ERR (1 1)
+#define RTL818X_INT_TXL_OK (1 2)
+#define RTL818X_INT_TXL_ERR (1 3)
+#define RTL818X_INT_RX_DU(1 4)
+#define RTL818X_INT_RX_FO(1 5)
+#define RTL818X_INT_TXN_OK (1 6)
+#define RTL818X_INT_TXN_ERR (1 7)
+#define RTL818X_INT_TXH_OK (1 8)
+#define RTL818X_INT_TXH_ERR (1 9)
+#define RTL818X_INT_TXB_OK (1 10)
+#define RTL818X_INT_TXB_ERR (1 11)
+#define RTL818X_INT_ATIM (1 12)
+#define RTL818X_INT_BEACON (1 13)
+#define RTL818X_INT_TIME_OUT (1 14)
+#define RTL818X_INT_TX_FO(1 15)
+ __le32 TX_CONF;
+#define RTL818X_TX_CONF_LOOPBACK_MAC (1 17)
+#define RTL818X_TX_CONF_NO_ICV (1 19)
+#define RTL818X_TX_CONF_DISCW(1 20)
+#define RTL818X_TX_CONF_R8180_ABCD (2 25)
+#define RTL818X_TX_CONF_R8180_F (3 25)
+#define RTL818X_TX_CONF_R8185_ABC(4 25)
+#define RTL818X_TX_CONF_R8185_D (5 25)
+#define RTL818X_TX_CONF_HWVER_MASK (7 25)
+#define RTL818X_TX_CONF_CW_MIN (1 31)
+ __le32 RX_CONF;
+#define RTL818X_RX_CONF_MONITOR (1 0)
+#define RTL818X_RX_CONF_NICMAC (1 1)
+#define RTL818X_RX_CONF_MULTICAST(1 2)
+#define RTL818X_RX_CONF_BROADCAST(1 3)
+#define RTL818X_RX_CONF_DATA (1 18)
+#define RTL818X_RX_CONF_CTRL (1 19
[PATCH 1/2] Add 93cx6 eeprom library
From: Ivo van Doorn [EMAIL PROTECTED]
This patch adds a library for reading from and writing to 93cx6 eeproms.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/misc/Kconfig |6 +
drivers/misc/Makefile|1
drivers/misc/eeprom_93cx6.c | 347 ++
include/linux/eeprom_93cx6.h | 77 +
4 files changed, 431 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3c525b..607a180 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -178,4 +178,10 @@ config THINKPAD_ACPI_BAY
If you are not sure, say Y here.
+config EEPROM_93CX6
+ tristate EEPROM 93CX6 support
+ ---help---
+ This is a driver for the EEPROM chipsets 93c46 and 93c66.
+ The driver supports both read as well as write commands.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e325164..42b34a9 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_TIFM_7XX1) += tifm_7
obj-$(CONFIG_SGI_IOC4) += ioc4.o
obj-$(CONFIG_SONY_LAPTOP) += sony-laptop.o
obj-$(CONFIG_THINKPAD_ACPI)+= thinkpad_acpi.o
+obj-$(CONFIG_EEPROM_93CX6) += eeprom_93cx6.o
diff --git a/drivers/misc/eeprom_93cx6.c b/drivers/misc/eeprom_93cx6.c
new file mode 100644
index 000..a948ddc
--- /dev/null
+++ b/drivers/misc/eeprom_93cx6.c
@@ -0,0 +1,347 @@
+/*
+ Copyright (C) 2004 - 2006 rt2x00 SourceForge Project
+ http://rt2x00.serialmonkey.com
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Module: eeprom_93cx6
+ Abstract: EEPROM reader routines for 93cx6 chipsets.
+ Supported chipsets: 93c46 93c66.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/version.h
+#include linux/delay.h
+#include linux/eeprom_93cx6.h
+
+MODULE_AUTHOR(http://rt2x00.serialmonkey.com;);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(EEPROM 93cx6 chip driver);
+MODULE_LICENSE(GPL);
+
+static inline void eeprom_93cx6_pulse_high(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 1;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static inline void eeprom_93cx6_pulse_low(struct eeprom_93cx6 *eeprom)
+{
+ eeprom-reg_data_clock = 0;
+ eeprom-register_write(eeprom);
+ udelay(1);
+}
+
+static void eeprom_93cx6_startup(struct eeprom_93cx6 *eeprom)
+{
+ /*
+* Clear all flags, and enable chip select.
+*/
+ eeprom-register_read(eeprom);
+ eeprom-reg_data_in = 0;
+ eeprom-reg_data_out = 0;
+ eeprom-reg_data_clock = 0;
+ eeprom-reg_chip_select = 1;
+ eeprom-register_write(eeprom);
+
+ /*
+* kick a pulse.
+*/
+ eeprom_93cx6_pulse_high(eeprom);
+ eeprom_93cx6_pulse_low(eeprom);
+}
+
+static void eeprom_93cx6_cleanup(struct eeprom_93cx6 *eeprom)
+{
+ /*
+* Clear chip_select and data_in flags.
+*/
+ eeprom-register_read(eeprom);
+ eeprom-reg_data_in = 0;
+ eeprom-reg_chip_select = 0;
+ eeprom-register_write(eeprom);
+
+ /*
+* kick a pulse.
+*/
+ eeprom_93cx6_pulse_high(eeprom);
+ eeprom_93cx6_pulse_low(eeprom);
+}
+
+static void eeprom_93cx6_write_bits(struct eeprom_93cx6 *eeprom,
+ const u16 data, const u16 count)
+{
+ unsigned int i;
+
+ eeprom-register_read(eeprom);
+
+ /*
+* Clear data flags.
+*/
+ eeprom-reg_data_in = 0;
+ eeprom-reg_data_out = 0;
+
+ /*
+* Start writing all bits.
+*/
+ for (i = count; i 0; i--) {
+ /*
+* Check if this bit needs to be set.
+*/
+ eeprom-reg_data_in = !!(data (1 (i - 1)));
+
+ /*
+* Write the bit to the eeprom register.
+*/
+ eeprom-register_write(eeprom);
+
+ /*
+* Kick a pulse.
+*/
+ eeprom_93cx6_pulse_high(eeprom);
+ eeprom_93cx6_pulse_low(eeprom);
+ }
+
+ eeprom-reg_data_in = 0;
+ eeprom-register_write(eeprom);
+}
+
+static void
Re: [PATCH 1/2] Add 93cx6 eeprom library
On Monday 07 May 2007 10:27, Ben Dooks wrote: On Mon, May 07, 2007 at 03:46:04AM -0400, Michael Wu wrote: From: Ivo van Doorn [EMAIL PROTECTED] This patch adds a library for reading from and writing to 93cx6 eeproms. This looks remarkably like an SPI device, why not use the spi framework to drive this? Yeah, it's SPI/microwire. As for using the SPI framework.. I dunno. The rt2x00 drivers depend on this too and I'd rather not change the code at this point since it's well tested and working. Thanks for the heads up about using SPI, however. I (or maybe Ivo if he has any time) will check the SPI framework later and see if that simplifies things. -Michael Wu pgpoT6rdeTeqh.pgp Description: PGP signature
Re: [PATCH v2] Add rtl8187 wireless driver
On Monday 07 May 2007 11:25, Jeff Garzik wrote: I am a bit skeptical that multiple files are needed. It seems like drivers/net/wireless/rtl818x.c would be a better path, a la tg3.c. The radio tuning stuff could be stuffed into rtl8187_dev.c, but I like to keep it separate since rtl8187_rtl8225.c tends to contain all the radio tuning black magic that no one really understands except for the engineers at Realtek, whereas rtl8187_dev.c is mostly straightforward. rtl8187 can also (in theory) use another radio chip (rtl8255). The two headers - rtl818x.h and rtl8187.h cannot be merged because the definitions in rtl818x.h are shared between the usb and pci drivers. I rather not combine any files, though I don't mind collapsing the driver another level. However, I think other driver authors much prefer having their own directory, and I'd like to keep the drivers consistently in their own directory or all together in drivers/net/wireless. -Michael Wu pgpOSGaxbCyiw.pgp Description: PGP signature
Re: Please pull 'upstream' branch of wireless-2.6
On Monday 07 May 2007 19:09, Jeff Garzik wrote: The general idea is everything you want in 2.6.22 should be prepared and in -mm BEFORE 2.6.21 is released, and the 2.6.22 merge window opens. rtl8187 has been in -mm since 2.6.21-rc2-mm1. -Michael Wu pgpqlzKVzSGGX.pgp Description: PGP signature
Re: [PATCH v2] Add rtl8187 wireless driver
On Monday 07 May 2007 19:25, David Miller wrote: I know this sounds trite, but when merging and researching up to 450 patches at a time like I have to, this stuff starts to matter. Please put things as high in the directory hierachy as possible and when you can put the entire driver into a single source file do so. Sure. I generally prefer that too, but all the drivers I put in wireless-dev were put in separate directories because I didn't want to break the pattern. The only significant argument you present is the code sharing one for the radio stuff, but that isn't realized yet and you can certainly split the code out once you make that sharing a reality. Having different modules for different radio chips really isn't the point of keeping it in a separate file. (in fact, rtl8187_rtl8225.c actually contains support for two versions of the rtl8225 radio) It's just that rtl8187_rtl8225.c is basically a bunch of numbers with a bit of glue code to send them to the hardware. Not much is missed if you decide not to look at how the radio tuning works, and I like to avoid looking at that code if I can. It's also consistent with how the (unreleased) rtl8180 driver works, which really does have support for different radios in different files. But of course, we can just make an exception for rtl8187. Would merging the files together make that much of a difference for you? -Michael Wu pgpXT8QQmP8PQ.pgp Description: PGP signature
Re: [PATCH RESEND] zd1211rw-mac80211: changed Kconfig
On Sunday 11 March 2007 15:19, Daniel Drake wrote: Changed the reference to Devicescape stack to mac80211. I referred to Devicescape originally because the only other driver that had both softmac and devicescape versions was bcm43xx, so I copied (DeviceScape stack) in order to be consistent. I would prefer that there be one patch to replace both instances of (DeviceScape stack) with (mac80211 stack). -Michael Wu pgpdfFfONCtcV.pgp Description: PGP signature
d80211-drivers pull request (week05)
Hi John, Please pull git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git for these patches: adm8211-week05 branch: Michael Wu (1): adm8211: set MAC address properly p54-week05 branch: Michael Wu (3): p54: set MAC address properly p54usb: silence warnings on BE p54pci: make work for big endian zd1211rw-week05 branch: Daniel Drake (3): zd1211rw-d80211: Generic HMAC initialization zd1211rw-d80211: Consistency for address space constants zd1211rw-d80211: Remove addressing abstraction Maxime Austruy (1): zd1211rw-d80211: fix potential leak in usb_init Michael Wu (1): zd1211rw-d80211: Support for multicast addresses Ulrich Kunitz (2): zd1211rw-d80211: Fixed array size issue in reset_mode zd1211rw-d80211: Reset device in the probe call Common to all branches: Michael Wu (1): Remove unnecessary includes and SET_MODULE_OWNER Patches ported from zd1211rw (softmac) now have the original author of the patch set as the author in the commit when the porting was trivial. Thanks, -Michael Wu pgpT98sDPxRFk.pgp Description: PGP signature
Re: [PATCH 3/3] d80211-p54: Add control structure for beacontemplates
On Saturday 03 February 2007 11:25, Ivo van Doorn wrote: p54 seems to ignore the beacon that is being passed, even though it is requesting the BEACON_TEMPLATE. That is why I not only added a line to free the control structure but also the beacon itself. Yeah, beacons aren't actually handled yet. BEACON_TEMPLATE can just be turned off for now if it's causing problems, though I don't see a reason why a beacon would be generated for managed mode. -Michael Wu pgp4nEF1flQzu.pgp Description: PGP signature
Re: [PATCH 3/3] d80211-p54: Add control structure for beacontemplates
On Saturday 03 February 2007 11:40, Ivo van Doorn wrote: It would only be generated for AP mode. In any case, the new patch: Signed-off-by Ivo van Doorn [EMAIL PROTECTED] ACK Thanks, -Michael Wu pgprYlsoEM9TR.pgp Description: PGP signature
Re: [PATCH] d80211: select CRC32 functions
On Wednesday 24 January 2007 04:35, Marcus Better wrote: The d80211 stack requires CRC32 functions for the WEP implementation. ACK. Please CC John Linville [EMAIL PROTECTED] and Jiri Benc [EMAIL PROTECTED] on d80211 patches next time. Thanks, -Michael Wu pgp7BD1v6LTlQ.pgp Description: PGP signature
Re: [RFC PATCH] bcm43xx: set channel when the interface is brought up
On Thursday 25 January 2007 01:50, Pavel Roskin wrote: If the hardware drivers are supposed to do it, here's my patch. It is working fine for me and ready to be applied. The changelog is in the subject. Let's fix this in the stack. This problem will be fixed for most users once auto channel selection is implemented, and fixing it for users manually setting the channel should be trivial. -Michael Wu pgp5LtQxHoU24.pgp Description: PGP signature
Re: Soft lockups with dscape on wireless-dev tree
On Tuesday 23 January 2007 12:10, Jon Smirl wrote: I've hit this twice. This time I unplugged my USB hub which had the device in it. Please try the patch I posted earlier: http://marc.theaimsgroup.com/?l=linux-netdevm=116841004113998w=2 Also can be found here: http://kernel.org/git/?p=linux/kernel/git/jbenc/dscape.git;a=commitdiff_plain;h=e3973cb079b24875af1f196d03569ce7eb517c92;hp=f85c9f7b6a0fe662b95595c51aed92d784e93c5e -Michael Wu pgpOMGuxIjYio.pgp Description: PGP signature
Re: dscape doesn't auto associate
On Tuesday 23 January 2007 18:23, Jon Smirl wrote: I have to manually associate the dscape stack with my AP. Is this way the code is supposed to work? Everything works ok after the manual association. It's suppose to work with wpa_supplicant which sets every parameter. NetworkManager uses wpa_supplicant so configuration can be pretty easy. If you really want to manually associate, set the channel, (e)ssid, and encryption (if any) in any order, and then set the bssid (ap) last. There will be patches to allow association by just setting the SSID for backwards compatibility with configuration scripts. -Michael Wu pgpzpfom9PxaA.pgp Description: PGP signature
Re: dscape doesn't auto associate
On Tuesday 23 January 2007 20:48, Jon Smirl wrote: As for running as an AP: rt2570 will start in Master mode zd1211 refused to set Master mode No master mode support in zd1211 yet - I haven't had time (and the other two developers don't work on the d80211 version yet). Only client mode is currently supported. -Michael Wu pgpgKymarwK0A.pgp Description: PGP signature
Re: dscape doesn't auto associate
On Tuesday 23 January 2007 20:48, Jon Smirl wrote: I'll try running NetworkManager in the debugger and see if I can figure out what is failing. NetworkManager is working ok for me on non-dscape devices. Dan, any idea what's happening? FWIW, I'm running NetworkManager 0.6.2 (from SuSE 10.1) with wpa_supplicant 0.5.7. zd1211 has this problem too: Error for wireless request Set Encode (8B2A) : SET failed on device wlan1 ; Invalid argument. Shouldn't happen if it works for rt2570. Both use software encryption. -Michael Wu pgpGy8QeW2zFa.pgp Description: PGP signature
Re: adm8211 (from linville wireless-2.6) in xen guest
On Saturday 20 January 2007 07:19, Jan Evert van Grootheest wrote: Hi, Just writing to thank all of you that made the adm8211 driver in John Linvilles wireless-2.6 development tree (not the dscape one, which I will try also). CC me then. :) Note that I only maintain the d80211 based adm8211 driver now, but that driver doesn't have adhoc support yet. One question, though. I'm trying to use it in ad-hoc mode. If there's no other station with the same essid, it just keeps mentioning that (besides the BCNTC and TSFTF messages) wlan0: No matching adhoc sta found. Creating IBSS 00:04:e2:3f:2a:70 CHAN=11 And the IBSS changes every time, which is about every 30 seconds. Is it really supposed to change the IBSS each time? Probably not, but I never debugged adhoc mode enough. The reason I ask is that my wife has a laptop with an Atheros chip in it. If it is configured for ad-hoc it creates the IBSS and sticks with it. So I now have two computers that have different behaviour in this respect. That in itself is not, I guess, a problem. But it seems to me that the random IBSS created by the adm8211 would result in two stations not seeing eachother or taking longer than necessary to find eachother? Have you checked? I think the bssid should stop changing once another station with the same ssid comes into range. And one more question that I don't understand... the wlan0 interface does not appear in snmp queries. Any idea about that? Nope. -Michael Wu pgp27kMghCcBL.pgp Description: PGP signature
Re: TKIP encryption should allocate enough tailroom
On Tuesday 16 January 2007 21:31, Brandon Craig Rhodes wrote: The attached patch, if applied to kernel 2.6.18, solves both problems. I am not very familiar with the conventions of kernel networking code, so there may be better ways of fixing this; but the patch should illustrate the general idea, and perhaps provides others in my unhappy situation with stable WPA connections until someone can provide a more authorized patch. Please read http://linux.yyz.us/patch-format.html. You should CC [EMAIL PROTECTED] as he is the maintainer of 802.11 things and can push your patch upstream. Also, you should have a '\n' at the end of the new printks. Thanks, -Michael Wu pgpFrRiLusyw0.pgp Description: PGP signature
Re: Using 802.11x wireless usb device on MIPS platform
On Tuesday 09 January 2007 09:09, Ralf Baechle wrote: On Tue, Jan 09, 2007 at 10:52:14AM +0800, colin wrote: I have used two 802.11x wireless usb devices successfully on MIPS platform. One is realtek 8187 and the other one is ralink 2571. I would like to put them into kernel tree and then I found that there are not many 802.11x devices supported in Linux. Please see the wireless-dev tree. There is a driver for the ralink 2571 in there which will be merged along with a number of other wireless drivers when the devicescape 802.11 (d80211) wireless stack is sufficiently polished. New softmac wireless drivers should be based on that stack if possible. I am working on a d80211 version of the rtl8187/rtl8185 driver right now, which is I think is the last linux 802.11g driver which needs to be ported. -Michael Wu pgpLv2C3LmE6G.pgp Description: PGP signature
[PATCH] d80211: Fix __ieee80211_if_del on live interfaces
d80211: Fix __ieee80211_if_del on live interfaces
ieee80211_if_reinit is called in __ieee80211_if_del, which clears the
contents of sdata-u. After that, unregister_netdevice is called. If the
interface is still up, unregister_netdevice will end up calling dev-stop,
and dev-stop expects the contents of sdata-u to be valid. Bad things
typically happen at this point.
This patch fixes that by setting dev-uninit to ieee80211_if_reinit and
eliminating the call to ieee80211_if_reinit in __ieee80211_if_del. This
allows ieee80211_if_reinit to be called at a safer time. It also allows
the removal of the call to ieee80211_if_shutdown in ieee80211_if_reinit
because ieee80211_if_reinit now will never be called while the interface
is up.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
net/d80211/ieee80211.c |2 ++
net/d80211/ieee80211_iface.c |4
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 964fe45..2f1dce5 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -4324,6 +4324,7 @@ void ieee80211_if_setup(struct net_devic
dev-open = ieee80211_open;
dev-stop = ieee80211_stop;
dev-tx_queue_len = 0;
+ dev-uninit = ieee80211_if_reinit;
dev-destructor = ieee80211_if_free;
}
@@ -4338,6 +4339,7 @@ void ieee80211_if_mgmt_setup(struct net_
dev-type = ARPHRD_IEEE80211_PRISM;
dev-hard_header_parse = header_parse_80211;
dev-tx_queue_len = 0;
+ dev-uninit = ieee80211_if_reinit;
dev-destructor = ieee80211_if_free;
}
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index cac0dd5..3b2d259 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -234,9 +234,6 @@ void ieee80211_if_reinit(struct net_devi
sdata-keys[i] = NULL;
}
- /* Shouldn't be necessary but won't hurt */
- ieee80211_if_shutdown(dev);
-
switch (sdata-type) {
case IEEE80211_IF_TYPE_AP: {
/* Remove all virtual interfaces that use this BSS
@@ -311,7 +308,6 @@ void __ieee80211_if_del(struct ieee80211
{
struct net_device *dev = sdata-dev;
- ieee80211_if_reinit(dev);
list_del(sdata-list);
ieee80211_sysfs_remove_netdevice(dev);
unregister_netdevice(dev);
pgpalZ3hw8dLv.pgp
Description: PGP signature
Re: [PATCH] d80211: Only free WEP crypto ciphers when they have been allocated correctly.
On Saturday 06 January 2007 12:00, Gertjan van Wingerde wrote: The d80211 stack still tries to free the WEP crypto ciphers, even when allocating them previously has failed. Actually, the code might not even have tried to allocate them. The ciphers are guaranteed to be allocated when the device is registered however, so we should be able to free it safely on unregister. Signed-off-by: Michael Wu [EMAIL PROTECTED] --- net/d80211/ieee80211.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c index 6e10db5..926d160 100644 --- a/net/d80211/ieee80211.c +++ b/net/d80211/ieee80211.c @@ -4715,6 +4715,7 @@ void ieee80211_unregister_hw(struct ieee skb_queue_purge(local-skb_queue_unreliable); ieee80211_dev_free_index(local); + ieee80211_wep_free(local); ieee80211_led_exit(local); } EXPORT_SYMBOL(ieee80211_unregister_hw); @@ -4724,7 +4725,6 @@ void ieee80211_free_hw(struct ieee80211_ struct ieee80211_local *local = hw_to_local(hw); ieee80211_if_free(local-mdev); - ieee80211_wep_free(local); ieee80211_dev_free(local); } EXPORT_SYMBOL(ieee80211_free_hw); pgpj7Z6FryVOG.pgp Description: PGP signature
Fixes for d80211 hwmode API change
These attached patches are a simplified version of Michael Buesch's original
hwmode API patches to adm8211, p54, and zd1211rw-d80211. These will be
necessary once you pull up2 from Jiri Benc's tree.
Thanks,
-Michael Wu
adm8211: Fix compilation for d80211 hwmode API change
From: Michael Wu [EMAIL PROTECTED]
This fixes compilation for the d80211 hwmode API change.
Based on a patch by Michael Buesch [EMAIL PROTECTED].
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c |8 ++--
drivers/net/wireless/d80211/adm8211/adm8211.h |2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c b/drivers/net/wireless/d80211/adm8211/adm8211.c
index d7fb484..3bdcec3 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -2035,8 +2035,6 @@ static int __devinit adm8211_probe(struc
dev-channel_change_time = 1000;
dev-maxssi = ADM8211_RX_MAX_SSI;// FIXME - This is an approximation
- dev-num_modes = 1;
- dev-modes = priv-modes;
priv-modes[0].mode = MODE_IEEE80211B;
/* channel info filled in by adm8211_read_eeprom */
memcpy(priv-rates, adm8211_rates, sizeof(adm8211_rates));
@@ -2069,6 +2067,12 @@ static int __devinit adm8211_probe(struc
priv-channel = priv-modes[0].channels[0].chan;
+ err = ieee80211_register_hwmode(dev, priv-modes[0]);
+ if (err) {
+ printk(KERN_ERR %s (adm8211): Cannot register hwmode\n, pci_name(pdev));
+ goto err_free_desc;
+ }
+
err = ieee80211_register_hw(dev);
if (err) {
printk(KERN_ERR %s (adm8211): Cannot register hardware\n, pci_name(pdev));
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.h b/drivers/net/wireless/d80211/adm8211/adm8211.h
index 06c54bc..dc7902f 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.h
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.h
@@ -532,7 +532,7 @@ struct adm8211_priv {
unsigned cur_tx, dirty_tx, cur_rx;
struct ieee80211_low_level_stats stats;
- struct ieee80211_hw_modes modes[1];
+ struct ieee80211_hw_mode modes[1];
struct ieee80211_rate rates[ARRAY_SIZE(adm8211_rates)];
int mode;
p54: Fix compilation for d80211 hwmode API change
From: Michael Wu [EMAIL PROTECTED]
This fixes compilation for the d80211 hwmode API change.
Based on a patch by Michael Buesch [EMAIL PROTECTED].
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/p54/prism54.h |2 +-
drivers/net/wireless/d80211/p54/prism54common.c | 11 ---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/d80211/p54/prism54.h b/drivers/net/wireless/d80211/p54/prism54.h
index 5e4f331..de8197e 100644
--- a/drivers/net/wireless/d80211/p54/prism54.h
+++ b/drivers/net/wireless/d80211/p54/prism54.h
@@ -63,7 +63,7 @@ struct p54_common {
/* FIXME: this channels/modes/rates stuff sucks */
struct ieee80211_channel channels[14];
struct ieee80211_rate rates[12];
- struct ieee80211_hw_modes modes[2];
+ struct ieee80211_hw_mode modes[2];
};
int p54_rx(struct ieee80211_hw *dev, struct sk_buff *skb);
diff --git a/drivers/net/wireless/d80211/p54/prism54common.c b/drivers/net/wireless/d80211/p54/prism54common.c
index 185cd53..2e19bf4 100644
--- a/drivers/net/wireless/d80211/p54/prism54common.c
+++ b/drivers/net/wireless/d80211/p54/prism54common.c
@@ -745,6 +745,7 @@ struct ieee80211_hw *p54_init_common(siz
{
struct ieee80211_hw *dev;
struct p54_common *priv;
+ int i;
dev = ieee80211_alloc_hw(priv_data_len, p54_ops);
if (!dev)
@@ -774,13 +775,17 @@ struct ieee80211_hw *p54_init_common(siz
dev-channel_change_time = 1000; /* TODO: find actual value */
dev-maxssi = 100; // just to avoid dividing by zero
- dev-num_modes = 2;
- dev-modes = priv-modes;
-
dev-queues = 1;
dev-extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
sizeof(struct p54_tx_control_allocdata);
+ for (i = 0; i 2; i++) {
+ if (ieee80211_register_hwmode(dev, priv-modes[i])) {
+ ieee80211_free_hw(dev);
+ return NULL;
+ }
+ }
+
return dev;
}
EXPORT_SYMBOL_GPL(p54_init_common);
zd1211rw-d80211: Fix compilation for d80211 hwmode API change
From: Michael Wu [EMAIL PROTECTED]
This fixes compilation for the d80211 hwmode API change.
Based on a patch by Michael Buesch [EMAIL PROTECTED].
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/zd1211rw/zd_mac.c | 12 +---
drivers/net/wireless/d80211/zd1211rw/zd_mac.h |2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
index 6ee650f..35c90fb 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
@@ -574,6 +574,7 @@ struct ieee80211_hw *zd_mac_alloc(struct
{
struct zd_mac *mac;
struct ieee80211_hw *dev;
+ int i;
dev = ieee80211_alloc_hw(sizeof(struct zd_mac
d80211-drivers pull request (week51)
Hi John,
Please pull
git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git
for these patches:
adm8211-week51 branch:
adm8211: set phymode in RX
p54-week51 branch:
p54: fix device memory allocator
p54: fix TX of encrypted frames
p54: remove unnecessary use of __constant_cpu_to_*
p54: use hardware RX frequency reporting
p54: use link LED
p54: fix issues found by sparse
p54: set phymode in RX
zd1211rw-week51 branch:
zd1211rw-d80211: Fix of a locking bug
zd1211rw-d80211: Revert zd1211rw: Removed unneeded packed attributes
zd1211rw-d80211: Add 3 more device IDs
zd1211rw-d80211: Add ID for ZyXEL G-220
zd1211rw-d80211: Add ID for Planex GW-US54Mini
zd1211rw-d80211: Add ID for Belkin F5D7050 v4000
zd1211rw-d80211: cleanups
zd1211rw-d80211: Optimized handling of zero length entries in length info
zd1211rw-d80211: check IEEE80211_TXCTL_USE_CTS_PROTECT
zd1211rw-d80211: Use ieee80211_tx_status
zd1211rw-d80211: 2 new ZD1211B device ID's
zd1211rw-d80211: Add ID for Linksys WUSBF54G
The LED class patch for zd1211rw-d80211 was dropped.
A patch which updates zd1211rw-d80211 to the new workqueue API is attached
for when you pull those changes.
Thanks,
-Michael Wu
zd1211rw-d80211: fix workqueue breakage
From: Michael Wu [EMAIL PROTECTED]
This allows zd1211rw-d80211 to compile with the workqueue API changes.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/zd1211rw/zd_mac.c |7 ---
drivers/net/wireless/d80211/zd1211rw/zd_mac.h |2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
index 6ee650f..7044ea3 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
@@ -625,9 +625,10 @@ struct ieee80211_hw *zd_mac_alloc(struct
#define LINK_LED_WORK_DELAY HZ
-static void link_led_handler(void *p)
+static void link_led_handler(struct work_struct *work)
{
- struct zd_mac *mac = p;
+ struct zd_mac *mac =
+ container_of(work, struct zd_mac, housekeeping.link_led_work);
struct zd_chip *chip = mac-chip;
int is_associated;
int r;
@@ -647,7 +648,7 @@ static void link_led_handler(void *p)
static void housekeeping_init(struct zd_mac *mac)
{
- INIT_WORK(mac-housekeeping.link_led_work, link_led_handler, mac);
+ INIT_DELAYED_WORK(mac-housekeeping.link_led_work, link_led_handler);
}
static void housekeeping_enable(struct zd_mac *mac)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.h b/drivers/net/wireless/d80211/zd1211rw/zd_mac.h
index e2ba410..6c402d9 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.h
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.h
@@ -119,7 +119,7 @@ enum mac_flags {
};
struct housekeeping {
- struct work_struct link_led_work;
+ struct delayed_work link_led_work;
};
#define ZD_MAC_STATS_BUFFER_SIZE 16
pgpm7T0K5zliF.pgp
Description: PGP signature
Re: d80211 constants inside d80211_common.h
On Wednesday 27 December 2006 03:32, Nick Kossifidis wrote: I did a grep inside drivers/net/wireless/d80211/* and they are not used yet in drivers. Can you plz fix it before drivers start using them ? Already fixed, just waiting for wireless-dev to get it. http://kernel.org/git/?p=linux/kernel/git/jbenc/dscape.git;a=commitdiff;h=4ae94181f808da96352478c6d4102e3b0b5dfaac -Michael Wu pgpiiIQUKezSE.pgp Description: PGP signature
Re: d80211 constants inside d80211_common.h
On Wednesday 27 December 2006 12:26, Nick Kossifidis wrote: We need those definitions for setting up the rate tables in dadwifi, phytypes are needed inside drivers, take a look here - http://madwifi.org/browser/branches/dadwifi-openhal/openhal/ar5xxx.h?rev=18 67 MODE_IEEE80211A/B/G and IEEE80211_RATE_* not enough? The definitions in d80211_common.h are used for communications with userspace, not drivers. If you are using the ieee80211_phytype_* in things that are passed to d80211, it is wrong. If you are not, you can switch to MODE_IEEE80211A/B/G and IEEE80211_RATE_*, though I think MODE_IEEE80211A/B/G should be all you need. Even if it does get out, constants should be in capitals. Sure. Submit a patch. :) -Michael Wu pgpT0vuMOW8nC.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
On Wednesday 20 December 2006 20:15, Matthew Garrett wrote: Because it works on the common hardware? If there's documentation about what userspace can legitimately expect, then I'm happy to defer to that. But in the absence of any indication as to what functionality users can depend on, deciding that existing functionality is a bug is, well, impolite. No, it's absolutely a bug. It just so happens that some drivers incorrectly allowed it. -Michael Wu pgpc8jW7GJRT5.pgp Description: PGP signature
[PATCH] d80211: allow migration to ieee80211_dev
d80211: allow migration to ieee80211_dev
This patch allows drivers to switch from ieee80211_hw to ieee80211_dev before
we really rename ieee80211_hw and break everything.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
include/net/d80211.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 65a5d36..f5de509 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -452,6 +452,9 @@ typedef enum {
SET_KEY, DISABLE_KEY, REMOVE_ALL_KEYS,
} set_key_cmd;
+/* Will go away once ieee80211_hw is really renamed to ieee80211_dev.
+ Please use ieee80211_dev in your driver. */
+#define ieee80211_dev ieee80211_hw
/* This is driver-visible part of the per-hw state the stack keeps. */
struct ieee80211_hw {
/* these are assigned by d80211, don't write */
pgp5zRV9mzULU.pgp
Description: PGP signature
Re: [PATCH] d80211: add radiotap support
On Monday 18 December 2006 12:20, David Kimdon wrote: htons and friends can handle determining the argument is a constant on their own, so this change should be dropped. Hm, appears so. Didn't know that. I'll resend the patch without this change. Thanks, -Michael Wu pgpAgXQMS5hq0.pgp Description: PGP signature
Re: [PATCH] d80211: add radiotap support
On Monday 18 December 2006 14:31, Jiri Benc wrote: Shouldn't the stack create the radiotap header for the driver? I will replace the current avs header generating code with basic (fixed len header) radiotap code too, but since radiotap is a variable length header, it is easier for the driver to fill it properly. Having drivers fill the radiotap header also avoids the problem of running out of header space. -Michael Wu pgpHliOi1pRSA.pgp Description: PGP signature
[PATCH] d80211: add radiotap support (v2)
d80211: add radiotap support
This patch adds support for radiotap to d80211. The driver must set
IEEE80211_HW_MONITOR_DURING_OPER as well as
IEEE80211_HW_RADIOTAP_SUPPORTED, and it must send radiotap frames when
there is at least one monitor interface up. Tested with zd1211rw-d80211.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
include/net/d80211.h |3 +++
net/d80211/ieee80211.c | 41 -
net/d80211/ieee80211_iface.c |5 -
3 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 30980e1..27b2487 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -501,6 +501,9 @@ struct ieee80211_hw {
* per-packet RC4 key with each TX frame when doing hwcrypto */
#define IEEE80211_HW_TKIP_REQ_PHASE2_KEY (114)
+ /* Driver supports radiotap. Temporary until all drivers support it. */
+#define IEEE80211_HW_RADIOTAP_SUPPORTED (120)
+
u32 flags; /* hardware flags defined above */
/* Set to the size of a needed device specific skb headroom for TX
skbs. */
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 6e10db5..a73046c 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -8,6 +8,7 @@
*/
#include net/d80211.h
+#include net/ieee80211_radiotap.h
#include linux/module.h
#include linux/init.h
#include linux/netdevice.h
@@ -284,6 +285,14 @@ int ieee80211_get_hdrlen_from_skb(struct
}
EXPORT_SYMBOL(ieee80211_get_hdrlen_from_skb);
+static int ieee80211_get_radiotap_len(struct sk_buff *skb)
+{
+ struct ieee80211_radiotap_header *hdr =
+ (struct ieee80211_radiotap_header *) skb-data;
+
+ return le16_to_cpu(hdr-it_len);
+}
+
#ifdef CONFIG_D80211_LOWTX_FRAME_DUMP
static void ieee80211_dump_frame(const char *ifname, const char *title,
struct sk_buff *skb)
@@ -2650,17 +2659,19 @@ ieee80211_rx_monitor(struct net_device *
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- if (skb_headroom(skb) hlen) {
- I802_DEBUG_INC(local-rx_expand_skb_head);
- if (pskb_expand_head(skb, hlen, 0, GFP_ATOMIC)) {
- dev_kfree_skb(skb);
-return;
+ if (!(local-hw.flags IEEE80211_HW_RADIOTAP_SUPPORTED)) {
+ if (skb_headroom(skb) hlen) {
+ I802_DEBUG_INC(local-rx_expand_skb_head);
+ if (pskb_expand_head(skb, hlen, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return;
+ }
}
- }
- fi = (struct ieee80211_frame_info *) skb_push(skb, hlen);
+ fi = (struct ieee80211_frame_info *) skb_push(skb, hlen);
+ ieee80211_fill_frame_info(local, fi, status);
+ }
- ieee80211_fill_frame_info(local, fi, status);
sdata-stats.rx_packets++;
sdata-stats.rx_bytes += skb-len;
@@ -3064,6 +3075,10 @@ ieee80211_rx_h_monitor(struct ieee80211_
return TXRX_QUEUED;
}
+ if (rx-local-monitors
+ rx-local-hw.flags IEEE80211_HW_RADIOTAP_SUPPORTED)
+ skb_pull(rx-skb, ieee80211_get_radiotap_len(rx-skb));
+
return TXRX_CONTINUE;
}
@@ -3628,6 +3643,13 @@ void __ieee80211_rx(struct ieee80211_hw
struct ieee80211_txrx_data rx;
u16 type;
int multicast;
+ int radiotap_len = 0;
+
+ if (local-monitors
+ local-hw.flags IEEE80211_HW_RADIOTAP_SUPPORTED) {
+ radiotap_len = ieee80211_get_radiotap_len(skb);
+ skb_pull(skb, radiotap_len);
+ }
hdr = (struct ieee80211_hdr *) skb-data;
memset(rx, 0, sizeof(rx));
@@ -3664,6 +3686,7 @@ void __ieee80211_rx(struct ieee80211_hw
goto end;
skb = rx.skb;
+ skb_push(skb, radiotap_len);
if (sta !sta-assoc_ap !(sta-flags WLAN_STA_WDS)
!local-iff_promiscs !multicast) {
rx.u.rx.ra_match = 1;
@@ -3672,7 +3695,7 @@ void __ieee80211_rx(struct ieee80211_hw
} else {
struct ieee80211_sub_if_data *prev = NULL;
struct sk_buff *skb_new;
- u8 *bssid = ieee80211_get_bssid(hdr, skb-len);
+ u8 *bssid = ieee80211_get_bssid(hdr, skb-len - radiotap_len);
list_for_each_entry(sdata, local-sub_if_list, list) {
rx.u.rx.ra_match = 1;
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 3e9d531..c1bb6d0 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -198,7 +198,10 @@ void ieee80211_if_set_type(struct net_de
break;
}
case IEEE80211_IF_TYPE_MNTR:
- dev-type = ARPHRD_IEEE80211_PRISM;
+ if (sdata-local-hw.flags
[PATCH] d80211: add radiotap support
d80211: add radiotap support
This patch adds support for radiotap to d80211. The driver must set
IEEE80211_HW_MONITOR_DURING_OPER as well as
IEEE80211_HW_RADIOTAP_SUPPORTED, and it must send radiotap frames when
there is at least one monitor interface up. Tested with zd1211rw-d80211.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
include/net/d80211.h |3 +++
net/d80211/ieee80211.c | 43 --
net/d80211/ieee80211_iface.c |5 -
3 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 30980e1..27b2487 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -501,6 +501,9 @@ struct ieee80211_hw {
* per-packet RC4 key with each TX frame when doing hwcrypto */
#define IEEE80211_HW_TKIP_REQ_PHASE2_KEY (114)
+ /* Driver supports radiotap. Temporary until all drivers support it. */
+#define IEEE80211_HW_RADIOTAP_SUPPORTED (120)
+
u32 flags; /* hardware flags defined above */
/* Set to the size of a needed device specific skb headroom for TX
skbs. */
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 6e10db5..c686f02 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -8,6 +8,7 @@
*/
#include net/d80211.h
+#include net/ieee80211_radiotap.h
#include linux/module.h
#include linux/init.h
#include linux/netdevice.h
@@ -284,6 +285,14 @@ int ieee80211_get_hdrlen_from_skb(struct
}
EXPORT_SYMBOL(ieee80211_get_hdrlen_from_skb);
+static int ieee80211_get_radiotap_len(struct sk_buff *skb)
+{
+ struct ieee80211_radiotap_header *hdr =
+ (struct ieee80211_radiotap_header *) skb-data;
+
+ return le16_to_cpu(hdr-it_len);
+}
+
#ifdef CONFIG_D80211_LOWTX_FRAME_DUMP
static void ieee80211_dump_frame(const char *ifname, const char *title,
struct sk_buff *skb)
@@ -2650,24 +2659,26 @@ ieee80211_rx_monitor(struct net_device *
sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- if (skb_headroom(skb) hlen) {
- I802_DEBUG_INC(local-rx_expand_skb_head);
- if (pskb_expand_head(skb, hlen, 0, GFP_ATOMIC)) {
- dev_kfree_skb(skb);
-return;
+ if (!(local-hw.flags IEEE80211_HW_RADIOTAP_SUPPORTED)) {
+ if (skb_headroom(skb) hlen) {
+ I802_DEBUG_INC(local-rx_expand_skb_head);
+ if (pskb_expand_head(skb, hlen, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return;
+ }
}
- }
- fi = (struct ieee80211_frame_info *) skb_push(skb, hlen);
+ fi = (struct ieee80211_frame_info *) skb_push(skb, hlen);
+ ieee80211_fill_frame_info(local, fi, status);
+ }
- ieee80211_fill_frame_info(local, fi, status);
sdata-stats.rx_packets++;
sdata-stats.rx_bytes += skb-len;
skb-mac.raw = skb-data;
skb-ip_summed = CHECKSUM_UNNECESSARY;
skb-pkt_type = PACKET_OTHERHOST;
- skb-protocol = htons(ETH_P_802_2);
+ skb-protocol = __constant_htons(ETH_P_802_2);
memset(skb-cb, 0, sizeof(skb-cb));
netif_rx(skb);
}
@@ -3064,6 +3075,10 @@ ieee80211_rx_h_monitor(struct ieee80211_
return TXRX_QUEUED;
}
+ if (rx-local-monitors
+ rx-local-hw.flags IEEE80211_HW_RADIOTAP_SUPPORTED)
+ skb_pull(rx-skb, ieee80211_get_radiotap_len(rx-skb));
+
return TXRX_CONTINUE;
}
@@ -3628,6 +3643,13 @@ void __ieee80211_rx(struct ieee80211_hw
struct ieee80211_txrx_data rx;
u16 type;
int multicast;
+ int radiotap_len = 0;
+
+ if (local-monitors
+ local-hw.flags IEEE80211_HW_RADIOTAP_SUPPORTED) {
+ radiotap_len = ieee80211_get_radiotap_len(skb);
+ skb_pull(skb, radiotap_len);
+ }
hdr = (struct ieee80211_hdr *) skb-data;
memset(rx, 0, sizeof(rx));
@@ -3664,6 +3686,7 @@ void __ieee80211_rx(struct ieee80211_hw
goto end;
skb = rx.skb;
+ skb_push(skb, radiotap_len);
if (sta !sta-assoc_ap !(sta-flags WLAN_STA_WDS)
!local-iff_promiscs !multicast) {
rx.u.rx.ra_match = 1;
@@ -3672,7 +3695,7 @@ void __ieee80211_rx(struct ieee80211_hw
} else {
struct ieee80211_sub_if_data *prev = NULL;
struct sk_buff *skb_new;
- u8 *bssid = ieee80211_get_bssid(hdr, skb-len);
+ u8 *bssid = ieee80211_get_bssid(hdr, skb-len - radiotap_len);
list_for_each_entry(sdata, local-sub_if_list, list) {
rx.u.rx.ra_match = 1;
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 3e9d531..c1bb6d0 100644
--- a/net/d80211/ieee80211_iface.c
Re: [PATCH] adm8211: Fix compilation for d80211 hwmode API change
On Friday 15 December 2006 14:44, Michael Buesch wrote: This fixes compilation for the d80211 hwmode API change. Signed-off-by: Michael Buesch [EMAIL PROTECTED] ACK, looks good to me. -Michael Wu pgpxYbqaiCNCw.pgp Description: PGP signature
Re: [PATCH] p54: Fix compilation for d80211 hwmode API change
On Friday 15 December 2006 14:45, Michael Buesch wrote: This fixes compilation for the d80211 hwmode API change. Signed-off-by: Michael Buesch [EMAIL PROTECTED] We can't specify modes before device registration now? There would be less duplicated code here if we could. -Michael Wu pgpsOOJjoLRM9.pgp Description: PGP signature
Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver
On Friday 15 December 2006 17:51, Marcelo Tosatti wrote:
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -168,6 +168,23 @@ struct ieee80211_radiotap_header {
* Unitless indication of the Rx/Tx antenna for this packet.
* The first antenna is antenna 0.
*
+ * IEEE80211_RADIOTAP_RX_FLAGS u_int16_t bitmap
+ *
+ * Properties of received frames. See flags defined below.
+ *
+ * IEEE80211_RADIOTAP_TX_FLAGS u_int16_t bitmap
+ *
+ * Properties of transmitted frames. See flags defined below.
+ *
+ * IEEE80211_RADIOTAP_RTS_RETRIES u_int8_tdata
+ *
+ * Number of rts retries a transmitted frame used.
+ *
+ * IEEE80211_RADIOTAP_DATA_RETRIES u_int8_tdata
+ *
+ * Number of unicast retries a transmitted frame used.
+ *
+ *
* IEEE80211_RADIOTAP_FCS u32 data
*
* FCS from frame in network byte order.
@@ -187,7 +204,11 @@ enum ieee80211_radiotap_type {
IEEE80211_RADIOTAP_ANTENNA = 11,
IEEE80211_RADIOTAP_DB_ANTSIGNAL = 12,
IEEE80211_RADIOTAP_DB_ANTNOISE = 13,
- IEEE80211_RADIOTAP_EXT = 31,
+ IEEE80211_RADIOTAP_RX_FLAGS = 14,
+ IEEE80211_RADIOTAP_TX_FLAGS = 15,
+ IEEE80211_RADIOTAP_RTS_RETRIES = 16,
+ IEEE80211_RADIOTAP_DATA_RETRIES = 17,
+ IEEE80211_RADIOTAP_EXT = 31
};
/* Channel flags. */
Did you send this part to netbsd also? We really don't want to fork
radiotap. ;) Also, this should be in a separate patch, but I'm guessing it's
all rolled together for convenience.
-Michael Wu
pgpnuZGgLuAbT.pgp
Description: PGP signature
Re: [PATCH 1/2] d80211: Turn PHYmode list from an array into a linked list
On Thursday 14 December 2006 13:20, Michael Buesch wrote: -int ieee80211_update_hw(struct ieee80211_hw *hw) +int ieee80211_register_hwmode(struct ieee80211_hw *hw, + struct ieee80211_hw_mode *mode) Looks like this function never returns nonzero now. Can it return void instead? This would simplify the fixes for drivers a bit. -Michael Wu pgpbs9yM7GdbU.pgp Description: PGP signature
[PATCH 3/3] d80211: fix workqueue breakage (v2)
d80211: fix workqueue breakage
This patch updates d80211 to use the new workqueue API.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
net/d80211/ieee80211.c |7 ---
net/d80211/ieee80211_i.h |8 +---
net/d80211/ieee80211_iface.c |2 +-
net/d80211/ieee80211_sta.c | 32 +++-
net/d80211/sta_info.c|7 ---
5 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 6e10db5..76ee491 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -2092,13 +2092,13 @@ void ieee80211_if_shutdown(struct net_de
case IEEE80211_IF_TYPE_IBSS:
sdata-u.sta.state = IEEE80211_DISABLED;
cancel_delayed_work(sdata-u.sta.work);
- if (local-scan_work.data == sdata-dev) {
+ if (local-scan_dev == sdata-dev) {
local-sta_scanning = 0;
cancel_delayed_work(local-scan_work);
flush_scheduled_work();
/* see comment in ieee80211_unregister_hw to
* understand why this works */
- local-scan_work.data = NULL;
+ local-scan_dev = NULL;
} else
flush_scheduled_work();
break;
@@ -4486,6 +4486,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(
INIT_LIST_HEAD(local-sub_if_list);
spin_lock_init(local-generic_lock);
+ INIT_DELAYED_WORK(local-scan_work, ieee80211_sta_scan_work);
init_timer(local-stat_timer);
local-stat_timer.function = ieee80211_stat_refresh;
local-stat_timer.data = (unsigned long) local;
@@ -4686,7 +4687,7 @@ void ieee80211_unregister_hw(struct ieee
if (local-stat_time)
del_timer_sync(local-stat_timer);
- if (local-scan_work.data) {
+ if (local-scan_dev) {
local-sta_scanning = 0;
cancel_delayed_work(local-scan_work);
flush_scheduled_work();
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..b7b4b35 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -240,7 +240,7 @@ struct ieee80211_if_sta {
IEEE80211_ASSOCIATE, IEEE80211_ASSOCIATED,
IEEE80211_IBSS_SEARCH, IEEE80211_IBSS_JOINED
} state;
- struct work_struct work;
+ struct delayed_work work;
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
u8 ssid[IEEE80211_MAX_SSID_LEN];
size_t ssid_len;
@@ -429,7 +429,8 @@ struct ieee80211_local {
int scan_channel_idx;
enum { SCAN_SET_CHANNEL, SCAN_SEND_PROBE } scan_state;
unsigned long last_scan_completed;
- struct work_struct scan_work;
+ struct delayed_work scan_work;
+ struct net_device *scan_dev;
int scan_oper_channel;
int scan_oper_channel_val;
int scan_oper_power_level;
@@ -638,7 +639,8 @@ int ieee80211_set_compression(struct iee
struct net_device *dev, struct sta_info *sta);
int ieee80211_init_client(struct net_device *dev);
/* ieee80211_sta.c */
-void ieee80211_sta_work(void *ptr);
+void ieee80211_sta_work(struct work_struct *work);
+void ieee80211_sta_scan_work(struct work_struct *work);
void ieee80211_sta_rx_mgmt(struct net_device *dev, struct sk_buff *skb,
struct ieee80211_rx_status *rx_status);
int ieee80211_sta_set_ssid(struct net_device *dev, char *ssid, size_t len);
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 3e9d531..288dce5 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -185,7 +185,7 @@ void ieee80211_if_set_type(struct net_de
struct ieee80211_if_sta *ifsta;
ifsta = sdata-u.sta;
- INIT_WORK(ifsta-work, ieee80211_sta_work, dev);
+ INIT_DELAYED_WORK(ifsta-work, ieee80211_sta_work);
ifsta-capab = WLAN_CAPABILITY_ESS;
ifsta-auth_algs = IEEE80211_AUTH_ALG_OPEN |
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 04bd5cd..5df585a 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1837,10 +1837,11 @@ static void ieee80211_sta_merge_ibss(str
}
-void ieee80211_sta_work(void *ptr)
+void ieee80211_sta_work(struct work_struct *work)
{
- struct net_device *dev = ptr;
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
u.sta.work.work);
+ struct net_device *dev = sdata-dev;
struct ieee80211_if_sta *ifsta;
if (!netif_running(dev))
@@ -2407,7 +2408,7 @@ static int ieee80211_active_scan(struct
void ieee80211_scan_completed(struct ieee80211_hw *hw)
{
struct ieee80211_local *local = hw_to_local(hw
Re: [PATCH] zd1211rw-d80211: Use LED class
On Wednesday 13 December 2006 17:54, Ulrich Kunitz wrote: I mean on the other hands we break APIs for four or eight bytes and here we spend a whole device strucuture and sysfs directory for something the wlan device firmware represents with a single bit. To call the housekeeping functions overkill under these circumstances appears not to be very rational. I do not consider the housekeeping functions overkill, but the function that it performs (eg. not confusing the user by keeping the LED off) can be done with less brute force. It should also be mentioned that the LEDs on the ZD1211 devices are not independent devices, because they are partly controlled by the firmware. That's exactly where some of the issues with your patch are. The link light can be treated as an independent device as long as the other LED bit is not flipped. As I mentioned before, fixing that isn't a problem. Let the device drivers do the blinking, but give them a chance to know about status changes at the MAC layer, without mandating to implement a LED device. I guess you don't like the LED trigger code currently in d80211 then and would rather see it removed. As far as I can tell, this patch is just a symptom of that issue. -Michael Wu pgp5JTyWMOqu6.pgp Description: PGP signature
Re: [PATCH 1/6] d80211: add IEEE802.11e/WMM MLMEs, Status Code and Reason Code
On Wednesday 13 December 2006 23:02, Zhu Yi wrote:
Signed-off-by: Zhu Yi [EMAIL PROTECTED]
You should probably have more in the description..
---
include/net/d80211_mgmt.h | 148
+ 1 files changed, 148
insertions(+), 0 deletions(-)
d80211_mgmt.h was recently merged into include/linux/ieee80211.h.
d83f6236e756f5f0bb1484d99188f06704de
diff --git a/include/net/d80211_mgmt.h b/include/net/d80211_mgmt.h
index 87141d4..450c0a2 100644
--- a/include/net/d80211_mgmt.h
+++ b/include/net/d80211_mgmt.h
@@ -14,6 +14,39 @@
#include linux/types.h
+struct ieee802_11_ts_info {
+ __le16 traffic_type:1;
+ __le16 tsid:4;
+ __le16 direction:2;
+ __le16 access_policy:2;
+ __le16 aggregation:1;
+ __le16 apsd:1;
+ __le16 up:3;
+ __le16 ack_policy:2;
+ u8 schedule:1;
+ u8 reserved:7;
+} __attribute__ ((packed));
+
Mind eliminating the bitfields?
-Michael Wu
pgp8Ba7jizphp.pgp
Description: PGP signature
Re: [PATCH 3/3] d80211: fix workqueue breakage
On Wednesday 13 December 2006 13:13, Jiri Benc wrote: On Tue, 12 Dec 2006 12:55:53 -0500, Michael Wu wrote: - schedule_work(local-scan_work); + schedule_work(local-scan_work.work); Hm, what is the preferred way here: schedule_work(some_delayed_work.work) or schedule_delayed_work(some_delayed_work, 0)? Hm, according to David Howells, the second is preferred. I'll update the workqueue patch tomorrow. Thanks, -Michael Wu pgp62V3GTJslg.pgp Description: PGP signature
[PATCH 0/3] Fix breakage in d80211
Hi, I've made some patches to make d80211 compile with recent changes in Linus' tree. They've only been compile tested since I haven't bothered to fix merge conflicts (or rather, haven't figured out how to) and make everything compile, but I don't see much of a reason why it shouldn't work. Hope you find this useful. -Michael Wu pgptTNY09pbnm.pgp Description: PGP signature
[PATCH 1/3] d80211: fix wep.c breakage
d80211: fix wep.c breakage This patch fixes wep.c, which was broken by Al Viro's severing skbuff.h - mm.h patch. Signed-off-by: Michael Wu [EMAIL PROTECTED] --- net/d80211/wep.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/d80211/wep.c b/net/d80211/wep.c index dee8eae..6a96ade 100644 --- a/net/d80211/wep.c +++ b/net/d80211/wep.c @@ -15,6 +15,7 @@ #include linux/crc32.h #include linux/crypto.h #include linux/err.h +#include linux/mm.h #include asm/scatterlist.h #include net/d80211.h pgpwt3FSYiljx.pgp Description: PGP signature
[PATCH 3/3] d80211: fix workqueue breakage
d80211: fix workqueue breakage
This patch updates d80211 to use the new workqueue API.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
net/d80211/ieee80211.c |7 ---
net/d80211/ieee80211_i.h |8 +---
net/d80211/ieee80211_iface.c |2 +-
net/d80211/ieee80211_sta.c | 26 ++
net/d80211/sta_info.c|7 ---
5 files changed, 28 insertions(+), 22 deletions(-)
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 6e10db5..76ee491 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -2092,13 +2092,13 @@ void ieee80211_if_shutdown(struct net_de
case IEEE80211_IF_TYPE_IBSS:
sdata-u.sta.state = IEEE80211_DISABLED;
cancel_delayed_work(sdata-u.sta.work);
- if (local-scan_work.data == sdata-dev) {
+ if (local-scan_dev == sdata-dev) {
local-sta_scanning = 0;
cancel_delayed_work(local-scan_work);
flush_scheduled_work();
/* see comment in ieee80211_unregister_hw to
* understand why this works */
- local-scan_work.data = NULL;
+ local-scan_dev = NULL;
} else
flush_scheduled_work();
break;
@@ -4486,6 +4486,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(
INIT_LIST_HEAD(local-sub_if_list);
spin_lock_init(local-generic_lock);
+ INIT_DELAYED_WORK(local-scan_work, ieee80211_sta_scan_work);
init_timer(local-stat_timer);
local-stat_timer.function = ieee80211_stat_refresh;
local-stat_timer.data = (unsigned long) local;
@@ -4686,7 +4687,7 @@ void ieee80211_unregister_hw(struct ieee
if (local-stat_time)
del_timer_sync(local-stat_timer);
- if (local-scan_work.data) {
+ if (local-scan_dev) {
local-sta_scanning = 0;
cancel_delayed_work(local-scan_work);
flush_scheduled_work();
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..b7b4b35 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -240,7 +240,7 @@ struct ieee80211_if_sta {
IEEE80211_ASSOCIATE, IEEE80211_ASSOCIATED,
IEEE80211_IBSS_SEARCH, IEEE80211_IBSS_JOINED
} state;
- struct work_struct work;
+ struct delayed_work work;
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
u8 ssid[IEEE80211_MAX_SSID_LEN];
size_t ssid_len;
@@ -429,7 +429,8 @@ struct ieee80211_local {
int scan_channel_idx;
enum { SCAN_SET_CHANNEL, SCAN_SEND_PROBE } scan_state;
unsigned long last_scan_completed;
- struct work_struct scan_work;
+ struct delayed_work scan_work;
+ struct net_device *scan_dev;
int scan_oper_channel;
int scan_oper_channel_val;
int scan_oper_power_level;
@@ -638,7 +639,8 @@ int ieee80211_set_compression(struct iee
struct net_device *dev, struct sta_info *sta);
int ieee80211_init_client(struct net_device *dev);
/* ieee80211_sta.c */
-void ieee80211_sta_work(void *ptr);
+void ieee80211_sta_work(struct work_struct *work);
+void ieee80211_sta_scan_work(struct work_struct *work);
void ieee80211_sta_rx_mgmt(struct net_device *dev, struct sk_buff *skb,
struct ieee80211_rx_status *rx_status);
int ieee80211_sta_set_ssid(struct net_device *dev, char *ssid, size_t len);
diff --git a/net/d80211/ieee80211_iface.c b/net/d80211/ieee80211_iface.c
index 3e9d531..288dce5 100644
--- a/net/d80211/ieee80211_iface.c
+++ b/net/d80211/ieee80211_iface.c
@@ -185,7 +185,7 @@ void ieee80211_if_set_type(struct net_de
struct ieee80211_if_sta *ifsta;
ifsta = sdata-u.sta;
- INIT_WORK(ifsta-work, ieee80211_sta_work, dev);
+ INIT_DELAYED_WORK(ifsta-work, ieee80211_sta_work);
ifsta-capab = WLAN_CAPABILITY_ESS;
ifsta-auth_algs = IEEE80211_AUTH_ALG_OPEN |
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 04bd5cd..35eb5a2 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -1837,10 +1837,11 @@ static void ieee80211_sta_merge_ibss(str
}
-void ieee80211_sta_work(void *ptr)
+void ieee80211_sta_work(struct work_struct *work)
{
- struct net_device *dev = ptr;
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_sub_if_data *sdata =
+ container_of(work, struct ieee80211_sub_if_data,
u.sta.work.work);
+ struct net_device *dev = sdata-dev;
struct ieee80211_if_sta *ifsta;
if (!netif_running(dev))
@@ -2407,7 +2408,7 @@ static int ieee80211_active_scan(struct
void ieee80211_scan_completed(struct ieee80211_hw *hw)
{
struct ieee80211_local *local = hw_to_local(hw
Re: d80211-drivers pull request (week-48)
On Tuesday 12 December 2006 18:39, Ulrich Kunitz wrote: Just two observations: 1) The retry-failed-interrupt message contains the destination MAC address of the transmitted message. Hm, that might be useful to check in master or adhoc mode to make sure the tx queue isn't messed up. 2) We could get easily two acks for the same transmission. How would this occur? 3) We could get ACKs or retry-failed-interrupts for packets, for which no status has been requested by the upper layers. We report status for every frame which will get an ACK, which is every unicast frame. Coincidentally, d80211 uses the same logic to determine when it wants the status to be reported (IIRC). I suggest that the skbs as buffer for the URB transmissions. Yes, copying the entire frame to another buffer isn't very performance friendly. This was one of the things that bothered me when I ported zd1211rw. We could add a timeout value to each packet to make sure, that we don't ACK or NAK packets, which have been overdue. Some sort of watchdog to kick things when things stall could be useful, though I'm not sure how to go about it. -Michael Wu pgpHi8ZnfpgQg.pgp Description: PGP signature
Re: [PATCH] zd1211rw-d80211: Use LED class
On Monday 11 December 2006 17:55, Ulrich Kunitz wrote: I cannot accknowledge this patch. Michael, the LED does not only show the link status, but also indicate that packets are sent, which is done by the firmware. However the LED flags have to be reset every second, because if an odd number of packets have been transmitted, the LED stays dark. The d80211 TX trigger has the same behavior. It's probably worse on single LED devices since it may look like nothing is on. Even then, I think having it reset every second is overkill. Having an TX LED watchdog run when we haven't TXed anything for the last second or sounds better to me. This would force the LEDs to a reasonable state when we know nothing has been TXed recently. This could be for STA mode only.. I dunno if the LED blinks when sending hardware generated/filled beacons. I even don't think, that the upper d80211 layers should care for LED controlling. The LEDs are part of the device and should be controlled by the device driver. I have a ZD1211 device, which has two LEDs. Now suddenly the upper layer must know about the two LEDs. But there could be WLAN devices who would have 6 LEDs for whatever reason. Should the upper layer know about all those LEDs and their semantics? The better design would be, that the driver could register for upper layer events and control it's LEDs accordingly. The upper layer does not know about the LEDs of individual devices. It merely provides a number of LED triggers which device drivers can choose to listen to - which sounds like what you're suggesting. If you would also have taken the time to look at my out-of-tree driver, you would have seen the other housekeeping/workqueue functions for handling strong signals. These changes are still missing from the kernel, because I have still to resolve issues with AL2230 RFs. This again can only be implemented in workqueues, because the register accesses require process context. Switching to using LED class makes the housekeeping workqueue code not do anything useful, so I removed it. I am not against the housekeeping workqueue code - but right now this is dead code that will unnecessarily cause zd1211rw-d80211 not to compile when wireless-dev gets the workqueue api changes. (of course, d80211 doesn't compile either with the workqueue changes, but I'm working out a patch for that..) If you are testing your new RF code with zd1211rw-d80211 also, I can add the workqueue housekeeping code back as soon as things are sorted out in wireless-dev. I will also probably port the rts/cts code after wireless-dev deals with the workqueue changes. Sound tolerable to you? -Michael Wu pgpQx8gvjRmUA.pgp Description: PGP signature
Re: d80211-drivers pull request (week-48)
On Monday 11 December 2006 20:07, Daniel Drake wrote: Michael Wu wrote: zd1211rw-d80211: Use ieee80211_tx_status I've thought some more about this and I'm not so sure that this is the right approach. Can't devicescape be taught that the ZD1211 handles retries in hardware and the stack doesn't need to worry about it? All 802.11 devices have to be able to handle retries in hardware to do random backoff properly. Still, the stack wants to know what happened. I think I remember reading that devicescape uses failed transmission rate in the rate adjustment calculations. Even without this racy ack system we can still achieve that - the device tells us every time it retries a transmit, and then it sends a special interrupt at the end saying that all retries failed. Yes, but it also uses successful transmissions in rate adjustment. I don't think this race is such a big deal. It will only happen when someone is really trying to mess with the link, and would cause the rate control to jump to the highest speed. However, if someone is really trying to mess with the link this way, the stability of the link is in trouble anyways. Wait for stations to send frames, and send an ack for every unicast frame - everyone will get confused. To actually mess with this code, the attacker would have to transmit acks nearly continuously as it can't tell exactly when is a good time to screw things up, and the driver recovers as soon as the queue is emptied. Someone transmitting all the time is a problem for all wireless cards. :) -Michael Wu pgpqy0LQcl1DB.pgp Description: PGP signature
Re: d80211-drivers pull request (week-48)
On Monday 11 December 2006 22:51, Daniel Drake wrote: It's ugly, in my mind not necessary, and it will kill performance. We haven't had to make such compromises in a long time. We got a large TX speed boost when the driver was modified to queue up multiple transmit URBs (i.e. don't wait for URB completion of the first) at the same time early during driver development. And even with that we're still a fair distance from the performance of the vendor driver. Yes, synchronous anything tends to kill performance. I do not see what about this patch kills performance, however. It merely frees skbs at a later point. The additional code in the RX path should be negligible. Also, every other d80211 driver has some sort of similar mechanism, the only difference being that the one for zd1211rw-d80211 isn't as reliable. I do not think it is that ugly. While the stack isn't so well suited for this device I'd much prefer to see a more simplistic workaround. For example, assume all packets were successful but then report a failure when an interrupt comes in. Or, if the stack won't accept out-of-the-blue notifications like that, then maintain a counter which is incremented when a failure is reported, and when transmitting the next few frames report them as failed and decrement the counter (while counter 0). I don't think these solutions are much prettier than a tx_queue. Maybe disable rate control until we can come up with a nicer solution. I don't think that's gonna happen unless changes are made in the firmware, or there's some bit somewhere to flip that does exactly what we need. And surely, having some working rate control is better than requiring manual tx rate tuning, right? (which isn't an option in d80211 anyway) -Michael Wu pgpAau91AjvBt.pgp Description: PGP signature
[PATCH 3/4] d80211: merge d80211_mgmt.h into linux/ieee80211.h
d80211: merge d80211_mgmt.h into linux/ieee80211.h
This merges d80211_mgmt.h with linux/ieee80211.h, to keep all the general
802.11 definitions in one place.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/bcm43xx/bcm43xx.h |1
include/linux/ieee80211.h | 208 +++
include/net/d80211_mgmt.h | 223 -
net/d80211/ieee80211.c|1
net/d80211/ieee80211_iface.c |1
net/d80211/ieee80211_ioctl.c |1
net/d80211/ieee80211_sta.c|1
7 files changed, 208 insertions(+), 228 deletions(-)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
index 2a18875..a607857 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
@@ -14,7 +14,6 @@
#include linux/ssb.h
#include linux/wireless.h
#include net/d80211.h
-#include net/d80211_mgmt.h
#include net/d80211_common.h
#include bcm43xx_debugfs.h
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index c7503eb..817001c 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -104,4 +104,212 @@ struct ieee80211_hdr {
__u8 addr4[6];
} __attribute__ ((packed));
+
+struct ieee80211_mgmt {
+ __le16 frame_control;
+ __le16 duration;
+ __u8 da[6];
+ __u8 sa[6];
+ __u8 bssid[6];
+ __le16 seq_ctrl;
+ union {
+ struct {
+ __le16 auth_alg;
+ __le16 auth_transaction;
+ __le16 status_code;
+ /* possibly followed by Challenge text */
+ __u8 variable[0];
+ } __attribute__ ((packed)) auth;
+ struct {
+ __le16 reason_code;
+ } __attribute__ ((packed)) deauth;
+ struct {
+ __le16 capab_info;
+ __le16 listen_interval;
+ /* followed by SSID and Supported rates */
+ u8 variable[0];
+ } __attribute__ ((packed)) assoc_req;
+ struct {
+ __le16 capab_info;
+ __le16 status_code;
+ __le16 aid;
+ /* followed by Supported rates */
+ __u8 variable[0];
+ } __attribute__ ((packed)) assoc_resp, reassoc_resp;
+ struct {
+ __le16 capab_info;
+ __le16 listen_interval;
+ __u8 current_ap[6];
+ /* followed by SSID and Supported rates */
+ __u8 variable[0];
+ } __attribute__ ((packed)) reassoc_req;
+ struct {
+ __le16 reason_code;
+ } __attribute__ ((packed)) disassoc;
+ struct {
+ __le64 timestamp;
+ __le16 beacon_int;
+ __le16 capab_info;
+ /* followed by some of SSID, Supported rates,
+* FH Params, DS Params, CF Params, IBSS Params, TIM */
+ __u8 variable[0];
+ } __attribute__ ((packed)) beacon;
+ struct {
+ /* only variable items: SSID, Supported rates */
+ __u8 variable[0];
+ } __attribute__ ((packed)) probe_req;
+ struct {
+ __le64 timestamp;
+ __le16 beacon_int;
+ __le16 capab_info;
+ /* followed by some of SSID, Supported rates,
+* FH Params, DS Params, CF Params, IBSS Params */
+ __u8 variable[0];
+ } __attribute__ ((packed)) probe_resp;
+ struct {
+ __u8 category;
+ union {
+ struct {
+ __u8 action_code;
+ __u8 dialog_token;
+ __u8 status_code;
+ __u8 variable[0];
+ } __attribute__ ((packed)) wme_action;
+ struct{
+ __u8 action_code;
+ __u8 element_id;
+ __u8 length;
+ __u8 switch_mode;
+ __u8 new_chan;
+ __u8 switch_count;
+ } __attribute__((packed)) chan_switch;
+ } u;
+ } __attribute__ ((packed)) action
[PATCH 1/4] d80211: move 802.11 defines to linux/ieee80211.h
d80211: move 802.11 defines to linux/ieee80211.h
This moves 802.11 defines from net/d80211.h into linux/ieee80211.h.
It also renames IEEE80211_DATA_LEN to IEEE80211_MAX_DATA_LEN to better
match the other definitions.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
include/linux/Kbuild |1
include/linux/ieee80211.h | 107 +
include/net/d80211.h | 90 --
net/d80211/ieee80211.c|4 +-
4 files changed, 111 insertions(+), 91 deletions(-)
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index c051f75..e6dccc8 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -72,6 +72,7 @@ header-y += hysdn_if.h
header-y += i2c-dev.h
header-y += i8k.h
header-y += icmp.h
+header-y += ieee80211.h
header-y += if_addr.h
header-y += if_arcnet.h
header-y += if_arp.h
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
new file mode 100644
index 000..c7503eb
--- /dev/null
+++ b/include/linux/ieee80211.h
@@ -0,0 +1,107 @@
+/*
+ * IEEE 802.11 defines
+ *
+ * Copyright (c) 2001-2002, SSH Communications Security Corp and Jouni Malinen
+ * [EMAIL PROTECTED]
+ * Copyright (c) 2002-2003, Jouni Malinen [EMAIL PROTECTED]
+ * Copyright (c) 2005, Devicescape Software, Inc.
+ * Copyright (c) 2006, Michael Wu [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef IEEE80211_H
+#define IEEE80211_H
+
+#include linux/types.h
+
+#define FCS_LEN 4
+
+#define IEEE80211_FCTL_VERS0x0003
+#define IEEE80211_FCTL_FTYPE 0x000c
+#define IEEE80211_FCTL_STYPE 0x00f0
+#define IEEE80211_FCTL_TODS0x0100
+#define IEEE80211_FCTL_FROMDS 0x0200
+#define IEEE80211_FCTL_MOREFRAGS 0x0400
+#define IEEE80211_FCTL_RETRY 0x0800
+#define IEEE80211_FCTL_PM 0x1000
+#define IEEE80211_FCTL_MOREDATA0x2000
+#define IEEE80211_FCTL_PROTECTED 0x4000
+#define IEEE80211_FCTL_ORDER 0x8000
+
+#define IEEE80211_SCTL_FRAG0x000F
+#define IEEE80211_SCTL_SEQ 0xFFF0
+
+#define IEEE80211_FTYPE_MGMT 0x
+#define IEEE80211_FTYPE_CTL0x0004
+#define IEEE80211_FTYPE_DATA 0x0008
+
+/* management */
+#define IEEE80211_STYPE_ASSOC_REQ 0x
+#define IEEE80211_STYPE_ASSOC_RESP 0x0010
+#define IEEE80211_STYPE_REASSOC_REQ0x0020
+#define IEEE80211_STYPE_REASSOC_RESP 0x0030
+#define IEEE80211_STYPE_PROBE_REQ 0x0040
+#define IEEE80211_STYPE_PROBE_RESP 0x0050
+#define IEEE80211_STYPE_BEACON 0x0080
+#define IEEE80211_STYPE_ATIM 0x0090
+#define IEEE80211_STYPE_DISASSOC 0x00A0
+#define IEEE80211_STYPE_AUTH 0x00B0
+#define IEEE80211_STYPE_DEAUTH 0x00C0
+#define IEEE80211_STYPE_ACTION 0x00D0
+
+/* control */
+#define IEEE80211_STYPE_PSPOLL 0x00A0
+#define IEEE80211_STYPE_RTS0x00B0
+#define IEEE80211_STYPE_CTS0x00C0
+#define IEEE80211_STYPE_ACK0x00D0
+#define IEEE80211_STYPE_CFEND 0x00E0
+#define IEEE80211_STYPE_CFENDACK 0x00F0
+
+/* data */
+#define IEEE80211_STYPE_DATA 0x
+#define IEEE80211_STYPE_DATA_CFACK 0x0010
+#define IEEE80211_STYPE_DATA_CFPOLL0x0020
+#define IEEE80211_STYPE_DATA_CFACKPOLL 0x0030
+#define IEEE80211_STYPE_NULLFUNC 0x0040
+#define IEEE80211_STYPE_CFACK 0x0050
+#define IEEE80211_STYPE_CFPOLL 0x0060
+#define IEEE80211_STYPE_CFACKPOLL 0x0070
+#define IEEE80211_STYPE_QOS_DATA 0x0080
+#define IEEE80211_STYPE_QOS_DATA_CFACK 0x0090
+#define IEEE80211_STYPE_QOS_DATA_CFPOLL0x00A0
+#define IEEE80211_STYPE_QOS_DATA_CFACKPOLL 0x00B0
+#define IEEE80211_STYPE_QOS_NULLFUNC 0x00C0
+#define IEEE80211_STYPE_QOS_CFACK 0x00D0
+#define IEEE80211_STYPE_QOS_CFPOLL 0x00E0
+#define IEEE80211_STYPE_QOS_CFACKPOLL 0x00F0
+
+
+/* miscellaneous IEEE 802.11 constants */
+#define IEEE80211_MAX_FRAG_THRESHOLD 2346
+#define IEEE80211_MAX_RTS_THRESHOLD2347
+#define IEEE80211_MAX_AID 2007
+#define IEEE80211_MAX_TIM_LEN 251
+#define IEEE80211_MAX_DATA_LEN 2304
+/* Maximum size for the MA-UNITDATA primitive, 802.11 standard section
+ 6.2.1.1.2.
+
+ The figure in section 7.1.2 suggests a body size of up to 2312
+ bytes is allowed, which is a bit confusing, I suspect this
+ represents the 2304 bytes of real data, plus a possible 8 bytes of
+ WEP IV and ICV. (this interpretation suggested by Ramiro Barreiro) */
+
+
+struct ieee80211_hdr {
+ __le16 frame_control;
+ __le16 duration_id;
+ __u8 addr1[6];
+ __u8 addr2[6];
+ __u8 addr3[6
[PATCH 4/4] d80211: move d80211_common.h to net/d80211
d80211: move d80211_common.h to net/d80211
This moves d80211_common.h to net/d80211/ieee80211_common.h since
d80211 drivers should not include this file.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/bcm43xx/bcm43xx.h |1
include/net/d80211_common.h | 98 -
net/d80211/ieee80211.c|2 -
net/d80211/ieee80211_common.h | 98 +
net/d80211/wpa.c |2 -
5 files changed, 100 insertions(+), 101 deletions(-)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
index a607857..55258e7 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
@@ -14,7 +14,6 @@
#include linux/ssb.h
#include linux/wireless.h
#include net/d80211.h
-#include net/d80211_common.h
#include bcm43xx_debugfs.h
#include bcm43xx_leds.h
diff --git a/include/net/d80211_common.h b/include/net/d80211_common.h
deleted file mode 100644
index 31167f0..000
--- a/include/net/d80211_common.h
+++ /dev/null
@@ -1,98 +0,0 @@
-/*
- * IEEE 802.11 driver (80211.o) -- hostapd interface
- * Copyright 2002-2004, Instant802 Networks, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef D80211_COMMON_H
-#define D80211_COMMON_H
-
-#include linux/types.h
-
-/*
- * This is common header information with user space. It is used on all
- * frames sent to wlan#ap interface.
- */
-
-#define IEEE80211_FI_VERSION 0x80211001
-
-struct ieee80211_frame_info {
- __be32 version;
- __be32 length;
- __be64 mactime;
- __be64 hosttime;
- __be32 phytype;
- __be32 channel;
- __be32 datarate;
- __be32 antenna;
- __be32 priority;
- __be32 ssi_type;
- __be32 ssi_signal;
- __be32 ssi_noise;
- __be32 preamble;
- __be32 encoding;
-
- /* Note: this structure is otherwise identical to capture format used
-* in linux-wlan-ng, but this additional field is used to provide meta
-* data about the frame to hostapd. This was the easiest method for
-* providing this information, but this might change in the future. */
- __be32 msg_type;
-} __attribute__ ((packed));
-
-
-enum ieee80211_msg_type {
- ieee80211_msg_normal = 0,
- ieee80211_msg_tx_callback_ack = 1,
- ieee80211_msg_tx_callback_fail = 2,
- ieee80211_msg_passive_scan = 3,
- ieee80211_msg_wep_frame_unknown_key = 4,
- ieee80211_msg_michael_mic_failure = 5,
- /* hole at 6, was monitor but never sent to userspace */
- ieee80211_msg_sta_not_assoc = 7,
- ieee80211_msg_set_aid_for_sta = 8 /* used by Intersil MVC driver */,
- ieee80211_msg_key_threshold_notification = 9,
- ieee80211_msg_radar = 11,
-};
-
-struct ieee80211_msg_set_aid_for_sta {
- charsta_address[ETH_ALEN];
- u16 aid;
-};
-
-struct ieee80211_msg_key_notification {
- int tx_rx_count;
- char ifname[IFNAMSIZ];
- u8 addr[ETH_ALEN]; /* ff:ff:ff:ff:ff:ff for broadcast keys */
-};
-
-
-enum ieee80211_phytype {
-ieee80211_phytype_fhss_dot11_97 = 1,
-ieee80211_phytype_dsss_dot11_97 = 2,
-ieee80211_phytype_irbaseband = 3,
-ieee80211_phytype_dsss_dot11_b = 4,
-ieee80211_phytype_pbcc_dot11_b = 5,
-ieee80211_phytype_ofdm_dot11_g = 6,
-ieee80211_phytype_pbcc_dot11_g = 7,
-ieee80211_phytype_ofdm_dot11_a = 8,
-ieee80211_phytype_dsss_dot11_turbog = 255,
-ieee80211_phytype_dsss_dot11_turbo = 256,
-};
-
-enum ieee80211_ssi_type {
-ieee80211_ssi_none = 0,
-ieee80211_ssi_norm = 1, /* normalized, 0-1000 */
-ieee80211_ssi_dbm = 2,
-ieee80211_ssi_raw = 3, /* raw SSI */
-};
-
-struct ieee80211_radar_info {
- int channel;
- int radar;
- int radar_type;
-};
-
-#endif /* D80211_COMMON_H */
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index d07d927..7c638b9 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -22,7 +22,7 @@
#include linux/compiler.h
#include linux/bitmap.h
-#include net/d80211_common.h
+#include ieee80211_common.h
#include ieee80211_i.h
#include ieee80211_rate.h
#include wep.h
diff --git a/net/d80211/ieee80211_common.h b/net/d80211/ieee80211_common.h
new file mode 100644
index 000..06c970d
--- /dev/null
+++ b/net/d80211/ieee80211_common.h
@@ -0,0 +1,98 @@
+/*
+ * IEEE 802.11 driver (80211.o) -- hostapd interface
+ * Copyright 2002-2004, Instant802 Networks, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
[PATCH 2/4] d80211: merge d80211_shared.h into d80211.h
merge d80211_shared.h into d80211.h
This merges d80211_shared.h into d80211.h.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
include/net/d80211.h| 32 +-
include/net/d80211_shared.h | 46 ---
2 files changed, 31 insertions(+), 47 deletions(-)
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 688c625..c7e5bb3 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -16,7 +16,6 @@
#include linux/wireless.h
#include linux/device.h
#include linux/ieee80211.h
-#include d80211_shared.h
/* Note! Only ieee80211_tx_status_irqsafe() and ieee80211_rx_irqsafe() can be
* called in hardware interrupt context. The low-level driver must not call any
@@ -47,6 +46,10 @@
#define IEEE80211_VERSION 2
+#define IEEE80211_CHAN_W_SCAN 0x0001
+#define IEEE80211_CHAN_W_ACTIVE_SCAN 0x0002
+#define IEEE80211_CHAN_W_IBSS 0x0004
+
/* Channel information structure. Low-level driver is expected to fill in chan,
* freq, and val fields. Other fields will be filled in by 80211.o based on
* hostapd information and low-level driver does not need to use them. The
@@ -61,6 +64,22 @@ struct ieee80211_channel {
unsigned char antenna_max;
};
+#define IEEE80211_RATE_ERP 0x0001
+#define IEEE80211_RATE_BASIC 0x0002
+#define IEEE80211_RATE_PREAMBLE2 0x0004
+#define IEEE80211_RATE_SUPPORTED 0x0010
+#define IEEE80211_RATE_OFDM 0x0020
+#define IEEE80211_RATE_CCK 0x0040
+#define IEEE80211_RATE_TURBO 0x0080
+#define IEEE80211_RATE_MANDATORY 0x0100
+
+#define IEEE80211_RATE_CCK_2 (IEEE80211_RATE_CCK | IEEE80211_RATE_PREAMBLE2)
+#define IEEE80211_RATE_MODULATION(f) \
+(f (IEEE80211_RATE_CCK | IEEE80211_RATE_OFDM))
+
+/* Low-level driver should set PREAMBLE2, OFDM, CCK, and TURBO flags.
+ * BASIC, SUPPORTED, ERP, and MANDATORY flags are set in 80211.o based on the
+ * configuration. */
struct ieee80211_rate {
int rate; /* rate in 100 kbps */
int val; /* hw specific value for the rate */
@@ -77,6 +96,17 @@ struct ieee80211_rate {
* optimizing channel utilization estimates */
};
+/* 802.11g is backwards-compatible with 802.11b, so a wlan card can
+ * actually be both in 11b and 11g modes at the same time. */
+enum {
+ MODE_IEEE80211A = 0 /* IEEE 802.11a */,
+ MODE_IEEE80211B = 1 /* IEEE 802.11b only */,
+ MODE_ATHEROS_TURBO = 2 /* Atheros Turbo mode (2x.11a at 5 GHz) */,
+ MODE_IEEE80211G = 3 /* IEEE 802.11g (and 802.11b compatibility) */,
+ MODE_ATHEROS_TURBOG = 4 /* Atheros Turbo mode (2x.11g at 2.4 GHz) */,
+ NUM_IEEE80211_MODES = 5
+};
+
struct ieee80211_hw_modes {
int mode;
int num_channels;
diff --git a/include/net/d80211_shared.h b/include/net/d80211_shared.h
deleted file mode 100644
index 2f1bb42..000
--- a/include/net/d80211_shared.h
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * IEEE 802.11 -- shared defines for low-level drivers, 80211.o, and hostapd
- * Copyright 2002-2004, Instant802 Networks, Inc.
- * Copyright 2005, Devicescape Software, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef D80211_SHARED_H
-#define D80211_SHARED_H
-
-/* 802.11g is backwards-compatible with 802.11b, so a wlan card can
- * actually be both in 11b and 11g modes at the same time. */
-enum {
- MODE_IEEE80211A = 0 /* IEEE 802.11a */,
- MODE_IEEE80211B = 1 /* IEEE 802.11b only */,
- MODE_ATHEROS_TURBO = 2 /* Atheros Turbo mode (2x.11a at 5 GHz) */,
- MODE_IEEE80211G = 3 /* IEEE 802.11g (and 802.11b compatibility) */,
- MODE_ATHEROS_TURBOG = 4 /* Atheros Turbo mode (2x.11g at 2.4 GHz) */,
- NUM_IEEE80211_MODES = 5
-};
-
-#define IEEE80211_CHAN_W_SCAN 0x0001
-#define IEEE80211_CHAN_W_ACTIVE_SCAN 0x0002
-#define IEEE80211_CHAN_W_IBSS 0x0004
-
-/* Low-level driver should set PREAMBLE2, OFDM, CCK, and TURBO flags.
- * BASIC, SUPPORTED, ERP, and MANDATORY flags are set in 80211.o based on the
- * configuration. */
-#define IEEE80211_RATE_ERP 0x0001
-#define IEEE80211_RATE_BASIC 0x0002
-#define IEEE80211_RATE_PREAMBLE2 0x0004
-#define IEEE80211_RATE_SUPPORTED 0x0010
-#define IEEE80211_RATE_OFDM 0x0020
-#define IEEE80211_RATE_CCK 0x0040
-#define IEEE80211_RATE_TURBO 0x0080
-#define IEEE80211_RATE_MANDATORY 0x0100
-
-#define IEEE80211_RATE_CCK_2 (IEEE80211_RATE_CCK | IEEE80211_RATE_PREAMBLE2)
-#define IEEE80211_RATE_MODULATION(f) \
-(f (IEEE80211_RATE_CCK | IEEE80211_RATE_OFDM))
-
-
-#endif /* D80211_SHARED_H */
pgpxnKpkYqlk6.pgp
Description: PGP signature
Re: [PATCH 04/26] rt2x00: EEPROM 93Cx6
On Friday 08 December 2006 13:56, Ivo van Doorn wrote: I have checked the adm80211 code as well, it seems to behave quite the same, with the most notable difference the fact that adm80211 writes the READ_OPCODE and the word index within a single command, while in eeprom_93cx6 this is split into 2 seperate write commands. I have not yet tested the exact impact for rt2x00 devices when they would combine the write commands, but if that has no impact (or the adm80211 suffers no impact when the write commands are being split) then rt2x00 and adm80211 could indeed share the eeprom_93cx6 module. Hm, which way is the correct way? (is there a correct way?) If eeprom_93cx6 is moved to the /lib folder of the kernel, should it be approved by a different maintainer first? I don't think so, but I'm not sure. BTW, I think there can actually be another user of this code. Take a look at drivers/scsi/aic7xxx/aic7xxx_93cx6.c I'm not sure who the maintainer for this is. Should be okay to just have adm8211 and rt2x00 using eeprom_93cx6 for now, unless you have a spare aic7xxx supported device lying around. ;) Thanks, -Michael Wu pgp1CpsZWtBaz.pgp Description: PGP signature
[PATCH] d80211: remove pkt_type/pkt_probe_resp
d80211: remove pkt_type/pkt_probe_resp
Nobody uses pkt_type, and the information can be obtained from the
header. This removes it and the associated code that keeps tracks of it.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
include/net/d80211.h |1 -
net/d80211/ieee80211.c |7 ---
net/d80211/ieee80211_i.h |3 +--
net/d80211/ieee80211_sta.c | 17 +++--
4 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/include/net/d80211.h b/include/net/d80211.h
index 30980e1..f7f6318 100644
--- a/include/net/d80211.h
+++ b/include/net/d80211.h
@@ -135,7 +135,6 @@ struct ieee80211_low_level_stats {
#define HW_KEY_IDX_INVALID -1
struct ieee80211_tx_control {
- enum { PKT_NORMAL = 0, PKT_PROBE_RESP } pkt_type;
int tx_rate; /* Transmit rate, given as the hw specific value for the
* rate (from struct ieee80211_rate) */
int rts_cts_rate; /* Transmit rate for RTS/CTS frame, given as the hw
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index 6e10db5..5ea51a5 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -1395,8 +1395,6 @@ static int ieee80211_master_start_xmit(s
control.flags |= IEEE80211_TXCTL_REQ_TX_STATUS;
if (pkt_data-do_not_encrypt)
control.flags |= IEEE80211_TXCTL_DO_NOT_ENCRYPT;
- control.pkt_type =
- pkt_data-pkt_probe_resp ? PKT_PROBE_RESP : PKT_NORMAL;
if (pkt_data-requeue)
control.flags |= IEEE80211_TXCTL_REQUEUE;
control.queue = pkt_data-queue;
@@ -1628,10 +1626,6 @@ ieee80211_mgmt_start_xmit(struct sk_buff
pkt_data-ifindex = sdata-dev-ifindex;
pkt_data-mgmt_iface = (sdata-type == IEEE80211_IF_TYPE_MGMT);
- if ((fc IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_MGMT
- (fc IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_PROBE_RESP)
- pkt_data-pkt_probe_resp = 1;
-
skb-priority = 20; /* use hardcoded priority for mgmt TX queue */
skb-dev = sdata-local-mdev;
@@ -4050,7 +4044,6 @@ static void ieee80211_remove_tx_extra(st
pkt_data-mgmt_iface = (control-type == IEEE80211_IF_TYPE_MGMT);
pkt_data-req_tx_status = !!(control-flags
IEEE80211_TXCTL_REQ_TX_STATUS);
pkt_data-do_not_encrypt = !!(control-flags
IEEE80211_TXCTL_DO_NOT_ENCRYPT);
- pkt_data-pkt_probe_resp = (control-pkt_type == PKT_PROBE_RESP);
pkt_data-requeue = !!(control-flags IEEE80211_TXCTL_REQUEUE);
pkt_data-queue = control-queue;
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ef303da..02fbdea 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -155,10 +155,9 @@ struct ieee80211_tx_packet_data {
unsigned long jiffies;
unsigned int req_tx_status:1;
unsigned int do_not_encrypt:1;
- unsigned int pkt_probe_resp:1;
unsigned int requeue:1;
- unsigned int queue:4;
unsigned int mgmt_iface:1;
+ unsigned int queue:4;
};
struct ieee80211_tx_stored_packet {
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 04bd5cd..7594022 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -384,7 +384,7 @@ static void ieee80211_set_associated(str
static void ieee80211_sta_tx(struct net_device *dev, struct sk_buff *skb,
-int encrypt, int probe_resp)
+int encrypt)
{
struct ieee80211_sub_if_data *sdata;
struct ieee80211_tx_packet_data *pkt_data;
@@ -398,8 +398,6 @@ static void ieee80211_sta_tx(struct net_
pkt_data-ifindex = sdata-dev-ifindex;
pkt_data-mgmt_iface = (sdata-type == IEEE80211_IF_TYPE_MGMT);
pkt_data-do_not_encrypt = !encrypt;
- if (probe_resp)
- pkt_data-pkt_probe_resp = 1;
dev_queue_xmit(skb);
}
@@ -436,7 +434,7 @@ static void ieee80211_send_auth(struct n
if (extra)
memcpy(skb_put(skb, extra_len), extra, extra_len);
- ieee80211_sta_tx(dev, skb, encrypt, 0);
+ ieee80211_sta_tx(dev, skb, encrypt);
}
@@ -573,7 +571,7 @@ static void ieee80211_send_assoc(struct
if (ifsta-assocreq_ies)
memcpy(ifsta-assocreq_ies, ies, ifsta-assocreq_ies_len);
- ieee80211_sta_tx(dev, skb, 0, 0);
+ ieee80211_sta_tx(dev, skb, 0);
}
@@ -600,7 +598,7 @@ static void ieee80211_send_deauth(struct
skb_put(skb, 2);
mgmt-u.deauth.reason_code = cpu_to_le16(reason);
- ieee80211_sta_tx(dev, skb, 0, 0);
+ ieee80211_sta_tx(dev, skb, 0);
}
@@ -627,7 +625,7 @@ static void ieee80211_send_disassoc(stru
skb_put(skb, 2);
mgmt-u.disassoc.reason_code = cpu_to_le16(reason);
- ieee80211_sta_tx(dev, skb, 0, 0);
+ ieee80211_sta_tx(dev, skb, 0);
}
@@ -803,7 +801,7 @@ static void ieee80211_send_probe_req(str
*pos = rate-rate / 5
[PATCH] zd1211rw-d80211: check IEEE80211_TXCTL_USE_CTS_PROTECT
zd1211rw-d80211: check IEEE80211_TXCTL_USE_CTS_PROTECT
This makes zd1211 check for IEEE80211_TXCTL_USE_CTS_PROTECT and set things
appropriately in the hardware TX header.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/zd1211rw/zd_mac.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
index dde972d..a76fa6a 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
@@ -248,15 +248,11 @@ static void cs_set_control(struct zd_mac
if ((fctl IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_PSPOLL)
cs-control |= ZD_CS_PS_POLL_FRAME;
- if (flags IEEE80211_TXCTL_USE_RTS_CTS) {
- /* FIXME: check the logic */
- if (ZD_CS_TYPE(cs-modulation) == ZD_CS_OFDM) {
- /* 802.11g */
- cs-control |= ZD_CS_SELF_CTS;
- } else { /* 802.11b */
- cs-control |= ZD_CS_RTS;
- }
- }
+ if (flags IEEE80211_TXCTL_USE_RTS_CTS)
+ cs-control |= ZD_CS_RTS;
+
+ if (flags IEEE80211_TXCTL_USE_CTS_PROTECT)
+ cs-control |= ZD_CS_SELF_CTS;
/* FIXME: Management frame? */
}
pgpBccSMwivY3.pgp
Description: PGP signature
[PATCH] zd1211rw-d80211: Use ieee80211_tx_status
zd1211rw-d80211: Use ieee80211_tx_status
This makes zd1211rw-d80211 properly report the TX result of a frame via
ieee80211_tx_status. I'm not sure if we can do much better than this since
the hardware doesn't explicitly report the success/failure of TXed frames
that require ACKs. We have to guess which ACKs match up with which
frames we're trying to send.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/zd1211rw/zd_chip.h |3 +
drivers/net/wireless/d80211/zd1211rw/zd_mac.c | 96
drivers/net/wireless/d80211/zd1211rw/zd_mac.h |2 +
drivers/net/wireless/d80211/zd1211rw/zd_usb.c |8 --
4 files changed, 99 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_chip.h
b/drivers/net/wireless/d80211/zd1211rw/zd_chip.h
index 4eaec47..b9c225d 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_chip.h
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_chip.h
@@ -467,8 +467,9 @@
#define RX_FILTER_BEACON (1 8)
#define RX_FILTER_DISASSOC (1 10)
#define RX_FILTER_AUTH (1 11)
+#define RX_FILTER_ACK (1 29)
#define AP_RX_FILTER 0x0400feff
-#define STA_RX_FILTER 0x
+#define STA_RX_FILTER 0x2000
/* Monitor mode sets filter to 0xf */
diff --git a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
index a76fa6a..6ee650f 100644
--- a/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/d80211/zd1211rw/zd_mac.c
@@ -153,6 +153,7 @@ static int zd_mac_stop(struct ieee80211_
{
struct zd_mac *mac = zd_dev_mac(dev);
struct zd_chip *chip = mac-chip;
+ struct sk_buff *skb;
/*
* The order here deliberately is a little different from the open()
@@ -167,6 +168,13 @@ static int zd_mac_stop(struct ieee80211_
zd_chip_switch_radio_off(chip);
zd_chip_disable_int(chip);
+ while ((skb = skb_dequeue(mac-tx_queue))) {
+ struct ieee80211_tx_control *control =
+ *(struct ieee80211_tx_control **)skb-cb;
+ kfree(control);
+ kfree_skb(skb);
+ }
+
return 0;
}
@@ -312,6 +320,7 @@ static int zd_mac_tx(struct ieee80211_hw
struct ieee80211_tx_control *control)
{
struct zd_mac *mac = zd_dev_mac(dev);
+ struct ieee80211_tx_control *control_copy;
int r;
if (skb_headroom(skb) dev-extra_tx_headroom
@@ -325,11 +334,43 @@ static int zd_mac_tx(struct ieee80211_hw
if (r)
return r;
- /* FIXME: figure out how to check if the TXed packet was ACKed */
- kfree_skb(skb);
+ if (control-flags IEEE80211_TXCTL_NO_ACK) {
+ kfree_skb(skb);
+ return 0;
+ }
+
+ control_copy = kmalloc(sizeof(*control_copy), GFP_ATOMIC);
+ if (control_copy)
+ memcpy(control_copy, control, sizeof(*control_copy));
+
+ *(struct ieee80211_tx_control **)skb-cb = control_copy;
+ skb_pull(skb, sizeof(struct zd_ctrlset));
+ skb_queue_tail(mac-tx_queue, skb);
return 0;
}
+void zd_mac_tx_failed(struct ieee80211_hw *dev)
+{
+ struct zd_mac *mac = zd_dev_mac(dev);
+ struct ieee80211_tx_control *control;
+ struct sk_buff *skb;
+
+ skb = skb_dequeue(mac-tx_queue);
+ if (!skb)
+ return;
+
+ control = *(struct ieee80211_tx_control **)skb-cb;
+ if (control) {
+ struct ieee80211_tx_status status = {{0}};
+ memcpy(status.control, control, sizeof(status.control));
+ ieee80211_tx_status_irqsafe(dev, skb, status);
+ kfree(control);
+ } else
+ kfree_skb(skb);
+
+ return;
+}
+
struct zd_rt_hdr {
struct ieee80211_radiotap_header rt_hdr;
u8 rt_flags;
@@ -391,6 +432,52 @@ static int fill_rx_stats(struct ieee8021
return 0;
}
+static int filter_ack(struct ieee80211_hw *dev, struct ieee80211_hdr *rx_hdr,
+ struct ieee80211_rx_status *stats)
+{
+ struct zd_mac *mac = zd_dev_mac(dev);
+ u16 fc = le16_to_cpu(rx_hdr-frame_control);
+ struct sk_buff *skb;
+ struct ieee80211_hdr *tx_hdr;
+ struct ieee80211_tx_control *control;
+ struct ieee80211_tx_status status = {{0}};
+
+ if ((fc (IEEE80211_FCTL_FTYPE | IEEE80211_FCTL_STYPE)) !=
+ (IEEE80211_FTYPE_CTL | IEEE80211_STYPE_ACK))
+ return 0;
+
+ spin_lock(mac-tx_queue.lock);
+
+ skb = skb_peek(mac-tx_queue);
+ if (!skb) {
+ spin_unlock(mac-tx_queue.lock);
+ return 1;
+ }
+
+ tx_hdr = (struct ieee80211_hdr *) skb-data;
+
+ if (!memcmp(tx_hdr-addr2, rx_hdr-addr1, ETH_ALEN))
+ skb = __skb_dequeue(mac-tx_queue);
+ else
Re: d80211-drivers updated (zd1211rw-d80211 synced with zd1211rw)
On Monday 04 December 2006 07:51, John W. Linville wrote: On Mon, Dec 04, 2006 at 02:50:39AM -0500, Michael Wu wrote: Other (d80211) wireless drivers are welcome to send patches this way if they do not have their own git tree for Linville to pull. Please don't do this. It adds to my pain for reviewing patches. Sure. While I'm complaining :-), I would probably prefer it if you had adm8211 and p54 in separate git trees (or at least on separate branches) as well. That way, if there is a problem in a p54 patch series, I can still pull adm8211 (or vice versa). I will keep separate branches for each driver then. It is not my intent to scold (so please don't feel scolded). It just is counter-productive to prematurely consolidate merging duties. No problem. It seemed like a good idea for zd1211rw, so I was offering to do the same for other drivers. Thanks, -Michael Wu pgpjrSZqN7Xi7.pgp Description: PGP signature
Re: [PATCH 04/26] rt2x00: EEPROM 93Cx6
On Sunday 03 December 2006 13:19, Ivo van Doorn wrote: rt2400pci, rt2500pci and rt61pci share exactly the same code for the eeprom reading. The only difference is that rt61pci has a slightly different register reading approach. In any case we have a lot of duplicate code. Create a new module eeprom_93cx6 inside the rt2x00 folder and make rt2x00 use that. Interesting. adm8211 has code to read 93C66 and 93C46 eeproms, and it looks similar, albeit smaller and simpler, to your 93cx6 reading code. However, it looks like your new eeprom reading code is general enough for adm8211 to use too. I'll have to try it.. -Michael Wu pgpjt3tLYG0s7.pgp Description: PGP signature
d80211-drivers updated (zd1211rw-d80211 synced with zd1211rw)
Hi, I've just ported 8 patches that were in the wireless-2.6 version of zd1211rw that weren't in the wireless-dev version. All of them, except for the cleanups patch, applied with just an offset, and all of the broken hunks in the cleanups patch were just thrown away since the code they were modifying doesn't exist anymore. zd1211rw-d80211: Fix of a locking bug zd1211rw-d80211: Revert zd1211rw: Removed unneeded packed attributes zd1211rw-d80211: Add 3 more device IDs zd1211rw-d80211: Add ID for ZyXEL G-220 zd1211rw-d80211: Add ID for Planex GW-US54Mini zd1211rw-d80211: Add ID for Belkin F5D7050 v4000 zd1211rw-d80211: cleanups zd1211rw-d80211: Optimized handling of zero length entries in length info git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git These patches are in the week-48 branch. (I think it should actually be week-49, but I realized after I committed..) I'll post a pull request at the end of every week when there are patches and branch. Patches sent here can be expected to be merged in a day. Other (d80211) wireless drivers are welcome to send patches this way if they do not have their own git tree for Linville to pull. Currently, patches are going into the week-48 branch, but I will switch to putting patches in the master branch and branching off master before every pull request for next week. -Michael Wu pgpLsagXFtkaN.pgp Description: PGP signature
zd1211 ported to Devicescape stack
Hi, I have finished a port of the zd1211 driver to the Devicescape 802.11 stack. Due to the size of the patch, the patch that copies the zd1211 directory to the d80211 directory has been omitted, but can be found at my git repo. (git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git up) The two other patches relevant to porting the driver are bzip2ed and attached due to size concerns. This port works fairly well in STA mode, with adhoc and monitor modes to come in the future. I tried to minimize changes to the structure of the driver and code whenever possible to make it easier to port patches from the softmac based zd1211 driver to this driver. However: - The original driver does not seem to check if a frame has been successfully TXed (as in RXed an ACK), so the port does not properly report to the stack whether or not a TX succeeded. -Because d80211 does not have complete regulatory domains support yet, the associated code was trimmed to the bare minimum of reading the region code. It should be a trivial patch to add regulatory domains support once the infrastructure is in place in d80211. - d80211 doesn't tell us the size of the next fragment, so that part of the hardware TX header isn't set anymore. This might be fixed in the future. - The LED link status isn't too reliable - I haven't found a way to reliably tell if the upper layer thinks it is associated, and I don't know how to use the LED api. Not too worried about this issue though. I will push this to wireless-dev soon if there are no major problems. Thanks, -Michael Wu zd1211-kconfig.bz2 Description: BZip2 compressed data zd1211-port-to-d80211.bz2 Description: BZip2 compressed data pgpsQqp0cDSeo.pgp Description: PGP signature
Re: zd1211 ported to Devicescape stack
On Saturday 02 December 2006 08:25, Ulrich Kunitz wrote: - The original driver does not seem to check if a frame has been successfully TXed (as in RXed an ACK), so the port does not properly report to the stack whether or not a TX succeeded. TX is atomic. Do you really want to spin for the received ACK? Layer 2 doesn't need to make any guarantees for packet transmission, so I have trouble to see the point here. The Linux Device Driver book says explicitly that packet transmission must not have been completed at the point in time the function returns. And it doesn't. Sleeping at that point would be bad. However, the p54 driver looks for special frames from the card that report the success/failure of sent frames, and adm8211 can tell if a frame was TXed successfully on TX ring cleanup. The notification is then done by calling ieee80211_tx_status, not by returning an error code. No sleeping necessary. This is needed for the upper layer to resend frames and to also do rate control. I would suggest to maintain it until d80211 has complete regulatory domains support. Why? It's not like any other d80211 drivers have regulatory domains support, and they need the exactly the same features that zd1211 needs. Also, the limited support for regulatory domains that d80211 does have restricts it to channels 1-11 (FCC) regardless, so the code would not be effective. Thanks, -Michael Wu pgpMQ7cClQqGX.pgp Description: PGP signature
Re: zd1211 ported to Devicescape stack
On Saturday 02 December 2006 12:57, Ulrich Kunitz wrote: I intend to track the d80211 stack, care for the forward porting and see also a number of things, which should be done for d80211. - 802.11a support - better d80211 integration (d80211_tx_status, led stuff) - cleanups Great! I expected to handle the patch porting alone, but it's better to have someone used to this hardware doing this. This will make the d80211 driver the development branch and the mainline driver the maintenance branch. As already stated I intend care for forwardportsi of the mainline fixes, but IMHO we should not care to much for backports and backport compatibility. I avoided cleanups in the patch to make any patch porting from the mainline driver easier, but if it's okay with you, I might make a few zd1211-d80211 specific clean up patches. Thanks, -Michael Wu pgpTXgNY8kbdB.pgp Description: PGP signature
d80211-drivers pull request
Hi John, Please pull git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git up for these patches: Michael Wu (4): zd1211-d80211: Copy zd1211 driver to d80211 directory zd1211-d80211: Hook up Kconfig and Makefiles zd1211-d80211: Port zd1211 to Devicescape stack p54: Don't send startup packet again on next ifup (USB) Kconfig |1 Makefile |1 p54/prism54usb.c | 26 zd1211rw/Kconfig | 19 zd1211rw/Makefile| 11 zd1211rw/zd_chip.c | 1655 +++ zd1211rw/zd_chip.h | 845 +++ zd1211rw/zd_def.h| 54 + zd1211rw/zd_ieee80211.h | 68 + zd1211rw/zd_mac.c| 638 ++ zd1211rw/zd_mac.h| 247 +++ zd1211rw/zd_rf.c | 156 zd1211rw/zd_rf.h | 83 ++ zd1211rw/zd_rf_al2230.c | 373 ++ zd1211rw/zd_rf_al7230b.c | 274 +++ zd1211rw/zd_rf_rf2959.c | 279 +++ zd1211rw/zd_types.h | 71 ++ zd1211rw/zd_usb.c| 1423 zd1211rw/zd_usb.h| 243 ++ zd1211rw/zd_util.c | 82 ++ zd1211rw/zd_util.h | 29 21 files changed, 6574 insertions(+), 4 deletions(-) Thanks, -Michael Wu pgpVXt3OWfgzF.pgp Description: PGP signature
Re: d80211: RFC: divide by zero when hw-maxssi not set
On Friday 17 November 2006 18:51, David Kimdon wrote: - reject registration of devices which do not set maxssi - do not attempt to report link quality for drivers which do not set maxssi - other ideas? I've noticed that too. p54 didn't get a driver update when maxssi was added. I don't mind adding a dummy maxssi just to make sure we don't divide by zero. In fact, I'm going to come up with a patch for p54 to do that soon. -Michael Wu pgp67DV8dGnpA.pgp Description: PGP signature
Re: [PATCH 0/6] rework d80211 cookie pointer
On Thursday 02 November 2006 17:38, Johannes Berg wrote: I'm sorry I didn't manage to update these drivers. As for out-of-tree drivers, I obviously haven't updated them either. It *shouldn't* be too hard as the net_dev shouldn't be used in many places. So uh, what am I going to prefix all my printk messages with now that I can't access dev-name? It seems like the other d80211 drivers have a habit of prefixing their messages with the driver name (wrong thing to do, IMHO), which is different from pretty much all other network drivers. -Michael Wu pgpdUJlLkwozo.pgp Description: PGP signature
Re: [PATCH 3/6] d80211: add a perm_addr hardware property
On Thursday 02 November 2006 17:38, Johannes Berg wrote: After removing knowledge of the master net_dev from drivers, they'll still need a way to tell us which MAC address they have. This is that way, the perm_addr is initially used for all devices. Shouldn't you add something to ieee80211_set_mac_address so the driver/d80211 can find out what MAC address the user actually wants? Might be easier to just point perm_addr to dev_addr, but that would make it obvious that perm_addr is a bit messy. A wrapper for drivers that returns a pointer to dev_addr might be a better idea. Also, do we need to update interfaces associated with the master interface when the master MAC address changes? -Michael Wu pgpGDCT9RsJnl.pgp Description: PGP signature
Re: [PATCH 0/6] rework d80211 cookie pointer
On Friday 03 November 2006 14:08, Johannes Berg wrote: Yeah, I thought about that and added that function to get the wiphy index. cfg80211 makes the wiphy index an actual identifier that you can use to enumerate all devices it has attached etc, so that makes sense. and d80211 also puts it into sysfs. Is that good enough? I still prefer obtaining the name of the master interface because well.. all other network drivers prefix their messages with the name of their interface. The master interface name should be as good as the wiphy index to enumerate attached devices. -Michael Wu pgpSjDUVGYY8u.pgp Description: PGP signature
Re: [PATCH 4/6] d80211: add a struct device* hardware property
On Thursday 02 November 2006 17:38, Johannes Berg wrote: + /* hardware device */ + struct device *dev; + Can we just pass this in as an argument instead? No one is gonna look at it ever again after ieee80211_register_hw, so I don't think it's worth putting in struct ieee80211_hw. + local-mdev-class_dev.dev = hw-dev; Why not use SET_NETDEV_DEV? -Michael Wu pgpED2SctxFK0.pgp Description: PGP signature
Re: [PATCH 5/6] d80211: add a ethtool_ops hardware property
On Thursday 02 November 2006 17:39, Johannes Berg wrote: After removing knowledge of the master net_dev from drivers, some will still want to have ethtool ops assigned (rt2x00 uses it). This is that way. But bcm43xx sets ethtool ops through bcm43xx_netdev_setup. Why not have rt2x00 do the same? Then we won't have to go through all the trouble of adding things to ieee80211_hw and ieee80211_register_hw to set things in net_device. This would work out pretty well for SET_NETDEV_DEV too. -Michael Wu pgpIZyGVpJaIw.pgp Description: PGP signature
Re: [PATCH 0/6] rework d80211 cookie pointer
On Thursday 02 November 2006 17:38, Johannes Berg wrote: Now, I tried to update adm8211 and rt2x00 as well, but faced some problems. adm8211 actually accesses the struct net_device and calls it's open() call! This is broken. Good catch. Looks like I never updated the suspend/resume code properly when I ported to d80211. The fix is easy - the code just needs to call the adm8211_open/stop functions directly. I'll send a patch later tonight. -Michael Wu pgpQYkVQJIbQS.pgp Description: PGP signature
[PATCH wireless-dev] adm8211: fix suspend code
adm8211: fix suspend code
Apparently, I forgot to port the suspend and resume code in the
d80211 port of adm8211. Thanks to Johannes Berg for finding this.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c
b/drivers/net/wireless/d80211/adm8211/adm8211.c
index bc0c8b6..fcfd05a 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -2135,26 +2135,31 @@ #ifdef CONFIG_PM
static int adm8211_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev = pci_get_drvdata(pdev);
- netif_device_detach(dev);
+ struct adm8211_priv *priv = ieee80211_dev_hw_data(dev);
- if (dev-flags IFF_UP)
- dev-stop(dev);
+ if (priv-mode != IEEE80211_IF_TYPE_MGMT) {
+ ieee80211_stop_queues(dev);
+ adm8211_stop(dev);
+ }
pci_save_state(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
}
static int adm8211_resume(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata(pdev);
+ struct adm8211_priv *priv = ieee80211_dev_hw_data(dev);
+
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
- if (dev-flags IFF_UP)
- dev-open(dev);
+ if (priv-mode != IEEE80211_IF_TYPE_MGMT) {
+ adm8211_open(dev);
+ ieee80211_start_queues(dev);
+ }
- netif_device_attach(dev);
return 0;
}
#endif /* CONFIG_PM */
pgpocvfmarqtd.pgp
Description: PGP signature
Re: [PATCH 1/6] d80211: change the cookie to be opaque
On Thursday 02 November 2006 19:22, Johannes Berg wrote: Ok, that one was wrong. But what is it doing in the public API? We need to remove it from the public API and leave struct net_device *dev as the parameter. adm8211 actually uses it and increases the tx_fifo_error counter, but that's a bit strange. That's because TX might fail for reasons other than not getting an ACK. I can't say I've actually seen this happen, so it might just be something left over from tulip that doesn't need to be there now. (or perhaps it only happens when there's something really bad going on) However, what's so bad about letting drivers update some statistics if it is possible? If you remove ieee80211_dev_stats, please provide some other way for drivers to access struct net_device_stats. -Michael Wu pgpSXbD257dOW.pgp Description: PGP signature
Re: [PATCH 3/4] adm8211-d80211: Add wireless statistics (compile tested only)
On Thursday 02 November 2006 13:47, Larry Finger wrote: These patches modify adm8211-d80211 to use the wireless statics added in patch 1. Signed-Off-By: Larry [EMAIL PROTECTED] ACK. I can put better values in later. Thanks, -Michael Wu pgpduYKxxEeea.pgp Description: PGP signature
Re: New stuff in wireless-dev, wireless developers please pull...
On Thursday 02 November 2006 23:30, John W. Linville wrote: One big addition is the cfg80211/nl80211 stuff from Johannes. I'm not quite confident that the Kconfig stuff is right, but the code is there. It doesn't seem to compile on my system: net/built-in.o: In function `iw_send_thrspy_event': wext-old.c:(.text+0x67672): undefined reference to `wireless_send_event' net/built-in.o: In function `ioctl_standard_call': wext-old.c:(.text+0x677bf): undefined reference to `standard_ioctl_num' wext-old.c:(.text+0x677ea): undefined reference to `standard_ioctl' wext-old.c:(.text+0x677f1): undefined reference to `standard_ioctl' wext-old.c:(.text+0x679b9): undefined reference to `wireless_send_event' wext-old.c:(.text+0x679f0): undefined reference to `wireless_send_event' wext-old.c:(.text+0x67abf): undefined reference to `wireless_send_event' net/built-in.o: In function `iw_handler_get_iwstats': wext-old.c:(.text+0x67f67): undefined reference to `get_wireless_stats' net/built-in.o: In function `net_dev_init': dev.c:(.init.text+0x28e): undefined reference to `wireless_proc_init' net/built-in.o:(__ksymtab+0x1248): undefined reference to `wireless_send_event' make: *** [.tmp_vmlinux1] Error 1 This is with cfg80211 turned off. Thanks, -Michael Wu pgpDYhLuuGOBL.pgp Description: PGP signature
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Tuesday 24 October 2006 18:03, Luis R. Rodriguez wrote: 1. Anyone working on completing FullMAC support on d80211? That doesn't really make sense. Fullmac devices should just use WE or cfg80211 because they, for the most part, do what d80211 does in firmware. There are also strange hybrid devices like ipw2100/ipw2200, but IMHO, it's not worth trying to bolt d80211 onto those devices unless saner firmware becomes available. 2. Who's working on a userspace MLME replacement for d80211 and where are we with that? I think HostAP can handle authentication/association.. or was it wpa-supplicant? Maybe both.. 3. Who's doing the endianness/smp testing of d80211 and how far are we with that? The endianness issues seemed fine the last time I checked, and people do seem to be testing BE enough that to uncover an endianness regression I introduced when converting WEP code to use crypto api. As for SMP/locking, I think Jiri Benc knows how to deal with this. Lastly, as I have said in previous e-mails -- I agree with a userspace daemon but where is it and how long before its ready.. also it may be difficult to introduce as a requirement for distributions and for this reason I am suggesting going with in-kernel regulatory domain control and now perhaps in-kernel MLME for a first stable push of d80211, specially since only... 3 in-kernel drivers currently use d80211! 4 once p54 is merged, and more to come as I get to them. /me pokes Linville. I think time working on the in-kernel MLME is well worth it since I would like softmac drivers to have feature parity with fullmac drivers. Anything beyond that can go to userspace as far as I'm concerned. (so transitioning to d80211 based drivers won't involve too much pain unless you really want to take advantage of new features) Having some basic regulatory domain control in d80211 in the kernel should be okay for now just to make sure all drivers like the api presented. Working out the details of how to move the d80211 side stuff to userspace should be orthogonal to the driver interface and can be dealt with later, IMHO. -Michael Wu pgpWGSngKV0AL.pgp Description: PGP signature
[PATCH wireless-dev] set freq in ieee80211_rx_status
set freq in ieee80211_rx_status
This patch fixes the RX handler in adm8211 and p54 to report the current
frequency and channel. Should probably be handled in d80211 instead, but this
will fix things for now. It also eliminates some definitions in adm8211.h
that are no longer necessary.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c |3 ++
drivers/net/wireless/d80211/adm8211/adm8211.h | 42
---
drivers/net/wireless/d80211/p54/prism54.h |1 +
drivers/net/wireless/d80211/p54/prism54common.c |6 +++
4 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c
b/drivers/net/wireless/d80211/adm8211/adm8211.c
index 3bce55f..9f965d3 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -551,6 +551,9 @@ static void adm8211_interrupt_rci(struct
if (rate = 4)
rx_status.rate = rate_tbl[rate];
+ rx_status.channel = priv-channel;
+ rx_status.freq = adm8211_channels[priv-channel -
1].freq;
+
/* remove FCS */
/* TODO: remove this and set flag in ieee80211_hw
instead? */
if (dev-flags IFF_PROMISC)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.h
b/drivers/net/wireless/d80211/adm8211/adm8211.h
index 89e0fdf..a579a90 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.h
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.h
@@ -590,47 +590,33 @@ static const struct ieee80211_chan_range
static const struct ieee80211_channel adm8211_channels[] = {
{ .chan = 1,
- .freq = 2412,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2412},
{ .chan = 2,
- .freq = 2417,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2417},
{ .chan = 3,
- .freq = 2422,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2422},
{ .chan = 4,
- .freq = 2427,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2427},
{ .chan = 5,
- .freq = 2432,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2432},
{ .chan = 6,
- .freq = 2437,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2437},
{ .chan = 7,
- .freq = 2442,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2442},
{ .chan = 8,
- .freq = 2447,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2447},
{ .chan = 9,
- .freq = 2452,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2452},
{ .chan = 10,
- .freq = 2457,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2457},
{ .chan = 11,
- .freq = 2462,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2462},
{ .chan = 12,
- .freq = 2467,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2467},
{ .chan = 13,
- .freq = 2472,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS},
+ .freq = 2472},
{ .chan = 14,
- .freq = 2484,
- .flag = IEEE80211_CHAN_W_SCAN | IEEE80211_CHAN_W_ACTIVE_SCAN |
IEEE80211_CHAN_W_IBSS}
+ .freq = 2484},
};
#endif /* ADM8211_H */
diff --git a/drivers/net/wireless/d80211/p54/prism54.h
b/drivers/net/wireless/d80211/p54/prism54.h
index a165cc5..f2aaafe 100644
--- a/drivers/net/wireless/d80211/p54/prism54.h
+++ b/drivers/net/wireless/d80211/p54/prism54.h
@@ -53,6 +53,7 @@ struct p54_common {
int (*open)(struct net_device *dev);
void (*stop)(struct net_device *dev);
int mode;
+ int channel;
struct pda_iq_autocal_entry *iq_autocal;
unsigned int iq_autocal_len;
struct pda_channel_output_limit *output_limit;
diff --git a/drivers/net/wireless/d80211/p54/prism54common.c
b/drivers/net/wireless/d80211/p54/prism54common.c
index a96a4fc..34bccee 100644
--- a/drivers/net/wireless/d80211/p54/prism54common.c
+++ b/drivers/net/wireless/d80211/p54/prism54common.c
@@ -206,11 +206,14 @@ EXPORT_SYMBOL_GPL(p54_parse_eeprom);
static void
[PATCH wireless-dev] p54: fix stalling in TX queue
p54: fix stalling in TX queue
This patch makes the p54 TX queue not stall anymore. Probably not the most
efficient thing to do, but it's better than stalling.
It also adds a small comment to prism54common.h about the origin of the pda
definitions and inserts a missing verb in the comment for p54_assign_address.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/p54/prism54common.c | 10 +-
drivers/net/wireless/d80211/p54/prism54common.h |2 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/d80211/p54/prism54common.c
b/drivers/net/wireless/d80211/p54/prism54common.c
index 34bccee..6f4cb5f 100644
--- a/drivers/net/wireless/d80211/p54/prism54common.c
+++ b/drivers/net/wireless/d80211/p54/prism54common.c
@@ -261,8 +261,8 @@ static void p54_rx_frame_sent(struct net
entry = entry-next;
}
- if (freed IEEE80211_MAX_RTS_THRESHOLD + 0x170 + sizeof(struct
p54_control_hdr))
- ieee80211_wake_queue(dev, 0);
+ if (skb_queue_empty(priv-tx_queue))
+ ieee80211_wake_queue(dev, 0);
}
static void p54_rx_control(struct net_device *dev, struct sk_buff *skb)
@@ -308,9 +308,9 @@ EXPORT_SYMBOL_GPL(p54_rx);
/*
* So, the firmware is somewhat stupid and doesn't know what places in its
* memory incoming data should go to. By poking around in the firmware, we
- * can some unused memory to upload our packets to. However, data that we
want
- * the card to TX needs to stay intact until the card has told us that it is
- * done with it. This function finds empty places we can upload to and
+ * can find some unused memory to upload our packets to. However, data that
we
+ * want the card to TX needs to stay intact until the card has told us that
+ * it is done with it. This function finds empty places we can upload to and
* marks allocated areas as reserved if necessary. p54_rx_frame_sent frees
* allocated areas.
*/
diff --git a/drivers/net/wireless/d80211/p54/prism54common.h
b/drivers/net/wireless/d80211/p54/prism54common.h
index e2c1ff4..15199f6 100644
--- a/drivers/net/wireless/d80211/p54/prism54common.h
+++ b/drivers/net/wireless/d80211/p54/prism54common.h
@@ -43,6 +43,8 @@ #define FW_LM86 0x4c4d3836
#define FW_LM87 0x4c4d3837
#define FW_LM20 0x4c4d3230
+/* PDA defines are Copyright (C) 2005 Nokia Corporation (taken from
islsm_pda.h) */
+
struct pda_entry {
u16 len;/* includes both code and data */
u16 code;
pgp4akAjeabep.pgp
Description: PGP signature
[PATCH wireless-dev] add p54 driver
(originally sent to John Linville, forgot to CC netdev..)
Hi,
The attached patch adds support for 3887 based prism54 usb wireless adaptors.
It is partially based on the islsm driver by Jean-Baptiste Note, but most of
the code is new (and uses d80211 instead of madwifi). It doesn't work
perfectly yet, but it can connect to an unsecure AP and send/receive packets
as long as you don't hit the tx code too hard. Further hardware support for
pci and net2280 usb will follow later. Also, I am unable to make it crash.
Thus, it should be in a suitable state for other developers to hack on.
Thanks,
-Michael Wu
p54patch.bz2
Description: BZip2 compressed data
p54usb: remove struct pt_regs *
This patch is necessary to compile once the changes from 2.6.19-rc2 are merged.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/p54/prism54usb.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/d80211/p54/prism54usb.c b/drivers/net/wireless/d80211/p54/prism54usb.c
index 9427786..c38e378 100644
--- a/drivers/net/wireless/d80211/p54/prism54usb.c
+++ b/drivers/net/wireless/d80211/p54/prism54usb.c
@@ -72,7 +72,7 @@ static struct usb_device_id p54u_table[]
MODULE_DEVICE_TABLE(usb, p54u_table);
-static void p54u_rx_cb(struct urb *urb, struct pt_regs *regs)
+static void p54u_rx_cb(struct urb *urb)
{
struct sk_buff *skb = (struct sk_buff *) urb-context;
struct p54u_priv *priv = ieee80211_dev_hw_data(((struct sk_buff *)urb-context)-dev);
@@ -105,12 +105,12 @@ static void p54u_rx_cb(struct urb *urb,
usb_submit_urb(urb, GFP_ATOMIC);
}
-static void p54u_tx_cb(struct urb *urb, struct pt_regs *regs)
+static void p54u_tx_cb(struct urb *urb)
{
usb_free_urb(urb);
}
-static void p54u_tx_free_cb(struct urb *urb, struct pt_regs *regs)
+static void p54u_tx_free_cb(struct urb *urb)
{
kfree(urb-transfer_buffer);
usb_free_urb(urb);
pgp614iHgGDJf.pgp
Description: PGP signature
Re: [PATCH wireless-dev] add p54 driver
On Tuesday 17 October 2006 11:43, Dan Williams wrote: On Tue, 2006-10-17 at 11:05 -0400, Michael Wu wrote: The attached patch adds support for 3887 based prism54 usb wireless adaptors. It is partially based on the islsm driver by Jean-Baptiste Note, but most of the code is new (and uses d80211 instead of madwifi). It doesn't work perfectly yet, but it can connect to an unsecure AP and send/receive packets as long as you don't hit the tx code too hard. Further hardware support for pci and net2280 usb will follow later. Also, I am unable to make it crash. Thus, it should be in a suitable state for other developers to hack on. I'm assuming this is for the softmac prism54 chipset, right? Yes. -Michael Wu pgp7IY53PoUDq.pgp Description: PGP signature
[PATCH wireless-dev] adm8211: small cleanups in adm8211_probe
adm8211: small cleanups in adm8211_probe
This patch adds a KERN_INFO to a printk that didn't have anything, and
shortens another line.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c
b/drivers/net/wireless/d80211/adm8211/adm8211.c
index dcabeab..5522e15 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -2072,13 +2072,13 @@ #endif
priv-channel = priv-modes[0].channels[0].chan;
- err = ieee80211_register_hw(dev, priv-hw);
+ err = ieee80211_register_hw(dev, hw);
if (err) {
printk(KERN_ERR %s (adm8211): Cannot register netdevice\n,
pci_name(pdev));
goto err_free_desc;
}
- printk(%s: hwaddr MAC_FMT , Rev 0x%02x\n,
+ printk(KERN_INFO %s: hwaddr MAC_FMT , Rev 0x%02x\n,
dev-name, MAC_ARG(dev-dev_addr), priv-revid);
return 0;
pgpjQWY7NMXiL.pgp
Description: PGP signature
[PATCH wireless-dev] Remove struct pt_regs * from d80211 drivers
Remove struct pt_regs * from d80211 drivers
This patch will be necessary once wireless-dev pulls the 2.6.19-rc2 changes
which include the removal of the struct pt_regs * argument in interrupt
handler callbacks.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c |3 +--
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |2 +-
drivers/net/wireless/d80211/rt2x00/rt2400pci.c |3 +--
drivers/net/wireless/d80211/rt2x00/rt2400pci.h |3 +--
drivers/net/wireless/d80211/rt2x00/rt2500pci.c |3 +--
drivers/net/wireless/d80211/rt2x00/rt2500pci.h |3 +--
drivers/net/wireless/d80211/rt2x00/rt2500usb.c |2 +-
drivers/net/wireless/d80211/rt2x00/rt2500usb.h |2 +-
drivers/net/wireless/d80211/rt2x00/rt61pci.c |3 +--
drivers/net/wireless/d80211/rt2x00/rt61pci.h |3 +--
drivers/net/wireless/d80211/rt2x00/rt73usb.c |2 +-
drivers/net/wireless/d80211/rt2x00/rt73usb.h |2 +-
12 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c
b/drivers/net/wireless/d80211/adm8211/adm8211.c
index 5522e15..38d483a 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -568,8 +568,7 @@ static void adm8211_interrupt_rci(struct
}
-static irqreturn_t adm8211_interrupt(int irq, void *dev_id,
-struct pt_regs *regs)
+static irqreturn_t adm8211_interrupt(int irq, void *dev_id)
{
#define ADM8211_INT(x) if (unlikely(stsr ADM8211_STSR_ ## x))
printk(KERN_DEBUG %s: #x \n, dev-name)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
index 82f1fd1..9ae69f8 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -1619,7 +1619,7 @@ static void bcm43xx_interrupt_ack(struct
}
/* Interrupt handler top-half */
-static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id, struct
pt_regs *regs)
+static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
{
irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_private *bcm = dev_id;
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
b/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
index a46b8b8..bdc57fc 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1803,8 +1803,7 @@ static void rt2400pci_txdone(void *data)
entry-tx_status.control.queue);
}
-static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance,
- struct pt_regs *regs)
+static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance)
{
struct rt2x00_dev *rt2x00dev = dev_instance;
u32 reg;
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
b/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
index a991b59..c120a4f 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
+++ b/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
@@ -943,7 +943,6 @@ static void rt2400pci_disable_radio(stru
static void rt2400pci_beacondone(void *data);
static void rt2400pci_rxdone(void *data);
static void rt2400pci_txdone(void *data);
-static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance,
- struct pt_regs *regs);
+static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance);
#endif /* RT2400PCI_H */
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
b/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
index c08b076..d350935 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
@@ -1952,8 +1952,7 @@ static void rt2500pci_txdone(void *data)
entry-tx_status.control.queue);
}
-static irqreturn_t rt2500pci_interrupt(int irq, void *dev_instance,
- struct pt_regs *regs)
+static irqreturn_t rt2500pci_interrupt(int irq, void *dev_instance)
{
struct rt2x00_dev *rt2x00dev = dev_instance;
u32 reg;
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
b/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
index fb44881..fe832d6 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
+++ b/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
@@ -1204,7 +1204,6 @@ static void rt2500pci_disable_radio(stru
static void rt2500pci_beacondone(void *data);
static void rt2500pci_rxdone(void *data);
static void rt2500pci_txdone(void *data);
-static irqreturn_t rt2500pci_interrupt(int irq, void *dev_instance,
- struct pt_regs *regs);
+static irqreturn_t rt2500pci_interrupt(int irq, void *dev_instance);
#endif /* RT2500PCI_H */
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
b/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
index 5d119cd..4f7dacd 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2500usb.c
+++ b/drivers/net
[PATCH wireless-dev] Remove struct pt_regs * from d80211 drivers
Remove struct pt_regs * from d80211 drivers
This patch will be necessary once wireless-dev pulls the 2.6.19-rc2 changes
which include the removal of the struct pt_regs * argument in interrupt
handler callbacks. Thanks to Johannes Berg [EMAIL PROTECTED] for
finding a spot in the bcm43xx driver that called the irq handler manually.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
drivers/net/wireless/d80211/adm8211/adm8211.c |3 +--
drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c |4 ++--
drivers/net/wireless/d80211/rt2x00/rt2400pci.c |3 +--
drivers/net/wireless/d80211/rt2x00/rt2400pci.h |3 +--
drivers/net/wireless/d80211/rt2x00/rt2500pci.c |3 +--
drivers/net/wireless/d80211/rt2x00/rt2500pci.h |3 +--
drivers/net/wireless/d80211/rt2x00/rt2500usb.c |2 +-
drivers/net/wireless/d80211/rt2x00/rt2500usb.h |2 +-
drivers/net/wireless/d80211/rt2x00/rt61pci.c |3 +--
drivers/net/wireless/d80211/rt2x00/rt61pci.h |3 +--
drivers/net/wireless/d80211/rt2x00/rt73usb.c |2 +-
drivers/net/wireless/d80211/rt2x00/rt73usb.h |2 +-
12 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/d80211/adm8211/adm8211.c
b/drivers/net/wireless/d80211/adm8211/adm8211.c
index 5522e15..38d483a 100644
--- a/drivers/net/wireless/d80211/adm8211/adm8211.c
+++ b/drivers/net/wireless/d80211/adm8211/adm8211.c
@@ -568,8 +568,7 @@ static void adm8211_interrupt_rci(struct
}
-static irqreturn_t adm8211_interrupt(int irq, void *dev_id,
-struct pt_regs *regs)
+static irqreturn_t adm8211_interrupt(int irq, void *dev_id)
{
#define ADM8211_INT(x) if (unlikely(stsr ADM8211_STSR_ ## x))
printk(KERN_DEBUG %s: #x \n, dev-name)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
index 82f1fd1..2c8339b 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
@@ -1619,7 +1619,7 @@ static void bcm43xx_interrupt_ack(struct
}
/* Interrupt handler top-half */
-static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id, struct
pt_regs *regs)
+static irqreturn_t bcm43xx_interrupt_handler(int irq, void *dev_id)
{
irqreturn_t ret = IRQ_HANDLED;
struct bcm43xx_private *bcm = dev_id;
@@ -3707,7 +3707,7 @@ static void bcm43xx_net_poll_controller(
local_irq_save(flags);
if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED)
- bcm43xx_interrupt_handler(bcm-irq, bcm, NULL);
+ bcm43xx_interrupt_handler(bcm-irq, bcm);
local_irq_restore(flags);
}
#endif /* CONFIG_NET_POLL_CONTROLLER */
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
b/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
index a46b8b8..bdc57fc 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
@@ -1803,8 +1803,7 @@ static void rt2400pci_txdone(void *data)
entry-tx_status.control.queue);
}
-static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance,
- struct pt_regs *regs)
+static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance)
{
struct rt2x00_dev *rt2x00dev = dev_instance;
u32 reg;
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
b/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
index a991b59..c120a4f 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
+++ b/drivers/net/wireless/d80211/rt2x00/rt2400pci.h
@@ -943,7 +943,6 @@ static void rt2400pci_disable_radio(stru
static void rt2400pci_beacondone(void *data);
static void rt2400pci_rxdone(void *data);
static void rt2400pci_txdone(void *data);
-static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance,
- struct pt_regs *regs);
+static irqreturn_t rt2400pci_interrupt(int irq, void *dev_instance);
#endif /* RT2400PCI_H */
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
b/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
index c08b076..d350935 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/d80211/rt2x00/rt2500pci.c
@@ -1952,8 +1952,7 @@ static void rt2500pci_txdone(void *data)
entry-tx_status.control.queue);
}
-static irqreturn_t rt2500pci_interrupt(int irq, void *dev_instance,
- struct pt_regs *regs)
+static irqreturn_t rt2500pci_interrupt(int irq, void *dev_instance)
{
struct rt2x00_dev *rt2x00dev = dev_instance;
u32 reg;
diff --git a/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
b/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
index fb44881..fe832d6 100644
--- a/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
+++ b/drivers/net/wireless/d80211/rt2x00/rt2500pci.h
@@ -1204,7 +1204,6 @@ static void rt2500pci_disable_radio(stru
static void rt2500pci_beacondone(void *data);
static void
Re: [patch 2/3] d80211: remove poorly documented ieee80211_hw extra_hdr_room flag
On Tuesday 10 October 2006 09:45, David Kimdon wrote: On Tue, Oct 10, 2006 at 12:00:12PM +0200, Michael Buesch wrote: On Monday 09 October 2006 19:03, David Kimdon wrote: This flag is unused by all in tree drivers. Furthermore, the way that it is documented is not consistent with the way it is actually used by ieee80211.c. The original attempt appears to be something to do with adding extra header room for low-level drivers which need to pad the IEEE 802.11 header (example: Atheros). What about not removing it, but extending it. Sure, I would be happy with that. For Atheros it will be '2' to ensure that we can properly align the packet in the tx path without needing to realloc. adm8211 needs this too to avoid realloc and possibly failing and dropping the packet. (except adm8211 needs closer to about 30 bytes of extra room to fit its hardware tx header) Thanks, -Michael Wu pgpiP72HgORhM.pgp Description: PGP signature
Re: [RFC] cfg80211 and nl80211
On Friday 29 September 2006 17:10, James Ketrenos wrote: Johannes Berg wrote: * Should the userspace daemon be allowed to unilaterally update the regulatory information if it learns something new (via the user)? Many countries forbid users (root is still a user) being enabled to override the parameters set up by the hardware vendor as tested for use with a specific device. If the hardware and/or driver for the hardware advertises a set of operating parameters, user space should honor those settings and the kernel should enforce them. This makes 802.11d impossible. There are already many ways of violating local regulations. We should not make it easy to override the regulatory domain parameters, but going out of our way to make it hard is not gonna work. With hardware that restricts operation to the capabilities it was tested and calibrated for, this will likely result in a broken user experience -- if they try and use a device on channel 13 and the device restricts operation to channels 1 - 11, tuning operations will fail. So the hardware should not even restrict tuning to channels 1-11, for example. That sort of enforcement belongs in the kernel, with information imported from userspace so parameters for various regulatory domains can be updated easily. (whereas with hardware enforcement, every change requires new firmware) Sure, it's a bit easier for an enthusiastic user to set the TX power too high or tune to channel 14, but it seems likely that the number of people who would do that is a bit smaller than the number of people who travel between different countries frequently (and would benefit from easy/automatic regulatory domain switching). -Michael Wu pgpx43ngepnZZ.pgp Description: PGP signature
Re: [RFC] cfg80211 and nl80211
On Thursday 28 September 2006 05:23, Johannes Berg wrote: * why should there be configuration per device? The user can only be operating in one country at a time... I think that information should just be available inside cfg80211 in a global structure for use by drivers whenever they need it (with some accessor methods to ensure locked access). Making regulatory info global is good. We're not really interested in a laptop with two wireless adapters sitting on a border. * I seem to have read between the lines that the EEPROM data is pretty much useless. Is that generally true, or should the userspace daemon be told what it contains (somehow)? Even if the EEPROM data is useful, the driver should probably process it before giving it to userspace so we don't have to worry about updating eeprom parsing in userspace. * Should the kernel perform some kind of validation on the regulatory data the daemon gives it as well? Probably just minimal sanity checks if needed. -Michael Wu pgpu6ZAkTUdqL.pgp Description: PGP signature
Re: [PATCH] softmac: Fix WX and association related races
On Thursday 28 September 2006 11:16, Larry Finger wrote: First of all, my problem is quite likely caused by a buggy AP. It is a Linksys WRT54G V5, which is one of those with a VxWorks kernel, not Linux. I have already reported one bug to Linksys, which they have neither acknowledged nor fixed! In that case, SoftMAC had to be modified as a work-around. These APs are truly bad. Hacking linux into it (DD-WRT) helps a bit, but wireless often seems to fail *completely* at times. I don't know why the deauthentication is being sent. The reason is not logged, which will be my first change in the code. The second place to look is why SoftMAC reports the network is unknown when the MAC printed is that of my AP. The deauth reason code is usually 6 or 7.. IIRC, it is 6: Class 2 Frame from Non Authenticated STA. The AP just forgets you're associated. However, I think that was from when I had a v3 WRT54G. I made sure the old adm8211 softmac stack had a very good set of printks to report these sort of things. :) Many APs do funny things.. -Michael Wu pgpar98uW1wrk.pgp Description: PGP signature
Re: [d80211] connecting to B-mode AP
On Friday 15 September 2006 19:50, mabbas wrote: I see your point here, although some one will file some bugs against the driver about showing G while associating with B-mode AP. By the way how can you figure if the AP is B/G other than the rates? IIRC, only 802.11g APs will send the extended rate information element, though I don't know if forcing 802.11b on the AP will cause it to stop sending that. (but it might still be okay if it doesn't - it's still a 802.11g AP, with the faster speeds turned off..) -Michael Wu pgpcbfmVQ6iNo.pgp Description: PGP signature
Re: [patch] d80211: fix WEP on big endian cpus
Huh. I assumed crc32_le gave us the result in little endian, but I guess
that's wrong.
I've attached another patch which basically does the same thing but adds some
sparse bitwise annotations to make things clear. Also, it has a signed-off-by
line. :)
d80211: fix WEP on big endian cpus
This patch fixes the endian issues with the ICV in WEP, as pointed out by
David Kimdon [EMAIL PROTECTED], and uses __le32 where
appropriate to make things clear.
Signed-off-by: Michael Wu [EMAIL PROTECTED]
---
net/d80211/wep.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/d80211/wep.c b/net/d80211/wep.c
index c3e4728..22c2e53 100644
--- a/net/d80211/wep.c
+++ b/net/d80211/wep.c
@@ -120,10 +120,10 @@ void ieee80211_wep_encrypt_data(struct c
size_t klen, u8 *data, size_t data_len)
{
struct scatterlist sg;
- u32 *icv;
+ __le32 *icv;
- icv = (u32 *)(data + data_len);
- *icv = ~crc32_le(~0, data, data_len);
+ icv = (__le32 *)(data + data_len);
+ *icv = cpu_to_le32(~crc32_le(~0, data, data_len));
crypto_cipher_setkey(tfm, rc4key, klen);
sg.page = virt_to_page(data);
@@ -187,7 +187,7 @@ int ieee80211_wep_decrypt_data(struct cr
size_t klen, u8 *data, size_t data_len)
{
struct scatterlist sg;
- u32 crc;
+ __le32 crc;
crypto_cipher_setkey(tfm, rc4key, klen);
sg.page = virt_to_page(data);
@@ -195,7 +195,7 @@ int ieee80211_wep_decrypt_data(struct cr
sg.length = data_len + WEP_ICV_LEN;
crypto_cipher_decrypt(tfm, sg, sg, sg.length);
- crc = ~crc32_le(~0, data, data_len);
+ crc = cpu_to_le32(~crc32_le(~0, data, data_len));
if (memcmp(crc, data + data_len, WEP_ICV_LEN) != 0)
/* ICV mismatch */
return -1;
pgpNK32qlwZjB.pgp
Description: PGP signature
