* Re: AR5523 driver - old Atheros USB
From: Luis R. Rodriguez @ 2009-07-22 1:04 UTC (permalink / raw)
To: Purushotham Nayak; +Cc: Christoph Hellwig, linux-wireless, Dan Williams
In-Reply-To: <928354.18240.qm@web56107.mail.re3.yahoo.com>
On Tue, Jul 21, 2009 at 6:03 PM, Purushotham
Nayak<nayak_purushotham@yahoo.com> wrote:
>
> Hi,
>
> I'm interested in working on this. I just posted to the Linux driver project a few days ago if I could work on the atheros USB devices. Please let me also know the USB device that uses the AR5523.
Dan recently purchased one of these devices. Dan any pointers?
Luis
^ permalink raw reply
* [PATCH] adm8211: remove uneeded code during suspend/resume
From: Luis R. Rodriguez @ 2009-07-22 1:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
mac80211 drivers do not need to stop the software queues
or call their own stop() callback upon suspend as we do it
for drivers. Equally drivers don't have to call their own
start() or start the queues as mac80211 will do it for us.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/adm8211.c | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
index ecc9383..5695911 100644
--- a/drivers/net/wireless/adm8211.c
+++ b/drivers/net/wireless/adm8211.c
@@ -1964,14 +1964,6 @@ static void __devexit adm8211_remove(struct pci_dev *pdev)
#ifdef CONFIG_PM
static int adm8211_suspend(struct pci_dev *pdev, pm_message_t state)
{
- struct ieee80211_hw *dev = pci_get_drvdata(pdev);
- struct adm8211_priv *priv = dev->priv;
-
- if (priv->mode != NL80211_IFTYPE_UNSPECIFIED) {
- ieee80211_stop_queues(dev);
- adm8211_stop(dev);
- }
-
pci_save_state(pdev);
pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
@@ -1979,17 +1971,8 @@ static int adm8211_suspend(struct pci_dev *pdev, pm_message_t state)
static int adm8211_resume(struct pci_dev *pdev)
{
- struct ieee80211_hw *dev = pci_get_drvdata(pdev);
- struct adm8211_priv *priv = dev->priv;
-
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
-
- if (priv->mode != NL80211_IFTYPE_UNSPECIFIED) {
- adm8211_start(dev);
- ieee80211_wake_queues(dev);
- }
-
return 0;
}
#endif /* CONFIG_PM */
--
1.6.0.4
^ permalink raw reply related
* [PATCH] ath9k: do not stop the queues in driver stop
From: Luis R. Rodriguez @ 2009-07-22 1:03 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez
mac80211 will have disabled the queues for us when
needed.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 254e787..3436295 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2101,8 +2101,6 @@ static void ath9k_stop(struct ieee80211_hw *hw)
mutex_lock(&sc->mutex);
- ieee80211_stop_queues(hw);
-
if (ath9k_wiphy_started(sc)) {
mutex_unlock(&sc->mutex);
return; /* another wiphy still in use */
--
1.6.0.4
^ permalink raw reply related
* lockdep complaint on tip + some pending patches
From: Luis R. Rodriguez @ 2009-07-22 0:50 UTC (permalink / raw)
To: linux-wireless
While running on wireless-testing + netns pending patches + wow patches:
wpa_supplicant -D wext -i wlan1 -c mosca.conf
[ 233.096916] phy0: device now idle
[ 233.114625] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 234.116189] phy0: device no longer idle - scanning
[ 234.233767]
[ 234.233772] =======================================================
[ 234.233797] [ INFO: possible circular locking dependency detected ]
[ 234.233807] 2.6.31-rc3-wl #16
[ 234.233814] -------------------------------------------------------
[ 234.233824] wpa_supplicant/3089 is trying to acquire lock:
[ 234.233835] (cfg80211_mutex){+.+.+.}, at: [<f83eb185>]
cfg80211_get_dev_from_ifindex+0x15/0x80 [cfg80211]
[ 234.233887]
[ 234.233889] but task is already holding lock:
[ 234.233901] (rtnl_mutex){+.+.+.}, at: [<c049de2f>] rtnl_lock+0xf/0x20
[ 234.233932]
[ 234.233934] which lock already depends on the new lock.
[ 234.233936]
[ 234.233957]
[ 234.233958] the existing dependency chain (in reverse order) is:
[ 234.233970]
[ 234.233972] -> #1 (rtnl_mutex){+.+.+.}:
[ 234.233996] [<c0169b35>] __lock_acquire+0xba5/0x1020
[ 234.234014] [<c016a06b>] lock_acquire+0xbb/0xe0
[ 234.234029] [<c05838f4>] mutex_lock_nested+0x54/0x300
[ 234.234045] [<c049de2f>] rtnl_lock+0xf/0x20
[ 234.234061] [<f83f734a>]
nl80211_send_reg_change_event+0x1aa/0x250 [cfg80211]
[ 234.234101] [<f83ed75b>] set_regdom+0x21b/0x4b0 [cfg80211]
[ 234.234133] [<f83f1d84>] nl80211_set_reg+0xe4/0x270 [cfg80211]
[ 234.234165] [<c04b04cf>] genl_rcv_msg+0x1df/0x210
[ 234.234183] [<c04af6c6>] netlink_rcv_skb+0x76/0xa0
[ 234.234199] [<c04b02de>] genl_rcv+0x1e/0x30
[ 234.234215] [<c04af3fb>] netlink_unicast+0x23b/0x250
[ 234.234231] [<c04afedb>] netlink_sendmsg+0x1db/0x2d0
[ 234.234246] [<c048481a>] soc[ 234.234265]
[<c0484951>] sys_sendmsg+0x111/0x230
[ 234.234281] [<c04850fa>] sys_socketcall+0xca/0x2a0
[ 234.234297] [<c010300c>] sysenter_do_call+0x12/0x38
[ 234.234314] [<ffffffff>] 0xffffffff
[ 234.234353]
[ 234.234355] -> #0 (cfg80211_mutex){+.+.+.}:
[ 234.234383] [<c0169be6>] __lock_acquire+0xc56/0x1020
[ 234.234400] [<c016a06b>] lock_acquire+0xbb/0xe0
[ 234.234415] [<c05838f4>] mutex_lock_nested+0x54/0x300
[ 234.234431] [<f83eb185>]
cfg80211_get_dev_from_ifindex+0x15/0x80 [cfg80211]
[ 234.234462] [<f83ef595>] cfg80211_wext_giwscan+0x35/0xc00 [cfg80211]
[ 234.234492] [<c0566fe9>] ioctl_standard_call+0x199/0x3a0
[ 234.234508] [<c0566aef>] wext_handle_ioctl+0x14f/0x230
[ 234.234524] [<c0495524>] dev_ioctl+0x474/0x540
[ 234.234541] [<c0482e75>] sock_ioctl+0xf5/0x270
[ 234.234555] [<c01f11a8>] vfs_ioctl+0x28/0x90
[ 234.234573] [<c01f135a>] do_vfs_ioctl+0x6a/0x5e0
[ 234.234589] [<c01f1933>] sys_ioctl+0x63/0x70
[ 234.234607] [<c010300c>] sysenter_do_call+0x12/0x38
[ 234.234622] [<ffffffff>] 0xffffffff
[ 234.234640]
[ 234.234641] other info that might help us debug this:
k_sendmsg+0xea/0x110
[ 234.234658] 1 lock held by wpa_supplicant/3089:
[ 234.234665] #0: (rtnl_mutex){+.+.+.}, at: [<c049de2f>] rtnl_lock+0xf/0x20
[ 234.234693]
[ 234.234695] stack backtrace:
[ 234.234710] Pid: 3089, comm: wpa_supplicant Not tainted 2.6.31-rc3-wl #16
[ 234.234719] Call Trace:
[ 234.234733] [<c0582215>] ? printk+0x18/0x1b
[ 234.234747] [<c01685b4>] print_circular_bug_tail+0x84/0xd0
[ 234.234761] [<c0169be6>] __lock_acquire+0xc56/0x1020
[ 234.234774] [<c016a06b>] lock_acquire+0xbb/0xe0
[ 234.234802] [<f83eb185>] ? cfg80211_get_dev_from_ifindex+0x15/0x80
[cfg80211]
[ 234.234816] [<c05838f4>] mutex_lock_nested+0x54/0x300
[ 234.234842] [<f83eb185>] ? cfg80211_get_dev_from_ifindex+0x15/0x80
[cfg80211]
[ 234.234857] [<c012bb7b>] ? __wake_up+0x1b/0x50
[ 234.234869] [<c0585535>] ? _spin_unlock_irqrestore+0x35/0x60
[ 234.234896] [<f83eb185>] cfg80211_get_dev_from_ifindex+0x15/0x80 [cfg80211]
[ 234.234924] [<f83ef595>] cfg80211_wext_giwscan+0x35/0xc00 [cfg80211]
[ 234.234939] [<c01689f3>] ? mark_held_locks+0x63/0x80
[ 234.234951] [<c01dc23d>] ? __kmalloc+0x9d/0x1d0
[ 234.234964] [<c0168cbc>] ? trace_hardirqs_on_caller+0x12c/0x170
[ 234.234979] [<c0168d0b>] ? trace_hardirqs_on+0xb/0x10
[ 234.234991] [<c0566fb3>] ? ioctl_standard_call+0x163/0x3a0
[ 234.235004] [<c01689f3>] ? mark_held_locks+0x63/0x80
[ 234.235016] [<c0566fe9>] ioctl_standard_call+0x199/0x3a0
[ 234.235028] [<c049de2f>] ? rtnl_lock+0xf/0x20
[ 234.235043] [<c049499d>] ? __dev_get_by_name+0x7d/0xa0
[ 234.235055] [<c0566aef>] wext_handle_ioctl+0x14f/0x230
[ 234.235083] [<f83ef560>] ? cfg80211_wext_giwscan+0x0/0xc00 [cfg80211]
[ 234.235097] [<c0495524>] dev_ioctl+0x474/0x540
[ 234.235109] [<c0482d80>] ? sock_ioctl+0x0/0x270
[ 234.235121] [<c0482e75>] sock_ioctl+0xf5/0x270
[ 234.235132] [<c0482d80>] ? sock_ioctl+0x0/0x270
[ 234.235144] [<c01f11a8>] vfs_ioctl+0x28/0x90
[ 234.235157] [<c01f135a>] do_vfs_ioctl+0x6a/0x5e0
[ 234.235171] [<c01c3feb>] ? might_fault+0x4b/0xa0
[ 234.235183] [<c01c4037>] ? might_fault+0x97/0xa0
[ 234.235198] [<c01c3feb>] ? might_fault+0x4b/0xa0
[ 234.235210] [<c0103041>] ? sysenter_exit+0xf/0x1a
[ 234.235222] [<c01f1933>] sys_ioctl+0x63/0x70
[ 234.235234] [<c010300c>] sysenter_do_call+0x12/0x38
[ 234.792004] cfg80211: Found new beacon on frequency: 5180 MHz (Ch 36) on phy0
[ 234.906721] cfg80211: Found new beacon on frequency: 5200 MHz (Ch 40) on phy0
[ 235.089212] cfg80211: Found new beacon on frequency: 5220 MHz (Ch 44) on phy0
[ 235.231620] cfg80211: Found new beacon on frequency: 5240 MHz (Ch 48) on phy0
[ 235.231671] cfg80211: Found new beacon on frequency: 5240 MHz (Ch 48) on phy0
[ 235.231696] cfg80211: Found new beacon on frequency: 5240 MHz (Ch 48) on phy0
[ 235.866781] cfg80211: Found new beacon on frequency: 5745 MHz (Ch
149) on phy0
[ 236.416552] phy0: device now idle
[ 244.243725] phy0: device no longer idle - scanning
[ 246.257179] cfg80211: Found new beacon on frequency: 5785 MHz (Ch
157) on phy0
[ 246.533629] phy0: device now idle
[ 251.530506] phy0: device no longer idle - scanning
[ 253.822071] phy0: device now idle
[ 258.816267] phy0: device no longer idle - scanning
[ 261.109986] phy0: device now idle
[ 266.106730] phy0: device no longer idle - scanning
[ 268.409957] phy0: device now idle
^ permalink raw reply
* (no subject)
From: root @ 2009-07-22 0:11 UTC (permalink / raw)
To: linux-wireless
subscribe linux-wireless
^ permalink raw reply
* Re: AR5523 driver - old Atheros USB
From: Luis R. Rodriguez @ 2009-07-22 0:03 UTC (permalink / raw)
To: Christoph Hellwig, linux-wireless, linux-kernel
Cc: Dan Williams, Jouni Malinen, Greg KH, John W. Linville, devel,
ath9k-devel, ath5k-devel, madwifi-devel
In-Reply-To: <20090721214219.GA25392@lst.de>
On Tue, Jul 21, 2009 at 2:42 PM, Christoph Hellwig<hch@lst.de> wrote:
> On Tue, Jul 21, 2009 at 02:24:36PM -0700, Luis R. Rodriguez wrote:
>> >> Hey Chris, was curious if you still had lying around the driver you
>> >> had worked on for the old Atheros 802.11 USB device. Dan asked about
>> >> it, seems he bought one. We at least now have specs for it and can
>> >> provide them to interested developers. Since Dan brought this device
>> >> up figured I'd check to see if you still had it to see if you still
>> >> had the code and might be willing to let someone try to give a shot at
>> >> finishing it up for inclusion. Perhaps staging?
>> >
>> > The code has been at http://verein.lst.de/~hch/ar5523.tgz.
>>
>> Sweet. How functional is this? Does it TX/RX?
>
> It's been quite some time. IIRC it does TX, but can't actually see
> any packets on RX (filter issue or something).
Sorry for the large cross post, just seeing if someone is interested
in working on a wireless driver. The task would be to try to get
AR5523 USB driver up to speed with mac80211 from wireless-testing and
giving it a shot to fix remaining issues?
It seems to have compiled last for 2.6.23.
If you're interested please remove all lists and only leave
linux-wireless on the reply.
Luis
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Luis R. Rodriguez @ 2009-07-21 23:26 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <43e72e890907201247x7df76b75wf6ba2bc2260dbf7a@mail.gmail.com>
On Mon, Jul 20, 2009 at 12:47 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Mon, Jul 20, 2009 at 12:16 PM, Philip A.
> Prindeville<philipp_subx@redfish-solutions.com> wrote:
>> Bob Copeland wrote:
>>> On Sun, Jul 19, 2009 at 08:05:47PM -0700, Philip A. Prindeville wrote:
>>>> Actually, it's saying:
>>>>
>>>> filename: /lib/modules/2.6.27.26-astlinux/kernel/drivers/net/wireless/ath5k/ath5k.ko
>>>> depends: mac80211,cfg80211
>>>>
>>>> And the 0.6.0 version number matches ath5k/base.c in the compat-wireless
>>>> sources as well.
>>>
>>> Yeah, ignore the module version number, no one ever changes it.
>>>
>>>> Not seeing the dependency on "ath", which is strange. Is that common code
>>>> that's shared in 2.6.30 for the Atheros drivers?
>>>
>>> In 2.6.31, yes.
>>>
>>>>> The fix was merged after 2.6.30, IIRC, but it should definitely be in
>>>>> compat-wireless. Also check your modules directory for an old ath5k.ko
>>>>> sitting in drivers/.../wireless/ath5k. It should now be in ath/ath5k.
>>>
>>> See above, the fix was post-2.6.30, however compat-wireless should have
>>> it. The module should now be in drivers/net/wireless/ath/ath5k, not
>>> drivers/net/wireless/ath5k.
>>>
>>
>> I'm using the tarball out of:
>>
>> http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.30
>>
>> perhaps I should be using a different one? I tried 2.6.31-rc1, but it doesn't build against 2.6.27.
>
> I have to fix this, will do so in a bit, will also update it to
> account for the new rc3.
Updated:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.31/compat-wireless-2.6.31-rc3.tar.bz2
Luis
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Luis R. Rodriguez @ 2009-07-21 23:24 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <4A6620B9.4@redfish-solutions.com>
On Tue, Jul 21, 2009 at 1:10 PM, Philip A.
Prindeville<philipp_subx@redfish-solutions.com> wrote:
> Philip A. Prindeville wrote:
>> Luis R. Rodriguez wrote:
>>
>>> On Mon, Jul 20, 2009 at 12:16 PM, Philip A.
>>> Prindeville<philipp_subx@redfish-solutions.com> wrote:
>>>
>>>> Bob Copeland wrote:
>>>>
>>>>> On Sun, Jul 19, 2009 at 08:05:47PM -0700, Philip A. Prindeville wrote:
>>>>>
>>>>>> Actually, it's saying:
>>>>>>
>>>>>> filename: /lib/modules/2.6.27.26-astlinux/kernel/drivers/net/wireless/ath5k/ath5k.ko
>>>>>> depends: mac80211,cfg80211
>>>>>>
>>>>>> And the 0.6.0 version number matches ath5k/base.c in the compat-wireless
>>>>>> sources as well.
>>>>>>
>>>>> Yeah, ignore the module version number, no one ever changes it.
>>>>>
>>>>>
>>>>>> Not seeing the dependency on "ath", which is strange. Is that common code
>>>>>> that's shared in 2.6.30 for the Atheros drivers?
>>>>>>
>>>>> In 2.6.31, yes.
>>>>>
>>>>>
>>>>>>> The fix was merged after 2.6.30, IIRC, but it should definitely be in
>>>>>>> compat-wireless. Also check your modules directory for an old ath5k.ko
>>>>>>> sitting in drivers/.../wireless/ath5k. It should now be in ath/ath5k.
>>>>>>>
>>>>> See above, the fix was post-2.6.30, however compat-wireless should have
>>>>> it. The module should now be in drivers/net/wireless/ath/ath5k, not
>>>>> drivers/net/wireless/ath5k.
>>>>>
>>>>>
>>>> I'm using the tarball out of:
>>>>
>>>> http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.30
>>>>
>>>> perhaps I should be using a different one? I tried 2.6.31-rc1, but it doesn't build against 2.6.27.
>>>>
>>> I have to fix this, will do so in a bit, will also update it to
>>> account for the new rc3.
>>>
>>> Luis
>>>
>>
>> Well, while waiting for a "blessed" (or at least, 'stable') tarball to be pushed out, I tried running 2009-06-30, and I'm seeing a lot of:
>>
>> mgmt::proberesp cb
>> Probe Request from 00:21:29:69:3e:a0 for broadcast SSID ignored
>> STA 00:21:29:69:3e:a0 sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> ...
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) ACK
>> mgmt::proberesp cb
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) ACK
>> mgmt::proberesp cb
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
>> STA 00:21:29:69:3e:a0 sent probe request for our SSID
>> Probe Request from 00:21:29:69:3e:a0 for broadcast SSID ignored
>> MGMT (TX callback) ACK
>> mgmt::proberesp cb
>> STA 00:21:29:69:3e:a0 sent probe request for our SSID
>> MGMT (TX callback) fail
>> mgmt::proberesp cb
>>
>>
>>
>> 00:21:29:69:3e:a0 is a PC running Vista SP2.
>>
>> 00:21:e9:6e:a7:4f is an iPhone running 3.0.
>>
>> The iPhone should be scanning for available networks, but it's also been explicitly configured with this particular AP (and SSID).
>>
>> Is this a known issue?
>>
>> -Philip
>>
>
> A little progress: I build 2009-07-10 with 2.6.27.26, and I can get the
> Vista box to associate, but not an iPhone running 3.0...
BTW new shiny compat-wireless is out based on John's latest merge from today.
> I have traces if anyone is interested.
>
> -Philip
>
>
^ permalink raw reply
* Slow roaming in mac80211 (2.6.30).
From: Lars Ericsson @ 2009-07-21 21:21 UTC (permalink / raw)
To: 'Johannes Berg'; +Cc: linux-wireless, hostap
Johannes,
I'm currently using the 2.6.26 kernel and have started evaluating the
2.6.30.
For .26 I have made a few patches to fix minor issues related to
roaming.
The trace below shows a typical roaming:
87.632965 AP 1 drops STA
87.733979 wpa_supplicant trigs a scan
88.629931 mac80211 probes for the old AP
90.670305 SCAN result to wpa_supplicant
90.702325 wpa_supplicant ready with new AP
92.158037 mac80211 executes the wpa_supplicant decisions
92.164776 we are on line again
Total roaming time is 4,5 seconds, where mac80211 had added 2*2
seconds delay.
A first analysis gives that the two delays are the ieee80211_sta_work()
timeout. There are many events trigging ieee80211_sta_work(), but
since only the timer sets IEEE80211_STA_REQ_RUN, nothing will happen.
Questions;
- Why does mac80211 tells the wpa_supplicant that the AP
is gone (87.632965), and then blocks/delays the actions taken by the
wpa_supplicant?
- Why are some wpa_supplicant actions (90.702325)
not event driven?
It looks to me as if we have to decision makers here. For me the
wpa_supplicant is the one that make the decision. Once the mac80211
gives up and feedback that the AP is gone, it should just sit
and wait for next decision from the wpa_supplicant.
I had a few patches for this for .26, but since the code is changed
they do not apply. Before I create new patches I would like to get
your opinion on this.
Regards
/Lars
-----
[ 87.632965] wlan0: deauthenticated (Reason: 1)
[ 87.733979] [B] LaE: SCANRQUEST: SSID=AGV
[ 88.629931] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 1
[ 88.829932] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 2
[ 89.029944] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 3
[ 89.230016] wlan0: direct probe to AP 00:40:96:a0:e7:e7 timed out
[ 90.670305] [B] LaE: SCANRESULT: BSSID=00:40:96:a0:e7:e7, SSID=
, ch= 1, , q= 0, l= 0(-30dBm), n= 0
[ 90.670384] [B] LaE: SCANRESULT: BSSID=00:08:21:31:53:87, SSID=
, ch=11, , q= 0, l= 0(-62dBm), n= 0
[ 90.670455] [B] LaE: SCANRESULT: BSSID=00:08:21:31:53:87, SSID=AGV
, ch=11, , q= 0, l= 0(-60dBm), n= 0
[ 90.670705] ieee80211_ioctl_siwauth: enter
[ 90.670777] ieee80211_ioctl_siwencodeext: enter
[ 90.670807] ieee80211_set_encryption: enter
[ 90.671128] ieee80211_ioctl_siwencodeext: enter
[ 90.671165] ieee80211_set_encryption: enter
[ 90.671219] ieee80211_ioctl_siwencodeext: enter
[ 90.671247] ieee80211_set_encryption: enter
[ 90.671297] ieee80211_ioctl_siwencodeext: enter
[ 90.671325] ieee80211_set_encryption: enter
[ 90.671375] ieee80211_ioctl_siwencodeext: enter
[ 90.671404] ieee80211_set_encryption: enter
[ 90.671623] ieee80211_ioctl_siwencodeext: enter
[ 90.671659] ieee80211_set_encryption: enter
[ 90.672062] ieee80211_ioctl_siwauth: enter
[ 90.672295] ieee80211_ioctl_siwgenie: enter
[ 90.672332] ieee80211_sta_req_auth: queue auth
[ 90.672380] ieee80211_ioctl_siwauth: enter
[ 90.672420] ieee80211_ioctl_siwauth: enter
[ 90.672458] ieee80211_ioctl_siwauth: enter
[ 90.672495] ieee80211_ioctl_siwauth: enter
[ 90.672532] ieee80211_ioctl_siwauth: enter
[ 90.672569] ieee80211_ioctl_siwauth: enter
[ 90.672612] ieee80211_ioctl_siwfreq: enter freq=246200000
[ 90.702175] ieee80211_ioctl_siwessid: enter ssid=AGV
[ 90.702217] ieee80211_sta_req_auth: queue auth
[ 90.702325] ieee80211_ioctl_siwap: enter AP=00:08:21:31:53:87
[ 90.702372] ieee80211_sta_req_auth: queue auth
[ 92.158037] wlan0: authenticate with AP 00:08:21:31:53:87
[ 92.159965] wlan0: authenticated
[ 92.160002] wlan0: associate with AP 00:08:21:31:53:87
[ 92.164733] wlan0: RX ReassocResp from 00:08:21:31:53:87 (capab=0x431
status=0 aid=140)
[ 92.164776] wlan0: associated
[ 92.166984] ieee80211_ioctl_giwap: enter
-----
^ permalink raw reply
* Re: Slow roaming in mac80211 (2.6.30).
From: Johannes Berg @ 2009-07-21 22:30 UTC (permalink / raw)
To: Lars Ericsson; +Cc: linux-wireless
In-Reply-To: <1B3FCF72EBBC44A39F5A80B8FFBF6402@gotws1589>
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
Lars,
> A first analysis gives that the two delays are the ieee80211_sta_work()
> timeout. There are many events trigging ieee80211_sta_work(), but
> since only the timer sets IEEE80211_STA_REQ_RUN, nothing will happen.
TBH I really no longer know the 2.6.30 code well, so I don't know.
> Questions;
> - Why does mac80211 tells the wpa_supplicant that the AP
> is gone (87.632965), and then blocks/delays the actions taken by the
> wpa_supplicant?
The real question is: why the hell is it probing the AP?
> [ 87.632965] wlan0: deauthenticated (Reason: 1)
> [ 87.733979] [B] LaE: SCANRQUEST: SSID=AGV
> [ 88.629931] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 1
> [ 88.829932] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 2
> [ 89.029944] wlan0: direct probe to AP 00:40:96:a0:e7:e7 try 3
> [ 89.230016] wlan0: direct probe to AP 00:40:96:a0:e7:e7 timed out
It doesn't really block actions, but it delays the scan because it's
busy doing the probing. So only after the probing fails will it start
the scan, and complete it within about 1.4 seconds.
> - Why are some wpa_supplicant actions (90.702325)
> not event driven?
>
> It looks to me as if we have to decision makers here. For me the
> wpa_supplicant is the one that make the decision. Once the mac80211
> gives up and feedback that the AP is gone, it should just sit
> and wait for next decision from the wpa_supplicant.
I agree -- the spurious probing is strange. But I also have to admit
that basically I don't care as long as it works -- most of this is just
a side effect of how wireless extensions work.
> I had a few patches for this for .26, but since the code is changed
> they do not apply. Before I create new patches I would like to get
> your opinion on this.
I would suggest you just use wpa_supplicant -Dnl80211, which should help
a lot with this kind of things.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ath9k rfkill behavior
From: Howard Chu @ 2009-07-21 21:01 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <200907211327.03954.chunkeey@web.de>
Christian Lamparter wrote:
> On Tuesday 21 July 2009 02:56:11 Howard Chu wrote:
>> I'm currently running 2.6.31-rc2 and noticed an annoying change in rfkill
>> behavior now; I can no longer toggle the state by echoing 0/1 into
>> sys/class/rfkill/rfkillX/state, it says write operation not permitted. I
>> haven't found any posts online related to this change in behavior, can anyone
>> point me to an explanation/rationale? The only way to change the state now
>> appears to be by using the wifi toggle switch on the laptop.
>
> http://lkml.org/lkml/2009/7/10/339
>
> but no need to patch the kernel (again):
> the legacy iwconfig tool can let you do the same:
>
> iwconfig wlanX txpower off
> and if you want it back:
> iwconfig wlanX txpower auto
Ah, not quite. I want the bluetooth off and the wifi on; if I hit the toggle
switch which turns them both off, iwconfig is unable to turn the wifi back on,
and there is no other command which turns off only the bluetooth.
The above patch works fine, thanks again.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Philip A. Prindeville @ 2009-07-21 20:10 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <4A650331.9020409@redfish-solutions.com>
Philip A. Prindeville wrote:
> Luis R. Rodriguez wrote:
>
>> On Mon, Jul 20, 2009 at 12:16 PM, Philip A.
>> Prindeville<philipp_subx@redfish-solutions.com> wrote:
>>
>>> Bob Copeland wrote:
>>>
>>>> On Sun, Jul 19, 2009 at 08:05:47PM -0700, Philip A. Prindeville wrote:
>>>>
>>>>> Actually, it's saying:
>>>>>
>>>>> filename: /lib/modules/2.6.27.26-astlinux/kernel/drivers/net/wireless/ath5k/ath5k.ko
>>>>> depends: mac80211,cfg80211
>>>>>
>>>>> And the 0.6.0 version number matches ath5k/base.c in the compat-wireless
>>>>> sources as well.
>>>>>
>>>> Yeah, ignore the module version number, no one ever changes it.
>>>>
>>>>
>>>>> Not seeing the dependency on "ath", which is strange. Is that common code
>>>>> that's shared in 2.6.30 for the Atheros drivers?
>>>>>
>>>> In 2.6.31, yes.
>>>>
>>>>
>>>>>> The fix was merged after 2.6.30, IIRC, but it should definitely be in
>>>>>> compat-wireless. Also check your modules directory for an old ath5k.ko
>>>>>> sitting in drivers/.../wireless/ath5k. It should now be in ath/ath5k.
>>>>>>
>>>> See above, the fix was post-2.6.30, however compat-wireless should have
>>>> it. The module should now be in drivers/net/wireless/ath/ath5k, not
>>>> drivers/net/wireless/ath5k.
>>>>
>>>>
>>> I'm using the tarball out of:
>>>
>>> http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.30
>>>
>>> perhaps I should be using a different one? I tried 2.6.31-rc1, but it doesn't build against 2.6.27.
>>>
>> I have to fix this, will do so in a bit, will also update it to
>> account for the new rc3.
>>
>> Luis
>>
>
> Well, while waiting for a "blessed" (or at least, 'stable') tarball to be pushed out, I tried running 2009-06-30, and I'm seeing a lot of:
>
> mgmt::proberesp cb
> Probe Request from 00:21:29:69:3e:a0 for broadcast SSID ignored
> STA 00:21:29:69:3e:a0 sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> ...
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) ACK
> mgmt::proberesp cb
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) ACK
> mgmt::proberesp cb
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
> STA 00:21:e9:6e:a7:4f sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> Probe Request from 00:21:e9:6e:a7:4f for broadcast SSID ignored
> STA 00:21:29:69:3e:a0 sent probe request for our SSID
> Probe Request from 00:21:29:69:3e:a0 for broadcast SSID ignored
> MGMT (TX callback) ACK
> mgmt::proberesp cb
> STA 00:21:29:69:3e:a0 sent probe request for our SSID
> MGMT (TX callback) fail
> mgmt::proberesp cb
>
>
>
> 00:21:29:69:3e:a0 is a PC running Vista SP2.
>
> 00:21:e9:6e:a7:4f is an iPhone running 3.0.
>
> The iPhone should be scanning for available networks, but it's also been explicitly configured with this particular AP (and SSID).
>
> Is this a known issue?
>
> -Philip
>
A little progress: I build 2009-07-10 with 2.6.27.26, and I can get the
Vista box to associate, but not an iPhone running 3.0...
I have traces if anyone is interested.
-Philip
^ permalink raw reply
* [PATCH] MAINTAINERS: Update rtl8180 patterns
From: Joe Perches @ 2009-07-21 20:09 UTC (permalink / raw)
To: John W. Linville; +Cc: Andrew Morton, LKML, linux-wireless
rtl8180 files were moved into a subdirectory
by commit 1c740ed2210a0d124674a477ea538468aba47810
Signed-off-by: Joe Perches <joe@perches.com>
diff --git a/MAINTAINERS b/MAINTAINERS
index 5befb1c..6e45e52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4960,7 +4963,7 @@ L: linux-wireless@vger.kernel.org
W: http://linuxwireless.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
S: Maintained
-F: drivers/net/wireless/rtl818*
+F: drivers/net/wireless/rtl818x/rtl8180*
RTL8187 WIRELESS DRIVER
P: Herton Ronaldo Krzesinski
^ permalink raw reply related
* Re: [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: reinette chatre @ 2009-07-21 20:10 UTC (permalink / raw)
To: Joe Perches
Cc: Kalle Valo, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, jirislaby@gmail.com,
luciano.coelho@nokia.com, James Ketrenos, Zhu, Yi
In-Reply-To: <1248206362.31365.292.camel@Joe-Laptop.home>
On Tue, 2009-07-21 at 12:59 -0700, Joe Perches wrote:
> On Tue, 2009-07-21 at 22:36 +0300, Kalle Valo wrote:
> > Also in the future we might share some of the code between
> > 1251 and 1271. Any tips for this?
>
> Sorry, no.
>
> There are a couple of examples of multiple maintainers
> for wireless drivers in a single directory.
>
> ipw2x00 and rtl818x
>
> ipw2xx has shared files, rtl818x does not.
> ipw2xx does not claim a "maintainer" for the
> shared files. That's probably not important.
>
> Maybe the maintainers for ipw2xx might give
> some more useful information (cc'd). It turns
> out they are the same people though.
I do not have anything useful to add here. As you note the same people
are listed for for both drivers under ipw2x00 so we do not have the same
problem.
Reinette
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: Joe Perches @ 2009-07-21 19:59 UTC (permalink / raw)
To: Kalle Valo
Cc: linville, linux-wireless, jirislaby, luciano.coelho,
Reinette Chatre, James Ketrenos, Zhu Yi
In-Reply-To: <87ocrdsu9f.fsf@litku.valot.fi>
On Tue, 2009-07-21 at 22:36 +0300, Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
>
> >> +F: drivers/net/wireless/wl12xx/wl1251*
> >
> > Not that I'm asking you to maintain more than you want to,
> > but why not:
> >
> > F: drivers/net/wireless/wl12xx/
>
> Just because Luciano will soon publish wl1271 driver (which will use
> wl1271_ prefix) and he will be maintaining that part, no other reason.
Ah, thanks.
> But what should we do with the shared Makefile and Kconfig?
Those files change slowly and generally without conflicts
so MAINTAINERS entries aren't an issue.
> Also in the future we might share some of the code between
> 1251 and 1271. Any tips for this?
Sorry, no.
There are a couple of examples of multiple maintainers
for wireless drivers in a single directory.
ipw2x00 and rtl818x
ipw2xx has shared files, rtl818x does not.
ipw2xx does not claim a "maintainer" for the
shared files. That's probably not important.
Maybe the maintainers for ipw2xx might give
some more useful information (cc'd). It turns
out they are the same people though.
As well, the file patterns for rtl818x need
updating. Thanks for making me check.
cheers, Joe
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: Luciano Coelho @ 2009-07-21 19:51 UTC (permalink / raw)
To: ext Kalle Valo
Cc: Joe Perches, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, jirislaby@gmail.com
In-Reply-To: <87ocrdsu9f.fsf@litku.valot.fi>
ext Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
>
>
>>> +F: drivers/net/wireless/wl12xx/wl1251*
>>>
>> Not that I'm asking you to maintain more than you want to,
>> but why not:
>>
>> F: drivers/net/wireless/wl12xx/
>>
>
> Just because Luciano will soon publish wl1271 driver (which will use
> wl1271_ prefix) and he will be maintaining that part, no other reason.
>
> But what should we do with the shared Makefile and Kconfig? Also in the
> future we might share some of the code between 1251 and 1271. Any tips
> for this?
>
I think we have to choose one maintainer for the shared files (= you!
;). So we could have something like this for your part:
F: drivers/net/wireless/wl12xx/*
X: drivers/net/wireless/wl12xx/wl1271*
Of course this doesn't apply yet, because there is no wl1271* at the
moment (hopefully there will be very soon). So, for now I think you
could have just the F line. And when I add my maintainer's block there,
I can add the X line to your part at the same time... How does that sound?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: Kalle Valo @ 2009-07-21 19:36 UTC (permalink / raw)
To: Joe Perches; +Cc: linville, linux-wireless, jirislaby, luciano.coelho
In-Reply-To: <1248204540.31365.275.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
>> +F: drivers/net/wireless/wl12xx/wl1251*
>
> Not that I'm asking you to maintain more than you want to,
> but why not:
>
> F: drivers/net/wireless/wl12xx/
Just because Luciano will soon publish wl1271 driver (which will use
wl1271_ prefix) and he will be maintaining that part, no other reason.
But what should we do with the shared Makefile and Kconfig? Also in the
future we might share some of the code between 1251 and 1271. Any tips
for this?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: Joe Perches @ 2009-07-21 19:29 UTC (permalink / raw)
To: Kalle Valo; +Cc: linville, linux-wireless, jirislaby
In-Reply-To: <20090721191154.22374.17349.stgit@tikku>
On Tue, 2009-07-21 at 22:11 +0300, Kalle Valo wrote:
> From: Kalle Valo <kalle.valo@nokia.com>
> Add myself as the maintainer for wl1251 driver.
> +WL1251 WIRELESS DRIVER
> +P: Kalle Valo
> +M: kalle.valo@nokia.com
> +L: linux-wireless@vger.kernel.org
> +W: http://wireless.kernel.org
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> +S: Maintained
> +F: drivers/net/wireless/wl12xx/wl1251*
Not that I'm asking you to maintain more than you want to,
but why not:
F: drivers/net/wireless/wl12xx/
? cheers, Joe
^ permalink raw reply
* [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: Kalle Valo @ 2009-07-21 19:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, jirislaby
In-Reply-To: <20090721191136.22374.69017.stgit@tikku>
From: Kalle Valo <kalle.valo@nokia.com>
Add myself as the maintainer for wl1251 driver.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
---
MAINTAINERS | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 18c3f0c..12be899 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6462,6 +6462,15 @@ M: mitr@volny.cz
S: Maintained
F: drivers/input/misc/wistron_btns.c
+WL1251 WIRELESS DRIVER
+P: Kalle Valo
+M: kalle.valo@nokia.com
+L: linux-wireless@vger.kernel.org
+W: http://wireless.kernel.org
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
+S: Maintained
+F: drivers/net/wireless/wl12xx/wl1251*
+
WL3501 WIRELESS PCMCIA CARD DRIVER
P: Arnaldo Carvalho de Melo
M: acme@ghostprotocols.net
^ permalink raw reply related
* [PATCH 2/3] wl1251: remove wl1251_plt_start/stop()
From: Kalle Valo @ 2009-07-21 19:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, jirislaby
In-Reply-To: <20090721191136.22374.69017.stgit@tikku>
From: Kalle Valo <kalle.valo@nokia.com>
This Production Line Testing code is currently unused and can be removed.
It can be reintroduced when nl80211 test mode implemented for the driver.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
---
drivers/net/wireless/wl12xx/wl1251_main.c | 54 -----------------------------
1 files changed, 0 insertions(+), 54 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1251_main.c b/drivers/net/wireless/wl12xx/wl1251_main.c
index cf5e054..08fcf90 100644
--- a/drivers/net/wireless/wl12xx/wl1251_main.c
+++ b/drivers/net/wireless/wl12xx/wl1251_main.c
@@ -246,60 +246,6 @@ out:
mutex_unlock(&wl->mutex);
}
-int wl1251_plt_start(struct wl1251 *wl)
-{
- int ret;
-
- mutex_lock(&wl->mutex);
-
- wl1251_notice("power up");
-
- if (wl->state != WL1251_STATE_OFF) {
- wl1251_error("cannot go into PLT state because not "
- "in off state: %d", wl->state);
- return -EBUSY;
- }
-
- wl->state = WL1251_STATE_PLT;
-
- ret = wl1251_chip_wakeup(wl);
- if (ret < 0)
- return ret;
-
- ret = wl->chip.op_boot(wl);
- if (ret < 0)
- return ret;
-
- wl1251_notice("firmware booted in PLT mode (%s)", wl->chip.fw_ver);
-
- ret = wl->chip.op_plt_init(wl);
- if (ret < 0)
- return ret;
-
- return 0;
-}
-
-int wl1251_plt_stop(struct wl1251 *wl)
-{
- mutex_lock(&wl->mutex);
-
- wl1251_notice("power down");
-
- if (wl->state != WL1251_STATE_PLT) {
- wl1251_error("cannot power down because not in PLT "
- "state: %d", wl->state);
- return -EBUSY;
- }
-
- wl1251_disable_interrupts(wl);
- wl1251_power_off(wl);
-
- wl->state = WL1251_STATE_OFF;
-
- return 0;
-}
-
-
static int wl1251_op_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
{
struct wl1251 *wl = hw->priv;
^ permalink raw reply related
* [PATCH 1/3] wl1251: remove accidentally added wl1251_netlink.c
From: Kalle Valo @ 2009-07-21 19:11 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, jirislaby
From: Kalle Valo <kalle.valo@nokia.com>
Commit "wl1251: add wl1251 prefix to all 1251 files" accidentally added
wl1251_netlink.c which contains a private netlink interface.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
---
drivers/net/wireless/wl12xx/wl1251_netlink.c | 679 --------------------------
1 files changed, 0 insertions(+), 679 deletions(-)
delete mode 100644 drivers/net/wireless/wl12xx/wl1251_netlink.c
diff --git a/drivers/net/wireless/wl12xx/wl1251_netlink.c b/drivers/net/wireless/wl12xx/wl1251_netlink.c
deleted file mode 100644
index 67d3d5a..0000000
--- a/drivers/net/wireless/wl12xx/wl1251_netlink.c
+++ /dev/null
@@ -1,679 +0,0 @@
-/*
- * This file is part of wl1251
- *
- * Copyright (C) 2008 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
- *
- */
-#include "wl1251_netlink.h"
-
-#include <linux/mutex.h>
-#include <linux/socket.h>
-#include <net/net_namespace.h>
-#include <net/sock.h>
-#include <net/genetlink.h>
-#include <net/wireless.h>
-#include <net/mac80211.h>
-
-#include "wl1251.h"
-#include "wl1251_spi.h"
-#include "wl1251_acx.h"
-
-/* FIXME: this should be changed as soon as user space catches up */
-#define WL1251_NL_NAME "wl1251"
-#define WL1251_NL_VERSION 1
-
-#define WL1251_MAX_TEST_LENGTH 1024
-#define WL1251_MAX_NVS_LENGTH 1024
-
-enum wl1251_nl_commands {
- WL1251_NL_CMD_UNSPEC,
- WL1251_NL_CMD_TEST,
- WL1251_NL_CMD_INTERROGATE,
- WL1251_NL_CMD_CONFIGURE,
- WL1251_NL_CMD_PHY_REG_READ,
- WL1251_NL_CMD_NVS_PUSH,
- WL1251_NL_CMD_REG_WRITE,
- WL1251_NL_CMD_REG_READ,
- WL1251_NL_CMD_SET_PLT_MODE,
-
- __WL1251_NL_CMD_AFTER_LAST
-};
-#define WL1251_NL_CMD_MAX (__WL1251_NL_CMD_AFTER_LAST - 1)
-
-enum wl1251_nl_attrs {
- WL1251_NL_ATTR_UNSPEC,
- WL1251_NL_ATTR_IFNAME,
- WL1251_NL_ATTR_CMD_TEST_PARAM,
- WL1251_NL_ATTR_CMD_TEST_ANSWER,
- WL1251_NL_ATTR_CMD_IE,
- WL1251_NL_ATTR_CMD_IE_LEN,
- WL1251_NL_ATTR_CMD_IE_BUFFER,
- WL1251_NL_ATTR_CMD_IE_ANSWER,
- WL1251_NL_ATTR_REG_ADDR,
- WL1251_NL_ATTR_REG_VAL,
- WL1251_NL_ATTR_NVS_BUFFER,
- WL1251_NL_ATTR_NVS_LEN,
- WL1251_NL_ATTR_PLT_MODE,
-
- __WL1251_NL_ATTR_AFTER_LAST
-};
-#define WL1251_NL_ATTR_MAX (__WL1251_NL_ATTR_AFTER_LAST - 1)
-
-static struct genl_family wl1251_nl_family = {
- .id = GENL_ID_GENERATE,
- .name = WL1251_NL_NAME,
- .hdrsize = 0,
- .version = WL1251_NL_VERSION,
- .maxattr = WL1251_NL_ATTR_MAX,
-};
-
-static struct net_device *ifname_to_netdev(struct net *net,
- struct genl_info *info)
-{
- char *ifname;
-
- if (!info->attrs[WL1251_NL_ATTR_IFNAME])
- return NULL;
-
- ifname = nla_data(info->attrs[WL1251_NL_ATTR_IFNAME]);
-
- wl1251_debug(DEBUG_NETLINK, "Looking for %s", ifname);
-
- return dev_get_by_name(net, ifname);
-}
-
-static struct wl1251 *ifname_to_wl1251(struct net *net, struct genl_info *info)
-{
- struct net_device *netdev;
- struct wireless_dev *wdev;
- struct wiphy *wiphy;
- struct ieee80211_hw *hw;
-
- netdev = ifname_to_netdev(net, info);
- if (netdev == NULL) {
- wl1251_error("Wrong interface");
- return NULL;
- }
-
- wdev = netdev->ieee80211_ptr;
- if (wdev == NULL) {
- wl1251_error("ieee80211_ptr is NULL");
- return NULL;
- }
-
- wiphy = wdev->wiphy;
- if (wiphy == NULL) {
- wl1251_error("wiphy is NULL");
- return NULL;
- }
-
- hw = wiphy_priv(wiphy);
- if (hw == NULL) {
- wl1251_error("hw is NULL");
- return NULL;
- }
-
- dev_put(netdev);
-
- return hw->priv;
-}
-
-static int wl1251_nl_test_cmd(struct sk_buff *skb, struct genl_info *info)
-{
- struct wl1251 *wl;
- struct wl1251_command *cmd;
- char *buf;
- int buf_len, ret, cmd_len;
- u8 answer;
-
- if (!info->attrs[WL1251_NL_ATTR_CMD_TEST_PARAM])
- return -EINVAL;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- return -EINVAL;
- }
-
- cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
- if (!cmd)
- return -ENOMEM;
-
- buf = nla_data(info->attrs[WL1251_NL_ATTR_CMD_TEST_PARAM]);
- buf_len = nla_len(info->attrs[WL1251_NL_ATTR_CMD_TEST_PARAM]);
- answer = nla_get_u8(info->attrs[WL1251_NL_ATTR_CMD_TEST_ANSWER]);
-
- cmd->header.id = CMD_TEST;
- memcpy(cmd->parameters, buf, buf_len);
- cmd_len = sizeof(struct wl1251_cmd_header) + buf_len;
-
- mutex_lock(&wl->mutex);
- ret = wl1251_cmd_test(wl, cmd, cmd_len, answer);
- mutex_unlock(&wl->mutex);
-
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto out;
- }
-
- if (answer) {
- struct sk_buff *msg;
- void *hdr;
-
- msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!msg) {
- ret = -ENOMEM;
- goto out;
- }
-
- hdr = genlmsg_put(msg, info->snd_pid, info->snd_seq,
- &wl1251_nl_family, 0, WL1251_NL_CMD_TEST);
- if (IS_ERR(hdr)) {
- ret = PTR_ERR(hdr);
- goto nla_put_failure;
- }
-
- NLA_PUT_STRING(msg, WL1251_NL_ATTR_IFNAME,
- nla_data(info->attrs[WL1251_NL_ATTR_IFNAME]));
- NLA_PUT(msg, WL1251_NL_ATTR_CMD_TEST_ANSWER,
- sizeof(*cmd), cmd);
-
- ret = genlmsg_end(msg, hdr);
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto nla_put_failure;
- }
-
- wl1251_debug(DEBUG_NETLINK, "TEST cmd sent, answer");
- ret = genlmsg_reply(msg, info);
- goto out;
-
- nla_put_failure:
- nlmsg_free(msg);
- } else
- wl1251_debug(DEBUG_NETLINK, "TEST cmd sent");
-
-out:
- kfree(cmd);
- return ret;
-}
-
-static int wl1251_nl_interrogate(struct sk_buff *skb, struct genl_info *info)
-{
- struct wl1251 *wl;
- struct sk_buff *msg;
- int ret = -ENOBUFS, cmd_ie, cmd_ie_len;
- struct wl1251_command *cmd;
- void *hdr;
-
- if (!info->attrs[WL1251_NL_ATTR_CMD_IE])
- return -EINVAL;
-
- if (!info->attrs[WL1251_NL_ATTR_CMD_IE_LEN])
- return -EINVAL;
-
- cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
- if (!cmd)
- return -ENOMEM;
-
- msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!msg)
- return -ENOMEM;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- ret = -EINVAL;
- goto nla_put_failure;
- }
-
- /* acx id */
- cmd_ie = nla_get_u32(info->attrs[WL1251_NL_ATTR_CMD_IE]);
-
- /* maximum length of acx, including all headers */
- cmd_ie_len = nla_get_u32(info->attrs[WL1251_NL_ATTR_CMD_IE_LEN]);
-
- wl1251_debug(DEBUG_NETLINK, "Getting IE 0x%x (len %d)",
- cmd_ie, cmd_ie_len);
-
- mutex_lock(&wl->mutex);
- ret = wl1251_cmd_interrogate(wl, cmd_ie, cmd, cmd_ie_len);
- mutex_unlock(&wl->mutex);
-
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto nla_put_failure;
- }
-
- hdr = genlmsg_put(msg, info->snd_pid, info->snd_seq,
- &wl1251_nl_family, 0, WL1251_NL_CMD_INTERROGATE);
- if (IS_ERR(hdr)) {
- ret = PTR_ERR(hdr);
- goto nla_put_failure;
- }
-
- NLA_PUT_STRING(msg, WL1251_NL_ATTR_IFNAME,
- nla_data(info->attrs[WL1251_NL_ATTR_IFNAME]));
- NLA_PUT(msg, WL1251_NL_ATTR_CMD_IE_ANSWER, cmd_ie_len, cmd);
-
- ret = genlmsg_end(msg, hdr);
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto nla_put_failure;
- }
-
- kfree(cmd);
- return genlmsg_reply(msg, info);
-
- nla_put_failure:
- kfree(cmd);
- nlmsg_free(msg);
-
- return ret;
-}
-
-static int wl1251_nl_configure(struct sk_buff *skb, struct genl_info *info)
-{
- int ret = 0, cmd_ie_len, acx_len;
- struct acx_header *acx = NULL;
- struct sk_buff *msg;
- struct wl1251 *wl;
- void *cmd_ie;
- u16 *id;
-
- if (!info->attrs[WL1251_NL_ATTR_CMD_IE_BUFFER])
- return -EINVAL;
-
- if (!info->attrs[WL1251_NL_ATTR_CMD_IE_LEN])
- return -EINVAL;
-
- msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!msg)
- return -ENOMEM;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- ret = -EINVAL;
- goto nla_put_failure;
- }
-
- /* contains the acx header but not the cmd header */
- cmd_ie = nla_data(info->attrs[WL1251_NL_ATTR_CMD_IE_BUFFER]);
-
- cmd_ie_len = nla_get_u32(info->attrs[WL1251_NL_ATTR_CMD_IE_LEN]);
-
- /* acx id is in the first two bytes */
- id = cmd_ie;
-
- /* need to add acx_header before cmd_ie, so create a new command */
- acx_len = sizeof(struct acx_header) + cmd_ie_len;
- acx = kzalloc(acx_len, GFP_KERNEL);
- if (!acx) {
- ret = -ENOMEM;
- goto nla_put_failure;
- }
-
- /* copy the acx header and the payload */
- memcpy(&acx->id, cmd_ie, cmd_ie_len);
-
- mutex_lock(&wl->mutex);
- ret = wl1251_cmd_configure(wl, *id, acx, acx_len);
- mutex_unlock(&wl->mutex);
-
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto nla_put_failure;
- }
-
- wl1251_debug(DEBUG_NETLINK, "CONFIGURE cmd sent");
-
- nla_put_failure:
- kfree(acx);
- nlmsg_free(msg);
-
- return ret;
-}
-
-static int wl1251_nl_phy_reg_read(struct sk_buff *skb, struct genl_info *info)
-{
- struct wl1251 *wl;
- struct sk_buff *msg;
- u32 reg_addr, *reg_value = NULL;
- int ret = 0;
- void *hdr;
-
- if (!info->attrs[WL1251_NL_ATTR_REG_ADDR])
- return -EINVAL;
-
- msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!msg)
- return -ENOMEM;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- ret = -EINVAL;
- goto nla_put_failure;
- }
-
- reg_value = kmalloc(sizeof(*reg_value), GFP_KERNEL);
- if (!reg_value) {
- ret = -ENOMEM;
- goto nla_put_failure;
- }
-
- reg_addr = nla_get_u32(info->attrs[WL1251_NL_ATTR_REG_ADDR]);
-
- wl1251_debug(DEBUG_NETLINK, "Reading PHY reg 0x%x", reg_addr);
-
- mutex_lock(&wl->mutex);
- ret = wl1251_cmd_read_memory(wl, reg_addr, reg_value,
- sizeof(*reg_value));
- mutex_unlock(&wl->mutex);
-
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto nla_put_failure;
- }
-
-
- hdr = genlmsg_put(msg, info->snd_pid, info->snd_seq,
- &wl1251_nl_family, 0, WL1251_NL_CMD_PHY_REG_READ);
- if (IS_ERR(hdr)) {
- ret = PTR_ERR(hdr);
- goto nla_put_failure;
- }
-
- NLA_PUT_STRING(msg, WL1251_NL_ATTR_IFNAME,
- nla_data(info->attrs[WL1251_NL_ATTR_IFNAME]));
-
- NLA_PUT_U32(msg, WL1251_NL_ATTR_REG_VAL, *reg_value);
-
- ret = genlmsg_end(msg, hdr);
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto nla_put_failure;
- }
-
- kfree(reg_value);
-
- return genlmsg_reply(msg, info);
-
- nla_put_failure:
- nlmsg_free(msg);
- kfree(reg_value);
-
- return ret;
-}
-
-static int wl1251_nl_nvs_push(struct sk_buff *skb, struct genl_info *info)
-{
- struct wl1251 *wl;
- int ret = 0;
-
- if (!info->attrs[WL1251_NL_ATTR_NVS_BUFFER])
- return -EINVAL;
-
- if (!info->attrs[WL1251_NL_ATTR_NVS_LEN])
- return -EINVAL;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- return -EINVAL;
- }
-
- mutex_lock(&wl->mutex);
- wl->nvs_len = nla_get_u32(info->attrs[WL1251_NL_ATTR_NVS_LEN]);
- if (wl->nvs_len % 4) {
- wl1251_error("NVS size is not multiple of 32: %d", wl->nvs_len);
- ret = -EILSEQ;
- goto out;
- }
-
- /* If we already have an NVS, we should free it */
- kfree(wl->nvs);
-
- wl->nvs = kzalloc(wl->nvs_len, GFP_KERNEL);
- if (wl->nvs == NULL) {
- wl1251_error("Can't allocate NVS");
- ret = -ENOMEM;
- goto out;
- }
-
- memcpy(wl->nvs,
- nla_data(info->attrs[WL1251_NL_ATTR_NVS_BUFFER]),
- wl->nvs_len);
-
- wl1251_debug(DEBUG_NETLINK, "got NVS from userspace, %d bytes",
- wl->nvs_len);
-
-out:
- mutex_unlock(&wl->mutex);
-
- return ret;
-}
-
-static int wl1251_nl_reg_read(struct sk_buff *skb, struct genl_info *info)
-{
- struct wl1251 *wl;
- u32 addr, val;
- int ret = 0;
- struct sk_buff *msg;
- void *hdr;
-
- if (!info->attrs[WL1251_NL_ATTR_REG_ADDR])
- return -EINVAL;
-
- msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!msg)
- return -ENOMEM;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- return -EINVAL;
- }
-
- addr = nla_get_u32(info->attrs[WL1251_NL_ATTR_REG_ADDR]);
-
- mutex_lock(&wl->mutex);
- val = wl1251_reg_read32(wl, addr);
- mutex_unlock(&wl->mutex);
-
- hdr = genlmsg_put(msg, info->snd_pid, info->snd_seq,
- &wl1251_nl_family, 0, WL1251_NL_CMD_PHY_REG_READ);
- if (IS_ERR(hdr)) {
- ret = PTR_ERR(hdr);
- goto nla_put_failure;
- }
-
- NLA_PUT_STRING(msg, WL1251_NL_ATTR_IFNAME,
- nla_data(info->attrs[WL1251_NL_ATTR_IFNAME]));
-
- NLA_PUT_U32(msg, WL1251_NL_ATTR_REG_VAL, val);
-
- ret = genlmsg_end(msg, hdr);
- if (ret < 0) {
- wl1251_error("%s() failed", __func__);
- goto nla_put_failure;
- }
-
- return genlmsg_reply(msg, info);
-
- nla_put_failure:
- nlmsg_free(msg);
-
- return ret;
-}
-
-static int wl1251_nl_reg_write(struct sk_buff *skb, struct genl_info *info)
-{
- struct wl1251 *wl;
- u32 addr, val;
-
- if (!info->attrs[WL1251_NL_ATTR_REG_ADDR])
- return -EINVAL;
-
- if (!info->attrs[WL1251_NL_ATTR_REG_VAL])
- return -EINVAL;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- return -EINVAL;
- }
-
- addr = nla_get_u32(info->attrs[WL1251_NL_ATTR_REG_ADDR]);
- val = nla_get_u32(info->attrs[WL1251_NL_ATTR_REG_VAL]);
-
- mutex_lock(&wl->mutex);
- wl1251_reg_write32(wl, addr, val);
- mutex_unlock(&wl->mutex);
-
- return 0;
-}
-
-static int wl1251_nl_set_plt_mode(struct sk_buff *skb, struct genl_info *info)
-{
- struct wl1251 *wl;
- u32 val;
- int ret;
-
- if (!info->attrs[WL1251_NL_ATTR_PLT_MODE])
- return -EINVAL;
-
- wl = ifname_to_wl1251(&init_net, info);
- if (wl == NULL) {
- wl1251_error("wl1251 not found");
- return -EINVAL;
- }
-
- val = nla_get_u32(info->attrs[WL1251_NL_ATTR_PLT_MODE]);
-
- switch (val) {
- case 0:
- ret = wl1251_plt_stop(wl);
- break;
- case 1:
- ret = wl1251_plt_start(wl);
- break;
- default:
- ret = -EINVAL;
- break;
- }
-
- return ret;
-}
-
-static struct nla_policy wl1251_nl_policy[WL1251_NL_ATTR_MAX + 1] = {
- [WL1251_NL_ATTR_IFNAME] = { .type = NLA_NUL_STRING,
- .len = IFNAMSIZ-1 },
- [WL1251_NL_ATTR_CMD_TEST_PARAM] = { .type = NLA_BINARY,
- .len = WL1251_MAX_TEST_LENGTH },
- [WL1251_NL_ATTR_CMD_TEST_ANSWER] = { .type = NLA_U8 },
- [WL1251_NL_ATTR_CMD_IE] = { .type = NLA_U32 },
- [WL1251_NL_ATTR_CMD_IE_LEN] = { .type = NLA_U32 },
- [WL1251_NL_ATTR_CMD_IE_BUFFER] = { .type = NLA_BINARY,
- .len = WL1251_MAX_TEST_LENGTH },
- [WL1251_NL_ATTR_CMD_IE_ANSWER] = { .type = NLA_BINARY,
- .len = WL1251_MAX_TEST_LENGTH },
- [WL1251_NL_ATTR_REG_ADDR] = { .type = NLA_U32 },
- [WL1251_NL_ATTR_REG_VAL] = { .type = NLA_U32 },
- [WL1251_NL_ATTR_NVS_BUFFER] = { .type = NLA_BINARY,
- .len = WL1251_MAX_NVS_LENGTH },
- [WL1251_NL_ATTR_NVS_LEN] = { .type = NLA_U32 },
- [WL1251_NL_ATTR_PLT_MODE] = { .type = NLA_U32 },
-};
-
-static struct genl_ops wl1251_nl_ops[] = {
- {
- .cmd = WL1251_NL_CMD_TEST,
- .doit = wl1251_nl_test_cmd,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
- {
- .cmd = WL1251_NL_CMD_INTERROGATE,
- .doit = wl1251_nl_interrogate,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
- {
- .cmd = WL1251_NL_CMD_CONFIGURE,
- .doit = wl1251_nl_configure,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
- {
- .cmd = WL1251_NL_CMD_PHY_REG_READ,
- .doit = wl1251_nl_phy_reg_read,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
- {
- .cmd = WL1251_NL_CMD_NVS_PUSH,
- .doit = wl1251_nl_nvs_push,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
- {
- .cmd = WL1251_NL_CMD_REG_WRITE,
- .doit = wl1251_nl_reg_write,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
- {
- .cmd = WL1251_NL_CMD_REG_READ,
- .doit = wl1251_nl_reg_read,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
- {
- .cmd = WL1251_NL_CMD_SET_PLT_MODE,
- .doit = wl1251_nl_set_plt_mode,
- .policy = wl1251_nl_policy,
- .flags = GENL_ADMIN_PERM,
- },
-};
-
-int wl1251_nl_register(void)
-{
- int err, i;
-
- err = genl_register_family(&wl1251_nl_family);
- if (err)
- return err;
-
- for (i = 0; i < ARRAY_SIZE(wl1251_nl_ops); i++) {
- err = genl_register_ops(&wl1251_nl_family, &wl1251_nl_ops[i]);
- if (err)
- goto err_out;
- }
- return 0;
- err_out:
- genl_unregister_family(&wl1251_nl_family);
- return err;
-}
-
-void wl1251_nl_unregister(void)
-{
- genl_unregister_family(&wl1251_nl_family);
-}
^ permalink raw reply related
* Re: ath9k rfkill behavior
From: Howard Chu @ 2009-07-21 17:21 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <200907211327.03954.chunkeey@web.de>
Christian Lamparter wrote:
> On Tuesday 21 July 2009 02:56:11 Howard Chu wrote:
>> I'm currently running 2.6.31-rc2 and noticed an annoying change in rfkill
>> behavior now; I can no longer toggle the state by echoing 0/1 into
>> sys/class/rfkill/rfkillX/state, it says write operation not permitted. I
>> haven't found any posts online related to this change in behavior, can anyone
>> point me to an explanation/rationale? The only way to change the state now
>> appears to be by using the wifi toggle switch on the laptop.
>
> http://lkml.org/lkml/2009/7/10/339
>
> but no need to patch the kernel (again):
> the legacy iwconfig tool can let you do the same:
>
> iwconfig wlanX txpower off
> and if you want it back:
> iwconfig wlanX txpower auto
>
> (or there's a nice utility there: http://git.sipsolutions.net/?p=rfkill.git )
Thanks very much, that covers everything.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
^ permalink raw reply
* Re: [ANN] rfkill: v0.1
From: Luis R. Rodriguez @ 2009-07-21 16:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <E1MTDop-0000kz-DX@sipsolutions.net>
On Tue, Jul 21, 2009 at 4:47 AM, <wireless@sipsolutions.net> wrote:
>
> A new release of rfkill (v0.1) is available at:
>
> http://wireless.kernel.org/download/rfkill/rfkill-0.1.tar.bz2
Documentation available at:
http://wireless.kernel.org/en/users/Documentation/rfkill
Luis
^ permalink raw reply
* Re: [PATCH 2.6.31] iwlagn: fix minimum number of queues setting
From: reinette chatre @ 2009-07-21 16:29 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <20090721154417.GB2721@tuxdriver.com>
Hi John,
On Tue, 2009-07-21 at 08:44 -0700, John W. Linville wrote:
> When built against 2.6.31, I get this:
>
> CC [M] drivers/net/wireless/iwlwifi/iwl3945-base.o
> In file included from drivers/net/wireless/iwlwifi/iwl3945-base.c:55:
> drivers/net/wireless/iwlwifi/iwl-3945.h:115:1: warning: "IWL_MIN_NUM_QUEUES" redefined
> In file included from drivers/net/wireless/iwlwifi/iwl-3945.h:48,
> from drivers/net/wireless/iwlwifi/iwl3945-base.c:55:
I am very sorry. This patch will fix this.
From: Reinette Chatre <reinette.chatre@intel.com>
We need to provide a reasonable minimum that will result in a
working setup if used. Set minimum to be 10 to provide for
4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
4 HT queues (one per AC).
We allow the user to change the number of queues used via a module
parameter and use this minimum value to check if it is valid. Without
this patch a user can select a value for the number of queues that
will result in a failing setup.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Reviewed-by: Tomas Winkler <tomas.winkler@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
---
This patch has already been submitted for wireless-testing, but we would
like to include this fix into 2.6.31 also if possible.
This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2011
drivers/net/wireless/iwlwifi/iwl-dev.h | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 1a2fe37..b989d5c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -258,8 +258,10 @@ struct iwl_channel_info {
#define IWL_TX_FIFO_HCCA_2 6
#define IWL_TX_FIFO_NONE 7
-/* Minimum number of queues. MAX_NUM is defined in hw specific files */
-#define IWL_MIN_NUM_QUEUES 4
+/* Minimum number of queues. MAX_NUM is defined in hw specific files.
+ * Set the minimum to accommodate the 4 standard TX queues, 1 command
+ * queue, 2 (unused) HCCA queues, and 4 HT queues (one for each AC) */
+#define IWL_MIN_NUM_QUEUES 10
/* Power management (not Tx power) structures */
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.h b/drivers/net/wireless/iwlwifi/iwl-3945.h
index fbb3a57..2de6471 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.h
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.h
@@ -112,7 +112,7 @@ enum iwl3945_antenna {
#define IWL_TX_FIFO_NONE 7
/* Minimum number of queues. MAX_NUM is defined in hw specific files */
-#define IWL_MIN_NUM_QUEUES 4
+#define IWL39_MIN_NUM_QUEUES 4
#define IEEE80211_DATA_LEN 2304
#define IEEE80211_4ADDR_LEN 30
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index cb9bd4c..b01fba3 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4020,10 +4020,10 @@ static int iwl3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
SET_IEEE80211_DEV(hw, &pdev->dev);
if ((iwl3945_mod_params.num_of_queues > IWL39_MAX_NUM_QUEUES) ||
- (iwl3945_mod_params.num_of_queues < IWL_MIN_NUM_QUEUES)) {
+ (iwl3945_mod_params.num_of_queues < IWL39_MIN_NUM_QUEUES)) {
IWL_ERR(priv,
"invalid queues_num, should be between %d and %d\n",
- IWL_MIN_NUM_QUEUES, IWL39_MAX_NUM_QUEUES);
+ IWL39_MIN_NUM_QUEUES, IWL39_MAX_NUM_QUEUES);
err = -EINVAL;
goto out_ieee80211_free_hw;
}
^ permalink raw reply related
* Re: [PATCH 2.6.31] iwlagn: fix minimum number of queues setting
From: John W. Linville @ 2009-07-21 15:44 UTC (permalink / raw)
To: Reinette Chatre; +Cc: linux-wireless, ipw3945-devel
In-Reply-To: <1247848476-24185-1-git-send-email-reinette.chatre@intel.com>
On Fri, Jul 17, 2009 at 09:34:36AM -0700, Reinette Chatre wrote:
> From: Reinette Chatre <reinette.chatre@intel.com>
>
> We need to provide a reasonable minimum that will result in a
> working setup if used. Set minimum to be 10 to provide for
> 4 standard TX queues + 1 command queue + 2 (unused) HCCA queues +
> 4 HT queues (one per AC).
>
> We allow the user to change the number of queues used via a module
> parameter and use this minimum value to check if it is valid. Without
> this patch a user can select a value for the number of queues that
> will result in a failing setup.
>
> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com>
> Acked-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
> This patch has already been submitted for wireless-testing, but we would
> like to include this fix into 2.6.31 also if possible.
>
> This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2011
When built against 2.6.31, I get this:
CC [M] drivers/net/wireless/iwlwifi/iwl3945-base.o
In file included from drivers/net/wireless/iwlwifi/iwl3945-base.c:55:
drivers/net/wireless/iwlwifi/iwl-3945.h:115:1: warning: "IWL_MIN_NUM_QUEUES" redefined
In file included from drivers/net/wireless/iwlwifi/iwl-3945.h:48,
from drivers/net/wireless/iwlwifi/iwl3945-base.c:55:
drivers/net/wireless/iwlwifi/iwl-dev.h:264:1: warning: this is the location of the previous definition
CC [M] drivers/net/wireless/iwlwifi/iwl-3945.o
In file included from drivers/net/wireless/iwlwifi/iwl-3945.c:45:
drivers/net/wireless/iwlwifi/iwl-3945.h:115:1: warning: "IWL_MIN_NUM_QUEUES" redefined
In file included from drivers/net/wireless/iwlwifi/iwl-3945.h:48,
from drivers/net/wireless/iwlwifi/iwl-3945.c:45:
drivers/net/wireless/iwlwifi/iwl-dev.h:264:1: warning: this is the location of the previous definition
CC [M] drivers/net/wireless/iwlwifi/iwl-3945-rs.o
In file included from drivers/net/wireless/iwlwifi/iwl-3945-rs.c:40:
drivers/net/wireless/iwlwifi/iwl-3945.h:115:1: warning: "IWL_MIN_NUM_QUEUES" redefined
In file included from drivers/net/wireless/iwlwifi/iwl-3945.h:48,
from drivers/net/wireless/iwlwifi/iwl-3945-rs.c:40:
drivers/net/wireless/iwlwifi/iwl-dev.h:264:1: warning: this is the location of the previous definition
CC [M] drivers/net/wireless/iwlwifi/iwl-3945-led.o
In file included from drivers/net/wireless/iwlwifi/iwl-3945-led.c:43:
drivers/net/wireless/iwlwifi/iwl-3945.h:115:1: warning: "IWL_MIN_NUM_QUEUES" redefined
In file included from drivers/net/wireless/iwlwifi/iwl-3945.h:48,
from drivers/net/wireless/iwlwifi/iwl-3945-led.c:43:
drivers/net/wireless/iwlwifi/iwl-dev.h:264:1: warning: this is the location of the previous definition
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ 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