Re: [PATCH 3/3] ath10k: average ack rssi support for data frames
Hi Balaji,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20180411]
[cannot apply to ath6kl/ath-next v4.16 v4.16-rc7 v4.16-rc6 v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Balaji-Pothunoori/cfg80211-average-ack-rssi-support-for-data-frames/20180414-115825
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/wireless/ath/ath10k/htt_rx.c:236:23: sparse: expression using
sizeof(void)
drivers/net/wireless/ath/ath10k/htt_rx.c:389:31: sparse: expression using
sizeof(void)
drivers/net/wireless/ath/ath10k/htt_rx.c:402:39: sparse: expression using
sizeof(void)
>> drivers/net/wireless/ath/ath10k/htt_rx.c:1911:30: sparse: cast to restricted
>> __le16
>> drivers/net/wireless/ath/ath10k/htt_rx.c:1911:28: sparse: incorrect type in
>> assignment (different base types) @@expected restricted __le16
>> [usertype] msdu_count @@got unsignedrestricted __le16 [usertype]
>> msdu_count @@
drivers/net/wireless/ath/ath10k/htt_rx.c:1911:28:expected restricted
__le16 [usertype] msdu_count
drivers/net/wireless/ath/ath10k/htt_rx.c:1911:28:got unsigned short
[unsigned] [usertype]
>> drivers/net/wireless/ath/ath10k/htt_rx.c:1925:29: sparse: restricted __le16
>> degrades to integer
drivers/net/wireless/ath/ath10k/htt_rx.c:1927:64: sparse: restricted __le16
degrades to integer
>> drivers/net/wireless/ath/ath10k/htt_rx.c:1926:50: sparse: incorrect type in
>> assignment (different base types) @@expected unsigned char [unsigned]
>> [assigned] [usertype] ack_rssi @@got igned] [usertype] ack_rssi @@
drivers/net/wireless/ath/ath10k/htt_rx.c:1926:50:expected unsigned char
[unsigned] [assigned] [usertype] ack_rssi
drivers/net/wireless/ath/ath10k/htt_rx.c:1926:50:got restricted __le16
drivers/net/wireless/ath/ath10k/htt_rx.c:1930:64: sparse: restricted __le16
degrades to integer
drivers/net/wireless/ath/ath10k/htt_rx.c:1929:50: sparse: incorrect type in
assignment (different base types) @@expected unsigned char [unsigned]
[assigned] [usertype] ack_rssi @@got igned] [usertype] ack_rssi @@
drivers/net/wireless/ath/ath10k/htt_rx.c:1929:50:expected unsigned char
[unsigned] [assigned] [usertype] ack_rssi
drivers/net/wireless/ath/ath10k/htt_rx.c:1929:50:got restricted __le16
drivers/net/wireless/ath/ath10k/htt_rx.c: In function
'ath10k_htt_t2h_msg_handler':
drivers/net/wireless/ath/ath10k/htt_rx.c:1886:9: warning: 'msdu_count' may
be used uninitialized in this function [-Wmaybe-uninitialized]
__le16 msdu_count;
^~
vim +1911 drivers/net/wireless/ath/ath10k/htt_rx.c
1875
1876 static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
1877 struct sk_buff *skb)
1878 {
1879 struct ath10k_htt *htt = &ar->htt;
1880 struct htt_resp *resp = (struct htt_resp *)skb->data;
1881 struct htt_tx_done tx_done = {};
1882 int status = MS(resp->data_tx_completion.flags,
HTT_DATA_TX_STATUS);
1883 __le16 msdu_id;
1884 int i;
1885 bool rssi_enabled;
1886 __le16 msdu_count;
1887
1888 switch (status) {
1889 case HTT_DATA_TX_STATUS_NO_ACK:
1890 tx_done.status = HTT_TX_COMPL_STATE_NOACK;
1891 break;
1892 case HTT_DATA_TX_STATUS_OK:
1893 tx_done.status = HTT_TX_COMPL_STATE_ACK;
1894 break;
1895 case HTT_DATA_TX_STATUS_DISCARD:
1896 case HTT_DATA_TX_STATUS_POSTPONE:
1897 case HTT_DATA_TX_STATUS_DOWNLOAD_FAIL:
1898 tx_done.status = HTT_TX_COMPL_STATE_DISCARD;
1899 break;
1900 default:
1901 ath10k_warn(ar, "unhandled tx completion status %d\n",
status);
1902 tx_done.status = HTT_TX_COMPL_STATE_DISCARD;
1903 break;
1904 }
1905
1906 ath10k_dbg(ar, ATH10K_DBG_HTT, "htt tx completion num_msdus
%d\n",
1907 resp->data_tx_completion.num_msdus);
1908
1909 if (resp->data_tx_completion.flags2 &
HTT_TX_CMPL_FLAG_DATA_RSSI) {
1910 rssi_enabled = true;
> 1911 msdu_count =
> __le16_to_cpu(resp->data_tx_completion.num_msdus);
1912 } else {
1913 rssi_enabled = false;
1914 }
1915
1916 for (i = 0; i < resp->data_tx_completion.num_msdus; i++) {
1917 msdu_id = resp->data_tx_completion.msdus[i];
1918 tx_done.msdu_id = __le16_to_cpu(msdu_id);
1919
1920 if (rssi_enabled) {
1921
Re: [PATCH 3/3] ath10k: average ack rssi support for data frames
Hi Balaji,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20180411]
[cannot apply to ath6kl/ath-next v4.16 v4.16-rc7 v4.16-rc6 v4.16]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Balaji-Pothunoori/cfg80211-average-ack-rssi-support-for-data-frames/20180414-115825
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/htt_rx.c: In function
'ath10k_htt_t2h_msg_handler':
>> drivers/net/wireless/ath/ath10k/htt_rx.c:1886:9: warning: 'msdu_count' may
>> be used uninitialized in this function [-Wmaybe-uninitialized]
__le16 msdu_count;
^~
vim +/msdu_count +1886 drivers/net/wireless/ath/ath10k/htt_rx.c
1875
1876 static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
1877 struct sk_buff *skb)
1878 {
1879 struct ath10k_htt *htt = &ar->htt;
1880 struct htt_resp *resp = (struct htt_resp *)skb->data;
1881 struct htt_tx_done tx_done = {};
1882 int status = MS(resp->data_tx_completion.flags,
HTT_DATA_TX_STATUS);
1883 __le16 msdu_id;
1884 int i;
1885 bool rssi_enabled;
> 1886 __le16 msdu_count;
1887
1888 switch (status) {
1889 case HTT_DATA_TX_STATUS_NO_ACK:
1890 tx_done.status = HTT_TX_COMPL_STATE_NOACK;
1891 break;
1892 case HTT_DATA_TX_STATUS_OK:
1893 tx_done.status = HTT_TX_COMPL_STATE_ACK;
1894 break;
1895 case HTT_DATA_TX_STATUS_DISCARD:
1896 case HTT_DATA_TX_STATUS_POSTPONE:
1897 case HTT_DATA_TX_STATUS_DOWNLOAD_FAIL:
1898 tx_done.status = HTT_TX_COMPL_STATE_DISCARD;
1899 break;
1900 default:
1901 ath10k_warn(ar, "unhandled tx completion status %d\n",
status);
1902 tx_done.status = HTT_TX_COMPL_STATE_DISCARD;
1903 break;
1904 }
1905
1906 ath10k_dbg(ar, ATH10K_DBG_HTT, "htt tx completion num_msdus
%d\n",
1907 resp->data_tx_completion.num_msdus);
1908
1909 if (resp->data_tx_completion.flags2 &
HTT_TX_CMPL_FLAG_DATA_RSSI) {
1910 rssi_enabled = true;
1911 msdu_count =
__le16_to_cpu(resp->data_tx_completion.num_msdus);
1912 } else {
1913 rssi_enabled = false;
1914 }
1915
1916 for (i = 0; i < resp->data_tx_completion.num_msdus; i++) {
1917 msdu_id = resp->data_tx_completion.msdus[i];
1918 tx_done.msdu_id = __le16_to_cpu(msdu_id);
1919
1920 if (rssi_enabled) {
1921 /* Total no of MSDUs should be even,
1922 * if odd MSDUs are sent firmware fills
1923 * last msdu id with 0x
1924 */
1925 if (msdu_count & 0x01)
1926 tx_done.ack_rssi =
1927
resp->data_tx_completion.msdus[msdu_count + i + 1];
1928 else
1929 tx_done.ack_rssi =
1930
resp->data_tx_completion.msdus[msdu_count + i];
1931 }
1932 /* kfifo_put: In practice firmware shouldn't fire off
per-CE
1933 * interrupt and main interrupt (MSI/-X range case) for
the same
1934 * HTC service so it should be safe to use kfifo_put
w/o lock.
1935 *
1936 * From kfifo_put() documentation:
1937 * Note that with only one concurrent reader and one
concurrent
1938 * writer, you don't need extra locking to use these
macro.
1939 */
1940 if (!kfifo_put(&htt->txdone_fifo, tx_done)) {
1941 ath10k_warn(ar, "txdone fifo overrun, msdu_id
%d status %d\n",
1942 tx_done.msdu_id, tx_done.status);
1943 ath10k_txrx_tx_unref(htt, &tx_done);
1944 }
1945 }
1946 }
1947
---
0-DAY kernel test infrastructureOpe
Re: [PATCH v2 13/13] dt: bindings: add bindings for wcn3990 wifi block
On Tue, Apr 10, 2018 at 10:19:46PM +0530, Govind Singh wrote:
> Add device tree binding documentation details for wcn3990
> wifi block present in Qualcomm SDM845/APQ8098 SoC into
> "qcom,ath10k.txt".
>
> Signed-off-by: Govind Singh
> ---
> .../bindings/net/wireless/qcom,ath10k.txt | 31
> ++
> 1 file changed, 31 insertions(+)
One nit, otherwise:
Reviewed-by: Rob Herring
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index 3d2a031..34e4f98 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -4,6 +4,7 @@ Required properties:
> - compatible: Should be one of the following:
> * "qcom,ath10k"
> * "qcom,ipq4019-wifi"
> + * "qcom,wcn3990-wifi"
>
> PCI based devices uses compatible string "qcom,ath10k" and takes calibration
> data along with board specific data via "qcom,ath10k-calibration-data".
> @@ -18,8 +19,12 @@ In general, entry "qcom,ath10k-pre-calibration-data" and
> "qcom,ath10k-calibration-data" conflict with each other and only one
> can be provided per device.
>
> +SNOC based devices (i.e. wcn3990) uses compatible string "qcom,wcn3990-wifi".
> +
> Optional properties:
> - reg: Address and length of the register set for the device.
> +- reg-names: Must include the list of following reg names,
> + "membase"
> - resets: Must contain an entry for each entry in reset-names.
>See ../reset/reseti.txt for details.
> - reset-names: Must include the list of following reset names,
> @@ -49,6 +54,8 @@ Optional properties:
>hw versions.
> - qcom,ath10k-pre-calibration-data : pre calibration data as an array,
>the length can vary between hw versions.
> +- -supply: handle to the regulator device tree node
> +optional "supply-name" is "vdd-0.8-cx-mx".
>
> Example (to supply the calibration data alone):
>
> @@ -119,3 +126,27 @@ wifi0: wifi@a00 {
> qcom,msi_base = <0x40>;
> qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
> };
> +
> +Example (to supply wcn3990 SoC wifi block details):
> +
> +qcom,wifi@1800 {
wifi@...
> + compatible = "qcom,wcn3990-wifi";
> + reg = <0x1880 0x80>;
> + reg-names = "membase";
> + clocks = <&clock_gcc clk_aggre2_noc_clk>;
> + clock-names = "smmu_aggre2_noc_clk"
> + interrupts =
> +<0 130 0 /* CE0 */ >,
> +<0 131 0 /* CE1 */ >,
> +<0 132 0 /* CE2 */ >,
> +<0 133 0 /* CE3 */ >,
> +<0 134 0 /* CE4 */ >,
> +<0 135 0 /* CE5 */ >,
> +<0 136 0 /* CE6 */ >,
> +<0 137 0 /* CE7 */ >,
> +<0 138 0 /* CE8 */ >,
> +<0 139 0 /* CE9 */ >,
> +<0 140 0 /* CE10 */ >,
> +<0 141 0 /* CE11 */ >;
> + vdd-0.8-cx-mx-supply = <&pm8998_l5>;
> +};
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/2] ath10k: support MAC address randomization in scan
On 4/13/2018 1:28 PM, Kalle Valo wrote:
cjhu...@codeaurora.org writes:
+ if (test_bit(WMI_SERVICE_SPOOF_MAC_SUPPORT, ar->wmi.svc_map)) {
+ ret = ath10k_wmi_scan_prob_req_oui(ar, ar->mac_addr);
+ if (ret) {
+ ath10k_err(ar, "failed to set prob req oui: %i\n", ret);
+ goto err_dfs_detector_exit;
+ }
+
+ ar->hw->wiphy->features |=
+ NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;
Do you support NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR too?
I'll add this flag too.
Are you going to send v2 or what's the plan?
Maybe a stupid question, but does ath10k support scheduled scan?
Regards,
Arend
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v2] ath10k: Implement get_expected_throughput callback
On 04/13/2018 06:48 AM, Kalle Valo wrote: Sven Eckelmann writes: But of course, I cannot say much about how the rate control from QCA works and in which form these information are already available. If you want to know the average PHY rate then wouldn't it be better to report the rates to one of the upper layers and let them to the averaging? Similar to what there already is for NL80211_STA_INFO_CHAIN_SIGNAL (NL80211_STA_INFO_CHAIN_SIGNAL_AVG) just for NL80211_STA_INFO_TX_BITRATE/ NL80211_STA_INFO_RX_BITRATE. Not sure whether this makes sense or whether someone has an use-case for it. Sounds like a good idea, but I don't see it preventing to apply this patch. We can always change the implementation later as this is just communication between ath10k and mac80211, right? I agree with Sven on the usage or expectation of get_expected_throughput cabllback. It's not really ab expected throughput implementation. However I'm with Kalle about approving this patch as Sven also mentioned "here sounds a little bit like in "Our medical doctor would ideally not decapitate each patient but we have at least an MD"". I could improve it once merged since there are more members in ath10k_per_peer_tx_stats useful such as succ_bytes, failed_bytes, duration, and etc. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Interest in getting ath10k-ct firmware support upstream?
On 04/13/2018 06:34 AM, Kalle Valo wrote: Ben Greear writes: I'm in the midst of porting my out-of-tree ath10k patches forward to the 4.16 kernel. In case you are interested in allowing support for ath10k-ct firmware in the upstream kernel, now would be a good time for me to work on this. Please let me know if you are interested. I don't really know what is needed for your firmware so difficult to really comment. And ath10k really does not support any specific firmware branch per se, it uses more finegrained feature based detection anyway. But as we are adding SDIO, USB and SNOC busses to ath10k, which is quite a enourmous task itself, and trying to support even a different firmware sounds really difficult. I have lots of mostly small tweaks, enabled by feature flags specific to my firmware. Adding my changes will increase the code size a bit, but I don't think it will add much fundamental complexity. If you will accept feature flags upstream for my firmware and will make an effort to review patches in a timely manner, I will work on a patch series and send it for review. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: search all IEs for variant before falling back
Kalle Valo writes:
> Thomas Hebb writes:
>
>> commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file
>> extension") added a feature to ath10k that allows Board Data File
>> (BDF) conflicts between multiple devices that use the same device IDs
>> but have different calibration requirements to be resolved by allowing
>> a "variant" string to be stored in SMBIOS [and later device tree, added
>> by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration-
>> variant")] that gets appended to the ID stored in board-2.bin.
>>
>> This original patch had a regression, however. Namely that devices with
>> a variant present in SMBIOS that didn't need custom BDFs could no longer
>> find the default BDF, which has no variant appended. The patch was
>> reverted and re-applied with a fix for this issue in commit 1657b8f84ed9
>> ("search SMBIOS for OEM board file extension").
>>
>> But the fix to fall back to a default BDF introduced another issue: the
>> driver currently parses IEs in board-2.bin one by one, and for each one
>> it first checks to see if it matches the ID with the variant appended.
>> If it doesn't, it checks to see if it matches the "fallback" ID with no
>> variant. If a matching BDF is found at any point during this search, the
>> search is terminated and that BDF is used. The issue is that it's very
>> possible (and is currently the case for board-2.bin files present in the
>> ath10k-firmware repository) for the default BDF to occur in an earlier
>> IE than the variant-specific BDF. In this case, the current code will
>> happily choose the default BDF even though a better-matching BDF is
>> present later in the file.
>>
>> This patch fixes the issue by first searching the entire file for the ID
>> with variant, and searching for the fallback ID only if that search
>> fails. It also includes some code cleanup in the area, as
>> ath10k_core_fetch_board_data_api_n() no longer does its own string
>> mangling to remove the variant from an ID, instead leaving that job to a
>> new flag passed to ath10k_core_create_board_name().
>>
>> I've tested this patch on a QCA4019 and verified that the driver behaves
>> correctly for 1) both fallback and variant BDFs present, 2) only fallback
>> BDF present, and 3) no matching BDFs present.
>>
>> Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension")
>> Signed-off-by: Thomas Hebb
>
> BTW, you forgot to CC linux-wireless so I don't see this in patchwork.
>
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches
I submitted v2 so that I see it in patchwork:
https://patchwork.kernel.org/patch/10340241/
--
Kalle Valo
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH v2] ath10k: search all IEs for variant before falling back
From: Thomas Hebb
commit f2593cb1b291 ("ath10k: Search SMBIOS for OEM board file
extension") added a feature to ath10k that allows Board Data File
(BDF) conflicts between multiple devices that use the same device IDs
but have different calibration requirements to be resolved by allowing
a "variant" string to be stored in SMBIOS [and later device tree, added
by commit d06f26c5c8a4 ("ath10k: search DT for qcom,ath10k-calibration-
variant")] that gets appended to the ID stored in board-2.bin.
This original patch had a regression, however. Namely that devices with
a variant present in SMBIOS that didn't need custom BDFs could no longer
find the default BDF, which has no variant appended. The patch was
reverted and re-applied with a fix for this issue in commit 1657b8f84ed9
("search SMBIOS for OEM board file extension").
But the fix to fall back to a default BDF introduced another issue: the
driver currently parses IEs in board-2.bin one by one, and for each one
it first checks to see if it matches the ID with the variant appended.
If it doesn't, it checks to see if it matches the "fallback" ID with no
variant. If a matching BDF is found at any point during this search, the
search is terminated and that BDF is used. The issue is that it's very
possible (and is currently the case for board-2.bin files present in the
ath10k-firmware repository) for the default BDF to occur in an earlier
IE than the variant-specific BDF. In this case, the current code will
happily choose the default BDF even though a better-matching BDF is
present later in the file.
This patch fixes the issue by first searching the entire file for the ID
with variant, and searching for the fallback ID only if that search
fails. It also includes some code cleanup in the area, as
ath10k_core_fetch_board_data_api_n() no longer does its own string
mangling to remove the variant from an ID, instead leaving that job to a
new flag passed to ath10k_core_create_board_name().
I've tested this patch on a QCA4019 and verified that the driver behaves
correctly for 1) both fallback and variant BDFs present, 2) only fallback
BDF present, and 3) no matching BDFs present.
Fixes: 1657b8f84ed9 ("ath10k: search SMBIOS for OEM board file extension")
Signed-off-by: Thomas Hebb
Signed-off-by: Kalle Valo
---
v2:
* resubmit to CC linux-wireless
drivers/net/wireless/ath/ath10k/core.c | 134 ++---
1 file changed, 72 insertions(+), 62 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 8a3020dbd4cf..50b52a9e9648 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1253,14 +1253,61 @@ static int ath10k_core_parse_bd_ie_board(struct ath10k
*ar,
return ret;
}
+static int ath10k_core_search_bd(struct ath10k *ar,
+const char *boardname,
+const u8 *data,
+size_t len)
+{
+ size_t ie_len;
+ struct ath10k_fw_ie *hdr;
+ int ret = -ENOENT, ie_id;
+
+ while (len > sizeof(struct ath10k_fw_ie)) {
+ hdr = (struct ath10k_fw_ie *)data;
+ ie_id = le32_to_cpu(hdr->id);
+ ie_len = le32_to_cpu(hdr->len);
+
+ len -= sizeof(*hdr);
+ data = hdr->data;
+
+ if (len < ALIGN(ie_len, 4)) {
+ ath10k_err(ar, "invalid length for board ie_id %d
ie_len %zu len %zu\n",
+ ie_id, ie_len, len);
+ return -EINVAL;
+ }
+
+ switch (ie_id) {
+ case ATH10K_BD_IE_BOARD:
+ ret = ath10k_core_parse_bd_ie_board(ar, data, ie_len,
+ boardname);
+ if (ret == -ENOENT)
+ /* no match found, continue */
+ break;
+
+ /* either found or error, so stop searching */
+ goto out;
+ }
+
+ /* jump over the padding */
+ ie_len = ALIGN(ie_len, 4);
+
+ len -= ie_len;
+ data += ie_len;
+ }
+
+out:
+ /* return result of parse_bd_ie_board() or -ENOENT */
+ return ret;
+}
+
static int ath10k_core_fetch_board_data_api_n(struct ath10k *ar,
const char *boardname,
+ const char *fallback_boardname,
const char *filename)
{
- size_t len, magic_len, ie_len;
- struct ath10k_fw_ie *hdr;
+ size_t len, magic_len;
const u8 *data;
- int ret, ie_id;
+ int ret;
ar->normal_mode_fw.board = ath10k_fetch_fw_file(ar,
ar->hw_params.fw.dir,
@@ -1298,69 +1345,23 @@
Re: [PATCH 3/3] ath10k: average ack rssi support for data frames
Balaji Pothunoori writes: > Average ack rssi value is weighted average of ack rssi for > no of msdu's has been sent. > This feature is enabled by the host driver if firmware is capable. > After receiving event from host, firmware allocates the necessary > memory to store the ack_rssi for data packets during the init time. > > After each successful transmission, If tx completion status is OK > and 24th bit is set in HTT message header then host will fetch the > ack_rssi else host can ignore the ack_rssi field. > > Note: This patch is depends on cfg80211 patch. > > Signed-off-by: Balaji Pothunoori > --- > drivers/net/wireless/ath/ath10k/core.c | 4 > drivers/net/wireless/ath/ath10k/htt.h| 6 +- > drivers/net/wireless/ath/ath10k/htt_rx.c | 21 + > drivers/net/wireless/ath/ath10k/mac.c| 4 > drivers/net/wireless/ath/ath10k/wmi.h| 8 > 5 files changed, 42 insertions(+), 1 deletion(-) Usually notes like above are better to put under "---" line, this way git-am will not include in the git commit log. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH v2] ath10k: Implement get_expected_throughput callback
Sven Eckelmann writes: > On Mittwoch, 28. März 2018 11:41:51 CEST ako...@codeaurora.org wrote: > [...] >> The rate average and throughput are relative. no? > > In the sense that rate has a tendency to affect the expected throughput - > yes. > But it is not like the expected throughput perfectly correlates with the rate > and you only have to multiply with a factor X (which seems to be missing in > your code) to get from rate to expected throughput. The average packet loss > for this selected rate, interframe spacing and the aggregation are important > factors here too. I doubt we can get that information from the firmware so should we just go with the "multiple with X" method? What would be good X? > But of course, I cannot say much about how the rate control from QCA works > and > in which form these information are already available. > > If you want to know the average PHY rate then wouldn't it be better to report > the rates to one of the upper layers and let them to the averaging? Similar > to > what there already is for NL80211_STA_INFO_CHAIN_SIGNAL > (NL80211_STA_INFO_CHAIN_SIGNAL_AVG) just for NL80211_STA_INFO_TX_BITRATE/ > NL80211_STA_INFO_RX_BITRATE. Not sure whether this makes sense or whether > someone has an use-case for it. Sounds like a good idea, but I don't see it preventing to apply this patch. We can always change the implementation later as this is just communication between ath10k and mac80211, right? -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: Interest in getting ath10k-ct firmware support upstream?
Ben Greear writes: > I'm in the midst of porting my out-of-tree ath10k patches forward to > the 4.16 kernel. > > In case you are interested in allowing support for ath10k-ct firmware > in the upstream kernel, now would be a good time for me to work on > this. > > Please let me know if you are interested. I don't really know what is needed for your firmware so difficult to really comment. And ath10k really does not support any specific firmware branch per se, it uses more finegrained feature based detection anyway. But as we are adding SDIO, USB and SNOC busses to ath10k, which is quite a enourmous task itself, and trying to support even a different firmware sounds really difficult. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: QCA9880 driver crash with FW 10.2.4-1.0-00029
Hauke Mehrtens writes: > I am using a BT home Hub 5A (Lantiq VR9 MIPS BE SoC). The wifi provided > by the QCA9880 chip is unstable with OpenWrt master from 26. Feb 2018. > > With FW 10.2.4-1.0-00033 and 10.2.4-1.0-00037 the wifi stops working > after about 1 to 3 days and I do not get any error message. With FW > 10.2.4-1.0-00029 I got this error message. FW 10.2.4.70.54 crashes > immediately. > > The 2.4 GHz wifi provided by ath9k is very stable. > > The wireless drivers shipped in OpenWrt master, which I am suing, are > based on backports with a snapshot of wireless testing from 1. November > 2017, and I am running kernel 4.9.85. Are you saying that it's unstable only on this product you have? Or is it a more general problem with all QCA9880 hardware? -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH 3/3] ath10k: average ack rssi support for data frames
Average ack rssi value is weighted average of ack rssi for
no of msdu's has been sent.
This feature is enabled by the host driver if firmware is capable.
After receiving event from host, firmware allocates the necessary
memory to store the ack_rssi for data packets during the init time.
After each successful transmission, If tx completion status is OK
and 24th bit is set in HTT message header then host will fetch the
ack_rssi else host can ignore the ack_rssi field.
Note: This patch is depends on cfg80211 patch.
Signed-off-by: Balaji Pothunoori
---
drivers/net/wireless/ath/ath10k/core.c | 4
drivers/net/wireless/ath/ath10k/htt.h| 6 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 21 +
drivers/net/wireless/ath/ath10k/mac.c| 4
drivers/net/wireless/ath/ath10k/wmi.h| 8
5 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 8a3020d..0fe98e9 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2307,6 +2307,10 @@ int ath10k_core_start(struct ath10k *ar, enum
ath10k_firmware_mode mode,
ar->wmi.svc_map))
val |= WMI_10_4_TDLS_UAPSD_BUFFER_STA;
+ if (test_bit(WMI_SERVICE_TX_DATA_ACK_RSSI,
+ar->wmi.svc_map))
+ val |= WMI_10_4_TX_DATA_ACK_RSSI;
+
status = ath10k_mac_ext_resource_config(ar, val);
if (status) {
ath10k_err(ar,
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 8cc2a8b..bd39d6b 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1,6 +1,7 @@
/*
* Copyright (c) 2005-2011 Atheros Communications Inc.
* Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -557,6 +558,8 @@ struct htt_mgmt_tx_completion {
#define HTT_RX_INDICATION_INFO1_NUM_MPDU_RANGES_MASK 0xFF00
#define HTT_RX_INDICATION_INFO1_NUM_MPDU_RANGES_LSB 24
+#define HTT_TX_CMPL_FLAG_DATA_RSSI BIT(0)
+
struct htt_rx_indication_hdr {
u8 info0; /* %HTT_RX_INDICATION_INFO0_ */
__le16 peer_id;
@@ -820,7 +823,7 @@ struct htt_data_tx_completion {
} __packed;
} __packed;
u8 num_msdus;
- u8 rsvd0;
+ u8 flags2; /* HTT_TX_CMPL_FLAG_DATA_RSSI */
__le16 msdus[0]; /* variable length based on %num_msdus */
} __packed;
@@ -1648,6 +1651,7 @@ struct htt_resp {
struct htt_tx_done {
u16 msdu_id;
u16 status;
+ u8 ack_rssi;
};
enum htt_tx_compl_state {
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 5e02e26..e16e818 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1882,6 +1882,8 @@ static void ath10k_htt_rx_tx_compl_ind(struct ath10k *ar,
int status = MS(resp->data_tx_completion.flags, HTT_DATA_TX_STATUS);
__le16 msdu_id;
int i;
+ bool rssi_enabled;
+ __le16 msdu_count;
switch (status) {
case HTT_DATA_TX_STATUS_NO_ACK:
@@ -1904,10 +1906,29 @@ static void ath10k_htt_rx_tx_compl_ind(struct ath10k
*ar,
ath10k_dbg(ar, ATH10K_DBG_HTT, "htt tx completion num_msdus %d\n",
resp->data_tx_completion.num_msdus);
+ if (resp->data_tx_completion.flags2 & HTT_TX_CMPL_FLAG_DATA_RSSI) {
+ rssi_enabled = true;
+ msdu_count = __le16_to_cpu(resp->data_tx_completion.num_msdus);
+ } else {
+ rssi_enabled = false;
+ }
+
for (i = 0; i < resp->data_tx_completion.num_msdus; i++) {
msdu_id = resp->data_tx_completion.msdus[i];
tx_done.msdu_id = __le16_to_cpu(msdu_id);
+ if (rssi_enabled) {
+ /* Total no of MSDUs should be even,
+* if odd MSDUs are sent firmware fills
+* last msdu id with 0x
+*/
+ if (msdu_count & 0x01)
+ tx_done.ack_rssi =
+ resp->data_tx_completion.msdus[msdu_count + i
+ 1];
+ else
+ tx_done.ack_rssi =
+ resp->data_tx_completion.msdus[msdu_count + i];
+ }
/* kfifo_put: In practice firmware shouldn't fire off per-CE
* interrupt and main interrupt (MSI/-X range case) for the same
* HTC service so it should be safe to use kfifo_put w/o lock.
diff --git a
Re: [PATCH v1 1/1] ath10k: convert kmemdup to dma_alloc_coherent
Jared Bents writes: > Update to convert the use of kmemdup to dma_alloc_coherent as > dma_alloc_coherent will consider DMA region limits such as > those seen with CONFIG_FSL_PCI && CONFIG_ZONE_DMA32 whereas > kmemdup does not take those limitations into account. > > Signed-off-by: Jared Bents Can you resend and CC linux-wireless, please? Otherwise patchwork won't see it and hence I won't see it either as I mostly work via patchwork. https://wireless.wiki.kernel.org/en/users/drivers/ath10k/submittingpatches -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/2] ath10k: support MAC address randomization in scan
cjhu...@codeaurora.org writes:
>>> + if (test_bit(WMI_SERVICE_SPOOF_MAC_SUPPORT, ar->wmi.svc_map)) {
>>> + ret = ath10k_wmi_scan_prob_req_oui(ar, ar->mac_addr);
>>> + if (ret) {
>>> + ath10k_err(ar, "failed to set prob req oui: %i\n", ret);
>>> + goto err_dfs_detector_exit;
>>> + }
>>> +
>>> + ar->hw->wiphy->features |=
>>> + NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;
>>
>> Do you support NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR too?
>
> I'll add this flag too.
Are you going to send v2 or what's the plan?
--
Kalle Valo
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: Please add new board files for WLE1216V5-20 and another Compex NIC.
Tim Harvey writes: > On Wed, Mar 21, 2018 at 2:59 PM, Ben Greear wrote: >> Hello, >> >> It seems the upstream board-2.bin file for 9984 does not yet include support >> for WLE1216V5-20 >> (or possibly it does and OpenWRT grabs the wrong one?). >> >> I'm attaching the board file for this NIC and for another one which >> I have not yet tested. I received these from Compex and have >> tested the bus=pci,bmi-chip-id=0,bmi-board-id=31-compex.bin file on the >> WLE1216V5-20 >> >> Please add these into the official board-2.bin for 9984. >> > > Kalle, > > Any progress on this? I believe your the one that has to update the > board-2.bin at > https://github.com/kvalo/ath10k-firmware/commits/master/QCA9984/hw1.0. This is on my queue but I don't update board files that often, due to lack of time. But I'll try to get to this request in the next few days. > It's not clear what the process is for getting new board id's > supported in the board.bin files. I think Sven already provided the link to the wiki page. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: Fix a typo in ath10k_wmi_set_wmm_param()
Hi All, Sorry for the inconvenience. Please ignore this duplicate patch. Please use the previous patch. On 2018-04-13 1:18 pm, mke...@codeaurora.org wrote: From: Maharaja Kennadyrajan Fix a typo in the function ath10k_wmi_set_wmm_param(). Signed-off-by: Maharaja Kennadyrajan --- drivers/net/wireless/ath/ath10k/wmi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index c5e1ca5..727c965 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -7648,7 +7648,7 @@ void ath10k_wmi_set_wmm_param(struct wmi_wmm_params *params, cmd->param = __cpu_to_le32(param); ath10k_dbg(ar, ATH10K_DBG_WMI, - "wmi pdev get tcp config param:%d\n", param); + "wmi pdev get tpc config param %d\n", param); return skb; } -- Regards, Maha ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: Fix a typo in ath10k_wmi_set_wmm_param()
From: Maharaja Kennadyrajan Fix a typo in the function ath10k_wmi_set_wmm_param(). Signed-off-by: Maharaja Kennadyrajan --- drivers/net/wireless/ath/ath10k/wmi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index c5e1ca5..727c965 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -7648,7 +7648,7 @@ void ath10k_wmi_set_wmm_param(struct wmi_wmm_params *params, cmd->param = __cpu_to_le32(param); ath10k_dbg(ar, ATH10K_DBG_WMI, - "wmi pdev get tcp config param:%d\n", param); + "wmi pdev get tpc config param %d\n", param); return skb; } -- 1.7.9.5 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] ath10k: Fix a typo in ath10k_wmi_set_wmm_param()
From: Maharaja Kennadyrajan Fix a typo in the function ath10k_wmi_set_wmm_param(). Signed-off-by: Maharaja Kennadyrajan --- drivers/net/wireless/ath/ath10k/wmi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c index c5e1ca5..727c965 100644 --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -7648,7 +7648,7 @@ void ath10k_wmi_set_wmm_param(struct wmi_wmm_params *params, cmd->param = __cpu_to_le32(param); ath10k_dbg(ar, ATH10K_DBG_WMI, - "wmi pdev get tcp config param:%d\n", param); + "wmi pdev get tpc config param %d\n", param); return skb; } -- 1.7.9.5 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
