* Re: wl1271 firmware
From: Pazzo Da Legare @ 2010-07-22 15:41 UTC (permalink / raw)
To: Luciano Coelho
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <1279780848.2322.31.camel@powerslave>
Dear Luciano,
Dear All,
I enabled the DEBUG_LEVEL as you advice me but I have no additional
information....
[ 186.230000] wl1271_sdio mmc0:0001:2: firmware: requesting
wl1271-fw.bin
[ 186.420000] wl1271_sdio mmc0:0001:2: firmware: requesting
wl1271-nvs.bin
[ 186.860000] wl1271: firmware booted (Rev 6.1.0.0.310)
[ 186.880000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 187.380000] wl1271: ERROR ELP wakeup timeout!
[ 187.880000] wl1271: ERROR ELP wakeup timeout!
Pazzo
2010/7/22 Luciano Coelho <luciano.coelho@nokia.com>:
> Hi Pazzo,
>
>
> On Wed, 2010-07-21 at 19:27 +0200, ext Pazzo Da Legare wrote:
>> Dear All again,
>>
>> I've just test with compact-wireless-2010-07-20 but I've the same problem:
>>
>> root@hawkboard:~# ifconfig wlan0 192.168.0.1 up
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> root@hawkboard:~# [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>>
>> looking at dmesg:
>>
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
>> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
>> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
>> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
>> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>>
>> Do you have any clue?
>
> I'm not sure what this is, but usually an ERROR ELP wakeup timeout means
> that the firmware has crashed.
>
> Could you enable the following DEBUG flags in wl1271.h and send the logs
> again? Maybe they provide more clues...
>
> #define DEBUG_LEVEL (DEBUG_BOOT | DEBUG_ACX | DEBUG_CMD | DEBUG_PSM | \
> DEBUG_IRQ | DEBUG_EVENT)
>
>
> --
> Cheers,
> Luca.
>
>
^ permalink raw reply
* How to Get Channel within iw-tool
From: Zhongliang Zhao @ 2010-07-22 16:30 UTC (permalink / raw)
To: linux-wireless; +Cc: Staub Thomas
Hi all,
We have a small system with iw-tool installed, and we wrote a program to
set the channel of wireless interface. However we're currently lost in
the iw web page about how to check the currently used channel of
certain interface, namely the "get channel" functionality.
Does anyone have experience on this or please give us a hint on how to
see which channel the wireless interface is currently using within iw-tool?
Many thanks in advance.
Zhongliang & Thomas
--
Zhongliang Zhao, Research Assistant
Institute of Computer Science and Applied Mathematics
University of Bern, Neubrueckstrasse 10, CH-3012 Bern, Switzerland
Email: zhao@iam.unibe.ch
Phone: +41 (0)31 511 2639
Fax: +41 (0)31 631 3261
^ permalink raw reply
* Re: wl1271 firmware
From: Luciano Coelho @ 2010-07-22 16:34 UTC (permalink / raw)
To: ext Pazzo Da Legare
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <AANLkTilZhvGg2SUk5btpQQA3qj2k4rob4rTychDu7gXM@mail.gmail.com>
On Thu, 2010-07-22 at 17:41 +0200, ext Pazzo Da Legare wrote:
> I enabled the DEBUG_LEVEL as you advice me but I have no additional
> information....
>
> [ 186.230000] wl1271_sdio mmc0:0001:2: firmware: requesting
> wl1271-fw.bin
> [ 186.420000] wl1271_sdio mmc0:0001:2: firmware: requesting
> wl1271-nvs.bin
> [ 186.860000] wl1271: firmware booted (Rev 6.1.0.0.310)
> [ 186.880000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 187.380000] wl1271: ERROR ELP wakeup timeout!
> [ 187.880000] wl1271: ERROR ELP wakeup timeout!
There's something wrong. There should have been a lot more traces with
the DEBUG_LEVEL I proposed. Please try again.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] MAINTAINERS: mark prism54 obsolete
From: John W. Linville @ 2010-07-22 18:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
The prism54 driver had an entry in feature-removal-schedule.txt and it
sees very little activity other than API-change "bombing runs". The
mac80211-based p54 driver should be used instead.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7faf729..3148b71 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4499,7 +4499,7 @@ PRISM54 WIRELESS DRIVER
M: "Luis R. Rodriguez" <mcgrof@gmail.com>
L: linux-wireless@vger.kernel.org
W: http://prism54.org
-S: Maintained
+S: Obsolete
F: drivers/net/wireless/prism54/
PROMISE DC4030 CACHING DISK CONTROLLER DRIVER
--
1.7.1.1
^ permalink raw reply related
* [RFT] airo: silence sparse warnings
From: John W. Linville @ 2010-07-22 18:23 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/airo.c
drivers/net/wireless/airo.c:2053:24: warning: incorrect type in assignment (different base types)
drivers/net/wireless/airo.c:2053:24: expected restricted __le16 [usertype] status
drivers/net/wireless/airo.c:2053:24: got unsigned short [unsigned] [usertype] status
drivers/net/wireless/airo.c:3247:18: warning: cast to restricted __le16
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
My airo cards seem to have died...or maybe airo is just broken?
drivers/net/wireless/airo.c | 50 +++++++++++++++++++++---------------------
1 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 053f90c..154554c 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -1042,43 +1042,43 @@ typedef struct {
} HostRidDesc;
typedef struct {
- u16 sw0;
- u16 sw1;
- u16 status;
- u16 len;
-#define HOST_SET (1 << 0)
-#define HOST_INT_TX (1 << 1) /* Interrupt on successful TX */
-#define HOST_INT_TXERR (1 << 2) /* Interrupt on unseccessful TX */
-#define HOST_LCC_PAYLOAD (1 << 4) /* LLC payload, 0 = Ethertype */
-#define HOST_DONT_RLSE (1 << 5) /* Don't release buffer when done */
-#define HOST_DONT_RETRY (1 << 6) /* Don't retry trasmit */
-#define HOST_CLR_AID (1 << 7) /* clear AID failure */
-#define HOST_RTS (1 << 9) /* Force RTS use */
-#define HOST_SHORT (1 << 10) /* Do short preamble */
- u16 ctl;
- u16 aid;
- u16 retries;
- u16 fill;
+ __le16 sw0;
+ __le16 sw1;
+ __le16 status;
+ __le16 len;
+#define HOST_SET cpu_to_le16(1 << 0)
+#define HOST_INT_TX cpu_to_le16(1 << 1) /* Interrupt on successful TX */
+#define HOST_INT_TXERR cpu_to_le16(1 << 2) /* Interrupt on unseccessful TX */
+#define HOST_LCC_PAYLOAD cpu_to_le16(1 << 4) /* LLC payload, 0 = Ethertype */
+#define HOST_DONT_RLSE cpu_to_le16(1 << 5) /* Don't release buffer when done */
+#define HOST_DONT_RETRY cpu_to_le16(1 << 6) /* Don't retry trasmit */
+#define HOST_CLR_AID cpu_to_le16(1 << 7) /* clear AID failure */
+#define HOST_RTS cpu_to_le16(1 << 9) /* Force RTS use */
+#define HOST_SHORT cpu_to_le16(1 << 10) /* Do short preamble */
+ __le16 ctl;
+ __le16 aid;
+ __le16 retries;
+ __le16 fill;
} TxCtlHdr;
typedef struct {
- u16 ctl;
- u16 duration;
+ __le16 ctl;
+ __le16 duration;
char addr1[6];
char addr2[6];
char addr3[6];
- u16 seq;
+ __le16 seq;
char addr4[6];
} WifiHdr;
typedef struct {
TxCtlHdr ctlhdr;
- u16 fill1;
- u16 fill2;
+ __le16 fill1;
+ __le16 fill2;
WifiHdr wifihdr;
- u16 gaplen;
- u16 status;
+ __le16 gaplen;
+ __le16 status;
} WifiCtlHdr;
static WifiCtlHdr wifictlhdr8023 = {
@@ -3244,7 +3244,7 @@ static void airo_handle_link(struct airo_info *ai)
u16 status;
/* Get new status and acknowledge the link change */
- status = le16_to_cpu(IN4500(ai, LINKSTAT));
+ status = IN4500(ai, LINKSTAT);
OUT4500(ai, EVACK, EV_LINK);
if ((status == STAT_FORCELOSS) && (ai->scan_timeout > 0))
--
1.7.1.1
^ permalink raw reply related
* [PATCH] atmel: silence sparse warnings
From: John W. Linville @ 2010-07-22 18:24 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/atmel.c
drivers/net/wireless/atmel.c:3694:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3695:31: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3696:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3697:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3698:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3699:31: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3700:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3701:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3702:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3703:30: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3704:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3705:32: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3706:28: warning: cast to restricted __le16
drivers/net/wireless/atmel.c:3707:29: warning: cast to restricted __le16
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Is this any better than what we have now??
drivers/net/wireless/atmel.c | 73 ++++++++++++++++++++++++++++++++----------
1 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
index c8f7090..008d712 100644
--- a/drivers/net/wireless/atmel.c
+++ b/drivers/net/wireless/atmel.c
@@ -3617,6 +3617,7 @@ static void atmel_command_irq(struct atmel_private *priv)
static int atmel_wakeup_firmware(struct atmel_private *priv)
{
struct host_info_struct *iface = &priv->host_info;
+ u8 buf[sizeof(struct host_info_struct)];
u16 mr1, mr3;
int i;
@@ -3688,23 +3689,61 @@ static int atmel_wakeup_firmware(struct atmel_private *priv)
return -EIO;
}
- atmel_copy_to_host(priv->dev, (unsigned char *)iface,
- priv->host_info_base, sizeof(*iface));
-
- iface->tx_buff_pos = le16_to_cpu(iface->tx_buff_pos);
- iface->tx_buff_size = le16_to_cpu(iface->tx_buff_size);
- iface->tx_desc_pos = le16_to_cpu(iface->tx_desc_pos);
- iface->tx_desc_count = le16_to_cpu(iface->tx_desc_count);
- iface->rx_buff_pos = le16_to_cpu(iface->rx_buff_pos);
- iface->rx_buff_size = le16_to_cpu(iface->rx_buff_size);
- iface->rx_desc_pos = le16_to_cpu(iface->rx_desc_pos);
- iface->rx_desc_count = le16_to_cpu(iface->rx_desc_count);
- iface->build_version = le16_to_cpu(iface->build_version);
- iface->command_pos = le16_to_cpu(iface->command_pos);
- iface->major_version = le16_to_cpu(iface->major_version);
- iface->minor_version = le16_to_cpu(iface->minor_version);
- iface->func_ctrl = le16_to_cpu(iface->func_ctrl);
- iface->mac_status = le16_to_cpu(iface->mac_status);
+ atmel_copy_to_host(priv->dev, (unsigned char *)&buf,
+ priv->host_info_base, sizeof(buf));
+
+ iface->int_status = buf[offsetof(struct host_info_struct,
+ int_status)];
+ iface->int_mask = buf[offsetof(struct host_info_struct, int_mask)];
+ iface->lockout_host = buf[offsetof(struct host_info_struct,
+ lockout_host)];
+ iface->lockout_mac = buf[offsetof(struct host_info_struct,
+ lockout_mac)];
+ iface->tx_buff_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_buff_pos)]);
+ iface->tx_buff_size =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_buff_size)]);
+ iface->tx_desc_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_desc_pos)]);
+ iface->tx_desc_count =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ tx_desc_count)]);
+ iface->rx_buff_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_buff_pos)]);
+ iface->rx_buff_size =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_buff_size)]);
+ iface->rx_desc_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_desc_pos)]);
+ iface->rx_desc_count =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ rx_desc_count)]);
+ iface->build_version =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ build_version)]);
+ iface->command_pos =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ command_pos)]);
+ iface->major_version =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ major_version)]);
+ iface->minor_version =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ minor_version)]);
+ iface->func_ctrl =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ func_ctrl)]);
+ iface->mac_status =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ mac_status)]);
+ iface->generic_IRQ_type =
+ le16_to_cpu(*(__le16 *)&buf[offsetof(struct host_info_struct,
+ generic_IRQ_type)]);
return 0;
}
--
1.7.1.1
^ permalink raw reply related
* wl1271 with atmel-mci
From: Logan Gunthorpe @ 2010-07-22 18:33 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
Hi Luciano,
I've had the wl1271 working for the most part on an Atmel
micro-controller, but I've been fighting with a bug for the past couple
of days.
The problem happens whenever I try to transmit large packets of data
(using iperf, or nc, etc) the driver would hang and no longer be able to
send packets. tx_queue_len in the debugfs would then grow as I tried to
send packets but nothing would actually be sent to the device. At the
same time receiving packets would consistently work all of the time.
When this occurred I usually got the following messages:
atmel_mci atmel_mci.0: data CRC error
wl1271: ERROR sdio write failed (-84) - addr 0x14fd8, 1076 bytes, 1
(Note: I added the bit at the end of the wl1271 write failed message in
order to try and debug this problem.)
Upon further investigation I found that any calls to sdio_writesb with a
length greater than or equal to 1024 will occasionally fail with a data
CRC error and this would cause the device to stop working.
I have also found that the following ugly hack in wl1271_sdio_raw_write
seems to fix the problem:
if (len <= 1000) {
ret = sdio_writesb(func, addr, buf, len);
} else {
ret = sdio_writesb(func, addr, buf, 1000);
ret |= sdio_writesb(func, addr, &buf[1000], len-1000);
}
Based on the above, I am currently thinking there may be a bug in the
atmel-mci driver that causes this problem. Therefore, I will likely
contact that driver's maintainer next. I was just hoping to get your
insight in case there is something I am missing on the wl1271 side.
Thanks,
Logan
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: Guy, Wey-Yi @ 2010-07-22 18:37 UTC (permalink / raw)
To: drago01; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTilxa09Cqn3icsTRAULhKBPzv5evOVPTqI-GrYiU@mail.gmail.com>
Hi drago,
On Wed, 2010-07-21 at 14:00 -0700, drago01 wrote:
> On Wed, Jul 21, 2010 at 10:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> > Hi drago,
> > On Wed, 2010-07-21 at 12:59 -0700, drago01 wrote:
> >> On Tue, Jul 20, 2010 at 1:56 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> >> > Hi drago,
> >> >
> >> >
> >> > Are you using 5350? here I attach a "RFC patch", could you give a try to
> >> > see if it help?
> >>
> >> Not quite I am on 5300; your patch seem to only touch the 5350 code
> >> ... should I try the same change for 5300?
> >
> > Yes, please
>
> Hi,
>
> As there is no such field in .34 I patched the .35 driver which seems
> to be fine with the change ... I couldn't trigger it using the close
> lid (no suspend) and wait a bit trick ... but I have not used it for
> long enough to say for certain that its gone.
>
> But unfortunately the driver has a different issue it spams my log with tons of:
>
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
> iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
>
Yes, I aware of this, this is introduced by a recent patch
commit d9763a384216336e180399b69461eae37f6c4f54
I will work on a new patch to help address this.
Thanks
Wey
^ permalink raw reply
* [PATCH] MAINTAINERS: orphan the raylink wireless driver
From: John W. Linville @ 2010-07-22 18:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Corey Thomas, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2911648..79b0679 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4680,9 +4680,8 @@ S: Maintained
F: drivers/rapidio/
RAYLINK/WEBGEAR 802.11 WIRELESS LAN DRIVER
-M: Corey Thomas <coreythomas@charter.net>
L: linux-wireless@vger.kernel.org
-S: Maintained
+S: Orphan
F: drivers/net/wireless/ray*
RCUTORTURE MODULE
--
1.7.1.1
^ permalink raw reply related
* [PATCH] MAINTAINERS: orphan the atmel wireless driver
From: John W. Linville @ 2010-07-22 18:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Simon Kelley, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3148b71..2911648 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1170,11 +1170,10 @@ S: Supported
F: drivers/usb/gadget/atmel_usba_udc.*
ATMEL WIRELESS DRIVER
-M: Simon Kelley <simon@thekelleys.org.uk>
L: linux-wireless@vger.kernel.org
W: http://www.thekelleys.org.uk/atmel
W: http://atmelwlandriver.sourceforge.net/
-S: Maintained
+S: Orphan
F: drivers/net/wireless/atmel*
AUDIT SUBSYSTEM
--
1.7.1.1
^ permalink raw reply related
* [PATCH] MAINTAINERS: orphan the zd1201 wireless driver
From: John W. Linville @ 2010-07-22 18:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Jeroen Vreeken, linux-usb, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 79b0679..220a4ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5989,10 +5989,9 @@ F: Documentation/video4linux/zc0301.txt
F: drivers/media/video/zc0301/
USB ZD1201 DRIVER
-M: Jeroen Vreeken <pe1rxq@amsat.org>
-L: linux-usb@vger.kernel.org
+L: linux-wireless@vger.kernel.org
W: http://linux-lc100020.sourceforge.net
-S: Maintained
+S: Orphan
F: drivers/net/wireless/zd1201.*
USB ZR364XX DRIVER
--
1.7.1.1
^ permalink raw reply related
* Wireless card on Debian squeeze
From: Nicholas Syrotiuk @ 2010-07-22 18:20 UTC (permalink / raw)
To: linux-wireless
Dear Linux Wireless users,
I'm having some trouble installing the correct driver on my laptop. I'm
slightly confused about the revision numbering of my wireless hardware;
that is, I'm not sure if it's revision 2 or 3.
My kernel is: 2.6.32-5
Relevant output from lspci is:
02:03.0 Network controller [0280]: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller [14e4:4320] (rev 02)
Subsystem: Dell TrueMobile 1300 WLAN Mini-PCI Card [1028:0001]
Flags: bus master, fast devsel, latency 32, IRQ 5
Memory at fafee000 (32-bit, non-prefetchable) [size=8K]
Kernel driver in use: b43-pci-bridge
-----------------------------------------------
It looks like I need the b43legacy driver, which comes in a separate
Debian package called "firmware-b43legacy-installer." When I install
this package, computer says: "Not supported card. Use b43 firmware."
When I install b43 firmware, configure the interface and bring it up,
computer says: "Firmware file b43legacy/ucode4.fw not found or load failed."
So, I am slightly confounded. However, it has occurred to me that I may
be getting the packages from the wrong source, which are currently:
deb http://debian.man.ac.uk/debian squeeze main
deb http://ftp.us.debian.org/debian squeeze main contrib
Any ideas?
Cheers, Nick
^ permalink raw reply
* Re: [PATCH] wireless: remove prism54
From: John W. Linville @ 2010-07-22 18:56 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Christian Lamparter
In-Reply-To: <AANLkTikWo6tjyYCDMgoA9WXvbNaWIe_oSp180jcdtWgy@mail.gmail.com>
On Wed, Jul 21, 2010 at 01:58:40PM -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 21, 2010 at 11:05 AM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > This driver is no longer necessary due to p54pci. It has seen very
> > little maintenance for some time, and at least Fedora has had it
> > disabled without any user complaints.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> Hm, we had a few users report back that only with prism54 and not
> p54pci could they get their device functional. IIRC Christian noted
> some issues with the EEPROM, and it seems the fault was on the
> manufacturer. My memory may be foggy but indeed I do remember a few
> users did complain about the feature removal plan. I can dig these
> e-mails up if needed.
I think I found some of that in the archive. Do we have any sort of
plan for resolving these EEPROM-related (i.e. missing and/or damaged
EEPROM) issue?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] MAINTAINERS: remove entry for wavelan
From: John W. Linville @ 2010-07-22 18:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Jean Tourrilhes, John W. Linville
The driver is already removed from drivers/staging. The wireless
extensions part is not really valid anymore either, since wext got moved
and refactored, etc.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
MAINTAINERS | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 220a4ba..f160c77 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6177,14 +6177,6 @@ F: Documentation/watchdog/
F: drivers/watchdog/
F: include/linux/watchdog.h
-WAVELAN NETWORK DRIVER & WIRELESS EXTENSIONS
-M: Jean Tourrilhes <jt@hpl.hp.com>
-L: linux-wireless@vger.kernel.org
-W: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/
-S: Maintained
-F: Documentation/networking/wavelan.txt
-F: drivers/staging/wavelan/
-
WD7000 SCSI DRIVER
M: Miroslav Zagorac <zaga@fly.cc.fer.hr>
L: linux-scsi@vger.kernel.org
--
1.7.1.1
^ permalink raw reply related
* Compat-wireless release for 2010-07-22 is baked
From: Compat-wireless cronjob account @ 2010-07-22 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
1a05138..04898a5 master -> origin/master
0442f68..c7ecb8a wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
5f11688..afdbfed history -> origin/history
+ fecd01b...dd5c869 master -> origin/master (forced update)
e095937..cd5b8f8 stable -> origin/stable
* [new tag] next-20100722 -> next-20100722
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
493727 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4605 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2467 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100722
compat-wireless release: compat-wireless-2010-07-13-4-g04898a5
^ permalink raw reply
* Re: minstrel_tx_status mac80211 WARNINGs in vanilla 2.6.34.1
From: Felix Fietkau @ 2010-07-22 19:07 UTC (permalink / raw)
To: John W. Linville; +Cc: Sven Geggus, netdev, linux-wireless
In-Reply-To: <20100722144723.GA2616@tuxdriver.com>
On 2010-07-22 4:47 PM, John W. Linville wrote:
> On Thu, Jul 22, 2010 at 02:30:01PM +0200, Sven Geggus wrote:
>> Hello,
>>
>> running vanilla 2.6.34.1 I get the following warnings in kernel log:
>>
>> WARNING: at net/mac80211/rc80211_minstrel.c:70 minstrel_tx_status+0x67/0xd1 [mac80211]()
>> Hardware name: SCENIC E300/E600
>> Modules linked in: i915 drm_kms_helper drm video backlight output lp loop
>> snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm
>> snd_seq_dummy zd1211rw snd_seq_oss usbhid mac80211 option cfg80211
>> snd_seq_midi usbserial snd_rawmidi snd_seq_midi_event snd_seq snd_timer
>> snd_seq_device snd parport_pc ehci_hcd uhci_hcd soundcore intel_agp parport
>> usbcore nls_base snd_page_alloc agpgart rng_core floppy sg
>> Pid: 0, comm: swapper Tainted: G W 2.6.34.1 #3
>> Call Trace:
>> [<c102af25>] warn_slowpath_common+0x60/0x90
>> [<c102af62>] warn_slowpath_null+0xd/0x10
>> [<f83cbd48>] minstrel_tx_status+0x67/0xd1 [mac80211]
>> [<f83b6eb1>] ieee80211_tx_status+0x1f6/0x5ac [mac80211]
>> [<c1261533>] ? skb_dequeue+0x45/0x4c
>> [<f83b6896>] ieee80211_tasklet_handler+0x61/0xd6 [mac80211]
>> [<c102ed7d>] tasklet_action+0x62/0x9f
>> [<c102f331>] __do_softirq+0x77/0xe5
>> [<c102f3c5>] do_softirq+0x26/0x2b
>> [<c102f52f>] irq_exit+0x29/0x66
>> [<c1003e90>] do_IRQ+0x85/0x9b
>> [<c1002d29>] common_interrupt+0x29/0x30
>> [<c10083ac>] ? default_idle+0x2d/0x42
>> [<c1001a9b>] cpu_idle+0x44/0x71
>> [<c12e00de>] rest_init+0x96/0x98
>> [<c1498862>] start_kernel+0x2a5/0x2aa
>> [<c14980b7>] i386_start_kernel+0xb7/0xbf
>> ---[ end trace f22ceacef336878f ]---
>>
>> Wireless driver is zd1211rw.
>>
>> Did not test with older kernel because this device has not been in user on
>> this machine before.
>>
>> WLAN does however seem to work anyway.
>
> Well, I just took a quick look -- so, I'm not 100% sure...
>
> But, it looks to me like zd1211rw is reporting tx status on a rate
> that minstrel didn't expect it to use. It seems like the hardware
> is pre-wired to do retries on sequentially lower rates, which seems
> a bit incompatible with minstrel's worldview.
>
> Felix, can we accomodate this? The "WLAN does however seem to work
> anyway" seems to suggest things work, so can we at least not yell
> about it?
I think we should just drop that WARN_ON(). It's not problematic if
minstrel gets feedback for rates that it doesn't have in its list, it
should just ignore it.
- Felix
^ permalink raw reply
* Re: [PATCH] zd1211rw: make CR_INTERRUPT cast explicit
From: John W. Linville @ 2010-07-22 19:03 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <1279730218.9003.7.camel@mj>
On Wed, Jul 21, 2010 at 12:36:58PM -0400, Pavel Roskin wrote:
> On Wed, 2010-07-21 at 11:08 -0400, John W. Linville wrote:
> > CHECK drivers/net/wireless/zd1211rw/zd_usb.c
> > drivers/net/wireless/zd1211rw/zd_usb.c:376:24: warning: implicit cast from nocast type
> >
> > The value comparison is intentional, so forcing the cast seems warranted
> > in order to silence the sparse warning.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
> > index 818e148..acbf4d9 100644
> > --- a/drivers/net/wireless/zd1211rw/zd_usb.c
> > +++ b/drivers/net/wireless/zd1211rw/zd_usb.c
> > @@ -373,7 +373,7 @@ static inline void handle_regs_int(struct urb *urb)
> > spin_lock(&intr->lock);
> >
> > int_num = le16_to_cpu(*(__le16 *)(urb->transfer_buffer+2));
> > - if (int_num == CR_INTERRUPT) {
> > + if (int_num == (u16 __force) CR_INTERRUPT) {
>
> I think __force should be used sparingly, especially outside headers. I
> tried other ways to prevent the warning. I tried declaring int_num as
> zd_addr_t, but sparse keeps complaining about the same comparison.
Actually, it looks like it works w/o the "__force" as well.
Any objection to a version like that?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: potential null deref in iwlagn_request_scan()?
From: John W. Linville @ 2010-07-22 19:28 UTC (permalink / raw)
To: Dan Carpenter; +Cc: johannes.berg, linux-wireless
In-Reply-To: <20100721221616.GT17585@bicker>
On Thu, Jul 22, 2010 at 12:16:16AM +0200, Dan Carpenter wrote:
> Smatch complains about iwlagn_request_scan().
>
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c +1354 iwlagn_request_scan(204)
> error: we previously assumed 'vif' could be null.
>
> 1351 if (!priv->is_internal_short_scan) {
> 1352 cmd_len = iwl_fill_probe_req(priv,
> 1353 (struct ieee80211_mgmt *)scan->data,
> 1354 vif->addr,
> ^^^^^^^^^
>
> 1355 priv->scan_request->ie,
> 1356 priv->scan_request->ie_len,
> 1357 IWL_MAX_SCAN_SIZE - sizeof(*scan));
> 1358 } else {
> 1359 /* use bcast addr, will not be transmitted but must be valid */
>
> This was added in 3a0b9aad0a8166e9f "iwlwifi: use virtual interface
> address for scan". Prior to that commit the function assumed that vif
> could be NULL throughout.
>
> I don't know the code well enough to know what to do about this.
>
> Also the same thing for:
> drivers/net/wireless/iwlwifi/iwl3945-base.c +2963 iwl3945_request_scan(158)
> error: we previously assumed 'vif' could be null.
I think both of these are more-or-less OK. It looks like the only
time vif would be NULL is in the "priv->is_internal_short_scan ==
true" case. I'll send a patch, but I don't know if it really matters.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] iwlwifi: assume vif is NULL for internal scans and non-NULL otherwise
From: John W. Linville @ 2010-07-22 19:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Dan Carpenter, John W. Linville
In-Reply-To: <20100721221616.GT17585@bicker>
The current practice of checking vif for NULL in one place but not
another seems to confuse some static checkers, smatch in particular.
Since vif will only be NULL in the case of internal scans, adjust the
checks accordingly.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 ++++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 74623e0..0ca0df4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -1234,7 +1234,10 @@ void iwlagn_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
spin_lock_irqsave(&priv->lock, flags);
- interval = vif ? vif->bss_conf.beacon_int : 0;
+ if (priv->is_internal_short_scan)
+ interval = 0;
+ else
+ interval = vif->bss_conf.beacon_int;
spin_unlock_irqrestore(&priv->lock, flags);
scan->suspend_time = 0;
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 8eb3471..b102bab 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -2883,7 +2883,10 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
spin_lock_irqsave(&priv->lock, flags);
- interval = vif ? vif->bss_conf.beacon_int : 0;
+ if (priv->is_internal_short_scan)
+ interval = 0;
+ else
+ interval = vif->bss_conf.beacon_int;
spin_unlock_irqrestore(&priv->lock, flags);
scan->suspend_time = 0;
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] iwlwifi: assume vif is NULL for internal scans and non-NULL otherwise
From: Guy, Wey-Yi @ 2010-07-22 19:36 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, Dan Carpenter
In-Reply-To: <1279826937-24581-1-git-send-email-linville@tuxdriver.com>
Hi John,
On Thu, 2010-07-22 at 12:28 -0700, John W. Linville wrote:
> The current practice of checking vif for NULL in one place but not
> another seems to confuse some static checkers, smatch in particular.
> Since vif will only be NULL in the case of internal scans, adjust the
> checks accordingly.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 ++++-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 5 ++++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> index 74623e0..0ca0df4 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> @@ -1234,7 +1234,10 @@ void iwlagn_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
>
> IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
> spin_lock_irqsave(&priv->lock, flags);
> - interval = vif ? vif->bss_conf.beacon_int : 0;
> + if (priv->is_internal_short_scan)
> + interval = 0;
> + else
> + interval = vif->bss_conf.beacon_int;
> spin_unlock_irqrestore(&priv->lock, flags);
>
> scan->suspend_time = 0;
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index 8eb3471..b102bab 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -2883,7 +2883,10 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
> IWL_DEBUG_INFO(priv, "Scanning while associated...\n");
>
> spin_lock_irqsave(&priv->lock, flags);
> - interval = vif ? vif->bss_conf.beacon_int : 0;
> + if (priv->is_internal_short_scan)
> + interval = 0;
> + else
> + interval = vif->bss_conf.beacon_int;
> spin_unlock_irqrestore(&priv->lock, flags);
>
> scan->suspend_time = 0;
Make sense, Thanks.
Wey
^ permalink raw reply
* Re: potential null deref in minstrel_ht_update_caps()?
From: John W. Linville @ 2010-07-22 19:35 UTC (permalink / raw)
To: Dan Carpenter; +Cc: nbd, linux-wireless, johannes
In-Reply-To: <20100722110933.GA17585@bicker>
On Thu, Jul 22, 2010 at 01:09:33PM +0200, Dan Carpenter wrote:
> This is a smatch thing.
>
> net/mac80211/rc80211_minstrel_ht.c +639 minstrel_ht_update_caps(15)
> warn: variable dereferenced before check 'sta'
> 631 struct ieee80211_mcs_info *mcs = &sta->ht_cap.mcs;
> 632 struct ieee80211_local *local = hw_to_local(mp->hw);
> 633 u16 sta_cap = sta->ht_cap.cap;
> ^^^^^^^^^^^^^^^
> Dereferenced here.
>
> 634 int ack_dur;
> 635 int stbc;
> 636 int i;
> 637
> 638 /* fall back to the old minstrel for legacy stations */
> 639 if (sta && !sta->ht_cap.ht_supported) {
> ^^^
> Checked here.
>
> 640 msp->is_ht = false;
> 641 memset(&msp->legacy, 0, sizeof(msp->legacy));
>
> It seems like a bug, but I'm not sure how to deal with it.
I think that sta NULL check is unnecessary there.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] minstrel_ht: remove unnecessary NULL check in minstrel_ht_update_caps
From: John W. Linville @ 2010-07-22 19:39 UTC (permalink / raw)
To: linux-wireless
Cc: Dan Carpenter, Felix Fietkau, Johannes Berg, John W. Linville
In-Reply-To: <20100722110933.GA17585@bicker>
If sta is NULL, we will have problems long before we get here...
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/rc80211_minstrel_ht.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index b5ace24..a16694b 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -636,7 +636,7 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
int i;
/* fall back to the old minstrel for legacy stations */
- if (sta && !sta->ht_cap.ht_supported) {
+ if (!sta->ht_cap.ht_supported) {
msp->is_ht = false;
memset(&msp->legacy, 0, sizeof(msp->legacy));
msp->legacy.r = msp->ratelist;
--
1.7.1.1
^ permalink raw reply related
* [PATCH] minstrel: don't complain about feedback for unrequested rates
From: John W. Linville @ 2010-07-22 19:46 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Sven Geggus, netdev, John W. Linville
In-Reply-To: <4C4896D5.8010802@openwrt.org>
"It's not problematic if minstrel gets feedback for rates that it
doesn't have in its list, it should just ignore it. - Felix"
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/rc80211_minstrel.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index f65ce6d..778c604 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -67,7 +67,6 @@ rix_to_ndx(struct minstrel_sta_info *mi, int rix)
for (i = rix; i >= 0; i--)
if (mi->r[i].rix == rix)
break;
- WARN_ON(i < 0);
return i;
}
--
1.7.1.1
^ permalink raw reply related
* Re: [patch -next] libertas: precedence bug
From: Dan Williams @ 2010-07-22 22:24 UTC (permalink / raw)
To: Dan Carpenter
Cc: John W. Linville, Holger Schurig, David S. Miller,
Amitkumar Karwar, Stephen Hemminger, libertas-dev, linux-wireless,
kernel-janitors
In-Reply-To: <20100722122102.GH17585@bicker>
On Thu, 2010-07-22 at 14:21 +0200, Dan Carpenter wrote:
> Negate has precedence over comparison so the original test was always
> false. (Neither 0 nor 1 are equal to NL80211_IFTYPE_MONITOR).
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> diff --git a/drivers/net/wireless/libertas/tx.c b/drivers/net/wireless/libertas/tx.c
> index 411a3bb..8000ca6 100644
> --- a/drivers/net/wireless/libertas/tx.c
> +++ b/drivers/net/wireless/libertas/tx.c
> @@ -180,7 +180,7 @@ void lbs_send_tx_feedback(struct lbs_private *priv, u32 try_count)
> {
> struct tx_radiotap_hdr *radiotap_hdr;
>
> - if (!priv->wdev->iftype == NL80211_IFTYPE_MONITOR ||
> + if (priv->wdev->iftype != NL80211_IFTYPE_MONITOR ||
> priv->currenttxskb == NULL)
> return;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: orphan the atmel wireless driver
From: Dan Williams @ 2010-07-22 22:28 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Simon Kelley
In-Reply-To: <1279823468-21366-1-git-send-email-linville@tuxdriver.com>
On Thu, 2010-07-22 at 14:31 -0400, John W. Linville wrote:
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Aww, how sad :(. I'll take it since I still have some of this
hardware. Not that I'll do much with it, but if the patches are simple
I'm happy to test+ack them.
Dan
> MAINTAINERS | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3148b71..2911648 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1170,11 +1170,10 @@ S: Supported
> F: drivers/usb/gadget/atmel_usba_udc.*
>
> ATMEL WIRELESS DRIVER
> -M: Simon Kelley <simon@thekelleys.org.uk>
> L: linux-wireless@vger.kernel.org
> W: http://www.thekelleys.org.uk/atmel
> W: http://atmelwlandriver.sourceforge.net/
> -S: Maintained
> +S: Orphan
> F: drivers/net/wireless/atmel*
>
> AUDIT SUBSYSTEM
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox