* Re: iwlagn is getting very shaky
From: wwguy @ 2011-10-26 19:36 UTC (permalink / raw)
To: Norbert Preining
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111026043419.GA30368@gamma.logic.tuwien.ac.at>
On Tue, 2011-10-25 at 21:34 -0700, Norbert Preining wrote:
> On Di, 25 Okt 2011, wwguy wrote:
> > > But *I* cannot be sure about it ;-)
> > >
> > Are you seeing this without suspend/resume?
>
> Yes. I just shut down and started, and the same happens again. If you
> need the dmesg output let me know.
>
please send us the log, but I will be late on response since I am on
business trip until the end of next week.
Thanks
Wey
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Chiefdome @ 2011-10-26 19:39 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <4EA83160.4080405@lwfinger.net>
On 10/26/2011 06:12 PM, Larry Finger wrote:
> On 10/26/2011 10:49 AM, Chiefdome wrote:
>> Is there a way to set the tx-power over 20dbm on the adapter?
>> I thought it is able to do 2w. There is no way for me to get it over
>> 20 dbm.
>> When trying to to set the adapter with "iwconfig wlan1 set txpower
>> 30" it answers
>>
>> Error for wireless request "Set Tx Power" (8B26) :
>> SET failed on device wlan1 ; Invalid argument.
>>
>> I think there has to be done some work in the code but where do I start?
>>
>> Thanks for all replys.
>
> The WEXT interface is deprecated. It is there as a convenience, but it
> will not be extended. To change the power setting, you need to use the
> iw utility. The specific commands are:
>
> iw dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
>
> or
>
> iw phy <phyname> set txpower <auto|fixed|limit> [<tx power in mBm>]
>
> The maximum power will be dependent on your regulatory domain setting.
>
> Larry
Did you tested the commands you posted to me? Anyway here they do
nothing. I cant see any changes in iwconfig nor in in iw.
iw reg get
country 00:
(2400 - 2494 @ 40), (N/A, 33)
(4910 - 5895 @ 40), (N/A, 33)
so after my regulatory domain I should be able to change the adapter
settings.
Chiefdome
^ permalink raw reply
* Re: a-MSDU question (bug in debugfs?)
From: Ben Greear @ 2011-10-26 19:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1319656123.4229.11.camel@jlt3.sipsolutions.net>
On 10/26/2011 12:08 PM, Johannes Berg wrote:
> On Wed, 2011-10-26 at 12:03 -0700, Ben Greear wrote:
>> This code from net/mac80211/debugfs_sta.c appears to say that
>> if the IEEE80211_HT_CAP_MAX_AMSDU is set, we are at value 3839,
>> but elsewhere on the web it appears the opposite.
>>
>> Anyone know what is correct? I'm having no good luck finding
>> an official document about this...
>>
>> PRINT_HT_CAP((htc->cap& BIT(11)), "Max AMSDU length: "
>> "3839 bytes");
>> PRINT_HT_CAP(!(htc->cap& BIT(11)), "Max AMSDU length: "
>> "7935 bytes");
>
> iw also has the other way around and I probably would have checked
> against 802.11n. If you can't find that google for getieee
Thanks, I found the 802.11n doc. Page 69 (section 7.3.2.56) seems to indicate
this debugfs code is reversed. I'll post a patch when I
get the rest of my tree sorted out, if no one beats me to it.
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: a-MSDU question (bug in debugfs?)
From: Johannes Berg @ 2011-10-26 19:08 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4EA8597A.50609@candelatech.com>
On Wed, 2011-10-26 at 12:03 -0700, Ben Greear wrote:
> This code from net/mac80211/debugfs_sta.c appears to say that
> if the IEEE80211_HT_CAP_MAX_AMSDU is set, we are at value 3839,
> but elsewhere on the web it appears the opposite.
>
> Anyone know what is correct? I'm having no good luck finding
> an official document about this...
>
> PRINT_HT_CAP((htc->cap & BIT(11)), "Max AMSDU length: "
> "3839 bytes");
> PRINT_HT_CAP(!(htc->cap & BIT(11)), "Max AMSDU length: "
> "7935 bytes");
iw also has the other way around and I probably would have checked
against 802.11n. If you can't find that google for getieee
johannes
^ permalink raw reply
* a-MSDU question (bug in debugfs?)
From: Ben Greear @ 2011-10-26 19:03 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
This code from net/mac80211/debugfs_sta.c appears to say that
if the IEEE80211_HT_CAP_MAX_AMSDU is set, we are at value 3839,
but elsewhere on the web it appears the opposite.
Anyone know what is correct? I'm having no good luck finding
an official document about this...
PRINT_HT_CAP((htc->cap & BIT(11)), "Max AMSDU length: "
"3839 bytes");
PRINT_HT_CAP(!(htc->cap & BIT(11)), "Max AMSDU length: "
"7935 bytes");
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Compat-wireless release for 2011-10-26 is baked
From: Compat-wireless cronjob account @ 2011-10-26 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
814862 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3523 - % of code consists of backport work
^ permalink raw reply
* Re: brcm80211 in linux-next git.
From: Arend van Spriel @ 2011-10-26 18:35 UTC (permalink / raw)
To: Piotr Karbowski
Cc: linux-wireless@vger.kernel.org, devel@linuxdriverproject.org
In-Reply-To: <4EA82F9A.6000709@gmail.com>
On 10/26/2011 06:04 PM, Piotr Karbowski wrote:
> Hi there,
>
> The question is, when the brcm80211 changes from linux-next will hit
> normal kernel? Using compat-wireless is not quite cool, I don't like
> idea of building modules instead of using regular kernel one, I also
> tried copy drivers/net/wireless/brcm80211 to my kernel's
> drivers/staging/brcm80211 but after compilation and loading modules I
> tried to connect to my network but then my system was frozen, music
> stopped, everything stopped.
linux-next is a normal kernel, but with the next best/bad stuff.
However, your 'normal' kernel will probably mean a kernel coming from
linus (posted on kernel.org).
I think compat-wireless is pretty cool. It provides the 'regular' kernel
modules of a new kernel in an older kernel. Especially manufacturers who
are not so eager to use the latest kernels
Bottom line is that until kernel 3.1 the brcm80211 drivers exist in
drivers/staging and we made a move to drivers/net/brcm80211 couple of
weeks ago. This means that it will pop-up in 3.2 kernels. Merge window
is now active so in about 2 weeks 3.2-rc1 will be there with
drivers/net/wireless/brcm80211.
> I wonder how I could port the brcm80211 code from linux-next to normal
> kernel, is there any tutorial on how should looks like the workflow when
> you want pull *some* code from linux-next git? I didn't find any.
Not sure how familiar you are with git, but it all starts with a 'git
clone' command. On git.kernel.org you can find the linux-next url.
$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
et voila. You will have a linux-next folder pretty much like you would
have when untar-ring a .tar.gz file and you can build your kernel from
there.
> Anyway, thanks for working on this driver! ;-)
>
> -- Piotr.
>
Gr. AvS
^ permalink raw reply
* Re: [PATCH] mac80211: support adding IV-room in the skb for CCMP keys
From: Arik Nemtsov @ 2011-10-26 17:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <4EA7DA0F.7050603@sipsolutions.net>
On Wed, Oct 26, 2011 at 11:59, Johannes Berg <johannes@sipsolutions.net> wrote:
> On 10/23/2011 8:21 AM, Arik Nemtsov wrote:
>>
>> Some cards can generate CCMP IVs in HW, but require the space for the IV
>> to be pre-allocated in the frame at the correct offset. Add a key flag
>> that allows us to achieve this.
>
> Is it really that expensive to generate the IV and then not use it that this
> is worth the extra complexity? This not just makes it more complex but also
> more expensive in the other case.
>
Some of the platforms with this chip are pretty weak (host CPU is the
bottleneck).
We add another "if" for the other case (for a value that's likely in
the cacheline already). I don't think that's too bad.
Arik
^ permalink raw reply
* Re: [PATCH] mac80211: use min rate as basic rate for buggy APs
From: Eliad Peller @ 2011-10-26 17:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <4EA7D8B5.5060306@sipsolutions.net>
On Wed, Oct 26, 2011 at 11:53 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On 10/25/2011 10:26 AM, Eliad Peller wrote:
>>
>> Some buggy APs (and even P2P_GO) don't advertise their
>> basic rates in the association response.
>>
>> In such case, use the min supported rate as the
>> basic rate.
>
> I seem to vaguely remember discussing using mandatory rates, did we?
>
yes.
the problem with the mandatory rates is that we shouldn't use CCK
rates when working as p2p_cli (there *shouldn't* be such GO, but this
was an actual case...)
> Also this seems like a last resort fallback, I'd really also try using the
> probe response information -- we should have that information still at this
> point. But maybe that doesn't make sense -- fix the APs instead!
>
right.
> I'd really like a (debug?) message here though. This is a stupid AP, and I
> will need to know if I'm debugging some throughput issues etc.
sure. i'll add it.
thanks for the review.
Eliad.
^ permalink raw reply
* Re: ipw2200 fails to load firmware when returning from suspend
From: Dan Williams @ 2011-10-26 16:31 UTC (permalink / raw)
To: plaes; +Cc: linux-wireless
In-Reply-To: <1319621899.29639.7.camel@localhost.localdomain>
On Wed, 2011-10-26 at 12:38 +0300, plaes@plaes.org wrote:
> Heya!
>
> I've been running into following issue with recent kernels fairly often
> when waking up Dell Latitude D610 laptop from suspend:
if (WARN_ON(usermodehelper_is_disabled())) {
dev_err(device, "firmware: %s will not be loaded\n", name);
retval = -EBUSY;
goto out;
}
The usermodehelper gets enabled by suspend_finish() in
kernel/power/suspend.c, so something is waking up the ipw driver from
userspace before the kernel has completed waking up. Maybe make
whatever that thing is that pokes ipw wait a second?
Dan
> [snip]
> [347767.844024] pci 0000:00:1e.0: setting latency timer to 64
> [347767.844046] eth1: Coming out of suspend...
> [347767.844060] ipw2200 0000:03:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [347767.884092] ------------[ cut here ]------------
> [347767.884107] WARNING: at drivers/base/firmware_class.c:537 _request_firmware+0xb5/0x31b()
> [347767.884113] Hardware name: Latitude D610
> [347767.884117] Modules linked in: lib80211_crypt_ccmp ipw2200 tg3 libipw libphy lib80211
> [347767.884134] Pid: 17562, comm: kworker/0:0 Not tainted 3.1.0-rc8+ #50
> [347767.884139] Call Trace:
> [347767.884150] [<c1027fce>] ? warn_slowpath_common+0x7c/0x8f
> [347767.884159] [<c1287e1c>] ? _request_firmware+0xb5/0x31b
> [347767.884167] [<c1287e1c>] ? _request_firmware+0xb5/0x31b
> [347767.884176] [<c1027ffc>] ? warn_slowpath_null+0x1b/0x1f
> [347767.884184] [<c1287e1c>] ? _request_firmware+0xb5/0x31b
> [347767.884194] [<c12880f8>] ? request_firmware+0x17/0x1b
> [347767.884211] [<f83900a8>] ? ipw_up+0xf9/0x133f [ipw2200]
> [347767.884222] [<c101ee71>] ? set_next_entity+0xb4/0x122
> [347767.884230] [<c1001a9b>] ? __switch_to+0x34/0x10f
> [347767.884239] [<c101f6b7>] ? finish_task_switch.clone.124.clone.138+0x3e/0x76
> [347767.884247] [<c101e963>] ? need_resched+0x11/0x1a
> [347767.884258] [<c13f13b1>] ? __schedule+0x471/0x4e7
> [347767.884274] [<f83914d3>] ? ipw_bg_up+0x1c/0x25 [ipw2200]
> [347767.884283] [<c1037370>] ? process_one_work+0xfd/0x1af
> [347767.884298] [<f83914b7>] ? ipw_net_init+0x32/0x32 [ipw2200]
> [347767.884307] [<c1038437>] ? worker_thread+0xbd/0x134
> [347767.884316] [<c103837a>] ? manage_workers.clone.30+0x19f/0x19f
> [347767.884324] [<c103aaaf>] ? kthread+0x62/0x67
> [347767.884332] [<c103aa4d>] ? flush_kthread_worker+0x7a/0x7a
> [347767.884341] [<c13f3076>] ? kernel_thread_helper+0x6/0xd
> [347767.884347] ---[ end trace 4141d0bfaee985bf ]---
> [347767.884353] ipw2200 0000:03:03.0: firmware: ipw2200-bss.fw will not be loaded
> [347767.884360] ipw2200: ipw2200-bss.fw request_firmware failed: Reason -16
> [347767.884365] ipw2200: Unable to load firmware: -16
> ...
> [347769.850709] Restarting tasks ... done.
> [347770.870138] ipw2200: No space for Tx
> [347770.870143] ipw2200: Failed to send POWER_MODE: Reason -16
> [/snip]
>
> After rmmod/insmod cycle card works fine again:
>
> [snip]
> [347824.614542] ipw2200 0000:03:03.0: PCI INT A disabled
> [347832.294216] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
> [347832.294221] ipw2200: Copyright(c) 2003-2006 Intel Corporation
> [347832.294353] ipw2200 0000:03:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [347832.294382] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
> [347832.503972] cfg80211: failed to add phy80211 symlink to netdev!
> [347832.505049] ipw2200: Detected geography ZZD (13 802.11bg channels, 0 802.11a channels)
> [/snip]
>
> [snip]
> 03:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
> Subsystem: Intel Corporation Dell Latitude D600
> Flags: bus master, medium devsel, latency 64, IRQ 17
> Memory at dfbff000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: [dc] Power Management version 2
> Kernel driver in use: ipw2200
> Kernel modules: ipw2200
> [/snip]
>
>
> Any ideas where to look further?
>
> Päikest,
> Priit Laes ;)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] libertas: ensure we clean up a scan request properly
From: Dan Williams @ 2011-10-26 17:35 UTC (permalink / raw)
To: Andres Salomon
Cc: dsd, libertas-dev, netdev, linux-wireless, linville, linux-kernel
In-Reply-To: <20111026101926.48109373@queued.net>
On Wed, 2011-10-26 at 10:19 -0700, Andres Salomon wrote:
> Commit 2e30168b ("libertas: terminate scan when stopping interface")
> adds cleanup code to lbs_eth_stop to call cfg80211_scan_done if there's
> an outstanding cfg80211_scan_request. However, it assumes that the
> scan request was allocated via the cfg80211 stack. Libertas has
> its own internal allocation method, kept track of with
> priv->internal_scan. This doesn't set scan_req->wiphy, amongst other
> things, which results in hitting a BUG() when we call cfg80211_scan_done
> on the request.
>
> This provides a function to take care of the low-level scan_req cleanup
> details. We simply call that to deal with finishing up scan requests.
Acked-by: Dan Williams <dcbw@redhat.com>
> The bug we were hitting was:
>
> [ 964.321495] kernel BUG at net/wireless/core.h:87!
> [ 964.329970] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [ 964.341963] pgd = dcf80000
> ...
> [ 964.849998] 9fe0: 00000000 beb417b8 4018e280 401e822c 60000010 00000004 00000000 00000000
> [ 964.865007] [<c003104c>] (__bug+0x1c/0x28) from [<c0384ffc>] (cfg80211_scan_done+0x54/0x6c)
> [ 964.895324] [<c0384ffc>] (cfg80211_scan_done+0x54/0x6c) from [<bf028bac>] (lbs_eth_stop+0x10c/0x188 [libertas])
> [ 964.895324] [<bf028bac>] (lbs_eth_stop+0x10c/0x188 [libertas]) from [<c03002a0>] (__dev_close_many+0x94/0xc4)
> [ 964.918995] [<c03002a0>] (__dev_close_many+0x94/0xc4) from [<c030037c>] (dev_close_many+0x78/0xe0)
>
> Signed-off-by: Andres Salomon <dilinger@queued.net>
> ---
> drivers/net/wireless/libertas/cfg.c | 25 +++++++++++++++++--------
> drivers/net/wireless/libertas/cfg.h | 1 +
> drivers/net/wireless/libertas/main.c | 6 ++----
> 3 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
> index ff63782..4fcd653 100644
> --- a/drivers/net/wireless/libertas/cfg.c
> +++ b/drivers/net/wireless/libertas/cfg.c
> @@ -728,15 +728,9 @@ static void lbs_scan_worker(struct work_struct *work)
> le16_to_cpu(scan_cmd->hdr.size),
> lbs_ret_scan, 0);
>
> - if (priv->scan_channel >= priv->scan_req->n_channels) {
> + if (priv->scan_channel >= priv->scan_req->n_channels)
> /* Mark scan done */
> - if (priv->internal_scan)
> - kfree(priv->scan_req);
> - else
> - cfg80211_scan_done(priv->scan_req, false);
> -
> - priv->scan_req = NULL;
> - }
> + lbs_scan_done(priv);
>
> /* Restart network */
> if (carrier)
> @@ -774,6 +768,21 @@ static void _internal_start_scan(struct lbs_private *priv, bool internal,
> lbs_deb_leave(LBS_DEB_CFG80211);
> }
>
> +/*
> + * Clean up priv->scan_req. Should be used to handle the allocation details.
> + */
> +void lbs_scan_done(struct lbs_private *priv)
> +{
> + WARN_ON(!priv->scan_req);
> +
> + if (priv->internal_scan)
> + kfree(priv->scan_req);
> + else
> + cfg80211_scan_done(priv->scan_req, false);
> +
> + priv->scan_req = NULL;
> +}
> +
> static int lbs_cfg_scan(struct wiphy *wiphy,
> struct net_device *dev,
> struct cfg80211_scan_request *request)
> diff --git a/drivers/net/wireless/libertas/cfg.h b/drivers/net/wireless/libertas/cfg.h
> index a02ee15..558168c 100644
> --- a/drivers/net/wireless/libertas/cfg.h
> +++ b/drivers/net/wireless/libertas/cfg.h
> @@ -16,6 +16,7 @@ int lbs_reg_notifier(struct wiphy *wiphy,
> void lbs_send_disconnect_notification(struct lbs_private *priv);
> void lbs_send_mic_failureevent(struct lbs_private *priv, u32 event);
>
> +void lbs_scan_done(struct lbs_private *priv);
> void lbs_scan_deinit(struct lbs_private *priv);
> int lbs_disconnect(struct lbs_private *priv, u16 reason);
>
> diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
> index b03779b..39a6a7a 100644
> --- a/drivers/net/wireless/libertas/main.c
> +++ b/drivers/net/wireless/libertas/main.c
> @@ -255,10 +255,8 @@ static int lbs_eth_stop(struct net_device *dev)
>
> lbs_update_mcast(priv);
> cancel_delayed_work_sync(&priv->scan_work);
> - if (priv->scan_req) {
> - cfg80211_scan_done(priv->scan_req, false);
> - priv->scan_req = NULL;
> - }
> + if (priv->scan_req)
> + lbs_scan_done(priv);
>
> netif_carrier_off(priv->dev);
>
^ permalink raw reply
* [PATCH] libertas: ensure we clean up a scan request properly
From: Andres Salomon @ 2011-10-26 17:19 UTC (permalink / raw)
To: Dan Williams
Cc: linville, libertas-dev, linux-wireless, netdev, linux-kernel, dsd
Commit 2e30168b ("libertas: terminate scan when stopping interface")
adds cleanup code to lbs_eth_stop to call cfg80211_scan_done if there's
an outstanding cfg80211_scan_request. However, it assumes that the
scan request was allocated via the cfg80211 stack. Libertas has
its own internal allocation method, kept track of with
priv->internal_scan. This doesn't set scan_req->wiphy, amongst other
things, which results in hitting a BUG() when we call cfg80211_scan_done
on the request.
This provides a function to take care of the low-level scan_req cleanup
details. We simply call that to deal with finishing up scan requests.
The bug we were hitting was:
[ 964.321495] kernel BUG at net/wireless/core.h:87!
[ 964.329970] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 964.341963] pgd = dcf80000
...
[ 964.849998] 9fe0: 00000000 beb417b8 4018e280 401e822c 60000010 00000004 00000000 00000000
[ 964.865007] [<c003104c>] (__bug+0x1c/0x28) from [<c0384ffc>] (cfg80211_scan_done+0x54/0x6c)
[ 964.895324] [<c0384ffc>] (cfg80211_scan_done+0x54/0x6c) from [<bf028bac>] (lbs_eth_stop+0x10c/0x188 [libertas])
[ 964.895324] [<bf028bac>] (lbs_eth_stop+0x10c/0x188 [libertas]) from [<c03002a0>] (__dev_close_many+0x94/0xc4)
[ 964.918995] [<c03002a0>] (__dev_close_many+0x94/0xc4) from [<c030037c>] (dev_close_many+0x78/0xe0)
Signed-off-by: Andres Salomon <dilinger@queued.net>
---
drivers/net/wireless/libertas/cfg.c | 25 +++++++++++++++++--------
drivers/net/wireless/libertas/cfg.h | 1 +
drivers/net/wireless/libertas/main.c | 6 ++----
3 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index ff63782..4fcd653 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -728,15 +728,9 @@ static void lbs_scan_worker(struct work_struct *work)
le16_to_cpu(scan_cmd->hdr.size),
lbs_ret_scan, 0);
- if (priv->scan_channel >= priv->scan_req->n_channels) {
+ if (priv->scan_channel >= priv->scan_req->n_channels)
/* Mark scan done */
- if (priv->internal_scan)
- kfree(priv->scan_req);
- else
- cfg80211_scan_done(priv->scan_req, false);
-
- priv->scan_req = NULL;
- }
+ lbs_scan_done(priv);
/* Restart network */
if (carrier)
@@ -774,6 +768,21 @@ static void _internal_start_scan(struct lbs_private *priv, bool internal,
lbs_deb_leave(LBS_DEB_CFG80211);
}
+/*
+ * Clean up priv->scan_req. Should be used to handle the allocation details.
+ */
+void lbs_scan_done(struct lbs_private *priv)
+{
+ WARN_ON(!priv->scan_req);
+
+ if (priv->internal_scan)
+ kfree(priv->scan_req);
+ else
+ cfg80211_scan_done(priv->scan_req, false);
+
+ priv->scan_req = NULL;
+}
+
static int lbs_cfg_scan(struct wiphy *wiphy,
struct net_device *dev,
struct cfg80211_scan_request *request)
diff --git a/drivers/net/wireless/libertas/cfg.h b/drivers/net/wireless/libertas/cfg.h
index a02ee15..558168c 100644
--- a/drivers/net/wireless/libertas/cfg.h
+++ b/drivers/net/wireless/libertas/cfg.h
@@ -16,6 +16,7 @@ int lbs_reg_notifier(struct wiphy *wiphy,
void lbs_send_disconnect_notification(struct lbs_private *priv);
void lbs_send_mic_failureevent(struct lbs_private *priv, u32 event);
+void lbs_scan_done(struct lbs_private *priv);
void lbs_scan_deinit(struct lbs_private *priv);
int lbs_disconnect(struct lbs_private *priv, u16 reason);
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index b03779b..39a6a7a 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -255,10 +255,8 @@ static int lbs_eth_stop(struct net_device *dev)
lbs_update_mcast(priv);
cancel_delayed_work_sync(&priv->scan_work);
- if (priv->scan_req) {
- cfg80211_scan_done(priv->scan_req, false);
- priv->scan_req = NULL;
- }
+ if (priv->scan_req)
+ lbs_scan_done(priv);
netif_carrier_off(priv->dev);
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] mac80211: support adding IV-room in the skb for CCMP keys
From: Johannes Berg @ 2011-10-26 9:59 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless
In-Reply-To: <1319350901-31178-1-git-send-email-arik@wizery.com>
On 10/23/2011 8:21 AM, Arik Nemtsov wrote:
> Some cards can generate CCMP IVs in HW, but require the space for the IV
> to be pre-allocated in the frame at the correct offset. Add a key flag
> that allows us to achieve this.
Is it really that expensive to generate the IV and then not use it that
this is worth the extra complexity? This not just makes it more complex
but also more expensive in the other case.
johannes
^ permalink raw reply
* Re: [RFC 1/7] mac80211: mesh power mode indication in QoS frames
From: Johannes Berg @ 2011-10-26 9:57 UTC (permalink / raw)
To: Ivan Bezyazychnyy; +Cc: linux-wireless
In-Reply-To: <CAG5dHkQtVC-cgEWcZOC_woLGeQ75Pkg-JmETWxVKJGdHs8qoOA@mail.gmail.com>
On 10/23/2011 3:10 PM, Ivan Bezyazychnyy wrote:
> On 21 October 2011 13:52, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Fri, 2011-10-21 at 12:36 +0400, Ivan Bezyazychnyy wrote:
>>
>>> +/* mesh power save level subfield mask */
>>> +#define IEEE80211_QOS_CTL_PS_LEVEL 0x0200
>>
>> That looks like it could use a better name?
>
> Do you mean something like IEEE80211_QOS_CTL_MESH_POWER_SAVE_LEVEL?
> The first half is similar to previous constants.
Not really .. I mean, it's like you have two levels, 0 and 1, but you
say this is the level. Why not say this is the 1 level, and the 0 level
is implied otherwise?
For example, typically, if we have something like a bit in a field that
indicates the device is getting too hot, we'll call it
FOOBAR_DEVICE_TOO_HOT
and not
FOOBAR_DEVICE_TEMPERATURE_LEVEL
Basically I think that the constant name you have now tells me nothing
about what it means when the bit is set and I think it'd be better if it
did. That might not even be possible, but I think in that case you
really should add a comment, e.g.:
/*
* mesh power save level:
* set - the device is doing ...
* unset - the device is doing ...
*/
#define ...
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: use min rate as basic rate for buggy APs
From: Johannes Berg @ 2011-10-26 9:53 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <1319531194-26839-1-git-send-email-eliad@wizery.com>
On 10/25/2011 10:26 AM, Eliad Peller wrote:
> Some buggy APs (and even P2P_GO) don't advertise their
> basic rates in the association response.
>
> In such case, use the min supported rate as the
> basic rate.
I seem to vaguely remember discussing using mandatory rates, did we?
Also this seems like a last resort fallback, I'd really also try using
the probe response information -- we should have that information still
at this point. But maybe that doesn't make sense -- fix the APs instead!
I'd really like a (debug?) message here though. This is a stupid AP, and
I will need to know if I'm debugging some throughput issues etc.
johannes
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-26 16:12 UTC (permalink / raw)
To: Chiefdome; +Cc: linux-wireless
In-Reply-To: <4EA82BFE.1070105@googlemail.com>
On 10/26/2011 10:49 AM, Chiefdome wrote:
> Is there a way to set the tx-power over 20dbm on the adapter?
> I thought it is able to do 2w. There is no way for me to get it over 20 dbm.
> When trying to to set the adapter with "iwconfig wlan1 set txpower 30" it answers
>
> Error for wireless request "Set Tx Power" (8B26) :
> SET failed on device wlan1 ; Invalid argument.
>
> I think there has to be done some work in the code but where do I start?
>
> Thanks for all replys.
The WEXT interface is deprecated. It is there as a convenience, but it will not
be extended. To change the power setting, you need to use the iw utility. The
specific commands are:
iw dev <devname> set txpower <auto|fixed|limit> [<tx power in mBm>]
or
iw phy <phyname> set txpower <auto|fixed|limit> [<tx power in mBm>]
The maximum power will be dependent on your regulatory domain setting.
Larry
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Chiefdome @ 2011-10-26 15:49 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4EA023B2.5000402@lwfinger.net>
Is there a way to set the tx-power over 20dbm on the adapter?
I thought it is able to do 2w. There is no way for me to get it over 20 dbm.
When trying to to set the adapter with "iwconfig wlan1 set txpower 30"
it answers
Error for wireless request "Set Tx Power" (8B26) :
SET failed on device wlan1 ; Invalid argument.
I think there has to be done some work in the code but where do I start?
Thanks for all replys.
^ permalink raw reply
* [PATCH] ath6kl: Fix compile error for ARM
From: Sangwook Lee @ 2011-10-26 15:28 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, patches, Sangwook Lee
Fix the compile error for ARM Platform.
Signed-off-by: Sangwook Lee <sangwook.lee@linaro.org>
---
Compile errors come from ARM plaform:
In file included from drivers/net/wireless/ath/ath6kl/init.c:19:0:
include/linux/of.h: In function ‘of_property_read_u32_array’:
include/linux/of.h:249:10: error: ‘ENOSYS’ undeclared
drivers/net/wireless/ath/ath6kl/init.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index 4c0c314..64975a9 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -16,6 +16,7 @@
*/
#include <linux/moduleparam.h>
+#include <linux/errno.h>
#include <linux/of.h>
#include <linux/mmc/sdio_func.h>
#include "core.h"
--
1.7.4.1
^ permalink raw reply related
* [PATCH] wl12xx: clear wl->vif on remove_interface
From: Eliad Peller @ 2011-10-26 14:40 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
wl->vif should be cleared on remove_interface()
(rather than on stop()) even when only a single
vif is supported, because during vif mode change
stop() might not get called (e.g. because of
monitor interface existence)
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/wl12xx/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index dc2ebb2..b9f9ef7 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -1859,7 +1859,6 @@ static void wl1271_op_stop(struct ieee80211_hw *hw)
wl->tx_results_count = 0;
wl->tx_packets_count = 0;
wl->time_offset = 0;
- wl->vif = NULL;
wl->tx_spare_blocks = TX_HW_BLOCK_SPARE_DEFAULT;
wl->ap_fw_ps_map = 0;
wl->ap_ps_map = 0;
@@ -2316,6 +2315,7 @@ static void wl1271_op_remove_interface(struct ieee80211_hw *hw,
break;
}
WARN_ON(iter != wlvif);
+ wl->vif = NULL;
out:
mutex_unlock(&wl->mutex);
cancel_work_sync(&wl->recovery_work);
--
1.7.6.401.g6a319
^ permalink raw reply related
* ipw2200 fails to load firmware when returning from suspend
From: plaes @ 2011-10-26 9:38 UTC (permalink / raw)
To: linux-wireless
Heya!
I've been running into following issue with recent kernels fairly often
when waking up Dell Latitude D610 laptop from suspend:
[snip]
[347767.844024] pci 0000:00:1e.0: setting latency timer to 64
[347767.844046] eth1: Coming out of suspend...
[347767.844060] ipw2200 0000:03:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[347767.884092] ------------[ cut here ]------------
[347767.884107] WARNING: at drivers/base/firmware_class.c:537 _request_firmware+0xb5/0x31b()
[347767.884113] Hardware name: Latitude D610
[347767.884117] Modules linked in: lib80211_crypt_ccmp ipw2200 tg3 libipw libphy lib80211
[347767.884134] Pid: 17562, comm: kworker/0:0 Not tainted 3.1.0-rc8+ #50
[347767.884139] Call Trace:
[347767.884150] [<c1027fce>] ? warn_slowpath_common+0x7c/0x8f
[347767.884159] [<c1287e1c>] ? _request_firmware+0xb5/0x31b
[347767.884167] [<c1287e1c>] ? _request_firmware+0xb5/0x31b
[347767.884176] [<c1027ffc>] ? warn_slowpath_null+0x1b/0x1f
[347767.884184] [<c1287e1c>] ? _request_firmware+0xb5/0x31b
[347767.884194] [<c12880f8>] ? request_firmware+0x17/0x1b
[347767.884211] [<f83900a8>] ? ipw_up+0xf9/0x133f [ipw2200]
[347767.884222] [<c101ee71>] ? set_next_entity+0xb4/0x122
[347767.884230] [<c1001a9b>] ? __switch_to+0x34/0x10f
[347767.884239] [<c101f6b7>] ? finish_task_switch.clone.124.clone.138+0x3e/0x76
[347767.884247] [<c101e963>] ? need_resched+0x11/0x1a
[347767.884258] [<c13f13b1>] ? __schedule+0x471/0x4e7
[347767.884274] [<f83914d3>] ? ipw_bg_up+0x1c/0x25 [ipw2200]
[347767.884283] [<c1037370>] ? process_one_work+0xfd/0x1af
[347767.884298] [<f83914b7>] ? ipw_net_init+0x32/0x32 [ipw2200]
[347767.884307] [<c1038437>] ? worker_thread+0xbd/0x134
[347767.884316] [<c103837a>] ? manage_workers.clone.30+0x19f/0x19f
[347767.884324] [<c103aaaf>] ? kthread+0x62/0x67
[347767.884332] [<c103aa4d>] ? flush_kthread_worker+0x7a/0x7a
[347767.884341] [<c13f3076>] ? kernel_thread_helper+0x6/0xd
[347767.884347] ---[ end trace 4141d0bfaee985bf ]---
[347767.884353] ipw2200 0000:03:03.0: firmware: ipw2200-bss.fw will not be loaded
[347767.884360] ipw2200: ipw2200-bss.fw request_firmware failed: Reason -16
[347767.884365] ipw2200: Unable to load firmware: -16
...
[347769.850709] Restarting tasks ... done.
[347770.870138] ipw2200: No space for Tx
[347770.870143] ipw2200: Failed to send POWER_MODE: Reason -16
[/snip]
After rmmod/insmod cycle card works fine again:
[snip]
[347824.614542] ipw2200 0000:03:03.0: PCI INT A disabled
[347832.294216] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.2kmprq
[347832.294221] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[347832.294353] ipw2200 0000:03:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[347832.294382] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
[347832.503972] cfg80211: failed to add phy80211 symlink to netdev!
[347832.505049] ipw2200: Detected geography ZZD (13 802.11bg channels, 0 802.11a channels)
[/snip]
[snip]
03:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)
Subsystem: Intel Corporation Dell Latitude D600
Flags: bus master, medium devsel, latency 64, IRQ 17
Memory at dfbff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
Kernel driver in use: ipw2200
Kernel modules: ipw2200
[/snip]
Any ideas where to look further?
Päikest,
Priit Laes ;)
^ permalink raw reply
* [PATCH] mac80211: init rate-control for TDLS sta when supp-rates are known
From: Arik Nemtsov @ 2011-10-26 13:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg, Arik Nemtsov
Initialize rate control algorithms only when supported rates are known
for a TDLS peer sta. Direct Tx between peers is not allowed before the
link is enabled. In turn, this only occurs after a change_station()
call that sets supported rates.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
net/mac80211/cfg.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1309bb9..9f05416d 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -829,7 +829,12 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
sdata->vif.type == NL80211_IFTYPE_STATION))
return -ENOTSUPP;
- rate_control_rate_init(sta);
+ /*
+ * for TDLS, rate control should be initialized only when supported
+ * rates are known.
+ */
+ if (!test_sta_flag(sta, WLAN_STA_TDLS_PEER))
+ rate_control_rate_init(sta);
layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
sdata->vif.type == NL80211_IFTYPE_AP;
@@ -913,6 +918,9 @@ static int ieee80211_change_station(struct wiphy *wiphy,
sta_apply_parameters(local, sta, params);
+ if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) && params->supported_rates)
+ rate_control_rate_init(sta);
+
rcu_read_unlock();
if (sdata->vif.type == NL80211_IFTYPE_STATION &&
--
1.7.5.4
^ permalink raw reply related
* How to enable clock/power from a wlan device driver
From: Dmitry Tarnyagin @ 2011-10-26 12:35 UTC (permalink / raw)
To: linux-wireless
Dear community,
Could you please give me an advise how to implement properly (in terms
of architecture design)
enabling / disabling of external functional clock and power of a WLAN
device from a (mac80211-based)
device driver?
We have a device on a board which needs to be powered on and clocked
before driver can use it.
There are several options:
1. Driver can call clk_get()/clk_enable() itself using name of the clock.
2. Driver can get struct clk* from platform data and call clk_enable()
3. Driver can call platform callback and request platform code to
enable the clock.
What is preferable way of doing it? I see there is no
clk_get()/regulator_get() calls from the
drivers/net/wireless/ code, nor *_enable(). For my understanding
clocks and power are platform-specific.
Other boards/platform using the same chip can require other clocks or
not require them at all in case
of self-clocked design. Same with power.
Thank you and with best regards,
Dmitry Tarnyagin
^ permalink raw reply
* Re: How to find the phy's associated with a wireless dev
From: Divinsky, Yonatan @ 2011-10-26 12:18 UTC (permalink / raw)
To: David Goodenough; +Cc: linux-wireless
In-Reply-To: <CACVrECHsEQ5fNeeZsaFUh=oHy9Kgc_ZLbnn4-fypSBhCbooq-g@mail.gmail.com>
On Wed, Oct 26, 2011 at 12:32 PM, Mariana Gambande <mlgambande@gmail.com> wrote:
>
> Hello Davis,
> Maybe is easier for you to create an udev rule to rename your wireless
> devices always the same way. An example:
>
> file /etc/udev/rules.d/wireless-devices.rules:
>
> KERNEL=="phy*", SYSFS{address}=="00:xx:xx:xx:xx:xx", NAME="phy0"
> KERNEL=="phy*", SYSFS{address}=="00:xx:xx:xx:xx:xx", NAME="phy1"
>
> You can see more information here
> http://www.science.uva.nl/research/air/wiki/LogicalInterfaceNames?show_comments=1
>
> This works fine for me :)
>
>
> 2011/10/25 Ben Greear <greearb@candelatech.com>
> >
> > On 10/25/2011 11:10 AM, David Goodenough wrote:
> >>
> >> I notice that if I remove the kernel module for a wireless
> >> interface and reload it, that a new phy is defined. This is
> >> confusing my script that sets up interfaces, in particular I
> >> need to set the distance for a long distance link and that has
> >> to be done on the phy not the dev.
> >>
> >> I am doing this from a script so I guess it has to be a query
> >> using iw, but I can not see which one to use.
> >
> > On a recent kernel:
> > cat /sys/class/net/wlan0/phy80211/name
> >
If your kernel does not support it you could just do:
iw phy | grep -o -m1 -e 'phy[0-9]'
Thanks,
Yoni
>
> > Thanks,
> > Ben
> >
> >
> >>
> >> David
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
> > --
> > Ben Greear <greearb@candelatech.com>
> > Candela Technologies Inc http://www.candelatech.com
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: How to find the phy's associated with a wireless dev
From: Mariana Gambande @ 2011-10-26 10:32 UTC (permalink / raw)
To: Ben Greear; +Cc: David Goodenough, linux-wireless
In-Reply-To: <4EA70429.8070505@candelatech.com>
Hello Davis,
Maybe is easier for you to create an udev rule to rename your wireless
devices always the same way. An example:
file /etc/udev/rules.d/wireless-devices.rules:
KERNEL=="phy*", SYSFS{address}=="00:xx:xx:xx:xx:xx", NAME="phy0"
KERNEL=="phy*", SYSFS{address}=="00:xx:xx:xx:xx:xx", NAME="phy1"
You can see more information here
http://www.science.uva.nl/research/air/wiki/LogicalInterfaceNames?show_comments=1
This works fine for me :)
2011/10/25 Ben Greear <greearb@candelatech.com>
>
> On 10/25/2011 11:10 AM, David Goodenough wrote:
>>
>> I notice that if I remove the kernel module for a wireless
>> interface and reload it, that a new phy is defined. This is
>> confusing my script that sets up interfaces, in particular I
>> need to set the distance for a long distance link and that has
>> to be done on the phy not the dev.
>>
>> I am doing this from a script so I guess it has to be a query
>> using iw, but I can not see which one to use.
>
> On a recent kernel:
> cat /sys/class/net/wlan0/phy80211/name
>
> Thanks,
> Ben
>
>
>>
>> David
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/9] ath6kl: remove unused A_CACHE_LINE_PAD
From: Kalle Valo @ 2011-10-26 8:33 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20111024091644.5004.2767.stgit@localhost6.localdomain6>
On 10/24/2011 12:16 PM, Kalle Valo wrote:
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
All nine patches applied. There were some conflicts but git was able to
handle that.
Kalle
^ 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