* Re: [RFC 06/07] compat-wireless: UAPSD configuration in STA mode
From: Johannes Berg @ 2011-10-12 8:25 UTC (permalink / raw)
To: Dmitry Tarnyagin
Cc: linux-wireless.vger.kernel.org, Bartosz MARKOWSKI,
Janusz DZIEDZIC
In-Reply-To: <op.v27ru00wya27un@edmitar>
On Wed, 2011-10-12 at 03:02 +0200, Dmitry Tarnyagin wrote:
> From: Janusz Dziedzic <janusz.dziedzic@tieto.com>
> Date: Wed, 3 Aug 2011 09:46:05 +0200
>
> This patch adds UAPSD queues configuration as a param to assoc request.
> With the patch it's possible to configure UAPSD from user space.
>
> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
> ---
> include/linux/nl80211.h | 2 ++
> include/net/cfg80211.h | 1 +
> net/mac80211/main.c | 3 ++-
> net/mac80211/mlme.c | 2 ++
> net/wireless/core.h | 6 ++++--
> net/wireless/mlme.c | 10 +++++++---
> net/wireless/nl80211.c | 7 ++++++-
> net/wireless/sme.c | 2 +-
> 8 files changed, 25 insertions(+), 8 deletions(-)
This is a rare case where *maybe* it's OK to do both mac80211 and
cfg80211 in one patch, but I haven't seen much evidence from all of you
that you really understand the separation, so I'd prefer if you split it
up and explained the changes separately.
> +++ b/include/net/cfg80211.h
> @@ -1050,6 +1050,7 @@ struct cfg80211_assoc_request {
> size_t ie_len;
> struct cfg80211_crypto_settings crypto;
> bool use_mfp;
> + int uapsd;
int? explain. also you're obviously missing documentation that would
have explained this.
> - local->uapsd_queues = IEEE80211_DEFAULT_UAPSD_QUEUES;
> + /* Disable all UAPSD AC by default */
> + local->uapsd_queues = 0;
You should obviously then remove the default constant, or better yet
just set it to 0. Also _that_ specific change needs to be a separate
change since it modifies existing behaviour.
> + if (info->attrs[NL80211_ATTR_UAPSD])
> + uapsd = nla_get_u32(info->attrs[NL80211_ATTR_UAPSD]);
clearly missing validation.
> +++ b/net/wireless/sme.c
> @@ -190,7 +190,7 @@ static int cfg80211_conn_do_work(struct wireless_dev
> *wdev)
> prev_bssid,
> params->ssid, params->ssid_len,
> params->ie, params->ie_len,
> - false, ¶ms->crypto);
> + false, ¶ms->crypto, -1);
> if (err)
> __cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid,
> NULL, 0,
Really? Why should this not be able to do uapsd with the same way?
johannes
^ permalink raw reply
* Re: [RFC 04/07] compat-wireless: p2p power save support
From: Johannes Berg @ 2011-10-12 8:30 UTC (permalink / raw)
To: Dmitry Tarnyagin
Cc: linux-wireless.vger.kernel.org, Bartosz MARKOWSKI,
Janusz DZIEDZIC
In-Reply-To: <op.v27ruwj6ya27un@edmitar>
On Wed, 2011-10-12 at 03:02 +0200, Dmitry Tarnyagin wrote:
> From: Janusz Dziedzic <janusz.dziedzic@tieto.com>
> Date: Thu, 4 Aug 2011 11:42:16 +0200
>
> P2P power save support:
> - Opportunistic Power Save
> - Notice Of Absence
More explanation please. I know I sound like a broken record but for
such a big change you really need more text.
I'm not even going to bother to review the patch in detail. You need to
explain why you need to set NoA. There are three reasons this would be
used:
1) actually save power
2) do scanning, multi-channel operation, etc.
3) P2P certification testing
Only 3) seems to be useful from userspace, and then maybe it shouldn't
be full-blown nl80211 API.
Similarly for the P2P power save stuff. Since you generally lack
documentation updates in your patches (read this as criticism) there's
no way reason to even look through your patches since they don't explain
anything.
FWIW, a very brief glance over this patch tells me that there's at least
one obvious, glaring bug in it.
johannes
^ permalink raw reply
* Re: [RFC 05/07] mac80211: Purge cfg80211 beacon cache before authentication.
From: Johannes Berg @ 2011-10-12 8:31 UTC (permalink / raw)
To: Dmitry Tarnyagin
Cc: linux-wireless.vger.kernel.org, Bartosz MARKOWSKI,
Janusz DZIEDZIC
In-Reply-To: <op.v27ruyliya27un@edmitar>
On Wed, 2011-10-12 at 03:02 +0200, Dmitry Tarnyagin wrote:
> From: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
> Date: Wed, 10 Aug 2011 19:15:13 +0200
>
> cw1200 device requires SSID to be available at AUTH stage.
> cfg80211 beacon cache is designed to handle multi-SSID BSSes, so
> bss struct returned by cfg80211_get_bss() has random SSID if BSS
> just changed SSID before authentication (typical for p2p).
>
> As a workaround cfg80211 beacon cache is purged to make sure
> target BSS is searchable in rb-tree at the AUTH stage.
Funny, but hell no.
johannes
^ permalink raw reply
* Re: [RFC 07/07] mac80211: Do not call release_buffered_frames if not available.
From: Johannes Berg @ 2011-10-12 8:32 UTC (permalink / raw)
To: Dmitry Tarnyagin
Cc: linux-wireless.vger.kernel.org, Bartosz MARKOWSKI,
Janusz DZIEDZIC
In-Reply-To: <op.v27ru2maya27un@edmitar>
On Wed, 2011-10-12 at 03:02 +0200, Dmitry Tarnyagin wrote:
> From: Dmitry Tarnyagin <dmitry.tarnyagin@stericsson.com>
> Date: Wed, 5 Oct 2011 13:20:04 +0200
>
> A new .release_buffered_frames callback was introduced recently.
> Check for the callback presence was missing in the mac80211 code,
> and PM state could get broken in some cases.
Interesting, but we do check:
drv_release_buffered_frames(struct ieee80211_local *local,
struct sta_info *sta, u16 tids, int num_frames,
enum ieee80211_frame_release_type reason,
bool more_data)
{
trace_drv_release_buffered_frames(local, &sta->sta, tids, num_frames,
reason, more_data);
if (local->ops->release_buffered_frames)
local->ops->release_buffered_frames(&local->hw, &sta->sta, tids,
So whatever you're trying to do must be something else.
johannes
^ permalink raw reply
* Re: [PATCH] iw: add DFS region parsing support
From: Johannes Berg @ 2011-10-12 8:37 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless
In-Reply-To: <CAB=NE6WtkokxWg4zJtjyKVZmhZAhzArfoJuOOqhuKSw940hxqg@mail.gmail.com>
On Tue, 2011-10-11 at 13:25 -0700, Luis R. Rodriguez wrote:
> > Also, I prefer patches w/o nl80211.h updates.
>
> In my RFC on December the stars aligned differently and you preferred
> it together I think.
Really? I must've been confused. The reason I don't want them is that
then I can never merge something that isn't upstream yet. :)
johannes
^ permalink raw reply
* Re: [RFC 01/07] wireless-next: WAPI support for hardware-accelerated drivers
From: Jouni Malinen @ 2011-10-12 8:50 UTC (permalink / raw)
To: Dmitry Tarnyagin; +Cc: linux-wireless, Bartosz MARKOWSKI, Janusz DZIEDZIC
In-Reply-To: <op.v27rufm9ya27un@edmitar>
On Wed, Oct 12, 2011 at 03:02:29AM +0200, Dmitry Tarnyagin wrote:
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> @@ -1551,12 +1552,14 @@ enum ieee80211_sa_query_action {
> #define WLAN_CIPHER_SUITE_CCMP 0x000FAC04
> #define WLAN_CIPHER_SUITE_WEP104 0x000FAC05
> #define WLAN_CIPHER_SUITE_AES_CMAC 0x000FAC06
> +#define WLAN_CIPHER_SUITE_SMS4 0x000FAC07
>
> /* AKM suite selectors */
> #define WLAN_AKM_SUITE_8021X 0x000FAC01
> #define WLAN_AKM_SUITE_PSK 0x000FAC02
> #define WLAN_AKM_SUITE_SAE 0x000FAC08
> #define WLAN_AKM_SUITE_FT_OVER_SAE 0x000FAC09
> +#define WLAN_AKM_SUITE_WAPI_PSK 0x000FAC03
Where do these values come from?
00-0F-AC:7 cipher suite selector has already been allocated for other
purposes ("Group addressed traffic not allowed") and similarly, AKM
suite 00-0F-AC:3 is already in use ("FT authentication negotiated over
IEEE 802.1X"). The 00-0F-AC OUI is managed by IEEE 802.11 and you cannot
just pick a random suite type from that OUI and hope for the best. This
will result in conflicts with other uses.
These need to be either allocated by IEEE 802.11 ANA or maybe more
likely, by any vendor that has their own OUI could allocate a unique
identifier for this purpose.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] iw: add DFS region parsing support
From: Luis R. Rodriguez @ 2011-10-12 9:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless
In-Reply-To: <1318408634.3933.32.camel@jlt3.sipsolutions.net>
On Wed, Oct 12, 2011 at 1:37 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2011-10-11 at 13:25 -0700, Luis R. Rodriguez wrote:
>
>> > Also, I prefer patches w/o nl80211.h updates.
>>
>> In my RFC on December the stars aligned differently and you preferred
>> it together I think.
>
> Really? I must've been confused. The reason I don't want them is that
> then I can never merge something that isn't upstream yet. :)
That's fine, I also like to split it. I'll resend the iw patches.
John, let me know if the other ones look peachy, once and if you merge
to wireless-regdb, wireless-next I'll push to CRDA too.
Luis
^ permalink raw reply
* Re: [PATCH] ath6kl: fix firmware start address for ar6003 hw2.0
From: Sangwook Lee @ 2011-10-12 10:45 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <4E953FDB.9090709@qca.qualcomm.com>
Hi Kalle
You wrote:
>>>Before I'm able to find a hw 2.0 device, can you try to debug this more?
>>>When scanning fails can check if ath6kldev_intr_bh_handler() is called
>>>or not? When scanning fails it usually happens because irqs are failing.
Yes, it seems true. when scanning fails. it failed to receive no more sdio irqs.
For the temporary testing, I made sdio polling kernel thread and then let it
call ath6kldev_intr_bh_handler(). With hw2.0, it works fine with
scanning issue.
Do you know any ideas to solve this problem clearly ?
Thanks
Sangwook
On 12 October 2011 08:20, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> On 10/06/2011 04:12 PM, Sangwook Lee wrote:
>> From: Kalle Valo <kvalo@qca.qualcomm.com>
>>
>> Sangwook found out that commit 639d0b89 ("ath6kl: read firmware start
>> address from hardware") broke firmware boot on ar6003 hw2.0 as it seems
>> it's not posible to automatically query the address from hardware. So
>> we need to hardcode the address for hw2.0.
>>
>> Reported-by: Sangwook Lee <sangwook.lee@linaro.org>
>> Tested-by: Sangwook Lee <sangwook.lee@linaro.org>
>> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
>> ---
>> Kalle:
>> I slightly changed again. without running ath6kl_bmi_read() before,
>> ath6kl_bmi_execute() failed with hw2.0 board, but I am not clear about this reason.
>
> Hmm, that's strange. I didn't find any reason why this is needed.
>
>> @@ -1201,25 +1202,28 @@ static int ath6kl_upload_otp(struct ath6kl *ar)
>> }
>>
>> /* read firmware start address */
>> - ret = ath6kl_bmi_read(ar,
>> - ath6kl_get_hi_item_addr(ar,
>> - HI_ITEM(hi_app_start)),
>> - (u8 *) &address, sizeof(address));
>> + ret = ath6kl_bmi_read(ar, ath6kl_get_hi_item_addr(ar,
>> + HI_ITEM(hi_app_start)), (u8 *) &address, sizeof(address));
>
> You just change indentation here, right? So this part can be dropped.
>
> I have applied to ath6kl.git now. Thank you very much for your help!
>
> Kalle
>
^ permalink raw reply
* Driver for Intel Pro/Wireless 2200BG
From: Jayanthi Venugopal @ 2011-10-12 12:58 UTC (permalink / raw)
To: linux-wireless
Hi,
I would like to download and install the above driver .I am not able
to download the driver from
http://ipw2200.sourceforge.net/index.php
I would like the driver and the installation instruction as well.
Looking forward for your reply,
Thanks
Jay
^ permalink raw reply
* Re: ath9k: irq storm after suspend/resume
From: Mohammed Shafi @ 2011-10-12 13:10 UTC (permalink / raw)
To: Adrian Chadd, Clemens Buchacher; +Cc: linux-wireless
In-Reply-To: <CAJ-Vmok4v2+ZEpAmVaj2pQ5U2StWxxD8f20u2Ln87o4+C_ST0g@mail.gmail.com>
Hi Clemens,
please try this in case it helps anything
to debug the issue.
this should avoid dead beef and the interrupt when we access MAC
registers when the MAC is asleep. also i did not see MAC irq being not
triggerred in your case(AR_INTR_ASYNC_CAUSE should be 0x2) or may be
its not an interrupt triggered by the chip itself. thanks
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 93fbe6f..51b7c54 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -770,6 +770,7 @@ irqreturn_t ath_isr(int irq, void *dev)
enum ath9k_int status;
bool sched = false;
+ ath9k_ps_wakeup(sc);
/*
* The hardware is not ready/present, don't
* touch anything. Note this can happen early
On Wed, Oct 5, 2011 at 6:32 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 5 October 2011 14:28, Clemens Buchacher <drizzd@aon.at> wrote:
>> For the record, instead of going to full sleep, I can reproduce the
>> issue with
>>
>> echo devices >/sys/power/pm_test
>> echo mem >/sys/power/state
>>
>> but not with
>>
>> echo freezer >/sys/power/pm_test
>> echo mem >/sys/power/state
>>
>> So it could still be a different device that's causing the issue? I
>> can try unloading all kinds of modules. Or is there an option to
>> suspend just one device?
>
> Right. So its likely something (more) odd. Yes, see if that's the case
> :) At this point I'm going to punt this to the power management/ACPI
> people .:)
>
> Good luck!
>
>
> Adrian
>
--
shafi
^ permalink raw reply related
* Re: [PATCH 1/5 V2] rtlwifi: Change PCI drivers to use the new PM framework
From: Mark Einon @ 2011-10-12 14:02 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless
In-Reply-To: <1318386531-5859-2-git-send-email-Larry.Finger@lwfinger.net>
On 12 October 2011 03:28, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> +static const struct dev_pm_ops rtlwifi_pm_ops = {
> + .suspend = rtl_pci_suspend,
> + .resume = rtl_pci_resume,
> + .freeze = rtl_pci_suspend,
> + .thaw = rtl_pci_resume,
> + .poweroff = rtl_pci_suspend,
> + .restore = rtl_pci_resume,
> +};
> +
Hi Larry,
You can save a few lines of code here, and in the other files where it
is done - there is a convenience macro for simplifying creating a
pm_ops struct like this, see SIMPLE_DEV_PM_OPS() in pm.h.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH] iwlagn: fix priv->cfg->ht_params NULL pointer dereference
From: Guy, Wey-Yi @ 2011-10-12 13:26 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org, John W. Linville
In-Reply-To: <20111012081634.GA2675@redhat.com>
On Wed, 2011-10-12 at 01:16 -0700, Stanislaw Gruszka wrote:
> This fix regression introduced by commit:
>
> commit 15b3f3b006b42a678523cad989bfd60b76bf4403
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Fri Jun 3 07:54:13 2011 -0700
>
> iwlagn: set smps mode after assoc for 1000 device
>
> Also remove unneeded brackets on the way.
>
> Address:
> https://bugzilla.redhat.com/show_bug.cgi?id=744155
>
> If fix will not get 3.1 release, it should be applied in 3.1 stable.
>
> Cc: stable@kernel.org # 3.1+
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
Thanks a lot
Wey
^ permalink raw reply
* [PATCH] staging: brcm80211: remove brcm80211 driver from the staging tree
From: Arend van Spriel @ 2011-10-12 14:18 UTC (permalink / raw)
To: gregkh@suse.de
Cc: devel@linuxdriverproject.org, linux-wireless@vger.kernel.org,
John W. Linville
Hi Greg,
John recommended to do the delete through your staging tree. Thanks for
the ride. It has been a learning experience for all of us here. Apart
from the significant cleanup (which needs ongoing work for sure) it took
some time to find the right way of working in coordinating our changes
with community patches.
The removal patch was just as big as the mainline patch so it has been
uploaded to linuxwireless.org:
http://linuxwireless.org/en/users/Drivers/brcm80211?action=AttachFile&do=view&target=0001-staging-brcm80211-remove-brcm80211-driver-from-the-s.patch
Regards,
Arend van Spriel
^ permalink raw reply
* Re: Driver for Intel Pro/Wireless 2200BG
From: Guy, Wey-Yi @ 2011-10-12 13:36 UTC (permalink / raw)
To: Jayanthi Venugopal; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAFvH45QeG7DQeLORkf4io=gfVAhuiKh1KtWGEwZscg1LY7hM8Q@mail.gmail.com>
On Wed, 2011-10-12 at 05:58 -0700, Jayanthi Venugopal wrote:
> Hi,
> I would like to download and install the above driver .I am not able
> to download the driver from
> http://ipw2200.sourceforge.net/index.php
>
> I would like the driver and the installation instruction as well.
>
> Looking forward for your reply,
>
is not ipw2200 part of kernel release?
drivers/net/wireless/ipw2x00
Thanks
Wey
^ permalink raw reply
* Re: [PATCH] staging: brcm80211: remove brcm80211 driver from the staging tree
From: Greg KH @ 2011-10-12 14:36 UTC (permalink / raw)
To: Arend van Spriel
Cc: devel@linuxdriverproject.org, linux-wireless@vger.kernel.org,
John W. Linville
In-Reply-To: <4E95A1D1.8010602@broadcom.com>
On Wed, Oct 12, 2011 at 04:18:57PM +0200, Arend van Spriel wrote:
> Hi Greg,
>
> John recommended to do the delete through your staging tree. Thanks for
> the ride. It has been a learning experience for all of us here. Apart
> from the significant cleanup (which needs ongoing work for sure) it took
> some time to find the right way of working in coordinating our changes
> with community patches.
>
> The removal patch was just as big as the mainline patch so it has been
> uploaded to linuxwireless.org:
>
> http://linuxwireless.org/en/users/Drivers/brcm80211?action=AttachFile&do=view&target=0001-staging-brcm80211-remove-brcm80211-driver-from-the-s.patch
So I'm taking it that the driver is now in the wireless-next tree?
That's great, I'll queue the patch up later today.
And thanks so much for working with us, I know it can be hard at times,
but I hope you will agree that the end result is much better than what
we started out with.
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: brcm80211: remove brcm80211 driver from the staging tree
From: Arend van Spriel @ 2011-10-12 15:08 UTC (permalink / raw)
To: Greg KH
Cc: devel@linuxdriverproject.org, linux-wireless@vger.kernel.org,
John W. Linville
In-Reply-To: <20111012143600.GA17938@suse.de>
On 10/12/2011 04:36 PM, Greg KH wrote:
> On Wed, Oct 12, 2011 at 04:18:57PM +0200, Arend van Spriel wrote:
>> Hi Greg,
>>
>> John recommended to do the delete through your staging tree. Thanks for
>> the ride. It has been a learning experience for all of us here. Apart
>> from the significant cleanup (which needs ongoing work for sure) it took
>> some time to find the right way of working in coordinating our changes
>> with community patches.
>>
>> The removal patch was just as big as the mainline patch so it has been
>> uploaded to linuxwireless.org:
>>
>> http://linuxwireless.org/en/users/Drivers/brcm80211?action=AttachFile&do=view&target=0001-staging-brcm80211-remove-brcm80211-driver-from-the-s.patch
>
> So I'm taking it that the driver is now in the wireless-next tree?
> That's great, I'll queue the patch up later today.
It is. From the day I sent the mainline patch for wireless-next we have
been staring at our inbox for the green light :-D
> And thanks so much for working with us, I know it can be hard at times,
> but I hope you will agree that the end result is much better than what
> we started out with.
>
> greg k-h
>
Yep. We got rid of a lot of redundant code that was not needed in the
mac80211 framework and the different level of abstractions. The are
still i's to dot and features to add.
Thanks again.
Gr. AvS
^ permalink raw reply
* Re: [PATCH 1/5 V2] rtlwifi: Change PCI drivers to use the new PM framework
From: Larry Finger @ 2011-10-12 15:20 UTC (permalink / raw)
To: Mark Einon; +Cc: linville, linux-wireless
In-Reply-To: <CANK3SE1zJDKry-r-M384jqo7rQezgj2FzbXBLS6SCMiaL934kw@mail.gmail.com>
On 10/12/2011 09:02 AM, Mark Einon wrote:
> On 12 October 2011 03:28, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>
>>
>> +static const struct dev_pm_ops rtlwifi_pm_ops = {
>> + .suspend = rtl_pci_suspend,
>> + .resume = rtl_pci_resume,
>> + .freeze = rtl_pci_suspend,
>> + .thaw = rtl_pci_resume,
>> + .poweroff = rtl_pci_suspend,
>> + .restore = rtl_pci_resume,
>> +};
>> +
>
> Hi Larry,
>
> You can save a few lines of code here, and in the other files where it
> is done - there is a convenience macro for simplifying creating a
> pm_ops struct like this, see SIMPLE_DEV_PM_OPS() in pm.h.
Mark,
Thanks for the tip.
Larry
^ permalink raw reply
* [PATCH] mac80211: reformat TX unauthorised check
From: Johannes Berg @ 2011-10-12 15:28 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Reformat the check, the indentation is completely strange.
Also change the last part of the condition to make the
code shorter.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Yes, it runs a bit over 80 cols but is easier to read than broken up.
net/mac80211/tx.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
--- a/net/mac80211/tx.c 2011-10-12 17:11:32.000000000 +0200
+++ b/net/mac80211/tx.c 2011-10-12 17:27:00.000000000 +0200
@@ -1896,11 +1896,10 @@ netdev_tx_t ieee80211_subif_start_xmit(s
* Drop unicast frames to unauthorised stations unless they are
* EAPOL frames from the local station.
*/
- if (!ieee80211_vif_is_mesh(&sdata->vif) &&
- unlikely(!is_multicast_ether_addr(hdr.addr1) && !authorized &&
- !(cpu_to_be16(ethertype) == sdata->control_port_protocol &&
- compare_ether_addr(sdata->vif.addr,
- skb->data + ETH_ALEN) == 0))) {
+ if (unlikely(!ieee80211_vif_is_mesh(&sdata->vif) &&
+ !is_multicast_ether_addr(hdr.addr1) && !authorized &&
+ (cpu_to_be16(ethertype) != sdata->control_port_protocol ||
+ compare_ether_addr(sdata->vif.addr, skb->data + ETH_ALEN)))) {
#ifdef CONFIG_MAC80211_VERBOSE_DEBUG
if (net_ratelimit())
printk(KERN_DEBUG "%s: dropped frame to %pM"
^ permalink raw reply
* Re: r8712u driver - on ARM
From: Ian Jeffray @ 2011-10-12 15:30 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <4E87A110.6030201@emobix.co.uk>
On 02/10/2011 00:24, Ian Jeffray wrote:
> On 01/10/2011 20:24, Larry Finger wrote:
>
>> BTW, netperf shows that r8712u can transmit at ~80 and receive at ~60
>> Mbps when connected to a 270 Mbps AP. As Realtek lists this as capable
>> of 150 Mbps, x86_64 is getting the max transmit rate that we might
>> expect.
>
> On x86 32bit, I get a sustained 94Mbps transmit to a 300Mbps AP, which
> seems pretty good - why I'm keen to get this to work for my ARM target.
Larry, just a little more info on this issue, FYI.
It would seem the problem is certainly specific to the 'Inventra' mUSB
host found in recent TI ARM products and ADI Blackfin devices.
I have added a PCI express NEC USB 2.0 host controller card to my ARM
Cortex A8 system, and the r8712u devices work just fine when connected
via that host controller. (Albeit only at 20MBps rate, but that's
because the host controller is rather poor in general).
We have now raised this problem with TI USB experts.
Regards,
Ian.
^ permalink raw reply
* Re: [PATCH v2] mac80211: pass vif param to conf_tx() callback
From: Johannes Berg @ 2011-10-12 15:31 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1317543352-29019-1-git-send-email-eliad@wizery.com>
On Sun, 2011-10-02 at 10:15 +0200, Eliad Peller wrote:
> tx params should be configured per interface.
> add ieee80211_vif param to the conf_tx callback,
> and change all the drivers that use this callback.
For the record, I said this to you on IRC but you weren't around I
guess. This patch (with the other ones) is now passing a bogus sdata/vif
pointer to drivers -- e.g. for monitor mode interfaces from
ieee80211_do_open -> ieee80211_set_wmm_default -> drv_conf_tx.
I suspect the way to fix this would be to move the call to
ieee80211_set_wmm_default into the last switch statement in do_open,
could you please look into it?
Thx,
johannes
^ permalink raw reply
* Re: r8712u driver - on ARM
From: Larry Finger @ 2011-10-12 17:28 UTC (permalink / raw)
To: Ian Jeffray; +Cc: linux-wireless
In-Reply-To: <4E95B299.8050006@emobix.co.uk>
On 10/12/2011 10:30 AM, Ian Jeffray wrote:
> On 02/10/2011 00:24, Ian Jeffray wrote:
>> On 01/10/2011 20:24, Larry Finger wrote:
>>
>>> BTW, netperf shows that r8712u can transmit at ~80 and receive at ~60
>>> Mbps when connected to a 270 Mbps AP. As Realtek lists this as capable
>>> of 150 Mbps, x86_64 is getting the max transmit rate that we might
>>> expect.
>>
>> On x86 32bit, I get a sustained 94Mbps transmit to a 300Mbps AP, which
>> seems pretty good - why I'm keen to get this to work for my ARM target.
>
> Larry, just a little more info on this issue, FYI.
>
> It would seem the problem is certainly specific to the 'Inventra' mUSB
> host found in recent TI ARM products and ADI Blackfin devices.
>
> I have added a PCI express NEC USB 2.0 host controller card to my ARM
> Cortex A8 system, and the r8712u devices work just fine when connected
> via that host controller. (Albeit only at 20MBps rate, but that's
> because the host controller is rather poor in general).
>
> We have now raised this problem with TI USB experts.
Thanks for the update. Good luck with finding the real problem and let me know
if I can be of help.
Larry
^ permalink raw reply
* Re: [PATCH v2 01/13] ath9k_hw: Updated ar9003 initval table for AR9380
From: John W. Linville @ 2011-10-12 18:21 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless
In-Reply-To: <1318225878-7283-1-git-send-email-rmanohar@qca.qualcomm.com>
At least three of the patches in this series don't apply to either
wireless-next or wireless-testing. Please only send me patch sets
that apply cleanly to recent kernels.
John
On Mon, Oct 10, 2011 at 11:21:06AM +0530, Rajkumar Manoharan wrote:
> The ar9003 table is updated to increase XLNA BIAS
> output driver strengh.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
> ---
> .../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
> index 08e9341..02be24e 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
> +++ b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
> @@ -24,11 +24,11 @@ static const u32 ar9300_2p2_radio_postamble[][5] = {
> {0x0001609c, 0x0dd08f29, 0x0dd08f29, 0x0b283f31, 0x0b283f31},
> {0x000160ac, 0xa4653c00, 0xa4653c00, 0x24652800, 0x24652800},
> {0x000160b0, 0x03284f3e, 0x03284f3e, 0x05d08f20, 0x05d08f20},
> - {0x0001610c, 0x08000000, 0x00000000, 0x00000000, 0x00000000},
> + {0x0001610c, 0xc8000000, 0xc0000000, 0xc0000000, 0xc0000000},
> {0x00016140, 0x10804008, 0x10804008, 0x50804008, 0x50804008},
> - {0x0001650c, 0x08000000, 0x00000000, 0x00000000, 0x00000000},
> + {0x0001650c, 0xc8000000, 0xc0000000, 0xc0000000, 0xc0000000},
> {0x00016540, 0x10804008, 0x10804008, 0x50804008, 0x50804008},
> - {0x0001690c, 0x08000000, 0x00000000, 0x00000000, 0x00000000},
> + {0x0001690c, 0xc8000000, 0xc0000000, 0xc0000000, 0xc0000000},
> {0x00016940, 0x10804008, 0x10804008, 0x50804008, 0x50804008},
> };
>
> --
> 1.7.7
>
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 00/34] update for 3.2
From: John W. Linville @ 2011-10-12 18:24 UTC (permalink / raw)
To: Wey-Yi Guy; +Cc: linux-wireless
In-Reply-To: <1318256839-31837-1-git-send-email-wey-yi.w.guy@intel.com>
On Mon, Oct 10, 2011 at 07:26:45AM -0700, Wey-Yi Guy wrote:
> We address the performance issue cause by earlier path which disable too many calibration.
> We include few more bugs fix and enhancement patches for WoWLAN operations
> We continue remove un-needed code and clean up after driver split
> We also include new SKUs for both 6005 and 105 series of devices
Applying: iwlagn: separate init calib and rt calib
error: patch failed: drivers/net/wireless/iwlwifi/iwl-agn.c:1222
error: drivers/net/wireless/iwlwifi/iwl-agn.c: patch does not apply
error: patch failed: drivers/net/wireless/iwlwifi/iwl-commands.h:3216
error: drivers/net/wireless/iwlwifi/iwl-commands.h: patch does not apply
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 4/5 V2] rtlwifi: rtl8192se: Updates from latest Realtek driver version - Part II
From: John W. Linville @ 2011-10-12 18:32 UTC (permalink / raw)
To: Larry Finger; +Cc: Chaoming Li, linux-wireless
In-Reply-To: <1318386531-5859-5-git-send-email-Larry.Finger@lwfinger.net>
On Tue, Oct 11, 2011 at 09:28:50PM -0500, Larry Finger wrote:
> From: Chaoming Li <chaoming_li@realsil.com.cn>
>
> This patch incorporate the differences between the 06/20/2011 and
> 08/16/2011 Realtek releases of the rtl8192se driver.
>
> The changes include:
>
> 1. Fixing some typos in register usage.
> 2. A change in the handling of decryption status for 802.11w packets.
>
> Signed-off-by: Chaoming Li <chaoming_li@realsil.com.cn>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
> ===================================================================
> --- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
> +++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192se/trx.c
> @@ -539,29 +540,39 @@ bool rtl92se_rx_query_desc(struct ieee80
> rx_status->freq = hw->conf.channel->center_freq;
> rx_status->band = hw->conf.channel->band;
>
> - if (GET_RX_STATUS_DESC_CRC32(pdesc))
> - rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
> + hdr = (struct ieee80211_hdr *)(skb->data + stats->rx_drvinfo_size
> + + stats->rx_bufshift);
>
> - if (!GET_RX_STATUS_DESC_SWDEC(pdesc))
> - rx_status->flag |= RX_FLAG_DECRYPTED;
> + if (stats->crc)
> + rx_status->flag |= RX_FLAG_FAILED_FCS_CRC;
>
> - if (GET_RX_STATUS_DESC_BW(pdesc))
> + if (stats->rx_is40Mhzpacket)
> rx_status->flag |= RX_FLAG_40MHZ;
>
> - if (GET_RX_STATUS_DESC_RX_HT(pdesc))
> + if (stats->is_ht)
> rx_status->flag |= RX_FLAG_HT;
>
> rx_status->flag |= RX_FLAG_MACTIME_MPDU;
>
> - if (stats->decrypted)
> - rx_status->flag |= RX_FLAG_DECRYPTED;
> + /* hw will set stats->decrypted true, if it finds the
> + * frame is open data frame or mgmt frame,
> + * hw will not decrypt robust managment frame
> + * for IEEE80211w but still set stats->decrypted
> + * true, so here we should set it back to undecrypted
> + * for IEEE80211w frame, and mac80211 sw will help
> + * to decrypt it */
> + if (stats->decrypted) {
> + if ((ieee80211_is_robust_mgmt_frame(hdr)) &&
> + (ieee80211_has_protected(hdr->frame_control)))
> + rx_status->flag &= ~RX_FLAG_DECRYPTED;
> + else
> + rx_status->flag |= RX_FLAG_DECRYPTED;
> + }
>
> rx_status->rate_idx = rtlwifi_rate_mapping(hw,
> - (bool)GET_RX_STATUS_DESC_RX_HT(pdesc),
> - (u8)GET_RX_STATUS_DESC_RX_MCS(pdesc));
> -
> + stats->is_ht, stats->rate);
>
> - rx_status->mactime = GET_RX_STATUS_DESC_TSFL(pdesc);
> + rx_status->mactime = stats->timestamp_low;
> if (phystatus) {
> p_drvinfo = (struct rx_fwinfo *)(skb->data +
> stats->rx_bufshift);
The above hunk doesn't apply, because I have this:
rx_status->rate_idx = rtlwifi_rate_mapping(hw,
(bool)GET_RX_STATUS_DESC_RX_HT(pdesc),
(u8)GET_RX_STATUS_DESC_RX_MCS(pdesc),
(bool)GET_RX_STATUS_DESC_PAGGR(pdesc));
Do you perhaps have another patch applied which you haven't sent?
John
P.S. Please note that my trees are still on infradead -- be sure to
pull the latest from there.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] ath9k_hw: Fix ASPM L1 issue for AR9462
From: John W. Linville @ 2011-10-12 18:40 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, stable
In-Reply-To: <1318226145-7772-1-git-send-email-rmanohar@qca.qualcomm.com>
On Mon, Oct 10, 2011 at 11:25:45AM +0530, Rajkumar Manoharan wrote:
> Because of not clearing Bit 14 of AR_WA, the ASPM L1 is not
> enabled when entering into sleep mode. AR9462 does not need
> bit 14 to be set.
>
> Cc: stable@kernel.org
> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
CC [M] drivers/net/wireless/ath/ath9k/hw.o
drivers/net/wireless/ath/ath9k/hw.c: In function ‘__ath9k_hw_init’:
drivers/net/wireless/ath/ath9k/hw.c:544:2: error: implicit declaration of function ‘AR_SREV_9462’
Missing a patch dependency?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
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