Re: [next] ath10k: wmi: remove redundant integer fc
Colin Ian King wrote: > Variable fc is being assigned but never used, so remove it. Cleans > up the clang warning: > > warning: Value stored to 'fc' is never read > > Signed-off-by: Colin Ian King > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. a0709dfd7ff8 ath10k: wmi: remove redundant integer fc -- https://patchwork.kernel.org/patch/10119831/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: wil6210: fix build warnings without CONFIG_PM
Arnd Bergmann wrote:
> The #ifdef checks are hard to get right, in this case some functions
> should have been left inside a CONFIG_PM_SLEEP check as seen by this
> message:
>
> drivers/net/wireless/ath/wil6210/pcie_bus.c:489:12: error:
> 'wil6210_pm_resume' defined but not used [-Werror=unused-function]
> drivers/net/wireless/ath/wil6210/pcie_bus.c:484:12: error:
> 'wil6210_pm_suspend' defined but not used [-Werror=unused-function]
>
> Using an __maybe_unused is easier here, so I'm replacing all the
> other #ifdef in this file as well for consistency.
>
> Fixes: 94162666cd51 ("wil6210: run-time PM when interface down")
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
203dab8395d9 wil6210: fix build warnings without CONFIG_PM
--
https://patchwork.kernel.org/patch/10119565/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [01/10] ath10k: Add hw param for 64-bit address support
Govind Singh wrote: > WCN3990 target supports 37-bit addressing mode. In order > to accommodate extended address support, add hw param to > indicate if the target supports addressing above 32-bits. > > Signed-off-by: Rakesh Pillai > Signed-off-by: Govind Singh > Signed-off-by: Kalle Valo 10 patches applied to ath-next branch of ath.git, thanks. f13cc6bd68ba ath10k: Add hw param for 64-bit address support e3def6f7ddf8 ath10k: Update rx descriptor for WCN3990 target 3b0b55b19d1d ath10k: Add support for 64 bit HTT in-order indication msg 9abe68535ad8 ath10k: Add support for 64 bit htt rx ring cfg 71ad70961093 ath10k: Add support for 64 bit HTT frag descriptor e62ee5c381c5 ath10k: Add support for htt_data_tx_desc_64 descriptor bb8d0d15fc6a ath10k: Add hw param for rx ring size support a91a626baa15 ath10k: Add paddrs_ring_64 support for 64bit target 5dac5f3772f6 ath10k: Use dma_addr_t for ce buffers to support 64bit target 2a1e1ad3fd37 ath10k: Add support for 64 bit ce descriptor -- https://patchwork.kernel.org/patch/10127165/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v2,1/3] ath10k: Add SNOC bus type for WCN3990 target
Rakesh Pillai wrote: > WCN3990 is integrated chipset which uses system NOC. > Add SNOC bus type and related definitions. > > Signed-off-by: Govind Singh > Signed-off-by: Rakesh Pillai > Signed-off-by: Kalle Valo 3 patches applied to ath-next branch of ath.git, thanks. 63855e3d6e7a ath10k: Add SNOC bus type for WCN3990 target b796240409b3 ath10k: Add debug mask for SNOC bus type 71e9c29fbd28 ath10k: Add fw feature flag for non-bmi firmware load -- https://patchwork.kernel.org/patch/10127929/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: You will definetely be interested...
Hi Dear, Reading your profile has given me courage in search of a reasponsable and trust worthy Fellow. The past has treated me so awfully but now I am ready to move on despite of my health condition. I will like to have a sincere and important discussion with you that will be in your favor likewise to you and your environment especially to your close family. Endeavor to reply me and I have attached my picture in case you long to know who emailed you. I will be waiting to hear from you as soon as possble. Thanks for paying attention to my mail and will appreciate so much if I receive a reply from you for understable details. Thanks, Mrs. Rania Hassan
Re: ath10k: advertising tdls wider bandwidth support for 5GHz
bpoth...@qti.qualcomm.com wrote: > Enable TDLS wider bandwidth support for 5GHz based on firmware wmi > capabilities. > > This patch is required for chipset QCA9888. Tested with firmware version > 10.4-3.5.1-00018. > > Signed-off-by: Balaji Pothunoori > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 14d65775687c ath10k: advertise TDLS wider bandwidth support for 5GHz -- https://patchwork.kernel.org/patch/10127717/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v2,1/6] ath10k: remove deprecated fw_crash_dump debugfs file
Kalle Valo wrote:
> The fw_crash_dump file was deprecated by commmit 727000e6af34 ("ath10k:
> support
> dev_coredump for crash dump") in v4.11 in favor of dev_coredump interface,
> remove it now for good. Everyone should use dev_coredump now.
>
> Signed-off-by: Kalle Valo
6 patches applied to ath-next branch of ath.git, thanks.
d333bdd9b065 ath10k: remove deprecated fw_crash_dump debugfs file
f25b9f285a0e ath10k: refactor firmware crashdump code to coredump.c
e2fcf60c6fe8 ath10k: detach coredump.c from debug.c
5c9d0a20202b ath10k: add coredump_mask module parameter
703f261dd77f ath10k: add memory dump support for QCA6174/QCA9377
1a8e5c618bfa ath10k: add memory dump support QCA988X
--
https://patchwork.kernel.org/patch/10130491/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath10k: update copyright year
Kalle Valo wrote: > Update year for Qualcomm Atheros, Inc. copyrights. > > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 8b1083d61882 ath10k: update copyright year -- https://patchwork.kernel.org/patch/10130915/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 03/11] ath10k_sdio: DMA bounce buffers for read write
On 12/25/2017 1:26 PM, Alagu Sankar wrote: On 2017-12-22 21:38, Kalle Valo wrote: silexcom...@gmail.com writes: From: Alagu Sankar Some SD host controllers still need bounce buffers for SDIO data transfers. While the transfers worked fine on x86 platforms, this is found to be required for i.MX6 based systems. Changes are similar to and derived from the ath6kl sdio driver. Signed-off-by: Alagu Sankar Why is the bounce buffer needed exactly, what are the symptoms etc? To me this sounds like an ugly workaround for a SDIO controller driver bug. We faced problems with i.MX6. The authentication frame sent by the driver never reached the air. The host driver accepted the buffer, but did not send out the packet to the sdio module. No errors reported anywhere, but the buffer is not accepted due to alignment. The same driver however works fine without bounce buffer on x86 platform with stdhci drivers. To make it compliant with all host controllers, we introduced the bounce buffers, similar to what was done in ath6kl_sdio drivers. As mentioned by Adrian the comment from Kalle is that you are solving an issue caused by the sdio host controller. Although strictly speaking it may not be a driver bug, but a requirement of the host controller hardware. Either way it seems the obvious place to solve this is in the sdio host controller driver to which the issue applies. Or make it a generic quirk which can be enabled for sdio host controller drivers that need it. However, there may reasons to do it in the networking driver. For instance, the buffer you want to transfer might be the data buffer of an sk_buff you got from the networking stack and you want to have a zero-copy solution towards the wireless device. Your solution checks for 4-byte alignment which is a requirement for ADMA as per SDIO spec. However, I have come across host controllers which have different alignment requirements. Also when CONFIG_ARCH_DMA_ADDR_T_64BIT is enabled the alignment changes from 4 to 8 bytes. So it seems you are solving a specific case you have come across, but you may want to design for more flexibility. Hope this helps. Regards, Arend
Re: [PATCH 03/11] ath10k_sdio: DMA bounce buffers for read write
[top post for emphasis] Arend is right. You won't be the only driver which has issues with a controller that doesn't handle non-aligned data payloads. Please push it into the stack or the controller side, but not in the driver side. That'll be a forever game of whack-a-mole. -adrian (I'm living this dream right now and it's unfun) On 27 December 2017 at 10:49, Arend van Spriel wrote: > On 12/25/2017 1:26 PM, Alagu Sankar wrote: >> >> On 2017-12-22 21:38, Kalle Valo wrote: >>> >>> silexcom...@gmail.com writes: >>> From: Alagu Sankar Some SD host controllers still need bounce buffers for SDIO data transfers. While the transfers worked fine on x86 platforms, this is found to be required for i.MX6 based systems. Changes are similar to and derived from the ath6kl sdio driver. Signed-off-by: Alagu Sankar >>> >>> >>> Why is the bounce buffer needed exactly, what are the symptoms etc? To >>> me this sounds like an ugly workaround for a SDIO controller driver bug. >> >> >> We faced problems with i.MX6. The authentication frame sent by the >> driver never reached the air. The host driver accepted the buffer, but >> did not send out the packet to the sdio module. No errors reported >> anywhere, but the buffer is not accepted due to alignment. The same >> driver however works fine without bounce buffer on x86 platform with >> stdhci drivers. To make it compliant with all host controllers, we >> introduced the bounce buffers, similar to what was done in ath6kl_sdio >> drivers. > > > As mentioned by Adrian the comment from Kalle is that you are solving an > issue caused by the sdio host controller. Although strictly speaking it may > not be a driver bug, but a requirement of the host controller hardware. > Either way it seems the obvious place to solve this is in the sdio host > controller driver to which the issue applies. Or make it a generic quirk > which can be enabled for sdio host controller drivers that need it. However, > there may reasons to do it in the networking driver. For instance, the > buffer you want to transfer might be the data buffer of an sk_buff you got > from the networking stack and you want to have a zero-copy solution towards > the wireless device. > > Your solution checks for 4-byte alignment which is a requirement for ADMA as > per SDIO spec. However, I have come across host controllers which have > different alignment requirements. Also when CONFIG_ARCH_DMA_ADDR_T_64BIT is > enabled the alignment changes from 4 to 8 bytes. So it seems you are solving > a specific case you have come across, but you may want to design for more > flexibility. > > Hope this helps. > > Regards, > Arend
[PATCH] ath10k: add sanity check to ie_len before parsing fw/board ie
From: Ryan Hsu
Validate ie_len after the alignment padding before access the buffer
to avoid potential overflow.
Signed-off-by: Ryan Hsu
---
drivers/net/wireless/ath/ath10k/core.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 042175a..2f24c17 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1240,7 +1240,10 @@ static int ath10k_core_fetch_board_data_api_n(struct
ath10k *ar,
len -= sizeof(*hdr);
data = hdr->data;
- if (len < ALIGN(ie_len, 4)) {
+ /* jump over the padding */
+ ie_len = ALIGN(ie_len, 4);
+
+ if (len < ie_len) {
ath10k_err(ar, "invalid length for board ie_id %d
ie_len %zu len %zu\n",
ie_id, ie_len, len);
ret = -EINVAL;
@@ -1279,8 +1282,6 @@ static int ath10k_core_fetch_board_data_api_n(struct
ath10k *ar,
goto out;
}
- /* jump over the padding */
- ie_len = ALIGN(ie_len, 4);
len -= ie_len;
data += ie_len;
@@ -1412,6 +1413,9 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar,
const char *name,
len -= sizeof(*hdr);
data += sizeof(*hdr);
+ /* jump over the padding */
+ ie_len = ALIGN(ie_len, 4);
+
if (len < ie_len) {
ath10k_err(ar, "invalid length for FW IE %d (%zu <
%zu)\n",
ie_id, len, ie_len);
@@ -1517,9 +1521,6 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k *ar,
const char *name,
break;
}
- /* jump over the padding */
- ie_len = ALIGN(ie_len, 4);
-
len -= ie_len;
data += ie_len;
}
--
1.9.1
