* 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
* wl12xx.git is back on git.kernel.org
From: Luciano Coelho @ 2011-10-12 18:46 UTC (permalink / raw)
To: linux-wireless
Hi,
Now that git.kernel.org is working again and I got my account back, the
official wl12xx.git tree is back to it's original place:
git://git.kernel.org/pub/scm/linux/kernel/git/luca/wl12xx.git
And the usual branches are back, master (used for development) and
wl12xx-next (used by me for integration). All wl12xx tags were also
pushed back to to repository.
I'll keep updating the wl12xx.git repo in github for a while, but I
don't know for how long, so I don't recommend using it anymore.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH 00/34] update for 3.2
From: Guy, Wey-Yi @ 2011-10-12 18:00 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20111012182440.GD18764@tuxdriver.com>
Hi John,
On Wed, 2011-10-12 at 11:24 -0700, John W. Linville wrote:
> 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
>
My mistake, I believe this patch already in the tree:
commit#af4dc88c56559c1ebf53628ddcc18dde23924e33 iwlagn: separate init
calib and rt calib
Thanks
Wey
^ permalink raw reply
* [PATCH 05/22] brcm80211: fix sparse endianess error in mac80211_if.c
From: Arend van Spriel @ 2011-10-12 18:51 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1318445492-24207-1-git-send-email-arend@broadcom.com>
The ht capabilities provided upon registration with mac80211 must
be in little endian. This was fixed adding cpu_to_le16() conversion.
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
index 6ce773a..ac8d02b 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
@@ -963,7 +963,7 @@ static int ieee_hw_rate_init(struct ieee80211_hw *hw)
if (phy_type == PHY_TYPE_LCN) {
/* Single stream */
band->ht_cap.mcs.rx_mask[1] = 0;
- band->ht_cap.mcs.rx_highest = 72;
+ band->ht_cap.mcs.rx_highest = cpu_to_le16(72);
}
hw->wiphy->bands[IEEE80211_BAND_2GHZ] = band;
} else {
--
1.7.4.1
^ permalink raw reply related
* [PATCH 19/22] brcm80211: moved function brcmu_chspec_malformed
From: Arend van Spriel @ 2011-10-12 18:51 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Alwin Beukers, Arend van Spriel
In-Reply-To: <1318445492-24207-1-git-send-email-arend@broadcom.com>
From: Alwin Beukers <alwin@broadcom.com>
Moved brcmu_chspec_malformed into the only file using it. The
function name was adjusted accordingly.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Roland Vossen <rvossen@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
drivers/net/wireless/brcm80211/brcmsmac/channel.c | 28 +++++++++++++++++++-
drivers/net/wireless/brcm80211/brcmutil/wifi.c | 27 -------------------
.../net/wireless/brcm80211/include/brcmu_wifi.h | 8 -----
3 files changed, 27 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/channel.c b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
index a1b415d..89ad1b7 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/channel.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/channel.c
@@ -1485,6 +1485,32 @@ brcms_c_channel_reg_limits(struct brcms_cm_info *wlc_cm, u16 chanspec,
}
/*
+ * Verify the chanspec is using a legal set of parameters, i.e. that the
+ * chanspec specified a band, bw, ctl_sb and channel and that the
+ * combination could be legal given any set of circumstances.
+ * RETURNS: true is the chanspec is malformed, false if it looks good.
+ */
+static bool brcms_c_chspec_malformed(u16 chanspec)
+{
+ /* must be 2G or 5G band */
+ if (!CHSPEC_IS5G(chanspec) && !CHSPEC_IS2G(chanspec))
+ return true;
+ /* must be 20 or 40 bandwidth */
+ if (!CHSPEC_IS40(chanspec) && !CHSPEC_IS20(chanspec))
+ return true;
+
+ /* 20MHZ b/w must have no ctl sb, 40 must have a ctl sb */
+ if (CHSPEC_IS20(chanspec)) {
+ if (!CHSPEC_SB_NONE(chanspec))
+ return true;
+ } else if (!CHSPEC_SB_UPPER(chanspec) && !CHSPEC_SB_LOWER(chanspec)) {
+ return true;
+ }
+
+ return false;
+}
+
+/*
* Validate the chanspec for this locale, for 40MHZ we need to also
* check that the sidebands are valid 20MZH channels in this locale
* and they are also a legal HT combination
@@ -1497,7 +1523,7 @@ brcms_c_valid_chanspec_ext(struct brcms_cm_info *wlc_cm, u16 chspec,
u8 channel = CHSPEC_CHANNEL(chspec);
/* check the chanspec */
- if (brcmu_chspec_malformed(chspec)) {
+ if (brcms_c_chspec_malformed(chspec)) {
wiphy_err(wlc->wiphy, "wl%d: malformed chanspec 0x%x\n",
wlc->pub->unit, chspec);
return false;
diff --git a/drivers/net/wireless/brcm80211/brcmutil/wifi.c b/drivers/net/wireless/brcm80211/brcmutil/wifi.c
index e8d3bf2..8483f24 100644
--- a/drivers/net/wireless/brcm80211/brcmutil/wifi.c
+++ b/drivers/net/wireless/brcm80211/brcmutil/wifi.c
@@ -14,30 +14,3 @@
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
#include <brcmu_wifi.h>
-
-/*
- * Verify the chanspec is using a legal set of parameters, i.e. that the
- * chanspec specified a band, bw, ctl_sb and channel and that the
- * combination could be legal given any set of circumstances.
- * RETURNS: true is the chanspec is malformed, false if it looks good.
- */
-bool brcmu_chspec_malformed(u16 chanspec)
-{
- /* must be 2G or 5G band */
- if (!CHSPEC_IS5G(chanspec) && !CHSPEC_IS2G(chanspec))
- return true;
- /* must be 20 or 40 bandwidth */
- if (!CHSPEC_IS40(chanspec) && !CHSPEC_IS20(chanspec))
- return true;
-
- /* 20MHZ b/w must have no ctl sb, 40 must have a ctl sb */
- if (CHSPEC_IS20(chanspec)) {
- if (!CHSPEC_SB_NONE(chanspec))
- return true;
- } else if (!CHSPEC_SB_UPPER(chanspec) && !CHSPEC_SB_LOWER(chanspec)) {
- return true;
- }
-
- return false;
-}
-EXPORT_SYMBOL(brcmu_chspec_malformed);
diff --git a/drivers/net/wireless/brcm80211/include/brcmu_wifi.h b/drivers/net/wireless/brcm80211/include/brcmu_wifi.h
index 5b1aca7..f10d302 100644
--- a/drivers/net/wireless/brcm80211/include/brcmu_wifi.h
+++ b/drivers/net/wireless/brcm80211/include/brcmu_wifi.h
@@ -168,14 +168,6 @@ static inline bool ac_bitmap_tst(u8 bitmap, int prec)
return (bitmap & (1 << (prec))) != 0;
}
-/*
- * Verify the chanspec is using a legal set of parameters, i.e. that the
- * chanspec specified a band, bw, ctl_sb and channel and that the
- * combination could be legal given any set of circumstances.
- * RETURNS: true is the chanspec is malformed, false if it looks good.
- */
-extern bool brcmu_chspec_malformed(u16 chanspec);
-
/* Enumerate crypto algorithms */
#define CRYPTO_ALGO_OFF 0
#define CRYPTO_ALGO_WEP1 1
--
1.7.4.1
^ permalink raw reply related
* [PATCH 20/22] brcm80211: moved function brcmu_mkiovar
From: Arend van Spriel @ 2011-10-12 18:51 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Alwin Beukers, Arend van Spriel
In-Reply-To: <1318445492-24207-1-git-send-email-arend@broadcom.com>
From: Alwin Beukers <alwin@broadcom.com>
Moved the brcmu_mkiovar function into fmac, adjusting the
name accordingly.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Roland Vossen <rvossen@broadcom.com>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
drivers/net/wireless/brcm80211/brcmfmac/dhd.h | 3 ++
.../net/wireless/brcm80211/brcmfmac/dhd_common.c | 39 +++++++++++++++-----
.../net/wireless/brcm80211/brcmfmac/dhd_linux.c | 6 ++--
.../net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 24 ++++++------
drivers/net/wireless/brcm80211/brcmutil/utils.c | 20 ----------
.../net/wireless/brcm80211/include/brcmu_utils.h | 3 --
6 files changed, 48 insertions(+), 47 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd.h b/drivers/net/wireless/brcm80211/brcmfmac/dhd.h
index 951910e..4645766 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd.h
@@ -680,6 +680,9 @@ struct bcmevent_name {
extern const struct bcmevent_name bcmevent_names[];
+extern uint brcmf_c_mkiovar(char *name, char *data, uint datalen,
+ char *buf, uint len);
+
/* Indication from bus module regarding presence/insertion of dongle.
* Return struct brcmf_pub pointer, used as handle to OS module in later calls.
* Returned structure should have bus and prot pointers filled in.
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
index a43b3da..8918261 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_common.c
@@ -65,6 +65,26 @@ struct msgtrace_hdr {
because of trace overflow */
} __packed;
+
+uint
+brcmf_c_mkiovar(char *name, char *data, uint datalen, char *buf, uint buflen)
+{
+ uint len;
+
+ len = strlen(name) + 1;
+
+ if ((len + datalen) > buflen)
+ return 0;
+
+ strncpy(buf, name, buflen);
+
+ /* append data onto the end of the name string */
+ memcpy(&buf[len], data, datalen);
+ len += datalen;
+
+ return len;
+}
+
void brcmf_c_init(void)
{
/* Init global variables at run-time, not as part of the declaration.
@@ -607,7 +627,7 @@ brcmf_c_pktfilter_offload_enable(struct brcmf_pub *drvr, char *arg, int enable,
/* Contorl the master mode */
mmode_le = cpu_to_le32(master_mode);
- brcmu_mkiovar("pkt_filter_mode", (char *)&mmode_le, 4, buf,
+ brcmf_c_mkiovar("pkt_filter_mode", (char *)&mmode_le, 4, buf,
sizeof(buf));
rc = brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, buf,
sizeof(buf));
@@ -756,7 +776,7 @@ static void brcmf_c_arp_offload_set(struct brcmf_pub *drvr, int arp_mode)
char iovbuf[32];
int retcode;
- brcmu_mkiovar("arp_ol", (char *)&arp_mode, 4, iovbuf, sizeof(iovbuf));
+ brcmf_c_mkiovar("arp_ol", (char *)&arp_mode, 4, iovbuf, sizeof(iovbuf));
retcode = brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR,
iovbuf, sizeof(iovbuf));
retcode = retcode >= 0 ? 0 : retcode;
@@ -773,7 +793,8 @@ static void brcmf_c_arp_offload_enable(struct brcmf_pub *drvr, int arp_enable)
char iovbuf[32];
int retcode;
- brcmu_mkiovar("arpoe", (char *)&arp_enable, 4, iovbuf, sizeof(iovbuf));
+ brcmf_c_mkiovar("arpoe", (char *)&arp_enable, 4,
+ iovbuf, sizeof(iovbuf));
retcode = brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR,
iovbuf, sizeof(iovbuf));
retcode = retcode >= 0 ? 0 : retcode;
@@ -812,33 +833,33 @@ int brcmf_c_preinit_dcmds(struct brcmf_pub *drvr)
/* query for 'ver' to get version info from firmware */
memset(buf, 0, sizeof(buf));
ptr = buf;
- brcmu_mkiovar("ver", NULL, 0, buf, sizeof(buf));
+ brcmf_c_mkiovar("ver", NULL, 0, buf, sizeof(buf));
brcmf_proto_cdc_query_dcmd(drvr, 0, BRCMF_C_GET_VAR, buf, sizeof(buf));
strsep(&ptr, "\n");
/* Print fw version info */
brcmf_dbg(ERROR, "Firmware version = %s\n", buf);
/* Match Host and Dongle rx alignment */
- brcmu_mkiovar("bus:txglomalign", (char *)&dongle_align, 4, iovbuf,
+ brcmf_c_mkiovar("bus:txglomalign", (char *)&dongle_align, 4, iovbuf,
sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, iovbuf,
sizeof(iovbuf));
/* disable glom option per default */
- brcmu_mkiovar("bus:txglom", (char *)&glom, 4, iovbuf, sizeof(iovbuf));
+ brcmf_c_mkiovar("bus:txglom", (char *)&glom, 4, iovbuf, sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, iovbuf,
sizeof(iovbuf));
/* Setup timeout if Beacons are lost and roam is off to report
link down */
- brcmu_mkiovar("bcn_timeout", (char *)&bcn_timeout, 4, iovbuf,
+ brcmf_c_mkiovar("bcn_timeout", (char *)&bcn_timeout, 4, iovbuf,
sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, iovbuf,
sizeof(iovbuf));
/* Enable/Disable build-in roaming to allowed ext supplicant to take
of romaing */
- brcmu_mkiovar("roam_off", (char *)&roaming, 4,
+ brcmf_c_mkiovar("roam_off", (char *)&roaming, 4,
iovbuf, sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, iovbuf,
sizeof(iovbuf));
@@ -847,7 +868,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_pub *drvr)
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_UP, (char *)&up, sizeof(up));
/* Setup event_msgs */
- brcmu_mkiovar("event_msgs", drvr->eventmask, BRCMF_EVENTING_MASK_LEN,
+ brcmf_c_mkiovar("event_msgs", drvr->eventmask, BRCMF_EVENTING_MASK_LEN,
iovbuf, sizeof(iovbuf));
brcmf_proto_cdc_set_dcmd(drvr, 0, BRCMF_C_SET_VAR, iovbuf,
sizeof(iovbuf));
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
index b05f177..4acbac5 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_linux.c
@@ -204,7 +204,7 @@ static void _brcmf_set_multicast_list(struct work_struct *work)
dcmd_le_value = cpu_to_le32(dcmd_value);
- if (!brcmu_mkiovar
+ if (!brcmf_c_mkiovar
("allmulti", (void *)&dcmd_le_value,
sizeof(dcmd_le_value), buf, buflen)) {
brcmf_dbg(ERROR, "%s: mkiovar failed for allmulti, datalen %d buflen %u\n",
@@ -260,7 +260,7 @@ _brcmf_set_mac_address(struct work_struct *work)
setmacaddr_work);
brcmf_dbg(TRACE, "enter\n");
- if (!brcmu_mkiovar("cur_etheraddr", (char *)drvr_priv->macvalue,
+ if (!brcmf_c_mkiovar("cur_etheraddr", (char *)drvr_priv->macvalue,
ETH_ALEN, buf, 32)) {
brcmf_dbg(ERROR, "%s: mkiovar failed for cur_etheraddr\n",
brcmf_ifname(&drvr_priv->pub, 0));
@@ -1084,7 +1084,7 @@ int brcmf_bus_start(struct brcmf_pub *drvr)
return -ENODEV;
}
- brcmu_mkiovar("event_msgs", drvr->eventmask, BRCMF_EVENTING_MASK_LEN,
+ brcmf_c_mkiovar("event_msgs", drvr->eventmask, BRCMF_EVENTING_MASK_LEN,
iovbuf, sizeof(iovbuf));
brcmf_proto_cdc_query_dcmd(drvr, 0, BRCMF_C_GET_VAR, iovbuf,
sizeof(iovbuf));
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
index 857b328..5eddabe 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
@@ -437,7 +437,7 @@ static s32 brcmf_dev_intvar_set(struct net_device *ndev, s8 *name, s32 val)
__le32 val_le;
val_le = cpu_to_le32(val);
- len = brcmu_mkiovar(name, (char *)(&val_le), sizeof(val_le), buf,
+ len = brcmf_c_mkiovar(name, (char *)(&val_le), sizeof(val_le), buf,
sizeof(buf));
BUG_ON(!len);
@@ -460,7 +460,7 @@ brcmf_dev_intvar_get(struct net_device *ndev, s8 *name, s32 *retval)
s32 err = 0;
len =
- brcmu_mkiovar(name, (char *)(&data_null), 0, (char *)(&var),
+ brcmf_c_mkiovar(name, (char *)(&data_null), 0, (char *)(&var),
sizeof(var.buf));
BUG_ON(!len);
err = brcmf_exec_dcmd(ndev, BRCMF_C_GET_VAR, &var, len);
@@ -508,7 +508,7 @@ brcmf_dev_iovar_setbuf(struct net_device *ndev, s8 * iovar, void *param,
{
s32 iolen;
- iolen = brcmu_mkiovar(iovar, param, paramlen, bufptr, buflen);
+ iolen = brcmf_c_mkiovar(iovar, param, paramlen, bufptr, buflen);
BUG_ON(!iolen);
return brcmf_exec_dcmd(ndev, BRCMF_C_SET_VAR, bufptr, iolen);
@@ -520,7 +520,7 @@ brcmf_dev_iovar_getbuf(struct net_device *ndev, s8 * iovar, void *param,
{
s32 iolen;
- iolen = brcmu_mkiovar(iovar, param, paramlen, bufptr, buflen);
+ iolen = brcmf_c_mkiovar(iovar, param, paramlen, bufptr, buflen);
BUG_ON(!iolen);
return brcmf_exec_dcmd(ndev, BRCMF_C_GET_VAR, bufptr, buflen);
@@ -2554,7 +2554,7 @@ brcmf_dev_bufvar_set(struct net_device *ndev, s8 *name, s8 *buf, s32 len)
struct brcmf_cfg80211_priv *cfg_priv = ndev_to_cfg(ndev);
u32 buflen;
- buflen = brcmu_mkiovar(name, buf, len, cfg_priv->dcmd_buf,
+ buflen = brcmf_c_mkiovar(name, buf, len, cfg_priv->dcmd_buf,
WL_DCMD_LEN_MAX);
BUG_ON(!buflen);
@@ -2570,7 +2570,7 @@ brcmf_dev_bufvar_get(struct net_device *ndev, s8 *name, s8 *buf,
u32 len;
s32 err = 0;
- len = brcmu_mkiovar(name, NULL, 0, cfg_priv->dcmd_buf,
+ len = brcmf_c_mkiovar(name, NULL, 0, cfg_priv->dcmd_buf,
WL_DCMD_LEN_MAX);
BUG_ON(!len);
err = brcmf_exec_dcmd(ndev, BRCMF_C_GET_VAR, cfg_priv->dcmd_buf,
@@ -3513,8 +3513,8 @@ static s32 brcmf_dongle_eventmsg(struct net_device *ndev)
WL_TRACE("Enter\n");
/* Setup event_msgs */
- brcmu_mkiovar("event_msgs", eventmask, BRCMF_EVENTING_MASK_LEN, iovbuf,
- sizeof(iovbuf));
+ brcmf_c_mkiovar("event_msgs", eventmask, BRCMF_EVENTING_MASK_LEN,
+ iovbuf, sizeof(iovbuf));
err = brcmf_exec_dcmd(ndev, BRCMF_C_GET_VAR, iovbuf, sizeof(iovbuf));
if (err) {
WL_ERR("Get event_msgs error (%d)\n", err);
@@ -3542,8 +3542,8 @@ static s32 brcmf_dongle_eventmsg(struct net_device *ndev)
setbit(eventmask, BRCMF_E_JOIN_START);
setbit(eventmask, BRCMF_E_SCAN_COMPLETE);
- brcmu_mkiovar("event_msgs", eventmask, BRCMF_EVENTING_MASK_LEN, iovbuf,
- sizeof(iovbuf));
+ brcmf_c_mkiovar("event_msgs", eventmask, BRCMF_EVENTING_MASK_LEN,
+ iovbuf, sizeof(iovbuf));
err = brcmf_exec_dcmd(ndev, BRCMF_C_SET_VAR, iovbuf, sizeof(iovbuf));
if (err) {
WL_ERR("Set event_msgs error (%d)\n", err);
@@ -3571,7 +3571,7 @@ brcmf_dongle_roam(struct net_device *ndev, u32 roamvar, u32 bcn_timeout)
*/
if (roamvar) {
bcn_to_le = cpu_to_le32(bcn_timeout);
- brcmu_mkiovar("bcn_timeout", (char *)&bcn_to_le,
+ brcmf_c_mkiovar("bcn_timeout", (char *)&bcn_to_le,
sizeof(bcn_to_le), iovbuf, sizeof(iovbuf));
err = brcmf_exec_dcmd(ndev, BRCMF_C_SET_VAR,
iovbuf, sizeof(iovbuf));
@@ -3587,7 +3587,7 @@ brcmf_dongle_roam(struct net_device *ndev, u32 roamvar, u32 bcn_timeout)
*/
WL_INFO("Internal Roaming = %s\n", roamvar ? "Off" : "On");
roamvar_le = cpu_to_le32(roamvar);
- brcmu_mkiovar("roam_off", (char *)&roamvar_le,
+ brcmf_c_mkiovar("roam_off", (char *)&roamvar_le,
sizeof(roamvar_le), iovbuf, sizeof(iovbuf));
err = brcmf_exec_dcmd(ndev, BRCMF_C_SET_VAR, iovbuf, sizeof(iovbuf));
if (err) {
diff --git a/drivers/net/wireless/brcm80211/brcmutil/utils.c b/drivers/net/wireless/brcm80211/brcmutil/utils.c
index 2d903ba..d55595a 100644
--- a/drivers/net/wireless/brcm80211/brcmutil/utils.c
+++ b/drivers/net/wireless/brcm80211/brcmutil/utils.c
@@ -439,23 +439,3 @@ int brcmu_format_hex(char *str, const void *bytes, int len)
}
EXPORT_SYMBOL(brcmu_format_hex);
#endif /* defined(BCMDBG) */
-
-uint brcmu_mkiovar(char *name, char *data, uint datalen, char *buf, uint buflen)
-{
- uint len;
-
- len = strlen(name) + 1;
-
- if ((len + datalen) > buflen)
- return 0;
-
- strncpy(buf, name, buflen);
-
- /* append data onto the end of the name string */
- memcpy(&buf[len], data, datalen);
- len += datalen;
-
- return len;
-}
-EXPORT_SYMBOL(brcmu_mkiovar);
-
diff --git a/drivers/net/wireless/brcm80211/include/brcmu_utils.h b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
index c19490c..f8664b2 100644
--- a/drivers/net/wireless/brcm80211/include/brcmu_utils.h
+++ b/drivers/net/wireless/brcm80211/include/brcmu_utils.h
@@ -200,7 +200,4 @@ extern int brcmu_format_flags(const struct brcmu_bit_desc *bd, u32 flags,
extern int brcmu_format_hex(char *str, const void *bytes, int len);
#endif
-extern uint brcmu_mkiovar(char *name, char *data, uint datalen,
- char *buf, uint len);
-
#endif /* _BRCMU_UTILS_H_ */
--
1.7.4.1
^ permalink raw reply related
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