Re: [PATCH 9/9] wil6210: Align Rx buffers on 4*n+2
On Sunday, February 15, 2015 02:02:38 PM Vladimir Kondratiev wrote: > For the normal (non-sniffer) mode of operation, align Rx buffer > on 4*n+2, so IP header (after 14 bytes of Ethernet header) > will start dword aligned. This accelerated IP stack a little bit. > > Signed-off-by: Vladimir Kondratiev > Kalle, please do not apply this patch. I found last minute problem with it - hardware is not always happy. For now, drop it please. I will do more testing and re-submit this patch if everything wends OK. Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: station kickout
On 02/15/2015 05:40 AM, Kalle Valo wrote: (Adding linux-wireless) Ben Greear writes: In AP mode, it seems that 3.17-ish kernels (at least) always set station kickout to hard-coded value of 50. Is this something that should be configurable? Maybe a module parameter if nothing else? Or should we add this to nl80211/cfg80211/mac80211? I would guess other drivers also have similar functionality. I guess that is up to Johannes. Do we really gain anything useful by letting firmware take care of this? Might be best to just disable the firmware option entirely and let the rest of the mac80211 stack take care of detecting loss of connectivity? Thanks, Ben -- Ben Greear 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8192cu beacon fix unreliable
On 02/13/2015 04:48 AM, Mike Turner wrote: When using hostapd and an rtl8192cu Wireless USB adaptor the beacon doesn't start sometimes. This was tested with the kernel/git/davem/net-next.git repository and 3423eb92315865d76cb8d488513bfef6ab9251d0 This behaviour is apparently random. If the beacon starts OK then it continues. If a beacon isn't generated then it never starts. Repeating cycles of hostapd stop/start may or may not generate a beacon. There are no specific error messages displayed either on console or in syslog. I have repeated hostapd stop/start a number of consecutive times and received a beacon each time, however I have also done this a number of times and never generated a beacon. We have succesfully used the pvaret-rtl8192cu driver which is based on the vendor driver and used that in conjunction with the modified hostapd code that requires use of the rtl871xdrv driver interface and as far as we have seen it always generates a beacon. Platform is a custom designed Atmel-ARM CPU (AT91SAM9G25) with a D-Link DWA-121. Is send_beacon_frame() being called even when the beacon fails to start? Adding a pr_info() at the start of the routine should answer that question. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] rtl8192cu: Fix beacon support in AP mode
On 02/18/2015 01:51 PM, Jon Hunter wrote:
When using the rtl8192cu in AP mode a few devices (an android phone,
iphone and ipad) were unable to associate, where as the laptops I tried
could. Using wireshark to sniff the wlan traffic, it appears that the
rtl8192cu is not beaconing, however, it is responding to broadcast
probe requests and so devices are able to detect the AP.
Searching the archives the same issue was reported for this WLAN device
and a fix to send an initial beacon frame was proposed [1]. This was
rejected as it was modifying the rtlwifi core. This change does the
same but from within the rtl8192cu driver and appears to fix the problem.
Please note that although this does fix the problem, I don't know if this
is the best way or correct way to fix the problem, hence the request for
comment.
[1] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/96770
Signed-off-by: Jon Hunter
Cc: Larry Finger
Cc: Chaoming Li
Cc: coe...@gmail.com
---
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
index fe4b699..4fbca80 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1520,6 +1520,22 @@ void rtl92cu_set_beacon_related_registers(struct
ieee80211_hw *hw)
_beacon_function_enable(hw, true, true);
}
+static void _beacon_send_frame(struct ieee80211_hw *hw)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
+ struct ieee80211_sta *sta;
+ struct rtl_tcb_desc tcb_desc;
+ struct sk_buff *skb;
+ memset(&tcb_desc, 0, sizeof(struct rtl_tcb_desc));
+
+ skb = ieee80211_beacon_get(hw, mac->vif);
+ sta = rtl_find_sta(hw, mac->bssid);
+
+ if (!rtlpriv->intf_ops->waitq_insert(hw, sta, skb))
+ rtlpriv->intf_ops->adapter_tx(hw, sta, skb, &tcb_desc);
+}
+
void rtl92cu_set_beacon_interval(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -1529,6 +1545,9 @@ void rtl92cu_set_beacon_interval(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG, "beacon_interval:%d\n",
bcn_interval);
rtl_write_word(rtlpriv, REG_BCN_INTERVAL, bcn_interval);
+
+/* Send initial beacon frame to start beaconing */
+ _beacon_send_frame(hw);
}
void rtl92cu_update_interrupt_mask(struct ieee80211_hw *hw,
In the current mainline merge between 3.19 and 3.20-rc1, there is code that
implements the initial beacon start in the core. The main commit is
33511b157bbc. A second commit, which fixes a problem in mesh beacons, is found
in 0b70dc273c13. These were much less intrusive than the one that was rejected,
thus they were accepted into the core. I just tested creating an AP using
NetworkManager and I was able to connect to a Kindle Fire HD, which is an
Android device.
Do these patches not fix the problem for you? There is a report that the beacon
startup is unreliable. Perhaps it may be necessary to change the static
send_beacon_frame() in the core into rtl_send_beacon_frame(), make it be
exported, and call it from rtl92cu_set_beacon_interval().
Larry
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ath10k: Increase AST table SKID length limit
Have you tried testing this with 30+ stations
associated and streaming data, and with other traffic on
nearby channels (say, channel 1 and 6)?
We see bad performance drop-off when we set number-of-peers above
100 (with CT firmware). My kernel will set AST skid limit to number-of-peers +
number-of-vdevs.
Performance is best at 32 peers or less (so skid is about 40).
I am wondering if the root cause is firmware/hardware walking the full
skid-length for pkts
from un-associated peers on same (or neighbouring) channels, or maybe unlucky
hash distribution
in existing peers?
Thanks,
Ben
On 02/13/2015 07:36 AM, SenthilKumar Jegadeesan wrote:
> The current SKID length configuration causes firmware
> to reject peer creation for not able to allocate
> AST entries for peers. This issue is observed when
> least significant 3 bytes are used ramdomly to create
> client MAC addresses.
>
> AST table SKID length configuration is increased to
> maximum value to fix this issue.
>
> Signed-off-by: SenthilKumar Jegadeesan
> ---
> drivers/net/wireless/ath/ath10k/hw.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/hw.h
> b/drivers/net/wireless/ath/ath10k/hw.h
> index 460771f..7f04645 100644
> --- a/drivers/net/wireless/ath/ath10k/hw.h
> +++ b/drivers/net/wireless/ath/ath10k/hw.h
> @@ -223,7 +223,7 @@ struct ath10k_pktlog_hdr {
> #define TARGET_10X_NUM_WDS_ENTRIES 32
> #define TARGET_10X_DMA_BURST_SIZE0
> #define TARGET_10X_MAC_AGGR_DELIM0
> -#define TARGET_10X_AST_SKID_LIMIT16
> +#define TARGET_10X_AST_SKID_LIMIT128
> #define TARGET_10X_NUM_STATIONS 128
> #define TARGET_10X_NUM_PEERS ((TARGET_10X_NUM_STATIONS) + \
>(TARGET_10X_NUM_VDEVS))
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Ben Greear
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ssb: Silence warning for unknown backplane revision
When using a BCM4318 in a PCMCIA format, I get a startup message that the device uses backplane revision 0xF00. Next a WARNING is logged. Despite the message, the device works fine, This patch silences the warning. Cc: Rafał Miłecki Signed-off-by: Larry Finger --- drivers/ssb/main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c index 1e180c4..a48a743 100644 --- a/drivers/ssb/main.c +++ b/drivers/ssb/main.c @@ -1135,6 +1135,8 @@ static u32 ssb_tmslow_reject_bitmask(struct ssb_device *dev) case SSB_IDLOW_SSBREV_25: /* TODO - find the proper REJECT bit */ case SSB_IDLOW_SSBREV_27: /* same here */ return SSB_TMSLOW_REJECT; /* this is a guess */ + case SSB_IDLOW_SSBREV: + break; default: WARN(1, KERN_INFO "ssb: Backplane Revision 0x%.8X\n", rev); } -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] rtl8192cu: Fix beacon support in AP mode
When using the rtl8192cu in AP mode a few devices (an android phone,
iphone and ipad) were unable to associate, where as the laptops I tried
could. Using wireshark to sniff the wlan traffic, it appears that the
rtl8192cu is not beaconing, however, it is responding to broadcast
probe requests and so devices are able to detect the AP.
Searching the archives the same issue was reported for this WLAN device
and a fix to send an initial beacon frame was proposed [1]. This was
rejected as it was modifying the rtlwifi core. This change does the
same but from within the rtl8192cu driver and appears to fix the problem.
Please note that although this does fix the problem, I don't know if this
is the best way or correct way to fix the problem, hence the request for
comment.
[1] http://permalink.gmane.org/gmane.linux.kernel.wireless.general/96770
Signed-off-by: Jon Hunter
Cc: Larry Finger
Cc: Chaoming Li
Cc: coe...@gmail.com
---
drivers/net/wireless/rtlwifi/rtl8192cu/hw.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
index fe4b699..4fbca80 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.c
@@ -1520,6 +1520,22 @@ void rtl92cu_set_beacon_related_registers(struct
ieee80211_hw *hw)
_beacon_function_enable(hw, true, true);
}
+static void _beacon_send_frame(struct ieee80211_hw *hw)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+ struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
+ struct ieee80211_sta *sta;
+ struct rtl_tcb_desc tcb_desc;
+ struct sk_buff *skb;
+ memset(&tcb_desc, 0, sizeof(struct rtl_tcb_desc));
+
+ skb = ieee80211_beacon_get(hw, mac->vif);
+ sta = rtl_find_sta(hw, mac->bssid);
+
+ if (!rtlpriv->intf_ops->waitq_insert(hw, sta, skb))
+ rtlpriv->intf_ops->adapter_tx(hw, sta, skb, &tcb_desc);
+}
+
void rtl92cu_set_beacon_interval(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -1529,6 +1545,9 @@ void rtl92cu_set_beacon_interval(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_BEACON, DBG_DMESG, "beacon_interval:%d\n",
bcn_interval);
rtl_write_word(rtlpriv, REG_BCN_INTERVAL, bcn_interval);
+
+/* Send initial beacon frame to start beaconing */
+ _beacon_send_frame(hw);
}
void rtl92cu_update_interrupt_mask(struct ieee80211_hw *hw,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ath10k number-of-peers exceeded (hacked 3.17, CT firmware)
One of the users of CT firmware (and my 3.17 kernel backported to their 3.14) reported this. This system is also having bad WMI mgt timeout issues, and firmware crashed before these logs started (due to WMI tx hang), so possibly that is the root cause of the peer issues. The user believes he has only a few stations connected to this AP. There may be additional patches to the driver/kernel as well..some of this looks a bit strange to me. I am curious if there are known bugs in the 3.17 era with peer counter mis-management? Feb 18 09:31:00 wlan1: AP-STA-CONNECTED 00:1f:3b:11:b1:25 Feb 18 09:31:00 hostapd: wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: associated (aid 8) Feb 18 09:31:00 kernel: [84594.723772] ath10k_pci :07:00.0: state: 1 number of peers exceeded: peers number 64 (max peers 64) Feb 18 09:31:00 wlan1: NEW-STA-CONNECTED 00:1f:3b:11:b1:25 Feb 18 09:31:00 wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: Could not add STA to kernel driver Feb 18 09:31:00 wlan1: AP-STA-DISCONNECTED 00:1f:3b:11:b1:25 Feb 18 09:31:00 hostapd: wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: Could not add STA to kernel driver Feb 18 09:31:00 wlan1: AUTH-RECEIVED 00:1f:3b:11:b1:25|04:f0:21:0f:3d:57|-41|| Feb 18 09:31:00 wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: authenticated Feb 18 09:31:00 hostapd: wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: authenticated Feb 18 09:31:00 wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: associated (aid 8) Feb 18 09:31:00 wlan1: AP-STA-CONNECTED 00:1f:3b:11:b1:25 Feb 18 09:31:00 hostapd: wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: associated (aid 8) Feb 18 09:31:00 kernel: [84594.776796] ath10k_pci :07:00.0: state: 1 number of peers exceeded: peers number 64 (max peers 64) Feb 18 09:31:00 wlan1: NEW-STA-CONNECTED 00:1f:3b:11:b1:25 Feb 18 09:31:00 wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: Could not add STA to kernel driver Feb 18 09:31:00 hostapd: wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: Could not add STA to kernel driver Feb 18 09:31:00 wlan1: AP-STA-DISCONNECTED 00:1f:3b:11:b1:25 Feb 18 09:31:00 wlan1: AUTH-RECEIVED 00:1f:3b:11:b1:25|04:f0:21:0f:3d:57|-39|| Feb 18 09:31:00 wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: authenticated Feb 18 09:31:00 hostapd: wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: authenticated Feb 18 09:31:00 wlan1: AUTH-RECEIVED 00:21:6a:5f:3f:c2|04:f0:21:0f:3d:57|-34|| Feb 18 09:31:00 wlan1: STA 00:21:6a:5f:3f:c2 IEEE 802.11: authenticated Feb 18 09:31:00 hostapd: wlan1: STA 00:21:6a:5f:3f:c2 IEEE 802.11: authenticated Feb 18 09:31:00 wlan1: STA 00:1f:3b:11:b1:25 IEEE 802.11: associated (aid 8) Feb 18 09:31:00 wlan1: AP-STA-CONNECTED 00:1f:3b:11:b1:25 Thanks, Ben -- Ben Greear 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -stable] ath6kl: fix struct hif_scatter_req list handling
From: Kalle Valo commit 31b9cc9a873dcab161999622314f98a75d838975 upstream. Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf command: iperf -c $TARGET_IP -i 5 -t 50 -w 1M The crash was: Unable to handle kernel paging request at virtual address 1a48 pgd = 80004000 [1a48] *pgd= Internal error: Oops: 805 [#1] SMP ARM Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core] CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1 Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio] task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000 PC is at v7_dma_clean_range+0x20/0x38 LR is at dma_cache_maint_page+0x50/0x54 pc : [<8001a6f8>]lr : [<800170fc>]psr: 2093 sp : dc9afcf8 ip : 8001a748 fp : 0004 r10: r9 : 0001 r8 : r7 : 0001 r6 : r5 : 80cb7000 r4 : 03f9a480 r3 : 001f r2 : 0020 r1 : 1a48 r0 : 1a48 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 6cc5004a DAC: 0015 Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238) Stack: (0xdc9afcf8 to 0xdc9b) fce0: 80c9b29c fd00: 80017134 8001a748 dc302ac0 dc454a00 80c12ed8 fd20: dc115410 80017238 dc454a10 0001 80017588 0001 fd40: dc302ac0 dc9afe38 dc9afe68 0004 80c12ed8 dc454a00 fd60: 0004 80436f88 0600 000c 80c113c4 fd80: 80c9b29c 0001 0004 dc115470 6013 dc302ac0 dc46e000 dc302800 fda0: dc9afe10 dc302b78 6013 dc302ac0 dc46e000 0035 dc46e5b0 80438c90 fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 0005 dc9afe10 fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00 fe00: 01b5 7f619d64 dcc7c830 dc9afe38 dc9afe68 fe20: dc9afe28 dc9afe28 80424d80 0035 9cac0034 fe40: 01b5 fe60: dc9afe68 dc9afe10 3b9aca00 0080 0034 0100 fe80: dc9afe10 0004 dc454a00 dc46e010 dc46e96c fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 0600 80c0e770 fec0: dc15a900 dcc7c838 dc46e954 8042d434 dcc44680 dc46e954 dc004400 fee0: dc454500 dc9ae038 dc004400 8003c450 dcc44680 dc004414 ff00: dc46e954 dc454500 0001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030 ff20: 0001 dc9ae000 dc004400 8003d158 8003d020 80c53941 ff40: dc9aff64 dcb71ea0 dcc44680 8003d020 ff60: 80042480 00f8 dcc44680 ff80: dc9aff80 dc9aff80 dc9aff90 dc9aff90 dc9affac dcb71ea0 ffa0: 800423cc 8000e018 ffc0: ffe0: 0013 [<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] (dma_cache_maint_page+0x50/0x54) [<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] (arm_dma_map_page+0x64/0x68) [<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] (arm_dma_map_sg+0x7c/0xf4) [<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] (sdhci_send_command+0x894/0xe00) [<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] (sdhci_request+0xc0/0x1ec) [<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] (mmc_start_request+0xb8/0xd4) [<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] (__mmc_start_req+0x60/0x84) [<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] (mmc_wait_for_req+0x10/0x20) [<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from [<8003c450>] (process_one_work+0x10c/0x370) [<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] (worker_thread+0x138/0x3fc) [<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] (kthread+0xb4/0xb8) [<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c) Code: e1a02312 e2423001 e1c3 f57ff04f (ee070f3a) ---[ end trace 0c038f0b8e0b67a3 ]--- Kernel panic - not syncing: Fatal exception Jason's analysis: "The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead, it only run one round loop. This may be caused by that the GCC 4.8.1 thought that the scat_list only have one item and then no need to do full iteration, but this is simply wrong by
[PATCH 1/2] ath10k: fix broken traffic for 802.1x in client mode
When running 802.1x WEP keys must be installed
without pairwise-groupwise swap (which is
necessary for static WEP).
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/mac.c | 122 ++
1 file changed, 93 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 0f39af7..733c79d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -37,7 +37,7 @@
static int ath10k_send_key(struct ath10k_vif *arvif,
struct ieee80211_key_conf *key,
enum set_key_cmd cmd,
- const u8 *macaddr, bool def_idx)
+ const u8 *macaddr, u32 flags)
{
struct ath10k *ar = arvif->ar;
struct wmi_vdev_install_key_arg arg = {
@@ -45,16 +45,12 @@ static int ath10k_send_key(struct ath10k_vif *arvif,
.key_idx = key->keyidx,
.key_len = key->keylen,
.key_data = key->key,
+ .key_flags = flags,
.macaddr = macaddr,
};
lockdep_assert_held(&arvif->ar->conf_mutex);
- if (key->flags & IEEE80211_KEY_FLAG_PAIRWISE)
- arg.key_flags = WMI_KEY_PAIRWISE;
- else
- arg.key_flags = WMI_KEY_GROUP;
-
switch (key->cipher) {
case WLAN_CIPHER_SUITE_CCMP:
arg.key_cipher = WMI_CIPHER_AES_CCM;
@@ -68,13 +64,6 @@ static int ath10k_send_key(struct ath10k_vif *arvif,
case WLAN_CIPHER_SUITE_WEP40:
case WLAN_CIPHER_SUITE_WEP104:
arg.key_cipher = WMI_CIPHER_WEP;
- /* AP/IBSS mode requires self-key to be groupwise
-* Otherwise pairwise key must be set */
- if (memcmp(macaddr, arvif->vif->addr, ETH_ALEN))
- arg.key_flags = WMI_KEY_PAIRWISE;
-
- if (def_idx)
- arg.key_flags |= WMI_KEY_TX_USAGE;
break;
case WLAN_CIPHER_SUITE_AES_CMAC:
/* this one needs to be done in software */
@@ -95,7 +84,7 @@ static int ath10k_send_key(struct ath10k_vif *arvif,
static int ath10k_install_key(struct ath10k_vif *arvif,
struct ieee80211_key_conf *key,
enum set_key_cmd cmd,
- const u8 *macaddr, bool def_idx)
+ const u8 *macaddr, u32 flags)
{
struct ath10k *ar = arvif->ar;
int ret;
@@ -104,7 +93,7 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
reinit_completion(&ar->install_key_done);
- ret = ath10k_send_key(arvif, key, cmd, macaddr, def_idx);
+ ret = ath10k_send_key(arvif, key, cmd, macaddr, flags);
if (ret)
return ret;
@@ -122,7 +111,7 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif
*arvif,
struct ath10k_peer *peer;
int ret;
int i;
- bool def_idx;
+ u32 flags;
lockdep_assert_held(&ar->conf_mutex);
@@ -136,14 +125,16 @@ static int ath10k_install_peer_wep_keys(struct ath10k_vif
*arvif,
for (i = 0; i < ARRAY_SIZE(arvif->wep_keys); i++) {
if (arvif->wep_keys[i] == NULL)
continue;
+
+ flags = 0;
+ flags |= WMI_KEY_PAIRWISE;
+
/* set TX_USAGE flag for default key id */
if (arvif->def_wep_key_idx == i)
- def_idx = true;
- else
- def_idx = false;
+ flags |= WMI_KEY_TX_USAGE;
ret = ath10k_install_key(arvif, arvif->wep_keys[i], SET_KEY,
-addr, def_idx);
+addr, flags);
if (ret)
return ret;
@@ -163,6 +154,7 @@ static int ath10k_clear_peer_keys(struct ath10k_vif *arvif,
int first_errno = 0;
int ret;
int i;
+ u32 flags = 0;
lockdep_assert_held(&ar->conf_mutex);
@@ -179,7 +171,7 @@ static int ath10k_clear_peer_keys(struct ath10k_vif *arvif,
/* key flags are not required to delete the key */
ret = ath10k_install_key(arvif, peer->keys[i],
-DISABLE_KEY, addr, false);
+DISABLE_KEY, addr, flags);
if (ret && first_errno == 0)
first_errno = ret;
@@ -229,6 +221,7 @@ static int ath10k_clear_vdev_key(struct ath10k_vif *arvif,
int first_errno = 0;
int ret;
int i;
+ u32 flags = 0;
lockdep_assert_held(&ar->conf_mutex);
@@ -254,7 +247,7 @@ static int ath10k_clear_vdev_key(struct ath10k_vif *arvif,
if (i == ARRAY_SIZE(peer->keys))
break;
/* key fl
[PATCH 2/2] ath10k: fix broken traffic for static WEP in IBSS
When WEP keys are uploaded it's possible that
there are stations associated already (e.g. when
merging) without any keys. Static WEP needs an
explicit per-peer key upload.
Make sure to re-upload wep keys if necessary.
Signed-off-by: Michal Kazior
---
drivers/net/wireless/ath/ath10k/mac.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 733c79d..e7e7d92 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -297,6 +297,39 @@ static int ath10k_mac_vif_sta_fix_wep_key(struct
ath10k_vif *arvif)
return 0;
}
+static int ath10k_mac_vif_update_wep_key(struct ath10k_vif *arvif,
+struct ieee80211_key_conf *key)
+{
+ struct ath10k *ar = arvif->ar;
+ struct ath10k_peer *peer;
+ int ret;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ list_for_each_entry(peer, &ar->peers, list) {
+ if (!memcmp(peer->addr, arvif->vif->addr, ETH_ALEN))
+ continue;
+
+ if (!memcmp(peer->addr, arvif->bssid, ETH_ALEN))
+ continue;
+
+ if (peer->keys[key->keyidx] == key)
+ continue;
+
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vif vdev %i update key %i
needs update\n",
+ arvif->vdev_id, key->keyidx);
+
+ ret = ath10k_install_peer_wep_keys(arvif, peer->addr);
+ if (ret) {
+ ath10k_warn(ar, "failed to update wep keys on vdev %i
for peer %pM: %d\n",
+ arvif->vdev_id, peer->addr, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
/*/
/* General utilities */
/*/
@@ -3862,6 +3895,14 @@ static int ath10k_set_key(struct ieee80211_hw *hw, enum
set_key_cmd cmd,
if (cmd == DISABLE_KEY)
ath10k_clear_vdev_key(arvif, key);
+ /* When WEP keys are uploaded it's possible that there are
+* stations associated already (e.g. when merging) without any
+* keys. Static WEP needs an explicit per-peer key upload.
+*/
+ if (vif->type == NL80211_IFTYPE_ADHOC &&
+ cmd == SET_KEY)
+ ath10k_mac_vif_update_wep_key(arvif, key);
+
/* 802.1x never sets the def_wep_key_idx so each set_key()
* call changes default tx key.
*
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: update MODULE_FIRMWARE definitions for QCA6174
This has been missed while adding the QCA6174 support.
As in the last time, without advertising the firmware files
as needed (or optional) for ath10k, these won't be built into
ram disk for instance.
Signed-off-by: Bartosz Markowski
---
drivers/net/wireless/ath/ath10k/pci.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 631b026a487b..a238a141b22a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2770,7 +2770,18 @@ module_exit(ath10k_pci_exit);
MODULE_AUTHOR("Qualcomm Atheros");
MODULE_DESCRIPTION("Driver support for Atheros QCA988X PCIe devices");
MODULE_LICENSE("Dual BSD/GPL");
+
+/* QCA988x 2.0 firmware files */
MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" QCA988X_HW_2_0_FW_FILE);
MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" ATH10K_FW_API2_FILE);
MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" ATH10K_FW_API3_FILE);
+MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" ATH10K_FW_API4_FILE);
MODULE_FIRMWARE(QCA988X_HW_2_0_FW_DIR "/" QCA988X_HW_2_0_BOARD_DATA_FILE);
+
+/* QCA6174 2.1 firmware files */
+MODULE_FIRMWARE(QCA6174_HW_2_1_FW_DIR "/" ATH10K_FW_API4_FILE);
+MODULE_FIRMWARE(QCA6174_HW_2_1_FW_DIR "/" QCA6174_HW_2_1_BOARD_DATA_FILE);
+
+/* QCA6174 3.1 firmware files */
+MODULE_FIRMWARE(QCA6174_HW_3_0_FW_DIR "/" ATH10K_FW_API4_FILE);
+MODULE_FIRMWARE(QCA6174_HW_3_0_FW_DIR "/" QCA6174_HW_3_0_BOARD_DATA_FILE);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] wlcore: add basic device-tree support
On Tue, Feb 17, 2015 at 5:45 PM, Mark Rutland wrote:
> On Tue, Feb 17, 2015 at 03:39:03PM +, Eliad Peller wrote:
>> On Mon, Feb 16, 2015 at 12:06 PM, Arnd Bergmann wrote:
>> > On Sunday 15 February 2015 13:09:10 Eliad Peller wrote:
>> > s
>> >> +
>> >> +This node provides properties for controlling the wilink wireless
>> >> device. The
>> >> +node is expected to be specified as a child node to the SDIO controller
>> >> that
>> >> +connects the device to the system.
>> >> +
>> >> +Required properties:
>> >> +
>> >> + - compatible : Should be "ti,wlcore".
>> >
>> > I think you should use the specific model number here. If I understand
>> > correctly, wlcore is the name of the driver that is used for multiple
>> > device implementation.
>> >
>> right, wlcore is the common driver part of wl12xx and wl18xx device drivers.
>> these DT properties are common for both.
>> can't we use a common binding as well in this case?
>
> Just have a string for each; the driver can easily match them all and
> handle them identically for now until we decide/realise we need to
> handle them differently later.
>
> Regardless, the compatible string should match some real part number
> and/or standard rather than the Linux driver name.
>
ok, makes sense.
>> >> +&mmc3 {
>> >> + status = "okay";
>> >> + vmmc-supply = <&wlan_en_reg>;
>> >> + bus-width = <4>;
>> >> + cap-power-off-card;
>> >> + keep-power-in-suspend;
>> >> +
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> + wlcore: wlcore@0 {
>> >> + compatible = "ti,wlcore";
>> >> + reg = <2>;
>> >> + interrupt-parent = <&gpio0>;
>> >> + interrupts = <19 IRQ_TYPE_NONE>;
>> >> + };
>> >> +};
>> >
>> > It could make sense to specify a few extra properties here:
>> >
>> > - The platform data lists two clocks. How about adding them
>> > here as optional clocks so we don't need to change the binding
>> > again.
>> >
>> There were some very long threads previously regarding the correct way
>> to describe these clocks.
>> I prefer starting a working basic implementation and add the
>> controversial parts later on, as needed.
>
> This could be problematic. Elsewhere we've later added properties that
> should have been mandatory from the start but were masked by some
> platform data somewhere. It would be very good to avoid that.
>
that's a good argument.
in this case, i'll start with submitting a binding only for wl18xx,
which doesn't need the clock bindings (they are needed only for
wl12xx).
> What is problematic about describing the clock inputs to this block? Is
> the problem specific to this block or to the specific clock
> controller(s) it happens to be wired to?
i'm referring to patches like this one:
http://thread.gmane.org/gmane.linux.kernel/1520752
Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
