* [PATCH v2 2/4] ath10k: Fix the wrong updation of BW in tx_stats debugfs entry
From: Surabhi Vishnoi @ 2019-02-26 9:27 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
In-Reply-To: <1551173278-20926-1-git-send-email-svishnoi@codeaurora.org>
Currently, the bandwidth is updated wrongly in BW table in tx_stats
debugfs per sta as there is difference in number of bandwidth type
in mac80211 and driver stats table. This leads to bandwidth getting
updated at wrong index in bandwidth table in tx_stats.
Fix this index mismatch between mac80211 and driver stats table (BW table)
by making the number of bandwidth type in driver compatible with mac80211.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Fixes: a904417fc876 ("ath10k: add extended per sta tx statistics support")
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 7 ++++---
drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debugfs_sta.c b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
index 8331d8b..c704ae3 100644
--- a/drivers/net/wireless/ath/ath10k/debugfs_sta.c
+++ b/drivers/net/wireless/ath/ath10k/debugfs_sta.c
@@ -685,11 +685,12 @@ static ssize_t ath10k_dbg_sta_dump_tx_stats(struct file *file,
" %llu ", stats->ht[j][i]);
len += scnprintf(buf + len, size - len, "\n");
len += scnprintf(buf + len, size - len,
- " BW %s (20,40,80,160 MHz)\n", str[j]);
+ " BW %s (20,5,10,40,80,160 MHz)\n", str[j]);
len += scnprintf(buf + len, size - len,
- " %llu %llu %llu %llu\n",
+ " %llu %llu %llu %llu %llu %llu\n",
stats->bw[j][0], stats->bw[j][1],
- stats->bw[j][2], stats->bw[j][3]);
+ stats->bw[j][2], stats->bw[j][3],
+ stats->bw[j][4], stats->bw[j][5]);
len += scnprintf(buf + len, size - len,
" NSS %s (1x1,2x2,3x3,4x4)\n", str[j]);
len += scnprintf(buf + len, size - len,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index d9b646f..d915942 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5045,7 +5045,7 @@ enum wmi_rate_preamble {
#define ATH10K_FW_SKIPPED_RATE_CTRL(flags) (((flags) >> 6) & 0x1)
#define ATH10K_VHT_MCS_NUM 10
-#define ATH10K_BW_NUM 4
+#define ATH10K_BW_NUM 6
#define ATH10K_NSS_NUM 4
#define ATH10K_LEGACY_NUM 12
#define ATH10K_GI_NUM 2
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/4] ath10k: Fix the incorrect updation of NSS data in tx stats
From: Surabhi Vishnoi @ 2019-02-26 9:27 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
In-Reply-To: <1551173278-20926-1-git-send-email-svishnoi@codeaurora.org>
The NSS data is updated incorrectly in the tx stats as the array
indexing starts from zero.
Fix the incorrect updation of NSS data in tx_stats by taking into
consideration the array index starting from zero.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Fixes: a904417fc876 ("ath10k: add extended per sta tx statistics support")
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 4fc8856..941ae20 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2969,7 +2969,7 @@ static inline s8 ath10k_get_legacy_rate_idx(struct ath10k *ar, u8 rate)
}
STATS_OP_FMT(AMPDU).bw[0][bw] +=
pstats->succ_bytes + pstats->retry_bytes;
- STATS_OP_FMT(AMPDU).nss[0][nss] +=
+ STATS_OP_FMT(AMPDU).nss[0][nss - 1] +=
pstats->succ_bytes + pstats->retry_bytes;
STATS_OP_FMT(AMPDU).gi[0][gi] +=
pstats->succ_bytes + pstats->retry_bytes;
@@ -2977,7 +2977,7 @@ static inline s8 ath10k_get_legacy_rate_idx(struct ath10k *ar, u8 rate)
pstats->succ_bytes + pstats->retry_bytes;
STATS_OP_FMT(AMPDU).bw[1][bw] +=
pstats->succ_pkts + pstats->retry_pkts;
- STATS_OP_FMT(AMPDU).nss[1][nss] +=
+ STATS_OP_FMT(AMPDU).nss[1][nss - 1] +=
pstats->succ_pkts + pstats->retry_pkts;
STATS_OP_FMT(AMPDU).gi[1][gi] +=
pstats->succ_pkts + pstats->retry_pkts;
@@ -2989,27 +2989,27 @@ static inline s8 ath10k_get_legacy_rate_idx(struct ath10k *ar, u8 rate)
}
STATS_OP_FMT(SUCC).bw[0][bw] += pstats->succ_bytes;
- STATS_OP_FMT(SUCC).nss[0][nss] += pstats->succ_bytes;
+ STATS_OP_FMT(SUCC).nss[0][nss - 1] += pstats->succ_bytes;
STATS_OP_FMT(SUCC).gi[0][gi] += pstats->succ_bytes;
STATS_OP_FMT(SUCC).bw[1][bw] += pstats->succ_pkts;
- STATS_OP_FMT(SUCC).nss[1][nss] += pstats->succ_pkts;
+ STATS_OP_FMT(SUCC).nss[1][nss - 1] += pstats->succ_pkts;
STATS_OP_FMT(SUCC).gi[1][gi] += pstats->succ_pkts;
STATS_OP_FMT(FAIL).bw[0][bw] += pstats->failed_bytes;
- STATS_OP_FMT(FAIL).nss[0][nss] += pstats->failed_bytes;
+ STATS_OP_FMT(FAIL).nss[0][nss - 1] += pstats->failed_bytes;
STATS_OP_FMT(FAIL).gi[0][gi] += pstats->failed_bytes;
STATS_OP_FMT(FAIL).bw[1][bw] += pstats->failed_pkts;
- STATS_OP_FMT(FAIL).nss[1][nss] += pstats->failed_pkts;
+ STATS_OP_FMT(FAIL).nss[1][nss - 1] += pstats->failed_pkts;
STATS_OP_FMT(FAIL).gi[1][gi] += pstats->failed_pkts;
STATS_OP_FMT(RETRY).bw[0][bw] += pstats->retry_bytes;
- STATS_OP_FMT(RETRY).nss[0][nss] += pstats->retry_bytes;
+ STATS_OP_FMT(RETRY).nss[0][nss - 1] += pstats->retry_bytes;
STATS_OP_FMT(RETRY).gi[0][gi] += pstats->retry_bytes;
STATS_OP_FMT(RETRY).bw[1][bw] += pstats->retry_pkts;
- STATS_OP_FMT(RETRY).nss[1][nss] += pstats->retry_pkts;
+ STATS_OP_FMT(RETRY).nss[1][nss - 1] += pstats->retry_pkts;
STATS_OP_FMT(RETRY).gi[1][gi] += pstats->retry_pkts;
if (txrate->flags >= RATE_INFO_FLAGS_MCS) {
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/4] Fix inconsistencies observed in population of tx_stats in debugfs
From: Surabhi Vishnoi @ 2019-02-26 9:27 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
There are some inconsistencies observed while filling various peer tx stats in tx_stats
debugfs entry per sta.
This patchset fixes the wrong updation of NSS, SGI, Bandwidth and rate_table in tx_stats
debugfs entry per sta.
Changes from v1:
-Initialized the uninitialized variable flags in [Patch 3/4]
Surabhi Vishnoi (4):
ath10k: Fix the incorrect updation of NSS data in tx stats
ath10k: Fix the wrong updation of BW in tx_stats debugfs entry
ath10k: Fix the wrong updation of SGI in tx_stats debugfs
ath10k: Fix the wrong calculation ht_idx and idx of rate table for
tx_stats
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 7 ++++---
drivers/net/wireless/ath/ath10k/htt_rx.c | 26 ++++++++++++++------------
drivers/net/wireless/ath/ath10k/wmi.h | 3 ++-
3 files changed, 20 insertions(+), 16 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] ath10k: fix incorrect multicast/broadcast rate setting
From: Sven Eckelmann @ 2019-02-26 9:23 UTC (permalink / raw)
To: Sven Eckelmann, Ansuel Smith
Cc: ath10k, Pradeep Kumar Chitrapu, Zhi Chen, linux-wireless,
Sebastian Gottschall, John Crispin, Steve deRosier
In-Reply-To: <2172036.sbaLp6LFFn@bentobox>
[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]
On Monday, 25 February 2019 21:00:38 CET Sven Eckelmann wrote:
[...]
> Tested-by: Sven Eckelmann <sven@narfation.org>
>
> Was tested on QCA988X with 10.2.4-1.0-00041
I just wanted to test it with 802.11s setup on IPQ4019 with 10.4-3.5.3-00057
and QCA9888 with 10.4-3.5.3-00053 (ath10k-firmware) and 10.4-3.6-00140
(linux-firmware 2018-12-16-211de167) for both. But it looks like the firmware
always crashes with and without this patch and 11s.
[ 221.620803] ath10k_pci 0000:01:00.0: wmi command 36967 timeout, restarting hardware
[ 221.744056] ieee80211 phy0: Hardware restart was requested
[ 225.130829] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling..
[ 226.170824] ath10k_pci 0000:01:00.0: Service connect timeout
[ 226.170871] ath10k_pci 0000:01:00.0: failed to connect htt (-110)
[ 226.252248] ath10k_pci 0000:01:00.0: Could not init core: -110
If i count correctly, this is WMI_10_4_GPIO_CONFIG_CMDID. Not really supported
by upstream but it looks like there is an Openwrt private patch (not yet
accepted upstream [1])
package/kernel/mac80211/patches/ath/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
which I have now removed to fix this problem for me.
The tests with 10.4-3.6-00140 and 10.4-3.5.3-* worked fine without this patch.
@Kalle are you expecting that he resents the patch again or can you just
append this information to the commit message? At least it looks at the moment
like there will be no new patch in the near future. But the
commit cd93b83ad92 ("ath10k: support for multicast rate control") is breaking
real world setups.
Kind regards,
Sven
[1] https://patchwork.kernel.org/patch/10327075/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
From: Sven Eckelmann @ 2019-02-26 9:16 UTC (permalink / raw)
To: ath10k, John Crispin, Ansuel Smith, openwrt-devel
Cc: Kalle Valo, Sebastian Gottschall, linux-wireless,
Sebastian Gottschall
In-Reply-To: <1523027875-5143-1-git-send-email-kvalo@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
> From: Sebastian Gottschall <s.gottschall@newmedia-net.de>
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
> chipsets with on chipset connected led's using WMI Firmware API. The LED
> device will get available named as "ath10k-phyX" at sysfs and can be controlled
> with various triggers. adds also debugfs interface for gpio control.
>
> Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
> Reviewed-by: Steve deRosier <derosier@cal-sierra.com>
> [kvalo: major reorg and cleanup]
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
[ 221.620803] ath10k_pci 0000:01:00.0: wmi command 36967 timeout, restarting hardware
[ 221.744056] ieee80211 phy0: Hardware restart was requested
[ 225.130829] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling..
[ 226.170824] ath10k_pci 0000:01:00.0: Service connect timeout
[ 226.170871] ath10k_pci 0000:01:00.0: failed to connect htt (-110)
[ 226.252248] ath10k_pci 0000:01:00.0: Could not init core: -110
This was tested on an A62 with following wireless config:
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/40000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/soc/a000000.wifi'
option htmode 'HT20'
option disabled '0'
option country US
config wifi-device 'radio2'
option type 'mac80211'
option channel '149'
option hwmode '11a'
option path 'platform/soc/a800000.wifi'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none'
config wifi-iface 'mesh1'
option device 'radio1'
option ifname 'mesh1'
option network 'nwi_mesh1'
option mode 'mesh'
option mesh_id 'TestMesh'
option encryption 'none'
config wifi-iface 'mesh2'
option device 'radio2'
option ifname 'mesh2'
option network 'nwi_mesh2'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V2] staging: wilc1000: fix incorrent type assignment
From: Ajay.Kathat @ 2019-02-26 8:24 UTC (permalink / raw)
To: tsu.yubo, Adham.Abozaeid, gregkh, linux-kernel, yuzibode
Cc: linux-wireless, devel
In-Reply-To: <20190226072556.26745-1-tsu.yubo@gmail.com>
Thanks.
On 2/26/2019 12:55 PM, Bo YU wrote:
> Fix sparse warning:
>
> drivers/staging/wilc1000/host_interface.c:450:30: warning: incorrect type in assignment (different base types)
> drivers/staging/wilc1000/host_interface.c:450:30: expected restricted __le16 [usertype] beacon_period
> drivers/staging/wilc1000/host_interface.c:450:30: got unsigned short [usertype] beacon_interval
> drivers/staging/wilc1000/host_interface.c:451:25: warning: incorrect type in assignment (different base types)
> drivers/staging/wilc1000/host_interface.c:451:25: expected restricted __le16 [usertype] cap_info
> drivers/staging/wilc1000/host_interface.c:451:25: got unsigned short [usertype] capability
>
> Signed-off-by: Bo YU <tsu.yubo@gmail.com>
Reviewed-by: Ajay Singh <ajay.kathat@microchip.com>
> ---
> V2: use cpu_to_le16 assign valid type according to Ajay's suggestions
> ---
> drivers/staging/wilc1000/host_interface.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
> index 50dc2dd942f5..20349af2ed30 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -447,8 +447,8 @@ void *wilc_parse_join_bss_param(struct cfg80211_bss *bss,
> if (!param)
> return NULL;
>
> - param->beacon_period = bss->beacon_interval;
> - param->cap_info = bss->capability;
> + param->beacon_period = cpu_to_le16(bss->beacon_interval);
> + param->cap_info = cpu_to_le16(bss->capability);
> param->bss_type = WILC_FW_BSS_TYPE_INFRA;
> param->ch = ieee80211_frequency_to_channel(bss->channel->center_freq);
> ether_addr_copy(param->bssid, bss->bssid);
>
^ permalink raw reply
* RE: [PATCH v2 00/24] rtw88: major fixes for 8822c to have stable functionalities
From: Tony Chuang @ 2019-02-26 8:20 UTC (permalink / raw)
To: kvalo@codeaurora.org, johannes@sipsolutions.net
Cc: Larry.Finger@lwfinger.net, linux-wireless@vger.kernel.org, Pkshih,
Andy Huang, briannorris@chromium.org, sgruszka@redhat.com
In-Reply-To: <1550134743-17443-1-git-send-email-yhchuang@realtek.com>
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> Note this patch set is based on patch set "rtw88: mac80211 driver for
> Realtek 802.11ac wireless network chips". For reference:
> https://patchwork.kernel.org/cover/10811967/
> https://lkml.kernel.org/linux-wireless/1550131671-2601-1-git-send-email-yhch
> uang@realtek.com/
>
> These patches are mean to make sure 8822c chip to operate normal for most
> of the basic functionalities, such as power on, switch channel, scan,
> connection establish and connection monitor.
>
> As the original patch set was sent 3 months ago, progress has been made
> by Realtek during the past months. Now we have tested on more chips and
> released tables and parameters for them. Also the chips are all
> programed with efuse map released for 8822c.
>
> Most of the changes are about BB and RF, both control the tx/rx path.
> PHY parameters/seq and efuse info make sure the hardware is powered on
> correctly. And channel setting updates help driver to switch to target
> channel accurately. Then trx mode setting and DACK will make hardware to
> have stable performance to tx/rx to connect to AP.
>
> Here tx power control is also required to transmit with a precise power.
> Otherwise if the power is too high or too low, the peer might not be able
> to receive the signal.
>
> Finally, we need to report correct tx status for mac80211's connection
> monitor system, this requires firmware's C2H of tx status report. After
> this, users can use 8822c chips for more stable wireless communication.
>
>
> v2
>
> This v2 is sent for that https://patchwork.kernel.org/cover/10811967/
> has many modifications and the original patch set would not apply.
> Also with a few changes in this one. Listed below
>
> - report ACK for tx frames not have IEEE80211_TX_CTL_REQ_TX_STATUS,
> otherwise they will be marked as "drop"
> - add more rf register write protection for patch "rtw88: add a delay
> after writing a rf register"
>
Hi Kalle,
Can I ask that when will this patch set probably be applied into your tree?
Thanks!
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH] staging: wilc1000: Fix incorrent type in assignment
From: YU Bo @ 2019-02-26 7:27 UTC (permalink / raw)
To: Ajay.Kathat
Cc: Adham.Abozaeid, gregkh, devel, linux-wireless, linux-kernel,
yuzibode
In-Reply-To: <d71296ff-1de3-3af7-7ade-02e4ced08e7e@microchip.com>
On Tue, Feb 26, 2019 at 06:39:28AM +0000, Ajay.Kathat@microchip.com wrote:
>
>
>On 2/26/2019 8:58 AM, Bo YU wrote:
>> The patch fixes following sparse warning:
>>
>> drivers/staging/wilc1000/host_interface.c:450:30: warning: incorrect type in assignment (different base types)
>> drivers/staging/wilc1000/host_interface.c:450:30: expected restricted __le16 [usertype] beacon_period
>> drivers/staging/wilc1000/host_interface.c:450:30: got unsigned short [usertype] beacon_interval
>> drivers/staging/wilc1000/host_interface.c:451:25: warning: incorrect type in assignment (different base types)
>> drivers/staging/wilc1000/host_interface.c:451:25: expected restricted __le16 [usertype] cap_info
>> drivers/staging/wilc1000/host_interface.c:451:25: got unsigned short [usertype] capability
>>
>> Signed-off-by: Bo YU <tsu.yubo@gmail.com>
>> ---
>> I have no hardware to test it and just to compile it
>
>Thanks for submitting the patch.
>
>The correct way to fix above spare warning is by using cpu_to_le16()
>while filing the information in ->beacon_period and ->cap_info because
>wilc1000 module expects the data in _le_ byte order.
>
>Please changes the below lines in host_interface.c and resubmit the patch.
> param->beacon_period = bss->beacon_interval;
> param->cap_info = bss->capability;
>to
> param->beacon_period = cpu_to_le16(bss->beacon_interval);
> param->cap_info = cpu_to_le16(bss->capability);
Ok, done, thank you,
Bo
>
>> ---
>> drivers/staging/wilc1000/host_interface.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
>> index 50dc2dd942f5..cdcb52aec779 100644
>> --- a/drivers/staging/wilc1000/host_interface.c
>> +++ b/drivers/staging/wilc1000/host_interface.c
>> @@ -106,10 +106,10 @@ struct wilc_join_bss_param {
>> u8 ssid_terminator;
>> u8 bss_type;
>> u8 ch;
>> - __le16 cap_info;
>> + u16 cap_info;
>> u8 sa[ETH_ALEN];
>> u8 bssid[ETH_ALEN];
>> - __le16 beacon_period;
>> + u16 beacon_period;
>> u8 dtim_period;
>> u8 supp_rates[WILC_MAX_RATES_SUPPORTED + 1];
>> u8 wmm_cap;
>>
>
>Regards,
>Ajay
^ permalink raw reply
* [PATCH V2] staging: wilc1000: fix incorrent type assignment
From: Bo YU @ 2019-02-26 7:25 UTC (permalink / raw)
To: adham.abozaeid, ajay.kathat, gregkh, linux-kernel, yuzibode
Cc: Bo YU, linux-wireless, devel
Fix sparse warning:
drivers/staging/wilc1000/host_interface.c:450:30: warning: incorrect type in assignment (different base types)
drivers/staging/wilc1000/host_interface.c:450:30: expected restricted __le16 [usertype] beacon_period
drivers/staging/wilc1000/host_interface.c:450:30: got unsigned short [usertype] beacon_interval
drivers/staging/wilc1000/host_interface.c:451:25: warning: incorrect type in assignment (different base types)
drivers/staging/wilc1000/host_interface.c:451:25: expected restricted __le16 [usertype] cap_info
drivers/staging/wilc1000/host_interface.c:451:25: got unsigned short [usertype] capability
Signed-off-by: Bo YU <tsu.yubo@gmail.com>
---
V2: use cpu_to_le16 assign valid type according to Ajay's suggestions
---
drivers/staging/wilc1000/host_interface.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
index 50dc2dd942f5..20349af2ed30 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -447,8 +447,8 @@ void *wilc_parse_join_bss_param(struct cfg80211_bss *bss,
if (!param)
return NULL;
- param->beacon_period = bss->beacon_interval;
- param->cap_info = bss->capability;
+ param->beacon_period = cpu_to_le16(bss->beacon_interval);
+ param->cap_info = cpu_to_le16(bss->capability);
param->bss_type = WILC_FW_BSS_TYPE_INFRA;
param->ch = ieee80211_frequency_to_channel(bss->channel->center_freq);
ether_addr_copy(param->bssid, bss->bssid);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] staging: wilc1000: Fix incorrent type in assignment
From: Ajay.Kathat @ 2019-02-26 6:39 UTC (permalink / raw)
To: tsu.yubo, Adham.Abozaeid, gregkh
Cc: devel, linux-wireless, linux-kernel, yuzibode
In-Reply-To: <20190226032825.26171-1-tsu.yubo@gmail.com>
On 2/26/2019 8:58 AM, Bo YU wrote:
> The patch fixes following sparse warning:
>
> drivers/staging/wilc1000/host_interface.c:450:30: warning: incorrect type in assignment (different base types)
> drivers/staging/wilc1000/host_interface.c:450:30: expected restricted __le16 [usertype] beacon_period
> drivers/staging/wilc1000/host_interface.c:450:30: got unsigned short [usertype] beacon_interval
> drivers/staging/wilc1000/host_interface.c:451:25: warning: incorrect type in assignment (different base types)
> drivers/staging/wilc1000/host_interface.c:451:25: expected restricted __le16 [usertype] cap_info
> drivers/staging/wilc1000/host_interface.c:451:25: got unsigned short [usertype] capability
>
> Signed-off-by: Bo YU <tsu.yubo@gmail.com>
> ---
> I have no hardware to test it and just to compile it
Thanks for submitting the patch.
The correct way to fix above spare warning is by using cpu_to_le16()
while filing the information in ->beacon_period and ->cap_info because
wilc1000 module expects the data in _le_ byte order.
Please changes the below lines in host_interface.c and resubmit the patch.
param->beacon_period = bss->beacon_interval;
param->cap_info = bss->capability;
to
param->beacon_period = cpu_to_le16(bss->beacon_interval);
param->cap_info = cpu_to_le16(bss->capability);
> ---
> drivers/staging/wilc1000/host_interface.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
> index 50dc2dd942f5..cdcb52aec779 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -106,10 +106,10 @@ struct wilc_join_bss_param {
> u8 ssid_terminator;
> u8 bss_type;
> u8 ch;
> - __le16 cap_info;
> + u16 cap_info;
> u8 sa[ETH_ALEN];
> u8 bssid[ETH_ALEN];
> - __le16 beacon_period;
> + u16 beacon_period;
> u8 dtim_period;
> u8 supp_rates[WILC_MAX_RATES_SUPPORTED + 1];
> u8 wmm_cap;
>
Regards,
Ajay
^ permalink raw reply
* [PATCH] staging: wilc1000: Fix incorrent type in assignment
From: Bo YU @ 2019-02-26 3:28 UTC (permalink / raw)
To: adham.abozaeid, ajay.kathat, gregkh
Cc: Bo YU, linux-wireless, devel, linux-kernel, yuzibode
The patch fixes following sparse warning:
drivers/staging/wilc1000/host_interface.c:450:30: warning: incorrect type in assignment (different base types)
drivers/staging/wilc1000/host_interface.c:450:30: expected restricted __le16 [usertype] beacon_period
drivers/staging/wilc1000/host_interface.c:450:30: got unsigned short [usertype] beacon_interval
drivers/staging/wilc1000/host_interface.c:451:25: warning: incorrect type in assignment (different base types)
drivers/staging/wilc1000/host_interface.c:451:25: expected restricted __le16 [usertype] cap_info
drivers/staging/wilc1000/host_interface.c:451:25: got unsigned short [usertype] capability
Signed-off-by: Bo YU <tsu.yubo@gmail.com>
---
I have no hardware to test it and just to compile it
---
drivers/staging/wilc1000/host_interface.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c
index 50dc2dd942f5..cdcb52aec779 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -106,10 +106,10 @@ struct wilc_join_bss_param {
u8 ssid_terminator;
u8 bss_type;
u8 ch;
- __le16 cap_info;
+ u16 cap_info;
u8 sa[ETH_ALEN];
u8 bssid[ETH_ALEN];
- __le16 beacon_period;
+ u16 beacon_period;
u8 dtim_period;
u8 supp_rates[WILC_MAX_RATES_SUPPORTED + 1];
u8 wmm_cap;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] ath10k: fix incorrect multicast/broadcast rate setting
From: Sven Eckelmann @ 2019-02-25 20:00 UTC (permalink / raw)
To: ath10k; +Cc: Pradeep Kumar Chitrapu, Zhi Chen, linux-wireless
In-Reply-To: <1544504171-19810-1-git-send-email-pradeepc@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 699 bytes --]
On Tuesday, 11 December 2018 05:56:11 CET Pradeep Kumar Chitrapu wrote:
> From: Pradeep kumar Chitrapu <pradeepc@codeaurora.org>
>
> Invalid rate code is sent to firmware when multicast rate value of 0 is
> sent to driver indicating disabled case, causing broken mesh path.
> so fix that.
>
> Tested on QCA9984 with firmware 10.4-3.6.1-00827
>
> Fixes: cd93b83ad92 ("ath10k: support for multicast rate control")
> Co-developed-by: Zhi Chen <zhichen@codeaurora.org>
> Signed-off-by: Zhi Chen <zhichen@codeaurora.org>
> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Tested-by: Sven Eckelmann <sven@narfation.org>
Was tested on QCA988X with 10.2.4-1.0-00041
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ath10k: Fill rx duration for each peer in fw_stats for WCN3990
From: Kalle Valo @ 2019-02-25 17:17 UTC (permalink / raw)
To: Surabhi Vishnoi; +Cc: ath10k, linux-wireless, Surabhi Vishnoi
In-Reply-To: <1550570110-32010-1-git-send-email-svishnoi@codeaurora.org>
Surabhi Vishnoi <svishnoi@codeaurora.org> wrote:
> Currently, rx_duration for each peer is not getting populated in
> fw_stats debugfs entry for WCN3990.
>
> WCN3990 firmware sends rx duration for each peer as part of
> peer_extd_stats in WMI_UPDATE_STATS_EVENT. To enable peer_extd_stats,
> firmware expects host to send fw_stats_req_mask with flag
> WMI_TLV_PEER_STATS_EXTD set in WMI_REQUEST_STATS_CMD.
>
> Send fw_stats_req_mask with flag WMI_TLV_PEER_STATS_EXTD set in
> WMI_REQUEST_STATS_CMD and parse the peer_extd_stats in
> WMI_UPDATE_STATS_EVENT to populate the rx_duration of each peer
> in fw_stats debugfs entry.
>
> Currently the driver handles 32-bit rx_duration, but the rx_duration
> for WCN3990 can be upto 63 bit. The firmware sends rx_duration split
> into two 32-bit fields, with the upper 32-bits being valid only if its
> MSB is set. This change handles the 63-bit rx_duration obtained from
> WCN3990 and maintain the backward compatibility.
>
> To get the rx_duration of each connected peer :
> cat /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kbuild bot reported a warning:
drivers/net/wireless/ath/ath10k/wmi-tlv.c: In function 'ath10k_wmi_tlv_op_pull_fw_stats':
>> drivers/net/wireless/ath/ath10k/wmi-tlv.c:1423:42: warning: left shift count >= width of type [-Wshift-count-overflow]
dst->rx_duration |= rx_duration_high <<
^~
--
https://patchwork.kernel.org/patch/10819589/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: net: mt76: update binding for mt7603 driver
From: Rob Herring @ 2019-02-25 16:33 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, devicetree
In-Reply-To: <20190130140756.91317-2-nbd@nbd.name>
On Wed, 30 Jan 2019 15:07:55 +0100, Felix Fietkau wrote:
> In addition to MT7603E PCI devices, the driver supports the WLAN core on
> MT7628/MT7688, which needs to be defined in DT.
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> .../bindings/net/wireless/mediatek,mt76.txt | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
From: Marc Zyngier @ 2019-02-25 14:52 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu, Devicetree List, <netdev@vger.kernel.org>,
<linux-wireless@vger.kernel.org>, Linux Kernel Mailing List,
linux-rockchip, David S. Miller, linux-arm-kernel
In-Reply-To: <CAKv+Gu9OOzOxx0rTAZqM8r4q_hRmOp3b=KP7fwgNeiu67FCApA@mail.gmail.com>
Hi Ard,
On 25/02/2019 12:45, Ard Biesheuvel wrote:
> On Sun, 24 Feb 2019 at 15:08, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>> For quite some time, I wondered why the PCI mwifiex device built in my
>> Chromebook was unable to use the good old legacy interrupts. But as MSIs
>> were working fine, I never really bothered investigating. I finally had a
>> look, and the result isn't very pretty.
>>
>> On this machine (rk3399-based kevin), the wake-up interrupt is described as
>> such:
>>
>> &pci_rootport {
>> mvl_wifi: wifi@0,0 {
>> compatible = "pci1b4b,2b42";
>> reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
>> 0x83010000 0x0 0x00100000 0x0 0x00100000>;
>> interrupt-parent = <&gpio0>;
>> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
>> pinctrl-names = "default";
>> pinctrl-0 = <&wlan_host_wake_l>;
>> wakeup-source;
>> };
>> };
>>
>> Note how the interrupt is part of the properties directly attached to the
>> PCI node. And yet, this interrupt has nothing to do with a PCI legacy
>> interrupt, as it is attached to the wake-up widget that bypasses the PCIe RC
>> altogether (Yay for the broken design!). This is in total violation of the
>> IEEE Std 1275-1994 spec[1], which clearly documents that such interrupt
>> specifiers describe the PCI device interrupts, and must obey the
>> INT-{A,B,C,D} mapping. Oops!
>>
>
> The mapping of legacy PCIe INTx interrupts onto wired system
> interrupts is a property of the PCIe host controller, not of a
> particular PCIe device. So I would argue that the code is broken here
> as well: it should never attempt to interpret 'interrupt' properties
> at the PCI device level as having any bearing on how legacy interrupts
> are routed.
OpenFirmware says that this node contains the interrupt number of the
device (4.1.1. Open Firmware-defined Properties for Child Nodes). The
trick is that this property is generated *from* the device, and not set
in stone.
DT, on the other hand, takes whatever is described there and uses it as
the gospel to configure the OS, no matter how the PCI device is actually
configured. If the two don't match (like in this case), things break.
This is the "DT describes the HW" mantra, for (sometimes) better or
(more generally) worse.
What the DT code does is to interpret the whole interrupt specifier,
*including the interrupt-parent*. And that feels wrong. It should always
be in the context of the host controller. But on the other side, the DT
code is not in the business of validating the DT either...
It outlines one thing: If you have to interpret per-device PCI
properties from DT, you're in for serious trouble. I should get some
better HW.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3] ath10k: Add support to provide higher range mem chunks in wmi init command
From: Surabhi Vishnoi @ 2019-02-25 12:48 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
With the current implementation of wmi init command,
there is no provision for the host driver to provide mem
chunks addresses with more than 32-bit, to the firmware.
WCN3990 is a 35-bit target and can accept mem chunks addresses
which are above 32-bit.
If firmware supports address range more than 32 bit, it
advertises the support by setting the WMI_SERVICE_EXTEND_ADDRESS
service. Based on this service fill the upper bits of paddr while
providing the mem chunks in the wmi init command.
Tested HW: WCN3990
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
This patch is dependent on following patch:
ath10k: correct the format of host memory chunks in wmi init command (https://patchwork.kernel.org/patch/10811669/)
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 10 ++++++--
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 42 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 1 +
3 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 554000c..4978299 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1572,7 +1572,7 @@ static enum wmi_txbf_conf ath10k_wmi_tlv_txbf_conf_scheme(struct ath10k *ar)
static void
ath10k_wmi_tlv_put_host_mem_chunks(struct ath10k *ar, void *host_mem_chunks)
{
- struct host_memory_chunk *chunk;
+ struct host_memory_chunk_tlv *chunk;
struct wmi_tlv *tlv;
int i;
__le16 tlv_len, tlv_tag;
@@ -1589,6 +1589,12 @@ static enum wmi_txbf_conf ath10k_wmi_tlv_txbf_conf_scheme(struct ath10k *ar)
chunk->size = __cpu_to_le32(ar->wmi.mem_chunks[i].len);
chunk->req_id = __cpu_to_le32(ar->wmi.mem_chunks[i].req_id);
+ if (test_bit(WMI_SERVICE_SUPPORT_EXTEND_ADDRESS,
+ ar->wmi.svc_map))
+ chunk->ptr_high = __cpu_to_le32
+ (upper_32_bits
+ (ar->wmi.mem_chunks[i].paddr));
+
ath10k_dbg(ar, ATH10K_DBG_WMI,
"wmi-tlv chunk %d len %d, addr 0x%llx, id 0x%x\n",
i,
@@ -1612,7 +1618,7 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_init(struct ath10k *ar)
void *ptr;
chunks_len = ar->wmi.num_mem_chunks *
- (sizeof(struct host_memory_chunk) + sizeof(*tlv));
+ (sizeof(struct host_memory_chunk_tlv) + sizeof(*tlv));
len = (sizeof(*tlv) + sizeof(*cmd)) +
(sizeof(*tlv) + sizeof(*cfg)) +
(sizeof(*tlv) + chunks_len);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index af4cb0e..b57522b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1384,6 +1384,30 @@ enum wmi_tlv_service {
WMI_TLV_SERVICE_AP_TWT = 153,
WMI_TLV_SERVICE_GMAC_OFFLOAD_SUPPORT = 154,
WMI_TLV_SERVICE_SPOOF_MAC_SUPPORT = 155,
+ WMI_TLV_SERVICE_PEER_TID_CONFIGS_SUPPORT = 156,
+ WMI_TLV_SERVICE_VDEV_SWRETRY_PER_AC_CONFIG_SUPPORT = 157,
+ WMI_TLV_SERVICE_DUAL_BEACON_ON_SINGLE_MAC_SCC_SUPPORT = 158,
+ WMI_TLV_SERVICE_DUAL_BEACON_ON_SINGLE_MAC_MCC_SUPPORT = 159,
+ WMI_TLV_SERVICE_MOTION_DET = 160,
+ WMI_TLV_SERVICE_INFRA_MBSSID = 161,
+ WMI_TLV_SERVICE_OBSS_SPATIAL_REUSE = 162,
+ WMI_TLV_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT = 163,
+ WMI_TLV_SERVICE_NAN_DBS_SUPPORT = 164,
+ WMI_TLV_SERVICE_NDI_DBS_SUPPORT = 165,
+ WMI_TLV_SERVICE_NAN_SAP_SUPPORT = 166,
+ WMI_TLV_SERVICE_NDI_SAP_SUPPORT = 167,
+ WMI_TLV_SERVICE_CFR_CAPTURE_SUPPORT = 168,
+ WMI_TLV_SERVICE_CFR_CAPTURE_IND_MSG_TYPE_1 = 169,
+ WMI_TLV_SERVICE_ESP_SUPPORT = 170,
+ WMI_TLV_SERVICE_PEER_CHWIDTH_CHANGE = 171,
+ WMI_TLV_SERVICE_WLAN_HPCS_PULSE = 172,
+ WMI_TLV_SERVICE_PER_VDEV_CHAINMASK_CONFIG_SUPPORT = 173,
+ WMI_TLV_SERVICE_TX_DATA_MGMT_ACK_RSSI = 174,
+ WMI_TLV_SERVICE_NAN_DISABLE_SUPPORT = 175,
+ WMI_TLV_SERVICE_HTT_H2T_NO_HTC_HDR_LEN_IN_MSG_LEN = 176,
+ WMI_TLV_SERVICE_COEX_SUPPORT_UNEQUAL_ISOLATION = 177,
+ WMI_TLV_SERVICE_HW_DB2DBM_CONVERSION_SUPPORT = 178,
+ WMI_TLV_SERVICE_SUPPORT_EXTEND_ADDRESS = 179,
WMI_TLV_MAX_EXT_SERVICE = 256,
};
@@ -1557,6 +1581,9 @@ enum wmi_tlv_service {
SVCMAP(WMI_TLV_SERVICE_THERM_THROT,
WMI_SERVICE_THERM_THROT,
WMI_TLV_MAX_SERVICE);
+ SVCMAP(WMI_TLV_SERVICE_SUPPORT_EXTEND_ADDRESS,
+ WMI_SERVICE_SUPPORT_EXTEND_ADDRESS,
+ WMI_TLV_MAX_SERVICE);
}
#undef SVCMAP
@@ -1694,6 +1721,21 @@ struct wmi_tlv_resource_config {
__le32 host_capab;
} __packed;
+/* structure describing host memory chunk. */
+struct host_memory_chunk_tlv {
+ /* id of the request that is passed up in service ready */
+ __le32 req_id;
+
+ /* the physical address the memory chunk */
+ __le32 ptr;
+
+ /* size of the chunk */
+ __le32 size;
+
+ /* the upper 32 bit address valid only for more than 32 bit target */
+ __le32 ptr_high;
+} __packed;
+
struct wmi_tlv_init_cmd {
struct wmi_tlv_abi_version abi;
__le32 num_host_mem_chunks;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index d9b646f..6277511 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -200,6 +200,7 @@ enum wmi_service {
WMI_SERVICE_RTT_RESPONDER_ROLE,
WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
WMI_SERVICE_REPORT_AIRTIME,
+ WMI_SERVICE_SUPPORT_EXTEND_ADDRESS,
/* Remember to add the new value to wmi_service_name()! */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
From: Ard Biesheuvel @ 2019-02-25 12:45 UTC (permalink / raw)
To: Marc Zyngier
Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu, Devicetree List, <netdev@vger.kernel.org>,
<linux-wireless@vger.kernel.org>, Linux Kernel Mailing List,
linux-rockchip, David S. Miller, linux-arm-kernel
In-Reply-To: <20190224140426.3267-1-marc.zyngier@arm.com>
On Sun, 24 Feb 2019 at 15:08, Marc Zyngier <marc.zyngier@arm.com> wrote:
>
> For quite some time, I wondered why the PCI mwifiex device built in my
> Chromebook was unable to use the good old legacy interrupts. But as MSIs
> were working fine, I never really bothered investigating. I finally had a
> look, and the result isn't very pretty.
>
> On this machine (rk3399-based kevin), the wake-up interrupt is described as
> such:
>
> &pci_rootport {
> mvl_wifi: wifi@0,0 {
> compatible = "pci1b4b,2b42";
> reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
> 0x83010000 0x0 0x00100000 0x0 0x00100000>;
> interrupt-parent = <&gpio0>;
> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> pinctrl-names = "default";
> pinctrl-0 = <&wlan_host_wake_l>;
> wakeup-source;
> };
> };
>
> Note how the interrupt is part of the properties directly attached to the
> PCI node. And yet, this interrupt has nothing to do with a PCI legacy
> interrupt, as it is attached to the wake-up widget that bypasses the PCIe RC
> altogether (Yay for the broken design!). This is in total violation of the
> IEEE Std 1275-1994 spec[1], which clearly documents that such interrupt
> specifiers describe the PCI device interrupts, and must obey the
> INT-{A,B,C,D} mapping. Oops!
>
The mapping of legacy PCIe INTx interrupts onto wired system
interrupts is a property of the PCIe host controller, not of a
particular PCIe device. So I would argue that the code is broken here
as well: it should never attempt to interpret 'interrupt' properties
at the PCI device level as having any bearing on how legacy interrupts
are routed.
> The net effect of the above is that Linux tries to do something vaguely
> sensible, and uses the same interrupt for both the wake-up widget and the
> PCI device. This doesn't work for two reasons: (1) the wake-up widget grabs
> the interrupt in exclusive mode, and (2) the PCI interrupt is still routed
> to the RC, leading to a screaming interrupt. This simply cannot work.
>
> To sort out this mess, we need to lift the confusion between the two
> interrupts. This is done by extending the DT binding to allow the wake-up
> interrupt to be described in a 'wake-up' subnode, sidestepping the issue
> completely. On my Chromebook, it now looks like this:
>
> &pci_rootport {
> mvl_wifi: wifi@0,0 {
> compatible = "pci1b4b,2b42";
> reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
> 0x83010000 0x0 0x00100000 0x0 0x00100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&wlan_host_wake_l>;
> wake-up {
> interrupt-parent = <&gpio0>;
> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> wakeup-source;
> };
> };
> };
>
> The driver is then updated to look for this subnode first, and fallback to
> the original, broken behaviour (spitting out a warning in the offending
> configuration).
>
> For good measure, there are two additional patches:
>
> - The wake-up interrupt requesting is horribly racy, and could lead to
> unpredictable behaviours. Let's fix that properly.
>
> - A final patch implementing the above transformation for the whole
> RK3399-based Chromebook range, which all use the same broken
> configuration.
>
> With all that, I finally have PCI legacy interrupts working with the mwifiex
> driver on my Chromebook.
>
> [1] http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
>
> Marc Zyngier (4):
> dt-bindings/marvell-8xxx: Allow wake-up interrupt to be placed in a
> separate node
> mwifiex: Fetch wake-up interrupt from 'wake-up' subnode when it exists
> mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling
> it too late
> arm64: dts: rockchip: gru: Move wifi wake-up interrupt into its own
> subnode
>
> .../bindings/net/wireless/marvell-8xxx.txt | 23 ++++++++++++++++++-
> .../dts/rockchip/rk3399-gru-chromebook.dtsi | 8 ++++---
> drivers/net/wireless/marvell/mwifiex/main.c | 13 +++++++++--
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> --
> 2.20.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] cfg80211: Use kmemdup in cfg80211_gen_new_ie()
From: YueHaibing @ 2019-02-25 12:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/wireless/scan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 287518c6caa4..04d888628f29 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -190,10 +190,9 @@ static size_t cfg80211_gen_new_ie(const u8 *ie, size_t ielen,
/* copy subelement as we need to change its content to
* mark an ie after it is processed.
*/
- sub_copy = kmalloc(subie_len, gfp);
+ sub_copy = kmemdup(subelement, subie_len, gfp);
if (!sub_copy)
return 0;
- memcpy(sub_copy, subelement, subie_len);
pos = &new_ie[0];
^ permalink raw reply related
* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Toke Høiland-Jørgensen @ 2019-02-25 11:04 UTC (permalink / raw)
To: Kalle Valo
Cc: YueHaibing, QCA ath9k Development, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <877edom8vl.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Toke Høiland-Jørgensen <toke@redhat.com> writes:
>
>> Kalle Valo <kvalo@codeaurora.org> writes:
>>
>>> Toke Høiland-Jørgensen <toke@redhat.com> writes:
>>>
>>>> YueHaibing <yuehaibing@huawei.com> writes:
>>>>
>>>>> Fixes gcc '-Wunused-but-set-variable' warning:
>>>>>
>>>>> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
>>>>> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
>>>>> variable 'acq' set but not used [-Wunused-but-set-variable]
>>>>>
>>>>> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
>>>>> and airtime APIs"). Also remove related variables.
>>>>
>>>> Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
>>>> compiler warning for it.
>>>
>>> I think the warning is not enabled by default and you need to use W=1
>>> Makefile variable to enable it.
>>
>> Hmm, right, thanks! Guess I should get into the habit of compiling with
>> warnings enabled before submitting patches :)
>
> But you might get a lot of warnings and it could be difficult to find
> new warnings from all the noise. In ath10k I just fixed all W=1 warnings
> which I saw with gcc 8.1 and only now I was able to enable W=1 on my
> build script.
Ah, that was what that patch series was about :)
Right, well, I guess I'll give it a shot at some point and if it's not
too annoying I'll try to keep an eye on the warnings output...
-Toke
^ permalink raw reply
* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Kalle Valo @ 2019-02-25 10:59 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: YueHaibing, QCA ath9k Development, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <87imx8uor2.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@redhat.com> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Toke Høiland-Jørgensen <toke@redhat.com> writes:
>>
>>> YueHaibing <yuehaibing@huawei.com> writes:
>>>
>>>> Fixes gcc '-Wunused-but-set-variable' warning:
>>>>
>>>> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
>>>> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
>>>> variable 'acq' set but not used [-Wunused-but-set-variable]
>>>>
>>>> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
>>>> and airtime APIs"). Also remove related variables.
>>>
>>> Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
>>> compiler warning for it.
>>
>> I think the warning is not enabled by default and you need to use W=1
>> Makefile variable to enable it.
>
> Hmm, right, thanks! Guess I should get into the habit of compiling with
> warnings enabled before submitting patches :)
But you might get a lot of warnings and it could be difficult to find
new warnings from all the noise. In ath10k I just fixed all W=1 warnings
which I saw with gcc 8.1 and only now I was able to enable W=1 on my
build script.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Toke Høiland-Jørgensen @ 2019-02-25 10:49 UTC (permalink / raw)
To: Kalle Valo
Cc: YueHaibing, QCA ath9k Development, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <87ftscmbh7.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Toke Høiland-Jørgensen <toke@redhat.com> writes:
>
>> YueHaibing <yuehaibing@huawei.com> writes:
>>
>>> Fixes gcc '-Wunused-but-set-variable' warning:
>>>
>>> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
>>> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
>>> variable 'acq' set but not used [-Wunused-but-set-variable]
>>>
>>> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
>>> and airtime APIs"). Also remove related variables.
>>
>> Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
>> compiler warning for it.
>
> I think the warning is not enabled by default and you need to use W=1
> Makefile variable to enable it.
Hmm, right, thanks! Guess I should get into the habit of compiling with
warnings enabled before submitting patches :)
-Toke
^ permalink raw reply
* Re: [PATCH] ath10k: Add peer param map for tlv and non-tlv
From: Kalle Valo @ 2019-02-25 10:15 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless
In-Reply-To: <1550556576-19803-1-git-send-email-pillair@codeaurora.org>
Rakesh Pillai <pillair@codeaurora.org> writes:
> The peer param id for PEER_PARAM_USE_FIXED_PWR
> is different for tlv and non-tlv firmware. This
> causes incorrect peer param to be set by the driver
> to the firmware(tlv/non-tlv).
>
> Create seperate peer param map for tlv and non-tlv
> firmware and attach the peer param id based on the
> firmware type during the init.
>
> Tested HW: WCN3990
> Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> ---
> This change is dependent on the below patchset
> ath10k: add support for controlling tx power to a station (https://patchwork.kernel.org/patch/9562405/)
You got me really confused, that patch is two years old :) But I think
you mean this v3 patch (oddly the one submitted in 2017 was also v3?):
[v3,3/3] ath10k: add support for controlling tx power to a station
https://patchwork.kernel.org/patch/10825293/
--
Kalle Valo
^ permalink raw reply
* [PATCH] nl80211: Add NL80211_FLAG_CLEAR_SKB flag for other NL commands
From: Sunil Dutt @ 2019-02-25 10:07 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Sunil Dutt
This commit adds NL80211_FLAG_CLEAR_SKB flag to other NL commands
that carry key data to ensure they do not stick around on heap
after the SKB is freed.
Also introduced this flag for NL80211_CMD_VENDOR as there are sub
commands which configure the keys.
Signed-off-by: Sunil Dutt <usdutt@codeaurora.org>
---
net/wireless/nl80211.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 1c2530e..9a2f5a0 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13663,11 +13663,12 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
.cmd = NL80211_CMD_ASSOCIATE,
.doit = nl80211_associate,
.policy = nl80211_policy,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_CLEAR_SKB,
},
{
.cmd = NL80211_CMD_DEAUTHENTICATE,
.doit = nl80211_deauthenticate,
.policy = nl80211_policy,
@@ -13714,19 +13715,21 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
.cmd = NL80211_CMD_CONNECT,
.doit = nl80211_connect,
.policy = nl80211_policy,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_CLEAR_SKB,
},
{
.cmd = NL80211_CMD_UPDATE_CONNECT_PARAMS,
.doit = nl80211_update_connect_params,
.policy = nl80211_policy,
.flags = GENL_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_CLEAR_SKB,
},
{
.cmd = NL80211_CMD_DISCONNECT,
.doit = nl80211_disconnect,
.policy = nl80211_policy,
@@ -13751,11 +13754,12 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
.cmd = NL80211_CMD_SET_PMKSA,
.doit = nl80211_setdel_pmksa,
.policy = nl80211_policy,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_CLEAR_SKB,
},
{
.cmd = NL80211_CMD_DEL_PMKSA,
.doit = nl80211_setdel_pmksa,
.policy = nl80211_policy,
@@ -14103,11 +14107,12 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
.doit = nl80211_vendor_cmd,
.dumpit = nl80211_vendor_cmd_dump,
.policy = nl80211_policy,
.flags = GENL_UNS_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_WIPHY |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_CLEAR_SKB,
},
{
.cmd = NL80211_CMD_SET_QOS_MAP,
.doit = nl80211_set_qos_map,
.policy = nl80211_policy,
@@ -14158,11 +14163,12 @@ static void nl80211_post_doit(const struct genl_ops *ops, struct sk_buff *skb,
{
.cmd = NL80211_CMD_SET_PMK,
.doit = nl80211_set_pmk,
.policy = nl80211_policy,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
- NL80211_FLAG_NEED_RTNL,
+ NL80211_FLAG_NEED_RTNL |
+ NL80211_FLAG_CLEAR_SKB,
},
{
.cmd = NL80211_CMD_DEL_PMK,
.doit = nl80211_del_pmk,
.policy = nl80211_policy,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Kalle Valo @ 2019-02-25 10:03 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: YueHaibing, QCA ath9k Development, linux-wireless, netdev,
kernel-janitors
In-Reply-To: <87lg24urgq.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@redhat.com> writes:
> YueHaibing <yuehaibing@huawei.com> writes:
>
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
>> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
>> variable 'acq' set but not used [-Wunused-but-set-variable]
>>
>> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
>> and airtime APIs"). Also remove related variables.
>
> Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
> compiler warning for it.
I think the warning is not enabled by default and you need to use W=1
Makefile variable to enable it.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k: remove set but not used variable 'acq'
From: Toke Høiland-Jørgensen @ 2019-02-25 9:50 UTC (permalink / raw)
To: YueHaibing, QCA ath9k Development, Kalle Valo
Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
In-Reply-To: <20190225033246.127410-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> writes:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/ath9k/recv.c: In function 'ath_rx_count_airtime':
> drivers/net/wireless/ath/ath9k/recv.c:1010:18: warning:
> variable 'acq' set but not used [-Wunused-but-set-variable]
>
> It's not used after 89cea7493a34 ("ath9k: Switch to mac80211 TXQ scheduling
> and airtime APIs"). Also remove related variables.
Ah, right, seems I forgot to clean that up. I wonder why I didn't get a
compiler warning for it. Anyway, nice catch :)
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
-Toke
^ 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