* Re: pci-half-mini 7206 ac/bluetooth issues
From: Emmanuel Grumbach @ 2013-10-08 19:21 UTC (permalink / raw)
To: Tim Nelson, linux-wireless
In-Reply-To: <CAOAOC6YGEphx+qo43hSWd=24knae_UC=JViTuiEUTT4TuGix4g@mail.gmail.com>
On Tue, Oct 8, 2013 at 10:06 PM, Tim Nelson <tim.l.nelson@gmail.com> wrote:
>
> The first step works, I tested it for a couple of days with no issues.
> I will test the power statement on it's own later today and let you
> know the results of it.
>
This is really weird... Please notice that new BT FW was published in
the last few days to linux-firmware.git. Can you please also try with
the new BT FW and without bt_coex_active=0?
Do you have the ability to use trace-cmd?
How long does it take to have wifi / bt die?
^ permalink raw reply
* Re: [PATCH/RFT v2 0/4] ath10k: fixes
From: Kalle Valo @ 2013-10-08 19:17 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380865425-3791-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> This patchset addresses recently spotted issue
> with (yet another) scheduling while atomic bug
> (the other being WEP key index setting). This one
> is related to hw_config() and powersave settings.
> This comes from recent changes I've done to
> HTC/WMI. WMI commands can block now so it's
> illegal to call them in an atomic context anymore.
>
> ath10k needs to setup some settings per-vdev (i.e.
> per-interface) such as powersave, rts, fragmentation.
> Until now mac80211 iteration functions were used.
> However using non-atomic iteration function variant
> doesn't solve the problem as it introduces an
> issue with iflist_mtx deadlock in some cases.
>
> I briefly tried to reproduce the issue Kalle
> reported but was unsuccessful thus the "/RFT".
>
> v2:
> * fix kbuild test robot warning
> (uninitialized `ret`)
> * add patch #4 that removes code that becomes
> unnecessary after patch #3
>
>
> Michal Kazior (4):
> ath10k: fix add_interface failure handling
> ath10k: track vif list internally
> ath10k: fix scheduling while atomic config bug
> ath10k: remove unnecessary checks
Due to problems with patch 1 I'm dropping this patchset for now.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH/RFT v2 1/4] ath10k: fix add_interface failure handling
From: Kalle Valo @ 2013-10-08 19:16 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, ath10k
In-Reply-To: <CA+BoTQ=qep+rKEyLKrNjNP6K1q+FHKpvkscwXuRMR_45YnRvHA@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 8 October 2013 05:54, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> If something failed along add_interface() setup it
>>> was possible to leak a vdev id, vdev and peer.
>>>
>>> This could end up with leaked FW state or FW crash
>>> (assuming add_interface() failure wasn't a result of
>>> a crash).
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>
>> Then I apply this patch on top of current ath.git master branch (commit
>> 18fe0b53e76) interface up fails on the managed mode:
>>
>> $ sudo ip link set wlan1 up
>> RTNETLINK answers: Invalid argument
>>
>> Logs don't have anything special (the TX encap error was already
>> before):
>>
>> [ 1259.818863] ath10k: MSI-X didn't succeed (1), trying MSI
>> [ 1259.819298] ath10k_pci 0000:02:00.0: irq 49 for MSI/MSI-X
>> [ 1259.820055] ath10k: MSI interrupt handling
>> [ 1260.747877] ath10k: UART prints disabled
>> [ 1260.828219] ath10k: firmware 10.1.389 booted
>> [ 1260.837585] ath10k: htt target version 2.1
>> [ 1260.838498] ath10k: Failed to set TX encap: -22
>
> Ah. Right. I've tested this patch with main FW branch which supports
> TX encap command. The TX encap issue should be dealth with first.
What do you mean? Did I miss a patch?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: fix station authorization
From: Kalle Valo @ 2013-10-08 19:09 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, ath10k
In-Reply-To: <8761t7sibr.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> Peer authorization should be delayed until
>> mac80211 says given station has transitioned into
>> authorized state.
>>
>> The state is propagated from mac80211 for both
>> open and protected networks.
>>
>> This should prevent data traffic to/from given
>> station until authorization completes. Until now
>> it was probably possible for unauthorized traffic
>> to pass leading to possible security issues.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Thanks, applied.
Actually I'll take this back. After this patch even ping doesn't work
with D-Link DIR-865L as AP using 10.1.389 firmware. So I have to drop
this patch.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 19:08 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-wireless, netdev, patches, linville
In-Reply-To: <1381231915-24232-1-git-send-email-ard.biesheuvel@linaro.org>
I'm not too familiar with the aead API, so here's another question:
> + sg_init_one(&pt, data, data_len);
> + sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
> + sg_init_table(ct, 2);
> + sg_set_buf(&ct[0], cdata, data_len);
> + sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
Is it guaranteed to be allowed that the input and output are the same
buffer? It seems we rely on that for encrypt_one(), but is it true here
as well?
(Btw - why pass in data/cdata as separate pointers into the function?)
> @@ -343,7 +337,7 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
> data_len -= IEEE80211_CCMP_MIC_LEN;
>
> /* First block, b_0 */
> - b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
> + b_0[0] = 0x1; /* set L := 1, M and Adata flags are implied */
Hmm. I don't think I understand, can you explain this to me?
johannes
^ permalink raw reply
* Re: [PATCH v3 0/2] ath10k: wep & ampdu fix
From: Kalle Valo @ 2013-10-08 18:58 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1381200718-16271-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> One throughput fix and one bug fix.
>
> The bug fix addresses my oversight when reworking
> HTC/WMI. I haven't seen the error yet but I'm
> quite certain this should be fixed.
>
> v2:
> * A-MPDU patch contains a workaround for
> Netgear/Linksys 11ac APs
> * patchset cover mail title changed to avoid
> confusion (too many patchsets named the same
> way..)
>
> v3:
> * fix lines over 80 chars (Kalle)
> * fix max() cast warning (Kalle)
> * rebase (Kalle)
> * add Tested-by (thanks Kalle!)
>
>
> Michal Kazior (1):
> ath10k: fix scheduling while atomic bug
I dropped this patch for now, need to think more about how to handle
this.
> Sujith Manoharan (1):
> ath10k: Fix bug in max. VHT A-MPDU size
This is applied, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: fix station authorization
From: Kalle Valo @ 2013-10-08 18:55 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380875428-20899-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Peer authorization should be delayed until
> mac80211 says given station has transitioned into
> authorized state.
>
> The state is propagated from mac80211 for both
> open and protected networks.
>
> This should prevent data traffic to/from given
> station until authorization completes. Until now
> it was probably possible for unauthorized traffic
> to pass leading to possible security issues.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* [PATCH] ath10k: remove unneded semicolon from ath10k_core_fetch_firmware_api_n()
From: Kalle Valo @ 2013-10-08 18:48 UTC (permalink / raw)
To: ath10k; +Cc: Fengguang Wu, linux-wireless
From: Fengguang Wu <fengguang.wu@intel.com>
drivers/net/wireless/ath/ath10k/core.c:507:2-3: Unneeded semicolon
Removes unneeded semicolon.
Generated by: coccinelle/misc/semicolon.cocci
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 5acb404..10c519d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -507,7 +507,7 @@ static int ath10k_core_fetch_firmware_api_n(struct ath10k *ar, const char *name)
len -= ie_len;
data += ie_len;
- };
+ }
if (!ar->firmware_data || !ar->firmware_len) {
ath10k_warn("No ATH10K_FW_IE_FW_IMAGE found from %s, skipping\n",
^ permalink raw reply related
* [PATCH] ath10k: fix ath10k_debug_start() locking
From: Kalle Valo @ 2013-10-08 18:45 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
ath10k_debug_start() was not called with conf_mutex, fix that. Also there was a
deadlock in ath10k_debug_stop(), rename it to ath10k_debug_destroy() and call
it only when the device is destroyed.
Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 12 ++++++++++++
drivers/net/wireless/ath/ath10k/debug.c | 15 ++++++++++++++-
drivers/net/wireless/ath/ath10k/debug.h | 5 +++++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 5acb404..e016f51 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -737,6 +737,8 @@ EXPORT_SYMBOL(ath10k_core_create);
void ath10k_core_destroy(struct ath10k *ar)
{
+ ath10k_debug_destroy(ar);
+
flush_workqueue(ar->workqueue);
destroy_workqueue(ar->workqueue);
@@ -748,6 +750,8 @@ int ath10k_core_start(struct ath10k *ar)
{
int status;
+ lockdep_assert_held(&ar->conf_mutex);
+
ath10k_bmi_start(ar);
if (ath10k_init_configure_target(ar)) {
@@ -836,6 +840,8 @@ EXPORT_SYMBOL(ath10k_core_start);
void ath10k_core_stop(struct ath10k *ar)
{
+ lockdep_assert_held(&ar->conf_mutex);
+
ath10k_debug_stop(ar);
ath10k_htc_stop(&ar->htc);
ath10k_htt_detach(&ar->htt);
@@ -883,15 +889,21 @@ static int ath10k_core_probe_fw(struct ath10k *ar)
return ret;
}
+ mutex_lock(&ar->conf_mutex);
+
ret = ath10k_core_start(ar);
if (ret) {
ath10k_err("could not init core (%d)\n", ret);
ath10k_core_free_firmware_files(ar);
ath10k_hif_power_down(ar);
+ mutex_unlock(&ar->conf_mutex);
return ret;
}
ath10k_core_stop(ar);
+
+ mutex_unlock(&ar->conf_mutex);
+
ath10k_hif_power_down(ar);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 59615c7..760ff22 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -618,6 +618,8 @@ int ath10k_debug_start(struct ath10k *ar)
{
int ret;
+ lockdep_assert_held(&ar->conf_mutex);
+
ret = ath10k_debug_htt_stats_req(ar);
if (ret)
/* continue normally anyway, this isn't serious */
@@ -628,7 +630,13 @@ int ath10k_debug_start(struct ath10k *ar)
void ath10k_debug_stop(struct ath10k *ar)
{
- cancel_delayed_work_sync(&ar->debug.htt_stats_dwork);
+ lockdep_assert_held(&ar->conf_mutex);
+
+ /* Must not use _sync to avoid deadlock, we do that in
+ * ath10k_debug_destroy(). The check for htt_stats_mask is to avoid
+ * warning from del_timer(). */
+ if (ar->debug.htt_stats_mask != 0)
+ cancel_delayed_work(&ar->debug.htt_stats_dwork);
}
int ath10k_debug_create(struct ath10k *ar)
@@ -662,6 +670,11 @@ int ath10k_debug_create(struct ath10k *ar)
return 0;
}
+void ath10k_debug_destroy(struct ath10k *ar)
+{
+ cancel_delayed_work_sync(&ar->debug.htt_stats_dwork);
+}
+
#endif /* CONFIG_ATH10K_DEBUGFS */
#ifdef CONFIG_ATH10K_DEBUG
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index fa58148..46e640a 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -46,6 +46,7 @@ extern __printf(1, 2) int ath10k_warn(const char *fmt, ...);
int ath10k_debug_start(struct ath10k *ar);
void ath10k_debug_stop(struct ath10k *ar);
int ath10k_debug_create(struct ath10k *ar);
+void ath10k_debug_destroy(struct ath10k *ar);
void ath10k_debug_read_service_map(struct ath10k *ar,
void *service_map,
size_t map_size);
@@ -67,6 +68,10 @@ static inline int ath10k_debug_create(struct ath10k *ar)
return 0;
}
+static inline void ath10k_debug_destroy(struct ath10k *ar)
+{
+}
+
static inline void ath10k_debug_read_service_map(struct ath10k *ar,
void *service_map,
size_t map_size)
^ permalink raw reply related
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 18:27 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: David Laight, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <CAKv+Gu8D_7d=u1PGWuxoLEETHe8uJMby3K98uQWQn7tk=t_t_w@mail.gmail.com>
On Tue, 2013-10-08 at 16:52 +0200, Ard Biesheuvel wrote:
> However, personally I don't think this should be necessary and in fact
> my patch removes a stack allocation of u8[48] (from
> ieee80211_crypto_ccmp_decrypt() and from ccmp_encrypt_skb() in wpa.c)
> so it does even out a bit.
I tend to agree.
johannes
^ permalink raw reply
* Re: [PATCH/RFT v2 1/4] ath10k: fix add_interface failure handling
From: Michal Kazior @ 2013-10-08 16:49 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87mwmjsz2k.fsf@kamboji.qca.qualcomm.com>
On 8 October 2013 05:54, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> If something failed along add_interface() setup it
>> was possible to leak a vdev id, vdev and peer.
>>
>> This could end up with leaked FW state or FW crash
>> (assuming add_interface() failure wasn't a result of
>> a crash).
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Then I apply this patch on top of current ath.git master branch (commit
> 18fe0b53e76) interface up fails on the managed mode:
>
> $ sudo ip link set wlan1 up
> RTNETLINK answers: Invalid argument
>
> Logs don't have anything special (the TX encap error was already
> before):
>
> [ 1259.818863] ath10k: MSI-X didn't succeed (1), trying MSI
> [ 1259.819298] ath10k_pci 0000:02:00.0: irq 49 for MSI/MSI-X
> [ 1259.820055] ath10k: MSI interrupt handling
> [ 1260.747877] ath10k: UART prints disabled
> [ 1260.828219] ath10k: firmware 10.1.389 booted
> [ 1260.837585] ath10k: htt target version 2.1
> [ 1260.838498] ath10k: Failed to set TX encap: -22
Ah. Right. I've tested this patch with main FW branch which supports
TX encap command. The TX encap issue should be dealth with first.
Michał
^ permalink raw reply
* Re: WIFI P2P ping doesn't work.
From: Matt Chen @ 2013-10-08 16:03 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: linux-wireless
In-Reply-To: <52542B3B.1020703@rempel-privat.de>
Hi Oleksij,
Thanks for the info anyway. :)
2013/10/8 Oleksij Rempel <linux@rempel-privat.de>:
> Hi Matt,
>
> no suggestions. I was able to reproduce same issue yesterday on
> ath9k_htc. But currently no time to digg in it.
>
>
> Am 08.10.2013 17:41, schrieb Matt Chen:
>> No one has any suggestion and comment ?
>>
>> 2013/10/8 Matt Chen <machen@suse.com>:
>>> Hi list,
>>>
>>> I am running the v3.12-rc3 and using Atheros AR9485 with ath9k. My
>>> wpa_supplicant is from git://w1.fi/srv/git/hostap.git in master branch
>>> with most recent commit.
>>>
>>> The my_p2p_supplicant.conf for my wpa_supplicant is :
>>> =======================================
>>> ctrl=/var/run/wpa_supplicant
>>> update_config=1
>>>
>>> device_name=HP GO
>>> device_type=1-0050F204-2
>>>
>>> p2p_go_ht40=1
>>>
>>> =========================================
>>>
>>> I run "wpa_supplicant -i wlan0 -f my_p2p_supplicant.conf -Dnl80211
>>> -ddt -f /var/log/wpa_supplicant -B
>>>
>>> I use wpa_cli to work on P2P. So here goes my case:
>>>
>>> M#1
>>> p2p_find
>>> p2p_stop
>>> p2p_peers
>>> p2p_connect [M#2 MAC ADDRESS] pbc go_intent=7
>>>
>>> M#2
>>> p2p_find
>>> p2p_stop
>>> p2p_peers
>>> p2p_connect [M#1 MAC ADDRESS] pbc
>>>
>>>
>>> Then I can find the M#1 become the P0 GO mode and M#2 become station
>>> mode. And each status is completed. But after that, I set each machine
>>> with a static IP such as 192.168.5.10 and 192.168.5.11 manually. I am
>>> not able to ping each IP.
>>>
>>> Is there anything I am doing wrong ?
>>>
>>> Thank you.
>> --
>> 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
>>
>
>
> --
> Regards,
> Oleksij
> --
> 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: WIFI P2P ping doesn't work.
From: Oleksij Rempel @ 2013-10-08 15:56 UTC (permalink / raw)
To: Matt Chen, linux-wireless
In-Reply-To: <CALx5=V8AJr5FTWkbT+s79kbPX2NftmbC74HgH3V5TEUj0gvdpA@mail.gmail.com>
Hi Matt,
no suggestions. I was able to reproduce same issue yesterday on
ath9k_htc. But currently no time to digg in it.
Am 08.10.2013 17:41, schrieb Matt Chen:
> No one has any suggestion and comment ?
>
> 2013/10/8 Matt Chen <machen@suse.com>:
>> Hi list,
>>
>> I am running the v3.12-rc3 and using Atheros AR9485 with ath9k. My
>> wpa_supplicant is from git://w1.fi/srv/git/hostap.git in master branch
>> with most recent commit.
>>
>> The my_p2p_supplicant.conf for my wpa_supplicant is :
>> =======================================
>> ctrl=/var/run/wpa_supplicant
>> update_config=1
>>
>> device_name=HP GO
>> device_type=1-0050F204-2
>>
>> p2p_go_ht40=1
>>
>> =========================================
>>
>> I run "wpa_supplicant -i wlan0 -f my_p2p_supplicant.conf -Dnl80211
>> -ddt -f /var/log/wpa_supplicant -B
>>
>> I use wpa_cli to work on P2P. So here goes my case:
>>
>> M#1
>> p2p_find
>> p2p_stop
>> p2p_peers
>> p2p_connect [M#2 MAC ADDRESS] pbc go_intent=7
>>
>> M#2
>> p2p_find
>> p2p_stop
>> p2p_peers
>> p2p_connect [M#1 MAC ADDRESS] pbc
>>
>>
>> Then I can find the M#1 become the P0 GO mode and M#2 become station
>> mode. And each status is completed. But after that, I set each machine
>> with a static IP such as 192.168.5.10 and 192.168.5.11 manually. I am
>> not able to ping each IP.
>>
>> Is there anything I am doing wrong ?
>>
>> Thank you.
> --
> 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
>
--
Regards,
Oleksij
^ permalink raw reply
* Re: WIFI P2P ping doesn't work.
From: Matt Chen @ 2013-10-08 15:41 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CALx5=V_OdHRJsourv2Hiykg-shyrisdrNnzD1qvpjAWR2iQyfg@mail.gmail.com>
No one has any suggestion and comment ?
2013/10/8 Matt Chen <machen@suse.com>:
> Hi list,
>
> I am running the v3.12-rc3 and using Atheros AR9485 with ath9k. My
> wpa_supplicant is from git://w1.fi/srv/git/hostap.git in master branch
> with most recent commit.
>
> The my_p2p_supplicant.conf for my wpa_supplicant is :
> =======================================
> ctrl=/var/run/wpa_supplicant
> update_config=1
>
> device_name=HP GO
> device_type=1-0050F204-2
>
> p2p_go_ht40=1
>
> =========================================
>
> I run "wpa_supplicant -i wlan0 -f my_p2p_supplicant.conf -Dnl80211
> -ddt -f /var/log/wpa_supplicant -B
>
> I use wpa_cli to work on P2P. So here goes my case:
>
> M#1
> p2p_find
> p2p_stop
> p2p_peers
> p2p_connect [M#2 MAC ADDRESS] pbc go_intent=7
>
> M#2
> p2p_find
> p2p_stop
> p2p_peers
> p2p_connect [M#1 MAC ADDRESS] pbc
>
>
> Then I can find the M#1 become the P0 GO mode and M#2 become station
> mode. And each status is completed. But after that, I set each machine
> with a static IP such as 192.168.5.10 and 192.168.5.11 manually. I am
> not able to ping each IP.
>
> Is there anything I am doing wrong ?
>
> Thank you.
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192cu: Fix error in pointer arithmetic
From: Larry Finger @ 2013-10-08 15:18 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry Finger, netdev, Mark Cave-Ayland, Stable
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
An error in calculating the offset in an skb causes the driver to read
essential device info from the wrong locations. The main effect is that
automatic gain calculations are nonsense.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [2.6.39+]
---
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
index 04c7e57..25e50ff 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
@@ -343,7 +343,8 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
(bool)GET_RX_DESC_PAGGR(pdesc));
rx_status->mactime = GET_RX_DESC_TSFL(pdesc);
if (phystatus) {
- p_drvinfo = (struct rx_fwinfo_92c *)(pdesc + RTL_RX_DESC_SIZE);
+ p_drvinfo = (struct rx_fwinfo_92c *)(skb->data +
+ stats->rx_bufshift);
rtl92c_translate_rx_signal_stuff(hw, skb, stats, pdesc,
p_drvinfo);
}
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Add new firmware files for rtl8192cu
From: Larry Finger @ 2013-10-08 15:00 UTC (permalink / raw)
To: dwmw2, Ben Hutchings; +Cc: linux-wireless
In-Reply-To: <1380234392-31062-1-git-send-email-Larry.Finger@lwfinger.net>
On 09/26/2013 05:26 PM, Larry Finger wrote:
> The vendor driver rtl8188C_8192C_8192D_usb_linux_v3.4.2_3727.20120404
> includes new firmware files. These were extracted from data statements
> in that driver to form these files.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> WHENCE | 3 +++
> rtlwifi/rtl8192cufw_A.bin | Bin 0 -> 16116 bytes
> rtlwifi/rtl8192cufw_B.bin | Bin 0 -> 16096 bytes
> rtlwifi/rtl8192cufw_TMSC.bin | Bin 0 -> 16116 bytes
> 4 files changed, 3 insertions(+)
> create mode 100644 rtlwifi/rtl8192cufw_A.bin
> create mode 100644 rtlwifi/rtl8192cufw_B.bin
> create mode 100644 rtlwifi/rtl8192cufw_TMSC.bin
I understand that you probably have too much to do, but I am inquiring about the
status of this submission and "[PATCH] rtlwifi: Add new firmware files for
rtl8188eu" that I sent on 09/27/2013. I have several patches that depend on
these firmware files, and I would prefer that those driver patches are submitted
in time to make the 3.13 kernel.
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 14:52 UTC (permalink / raw)
To: Johannes Berg
Cc: David Laight, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <1381239951.13359.13.camel@jlt4.sipsolutions.net>
On 8 October 2013 15:45, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-10-08 at 15:45 +0200, Johannes Berg wrote:
>> On Tue, 2013-10-08 at 15:41 +0200, Ard Biesheuvel wrote:
>>
>> > Actually, as the size is always the same, it should be feasible to
>> > alloc a couple of request structs at init time. would one for rx and
>> > one for tx be sufficient? or is this code more reentrant than that?
>>
>> TX can run concurrently on multiple (four) queues using the same key.
>
> And maybe even more with injection ... I wouldn't go there.
>
OK, clear.
If you think this patch has any merit at all, I am happy to modify it
so that it kmalloc()s the request struct with GFP_ATOMIC at every
invocation.
However, personally I don't think this should be necessary and in fact
my patch removes a stack allocation of u8[48] (from
ieee80211_crypto_ccmp_decrypt() and from ccmp_encrypt_skb() in wpa.c)
so it does even out a bit.
regards,
Ard.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 13:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: David Laight, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <1381239908.13359.12.camel@jlt4.sipsolutions.net>
On Tue, 2013-10-08 at 15:45 +0200, Johannes Berg wrote:
> On Tue, 2013-10-08 at 15:41 +0200, Ard Biesheuvel wrote:
>
> > Actually, as the size is always the same, it should be feasible to
> > alloc a couple of request structs at init time. would one for rx and
> > one for tx be sufficient? or is this code more reentrant than that?
>
> TX can run concurrently on multiple (four) queues using the same key.
And maybe even more with injection ... I wouldn't go there.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 13:45 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: David Laight, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <23D74823-0DE3-4A87-9E89-310F437A328D@linaro.org>
On Tue, 2013-10-08 at 15:41 +0200, Ard Biesheuvel wrote:
> Actually, as the size is always the same, it should be feasible to
> alloc a couple of request structs at init time. would one for rx and
> one for tx be sufficient? or is this code more reentrant than that?
TX can run concurrently on multiple (four) queues using the same key.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 13:41 UTC (permalink / raw)
To: David Laight
Cc: Johannes Berg, <linux-wireless@vger.kernel.org>,
<netdev@vger.kernel.org>, <patches@linaro.org>,
<linville@tuxdriver.com>
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B737B@saturn3.aculab.com>
On 8 okt. 2013, at 15:01, "David Laight" <David.Laight@ACULAB.COM> wrote:
>> Hmm, thanks I guess. I'll need to review this in more detail, but I have
>> a question first:
>>
>>> + /* allocate the variable sized aead_request on the stack */
>>> + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
>>> + sizeof(struct aead_request));
>>> + struct aead_request req[1 + l];
>>
>> This looks a bit odd, why round up first and then add one? Why even
>> bother using a struct array rather than some local struct like
>
> Is it even a good idea to be allocating variable sized items
> on the kernel stack?
>
> There has to be enough stack available for the maximum number
> of entries - so there is little point in dynamically sizing it.
Actually, as the size is always the same, it should be feasible to alloc a couple of request structs at init time. would one for rx and one for tx be sufficient? or is this code more reentrant than that?
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 13:16 UTC (permalink / raw)
To: David Laight
Cc: Johannes Berg, linux-wireless, netdev, Patch Tracking,
John Linville
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B737B@saturn3.aculab.com>
On 8 October 2013 15:01, David Laight <David.Laight@aculab.com> wrote:
>> Hmm, thanks I guess. I'll need to review this in more detail, but I have
>> a question first:
>>
>> > + /* allocate the variable sized aead_request on the stack */
>> > + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
>> > + sizeof(struct aead_request));
>> > + struct aead_request req[1 + l];
>>
>> This looks a bit odd, why round up first and then add one? Why even
>> bother using a struct array rather than some local struct like
>
> Is it even a good idea to be allocating variable sized items
> on the kernel stack?
>
> There has to be enough stack available for the maximum number
> of entries - so there is little point in dynamically sizing it.
>
The result of crypto_aead_reqsize() has nothing to do with the input
or output data, it is a property of the particular implementation of
ccm(aes) that is being used. In the generic case (ccm.c),
it always returns the size of this struct
struct crypto_ccm_req_priv_ctx {
u8 odata[16];
u8 idata[16];
u8 auth_tag[16];
u32 ilen;
u32 flags;
struct scatterlist src[2];
struct scatterlist dst[2];
struct ablkcipher_request abreq;
};
while the particular implementation that I am working on for ARM64
always has size 0. Note that this is data that would otherwise be
allocated on the stack, but in the case of aead, which supports an
asynchronous interface (which this code does not use btw), the data is
attached to the end of the aead_request struct instead.
The alternative is to allocate it dynamically using GFP_ATOMIC and
free it at the end of the function, but in this particular case I
don't think that makes much sense tbh
--
Ard.
^ permalink raw reply
* RE: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: David Laight @ 2013-10-08 13:01 UTC (permalink / raw)
To: Johannes Berg, Ard Biesheuvel; +Cc: linux-wireless, netdev, patches, linville
In-Reply-To: <1381233152.13359.10.camel@jlt4.sipsolutions.net>
PiBIbW0sIHRoYW5rcyBJIGd1ZXNzLiBJJ2xsIG5lZWQgdG8gcmV2aWV3IHRoaXMgaW4gbW9yZSBk
ZXRhaWwsIGJ1dCBJIGhhdmUNCj4gYSBxdWVzdGlvbiBmaXJzdDoNCj4gDQo+ID4gKwkvKiBhbGxv
Y2F0ZSB0aGUgdmFyaWFibGUgc2l6ZWQgYWVhZF9yZXF1ZXN0IG9uIHRoZSBzdGFjayAqLw0KPiA+
ICsJaW50IGwgPSBESVZfUk9VTkRfVVAoY3J5cHRvX2FlYWRfcmVxc2l6ZSh0Zm0pLA0KPiA+ICsJ
CQkgICAgIHNpemVvZihzdHJ1Y3QgYWVhZF9yZXF1ZXN0KSk7DQo+ID4gKwlzdHJ1Y3QgYWVhZF9y
ZXF1ZXN0IHJlcVsxICsgbF07DQo+IA0KPiBUaGlzIGxvb2tzIGEgYml0IG9kZCwgd2h5IHJvdW5k
IHVwIGZpcnN0IGFuZCB0aGVuIGFkZCBvbmU/IFdoeSBldmVuDQo+IGJvdGhlciB1c2luZyBhIHN0
cnVjdCBhcnJheSByYXRoZXIgdGhhbiBzb21lIGxvY2FsIHN0cnVjdCBsaWtlDQoNCklzIGl0IGV2
ZW4gYSBnb29kIGlkZWEgdG8gYmUgYWxsb2NhdGluZyB2YXJpYWJsZSBzaXplZCBpdGVtcw0Kb24g
dGhlIGtlcm5lbCBzdGFjaz8NCg0KVGhlcmUgaGFzIHRvIGJlIGVub3VnaCBzdGFjayBhdmFpbGFi
bGUgZm9yIHRoZSBtYXhpbXVtIG51bWJlcg0Kb2YgZW50cmllcyAtIHNvIHRoZXJlIGlzIGxpdHRs
ZSBwb2ludCBpbiBkeW5hbWljYWxseSBzaXppbmcgaXQuDQoNCglEYXZpZA0KDQo=
^ permalink raw reply
* Re: [PATCH/RFT v2 1/4] ath10k: fix add_interface failure handling
From: Kalle Valo @ 2013-10-08 12:54 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380865425-3791-2-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> If something failed along add_interface() setup it
> was possible to leak a vdev id, vdev and peer.
>
> This could end up with leaked FW state or FW crash
> (assuming add_interface() failure wasn't a result of
> a crash).
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Then I apply this patch on top of current ath.git master branch (commit
18fe0b53e76) interface up fails on the managed mode:
$ sudo ip link set wlan1 up
RTNETLINK answers: Invalid argument
Logs don't have anything special (the TX encap error was already
before):
[ 1259.818863] ath10k: MSI-X didn't succeed (1), trying MSI
[ 1259.819298] ath10k_pci 0000:02:00.0: irq 49 for MSI/MSI-X
[ 1259.820055] ath10k: MSI interrupt handling
[ 1260.747877] ath10k: UART prints disabled
[ 1260.828219] ath10k: firmware 10.1.389 booted
[ 1260.837585] ath10k: htt target version 2.1
[ 1260.838498] ath10k: Failed to set TX encap: -22
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: fix RX performance when using AP 10.X FW
From: Kalle Valo @ 2013-10-08 12:24 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1381201236-17035-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Due to oversight AP 10.X support was merged with
> Ethernet RX decap mode.
>
> Only Native Wifi RX decap mode guarantees IP
> header is properly aligned and avoids sk_buff data
> realignment (which is very expensive
> performance-wise) in mac80211.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/2] ath10k: minor fixes
From: Kalle Valo @ 2013-10-08 12:23 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380867200-19714-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> The patchset fixes a compilation warning and a
> memory leak in FW loading code.
>
> Michal Kazior (2):
> ath10k: fix printf format string
> ath10k: fix possible memory leak in new FW loading
Both appplied, thanks for fixing my bugs :)
--
Kalle Valo
^ 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