* Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH
From: Arend Van Spriel @ 2016-10-14 10:13 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless@vger.kernel.org, brcm80211 development
In-Reply-To: <b395146e-1917-e8d7-04e6-5d544f17531e@gmail.com>
Ok. Did you also try the firmware I sent you?
Regards,
Arend
On Fri, Oct 14, 2016 at 8:33 AM, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com>=
wrote:
> On 10/05/2016 11:08 AM, Arend Van Spriel wrote:
>>
>> On 4-10-2016 20:15, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>
>>> On 09/28/2015 11:00 AM, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>>
>>>> I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
>>>> sits in linux-firmware.git.
>>>>
>>>> In OpenWrt we have hostapd with a feature of banning STAs. It works in
>>>> a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
>>>> STA that is banned it sends NL80211_CMD_DEL_STATION.
>>>>
>>>> The problem is that in such case BCM43602 firmware happens to randomly
>>>> send more than 1 BRCMF_E_DEAUTH event. It seems it can send random
>>>> amount between 1 and 3. Looks a bit like some kind of race. It's
>>>> nothing really critical, just makes hostapd log a bit confusing.
>>>>
>>>> Could someone at Broadcom look at firmware source to see if you can
>>>> fix this, please?
>>>
>>>
>>> Hey, I didn't get any reply on this for a year. I just saw similar
>>> problem with
>>> BCM4366. Below you will find a nice log with my extra comments.
>>>
>>> Could take a look at this issue this time, please?
>>
>>
>> Can try.
>
>
> Thank you and sorry for my late reply! I'm back home now ready to provide
> any
> extra details.
>
>
>>> I think it may be another problem related to the A-MPDU thing (bug?) I
>>> reported
>>> in "AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs" e-mai=
l
>>> thread.
>>
>>
>> So what firmware version do you have? A colleague pointed me to firmware
>> fix that may be related so I want to know the target string to build.
>> Firmware version is in the bin file:
>>
>> $ hexdump -C fw.bin | tail -40
>
>
> Well, I am pretty sure I was using the one released by Broadcom. Also my
> only
> device with 4366b1 is DIR-885L. Once I was looking for 4366c0 firmware as
> described in the kernel's bugzilla:
> https://bugzilla.kernel.org/show_bug.cgi?id=3D135321
> but I don't think I replaced them or anything.
>
> Anyway, I repeated my tests paying attention to the firmware file. I'm
> pretty
> sure it's the same one you can find in:
> https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/=
tree/brcm/brcmfmac4366b-pcie.bin
>
> root@lede:/# md5sum /lib/firmware/brcm/brcmfmac4366b-pcie.bin
> 596f13d84e0042035cdb41202cfc385a /lib/firmware/brcm/brcmfmac4366b-pcie.b=
in
>
> root@lede:/# hexdump -C /lib/firmware/brcm/brcmfmac4366b-pcie.bin | tail =
-40
> 000f1670 40 00 03 07 07 07 40 00 03 07 07 07 40 00 03 07
> |@.....@.....@...|
> 000f1680 07 07 40 00 72 61 74 65 73 65 6c 00 73 74 66 00
> |..@.ratesel.stf.|
> 000f1690 63 63 6b 5f 6f 6e 65 63 6f 72 65 5f 74 78 00 74
> |cck_onecore_tx.t|
> 000f16a0 65 6d 70 73 5f 70 65 72 69 6f 64 00 74 78 63 68
> |emps_period.txch|
> 000f16b0 61 69 6e 00 72 78 63 68 61 69 6e 00 4d cc 07 00
> |ain.rxchain.M...|
> 000f16c0 69 44 26 00 71 c9 07 00 91 c6 07 00 2d e9 ff 41
> |iD&.q.......-..A|
> 000f16d0 80 46 4f f4 40 70 0d 46 17 46 1e 46 1f f5 4c ff
> |.FO.@p.F.F.F..L.|
> 000f16e0 04 46 48 b9 28 46 1f f5 4d ff 02 46 23 49 24 48
> |.FH.(F..M..F#I$H|
> 000f16f0 13 f7 24 fb 1e 20 3e e0 00 21 4f f4 40 72 12 f5 |..$..
>>..!O.@r..|
> 000f1700 9d fd 0a 9b 40 46 00 93 04 f1 f8 03 01 93 04 f1
> |....@F..........|
> 000f1710 fc 03 02 93 29 46 3a 46 33 46 e0 f7 5f fa c4 f8
> |....)F:F3F.._...|
> 000f1720 f4 00 28 b9 17 48 15 49 0b 25 13 f7 07 fb 1e e0
> |..(..H.I.%......|
> 000f1730 00 22 40 f6 12 01 00 25 22 f5 26 fb c4 f8 00 01
> |."@....%".&.....|
> 000f1740 40 f6 12 01 d4 f8 f4 00 22 f5 06 fa c4 f8 e8 00
> |@.......".......|
> 000f1750 20 46 51 f7 8d fb 0c 21 00 22 20 46 51 f7 94 fb | FQ....!."
> FQ...|
> 000f1760 20 46 4d f7 69 f8 d4 f8 f4 00 df f7 d1 fe 20 46 | FM.i.......=
..
> F|
> 000f1770 1f f5 16 ff 28 46 04 b0 bd e8 f0 81 88 17 2f 00
> |....(F......../.|
> 000f1780 97 1b 2a 00 e2 f1 29 00 77 6c 63 5f 62 6d 61 63
> |..*...).wlc_bmac|
> 000f1790 5f 70 72 6f 63 65 73 73 5f 75 63 6f 64 65 5f 73
> |_process_ucode_s|
> 000f17a0 72 00 00 00 84 73 3b b4 0a 0a 45 ed 3d 22 90 56
> |r....s;...E.=3D".V|
> 000f17b0 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 a4
> |................|
> 000f17c0 91 7a c4 13 01 bd 32 08 01 00 34 33 36 36 62 31
> |.z....2...4366b1|
> 000f17d0 2d 72 6f 6d 6c 2f 70 63 69 65 2d 61 67 2d 73 70
> |-roml/pcie-ag-sp|
> 000f17e0 6c 69 74 72 78 2d 66 64 61 70 2d 6d 62 73 73 2d
> |litrx-fdap-mbss-|
> 000f17f0 6d 66 70 2d 77 6e 6d 2d 6f 73 65 6e 2d 77 6c 31
> |mfp-wnm-osen-wl1|
> 000f1800 31 6b 2d 77 6c 31 31 75 2d 74 78 62 66 2d 70 6b
> |1k-wl11u-txbf-pk|
> 000f1810 74 63 74 78 2d 61 6d 73 64 75 74 78 2d 61 6d 70
> |tctx-amsdutx-amp|
> 000f1820 64 75 72 65 74 72 79 2d 63 68 6b 64 32 68 64 6d
> |duretry-chkd2hdm|
> 000f1830 61 2d 70 72 6f 70 74 78 73 74 61 74 75 73 2d 31
> |a-proptxstatus-1|
> 000f1840 31 6e 70 72 6f 70 2d 6f 62 73 73 2d 64 62 77 73
> |1nprop-obss-dbws|
> 000f1850 77 2d 72 69 6e 67 65 72 2d 64 6d 61 69 6e 64 65
> |w-ringer-dmainde|
> 000f1860 78 31 36 2d 62 67 64 66 73 20 56 65 72 73 69 6f |x16-bgdfs
> Versio|
> 000f1870 6e 3a 20 31 30 2e 31 30 2e 36 39 2e 32 33 37 20 |n: 10.10.69.=
237
> |
> 000f1880 43 52 43 3a 20 34 62 63 34 38 63 37 62 20 44 61 |CRC: 4bc48c7=
b
> Da|
> 000f1890 74 65 3a 20 46 72 69 20 32 30 31 36 2d 30 31 2d |te: Fri
> 2016-01-|
> 000f18a0 30 38 20 31 32 3a 35 35 3a 32 35 20 50 53 54 20 |08 12:55:25 =
PST
> |
> 000f18b0 55 63 6f 64 65 20 56 65 72 3a 20 31 30 37 33 2e |Ucode Ver:
> 1073.|
> 000f18c0 35 33 31 20 46 57 49 44 3a 20 30 31 2d 63 34 37 |531 FWID:
> 01-c47|
> 000f18d0 61 39 31 61 34 0a 00 0d 01 |a91a4....|
> 000f18d9
>
> And there is a log using that very firmware I verified above.
>
> # I got some timeouts, this time without ampdu_dbg or wlc_ampdu_watchdog
> Fri Oct 14 06:09:07 2016 kern.err kernel: [ 437.579199] brcmfmac:
> brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x pack=
ets
> Fri Oct 14 06:09:08 2016 kern.err kernel: [ 438.529199] brcmfmac:
> brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x pack=
ets
>
> # Firmware sends BRCMF_E_DEAUTH and BRCMF_E_DISASSOC_IND events.
> # My smartphone never receives deauth/disassoc and it believes it's still
> # connected to the AP.
> Fri Oct 14 06:09:12 2016 kern.debug kernel: [ 442.276363] brcmfmac:
> CONSOLE: 027172.113 wl0: Proxy STA 78:d6:f0:9b:ba:bc link is already gone
> !!??
> Fri Oct 14 06:09:12 2016 kern.err kernel: [ 442.276405] brcmfmac:
> brcmf_notify_connect_status_ap: event 5, reason 3
> Fri Oct 14 06:09:12 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba=
:bc
> IEEE 802.11: disassociated
> Fri Oct 14 06:09:12 2016 kern.err kernel: [ 442.276447] brcmfmac:
> brcmf_notify_connect_status_ap: event 5, reason 3
> Fri Oct 14 06:09:12 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba=
:bc
> IEEE 802.11: disassociated
>
> # My smartphone starts sending packets. Firmware reacts by sending
> # BRCMF_E_DEAUTH events to the driver.
> Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.213534] brcmfmac:
> brcmf_notify_connect_status_ap: event 5, reason 7
> Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba=
:bc
> IEEE 802.11: disassociated
> Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.321590] brcmfmac:
> brcmf_notify_connect_status_ap: event 5, reason 7
> Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba=
:bc
> IEEE 802.11: disassociated
> Fri Oct 14 06:10:57 2016 kern.err kernel: [ 547.321918] brcmfmac:
> brcmf_notify_connect_status_ap: event 5, reason 7
> Fri Oct 14 06:10:57 2016 daemon.info hostapd: wlan1-1: STA 78:d6:f0:9b:ba=
:bc
> IEEE 802.11: disassociated
^ permalink raw reply
* [PATCH v2 0/2] ath10k: add VHT160 support
From: Kalle Valo @ 2016-10-14 10:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Hi,
here's v2 of Sebastian's VHT160 patch.
v2:
* cc linux-wireless
* refactor ath10k_peer_assoc_h_phymode()
* fix two rebase issues
* fix checkpatch warnings
---
Kalle Valo (1):
ath10k: refactor ath10k_peer_assoc_h_phymode()
Sebastian Gottschall (1):
ath10k: add VHT160 support
drivers/net/wireless/ath/ath10k/htt_rx.c | 7 +++-
drivers/net/wireless/ath/ath10k/mac.c | 54 +++++++++++++++++++++++++----
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 +
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 9 ++++-
drivers/net/wireless/ath/ath10k/wmi.h | 27 +++++++++++++--
6 files changed, 87 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH v2 2/2] ath10k: add VHT160 support
From: Kalle Valo @ 2016-10-14 10:19 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20161014101710.5300.21550.stgit@potku.adurom.net>
From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
This patch adds full VHT160 support for QCA9984 chipsets Tested on Netgear
R7800. 80+80 is possible, but disabled so far since it seems to contain
glitches like missing vht station flags (this may be firmware or mac80211
related).
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Patchwork-Id: 9335111
[kvalo@qca.qualcomm.com: refactoring and fix few warnings]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 7 +++++-
drivers/net/wireless/ath/ath10k/mac.c | 32 +++++++++++++++++++++++++++--
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 +
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 9 +++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 27 +++++++++++++++++++++++-
6 files changed, 71 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 285b235268d7..fc93d14ad472 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -702,6 +702,10 @@ static void ath10k_htt_rx_h_rates(struct ath10k *ar,
/* 80MHZ */
case 2:
status->vht_flag |= RX_VHT_FLAG_80MHZ;
+ break;
+ case 3:
+ status->vht_flag |= RX_VHT_FLAG_160MHZ;
+ break;
}
status->flag |= RX_FLAG_VHT;
@@ -926,7 +930,7 @@ static void ath10k_process_rx(struct ath10k *ar,
*status = *rx_status;
ath10k_dbg(ar, ATH10K_DBG_DATA,
- "rx skb %pK len %u peer %pM %s %s sn %u %s%s%s%s%s %srate_idx %u vht_nss %u freq %u band %u flag 0x%llx fcs-err %i mic-err %i amsdu-more %i\n",
+ "rx skb %pK len %u peer %pM %s %s sn %u %s%s%s%s%s%s %srate_idx %u vht_nss %u freq %u band %u flag 0x%llx fcs-err %i mic-err %i amsdu-more %i\n",
skb,
skb->len,
ieee80211_get_SA(hdr),
@@ -940,6 +944,7 @@ static void ath10k_process_rx(struct ath10k *ar,
status->flag & RX_FLAG_VHT ? "vht" : "",
status->flag & RX_FLAG_40MHZ ? "40" : "",
status->vht_flag & RX_VHT_FLAG_80MHZ ? "80" : "",
+ status->vht_flag & RX_VHT_FLAG_160MHZ ? "160" : "",
status->flag & RX_FLAG_SHORT_GI ? "sgi " : "",
status->rate_idx,
status->vht_nss,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index cbd0f4c3dad4..a8e7ae4b3f1b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -569,10 +569,14 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
case NL80211_CHAN_WIDTH_80:
phymode = MODE_11AC_VHT80;
break;
+ case NL80211_CHAN_WIDTH_160:
+ phymode = MODE_11AC_VHT160;
+ break;
+ case NL80211_CHAN_WIDTH_80P80:
+ phymode = MODE_11AC_VHT80_80;
+ break;
case NL80211_CHAN_WIDTH_5:
case NL80211_CHAN_WIDTH_10:
- case NL80211_CHAN_WIDTH_80P80:
- case NL80211_CHAN_WIDTH_160:
phymode = MODE_UNKNOWN;
break;
}
@@ -971,6 +975,7 @@ static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
arg.vdev_id = vdev_id;
arg.channel.freq = channel->center_freq;
arg.channel.band_center_freq1 = chandef->center_freq1;
+ arg.channel.band_center_freq2 = chandef->center_freq2;
/* TODO setup this dynamically, what in case we
don't have any vifs? */
@@ -1382,6 +1387,7 @@ static int ath10k_vdev_start_restart(struct ath10k_vif *arvif,
arg.channel.freq = chandef->chan->center_freq;
arg.channel.band_center_freq1 = chandef->center_freq1;
+ arg.channel.band_center_freq2 = chandef->center_freq2;
arg.channel.mode = chan_to_phymode(chandef);
arg.channel.min_power = 0;
@@ -2445,6 +2451,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+ arg->peer_flags |= ar->wmi.peer_flags->bw160;
+
arg->peer_vht_rates.rx_max_rate =
__le16_to_cpu(vht_cap->vht_mcs.rx_highest);
arg->peer_vht_rates.rx_mcs_set =
@@ -2501,6 +2510,18 @@ static bool ath10k_mac_sta_has_ofdm_only(struct ieee80211_sta *sta)
static enum wmi_phy_mode ath10k_mac_get_phymode_vht(struct ath10k *ar,
struct ieee80211_sta *sta)
{
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
+ switch (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) {
+ case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ:
+ return MODE_11AC_VHT160;
+ case IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ:
+ return MODE_11AC_VHT80_80;
+ default:
+ /* not sure if this is a valid case? */
+ return MODE_11AC_VHT160;
+ }
+ }
+
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
return MODE_11AC_VHT80;
@@ -4289,6 +4310,10 @@ static struct ieee80211_sta_vht_cap ath10k_create_vht_cap(struct ath10k *ar)
vht_cap.cap |= val;
}
+ if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
+ !(ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ))
+ vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
+
mcs_map = 0;
for (i = 0; i < 8; i++) {
if ((i < ar->num_rf_chains) && (ar->cfg_tx_chainmask & BIT(i)))
@@ -6945,6 +6970,9 @@ static void ath10k_sta_rc_update(struct ieee80211_hw *hw,
bw = WMI_PEER_CHWIDTH_80MHZ;
break;
case IEEE80211_STA_RX_BW_160:
+ bw = WMI_PEER_CHWIDTH_160MHZ;
+ break;
+ default:
ath10k_warn(ar, "Invalid bandwidth %d in rc update for %pM\n",
sta->bandwidth, sta->addr);
bw = WMI_PEER_CHWIDTH_20MHZ;
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e64f59300a7c..e6d0fe5dcfe4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3560,6 +3560,7 @@ static const struct wmi_peer_flags_map wmi_tlv_peer_flags_map = {
.vht = WMI_TLV_PEER_VHT,
.bw80 = WMI_TLV_PEER_80MHZ,
.pmf = WMI_TLV_PEER_PMF,
+ .bw160 = WMI_TLV_PEER_160MHZ,
};
/************/
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index b8aa6000573c..22cf011e839a 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -543,6 +543,7 @@ enum wmi_tlv_peer_flags {
WMI_TLV_PEER_VHT = 0x02000000,
WMI_TLV_PEER_80MHZ = 0x04000000,
WMI_TLV_PEER_PMF = 0x08000000,
+ WMI_TLV_PEER_160MHZ = 0x20000000,
};
enum wmi_tlv_tag {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 387c4eede388..12b3aff8ffa2 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -28,6 +28,7 @@
#include "wmi-ops.h"
#include "p2p.h"
#include "hw.h"
+#include "hif.h"
#define ATH10K_WMI_BARRIER_ECHO_ID 0xBA991E9
#define ATH10K_WMI_BARRIER_TIMEOUT_HZ (3 * HZ)
@@ -1576,6 +1577,7 @@ static const struct wmi_peer_flags_map wmi_peer_flags_map = {
.bw80 = WMI_PEER_80MHZ,
.vht_2g = WMI_PEER_VHT_2G,
.pmf = WMI_PEER_PMF,
+ .bw160 = WMI_PEER_160MHZ,
};
static const struct wmi_peer_flags_map wmi_10x_peer_flags_map = {
@@ -1593,6 +1595,7 @@ static const struct wmi_peer_flags_map wmi_10x_peer_flags_map = {
.spatial_mux = WMI_10X_PEER_SPATIAL_MUX,
.vht = WMI_10X_PEER_VHT,
.bw80 = WMI_10X_PEER_80MHZ,
+ .bw160 = WMI_10X_PEER_160MHZ,
};
static const struct wmi_peer_flags_map wmi_10_2_peer_flags_map = {
@@ -1612,6 +1615,7 @@ static const struct wmi_peer_flags_map wmi_10_2_peer_flags_map = {
.bw80 = WMI_10_2_PEER_80MHZ,
.vht_2g = WMI_10_2_PEER_VHT_2G,
.pmf = WMI_10_2_PEER_PMF,
+ .bw160 = WMI_10_2_PEER_160MHZ,
};
void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
@@ -1636,7 +1640,10 @@ void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
ch->mhz = __cpu_to_le32(arg->freq);
ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
- ch->band_center_freq2 = 0;
+ if (arg->mode == MODE_11AC_VHT80_80)
+ ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
+ else
+ ch->band_center_freq2 = 0;
ch->min_power = arg->min_power;
ch->max_power = arg->max_power;
ch->reg_power = arg->max_reg_power;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b243c899bef..69d854e04594 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1728,8 +1728,10 @@ enum wmi_phy_mode {
MODE_11AC_VHT20_2G = 11,
MODE_11AC_VHT40_2G = 12,
MODE_11AC_VHT80_2G = 13,
- MODE_UNKNOWN = 14,
- MODE_MAX = 14
+ MODE_11AC_VHT80_80 = 14,
+ MODE_11AC_VHT160 = 15,
+ MODE_UNKNOWN = 16,
+ MODE_MAX = 16
};
static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
@@ -1757,6 +1759,10 @@ static inline const char *ath10k_wmi_phymode_str(enum wmi_phy_mode mode)
return "11ac-vht40";
case MODE_11AC_VHT80:
return "11ac-vht80";
+ case MODE_11AC_VHT160:
+ return "11ac-vht160";
+ case MODE_11AC_VHT80_80:
+ return "11ac-vht80+80";
case MODE_11AC_VHT20_2G:
return "11ac-vht20-2g";
case MODE_11AC_VHT40_2G:
@@ -1811,6 +1817,7 @@ struct wmi_channel {
struct wmi_channel_arg {
u32 freq;
u32 band_center_freq1;
+ u32 band_center_freq2;
bool passive;
bool allow_ibss;
bool allow_ht;
@@ -1875,9 +1882,18 @@ enum wmi_channel_change_cause {
#define WMI_VHT_CAP_MAX_MPDU_LEN_MASK 0x00000003
#define WMI_VHT_CAP_RX_LDPC 0x00000010
#define WMI_VHT_CAP_SGI_80MHZ 0x00000020
+#define WMI_VHT_CAP_SGI_160MHZ 0x00000040
#define WMI_VHT_CAP_TX_STBC 0x00000080
#define WMI_VHT_CAP_RX_STBC_MASK 0x00000300
#define WMI_VHT_CAP_RX_STBC_MASK_SHIFT 8
+#define WMI_VHT_CAP_SU_BFER 0x00000800
+#define WMI_VHT_CAP_SU_BFEE 0x00001000
+#define WMI_VHT_CAP_MAX_CS_ANT_MASK 0x0000E000
+#define WMI_VHT_CAP_MAX_CS_ANT_MASK_SHIFT 13
+#define WMI_VHT_CAP_MAX_SND_DIM_MASK 0x00070000
+#define WMI_VHT_CAP_MAX_SND_DIM_MASK_SHIFT 16
+#define WMI_VHT_CAP_MU_BFER 0x00080000
+#define WMI_VHT_CAP_MU_BFEE 0x00100000
#define WMI_VHT_CAP_MAX_AMPDU_LEN_EXP 0x03800000
#define WMI_VHT_CAP_MAX_AMPDU_LEN_EXP_SHIFT 23
#define WMI_VHT_CAP_RX_FIXED_ANT 0x10000000
@@ -1926,6 +1942,8 @@ enum {
REGDMN_MODE_11AC_VHT40PLUS = 0x40000, /* 5Ghz, VHT40 + channels */
REGDMN_MODE_11AC_VHT40MINUS = 0x80000, /* 5Ghz VHT40 - channels */
REGDMN_MODE_11AC_VHT80 = 0x100000, /* 5Ghz, VHT80 channels */
+ REGDMN_MODE_11AC_VHT160 = 0x200000, /* 5Ghz, VHT160 channels */
+ REGDMN_MODE_11AC_VHT80_80 = 0x400000, /* 5Ghz, VHT80+80 channels */
REGDMN_MODE_ALL = 0xffffffff
};
@@ -5769,6 +5787,7 @@ enum wmi_peer_chwidth {
WMI_PEER_CHWIDTH_20MHZ = 0,
WMI_PEER_CHWIDTH_40MHZ = 1,
WMI_PEER_CHWIDTH_80MHZ = 2,
+ WMI_PEER_CHWIDTH_160MHZ = 3,
};
enum wmi_peer_param {
@@ -5859,6 +5878,7 @@ struct wmi_peer_flags_map {
u32 bw80;
u32 vht_2g;
u32 pmf;
+ u32 bw160;
};
enum wmi_peer_flags {
@@ -5878,6 +5898,7 @@ enum wmi_peer_flags {
WMI_PEER_80MHZ = 0x04000000,
WMI_PEER_VHT_2G = 0x08000000,
WMI_PEER_PMF = 0x10000000,
+ WMI_PEER_160MHZ = 0x20000000
};
enum wmi_10x_peer_flags {
@@ -5895,6 +5916,7 @@ enum wmi_10x_peer_flags {
WMI_10X_PEER_SPATIAL_MUX = 0x00200000,
WMI_10X_PEER_VHT = 0x02000000,
WMI_10X_PEER_80MHZ = 0x04000000,
+ WMI_10X_PEER_160MHZ = 0x20000000
};
enum wmi_10_2_peer_flags {
@@ -5914,6 +5936,7 @@ enum wmi_10_2_peer_flags {
WMI_10_2_PEER_80MHZ = 0x04000000,
WMI_10_2_PEER_VHT_2G = 0x08000000,
WMI_10_2_PEER_PMF = 0x10000000,
+ WMI_10_2_PEER_160MHZ = 0x20000000
};
/*
^ permalink raw reply related
* [PATCH v2 1/2] ath10k: refactor ath10k_peer_assoc_h_phymode()
From: Kalle Valo @ 2016-10-14 10:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20161014101710.5300.21550.stgit@potku.adurom.net>
When adding VHT160 support to ath10k_peer_assoc_h_phymode() the VHT mode
selection code becomes too complex. Simplify it by refactoring the vht part to
a separate function.
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 691b7b58c584..cbd0f4c3dad4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2498,6 +2498,21 @@ static bool ath10k_mac_sta_has_ofdm_only(struct ieee80211_sta *sta)
ATH10K_MAC_FIRST_OFDM_RATE_IDX;
}
+static enum wmi_phy_mode ath10k_mac_get_phymode_vht(struct ath10k *ar,
+ struct ieee80211_sta *sta)
+{
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
+ return MODE_11AC_VHT80;
+
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
+ return MODE_11AC_VHT40;
+
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
+ return MODE_11AC_VHT20;
+
+ return MODE_UNKNOWN;
+}
+
static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
@@ -2544,12 +2559,7 @@ static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
*/
if (sta->vht_cap.vht_supported &&
!ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
- if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
- phymode = MODE_11AC_VHT80;
- else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
- phymode = MODE_11AC_VHT40;
- else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
- phymode = MODE_11AC_VHT20;
+ phymode = ath10k_mac_get_phymode_vht(ar, sta);
} else if (sta->ht_cap.ht_supported &&
!ath10k_peer_assoc_h_ht_masked(ht_mcs_mask)) {
if (sta->bandwidth >= IEEE80211_STA_RX_BW_40)
^ permalink raw reply related
* [PATCH] mwifiex: add power save parameters in hs_cfg cmd
From: Amitkumar Karwar @ 2016-10-14 10:20 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Shengzhen Li, Amitkumar Karwar
From: Shengzhen Li <szli@marvell.com>
This patch adds power save parameters(hs_wake_interval and
hs_inactivity_timeout) in host sleep cfg cmd.
Signed-off-by: Shengzhen Li <szli@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/fw.h | 10 +++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 29 ++++++++++++++++++++------
2 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
index 4b1894b..9b3ccea 100644
--- a/drivers/net/wireless/marvell/mwifiex/fw.h
+++ b/drivers/net/wireless/marvell/mwifiex/fw.h
@@ -181,6 +181,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
#define TLV_TYPE_COALESCE_RULE (PROPRIETARY_TLV_BASE_ID + 154)
#define TLV_TYPE_KEY_PARAM_V2 (PROPRIETARY_TLV_BASE_ID + 156)
#define TLV_TYPE_REPEAT_COUNT (PROPRIETARY_TLV_BASE_ID + 176)
+#define TLV_TYPE_PS_PARAMS_IN_HS (PROPRIETARY_TLV_BASE_ID + 181)
#define TLV_TYPE_MULTI_CHAN_INFO (PROPRIETARY_TLV_BASE_ID + 183)
#define TLV_TYPE_MC_GROUP_INFO (PROPRIETARY_TLV_BASE_ID + 184)
#define TLV_TYPE_TDLS_IDLE_TIMEOUT (PROPRIETARY_TLV_BASE_ID + 194)
@@ -986,6 +987,15 @@ struct mwifiex_ps_param {
__le16 delay_to_ps;
};
+#define HS_DEF_WAKE_INTERVAL 100
+#define HS_DEF_INACTIVITY_TIMEOUT 50
+
+struct mwifiex_ps_param_in_hs {
+ struct mwifiex_ie_types_header header;
+ __le32 hs_wake_int;
+ __le32 hs_inact_timeout;
+};
+
#define BITMAP_AUTO_DS 0x01
#define BITMAP_STA_PS 0x10
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index f2a7a13..b697b61 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -368,7 +368,10 @@ mwifiex_cmd_802_11_hs_cfg(struct mwifiex_private *priv,
{
struct mwifiex_adapter *adapter = priv->adapter;
struct host_cmd_ds_802_11_hs_cfg_enh *hs_cfg = &cmd->params.opt_hs_cfg;
+ u8 *tlv = (u8 *)hs_cfg + sizeof(struct host_cmd_ds_802_11_hs_cfg_enh);
+ struct mwifiex_ps_param_in_hs *psparam_tlv = NULL;
bool hs_activate = false;
+ u16 size;
if (!hscfg_param)
/* New Activate command */
@@ -385,13 +388,14 @@ mwifiex_cmd_802_11_hs_cfg(struct mwifiex_private *priv,
memcpy(((u8 *) hs_cfg) +
sizeof(struct host_cmd_ds_802_11_hs_cfg_enh),
adapter->arp_filter, adapter->arp_filter_size);
- cmd->size = cpu_to_le16
- (adapter->arp_filter_size +
- sizeof(struct host_cmd_ds_802_11_hs_cfg_enh)
- + S_DS_GEN);
+ size = adapter->arp_filter_size +
+ sizeof(struct host_cmd_ds_802_11_hs_cfg_enh)
+ + S_DS_GEN;
+ tlv = (u8 *)hs_cfg
+ + sizeof(struct host_cmd_ds_802_11_hs_cfg_enh)
+ + adapter->arp_filter_size;
} else {
- cmd->size = cpu_to_le16(S_DS_GEN + sizeof(struct
- host_cmd_ds_802_11_hs_cfg_enh));
+ size = S_DS_GEN + sizeof(struct host_cmd_ds_802_11_hs_cfg_enh);
}
if (hs_activate) {
hs_cfg->action = cpu_to_le16(HS_ACTIVATE);
@@ -401,12 +405,25 @@ mwifiex_cmd_802_11_hs_cfg(struct mwifiex_private *priv,
hs_cfg->params.hs_config.conditions = hscfg_param->conditions;
hs_cfg->params.hs_config.gpio = hscfg_param->gpio;
hs_cfg->params.hs_config.gap = hscfg_param->gap;
+
+ size += sizeof(struct mwifiex_ps_param_in_hs);
+ psparam_tlv = (struct mwifiex_ps_param_in_hs *)tlv;
+ psparam_tlv->header.type =
+ cpu_to_le16(TLV_TYPE_PS_PARAMS_IN_HS);
+ psparam_tlv->header.len =
+ cpu_to_le16(sizeof(struct mwifiex_ps_param_in_hs)
+ - sizeof(struct mwifiex_ie_types_header));
+ psparam_tlv->hs_wake_int = cpu_to_le32(HS_DEF_WAKE_INTERVAL);
+ psparam_tlv->hs_inact_timeout =
+ cpu_to_le32(HS_DEF_INACTIVITY_TIMEOUT);
+
mwifiex_dbg(adapter, CMD,
"cmd: HS_CFG_CMD: condition:0x%x gpio:0x%x gap:0x%x\n",
hs_cfg->params.hs_config.conditions,
hs_cfg->params.hs_config.gpio,
hs_cfg->params.hs_config.gap);
}
+ cmd->size = cpu_to_le16(size);
return 0;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] ath10k: add VHT160 support
From: Valo, Kalle @ 2016-10-14 10:26 UTC (permalink / raw)
To: ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20161014101912.5300.66145.stgit@potku.adurom.net>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
>
> This patch adds full VHT160 support for QCA9984 chipsets Tested on Netgea=
r
> R7800. 80+80 is possible, but disabled so far since it seems to contain
> glitches like missing vht station flags (this may be firmware or mac80211
> related).
>
> Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
> Patchwork-Id: 9335111
Oops, the patchwork id is a leftover from my patchwork script. I'll
remove it before I apply the patch.
--=20
Kalle Valo=
^ permalink raw reply
* Re: Qualcomm: Power Save Algorithm in STA+STA mode
From: Gucea Doru @ 2016-10-14 11:10 UTC (permalink / raw)
To: linux-wireless
Cc: Andra Paraschiv, c_sadash, c_saidir, kapgupta, sgoud, c_gowri
In-Reply-To: <CANfLQrbz1x6q+S2OmWah583=pTJ_6vK1BgnwLPSTk_VnFQ6TsA@mail.gmail.com>
On Tue, Sep 20, 2016 at 8:27 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> Hello, everyone
>
> I'm a master student and I currently work on designing an algorithm
> for reducing the power consumption when a mobile device is associated
> to multiple Access Points that operate on the same channel.
>
> I tried to design my algorithm around the prima driver [1] but I
> noticed that the power save feature is fully implemented in the
> firmware (Beacon Mode Power Save). Unfortunately, the firmware is
> closed-source and I can't do any modifications.
>
> Is there any Qualcomm representative reading this mailing list that
> could help me get a possible solution for the above problem?
>
>
> [1] https://source.codeaurora.org/quic/la
>
> Thank you,
> Doru
Is there any Qualcomm-Atheros developer who could help me/redirect to
the right person?
Thanks,
Doru
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Ard Biesheuvel @ 2016-10-14 11:11 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Stephen Rothwell, linux-next@vger.kernel.org,
Sergey Senozhatsky, Network Development, Sergey Senozhatsky,
Herbert Xu, David S. Miller, Linux Wireless List,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <1476439212.31114.37.camel@sipsolutions.net>
On 14 October 2016 at 11:00, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> So why is the performance hit acceptable for ESP but not for WPA? We
>> could easily implement the same thing, i.e.,
>> kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it
>> on the stack
>
> Yeah, maybe we should. It's likely a much bigger allocation, but I
> don't actually know if that affects speed.
>
> In most cases where you want high performance we never hit this anyway
> since we'll have hardware crypto. I know for our (Intel's) devices we
> normally never hit these code paths.
>
> But on the other hand, you also did your changes for a reason, and the
> only reason I can see of that is performance. So you'd be the one with
> most "skin in the game", I guess?
>
Well, what sucks here is that the accelerated driver I implemented for
arm64 does not actually need this, as long as we take aad[] off the
stack. And note that the API was changed since my patch, to add aad[]
to the scatterlist: prior to this change, it used
aead_request_set_assoc() to set the associated data separately.
^ permalink raw reply
* Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH
From: Rafał Miłecki @ 2016-10-14 11:02 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless@vger.kernel.org, brcm80211 development
In-Reply-To: <CAF7Mx6ocYn21OkP7Tv7tMcuP_LLUQa-oPZigKzQWE1S4q9v=VA@mail.gmail.com>
On 14 October 2016 at 12:13, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> Ok. Did you also try the firmware I sent you?
It gets more complex there, I'm still working on this. Will provide
more info later today.
^ permalink raw reply
* [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Ard Biesheuvel @ 2016-10-14 13:09 UTC (permalink / raw)
To: johannes, luto, sergey.senozhatsky.work, netdev, herbert, davem,
linux-wireless, linux-kernel, j
Cc: Ard Biesheuvel
Some CCM implementations (such as the generic CCM wrapper in crypto/)
use scatterlists to map fields of struct aead_req. This means these
data structures cannot live in the vmalloc area, which means that in
the near future, they can no longer live on the stack either.
Given that these data structures have implementation specific context fields,
it really depends on the particular driver whether this issue is likely to
occur or not, and so it seems best to simply move the entire data structure
into the direct mapped kernel heap.
So use kzalloc/kfree to allocate and free the data structures. This pattern
already exists in the IPsec ESP driver, but in the future, we may need to
improve upon this by either moving the request into the SKB, or using a
slab cache to allocate/free the data structures.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
This only addresses one half of the problem. The other problem, i.e., the
fact that the aad[] array lives on the stack of the caller, is handled
adequately imo by the change proposed by Johannes.
net/mac80211/aes_ccm.c | 24 ++++++++++----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7663c28ba353..a0ae8cebbe4e 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -23,13 +23,10 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
size_t mic_len)
{
struct scatterlist sg[3];
+ struct aead_request *aead_req;
- char aead_req_data[sizeof(struct aead_request) +
- crypto_aead_reqsize(tfm)]
- __aligned(__alignof__(struct aead_request));
- struct aead_request *aead_req = (void *) aead_req_data;
-
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = kzalloc(sizeof(struct aead_request) +
+ crypto_aead_reqsize(tfm), GFP_ATOMIC);
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
@@ -41,6 +38,7 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
aead_request_set_ad(aead_req, sg[0].length);
crypto_aead_encrypt(aead_req);
+ kfree(aead_req);
}
int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
@@ -48,15 +46,14 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
size_t mic_len)
{
struct scatterlist sg[3];
- char aead_req_data[sizeof(struct aead_request) +
- crypto_aead_reqsize(tfm)]
- __aligned(__alignof__(struct aead_request));
- struct aead_request *aead_req = (void *) aead_req_data;
+ struct aead_request *aead_req;
+ int err;
if (data_len == 0)
return -EINVAL;
- memset(aead_req, 0, sizeof(aead_req_data));
+ aead_req = kzalloc(sizeof(struct aead_request) +
+ crypto_aead_reqsize(tfm), GFP_ATOMIC);
sg_init_table(sg, 3);
sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad));
@@ -67,7 +64,10 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
- return crypto_aead_decrypt(aead_req);
+ err = crypto_aead_decrypt(aead_req);
+ kfree(aead_req);
+
+ return err;
}
struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Johannes Berg @ 2016-10-14 13:10 UTC (permalink / raw)
To: Ard Biesheuvel, luto, sergey.senozhatsky.work, netdev, herbert,
davem, linux-wireless, linux-kernel, j
In-Reply-To: <1476450540-1760-1-git-send-email-ard.biesheuvel@linaro.org>
> So use kzalloc
Do we really need kzalloc()? We have things on the stack right now, and
don't initialize, so surely we don't really need to zero things?
> This only addresses one half of the problem. The other problem, i.e.,
> the fact that the aad[] array lives on the stack of the caller, is
> handled adequately imo by the change proposed by Johannes.
But if we allocate things anyway, is it worth expending per-CPU buffers
on these?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Johannes Berg @ 2016-10-14 13:11 UTC (permalink / raw)
To: Ard Biesheuvel, luto, sergey.senozhatsky.work, netdev, herbert,
davem, linux-wireless, linux-kernel, j
In-Reply-To: <1476450635.31114.42.camel@sipsolutions.net>
On Fri, 2016-10-14 at 15:10 +0200, Johannes Berg wrote:
> >
> > So use kzalloc
>
> Do we really need kzalloc()? We have things on the stack right now,
> and don't initialize, so surely we don't really need to zero things?
Err, never mind, I'm an idiot - we *do* initialize to 0, of course.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Ard Biesheuvel @ 2016-10-14 13:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Sergey Senozhatsky,
<netdev@vger.kernel.org>, Herbert Xu, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <1476450635.31114.42.camel@sipsolutions.net>
On 14 October 2016 at 14:10, Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> So use kzalloc
>
> Do we really need kzalloc()? We have things on the stack right now, and
> don't initialize, so surely we don't really need to zero things?
>
>> This only addresses one half of the problem. The other problem, i.e.,
>> the fact that the aad[] array lives on the stack of the caller, is
>> handled adequately imo by the change proposed by Johannes.
>
> But if we allocate things anyway, is it worth expending per-CPU buffers
> on these?
>
Ehmm, maybe not. I could spin a v2 that allocates a bigger buffer, and
copies aad[] into it as well
That does not help the other algos though
^ permalink raw reply
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Ard Biesheuvel @ 2016-10-14 13:19 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Sergey Senozhatsky,
<netdev@vger.kernel.org>, Herbert Xu, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <1476450941.31114.45.camel@sipsolutions.net>
On 14 October 2016 at 14:15, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2016-10-14 at 14:13 +0100, Ard Biesheuvel wrote:
>>
>> > But if we allocate things anyway, is it worth expending per-CPU
>> > buffers on these?
>>
>> Ehmm, maybe not. I could spin a v2 that allocates a bigger buffer,
>> and copies aad[] into it as well
>
> Copies in/out, I guess. Also there's B_0/J_0 for CCM/GCM, and the
> 'zero' thing that GMAC has.
>
Is the aad[] actually reused? I would assume it only affects the mac
on encryption, and the verification on decryption but I don't think we
actually need it back from the crypto routines.
>> That does not help the other algos though
>
> What do you mean?
>
Exactly what you said above :-) My patch only touches CCM but as you said,
"""
'Also there's B_0/J_0 for CCM/GCM, and the 'zero' thing that GMAC has.
"""
^ permalink raw reply
* Re: [PATCH] nl80211: add key management offload feature
From: Jouni Malinen @ 2016-10-14 13:38 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Amitkumar Karwar, linux-wireless, hostap, yangzy, Cathy Luo,
Nishant Sarmukadam, lihz
In-Reply-To: <df801822-f23d-e7e3-15c2-1849370fd01f@broadcom.com>
On Tue, Sep 27, 2016 at 01:24:24PM +0200, Arend Van Spriel wrote:
> On 27-9-2016 12:56, Amitkumar Karwar wrote:
> > From: lihz <lihz@marvell.com>
>
> minor thing. Could you use another prefix iso 'nl80211:'. That has
> different expectation for me at least, ie. changes in nl80211 api, but
> this patch is for hostap repo so 'hostap:' or 'wpa_supp:' would be
> better fit here.
Well.. That's for the context of linux-wireless. As far as the actual
commit in hostap.git and the hostap mailing list (now with the correct
address) is concerned, "nl80211:" is the correct prefix to use in the
commit message.
> > diff --git a/src/common/defs.h b/src/common/defs.h
> > @@ -148,7 +148,9 @@ enum wpa_alg {
> > - WPA_ALG_BIP_CMAC_256
> > + WPA_ALG_BIP_CMAC_256,
> > + WPA_ALG_PMK_R0,
> > + WPA_ALG_PMK_R0_NAME,
I guess I could kind of understand WPA_ALG_PMK_R0 as a new "algorithm"
since this is also used to configure keys, but PMK-R0-Name is going
pretty far in that regard. It most certainly is not a key..
> > #define WLAN_CIPHER_SUITE_SMS4 0x00147201
> > +#define WLAN_CIPHER_SUITE_PMK 0x00147202
> > +#define WLAN_CIPHER_SUITE_PMK_R0 0x00147203
> > +#define WLAN_CIPHER_SUITE_PMK_R0_NAME 0x00147204
As noted previously, it is not acceptable to assign new AKMs from
someone else's OUI. Once there is consensus on what values are needed, I
can assign the needed values from the 00:13:74 OUI.
> > diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c
> > @@ -2675,21 +2675,34 @@ static int wpa_driver_nl80211_set_key(const char *ifname, struct i802_bss *bss,
> > -#ifdef CONFIG_DRIVER_NL80211_QCA
> > - if (alg == WPA_ALG_PMK &&
> > - (drv->capa.flags & WPA_DRIVER_FLAGS_KEY_MGMT_OFFLOAD)) {
> > - wpa_printf(MSG_DEBUG, "%s: calling issue_key_mgmt_set_key",
> > - __func__);
> > - ret = issue_key_mgmt_set_key(drv, key, key_len);
> > - return ret;
> > +
> > + if ((alg == WPA_ALG_PMK || alg == WPA_ALG_PMK_R0 ||
> > + alg == WPA_ALG_PMK_R0_NAME) &&
I understand PMK as a new key that is being configured. For FT, I'm not
completely sure about PMK-R0 as a separate algorithm and especially not
about using this interface for setting PMK-R0-Name which is tightly
coupled name with a specific PMK-R0 and not something that one would
configure separately.
> > diff --git a/src/drivers/driver_nl80211_event.c b/src/drivers/driver_nl80211_event.c
> > @@ -2065,18 +2065,6 @@ static void do_process_drv_event(struct i802_bss *bss, int cmd,
> > wpa_printf(MSG_DEBUG, "nl80211: Drv Event %d (%s) received for %s",
> > cmd, nl80211_command_to_string(cmd), bss->ifname);
> >
> > - if (cmd == NL80211_CMD_ROAM &&
> > - (drv->capa.flags & WPA_DRIVER_FLAGS_KEY_MGMT_OFFLOAD)) {
> > - /*
> > - * Device will use roam+auth vendor event to indicate
> > - * roaming, so ignore the regular roam event.
> > - */
> > - wpa_printf(MSG_DEBUG,
> > - "nl80211: Ignore roam event (cmd=%d), device will use vendor event roam+auth",
> > - cmd);
> > - return;
> > - }
It is not going to be acceptable to break the existing mechanism that
uses QCA vendor specific commands/events. In other words, the new
extensions need to be done in a backwards compatible manner that allow
both to work based on driver capabilities.
> > diff --git a/src/rsn_supp/wpa_ft.c b/src/rsn_supp/wpa_ft.c
> > @@ -37,6 +37,10 @@ int wpa_derive_ptk_ft(struct wpa_sm *sm, const unsigned char *src_addr,
> > + wpa_sm_set_key(sm, WPA_ALG_PMK_R0, NULL, 0, 1, NULL,
> > + 0, sm->pmk_r0, PMK_LEN);
> > + wpa_sm_set_key(sm, WPA_ALG_PMK_R0_NAME, NULL, 0, 1, NULL,
> > + 0, sm->pmk_r0_name, WPA_PMK_NAME_LEN);
This looks quite bad. I don't think I can really support two separate
nl80211 commands to set a PMK-R0 and the matching PMK-R0-Name, i.e.,
this should really be a single (atomic) operation.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Johannes Berg @ 2016-10-14 13:15 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andy Lutomirski, Sergey Senozhatsky,
<netdev@vger.kernel.org>, Herbert Xu, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <CAKv+Gu_eS-C84rH_MLYy--ivC0a99wwJvNDLhETfrBkYXW-XpA@mail.gmail.com>
On Fri, 2016-10-14 at 14:13 +0100, Ard Biesheuvel wrote:
>
> > But if we allocate things anyway, is it worth expending per-CPU
> > buffers on these?
>
> Ehmm, maybe not. I could spin a v2 that allocates a bigger buffer,
> and copies aad[] into it as well
Copies in/out, I guess. Also there's B_0/J_0 for CCM/GCM, and the
'zero' thing that GMAC has.
> That does not help the other algos though
What do you mean?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Johannes Berg @ 2016-10-14 13:46 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Andy Lutomirski, Sergey Senozhatsky,
<netdev@vger.kernel.org>, Herbert Xu, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <CAKv+Gu81RYq1aZUQ2Aru3Vev4LGgb1zFwWz8gepE0tQEhQi9Uw@mail.gmail.com>
>
> Is the aad[] actually reused? I would assume it only affects the mac
> on encryption, and the verification on decryption but I don't think
> we actually need it back from the crypto routines.
I don't think it's reused.
> Exactly what you said above :-) My patch only touches CCM but as you
> said,
>
> """
> 'Also there's B_0/J_0 for CCM/GCM, and the 'zero' thing that GMAC
> has.
> """
Ah, but we can/should do the same for the others, no?
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: add key management offload feature
From: Jouni Malinen @ 2016-10-14 13:52 UTC (permalink / raw)
To: Johannes Berg
Cc: Amitkumar Karwar, linux-wireless, hostap, Ilan Peer, yangzy,
Cathy Luo, Nishant Sarmukadam, lihz
In-Reply-To: <1474979775.5141.27.camel@sipsolutions.net>
On Tue, Sep 27, 2016 at 02:36:15PM +0200, Johannes Berg wrote:
> > + * @NL80211_ATTR_AUTHORIZED: flag attribute, if set indicates that the
> > + * connection is authorized.
> > @@ -2267,6 +2270,8 @@ enum nl80211_attrs {
> > + NL80211_ATTR_AUTHORIZED,
>
> This already exists, no?
>
> NL80211_STA_FLAG_AUTHORIZED should be more or less equivalent, if you
> do it per station (or just for the AP in case of managed connection)
It does indeed have a very similar meaning to the proposed
NL80211_ATTR_AUTHORIZED. However, NL80211_STA_FLAG_AUTHORIZED is
something that gets nested in NL80211_ATTR_STA or used with the mask/set
struct in NL80211_ATTR_STA_FLAGS2. I'm not sure either of those would
really be very clean ways to use with a connection/roam event..
> > @@ -3687,6 +3692,9 @@ enum nl80211_key_attributes {
> > + NL80211_KEY_REPLAY_CTR,
> > + NL80211_KEY_KCK,
> > + NL80211_KEY_KEK,
>
> I don't think we should conflate the (P)MK and *TK concepts in nl80211,
> they're both keys, but they're completely separate in terms of expected
> usage.
>
>
> Ilan and I looked at this, considering 4-way-HS offload after 1X
> authentication, and think that the more natural API would be to add all
> the necessary data to the PMKSA cache entry. Thus, a PMKSA cache entry
> for a device that does 4-way-handshake offloading would include the PMK
> (or perhaps MSK?), and for FT it would also including the PMK-R0,
> PMKR0Name (and possibly the MDID, or can it be derived?)
PMKSA caching cases, FT protocol, and 4-way handshake following EAP
might be doable in this manner and that might indeed be the cleanest
approach there. However, there will also be need to cover possibility
for offloading FILS at some point in the future.. For FILS with shared
key, the configuration will actually include ERP keys that are not bound
to any specific Authenticator/AP/BSSID and do not really have a PMKSA
cache entry.. At latest at that point, I'd think we'll end up needing
something else and that something else could be defined already now to
cover all these cases instead of trying to force the current cases to go
through NL80211_CMD_SET_PMKSA.
> However, I'm wondering what exactly the offloads here do. Jouni, could
> you also chime in with the QCA (vendor command) design?
The QCA vendor command/event allows multiple different authentication
cases to be offloaded to the driver (well, firmware) and depending on
the driver/firmware version, there could be a bit different behavior
based on whether the particular exchange was offloaded. In other words,
there is automatic fallback to wpa_supplicant completing the exchange if
the driver does not report that it was completed.
> In particular, with key management offloaded, it's not clear to me what
> exactly the roles of the device and host are here. I'm considering that
> the device would handle the 4-way and 2-way handshakes, but then you
> wouldn't need the KEK/KCK/ReplayCounter in the host, so there wouldn't
> be much point in giving them to it.
> But if the device doesn't do that, what exactly *does* it do?
One of the key uses is to allow the Wi-Fi firmware to complete roaming
(say, 4-way handshake based on existing PMKSA) when the host processor
is not awake (i.e., wpa_supplicant is not running at all). However, this
does not mean that we would necessarily offload all EAPOL-Key
processing. GTK rekeying and the initial 4-way handshake for the first
connection to an ESS might be performed by wpa_supplicant especially in
cases where the host is awake anyway. That's why those PTK-related
values need to be kept in sync between the driver/firmware and host
(wpa_supplicant).
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack
From: Ard Biesheuvel @ 2016-10-14 14:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Andy Lutomirski, Sergey Senozhatsky,
<netdev@vger.kernel.org>, Herbert Xu, David S. Miller,
<linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, Jouni Malinen
In-Reply-To: <1476452792.31114.46.camel@sipsolutions.net>
> On 14 Oct 2016, at 14:46, Johannes Berg <johannes@sipsolutions.net> wrote:=
>=20
>=20
>>=20
>> Is the aad[] actually reused? I would assume it only affects the mac
>> on encryption, and the verification on decryption but I don't think
>> we actually need it back from the crypto routines.
>=20
> I don't think it's reused.
>=20
>> Exactly what you said above :-) My patch only touches CCM but as you
>> said,
>>=20
>> """
>> 'Also there's B_0/J_0 for CCM/GCM, and the 'zero' thing that GMAC
>> has.
>> """
>=20
> Ah, but we can/should do the same for the others, no?
>=20
Yes, but then we end up kmalloc/kfreeing chunks of 16 bytes, which is actual=
ly another problem.
I still think we are not violating the api by putting aead_req on the stack (=
but herbert should confirm). The aad[] issue does violate the api, so it des=
erves a separate fix imo=
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Erik Stromdahl @ 2016-10-14 15:38 UTC (permalink / raw)
To: Valo, Kalle, Steve deRosier; +Cc: linux-wireless
In-Reply-To: <87y41rbleo.fsf@kamboji.qca.qualcomm.com>
On 10/14/2016 06:32 AM, Valo, Kalle wrote:
> Steve deRosier <derosier@gmail.com> writes:
>
>> Hi Eric,
>>
>> On Thu, Oct 13, 2016 at 9:39 AM, Erik Stromdahl
>> <erik.stromdahl@gmail.com> wrote:
>>> This patch series is intended to prepare the ath6kl driver
>>> for newer chipsets that doesn't use the current WMI data
>>> endpoints for data traffic.
>>>
>>> The chipset I have been working with (and used for testing)
>>> is QCA6584. It is SDIO based (at least the variant I have
>>> been using) with 802.11p WAVE DSRC capabilities.
>>>
>>> This chipset is different from the AR600X family in that
>>> it does not use the WMI data services (service id's 0x101
>>> to 0x104 ) for data traffic.
>>> Instead it uses the HTT data service for data and wmi unified
>>> for control messages.
>>> It is also different when it comes to mailbox addresses
>>> and HTC header format as well, but these differences are not
>>> part of this patch series.
>>>
>>
>> I've only taken a quick look and I'll make specific comments to
>> specific patches later, but I've got to ask the question, should these
>> changes go into ath6kl or be a new driver?
>>
>> Just because the number starts with 6000 doesn't mean it's a ath6kl
>> chip. The 10k series chips all start with 9000 for example, but they
>> rate their own driver.
>>
>> You state that all of the underpinnings of the communication with the
>> chip are totally different:
>> * Doesn't use WMI
>> * Different mailboxing
>> * Different HTC layer
>>
>> If all of the commands and all of the communication layers to the chip
>> are totally different, then perhaps it isn't an ath6kl chip. So if
>> it's largely similar, then OK, but seems to me with the changes you're
>> saying above, it's mostly different.
>>
>> I'm saying all that without any knowledge of this chip. My experience
>> is limited to various versions of the 6003 and 6004 chips.
>
> Exactly what I was thinking. When I saw terms like "HTT" and "unified
> WMI" my first thought was that is this actually an ath10k based design?
> The product numbers really don't give any indication what driver
> supports, the division goes something like this:
>
> * ath9k: "non-mobile" 11n chips
> * ath6k: mobile 11n chips
> * ath10k: mobile and "non-mobile" 11ac chips
>
> For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
> only supports PCI bus at the moment, but I'm hoping someone would add
> USB and SDIO support. Patches are very welcome.
>
> I'm starting to suspect that QCA6584 is actually based on the same
> design as QCA6174. If that's the case when we should also think if
> instead we should add SDIO support to ath10k, maybe by taking relevant
> parts from ath6kl?
>
> I'll investigate more what this QCA6584 is, I haven't heard about it
> before.
>
The reason I have patched to ath6kl driver was that it is the
only driver with sdio/mbox support.
I was actually thinking of writing a new driver from scratch, but I
thought that it was less work to modify the existing ath6kl driver.
I just haven't considered the option to add sdio/mbox support to ath10k.
This is definitely something I will have a look at.
I should mention that I have been using the qcacld2.0 driver as
"documentation" of the chipset.
The qcacld driver identifies the chipset as AR6320
>From the qcacld2.0 driver bmi_msg.h:
#define TARGET_TYPE_AR6320 8
Perhaps this can shed some light on what kind of chip this is?
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Erik Stromdahl @ 2016-10-14 15:54 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <87k2dbbczu.fsf@kamboji.qca.qualcomm.com>
On 10/14/2016 09:34 AM, Valo, Kalle wrote:
> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>
>> This patch series is intended to prepare the ath6kl driver
>> for newer chipsets that doesn't use the current WMI data
>> endpoints for data traffic.
>>
>> The chipset I have been working with (and used for testing)
>> is QCA6584. It is SDIO based (at least the variant I have
>> been using) with 802.11p WAVE DSRC capabilities.
>>
>> This chipset is different from the AR600X family in that
>> it does not use the WMI data services (service id's 0x101
>> to 0x104 ) for data traffic.
>> Instead it uses the HTT data service for data and wmi unified
>> for control messages.
>> It is also different when it comes to mailbox addresses
>> and HTC header format as well, but these differences are not
>> part of this patch series.
>
> Do you have more patches implemented, like something already working or
> have just started?
>
I have an implementation with all features I need so far, but the other
patches will require cleanup before I can submit anything.
I have been using the qcacld driver as a basis for the work and some of
the stuff in that driver is not really compliant with the kernel coding
style (to say the least).
I have so far mainly been focused on getting all features up and running
and that has (unfortunately) resulted in some copy-pasting from qcacld.
I will start having a look at ath10k and see how much work it would be
to add sdio support to it...
^ permalink raw reply
* Re: pull-request: wireless-drivers 2016-10-14
From: David Miller @ 2016-10-14 20:08 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87oa2nbdpp.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Fri, 14 Oct 2016 10:18:42 +0300
> first wireless-drivers pull request for 4.9 and this time we have
> unusually many fixes even before -rc1 is released. Most important here
> are the wlcore and rtlwifi commits which fix critical regressions,
> otherwise smaller impact fixes and one new sdio id for ath6kl.
>
> Please let me know if there are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Valo, Kalle @ 2016-10-15 5:24 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: Steve deRosier, linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <656f8674-64b9-0440-f8ae-28177c300b1c@gmail.com>
(Adding ath10k list to CC)
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>> Exactly what I was thinking. When I saw terms like "HTT" and "unified
>> WMI" my first thought was that is this actually an ath10k based design?
>> The product numbers really don't give any indication what driver
>> supports, the division goes something like this:
>>=20
>> * ath9k: "non-mobile" 11n chips
>> * ath6k: mobile 11n chips
>> * ath10k: mobile and "non-mobile" 11ac chips
>>=20
>> For example QCA6174 is an 11ac mobile chip supported by ath10k. ath10k
>> only supports PCI bus at the moment, but I'm hoping someone would add
>> USB and SDIO support. Patches are very welcome.
>>=20
>> I'm starting to suspect that QCA6584 is actually based on the same
>> design as QCA6174. If that's the case when we should also think if
>> instead we should add SDIO support to ath10k, maybe by taking relevant
>> parts from ath6kl?
>>=20
>> I'll investigate more what this QCA6584 is, I haven't heard about it
>> before.
>>=20
>
> The reason I have patched to ath6kl driver was that it is the
> only driver with sdio/mbox support.
>
> I was actually thinking of writing a new driver from scratch, but I
> thought that it was less work to modify the existing ath6kl driver.
Ok.
> I just haven't considered the option to add sdio/mbox support to ath10k.
> This is definitely something I will have a look at.
>
> I should mention that I have been using the qcacld2.0 driver as
> "documentation" of the chipset.
>
> The qcacld driver identifies the chipset as AR6320
>
> From the qcacld2.0 driver bmi_msg.h:
>
> #define TARGET_TYPE_AR6320 8
>
> Perhaps this can shed some light on what kind of chip this is?
I'm pretty sure that this is QCA6174 based design which is already
supported by ath10k. So my suggestion is to first look at adding SDIO
support to ath10k and see if that's feasible. We already have PCI code
split from the core code (ath10k_core.ko and ath10k_pci.ko) just because
I was expecting that we would add SDIO and USB support later. That has
just never happened due to lack of time, hopefully you can fix that now
;)
I haven't studied SDIO support at all yet but hopefully WMI, core.c and
mac.c won't need that much modifications. HTT and HTC most likely need
bigger changes. And then you would need to add sdio.c, similarly like we
have pci.c now. Keep in mind that later we might want to add USB support
also so if there's something which both SDIO and USB need to that would
need to be easily sharable. Actually after adding SDIO I hope USB would
be easier to add.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [RFC 0/5] ath6kl: non WMI data service support
From: Valo, Kalle @ 2016-10-15 5:29 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <ce941451-4d1c-4931-0f26-da52f5334f08@gmail.com>
(Adding ath10k list)
Erik Stromdahl <erik.stromdahl@gmail.com> writes:
> On 10/14/2016 09:34 AM, Valo, Kalle wrote:
>> Erik Stromdahl <erik.stromdahl@gmail.com> writes:
>>=20
>>> This patch series is intended to prepare the ath6kl driver
>>> for newer chipsets that doesn't use the current WMI data
>>> endpoints for data traffic.
>>>
>>> The chipset I have been working with (and used for testing)
>>> is QCA6584. It is SDIO based (at least the variant I have
>>> been using) with 802.11p WAVE DSRC capabilities.
>>>
>>> This chipset is different from the AR600X family in that
>>> it does not use the WMI data services (service id's 0x101
>>> to 0x104 ) for data traffic.
>>> Instead it uses the HTT data service for data and wmi unified
>>> for control messages.
>>> It is also different when it comes to mailbox addresses
>>> and HTC header format as well, but these differences are not
>>> part of this patch series.
>>=20
>> Do you have more patches implemented, like something already working or
>> have just started?
>>=20
>
> I have an implementation with all features I need so far, but the other
> patches will require cleanup before I can submit anything.
>
> I have been using the qcacld driver as a basis for the work and some of
> the stuff in that driver is not really compliant with the kernel coding
> style (to say the least).
>
> I have so far mainly been focused on getting all features up and running
> and that has (unfortunately) resulted in some copy-pasting from
> qcacld.
Can you share the current code you have somewhere so that I could take a
quick look? I don't care how ugly it is, I would just like to understand
what kind of changes are needed.
> I will start having a look at ath10k and see how much work it would be
> to add sdio support to it...
Thanks, let me know how it goes or if I can help somehow. My time is
limited but if nothing else I can give some tips.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] p54: memset(0) whole array
From: Christian Lamparter @ 2016-10-15 6:04 UTC (permalink / raw)
To: Jiri Slaby, linux-kernel; +Cc: Kalle Valo, linux-wireless, netdev
In-Reply-To: <20161014092309.24113-1-jslaby@suse.cz>
On Friday, October 14, 2016 11:23:09 AM CEST Jiri Slaby wrote:
> gcc 7 complains:
> drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
> drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
>
> Fix that by passing the correct size to memset.
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: Christian Lamparter <chunkeey@googlemail.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
> drivers/net/wireless/intersil/p54/fwio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intersil/p54/fwio.c b/drivers/net/wireless/intersil/p54/fwio.c
> index 257a9eadd595..4ac6764f4897 100644
> --- a/drivers/net/wireless/intersil/p54/fwio.c
> +++ b/drivers/net/wireless/intersil/p54/fwio.c
> @@ -488,7 +488,7 @@ int p54_scan(struct p54_common *priv, u16 mode, u16 dwell)
>
> entry += sizeof(__le16);
> chan->pa_points_per_curve = 8;
> - memset(chan->curve_data, 0, sizeof(*chan->curve_data));
> + memset(chan->curve_data, 0, sizeof(chan->curve_data));
> memcpy(chan->curve_data, entry,
> sizeof(struct p54_pa_curve_data_sample) *
> min((u8)8, curve_data->points_per_channel));
>
^ 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