* PATCH ar9170usb LEDs are confused
From: Malte Gell @ 2009-10-01 4:32 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 281 bytes --]
Hello,
I first noticed the LEDs are confused, when I ran my AVM Fritz USBN N under
Windows, where the LEDs had the right order. I made a little patch that put
the assoc and the tx LEDs in the right order.
That patch was built against compat-wireless-2009-09-29.
Regards
Malte
[-- Attachment #2: ar9170-led.patch --]
[-- Type: text/x-patch, Size: 643 bytes --]
--- drivers/net/wireless/ath/ar9170/led_c_orig 2009-10-01 05:55:55.000000000 +0200
+++ drivers/net/wireless/ath/ar9170/led.c 2009-10-01 06:02:26.000000000 +0200
@@ -161,13 +161,13 @@
INIT_DELAYED_WORK(&ar->led_work, ar9170_update_leds);
- err = ar9170_register_led(ar, 0, "tx",
- ieee80211_get_tx_led_name(ar->hw));
+ err = ar9170_register_led(ar, 0, "assoc",
+ ieee80211_get_assoc_led_name(ar->hw));
if (err)
goto fail;
- err = ar9170_register_led(ar, 1, "assoc",
- ieee80211_get_assoc_led_name(ar->hw));
+ err = ar9170_register_led(ar, 1, "tx",
+ ieee80211_get_tx_led_name(ar->hw));
if (err)
goto fail;
^ permalink raw reply
* Re: [PATCH] net: fix NOHZ: local_softirq_pending 08
From: Oliver Hartkopp @ 2009-10-01 7:08 UTC (permalink / raw)
To: David Miller; +Cc: johannes, mb, kalle.valo, linville, linux-wireless, netdev
In-Reply-To: <20090930.163333.234658158.davem@davemloft.net>
David Miller wrote:
> From: Oliver Hartkopp <oliver@hartkopp.net>
> Date: Wed, 30 Sep 2009 20:18:25 +0200
>
>> Socket buffers that are generated and received inside softirqs or from process
>> context must not use netif_rx() that's intended to be used from irq context only.
>>
>> This patch introduces a new helper function netif_rx_ti(skb) that tests for
>> in_interrupt() before invoking netif_rx() or netif_rx_ni().
>>
>> It fixes the ratelimited kernel warning
>>
>> NOHZ: local_softirq_pending 08
>>
>> in the mac80211 and can subsystems.
>>
>> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
>
> I bet all of these code paths can use netif_receive_skb() or
> don't need this conditional blob at all.
>
> Looking at some specific cases in this patch:
>
> 1) VCAN: This RX routine is only invoked from the drivers
> ->ndo_start_xmit() handler, and therefore like the loopback
> driver we know that BH's are already disabled and therefore
> it can always use netif_rx() safely.
>
> Why did you convert this case?
>
> And if this needs to be converted, why doesn't loopback need
> to be?
>
> 2) af_can.c: In what situation will netif_rx_ni() not be appropriate
> here? It should always execute in softirq or user context, now
> hardirq context.
>
> And the list goes on and on, I don't really like this new conditional
> testing of interrupt state.
Hello Dave,
i'm confused about in_interrupt(), in_softirq() and in_irq() as pointed out by
Johannes here:
http://marc.info/?l=linux-wireless&m=125432410405562&w=2
Indeed in the two cases for the CAN stuff (in vcan.c and af_can.c) the skb's
are received in process-context and softirq-context only.
Therefore i used netif_rx_ni() in my last change of this code.
Now i was reading from Johannes that in_interrupt() is used for
hardirq-context /and/ softirq-context, so i was just *unsure* and used the
newly introduced netif_rx_ti() for that, which tests for in_interrupt().
Indeed i'm not really happy with that, as it is always better to check each
receive case in which context it can be used and used exactly the right
function for that.
So when netif_rx_ni() or netif_receive_skb() is the best i can use when in
process-context or in softirq-context, i'll do it with pleasure.
And if it is like this the problematic netif_rx() calls in mac80211 need to be
sorted out in detail also ...
Regards,
Oliver
^ permalink raw reply
* Re: [PATCH v2] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Holger Schurig @ 2009-10-01 7:42 UTC (permalink / raw)
To: Bing Zhao; +Cc: libertas-dev, linux-wireless, Amitkumar Karwar
In-Reply-To: <1254366278-15483-1-git-send-email-bzhao@marvell.com>
> Tests have been done for USB/CS cards to make sure that the patch
> won't break USB/CS code.
Side question: which firmware are you using on CS cards?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: unused header file drivers/net/wireless/wl12xx/wl1251_netlink.h?
From: Kalle Valo @ 2009-10-01 7:49 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: linux-wireless
In-Reply-To: <alpine.LFD.2.00.0909301554001.21753@localhost>
"Robert P. J. Day" <rpjday@crashcourse.ca> writes:
> as best i can tell, that header file is entirely unreferenced by
> anything in the tree. just an observation.
Yes, it's unused. I added it accidentally a long time ago when I
rebased a big pile of patches. I'll send a patch to remove it.
Thanks for reporting this.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH]: nl80211: report age of scan results
From: Holger Schurig @ 2009-10-01 7:57 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John Linville, linux-wireless, Johannes Berg
In-Reply-To: <20090930212123.GA8616@jm.kir.nu>
> If anyone gets interested enough in trying to figure out whether
> scan results are from the time after the last scan (more exactly than
> just guessing based on age), he/she can add that later and probably
> using something like a sequence number for scan requests, etc.
Hmm, what would a scan-sequence help in the case when mac80211 updates
a BSS because of a received beacon?
E.g.:
scan trigger, seq 5:
find AP 'XXX', signal -50
find AP 'YYY', signal -60
scan trigger, seq 6:
find AP 'ZZZ', signal -55
normal operation:
beacon for 'YYY' comes in, signal -45
scan-dump:
get 'XXX', signal -50, seq 5
get 'ZZZ', signal -55, seq 6
get 'YYY', signal -45, but with which seq?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: driver_nl80211 broken again
From: Johannes Berg @ 2009-10-01 8:46 UTC (permalink / raw)
To: Jouni Malinen; +Cc: Maxim Levitsky, hostap@lists.shmoo.com, linux-wireless
In-Reply-To: <20090930221353.GB11052@jm.kir.nu>
[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]
On Thu, 2009-10-01 at 01:13 +0300, Jouni Malinen wrote:
> > @@ -1302,8 +1302,10 @@ void wpa_supplicant_disassociate(struct wpa_supplicant *wpa_s,
> > wpa_drv_disassociate(wpa_s, wpa_s->bssid, reason_code);
> > + wpa_drv_deauthenticate(wpa_s, wpa_s->bssid, reason_code);
>
> To me, this looks broken. When wpa_supplicant requests a
> disassociastion, it is _only_ asking for disassociation, not
> deauthentication. cfg80211/mac80211 may not currently handle that, but
> as far as I can tell, it sounds like an issue there and not in
> wpa_supplicant. Johannes may disagree with this, though.
cfg80211/mac80211 _do_ handle that. If you ask for disassociation, it
stays authenticated, and later expects you to still remember that and
refuses authentication since you're already authenticated.
> I don't think either of those options would be acceptable for
> wpa_supplicant and the correct fix is to make cfg80211/mac80211 be able
> to handle authentication to a STA that is already authenticated. If
> that is not acceptable, this hack needs to be hidden in driver_nl80211.c
> instead of polluting core wpa_supplicant code which is supposed to be
> driver independent. In other words, make driver_nl80211.c deauth if auth
> fails and then try auth again. I don't really like that much, but if
> this needs to be worked around in wpa_supplicant, that is the most
> likely place where such a change could be considered.
I still don't see how it makes sense to authenticate while still being
authenticated.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] wireless: implement basic ethtool support for cfg80211 devices
From: Johannes Berg @ 2009-10-01 8:51 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, netdev, Kalle Valo, Kalle Valo, Luis R. Rodriguez
In-Reply-To: <1254359942-3483-1-git-send-email-linville@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
On Wed, 2009-09-30 at 21:19 -0400, John W. Linville wrote:
> + if (!dev->ethtool_ops)
> + dev->ethtool_ops = &cfg80211_ethtool_ops;
> break;
I might go so far and do it unconditionally so we get consistent
functionality across things. OTOH, full-mac drivers might be able to
support more.
> +const struct ethtool_ops cfg80211_ethtool_ops = {
> + .get_drvinfo = cfg80211_get_drvinfo,
> + .get_link = ethtool_op_get_link,
> +};
> +
> +void cfg80211_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
if you change the order, you can make the latter static
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [SOLVED][.32-rc1/2] ath5k: has become unreliable with .32-rc1
From: Johannes Berg @ 2009-10-01 8:52 UTC (permalink / raw)
To: Frans Pop; +Cc: linux-wireless, linux-kernel, Bob Copeland, Rafael J. Wysocki
In-Reply-To: <200910010235.28904.elendil@planet.nl>
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
On Thu, 2009-10-01 at 02:35 +0200, Frans Pop wrote:
> the boot issue by one of Johannes' patches (I'd guess either
> 4be3bd8c 'cfg80211: don't set privacy w/o key' or maybe 8bb89485
> 'cfg80211: always get BSS').
Nah, it's going to be the "add back wireless/ dir" patch.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* b43: fix wldev use after free
From: Dave Young @ 2009-10-01 8:49 UTC (permalink / raw)
To: mb, linville; +Cc: bcm43xx-dev, linux-wireless, linux-kernel
when rmmod b43, I got following bug message
[ 100.121798] BUG: unable to handle kernel paging request at 2f4066fa
[ 100.123338] IP: [<f9e9dd57>] b43_unregister_led+0x6/0x1c [b43]
[ 100.123338] *pde = 00000000
[ 100.123338] Oops: 0000 [#1] SMP
[ 100.123338] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.1/0000:0c:00.0/ssb0:0/firmware/ssb0:0/loading
[ 100.123338] Modules linked in: reiserfs kvm_intel kvm snd_hda_codec_intelhdmi firewire_ohci snd_hda_codec_idt firewire_core b43(-) snd_hda_intel mac80211 snd_hda_codec crc_itu_t cfg80211 snd_hwdep ohci1394 snd_pcm dell_laptop wmi ieee1394 rfkill snd_timer snd_page_alloc
[ 100.123338]
[ 100.123338] Pid: 1931, comm: rmmod Not tainted (2.6.31-mm1 #2) Latitude E5400
[ 100.123338] EIP: 0060:[<f9e9dd57>] EFLAGS: 00010246 CPU: 0
[ 100.123338] EIP is at b43_unregister_led+0x6/0x1c [b43]
[ 100.123338] EAX: 2f4066fa EBX: 2f4066fa ECX: 00000006 EDX: 00000246
[ 100.123338] ESI: f6a59000 EDI: f72030a8 EBP: f6373ec8 ESP: f6373ec4
[ 100.123338] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[ 100.123338] Process rmmod (pid: 1931, ti=f6372000 task=f66e0000 task.ti=f6372000)
[ 100.123338] Stack:
[ 100.123338] 2f406576 f6373ed4 f9e9dd7f f674cda0 f6373ee8 f9e8816e f72030a8 f9ea4b18
[ 100.123338] <0> f9ea4b18 f6373ef4 c04bbd57 f7297000 f6373f04 c03f2563 f7297000 f7297034
[ 100.123338] <0> f6373f18 c03f2609 f9ea4b18 00000000 c07742fc f6373f2c c03f1aac 00000000
[ 100.123338] Call Trace:
[ 100.123338] [<f9e9dd7f>] ? b43_leds_unregister+0x12/0x36 [b43]
[ 100.123338] [<f9e8816e>] ? b43_remove+0x79/0x87 [b43]
[ 100.123338] [<c04bbd57>] ? ssb_device_remove+0x1d/0x29
[ 100.123338] [<c03f2563>] ? __device_release_driver+0x59/0x98
[ 100.123338] [<c03f2609>] ? driver_detach+0x67/0x85
[ 100.123338] [<c03f1aac>] ? bus_remove_driver+0x63/0x7f
[ 100.123338] [<c03f2a04>] ? driver_unregister+0x4d/0x54
[ 100.123338] [<c04bb828>] ? ssb_driver_unregister+0xb/0xd
[ 100.123338] [<f9e9f876>] ? b43_exit+0xd/0x19 [b43]
[ 100.123338] [<c025124b>] ? sys_delete_module+0x17c/0x1e0
[ 100.123338] [<c054c654>] ? do_page_fault+0x29d/0x2a5
[ 100.123338] [<c02032d6>] ? restore_all_notrace+0x0/0x18
[ 100.123338] [<c054c3b7>] ? do_page_fault+0x0/0x2a5
[ 100.123338] [<c020329d>] ? syscall_call+0x7/0xb
[ 100.123338] Code: 0f b6 93 d8 03 00 00 e8 16 ff ff ff 0f b6 8b 39 03 00 00 89 f0 0f b6 93 38 03 00 00 e8 01 ff ff ff 5b 5e 5d c3 55 89 e5 53 89 c3 <83> 38 00 74 0e 8d 40 04 e8 de cc 60 c6 c7 03 00 00 00 00 5b 5d
[ 100.123338] EIP: [<f9e9dd57>] b43_unregister_led+0x6/0x1c [b43] SS:ESP 0068:f6373ec4
[ 100.123338] CR2: 000000002f4066fa
[ 100.953375] ---[ end trace d100c06b1451fbd8 ]---
in b43_remove, b43_one_core_detach free the wldev,
thus following callback which reference wldev will oops.
fix it by call b43_leds_unregister before b43_one_core_detach
if it is the last one in wl->devlist
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
---
drivers/net/wireless/b43/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.31.orig/drivers/net/wireless/b43/main.c 2009-10-01 16:17:00.000000000 +0800
+++ linux-2.6.31/drivers/net/wireless/b43/main.c 2009-10-01 16:37:41.000000000 +0800
@@ -4993,11 +4993,13 @@ static void b43_remove(struct ssb_device
ieee80211_unregister_hw(wl->hw);
}
+ if (list_is_last(&wldev->list, &wl->devlist))
+ b43_leds_unregister(wldev);
+
b43_one_core_detach(dev);
if (list_empty(&wl->devlist)) {
b43_rng_exit(wl);
- b43_leds_unregister(wldev);
/* Last core on the chip unregistered.
* We can destroy common struct b43_wl.
*/
^ permalink raw reply
* BUG: "wext: refactor" broke compilation
From: Holger Schurig @ 2009-10-01 9:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
LD net/wireless/built-in.o
CC [M] net/wireless/core.o
net/wireless/core.c: In function 'cfg80211_netdev_notifier_call':
net/wireless/core.c:673: error: 'struct wireless_dev' has no member named 'wext'
net/wireless/core.c:674: error: 'struct wireless_dev' has no member named 'wext'
net/wireless/core.c:675: error: 'struct wireless_dev' has no member named 'wext'
net/wireless/core.c:676: error: 'struct wireless_dev' has no member named 'wext'
net/wireless/core.c:677: error: 'struct wireless_dev' has no member named 'wext'
net/wireless/core.c:680: error: 'struct wireless_dev' has no member named 'wext'
net/wireless/core.c:681: error: 'struct wireless_dev' has no member named 'wext'
net/wireless/core.c:683: error: 'struct wireless_dev' has no member named 'wext'
The reason is that currently two different Kconfig
defines are used:
in net/wireless/core.c:
#ifdef CONFIG_WIRELESS_EXT
wdev->wext.default_key = -1;
...
#endif
in include/net/cfg80211.h:
#ifdef CONFIG_CFG80211_WEXT
/* wext data */
struct {
...
} wext;
#endif
But I configure my kernel this way:
$ grep WIRELESS .config
CONFIG_WIRELESS=y
CONFIG_WIRELESS_EXT=y
...
$ grep WEXT .config
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
# CONFIG_CFG80211_WEXT is not set
--
http://www.holgerschurig.de
^ permalink raw reply
* Linux-2.6.32-rc1/2] wext refactor needs wpasupplicant 0.7.0+?
From: Sedat Dilek @ 2009-10-01 9:47 UTC (permalink / raw)
To: wireless; +Cc: Johannes Berg
Hi,
a few hours ago I compiled a new kernel from upstream and put
wireless-testing master-2009-09-30 on top of it.
Last commit a1bec0ecfc76281d5e1ebd33435c67da7dd0fe71
wext: refactor
linux-2.6/master:
84d88d5: Merge branch 'sched-fixes-for-linus' of
git://git./linux/kernel/git/tip/linux-2.6-tip
After installation of the above described kernel, I could not connect
to my AP using wext driver and wpasupplicant (0.6.9-3) from Debian/sid
[1].
With ath5k I could not establish a network connection neither via DHCP
nor via static-IP to my AP (iwl3945 on a second machine works with
self-debianized wpasupplicant 0.7.0+ and static-IP, same kernel).
Just for clarification:
Does wext refactor need a wpasupplicant >= 0.7.0 from hostap GIT repository [2]?
Below you will find some needful informations of my configuration and system.
Kind Regards,
- Sedat -
P.S.:
I can offer a debianized wpasupplicant package for 32bit, if you like.
[1] http://packages.debian.org/sid/wpasupplicant
[2] http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=summary
---- NEEDFUL INFORMATIONS ----
# lspci -nnvv | grep -i ath
02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
802.11abg NIC [168c:1014] (rev 01)
Kernel driver in use: ath5k
# ps axu | grep -v grep | grep wpa
root 1411 0.0 0.1 4916 1124 ? Ss 10:59 0:00
/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0
-D wext -C /var/run/wpa_supplicant
# wpa_cli -iwlan0 status
bssid=00:04:0e:e4:00:3d
ssid=$mySSID
id=0
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=$myIPADDR
# cat /proc/version
Linux version 2.6.32-rc1-iniza-686-kms (Debian 2.6.32~rc1-5)
(sedat.dilek@gmail.com) (gcc version 4.4.1 (Debian 4.4.1-4) ) #1 SMP
PREEMPT Thu Oct 1 04:57:49 CEST 2009
^ permalink raw reply
* [PATCH] wl1251: remove wl1251_netlink.h
From: Kalle Valo @ 2009-10-01 9:51 UTC (permalink / raw)
To: linux-wireless
From: Kalle Valo <kalle.valo@nokia.com>
The file was accidentally added in commit ef2f8d4577 ("wl1251: add
wl1251 prefix to all 1251 files"). This happened when I rebased the
patches from a private tree.
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
---
drivers/net/wireless/wl12xx/wl1251_netlink.h | 30 --------------------------
1 files changed, 0 insertions(+), 30 deletions(-)
delete mode 100644 drivers/net/wireless/wl12xx/wl1251_netlink.h
diff --git a/drivers/net/wireless/wl12xx/wl1251_netlink.h b/drivers/net/wireless/wl12xx/wl1251_netlink.h
deleted file mode 100644
index ee36695..0000000
--- a/drivers/net/wireless/wl12xx/wl1251_netlink.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * This file is part of wl1251
- *
- * Copyright (C) 2009 Nokia Corporation
- *
- * Contact: Kalle Valo <kalle.valo@nokia.com>
- *
- * 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.
- *
- * 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., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#ifndef __WL1251_NETLINK_H__
-#define __WL1251_NETLINK_H__
-
-int wl1251_nl_register(void);
-void wl1251_nl_unregister(void);
-
-#endif /* __WL1251_NETLINK_H__ */
^ permalink raw reply related
* Re: Linux-2.6.32-rc1/2] wext refactor needs wpasupplicant 0.7.0+?
From: Sedat Dilek @ 2009-10-01 10:15 UTC (permalink / raw)
To: wireless; +Cc: Johannes Berg
In-Reply-To: <2d0a357f0910010247jfda1199h5a9b873233b186ca@mail.gmail.com>
For the sake of completeness:
Herre the WEXT config parameters in kernel dot-config:
# grep -i wext /boot/config-$(uname -r)
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
CONFIG_CFG80211_WEXT=y
- Sedat -
On Thu, Oct 1, 2009 at 11:47 AM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> Hi,
>
> a few hours ago I compiled a new kernel from upstream and put
> wireless-testing master-2009-09-30 on top of it.
>
> Last commit a1bec0ecfc76281d5e1ebd33435c67da7dd0fe71
> wext: refactor
>
> linux-2.6/master:
> 84d88d5: Merge branch 'sched-fixes-for-linus' of
> git://git./linux/kernel/git/tip/linux-2.6-tip
>
> After installation of the above described kernel, I could not connect
> to my AP using wext driver and wpasupplicant (0.6.9-3) from Debian/sid
> [1].
> With ath5k I could not establish a network connection neither via DHCP
> nor via static-IP to my AP (iwl3945 on a second machine works with
> self-debianized wpasupplicant 0.7.0+ and static-IP, same kernel).
>
> Just for clarification:
> Does wext refactor need a wpasupplicant >= 0.7.0 from hostap GIT repository [2]?
>
> Below you will find some needful informations of my configuration and system.
>
> Kind Regards,
> - Sedat -
>
> P.S.:
> I can offer a debianized wpasupplicant package for 32bit, if you like.
>
> [1] http://packages.debian.org/sid/wpasupplicant
> [2] http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=summary
>
> ---- NEEDFUL INFORMATIONS ----
>
> # lspci -nnvv | grep -i ath
> 02:02.0 Ethernet controller [0200]: Atheros Communications Inc. AR5212
> 802.11abg NIC [168c:1014] (rev 01)
> Kernel driver in use: ath5k
>
> # ps axu | grep -v grep | grep wpa
> root 1411 0.0 0.1 4916 1124 ? Ss 10:59 0:00
> /sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0
> -D wext -C /var/run/wpa_supplicant
>
> # wpa_cli -iwlan0 status
> bssid=00:04:0e:e4:00:3d
> ssid=$mySSID
> id=0
> pairwise_cipher=CCMP
> group_cipher=CCMP
> key_mgmt=WPA2-PSK
> wpa_state=COMPLETED
> ip_address=$myIPADDR
>
> # cat /proc/version
> Linux version 2.6.32-rc1-iniza-686-kms (Debian 2.6.32~rc1-5)
> (sedat.dilek@gmail.com) (gcc version 4.4.1 (Debian 4.4.1-4) ) #1 SMP
> PREEMPT Thu Oct 1 04:57:49 CEST 2009
>
^ permalink raw reply
* Re: [PATCH]: nl80211: report age of scan results
From: Jouni Malinen @ 2009-10-01 12:40 UTC (permalink / raw)
To: Holger Schurig; +Cc: John Linville, linux-wireless, Johannes Berg
In-Reply-To: <200910010957.31558.hs4233@mail.mn-solutions.de>
On Thu, Oct 01, 2009 at 09:57:31AM +0200, Holger Schurig wrote:
> Hmm, what would a scan-sequence help in the case when mac80211 updates
> a BSS because of a received beacon?
I have been most interested in knowing whether the result was after the
scan request or not; not necessarily receiving during the scan request
itself.
> scan trigger, seq 5:
> find AP 'XXX', signal -50
> find AP 'YYY', signal -60
> scan trigger, seq 6:
> find AP 'ZZZ', signal -55
> normal operation:
> beacon for 'YYY' comes in, signal -45
> scan-dump:
> get 'XXX', signal -50, seq 5
> get 'ZZZ', signal -55, seq 6
> get 'YYY', signal -45, but with which seq?
seq 6 based on the earlier discussion. However, there would be an option
to increment the sequence number whenever a scan is terminated, i.e.,
the move to normal operation would move to seq 7 and 'YYY' would
actually show up with seq 7 here. The scan trigger command would return
the sequence number for that particular scan (6 for the second one), so
it would be possible to notice the difference between ZZZ and YYY.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH] b43: Don't use struct wldev after detach.
From: Michael Buesch @ 2009-10-01 13:54 UTC (permalink / raw)
To: linville; +Cc: bcm43xx-dev, linux-wireless
Don't use struct wldev after detach. This fixes an oops on access.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
drivers/net/wireless/b43/leds.c | 4 ++--
drivers/net/wireless/b43/leds.h | 4 ++--
drivers/net/wireless/b43/main.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/b43/leds.c
+++ wireless-testing/drivers/net/wireless/b43/leds.c
@@ -348,9 +348,9 @@ void b43_leds_register(struct b43_wldev
}
}
-void b43_leds_unregister(struct b43_wldev *dev)
+void b43_leds_unregister(struct b43_wl *wl)
{
- struct b43_leds *leds = &dev->wl->leds;
+ struct b43_leds *leds = &wl->leds;
b43_unregister_led(&leds->led_tx);
b43_unregister_led(&leds->led_rx);
--- wireless-testing.orig/drivers/net/wireless/b43/leds.h
+++ wireless-testing/drivers/net/wireless/b43/leds.h
@@ -60,7 +60,7 @@ enum b43_led_behaviour {
};
void b43_leds_register(struct b43_wldev *dev);
-void b43_leds_unregister(struct b43_wldev *dev);
+void b43_leds_unregister(struct b43_wl *wl);
void b43_leds_init(struct b43_wldev *dev);
void b43_leds_exit(struct b43_wldev *dev);
void b43_leds_stop(struct b43_wldev *dev);
@@ -76,7 +76,7 @@ struct b43_leds {
static inline void b43_leds_register(struct b43_wldev *dev)
{
}
-static inline void b43_leds_unregister(struct b43_wldev *dev)
+static inline void b43_leds_unregister(struct b43_wl *wl)
{
}
static inline void b43_leds_init(struct b43_wldev *dev)
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wireless-testing/drivers/net/wireless/b43/main.c
@@ -4997,7 +4997,7 @@ static void b43_remove(struct ssb_device
if (list_empty(&wl->devlist)) {
b43_rng_exit(wl);
- b43_leds_unregister(wldev);
+ b43_leds_unregister(wl);
/* Last core on the chip unregistered.
* We can destroy common struct b43_wl.
*/
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] net: fix NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-10-01 14:04 UTC (permalink / raw)
To: David Miller
Cc: oliver, johannes, kalle.valo, linville, linux-wireless, netdev
In-Reply-To: <20090930.163333.234658158.davem@davemloft.net>
On Thursday 01 October 2009 01:33:33 David Miller wrote:
> I'm not applying this until all of these details are sorted out
John, please apply my fix to wireless-testing to get rid of the regression.
You can revert it later, if there's a better fix available.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: Kalle Valo @ 2009-10-01 14:18 UTC (permalink / raw)
To: John W. Linville; +Cc: Luis R. Rodriguez, linux-wireless, netdev
In-Reply-To: <20091001011340.GA3123@tuxdriver.com>
"John W. Linville" <linville@tuxdriver.com> writes:
> On Fri, Sep 25, 2009 at 09:53:35AM -0700, Luis R. Rodriguez wrote:
>
>> So for Wake-on-Wireless I ran into the same, ethtool just did not
>> offer the same wake up events needed for wireless. I could have
>> technically used ethtool and expanded it to support wireless but it
>> just seemed dirty.
>>
>> I agree that using ethtool seems overkill compared to the patches
>> you posted.
>
> I think you either overestimate the amount of trouble for implementing
> (minimal) ethtool support or you underestimate the amount of
> functionality available through that interface.
I'm not worried about the implementation complexity, and as your
patches show it was easy. My concern is the overall design for
wireless devices. Instead of using nl80211 for everything, with some
features we would use nl80211/iw and with some ethtool. That's just
confusing and I don't like that. I would prefer that nl80211 provides
everything, it makes things so much easier.
> That, or you just don't like using something named "eth"tool for
> wireless -- but hey, let's be honest about the frames we
> send/receive to/from the kernel... :-)
I don't have a problem with the name :) But ethernet is still so much
different from 802.11 that there isn't that much to share and we in
wireless will need different features.
One example is the hw version, ethtool only provides u32 to userspace
and moves the burden of translating hw id to the user. For us a string
is much better choise because when debuggin we need to often (or
always?) know the chip version.
But this is not something I will start fighting about. If you still
think that ethtool is the way to go, I'm perfectly fine with it.
>> The ethtool interface provides functionality for viewing and modifying
> eeprom contents, dumping registers, trigger self-tests, basic driver
> info, getting and setting message reporting levels, external card
> identification (hey, _could_ be useful!), and some other bits like
> checksum offload that might(?) be useful in the future. I understand
> regarding the WoW vs. WoL issue but probably the answer is just to
> add a new method for WoW...?
I took a look at ethtool help output from debian unstable and I think
this is the set of features we can use in wireless:
ethtool -i|--driver DEVNAME Show driver information
ethtool -d|--register-dump DEVNAME Do a register dump
[ raw on|off ]
[ file FILENAME ]
ethtool -e|--eeprom-dump DEVNAME Do a EEPROM dump
[ raw on|off ]
[ offset N ]
[ length N ]
ethtool -E|--change-eeprom DEVNAME Change bytes in device
EEPROM
[ magic N ]
[ offset N ]
[ value N ]
ethtool -p|--identify DEVNAME Show visible port
identification (e.g. blinking)
[ TIME-IN-SECONDS ]
ethtool -t|--test DEVNAME Execute adapter self test
[ online | offline ]
But here are the features which I doubt we will ever use:
ethtool -s|--change DEVNAME Change generic options
[ speed %%d ]
[ duplex half|full ]
[ port tp|aui|bnc|mii|fibre ]
[ autoneg on|off ]
[ advertise %%x ]
[ phyad %%d ]
[ xcvr internal|external ]
[ wol p|u|m|b|a|g|s|d... ]
[ sopass %%x:%%x:%%x:%%x:%%x:%%x ]
[ msglvl %%d ]
ethtool -a|--show-pause DEVNAME Show pause options
ethtool -A|--pause DEVNAME Set pause options
[ autoneg on|off ]
[ rx on|off ]
[ tx on|off ]
ethtool -c|--show-coalesce DEVNAME Show coalesce options
ethtool -C|--coalesce DEVNAME Set coalesce options
[adaptive-rx on|off]
[adaptive-tx on|off]
[rx-usecs N]
[rx-frames N]
[rx-usecs-irq N]
[rx-frames-irq N]
[tx-usecs N]
[tx-frames N]
[tx-usecs-irq N]
[tx-frames-irq N]
[stats-block-usecs N]
[pkt-rate-low N]
[rx-usecs-low N]
[rx-frames-low N]
[tx-usecs-low N]
[tx-frames-low N]
[pkt-rate-high N]
[rx-usecs-high N]
[rx-frames-high N]
[tx-usecs-high N]
[tx-frames-high N]
[sample-interval N]
ethtool -g|--show-ring DEVNAME Query RX/TX ring parameters
ethtool -G|--set-ring DEVNAME Set RX/TX ring parameters
[ rx N ]
[ rx-mini N ]
[ rx-jumbo N ]
[ tx N ]
ethtool -k|--show-offload DEVNAME Get protocol offload
information
ethtool -K|--offload DEVNAME Set protocol offload
[ rx on|off ]
[ tx on|off ]
[ sg on|off ]
[ tso on|off ]
[ ufo on|off ]
[ gso on|off ]
[ gro on|off ]
[ lro on|off ]
ethtool -r|--negotiate DEVNAME Restart N-WAY negotation
ethtool -n|--show-nfc DEVNAME Show Rx network flow
classificationoptions
[ rx-flow-hash
tcp4|udp4|ah4|sctp4|tcp6|udp6|ah6|sctp6 ]
ethtool -N|--config-nfc DEVNAME Configure Rx network flow
classification options
[ rx-flow-hash tcp4|udp4|ah4|sctp4|tcp6|udp6|ah6|sctp6
m|v|t|s|d|f|n|r... ]
--
Kalle Valo
^ permalink raw reply
* Re: BUG: "wext: refactor" broke compilation
From: Johannes Berg @ 2009-10-01 14:23 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910011139.30914.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
On Thu, 2009-10-01 at 11:39 +0200, Holger Schurig wrote:
> LD net/wireless/built-in.o
> CC [M] net/wireless/core.o
> net/wireless/core.c: In function 'cfg80211_netdev_notifier_call':
> net/wireless/core.c:673: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:674: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:675: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:676: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:677: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:680: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:681: error: 'struct wireless_dev' has no member named 'wext'
> net/wireless/core.c:683: error: 'struct wireless_dev' has no member named 'wext'
>
> The reason is that currently two different Kconfig
> defines are used:
>
>
> in net/wireless/core.c:
>
> #ifdef CONFIG_WIRELESS_EXT
> wdev->wext.default_key = -1;
> ...
> #endif
Oops, yes, that one needs to be fixed. I thought I just used sed but I
guess somehow I managed to miss this one.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] net: fix NOHZ: local_softirq_pending 08
From: Kalle Valo @ 2009-10-01 14:24 UTC (permalink / raw)
To: Michael Buesch
Cc: David Miller, oliver, johannes, linville, linux-wireless, netdev
In-Reply-To: <200910011604.42916.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> writes:
> On Thursday 01 October 2009 01:33:33 David Miller wrote:
>
>> I'm not applying this until all of these details are sorted out
>
> John, please apply my fix to wireless-testing to get rid of the
> regression. You can revert it later, if there's a better fix
> available.
I agree, please take Michael's patch. It's trivial to change mac80211
part whenever there's better support available.
But I don't think this is a regression because I see the bug also with
2.6.28, most probably it has been in mac80211 forever. But it's still
a bug which needs to be fixed.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 3/3] at76c50x-usb: set firmware and hardware version in wiphy
From: Kalle Valo @ 2009-10-01 14:27 UTC (permalink / raw)
To: Ben Hutchings; +Cc: John W. Linville, linux-wireless, netdev, Luis R. Rodriguez
In-Reply-To: <1254360747.23350.2.camel@localhost>
Ben Hutchings <bhutchings@solarflare.com> writes:
> On Wed, 2009-09-30 at 21:19 -0400, John W. Linville wrote:
> [...]
>> + len = sizeof(wiphy->fw_version);
>> + snprintf(wiphy->fw_version, len, "%d.%d.%d-%d",
>> + priv->fw_version.major, priv->fw_version.minor,
>> + priv->fw_version.patch, priv->fw_version.build);
>> + /* null terminate the strings in case they were truncated */
>> + wiphy->fw_version[len - 1] = '\0';
> [...]
>
> This last statement is unnecessary; snprintf() always null-terminates
> (unless the length is zero).
Yes, the extra null termination is unnecessary. This was my mistake in
the first patchset I sent.
--
Kalle Valo
^ permalink raw reply
* Re: VLAN traffic appearing on the wrong iface
From: Blaž Bačnik @ 2009-10-01 14:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1254341787.3959.11.camel@johannes.local>
On Wed, Sep 30, 2009 at 10:16 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> I can't reproduce that oops, but we have a fix to the issue which I'll
> send separately.
Thanks for patches. However, I've investigated that oops and I don't really
understand it. Problem seems to be in __sta_info_unlink where code checks
if vif is a mesh. Since this is a vlan iface, sdata used actually belongs to ap
iface due to previous if but that really shouldn't be a problem since ap's
sdata should have vif->type as well, right?
While testing I've found out that sdata_of_ap->vif points to funny addresses
like 248 and such. So I've changed the code and that seems to have fixed
oops. I think this is now the right behaviour, anyway.
--- a/net/mac80211/sta_info.c 2009-10-01 16:27:31.000000000 +0200
+++ b/net/mac80211/sta_info.c 2009-10-01 16:24:34.000000000 +0200
@@ -498,7 +498,7 @@ static void __sta_info_unlink(struct sta
&(*sta)->sta);
}
- if (ieee80211_vif_is_mesh(&(*sta)->sdata->vif)) {
+ if (ieee80211_vif_is_mesh(&sdata->vif)) {
mesh_accept_plinks_update(sdata);
#ifdef CONFIG_MAC80211_MESH
del_timer(&(*sta)->plink_timer);
^ permalink raw reply
* Re: VLAN traffic appearing on the wrong iface
From: Blaž Bačnik @ 2009-10-01 14:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <57b62e7d0910010732m38ab57k916662f9047fcc91@mail.gmail.com>
Meh, I messed up the patch. Take two, hopefully better. Sorry.
Regards, Blaz
--- a/net/mac80211/sta_info.c 2009-10-01 16:24:34.000000000 +0200
+++ b/net/mac80211/sta_info.c 2009-10-01 16:27:31.000000000 +0200
@@ -498,7 +498,7 @@ static void __sta_info_unlink(struct sta
&(*sta)->sta);
}
- if (ieee80211_vif_is_mesh(&sdata->vif)) {
+ if (ieee80211_vif_is_mesh(&(*sta)->sdata->vif)) {
mesh_accept_plinks_update(sdata);
#ifdef CONFIG_MAC80211_MESH
del_timer(&(*sta)->plink_timer);
On Thu, Oct 1, 2009 at 4:32 PM, Blaž Bačnik <bacnik@gmail.com> wrote:
> On Wed, Sep 30, 2009 at 10:16 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> I can't reproduce that oops, but we have a fix to the issue which I'll
>> send separately.
>
> Thanks for patches. However, I've investigated that oops and I don't really
> understand it. Problem seems to be in __sta_info_unlink where code checks
> if vif is a mesh. Since this is a vlan iface, sdata used actually belongs to ap
> iface due to previous if but that really shouldn't be a problem since ap's
> sdata should have vif->type as well, right?
>
> While testing I've found out that sdata_of_ap->vif points to funny addresses
> like 248 and such. So I've changed the code and that seems to have fixed
> oops. I think this is now the right behaviour, anyway.
>
> --- a/net/mac80211/sta_info.c 2009-10-01 16:27:31.000000000 +0200
> +++ b/net/mac80211/sta_info.c 2009-10-01 16:24:34.000000000 +0200
> @@ -498,7 +498,7 @@ static void __sta_info_unlink(struct sta
> &(*sta)->sta);
> }
>
> - if (ieee80211_vif_is_mesh(&(*sta)->sdata->vif)) {
> + if (ieee80211_vif_is_mesh(&sdata->vif)) {
> mesh_accept_plinks_update(sdata);
> #ifdef CONFIG_MAC80211_MESH
> del_timer(&(*sta)->plink_timer);
>
^ permalink raw reply
* Re: [PATCH] ar9170usb: LEDs are confused
From: Christian Lamparter @ 2009-10-01 14:54 UTC (permalink / raw)
To: Malte Gell; +Cc: linux-wireless, Luis R. Rodriguez, linville
On 2009-10-01 06:32 AM, Malte Gell wrote:
>I first noticed the LEDs are confused,
no, the LED colors is not _confused_ at all.
This is simply different on.... well, you know: on a per-device base!
For example: The Netgear uses a single bi-color LED for their WNDA3100 stick.
It glows blue or/and orange depending on the selected band and current
operation mode and state...
No idea why they didn't stick to the usual red/green mix.
Maybe because someone told the hw-devs about the existence of
red/green colorblind people??!
The original vendor driver (located: drivers/staging/otus/80211core/ledmgr.c)
goes to great lengths to describe what's behind the variety of
blinking signals. Which is nice, if you like expensive light shows...
>when I ran my AVM Fritz USBN N under Windows,
>where the LEDs had the right order. I made a little patch that put
>the assoc and the tx LEDs in the right order.
FYI: you can assign the LEDs under "/sys/class/leds/" with a different tigger
without messing with the kernel source... An up-to-date README can be found in
the kernel's documentation directory: Documentation/leds-class.txt ,
or you can look it up online as well:
http://www.mjmwired.net/kernel/Documentation/leds-class.txt (from 2.6.31)
but back to the patch and the problem with the wide diversity of
over-customized solutions for a direct feedback mechanism to the
mindful human operator...
what about the (inline) _attached_ approach?
Sure, this idea needs some more code... but, it covers all/most
possible scenarios from beloved "no, no, no" vendors.
---
From: Christian Lamparter <chunkeey@googlemail.com>
Subject: [PATCH] ar9170usb: flexible LED mapping
This patch adds two more quirk flags which are useful to:
- reduce the number of virtual/ghost LEDs
( for low-budget devices: Netgear WN111 v2 )
- select an alternative LED mapping.
( for AVM FRITZ!WLAN USB Stick N )
Reported-by: Malte Gell <malte.gell@gmx.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/drivers/net/wireless/ath/ar9170/ar9170.h b/drivers/net/wireless/ath/ar9170/ar9170.h
index ec034af..a451bb1 100644
--- a/drivers/net/wireless/ath/ar9170/ar9170.h
+++ b/drivers/net/wireless/ath/ar9170/ar9170.h
@@ -155,6 +155,12 @@ struct ar9170_sta_tid {
#define AR9170_NUM_TX_STATUS 128
#define AR9170_NUM_TX_AGG_MAX 30
+enum ar9170_quirks {
+ AR9170_REQ_FW1_ONLY = BIT(0),
+ AR9170_ONLY_ONE_LED = BIT(1),
+ AR9170_SWAPPED_LEDS = BIT(2),
+};
+
struct ar9170 {
struct ieee80211_hw *hw;
struct ath_common common;
@@ -241,6 +247,9 @@ struct ar9170 {
/* (cached) HW A-MPDU settings */
u8 global_ampdu_density;
u8 global_ampdu_factor;
+
+ /* device quirks */
+ unsigned long quirks;
};
struct ar9170_sta_info {
diff --git a/drivers/net/wireless/ath/ar9170/led.c b/drivers/net/wireless/ath/ar9170/led.c
index 86c4e79..36ab738 100644
--- a/drivers/net/wireless/ath/ar9170/led.c
+++ b/drivers/net/wireless/ath/ar9170/led.c
@@ -155,18 +155,30 @@ void ar9170_unregister_leds(struct ar9170 *ar)
cancel_delayed_work_sync(&ar->led_work);
}
+const static int std_led_map[AR9170_NUM_LEDS] = { 0, 1 };
+const static int avm_led_map[AR9170_NUM_LEDS] = { 1, 0 };
+
int ar9170_register_leds(struct ar9170 *ar)
{
+ const int *led_map;
int err;
+ if (ar->quirks & AR9170_SWAPPED_LEDS)
+ led_map = avm_led_map;
+ else
+ led_map = std_led_map;
+
INIT_DELAYED_WORK(&ar->led_work, ar9170_update_leds);
- err = ar9170_register_led(ar, 0, "tx",
+ err = ar9170_register_led(ar, led_map[0], "tx",
ieee80211_get_tx_led_name(ar->hw));
if (err)
goto fail;
- err = ar9170_register_led(ar, 1, "assoc",
+ if (ar->quirks & AR9170_ONLY_ONE_LED)
+ return 0;
+
+ err = ar9170_register_led(ar, led_map[1], "assoc",
ieee80211_get_assoc_led_name(ar->hw));
if (err)
goto fail;
diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index e974e58..3be19e4 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -55,10 +55,6 @@ MODULE_FIRMWARE("ar9170.fw");
MODULE_FIRMWARE("ar9170-1.fw");
MODULE_FIRMWARE("ar9170-2.fw");
-enum ar9170_requirements {
- AR9170_REQ_FW1_ONLY = 1,
-};
-
static struct usb_device_id ar9170_usb_ids[] = {
/* Atheros 9170 */
{ USB_DEVICE(0x0cf3, 0x9170) },
@@ -73,7 +69,7 @@ static struct usb_device_id ar9170_usb_ids[] = {
/* Netgear WNDA3100 */
{ USB_DEVICE(0x0846, 0x9010) },
/* Netgear WN111 v2 */
- { USB_DEVICE(0x0846, 0x9001) },
+ { USB_DEVICE(0x0846, 0x9001), .driver_info = AR9170_ONLY_ONE_LED },
/* Zydas ZD1221 */
{ USB_DEVICE(0x0ace, 0x1221) },
/* ZyXEL NWD271N */
@@ -89,7 +85,7 @@ static struct usb_device_id ar9170_usb_ids[] = {
/* IO-Data WNGDNUS2 */
{ USB_DEVICE(0x04bb, 0x093f) },
/* AVM FRITZ!WLAN USB Stick N */
- { USB_DEVICE(0x057C, 0x8401) },
+ { USB_DEVICE(0x057C, 0x8401), .driver_info = AR9170_SWAPPED_LEDS },
/* AVM FRITZ!WLAN USB Stick N 2.4 */
{ USB_DEVICE(0x057C, 0x8402), .driver_info = AR9170_REQ_FW1_ONLY },
@@ -589,7 +585,7 @@ static int ar9170_usb_request_firmware(struct ar9170_usb *aru)
return 0;
}
- if (aru->req_one_stage_fw) {
+ if (aru->common.quirks & AR9170_REQ_FW1_ONLY) {
dev_err(&aru->udev->dev, "ar9170.fw firmware file "
"not found and is required for this device\n");
return -EINVAL;
@@ -753,15 +749,6 @@ err_out:
return err;
}
-static bool ar9170_requires_one_stage(const struct usb_device_id *id)
-{
- if (!id->driver_info)
- return false;
- if (id->driver_info == AR9170_REQ_FW1_ONLY)
- return true;
- return false;
-}
-
static int ar9170_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -781,8 +768,7 @@ static int ar9170_usb_probe(struct usb_interface *intf,
aru->udev = udev;
aru->intf = intf;
ar = &aru->common;
-
- aru->req_one_stage_fw = ar9170_requires_one_stage(id);
+ ar->quirks = id->driver_info;
usb_set_intfdata(intf, aru);
SET_IEEE80211_DEV(ar->hw, &intf->dev);
diff --git a/drivers/net/wireless/ath/ar9170/usb.h b/drivers/net/wireless/ath/ar9170/usb.h
index d098f4d..714436d 100644
--- a/drivers/net/wireless/ath/ar9170/usb.h
+++ b/drivers/net/wireless/ath/ar9170/usb.h
@@ -64,8 +64,6 @@ struct ar9170_usb {
struct usb_anchor tx_pending;
struct usb_anchor tx_submitted;
- bool req_one_stage_fw;
-
spinlock_t tx_urb_lock;
unsigned int tx_submitted_urbs;
unsigned int tx_pending_urbs;
^ permalink raw reply related
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: John W. Linville @ 2009-10-01 15:18 UTC (permalink / raw)
To: Kalle Valo; +Cc: Luis R. Rodriguez, linux-wireless, netdev
In-Reply-To: <87fxa3qjt2.fsf@purkki.valot.fi>
On Thu, Oct 01, 2009 at 05:18:33PM +0300, Kalle Valo wrote:
> "John W. Linville" <linville@tuxdriver.com> writes:
>
> > On Fri, Sep 25, 2009 at 09:53:35AM -0700, Luis R. Rodriguez wrote:
> >
> >> So for Wake-on-Wireless I ran into the same, ethtool just did not
> >> offer the same wake up events needed for wireless. I could have
> >> technically used ethtool and expanded it to support wireless but it
> >> just seemed dirty.
> >>
> >> I agree that using ethtool seems overkill compared to the patches
> >> you posted.
> >
> > I think you either overestimate the amount of trouble for implementing
> > (minimal) ethtool support or you underestimate the amount of
> > functionality available through that interface.
>
> I'm not worried about the implementation complexity, and as your
> patches show it was easy. My concern is the overall design for
> wireless devices. Instead of using nl80211 for everything, with some
> features we would use nl80211/iw and with some ethtool. That's just
> confusing and I don't like that. I would prefer that nl80211 provides
> everything, it makes things so much easier.
Well, if the hw/fw version numbers were the only thing then I'd
probably say it's not a big deal. But having ethtool support is nice
in that it makes a familiar tool work for us. Among other things,
this probably helps with some distro scripts that don't work quite
right without it. Plus, there is lots of debugging stuff that could
be turned-on without having to write new tools.
I suppose I understand the 'one API' idea, but why duplicate
functionality? Anyway, adding a couple of ioctl calls isn't a
big deal. And don't forget, we are still network drivers too...
> > That, or you just don't like using something named "eth"tool for
> > wireless -- but hey, let's be honest about the frames we
> > send/receive to/from the kernel... :-)
>
> I don't have a problem with the name :) But ethernet is still so much
> different from 802.11 that there isn't that much to share and we in
> wireless will need different features.
>
> One example is the hw version, ethtool only provides u32 to userspace
> and moves the burden of translating hw id to the user. For us a string
> is much better choise because when debuggin we need to often (or
> always?) know the chip version.
Look at the way most drivers set the version (using each byte as a
field). If you want prettier output, adding a parser to the userland
ethtool is fairly trivial. It looks something like the patch below...
> But this is not something I will start fighting about. If you still
> think that ethtool is the way to go, I'm perfectly fine with it.
>
> >> The ethtool interface provides functionality for viewing and modifying
> > eeprom contents, dumping registers, trigger self-tests, basic driver
> > info, getting and setting message reporting levels, external card
> > identification (hey, _could_ be useful!), and some other bits like
> > checksum offload that might(?) be useful in the future. I understand
> > regarding the WoW vs. WoL issue but probably the answer is just to
> > add a new method for WoW...?
>
> I took a look at ethtool help output from debian unstable and I think
> this is the set of features we can use in wireless:
>
> ethtool -i|--driver DEVNAME Show driver information
> ethtool -d|--register-dump DEVNAME Do a register dump
> [ raw on|off ]
> [ file FILENAME ]
> ethtool -e|--eeprom-dump DEVNAME Do a EEPROM dump
> [ raw on|off ]
> [ offset N ]
> [ length N ]
> ethtool -E|--change-eeprom DEVNAME Change bytes in device
> EEPROM
> [ magic N ]
> [ offset N ]
> [ value N ]
> ethtool -p|--identify DEVNAME Show visible port
> identification (e.g. blinking)
> [ TIME-IN-SECONDS ]
> ethtool -t|--test DEVNAME Execute adapter self test
> [ online | offline ]
I agree with the above.
> But here are the features which I doubt we will ever use:
>
> ethtool -s|--change DEVNAME Change generic options
> [ speed %%d ]
> [ duplex half|full ]
> [ port tp|aui|bnc|mii|fibre ]
> [ autoneg on|off ]
> [ advertise %%x ]
> [ phyad %%d ]
> [ xcvr internal|external ]
> [ wol p|u|m|b|a|g|s|d... ]
> [ sopass %%x:%%x:%%x:%%x:%%x:%%x ]
> [ msglvl %%d ]
> ethtool -a|--show-pause DEVNAME Show pause options
> ethtool -A|--pause DEVNAME Set pause options
> [ autoneg on|off ]
> [ rx on|off ]
> [ tx on|off ]
I agree that the above are ethernet-specific.
> ethtool -c|--show-coalesce DEVNAME Show coalesce options
> ethtool -C|--coalesce DEVNAME Set coalesce options
> [adaptive-rx on|off]
> [adaptive-tx on|off]
> [rx-usecs N]
> [rx-frames N]
> [rx-usecs-irq N]
> [rx-frames-irq N]
> [tx-usecs N]
> [tx-frames N]
> [tx-usecs-irq N]
> [tx-frames-irq N]
> [stats-block-usecs N]
> [pkt-rate-low N]
> [rx-usecs-low N]
> [rx-frames-low N]
> [tx-usecs-low N]
> [tx-frames-low N]
> [pkt-rate-high N]
> [rx-usecs-high N]
> [rx-frames-high N]
> [tx-usecs-high N]
> [tx-frames-high N]
> [sample-interval N]
These _could_ be useful if wireless becomes more
performance-oriented...
> ethtool -g|--show-ring DEVNAME Query RX/TX ring parameters
> ethtool -G|--set-ring DEVNAME Set RX/TX ring parameters
> [ rx N ]
> [ rx-mini N ]
> [ rx-jumbo N ]
> [ tx N ]
Wireless devices have ring buffers, no?
> ethtool -k|--show-offload DEVNAME Get protocol offload
> information
> ethtool -K|--offload DEVNAME Set protocol offload
> [ rx on|off ]
> [ tx on|off ]
> [ sg on|off ]
> [ tso on|off ]
> [ ufo on|off ]
> [ gso on|off ]
> [ gro on|off ]
> [ lro on|off ]
Again, if wireless devices become performance-oriented...
> ethtool -r|--negotiate DEVNAME Restart N-WAY negotation
Ethernet-specific...might could be overloaded for wireless to trigger
reassoc...?
> ethtool -n|--show-nfc DEVNAME Show Rx network flow
> classificationoptions
> [ rx-flow-hash
> tcp4|udp4|ah4|sctp4|tcp6|udp6|ah6|sctp6 ]
> ethtool -N|--config-nfc DEVNAME Configure Rx network flow
> classification options
> [ rx-flow-hash tcp4|udp4|ah4|sctp4|tcp6|udp6|ah6|sctp6
> m|v|t|s|d|f|n|r... ]
Long-shot, but no reason it couldn't be used in wireless... :-)
Anyway, it doesn't really matter if we don't use the whole API -- many
older ethernet devices don't support all these features. The point
is that the API exists and has some overlap with our needs. It is a
driver-oriented API, with nitty-gritty stuff that need not clutter a
configuraiton API like cfg80211. There is even the potential of us
adding our own extensions (e.g. WoW) that are also device-oriented.
Anyway, between the link detection and making distro scripts work
plus enabling a familiar tool for basic driver info I think this is
a win. So much the better if some drivers move to ethtool for register
dumping, setting message verbosity, querying/changing eeprom values,
etc, etc...
John
P.S. The aforementioned path for userland ethtool...(theorhetical,
not even compiled...)
>From aa92d32ac1cca57bdd3439013b0c7777bdf1217c Mon Sep 17 00:00:00 2001
From: John W. Linville <linville@tuxdriver.com>
Date: Thu, 1 Oct 2009 11:01:32 -0400
Subject: [PATCH] add support for at76c50x-usb driver.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Makefile.am | 2 +-
at76c50x-usb.c | 32 ++++++++++++++++++++++++++++++++
ethtool.c | 1 +
3 files changed, 34 insertions(+), 1 deletions(-)
create mode 100644 at76c50x-usb.c
diff --git a/Makefile.am b/Makefile.am
index eac65fe..a384949 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,7 +8,7 @@ ethtool_SOURCES = ethtool.c ethtool-copy.h ethtool-util.h \
amd8111e.c de2104x.c e100.c e1000.c igb.c \
fec_8xx.c ibm_emac.c ixgb.c ixgbe.c natsemi.c \
pcnet32.c realtek.c tg3.c marvell.c vioc.c \
- smsc911x.c
+ smsc911x.c at76c50x-usb.c
dist-hook:
cp $(top_srcdir)/ethtool.spec $(distdir)
diff --git a/at76c50x-usb.c b/at76c50x-usb.c
new file mode 100644
index 0000000..295d1cb
--- /dev/null
+++ b/at76c50x-usb.c
@@ -0,0 +1,32 @@
+#include <stdio.h>
+#include "ethtool-util.h"
+
+static char hw_versions[] = {
+ "503_ISL3861",
+ "503_ISL3863",
+ " 503",
+ " 503_ACC",
+ " 505",
+ " 505_2958",
+ " 505A",
+ " 505AMX",
+};
+
+int
+at76c50x_usb_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
+{
+ u8 version = (u8)(regs->version >> 24);
+ u8 rev_id = (u8)(regs->version);
+ char *ver_string;
+
+ if(version != 0)
+ return -1;
+
+ ver_string = hw_versions[rev_id];
+ fprintf(stdout,
+ "Hardware Version %s\n",
+ ver_string);
+
+ return 0;
+}
+
diff --git a/ethtool.c b/ethtool.c
index 0110682..7608750 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1189,6 +1189,7 @@ static struct {
{ "sky2", sky2_dump_regs },
{ "vioc", vioc_dump_regs },
{ "smsc911x", smsc911x_dump_regs },
+ { "at76c50x-usb", at76c50x_usb_dump_regs },
};
static int dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
--
1.6.2.5
--
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 related
* Re: [PATCH 0/2] cfg80211: firmware and hardware version
From: Ben Hutchings @ 2009-10-01 15:33 UTC (permalink / raw)
To: John W. Linville; +Cc: Kalle Valo, Luis R. Rodriguez, linux-wireless, netdev
In-Reply-To: <20091001151820.GA2895@tuxdriver.com>
On Thu, 2009-10-01 at 11:18 -0400, John W. Linville wrote:
[...]
> > But here are the features which I doubt we will ever use:
> >
> > ethtool -s|--change DEVNAME Change generic options
> > [ speed %%d ]
> > [ duplex half|full ]
> > [ port tp|aui|bnc|mii|fibre ]
> > [ autoneg on|off ]
> > [ advertise %%x ]
> > [ phyad %%d ]
> > [ xcvr internal|external ]
> > [ wol p|u|m|b|a|g|s|d... ]
> > [ sopass %%x:%%x:%%x:%%x:%%x:%%x ]
> > [ msglvl %%d ]
> > ethtool -a|--show-pause DEVNAME Show pause options
> > ethtool -A|--pause DEVNAME Set pause options
> > [ autoneg on|off ]
> > [ rx on|off ]
> > [ tx on|off ]
>
> I agree that the above are ethernet-specific.
[...]
Message level isn't and WoL arguably isn't. It's a shame that these
original ethtool settings are still bundled together...
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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