* Re: [PATCH] mac80211: don't sleep in mesh_path_add allocation
From: Johannes Berg @ 2009-07-15 18:17 UTC (permalink / raw)
To: Andrey Yurovsky; +Cc: linux-wireless, javier
In-Reply-To: <1247680936-21513-1-git-send-email-andrey@cozybit.com>
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
On Wed, 2009-07-15 at 11:02 -0700, Andrey Yurovsky wrote:
> mesh_path_add allocates an mpath and a node but it is called with RCU
> held. Use the GFP_ATOMIC flag to prevent these allocations from
> sleeping since otherwise we can hit the following sleep-while-atomic:
This isn't sufficient, quoting from the function, highlight added:
int mesh_path_add(u8 *dst, struct ieee80211_sub_if_data *sdata)
{
...
if (grow) {
struct mesh_table *oldtbl, *newtbl;
write_lock(&pathtbl_resize_lock);
oldtbl = mesh_paths;
newtbl = mesh_table_grow(mesh_paths);
if (!newtbl) {
write_unlock(&pathtbl_resize_lock);
return 0;
}
rcu_assign_pointer(mesh_paths, newtbl);
write_unlock(&pathtbl_resize_lock);
******* synchronize_rcu();
mesh_table_free(oldtbl, false);
}
...
}
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: any controller working in AP mode ?
From: Andrey Yurovsky @ 2009-07-15 18:12 UTC (permalink / raw)
To: Ram kumar; +Cc: linux-wireless
In-Reply-To: <6306c640907142221o27c257aaw12f73da8118376f@mail.gmail.com>
On Tue, Jul 14, 2009 at 10:21 PM, Ram kumar<ramkumar.research@gmail.com> wrote:
> 2.Marvell 8388 controller supports AP mode,but it seems marvell has
> not released the AP mode firmware.
http://wireless.kernel.org/en/users/Drivers/libertastf
> 3.Any info on wireless controller that supports AP mode will be helpful to me.
Perhaps the rt2x00 driver? I've used the USB variant (rt73usb) in AP
mode before but haven't tried it recently.
-Andrey
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Luis R. Rodriguez @ 2009-07-15 18:00 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, linux-kernel, Johannes Berg, John W. Linville,
Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <43e72e890907150851m69cd2de6lfb71596fbfac30e6@mail.gmail.com>
On Wed, Jul 15, 2009 at 8:51 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
>> On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
>>> I'm working on Wake-on-Wireless support for wireless right now [1].
>>> Upon wake up I wanted to inform the kernel of the event which caused
>>> the wake up but am not clear if there is a generic API for this. Mind
>>> you, for WoW we'll need at least some AC power to the card so we'll
>>> need to at least be in S3-Hot so we'll only need events for that for
>>> now.
>>>
>>> Do we have some generic infrastructure to gather reasons for wake up
>>> from S1-S4 and pass this to userspace yet?
>>
>> I do not think generic api exists...
Going back to this topic -- any suggestions? Will a generic netlink
family be OK? Or perhaps easier a udev event for some suitable
existing parent ?
Luis
^ permalink raw reply
* [PATCH] mac80211: don't sleep in mesh_path_add allocation
From: Andrey Yurovsky @ 2009-07-15 18:02 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, javier, Andrey Yurovsky
mesh_path_add allocates an mpath and a node but it is called with RCU
held. Use the GFP_ATOMIC flag to prevent these allocations from
sleeping since otherwise we can hit the following sleep-while-atomic:
[425889.502761] BUG: scheduling while atomic: ping/23249/0x10000100
[425889.503220] Modules linked in: ath5k mac80211 ath [last unloaded:
ath]
[425889.504563] Pid: 23249, comm: ping Not tainted 2.6.31-rc2-wl #13
[425889.505034] Call Trace:
[425889.505441] [<c1026534>] __schedule_bug+0x48/0x4d
[425889.506056] [<c13e9945>] schedule+0x8c/0x792
[425889.506659] [<c10047b9>] ? handle_irq+0x3b/0x46
[425889.507138] [<c1003f9b>] ? do_IRQ+0x80/0x96
[425889.507727] [<c10030c9>] ? common_interrupt+0x29/0x30
[425889.508227] [<c102c092>] ? vprintk+0x2a7/0x2ca
[425889.508809] [<c1027f09>] __cond_resched+0x16/0x2c
[425889.509286] [<c13ea139>] _cond_resched+0x24/0x2f
[425889.509881] [<c109a164>] __kmalloc+0x87/0x110
[425889.510636] [<c853d774>] ? kzalloc+0xb/0xd [mac80211]
[425889.511572] [<c853d774>] kzalloc+0xb/0xd [mac80211]
[425889.512513] [<c853e165>] mesh_path_add+0x289/0x29a [mac80211]
[425889.513498] [<c853f285>] mesh_nexthop_lookup+0x3c/0x164 [mac80211]
[425889.514477] [<c85365a4>] ieee80211_xmit+0xef/0x2ab [mac80211]
[425889.515438] [<c853757d>] ieee80211_subif_start_xmit+0x69a/0x6b5
[mac80211]
[425889.516174] [<c130ecb6>] dev_hard_start_xmit+0x20e/0x2a1
[425889.516841] [<c10300fc>] ? local_bh_enable_ip+0x8/0xa
[425889.517340] [<c131cb53>] __qdisc_run+0xbf/0x1a0
[425889.517897] [<c130f08a>] dev_queue_xmit+0x25b/0x350
[425889.518364] [<c13143fe>] neigh_resolve_output+0x1e7/0x231
[425889.519012] [<c133a0d0>] ip_finish_output2+0x1a5/0x1cf
[425889.519677] [<c133a159>] ip_finish_output+0x5f/0x62
[425889.520183] [<c133a1e6>] ip_output+0x8a/0x8f
[425889.520804] [<c13395ed>] ip_local_out+0x18/0x1b
[425889.521310] [<c1339860>] ip_push_pending_frames+0x270/0x2ce
[425889.521956] [<c135077f>] raw_sendmsg+0x5f0/0x671
[425889.522451] [<c1357e4a>] inet_sendmsg+0x3b/0x48
[425889.523061] [<c1301ee4>] __sock_sendmsg+0x45/0x4e
[425889.523686] [<c130266d>] sock_sendmsg+0xb8/0xce
[425889.524182] [<c103cb47>] ? autoremove_wake_function+0x0/0x33
[425889.525104] [<c8535061>] ? __ieee80211_rx+0x4a7/0x4f6 [mac80211]
[425889.525941] [<c858663f>] ? ath5k_rxbuf_setup+0x6d/0x8d [ath5k]
[425889.526749] [<c857c46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k]
[425889.527329] [<c1176549>] ? copy_from_user+0x2a/0x111
[425889.528004] [<c1309805>] ? verify_iovec+0x40/0x6f
[425889.528634] [<c13027c2>] sys_sendmsg+0x13f/0x192
[425889.529139] [<c1043d6a>] ? getnstimeofday+0x52/0xd2
[425889.529782] [<c1040beb>] ? sched_clock_cpu+0x8d/0x2e9
[425889.530301] [<c1021d53>] ? task_tick_fair+0x1d/0x9e
[425889.530922] [<c1028372>] ? scheduler_tick+0xc8/0x1df
[425889.531412] [<c103f29a>] ? hrtimer_run_pending+0x2d/0xa7
[425889.532017] [<c103373d>] ? run_timer_softirq+0x32/0x190
[425889.532632] [<c13037ff>] sys_socketcall+0x153/0x183
[425889.533103] [<c1003f9b>] ? do_IRQ+0x80/0x96
[425889.533694] [<c1002ab5>] syscall_call+0x7/0xb
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
---
net/mac80211/mesh_pathtbl.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 1ede8cb..42237fd 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -204,11 +204,11 @@ int mesh_path_add(u8 *dst, struct ieee80211_sub_if_data *sdata)
return -ENOSPC;
err = -ENOMEM;
- new_mpath = kzalloc(sizeof(struct mesh_path), GFP_KERNEL);
+ new_mpath = kzalloc(sizeof(struct mesh_path), GFP_ATOMIC);
if (!new_mpath)
goto err_path_alloc;
- new_node = kmalloc(sizeof(struct mpath_node), GFP_KERNEL);
+ new_node = kmalloc(sizeof(struct mpath_node), GFP_ATOMIC);
if (!new_node)
goto err_node_alloc;
--
1.5.6.3
^ permalink raw reply related
* [PATCH v2 01/21] mac80211: drop frames for sta with no valid rate
From: Luis R. Rodriguez @ 2009-07-15 17:52 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez
When we're associated we should be able to send data to
target sta. If we cannot we may be trying to use the incorrect
band to talk to the sta. Lets catch any such cases, warn, and
drop the frames to not invalidate assumptions being made on
rate control algorithms when they have a valid sta to
communicate with. Any such cases should be handled and fixed.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
This v2 takes into account johill's comments. Lines diff
count matches to the previous patch and there are no other
patches I posted which touch net/mac80211/tx.c so I don't
expect any conflicts with the other pending patches.
include/net/mac80211.h | 11 +++++++++++
net/mac80211/tx.c | 23 +++++++++++++++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 14ef478..9428258 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2113,6 +2113,17 @@ rate_lowest_index(struct ieee80211_supported_band *sband,
return 0;
}
+static inline
+bool rate_usable_index_exists(struct ieee80211_supported_band *sband,
+ struct ieee80211_sta *sta)
+{
+ unsigned int i;
+
+ for (i = 0; i < sband->n_bitrates; i++)
+ if (rate_supported(sta, sband->band, i))
+ return true;
+ return false;
+}
int ieee80211_rate_control_register(struct rate_control_ops *ops);
void ieee80211_rate_control_unregister(struct rate_control_ops *ops);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 969a4b2..ab1152c 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -512,6 +512,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
int i, len;
bool inval = false, rts = false, short_preamble = false;
struct ieee80211_tx_rate_control txrc;
+ u32 sta_flags;
memset(&txrc, 0, sizeof(txrc));
@@ -544,7 +545,29 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
(tx->sta && test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE))))
txrc.short_preamble = short_preamble = true;
+ sta_flags = tx->sta ? get_sta_flags(tx->sta) : 0;
+ /*
+ * Lets not bother rate control if we're associated and cannot
+ * talk to the sta. This should not happen.
+ */
+ if (WARN((tx->local->sw_scanning) &&
+ (sta_flags & WLAN_STA_ASSOC) &&
+ !rate_usable_index_exists(sband, &tx->sta->sta),
+ "No usable bitrate found while scanning and associated\n")) {
+#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
+ printk(KERN_DEBUG "%s: dropped data frame -- no "
+ "supported rate for station %pM on %c GHz band\n",
+ tx->dev->name, hdr->addr1,
+ tx->channel->band ? '5' : '2');
+#endif /* CONFIG_MAC80211_VERBOSE_DEBUG */
+ return TX_DROP;
+ }
+
+ /*
+ * If we're associated with the sta at this point we know we can at
+ * least send the frame at the lowest bit rate.
+ */
rate_control_get_rate(tx->sdata, tx->sta, &txrc);
if (unlikely(info->control.rates[0].idx < 0))
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 3/5] cfg80211: add WoW support
From: Luis R. Rodriguez @ 2009-07-15 16:33 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <1247674829.10754.21.camel@johannes.local>
On Wed, Jul 15, 2009 at 09:20:29AM -0700, Johannes Berg wrote:
> On Wed, 2009-07-15 at 09:16 -0700, Luis R. Rodriguez wrote:
> > On Wed, Jul 15, 2009 at 09:05:06AM -0700, Johannes Berg wrote:
> > > On Wed, 2009-07-15 at 08:14 -0700, Luis R. Rodriguez wrote:
> > > > > > + if (!(wiphy->wow_triggers_supported & triggers_requested)) {
> > > > > > + err = -EOPNOTSUPP;
> > > > > > + goto out;
> > > > >
> > > > > This seems wrong, should be "requested & supported != requested", I
> > > > > think.
> > > >
> > > > The above one won't return -EOPNOTSUPP when you add additional junk, you're
> > > > right, better to just inform userspace of that.
> > >
> > > Your version also disallows turning off WoW again, afaict.
> >
> > That is something we do want, as otherwise we'll keep the device powered on.
> > Will consider both.
>
> Huh? There has to be a way to turn off wow again after you've actually
> resumed for other reasons, or whatever.
Yes, we want that.
Luis
^ permalink raw reply
* Re: Unable to load iwlagn module: Failed to register hw (error -17)
From: Luis R. Rodriguez @ 2009-07-15 16:25 UTC (permalink / raw)
To: Johannes Berg
Cc: reinette chatre, John Ranson, linux-wireless@vger.kernel.org
In-Reply-To: <1247674310.10754.19.camel@johannes.local>
On Wed, Jul 15, 2009 at 9:11 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> Hi,
>
>> On Tue, 2009-07-14 at 21:25 -0700, John Ranson wrote:
>> > [ 4.252445] iwlagn 0000:03:00.0: Tunable channels: 11 802.11bg, 13
>> > 802.11a channels
>> > [ 4.252556] iwlagn 0000:03:00.0: irq 30 for MSI/MSI-X
>> > [ 4.252945] iwlagn 0000:03:00.0: Failed to register hw (error -17)
>> > [ 4.253255] iwlagn 0000:03:00.0: PCI INT A disabled
>> > [ 4.253263] iwlagn: probe of 0000:03:00.0 failed with error -17
>>
>> This is ieee80211_register_hw() returning error 17 (EEXIST). One spot I
>> saw where this can happen is if you are trying to register with the same
>> name (wlanX) already used by another netdevice. Does this sound possible
>> in your setup?
>>
>> Johannes - do you perhaps have an idea when this can happen?
>
> This is strange -- I've had one report of this with 3945 which went away
> and seemed to have been a compat only issue, I suspect this is also just
> a compat-wireless issue, but I have no idea.
We've had a lot of changes to compat-wireless recently so this is possible.
John, can you cat compat-release on your compat-wireless directory?
Luis
^ permalink raw reply
* Re: Unable to load iwlagn module: Failed to register hw (error -17)
From: Johannes Berg @ 2009-07-15 16:21 UTC (permalink / raw)
To: reinette chatre; +Cc: John Ranson, linux-wireless@vger.kernel.org
In-Reply-To: <1247674573.17896.1989.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]
On Wed, 2009-07-15 at 09:16 -0700, reinette chatre wrote:
> > -EEXIST should only happen if something has already claimed something in
> > sysfs, but not with netdevs (i.e. wlan0 would just be renamed to wlan1)
> > and phy0 is numbered all the time so that can't be it either. I don't
> > know.
>
> fyi ... I based my response on register_netdevice() being able to return
> -EEXIST at the time it checks for the existence of "name".
Yes, it does that, but we don't ask it for a fixed name -- we allocate
"wlan%d" and in the same rtnl-locked section register it, so we should
always get a new number and be able to register that number.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] cfg80211: add WoW support
From: Johannes Berg @ 2009-07-15 16:20 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <20090715161600.GF5682@mosca>
[-- Attachment #1: Type: text/plain, Size: 876 bytes --]
On Wed, 2009-07-15 at 09:16 -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 15, 2009 at 09:05:06AM -0700, Johannes Berg wrote:
> > On Wed, 2009-07-15 at 08:14 -0700, Luis R. Rodriguez wrote:
> > > > > + if (!(wiphy->wow_triggers_supported & triggers_requested)) {
> > > > > + err = -EOPNOTSUPP;
> > > > > + goto out;
> > > >
> > > > This seems wrong, should be "requested & supported != requested", I
> > > > think.
> > >
> > > The above one won't return -EOPNOTSUPP when you add additional junk, you're
> > > right, better to just inform userspace of that.
> >
> > Your version also disallows turning off WoW again, afaict.
>
> That is something we do want, as otherwise we'll keep the device powered on.
> Will consider both.
Huh? There has to be a way to turn off wow again after you've actually
resumed for other reasons, or whatever.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] mac80211: add WoW support
From: Luis R. Rodriguez @ 2009-07-15 16:18 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <1247673831.10754.12.camel@johannes.local>
On Wed, Jul 15, 2009 at 09:03:51AM -0700, Johannes Berg wrote:
> On Wed, 2009-07-15 at 08:22 -0700, Luis R. Rodriguez wrote:
> > On Wed, Jul 15, 2009 at 04:57:35AM -0700, Johannes Berg wrote:
> > > On Tue, 2009-07-14 at 20:21 -0400, Luis R. Rodriguez wrote:
> > > > If we're associated and have not already gone into PS mode
> > > > we ensure send a nullfunc frame before going to suspend. Upon
> > > > resume we ensure we restore PS mode if it was enabled and inform
> > > > the driver accordingly, also notify the AP we're awake.
> > > >
> > > > WoW requires the radio to be left on during suspend, to do this
> > > > we inform drivers of the requested wow triggers on the mac80211
> > > > stop callback.
> > >
> > > I don't think this patch would work if ath9k unprogrammed the hardware
> > > correctly in ->remove_interface(), since you don't seem to skip that
> > > call.
> >
> > We just stop ANI in remove interface and reclaim beacon resources.
> > As per documentation it seems we are not correctly removing the MAC
> > address in ath9k for the removed interface to stop sending ACKs back.
> > I'd rather see that as a separate patch fix, but you do have a point.
> > As is right now though this doesn't affect WoW.
>
> You haven't understood my point -- it makes your WoW patch invalid
> because drivers that implement remove_interface properly cannot possibly
> implement WoW this way.
Ah sure, will respin and add some stuff for this...
Luis
^ permalink raw reply
* Re: Unable to load iwlagn module: Failed to register hw (error -17)
From: reinette chatre @ 2009-07-15 16:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Ranson, linux-wireless@vger.kernel.org
In-Reply-To: <1247674310.10754.19.camel@johannes.local>
On Wed, 2009-07-15 at 09:11 -0700, Johannes Berg wrote:
> Hi,
>
> > On Tue, 2009-07-14 at 21:25 -0700, John Ranson wrote:
> > > [ 4.252445] iwlagn 0000:03:00.0: Tunable channels: 11 802.11bg, 13
> > > 802.11a channels
> > > [ 4.252556] iwlagn 0000:03:00.0: irq 30 for MSI/MSI-X
> > > [ 4.252945] iwlagn 0000:03:00.0: Failed to register hw (error -17)
> > > [ 4.253255] iwlagn 0000:03:00.0: PCI INT A disabled
> > > [ 4.253263] iwlagn: probe of 0000:03:00.0 failed with error -17
> >
> > This is ieee80211_register_hw() returning error 17 (EEXIST). One spot I
> > saw where this can happen is if you are trying to register with the same
> > name (wlanX) already used by another netdevice. Does this sound possible
> > in your setup?
> >
> > Johannes - do you perhaps have an idea when this can happen?
>
> This is strange -- I've had one report of this with 3945 which went away
> and seemed to have been a compat only issue, I suspect this is also just
> a compat-wireless issue, but I have no idea.
>
> -EEXIST should only happen if something has already claimed something in
> sysfs, but not with netdevs (i.e. wlan0 would just be renamed to wlan1)
> and phy0 is numbered all the time so that can't be it either. I don't
> know.
fyi ... I based my response on register_netdevice() being able to return
-EEXIST at the time it checks for the existence of "name".
Reinette
^ permalink raw reply
* Re: [PATCH 3/5] cfg80211: add WoW support
From: Luis R. Rodriguez @ 2009-07-15 16:16 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <1247673906.10754.14.camel@johannes.local>
On Wed, Jul 15, 2009 at 09:05:06AM -0700, Johannes Berg wrote:
> On Wed, 2009-07-15 at 08:14 -0700, Luis R. Rodriguez wrote:
> > > > + if (!(wiphy->wow_triggers_supported & triggers_requested)) {
> > > > + err = -EOPNOTSUPP;
> > > > + goto out;
> > >
> > > This seems wrong, should be "requested & supported != requested", I
> > > think.
> >
> > The above one won't return -EOPNOTSUPP when you add additional junk, you're
> > right, better to just inform userspace of that.
>
> Your version also disallows turning off WoW again, afaict.
That is something we do want, as otherwise we'll keep the device powered on.
Will consider both.
Luis
^ permalink raw reply
* Re: Unable to load iwlagn module: Failed to register hw (error -17)
From: Johannes Berg @ 2009-07-15 16:11 UTC (permalink / raw)
To: reinette chatre; +Cc: John Ranson, linux-wireless@vger.kernel.org
In-Reply-To: <1247673740.17896.1983.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
Hi,
> On Tue, 2009-07-14 at 21:25 -0700, John Ranson wrote:
> > [ 4.252445] iwlagn 0000:03:00.0: Tunable channels: 11 802.11bg, 13
> > 802.11a channels
> > [ 4.252556] iwlagn 0000:03:00.0: irq 30 for MSI/MSI-X
> > [ 4.252945] iwlagn 0000:03:00.0: Failed to register hw (error -17)
> > [ 4.253255] iwlagn 0000:03:00.0: PCI INT A disabled
> > [ 4.253263] iwlagn: probe of 0000:03:00.0 failed with error -17
>
> This is ieee80211_register_hw() returning error 17 (EEXIST). One spot I
> saw where this can happen is if you are trying to register with the same
> name (wlanX) already used by another netdevice. Does this sound possible
> in your setup?
>
> Johannes - do you perhaps have an idea when this can happen?
This is strange -- I've had one report of this with 3945 which went away
and seemed to have been a compat only issue, I suspect this is also just
a compat-wireless issue, but I have no idea.
-EEXIST should only happen if something has already claimed something in
sysfs, but not with netdevs (i.e. wlan0 would just be renamed to wlan1)
and phy0 is numbered all the time so that can't be it either. I don't
know.
John, can you poke around in sysfs, /sys/class/ieee80211/ and see if
there's anything there when loading fails?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3 v3] net/compat/wext: send different messages to compat tasks
From: David Miller @ 2009-07-15 16:08 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1246483562.8154.11.camel@johannes.local>
Ok, all 3 patches applied to net-next-2.6, let's see what explodes ;-)
^ permalink raw reply
* Re: [PATCH 01/21] mac80211: drop frames for sta with no valid rate
From: Johannes Berg @ 2009-07-15 16:05 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <20090715145601.GA5682@mosca>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Wed, 2009-07-15 at 07:56 -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 15, 2009 at 04:58:41AM -0700, Johannes Berg wrote:
> > On Tue, 2009-07-14 at 20:13 -0400, Luis R. Rodriguez wrote:
> >
> > > + if (unlikely((tx->local->sw_scanning) &&
> > > + (sta_flags & WLAN_STA_ASSOC) &&
> > > + !rate_usable_index_exists(sband, &tx->sta->sta))) {
> > > +#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
> > > + printk(KERN_DEBUG "%s: dropped data frame -- no "
> > > + "supported rate for station %pM on %c GHz band\n",
> > > + tx->dev->name, hdr->addr1,
> > > + tx->channel->band ? '5' : '2');
> > > +#endif /* CONFIG_MAC80211_VERBOSE_DEBUG */
> > > + WARN_ON(1);
> > > + return TX_DROP;
> >
> > Can you use WARN(),
>
> sure.
>
> > and put it into the if() please?
>
> It is already in the if() branch, do you mean in the #ifdef?
No, I mean if (WARN(...)) return TX_DROP;
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] cfg80211: add WoW support
From: Johannes Berg @ 2009-07-15 16:05 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <20090715151425.GC5682@mosca>
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
On Wed, 2009-07-15 at 08:14 -0700, Luis R. Rodriguez wrote:
> Will change it, thanks. I see NLMSG_DEFAULT_SIZE is smaller than
> NLMSG_GOODSIZE (it removes the NLMSG_HDRLEN), but no documentation
> for either, when should I use either?
I don't know, but GOODSIZE is larger than a page or something, iirc.
There was a patch recently changing all the users.
> > > + if (!(wiphy->wow_triggers_supported & triggers_requested)) {
> > > + err = -EOPNOTSUPP;
> > > + goto out;
> >
> > This seems wrong, should be "requested & supported != requested", I
> > think.
>
> The above one won't return -EOPNOTSUPP when you add additional junk, you're
> right, better to just inform userspace of that.
Your version also disallows turning off WoW again, afaict.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] mac80211: add WoW support
From: Johannes Berg @ 2009-07-15 16:03 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <20090715152250.GD5682@mosca>
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]
On Wed, 2009-07-15 at 08:22 -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 15, 2009 at 04:57:35AM -0700, Johannes Berg wrote:
> > On Tue, 2009-07-14 at 20:21 -0400, Luis R. Rodriguez wrote:
> > > If we're associated and have not already gone into PS mode
> > > we ensure send a nullfunc frame before going to suspend. Upon
> > > resume we ensure we restore PS mode if it was enabled and inform
> > > the driver accordingly, also notify the AP we're awake.
> > >
> > > WoW requires the radio to be left on during suspend, to do this
> > > we inform drivers of the requested wow triggers on the mac80211
> > > stop callback.
> >
> > I don't think this patch would work if ath9k unprogrammed the hardware
> > correctly in ->remove_interface(), since you don't seem to skip that
> > call.
>
> We just stop ANI in remove interface and reclaim beacon resources.
> As per documentation it seems we are not correctly removing the MAC
> address in ath9k for the removed interface to stop sending ACKs back.
> I'd rather see that as a separate patch fix, but you do have a point.
> As is right now though this doesn't affect WoW.
You haven't understood my point -- it makes your WoW patch invalid
because drivers that implement remove_interface properly cannot possibly
implement WoW this way.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Unable to load iwlagn module: Failed to register hw (error -17)
From: reinette chatre @ 2009-07-15 16:02 UTC (permalink / raw)
To: John Ranson; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <bcd1ba70907142125y35c78cf5v251953eafede0e74@mail.gmail.com>
Hi John,
On Tue, 2009-07-14 at 21:25 -0700, John Ranson wrote:
> [ 4.252445] iwlagn 0000:03:00.0: Tunable channels: 11 802.11bg, 13
> 802.11a channels
> [ 4.252556] iwlagn 0000:03:00.0: irq 30 for MSI/MSI-X
> [ 4.252945] iwlagn 0000:03:00.0: Failed to register hw (error -17)
> [ 4.253255] iwlagn 0000:03:00.0: PCI INT A disabled
> [ 4.253263] iwlagn: probe of 0000:03:00.0 failed with error -17
This is ieee80211_register_hw() returning error 17 (EEXIST). One spot I
saw where this can happen is if you are trying to register with the same
name (wlanX) already used by another netdevice. Does this sound possible
in your setup?
Johannes - do you perhaps have an idea when this can happen?
Reinette
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Luis R. Rodriguez @ 2009-07-15 15:56 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, linux-kernel, Johannes Berg, John W. Linville,
Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <43e72e890907150851m69cd2de6lfb71596fbfac30e6@mail.gmail.com>
On Wed, Jul 15, 2009 at 8:51 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
>> I thought that wifi stack is in software -> you need
>> main cpu to run for wifi to work?
>
> Yes, but we are not processing 802.11 frames for data processing and
> sending them up to any higher layer, we're just doing raw hardware
> pattern matching and event triggering. This of course also means
> devices which do not a CPU or a CPU but no special WoW firmware that
> you won't be able to use WPA for group key stuff for example for which
> I do believe we do need the box's CPU. Which reminds me, maybe we
> should not allow WoW for that case for now.
I should clarify a little more here. It is true you need the main CPU
for wifi to "work", but you don't need it to have the wireless
device's radio turned on, or other logical components of the hardware
sending a PCI PME, for example. All you need for that is some juice.
"Work" in the usual sense would mean to process your raw 802.11
frames, and send them up the stack. That's the part we leave off to
the CPU/driver.
Luis
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Luis R. Rodriguez @ 2009-07-15 15:51 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, linux-kernel, Johannes Berg, John W. Linville,
Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <20090714235332.GA1552@ucw.cz>
On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
> On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
>> I'm working on Wake-on-Wireless support for wireless right now [1].
>> Upon wake up I wanted to inform the kernel of the event which caused
>> the wake up but am not clear if there is a generic API for this. Mind
>> you, for WoW we'll need at least some AC power to the card so we'll
>> need to at least be in S3-Hot so we'll only need events for that for
>> now.
>>
>> Do we have some generic infrastructure to gather reasons for wake up
>> from S1-S4 and pass this to userspace yet?
>
> I do not think generic api exists...
>
> How does it work?
I tried to brain dump as much as I could on the WoW wiki page [1]. In
essence we send keep alive messages (null data frames) and since we're
in PS mode the AP buffers the frames for us. At least for Atheros
ath9k devices we don't have any option but to not process any frames
sent to us from the AP except for WoW hardware processing. For WoW we
have a few triggers, with user patterns we can customize a wakeup upon
ARP requests, for example, but right now I've only enabled and tested
Magic Packet.
> I thought that wifi stack is in software -> you need
> main cpu to run for wifi to work?
Yes, but we are not processing 802.11 frames for data processing and
sending them up to any higher layer, we're just doing raw hardware
pattern matching and event triggering. This of course also means
devices which do not a CPU or a CPU but no special WoW firmware that
you won't be able to use WPA for group key stuff for example for which
I do believe we do need the box's CPU. Which reminds me, maybe we
should not allow WoW for that case for now.
> ...and what are the applications?
Same as with Ethernet, only difference this is 802.11. Also not all
Ethernet drivers support WoL.
> I understand that WoL is useful for
> remote administration of connected desktops.
Sure, I for instance want to be able to use WoL and WoW to power up my
machines at home when I walk in and my Android associates to my AP.
Some devices may be connected through Ethernet some not.
>> [1] http://wireless.kernel.org/en/users/Documentation/WoW
Luis
^ permalink raw reply
* Re: unable to bring up iwlagn wireless after update from 2.6.29.6 to 2.6.31-rc3
From: reinette chatre @ 2009-07-15 15:45 UTC (permalink / raw)
To: Thomas Backlund; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <4A5D0A7F.5090108@mandriva.org>
Thomas,
On Tue, 2009-07-14 at 15:45 -0700, Thomas Backlund wrote:
> Johannes Berg skrev:
> > On Wed, 2009-07-15 at 01:15 +0300, Thomas Backlund wrote:
> >> Hi,
> >> (please cc me on replies)
> >>
> >> before I start to try and figure this out, I thought of asking here if
> >> it rings any bells...
> >>
> >> Distribution: Mandriva Cooker
> >> Arch: x86_64.
> >>
> >> NIC: 04:00.0 Network controller [0280]: Intel Corporation PRO/Wireless
> >> 4965 AG or AGN [Kedron] Network Connection [8086:4229] (rev 61)
> >>
> >> ucode version: 228.61.2.24
> >>
> >> wpa_supplicant version: 0.6.9
> >> crda version: 1.1.0
> >> wireless-regdb version: 2009.04.17
> >>
> >> Running a 2.6.29.6 based kernel works with iwlagn
> >> Running a 2.6.30.1 based kernel works with iwlagn
> >>
> >> Running a 2.6.31-rc3 based kernel gets me this:
> >>
> >> --- cut ---
> >> Bringing up interface wlan0: RTNETLINK answers: Unknown error 132
> >> RTNETLINK answers: Unknown error 132
> >
> > press your rfkill button.
>
> I wish it was that simple :-(
>
> I already tried it, but it does not help...
> I get no reaction what so ever from pressing it...
>
> The laptop is an Acer 5720G if that makes any difference...
>
> Could it be that rfkill has been broken for my laptop ?
>
> And why should I need to press rfkill now, when I didn't before ?
> Has some kernel defaults changed since 2.6.30 series ?
Do you have debugging enabled? Does your logs contain anything useful?
Reinette
^ permalink raw reply
* [RFC] mac80211: deprecate qual value
From: Johannes Berg @ 2009-07-15 15:28 UTC (permalink / raw)
To: linux-wireless
This value is unused by mac80211, because it was only
be used by wireless extensions, and turned out to not
be useful there because the quality value needs to be
comparable between scan results and the current value
which is impossible when the qual value is calculated
taking into account noise, for example.
Since it is unused anyway, this patch deprecates it
in the hope that drivers will remove their sometimes
quite expensive calculations of the value.
I'm open to actual uses of the value, but the best
way of using it seems to be what the Intel drivers do
which should probably be generalised if we have noise
values from the hardware.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
include/net/mac80211.h | 2 +-
net/mac80211/debugfs_sta.c | 3 ---
net/mac80211/rx.c | 1 -
net/mac80211/sta_info.h | 3 ---
4 files changed, 1 insertion(+), 8 deletions(-)
--- wireless-testing.orig/include/net/mac80211.h 2009-07-15 17:27:36.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2009-07-15 17:27:39.000000000 +0200
@@ -508,7 +508,7 @@ struct ieee80211_rx_status {
int freq;
int signal;
int noise;
- int qual;
+ int __deprecated qual;
int antenna;
int rate_idx;
int flag;
--- wireless-testing.orig/net/mac80211/debugfs_sta.c 2009-07-15 17:28:00.000000000 +0200
+++ wireless-testing/net/mac80211/debugfs_sta.c 2009-07-15 17:28:04.000000000 +0200
@@ -57,7 +57,6 @@ STA_FILE(tx_filtered, tx_filtered_count,
STA_FILE(tx_retry_failed, tx_retry_failed, LU);
STA_FILE(tx_retry_count, tx_retry_count, LU);
STA_FILE(last_signal, last_signal, D);
-STA_FILE(last_qual, last_qual, D);
STA_FILE(last_noise, last_noise, D);
STA_FILE(wep_weak_iv_count, wep_weak_iv_count, LU);
@@ -209,7 +208,6 @@ void ieee80211_sta_debugfs_add(struct st
DEBUGFS_ADD(tx_retry_failed);
DEBUGFS_ADD(tx_retry_count);
DEBUGFS_ADD(last_signal);
- DEBUGFS_ADD(last_qual);
DEBUGFS_ADD(last_noise);
DEBUGFS_ADD(wep_weak_iv_count);
}
@@ -235,7 +233,6 @@ void ieee80211_sta_debugfs_remove(struct
DEBUGFS_DEL(tx_retry_failed);
DEBUGFS_DEL(tx_retry_count);
DEBUGFS_DEL(last_signal);
- DEBUGFS_DEL(last_qual);
DEBUGFS_DEL(last_noise);
DEBUGFS_DEL(wep_weak_iv_count);
--- wireless-testing.orig/net/mac80211/rx.c 2009-07-15 17:27:54.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-07-15 17:27:55.000000000 +0200
@@ -860,7 +860,6 @@ ieee80211_rx_h_sta_process(struct ieee80
sta->rx_fragments++;
sta->rx_bytes += rx->skb->len;
sta->last_signal = rx->status->signal;
- sta->last_qual = rx->status->qual;
sta->last_noise = rx->status->noise;
/*
--- wireless-testing.orig/net/mac80211/sta_info.h 2009-07-15 17:27:44.000000000 +0200
+++ wireless-testing/net/mac80211/sta_info.h 2009-07-15 17:28:10.000000000 +0200
@@ -195,7 +195,6 @@ struct sta_ampdu_mlme {
* @rx_fragments: number of received MPDUs
* @rx_dropped: number of dropped MPDUs from this STA
* @last_signal: signal of last received frame from this STA
- * @last_qual: qual of last received frame from this STA
* @last_noise: noise of last received frame from this STA
* @last_seq_ctrl: last received seq/frag number from this STA (per RX queue)
* @tx_filtered_count: number of frames the hardware filtered for this STA
@@ -261,7 +260,6 @@ struct sta_info {
unsigned long rx_fragments;
unsigned long rx_dropped;
int last_signal;
- int last_qual;
int last_noise;
__le16 last_seq_ctrl[NUM_RX_DATA_QUEUES];
@@ -322,7 +320,6 @@ struct sta_info {
struct dentry *tx_retry_failed;
struct dentry *tx_retry_count;
struct dentry *last_signal;
- struct dentry *last_qual;
struct dentry *last_noise;
struct dentry *wep_weak_iv_count;
bool add_has_run;
^ permalink raw reply
* [PATCH] wireless: remove print_mac uses
From: Johannes Berg @ 2009-07-15 15:21 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
Use %pM instead, and also remove stray variables
declared with DECLARE_MAC_BUF.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/ath/ar9170/main.c | 1 -
drivers/net/wireless/b43/main.c | 4 +---
drivers/net/wireless/libertas/assoc.c | 10 +++-------
drivers/net/wireless/mac80211_hwsim.c | 2 --
drivers/net/wireless/mwl8k.c | 6 ++----
drivers/net/wireless/rt2x00/rt2800usb.c | 4 +---
drivers/net/wireless/wl12xx/wl1251_main.c | 5 ++---
7 files changed, 9 insertions(+), 23 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-07-15 17:05:34.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-07-15 17:05:39.000000000 +0200
@@ -938,7 +938,6 @@ static void b43_clear_keys(struct b43_wl
static void b43_dump_keymemory(struct b43_wldev *dev)
{
unsigned int i, index, offset;
- DECLARE_MAC_BUF(macbuf);
u8 mac[ETH_ALEN];
u16 algo;
u32 rcmta0;
@@ -973,8 +972,7 @@ static void b43_dump_keymemory(struct b4
((index - 4) * 2) + 1);
*((__le32 *)(&mac[0])) = cpu_to_le32(rcmta0);
*((__le16 *)(&mac[4])) = cpu_to_le16(rcmta1);
- printk(" MAC: %s",
- print_mac(macbuf, mac));
+ printk(" MAC: %pM", mac);
} else
printk(" DEFAULT KEY");
printk("\n");
--- wireless-testing.orig/drivers/net/wireless/libertas/assoc.c 2009-07-15 17:05:34.000000000 +0200
+++ wireless-testing/drivers/net/wireless/libertas/assoc.c 2009-07-15 17:10:10.000000000 +0200
@@ -129,7 +129,6 @@ static int lbs_set_authentication(struct
{
struct cmd_ds_802_11_authenticate cmd;
int ret = -1;
- DECLARE_MAC_BUF(mac);
lbs_deb_enter(LBS_DEB_JOIN);
@@ -138,8 +137,7 @@ static int lbs_set_authentication(struct
cmd.authtype = iw_auth_to_ieee_auth(auth);
- lbs_deb_join("AUTH_CMD: BSSID %s, auth 0x%x\n",
- print_mac(mac, bssid), cmd.authtype);
+ lbs_deb_join("AUTH_CMD: BSSID %pM, auth 0x%x\n", bssid, cmd.authtype);
ret = lbs_cmd_with_response(priv, CMD_802_11_AUTHENTICATE, &cmd);
@@ -342,8 +340,6 @@ static int lbs_associate(struct lbs_priv
/* Firmware v9+ indicate authentication suites as a TLV */
if (priv->fwrelease >= 0x09000000) {
- DECLARE_MAC_BUF(mac);
-
auth = (struct mrvl_ie_auth_type *) pos;
auth->header.type = cpu_to_le16(TLV_TYPE_AUTH_TYPE);
auth->header.len = cpu_to_le16(2);
@@ -351,8 +347,8 @@ static int lbs_associate(struct lbs_priv
auth->auth = cpu_to_le16(tmpauth);
pos += sizeof(auth->header) + 2;
- lbs_deb_join("AUTH_CMD: BSSID %s, auth 0x%x\n",
- print_mac(mac, bss->bssid), priv->secinfo.auth_mode);
+ lbs_deb_join("AUTH_CMD: BSSID %pM, auth 0x%x\n",
+ bss->bssid, priv->secinfo.auth_mode);
}
/* WPA/WPA2 IEs */
--- wireless-testing.orig/drivers/net/wireless/mwl8k.c 2009-07-15 17:05:34.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mwl8k.c 2009-07-15 17:09:59.000000000 +0200
@@ -2271,7 +2271,6 @@ static int mwl8k_cmd_update_sta_db(struc
struct mwl8k_cmd_update_sta_db *cmd;
struct peer_capability_info *peer_info;
struct ieee80211_rate *bitrates = mv_vif->legacy_rates;
- DECLARE_MAC_BUF(mac);
int rc;
__u8 count, *rates;
@@ -3480,7 +3479,6 @@ static int __devinit mwl8k_probe(struct
{
struct ieee80211_hw *hw;
struct mwl8k_priv *priv;
- DECLARE_MAC_BUF(mac);
int rc;
int i;
u8 *fw;
@@ -3669,8 +3667,8 @@ static int __devinit mwl8k_probe(struct
MWL8K_DESC);
printk(KERN_INFO "%s: Driver Ver:%s Firmware Ver:%u.%u.%u.%u\n",
priv->name, MWL8K_VERSION, fw[3], fw[2], fw[1], fw[0]);
- printk(KERN_INFO "%s: MAC Address: %s\n", priv->name,
- print_mac(mac, hw->wiphy->perm_addr));
+ printk(KERN_INFO "%s: MAC Address: %pM\n", priv->name,
+ hw->wiphy->perm_addr);
return 0;
--- wireless-testing.orig/drivers/net/wireless/rt2x00/rt2800usb.c 2009-07-15 17:05:34.000000000 +0200
+++ wireless-testing/drivers/net/wireless/rt2x00/rt2800usb.c 2009-07-15 17:05:39.000000000 +0200
@@ -2220,10 +2220,8 @@ static int rt2800usb_validate_eeprom(str
*/
mac = rt2x00_eeprom_addr(rt2x00dev, EEPROM_MAC_ADDR_0);
if (!is_valid_ether_addr(mac)) {
- DECLARE_MAC_BUF(macbuf);
-
random_ether_addr(mac);
- EEPROM(rt2x00dev, "MAC: %s\n", print_mac(macbuf, mac));
+ EEPROM(rt2x00dev, "MAC: %pM\n", mac);
}
rt2x00_eeprom_read(rt2x00dev, EEPROM_ANTENNA, &word);
--- wireless-testing.orig/drivers/net/wireless/wl12xx/wl1251_main.c 2009-07-15 17:05:34.000000000 +0200
+++ wireless-testing/drivers/net/wireless/wl12xx/wl1251_main.c 2009-07-15 17:05:39.000000000 +0200
@@ -435,11 +435,10 @@ static int wl1251_op_add_interface(struc
struct ieee80211_if_init_conf *conf)
{
struct wl1251 *wl = hw->priv;
- DECLARE_MAC_BUF(mac);
int ret = 0;
- wl1251_debug(DEBUG_MAC80211, "mac80211 add interface type %d mac %s",
- conf->type, print_mac(mac, conf->mac_addr));
+ wl1251_debug(DEBUG_MAC80211, "mac80211 add interface type %d mac %pM",
+ conf->type, conf->mac_addr);
mutex_lock(&wl->mutex);
--- wireless-testing.orig/drivers/net/wireless/ath/ar9170/main.c 2009-07-15 17:10:21.000000000 +0200
+++ wireless-testing/drivers/net/wireless/ath/ar9170/main.c 2009-07-15 17:10:24.000000000 +0200
@@ -2087,7 +2087,6 @@ static int ar9170_read_eeprom(struct ar9
{
#define RW 8 /* number of words to read at once */
#define RB (sizeof(u32) * RW)
- DECLARE_MAC_BUF(mbuf);
u8 *eeprom = (void *)&ar->eeprom;
u8 *addr = ar->eeprom.mac_address;
__le32 offsets[RW];
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2009-07-15 17:08:48.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2009-07-15 17:08:54.000000000 +0200
@@ -838,7 +838,6 @@ static void hwsim_send_ps_poll(void *dat
{
struct mac80211_hwsim_data *data = dat;
struct hwsim_vif_priv *vp = (void *)vif->drv_priv;
- DECLARE_MAC_BUF(buf);
struct sk_buff *skb;
struct ieee80211_pspoll *pspoll;
@@ -868,7 +867,6 @@ static void hwsim_send_nullfunc(struct m
struct ieee80211_vif *vif, int ps)
{
struct hwsim_vif_priv *vp = (void *)vif->drv_priv;
- DECLARE_MAC_BUF(buf);
struct sk_buff *skb;
struct ieee80211_hdr *hdr;
^ permalink raw reply
* Re: [PATCH 4/5] mac80211: add WoW support
From: Luis R. Rodriguez @ 2009-07-15 15:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <1247659055.2477.0.camel@johannes.local>
On Wed, Jul 15, 2009 at 04:57:35AM -0700, Johannes Berg wrote:
> On Tue, 2009-07-14 at 20:21 -0400, Luis R. Rodriguez wrote:
> > If we're associated and have not already gone into PS mode
> > we ensure send a nullfunc frame before going to suspend. Upon
> > resume we ensure we restore PS mode if it was enabled and inform
> > the driver accordingly, also notify the AP we're awake.
> >
> > WoW requires the radio to be left on during suspend, to do this
> > we inform drivers of the requested wow triggers on the mac80211
> > stop callback.
>
> I don't think this patch would work if ath9k unprogrammed the hardware
> correctly in ->remove_interface(), since you don't seem to skip that
> call.
We just stop ANI in remove interface and reclaim beacon resources.
As per documentation it seems we are not correctly removing the MAC
address in ath9k for the removed interface to stop sending ACKs back.
I'd rather see that as a separate patch fix, but you do have a point.
As is right now though this doesn't affect WoW.
Luis
^ permalink raw reply
* Re: [PATCH 3/5] cfg80211: add WoW support
From: Luis R. Rodriguez @ 2009-07-15 15:14 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis Rodriguez, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org
In-Reply-To: <1247658322.2302.1.camel@johannes.local>
On Wed, Jul 15, 2009 at 04:45:22AM -0700, Johannes Berg wrote:
> On Tue, 2009-07-14 at 20:21 -0400, Luis R. Rodriguez wrote:
>
> > + /* Draw up a netlink message to send back */
> > + msg = nlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL);
> > + if (!msg) {
>
> Need to use DEFAULT_SIZE or something.
Will change it, thanks. I see NLMSG_DEFAULT_SIZE is smaller than
NLMSG_GOODSIZE (it removes the NLMSG_HDRLEN), but no documentation
for either, when should I use either?
> > + if (!(wiphy->wow_triggers_supported & triggers_requested)) {
> > + err = -EOPNOTSUPP;
> > + goto out;
>
> This seems wrong, should be "requested & supported != requested", I
> think.
The above one won't return -EOPNOTSUPP when you add additional junk, you're
right, better to just inform userspace of that.
> > @@ -4253,6 +4359,16 @@ static struct genl_ops nl80211_ops[] = {
> > {
> > .cmd = NL80211_CMD_DISCONNECT,
> > .doit = nl80211_disconnect,
> > + },
> > + {
> > + .cmd = NL80211_CMD_GET_WOW,
> > + .doit = nl80211_get_wow,
> > + .policy = nl80211_policy,
> > + /* can be retrieved by unprivileged users */
> > + },
> > + {
> > + .cmd = NL80211_CMD_SET_WOW,
> > + .doit = nl80211_set_wow,
> > .policy = nl80211_policy,
> > .flags = GENL_ADMIN_PERM,
> > },
>
> This messes up the disconnect command.
Must have been a rebase issue, strange, thanks, will fix up.
Luis
^ 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