Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
On Wed, Jul 27, 2016 at 08:26:48PM -0400, alexmcwhir...@triadic.us wrote: > I'm going to go ahead and say this is where my issue and the op's issue > begin to branch apart from one another. He's seeing this on all incoming > data, whereas i am only seeing it on ssl data and not on sun4v. > > At this point i would say data from my issue is only going to cloud this > issue as they seem to be two completely different issues revolving around > the same commit. If i come across any relevant data for x86_64 ill be sure > to post it if this isn't resolved by then, but for now i'm going to refrain > from submitting anything sparc related. Which just might mean that we have *three* issues here - (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs (2) your ssl-only corruption (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc anywhere, and no multi-segment recvmsg(). Which would strongly argue in favour of some kind of copy_page_to_iter() breakage triggered when handling a fragmented skb, as in (1). Except that I don't see anything similar in x86_64 uaccess primitives... -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
On 2016-07-27 20:31, Al Viro wrote: On Wed, Jul 27, 2016 at 04:45:43PM -0700, David Miller wrote: > I highly expect both my issue and OP's issue to revolve not around > commit e5a4b0bb803b specifically, but around other code that no longer > behaves as expected because of it. Indeed, and that fault address rounding bug occurs two other times in arch/sparc/lib/user_fixup.c The mentioned patchwork patch should fix the bug and I'll get that into my sparc tree, merged, and queued up for -stable ASAP. Plausible for sparc, but I don't see similar __copy_to_user_inatomic() bugs in case of x86_64... I'm going to go ahead and say this is where my issue and the op's issue begin to branch apart from one another. He's seeing this on all incoming data, whereas i am only seeing it on ssl data and not on sun4v. At this point i would say data from my issue is only going to cloud this issue as they seem to be two completely different issues revolving around the same commit. If i come across any relevant data for x86_64 ill be sure to post it if this isn't resolved by then, but for now i'm going to refrain from submitting anything sparc related. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
On Wed, Jul 27, 2016 at 04:45:43PM -0700, David Miller wrote: > > I highly expect both my issue and OP's issue to revolve not around > > commit e5a4b0bb803b specifically, but around other code that no longer > > behaves as expected because of it. > > Indeed, and that fault address rounding bug occurs two other times > in arch/sparc/lib/user_fixup.c > > The mentioned patchwork patch should fix the bug and I'll get that > into my sparc tree, merged, and queued up for -stable ASAP. Plausible for sparc, but I don't see similar __copy_to_user_inatomic() bugs in case of x86_64... -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
From: alexmcwhir...@triadic.us Date: Wed, 27 Jul 2016 19:02:40 -0400 > On 2016-07-27 14:04, alexmcwhir...@triadic.us wrote: >> Just to add some more information to this, the corruption seems to >> effect ssh as well. >> Using a sun hme interface, occasionally upon an ssh connection it will >> refuse to authenticate a client with either password or cert >> authentication. Using wireshark to capture and decrypt the packets >> between the two machines, the data coming from the server seems good, >> but the data received by the server from the client is essentially >> garbage. Note that the client is sending valid data, but the server is >> corrupting it upon receipt. Closing the connection and starting a new >> one will remedy the login issue, but you do occasionally see >> corruption on the server side sporadically. >> So far this only seems to occur on incoming data, outgoing data seems >> fine. > > Also, there is another patch the references this commit on sparc64 at > least. > > https://patchwork.kernel.org/patch/9221895/ > > I highly expect both my issue and OP's issue to revolve not around > commit e5a4b0bb803b specifically, but around other code that no longer > behaves as expected because of it. Indeed, and that fault address rounding bug occurs two other times in arch/sparc/lib/user_fixup.c The mentioned patchwork patch should fix the bug and I'll get that into my sparc tree, merged, and queued up for -stable ASAP. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
On 2016-07-27 14:04, alexmcwhir...@triadic.us wrote: Just to add some more information to this, the corruption seems to effect ssh as well. Using a sun hme interface, occasionally upon an ssh connection it will refuse to authenticate a client with either password or cert authentication. Using wireshark to capture and decrypt the packets between the two machines, the data coming from the server seems good, but the data received by the server from the client is essentially garbage. Note that the client is sending valid data, but the server is corrupting it upon receipt. Closing the connection and starting a new one will remedy the login issue, but you do occasionally see corruption on the server side sporadically. So far this only seems to occur on incoming data, outgoing data seems fine. Also, there is another patch the references this commit on sparc64 at least. https://patchwork.kernel.org/patch/9221895/ I highly expect both my issue and OP's issue to revolve not around commit e5a4b0bb803b specifically, but around other code that no longer behaves as expected because of it. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcm4330 fails to load on newer kernels
Hi Arend, On Wed, Jul 27, 2016 at 5:51 PM, Arend van Spriel wrote: > On 27-07-16 00:35, Fabio Estevam wrote: >> Hi, >> >> On a imx6sl-warp board with a brcm4330 I get the following results >> depending on the kernel version: >> >> - Kernel 4.4.15: place brcmfmac4330-sdio.bin and brcmfmac4330-sdio.txt >> in the rootfs and the kernel is able to read them correctly. wlan0 is >> present. All is fine. >> >> - Kernel 4.5.7: place brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt in >> the rootfs and the kernel fails to load them: >> >> brcmfmac mmc1:0001:1: Direct firmware load for >> brcm/brcmfmac4330-sdio.bin failed with error -2 >> >> Then I build brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt into the >> kernel and then firmware is detected and wlan0 appears. >> >> - Kernel 4.7: I can place the firmware and nvram file into the rootfs >> or built-i and the following error is seen: >> >> brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 >> brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 >> brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 >> >> So wlan0 never appears here. >> >> Does anyone have any suggestions about these different behaviours? > > So for all kernel you have brcmfmac built-in the kernel or as a module? In all these tests I have brcmfmac built-in the kernel. Thanks, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: brcm4330 fails to load on newer kernels
On 27-07-16 00:35, Fabio Estevam wrote: > Hi, > > On a imx6sl-warp board with a brcm4330 I get the following results > depending on the kernel version: > > - Kernel 4.4.15: place brcmfmac4330-sdio.bin and brcmfmac4330-sdio.txt > in the rootfs and the kernel is able to read them correctly. wlan0 is > present. All is fine. > > - Kernel 4.5.7: place brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt in > the rootfs and the kernel fails to load them: > > brcmfmac mmc1:0001:1: Direct firmware load for > brcm/brcmfmac4330-sdio.bin failed with error -2 > > Then I build brcmfmac4330-sdio.bin brcmfmac4330-sdio.txt into the > kernel and then firmware is detected and wlan0 appears. > > - Kernel 4.7: I can place the firmware and nvram file into the rootfs > or built-i and the following error is seen: > > brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 > brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 > brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50 > > So wlan0 never appears here. > > Does anyone have any suggestions about these different behaviours? So for all kernel you have brcmfmac built-in the kernel or as a module? Regards, Arend > Thanks, > > Fabio Estevam > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
Just to add some more information to this, the corruption seems to effect ssh as well. Using a sun hme interface, occasionally upon an ssh connection it will refuse to authenticate a client with either password or cert authentication. Using wireshark to capture and decrypt the packets between the two machines, the data coming from the server seems good, but the data received by the server from the client is essentially garbage. Note that the client is sending valid data, but the server is corrupting it upon receipt. Closing the connection and starting a new one will remedy the login issue, but you do occasionally see corruption on the server side sporadically. So far this only seems to occur on incoming data, outgoing data seems fine. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP performance regression in mac80211 triggered by the fq code
Michal Kazior writes:
> On 20 July 2016 at 17:24, Toke Høiland-Jørgensen wrote:
>> Toke Høiland-Jørgensen writes:
>>
>>> Felix Fietkau writes:
>>>
- if I put a hack in the fq code to force the hash to a constant value
(effectively disabling fq without disabling codel), the problem
disappears and even multiple streams get proper performance.
>>>
>>> There's definitely something iffy about the hashing. Here's the output
>>> relevant line from the aqm debug file after running a single TCP stream
>>> for 60 seconds to that station:
>>>
>>> ifname addr tid ac backlog-bytes backlog-packets flows drops marks
>>> overlimit collisions
>>> tx-bytes tx-packets
>>> wlp2s0 04:f0:21:1e:74:20 0 2 0 0 146 16 0 0 0 717758966 467925
>>>
>>> (there are two extra fields here; I added per-txq CoDel stats, will send
>>> a patch later).
>>>
>>> This shows that the txq has 146 flows associated from that one TCP flow.
>>> Looking at this over time, it seems that each time the queue runs empty
>>> (which happens way too often, which is what I was originally
>>> investigating), another flow is assigned.
>>>
>>> Michal, any idea why? :)
>>
>> And to answer this: because the flow is being freed to be reassigned
>> when it runs empty, but the counter is not decremented. Is this
>> deliberate? I.e. is the 'flows' var supposed to be a total 'new_flows'
>> counter and not a measure of the current number of assigned flows?
>
> Yes, it is deliberate. fq_codel qdisc does the same thing and I just
> mimicked it.
Right. Think it was the name that sent me down the wrong track ('flows'
instead of 'new_flows'). Especially since the way you structured things,
having a counter for how many flows are currently assigned each tid
might actually make sense...
-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Allow setting coverage class
On 07/27/2016 01:33 AM, Benjamin Berg wrote: Unfortunately ath10k does not generally allow modifying the coverage class with the stock firmware and Qualcomm has so far refused to implement this feature so that it can be properly supported in ath10k. If we however know the registers that need to be modified for proper operation with a higher coverage class, then we can do these modifications from the driver. This patch implements this hack for first generation cards which are based on a core that is similar to ath9k. The registers are modified in place and need to be re-written every time the firmware sets them. To achieve this the register status is verified after any event from the firmware. The coverage class may not be modified temporarily right after the card re-initializes the registers. This is for example the case during scanning. A warning will be generated if the hack is not supported on the card or unexpected values are hit. There is no error reporting for userspace applications though (this is a limitation in the mac80211 driver interface). Thanks to Sebastian Gottschall for initially working on a userspace support for this. This patch wouldn't have been possible without this documentation. I would be concerned about the various resets firmware does to work around hardware hangs as well. I don't think any events are generated for these, unless you count the dbglog messages? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3] UCC_GETH/UCC_FAST: Use IS_ERR_VALUE_U32 API to avoid IS_ERR_VALUE abuses.
I am also agree with Arnd Bergmann. We should use 'static inline function'
instead of macro to deal with error check.
On Tuesday 26 July 2016 05:09 PM, Arnd Bergmann wrote:
On Saturday, July 23, 2016 11:35:51 PM CEST Arvind Yadav wrote:
diff --git a/include/linux/err.h b/include/linux/err.h
index 1e35588..a42f942 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -19,6 +19,7 @@
#ifndef __ASSEMBLY__
#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
+#define IS_ERR_VALUE_U32(x) unlikely((unsigned int)(x) >= (unsigned
int)-MAX_ERRNO)
static inline void * __must_check ERR_PTR(long error)
{
This doesn't really look like something we want to have as a generic
interface. The IS_ERR_VALUE() API is rather awkward already, and your
use seems specific to the cpu_muram_alloc() function.
How about something like
int cpm_muram_error(unsigned long addr)
{
if (addr >= (unsigned long)-MAX_ERRNO)
return addr;
else
return 0;
}
and then use that to check the value returned by the allocation
that is still an 'unsigned long', before assigning it to a 'u32'.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: Remove driver log suggesting QCA9887 support is experimental
From: Mohammed Shafi Shajakhan Support for QCA9887 is no longer experimental and if there are any issues we need to address them Signed-off-by: Mohammed Shafi Shajakhan --- drivers/net/wireless/ath/ath10k/pci.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c index f06dd39..f3d943c 100644 --- a/drivers/net/wireless/ath/ath10k/pci.c +++ b/drivers/net/wireless/ath/ath10k/pci.c @@ -3144,7 +3144,6 @@ static int ath10k_pci_probe(struct pci_dev *pdev, pci_hard_reset = ath10k_pci_qca988x_chip_reset; break; case QCA9887_1_0_DEVICE_ID: - dev_warn(&pdev->dev, "QCA9887 support is still experimental, there are likely bugs. You have been warned.\n"); hw_rev = ATH10K_HW_QCA9887; pci_ps = false; pci_soft_reset = ath10k_pci_warm_reset; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] rtl8xxxu: gen1: Fix non static symbol warning
weiyj...@163.com writes: > From: Wei Yongjun > > Fixes the following sparse warning: > > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1: warning: > symbol 'rtl8xxxu_gen1_h2c_cmd' was not declared. Should it be static? > > Signed-off-by: Wei Yongjun > --- > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Looks reasonable - I'll apply it to my tree. Thanks, Jes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1 V3] ath9k: consider return code on ar9300_eeprom_restore_flash
Hi Kale, Just added the two error codes you asked: https://lists.ath9k.org/pipermail/ath9k-devel/2016-July/014686.html Thanks. Eduardo Abinader (1): ath9k: consider return code on ar9300_eeprom_restore_flash drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1 V3] ath9k: consider return code on
just to comply with current ath9k_hw_nvram_read to return value, hence
behaving reacting accordingly.
Signed-off-by: Eduardo Abinader
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 5bd2cba..08607d7 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3252,7 +3252,8 @@ static int ar9300_eeprom_restore_flash(struct ath_hw *ah,
u8 *mptr,
int i;
for (i = 0; i < mdata_size / 2; i++, data++)
- ath9k_hw_nvram_read(ah, i, data);
+ if (!ath9k_hw_nvram_read(ah, i, data))
+ return -EIO;
return 0;
}
@@ -3282,7 +3283,8 @@ static int ar9300_eeprom_restore_internal(struct ath_hw
*ah,
if (ath9k_hw_use_flash(ah)) {
u8 txrx;
- ar9300_eeprom_restore_flash(ah, mptr, mdata_size);
+ if (ar9300_eeprom_restore_flash(ah, mptr, mdata_size))
+ return -EIO;
/* check if eeprom contains valid data */
eep = (struct ar9300_eeprom *) mptr;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
On 27 July 2016 at 14:59, Thiagarajan, Vasanthakumar
wrote:
> On Wednesday 27 July 2016 06:13 PM, Michal Kazior wrote:
>> On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan
[...]
>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>> @@ -68,6 +68,7 @@ static const struct ath10k_hw_params
>>> ath10k_hw_params_list[] = {
>>> .board_size = QCA988X_BOARD_DATA_SZ,
>>> .board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
>>> },
>>> + .hw_rx_desc_ops = &qca988x_rx_desc_ops,
>> [...]
>>> +struct ath10k_hw_rx_desc_ops {
>>> + int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
>>> +};
>>
>> Benjamin is trying to implement coverage class by poking hw registers
>> over firmware's head [1]. I'm thinking the hw_rx_desc_ops could be
>> generalized to hw_ops so it can be used for doing hw-specific hacks as
>> well. What do you think?
>
> Sure. Instead of reworking this patch set, can this be done in a separate
> patch?.
I don't really mind especially since there's not much comments on his work yet.
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
On Wednesday 27 July 2016 06:13 PM, Michal Kazior wrote:
> On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan
> wrote:
>> There are slight differences in Rx hw descriptor information
>> among different chips. So far driver does not use those new
>> information for any functionalities, but there is one important
>> information which is available from QCA99X0 onwards to indicate
>> the number of bytes that hw padded at the begining of the rx
>> payload and this information is needed to undecap the rx
>> packet. Add an abstraction for Rx desc to make use of the
>> new desc information available. The callback that this patch
>> defines to retrieve the padding bytes will be used in follow-up
>> patch.
>>
>> Signed-off-by: Vasanthakumar Thiagarajan
>> ---
>> drivers/net/wireless/ath/ath10k/core.c | 12
>> drivers/net/wireless/ath/ath10k/hw.c | 13 +
>> drivers/net/wireless/ath/ath10k/hw.h | 12
>> 3 files changed, 37 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.c
>> b/drivers/net/wireless/ath/ath10k/core.c
>> index e889829..9c5e93b 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.c
>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>> @@ -68,6 +68,7 @@ static const struct ath10k_hw_params
>> ath10k_hw_params_list[] = {
>> .board_size = QCA988X_BOARD_DATA_SZ,
>> .board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
>> },
>> + .hw_rx_desc_ops = &qca988x_rx_desc_ops,
> [...]
>> +struct ath10k_hw_rx_desc_ops {
>> + int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
>> +};
>
> Benjamin is trying to implement coverage class by poking hw registers
> over firmware's head [1]. I'm thinking the hw_rx_desc_ops could be
> generalized to hw_ops so it can be used for doing hw-specific hacks as
> well. What do you think?
Sure. Instead of reworking this patch set, can this be done in a separate
patch?.
Vasanth
[PATCH] ath10k: Fix rfc1042 header retrieval in QCA4019 with eth decap mode
Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
rx_hdr_status is not padded to align in 4-byte boundary. Define a
new hw_params field to handle different alignment behaviour between
different hw. This patch fixes improper retrieval of rfc1042 header
with QCA4019. This patch along with "ath10k: Properly remove padding
from the start of rx payload" will fix traffic failure in ethernet
decap mode for QCA4019.
Signed-off-by: Vasanthakumar Thiagarajan
---
drivers/net/wireless/ath/ath10k/core.c | 12
drivers/net/wireless/ath/ath10k/htt_rx.c | 5 +++--
drivers/net/wireless/ath/ath10k/hw.h | 3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 74d0ace..ea6a8f4 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -68,6 +68,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA9887_HW_1_0_VERSION,
@@ -87,6 +88,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.board_ext_size = QCA9887_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -105,6 +107,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -123,6 +126,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_3_0_VERSION,
@@ -141,6 +145,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA6174_HW_3_2_VERSION,
@@ -160,6 +165,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -183,6 +189,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+ .decap_align_bytes = 1,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -206,6 +213,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+ .decap_align_bytes = 1,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -228,6 +236,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+ .decap_align_bytes = 1,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -246,6 +255,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -264,6 +274,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca988x_rx_desc_ops,
+ .decap_align_bytes = 4,
},
{
.id = QCA4019_HW_1_0_DEV_VERSION,
@@ -288,6 +299,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
},
.hw_rx_desc_ops = &qca99x0_rx_desc_ops,
+ .decap_align_bytes = 1,
},
};
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/at
[PATCH 3/4] ath10k: Properly remove padding from the start of rx payload
In QCA99X0 (QCA99X0, QCA9984, QCA9888 and QCA4019) family chips,
hw adds padding at the begining of the rx payload to make L3
header 4-byte aligned. In the chips doing this type of padding,
the number of bytes padded will be indicated through msdu_end:info1.
Define a hw_rx_desc_ops wrapper to retrieve the number of padded
bytes and use this while doing undecap. This should fix padding
related issues with ethernt decap format with QCA99X0, QCA9984,
QCA9888 and QCA4019 hw.
Signed-off-by: Vasanthakumar Thiagarajan
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 36 +++-
drivers/net/wireless/ath/ath10k/hw.h | 9
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 78db5d6..36c4809 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1056,9 +1056,11 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k
*ar,
const u8 first_hdr[64])
{
struct ieee80211_hdr *hdr;
+ struct htt_rx_desc *rxd;
size_t hdr_len;
u8 da[ETH_ALEN];
u8 sa[ETH_ALEN];
+ int l3_pad_bytes;
/* Delivered decapped frame:
* [nwifi 802.11 header] <-- replaced with 802.11 hdr
@@ -1072,19 +1074,12 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k
*ar,
*/
/* pull decapped header and copy SA & DA */
- if ((ar->hw_params.hw_4addr_pad == ATH10K_HW_4ADDR_PAD_BEFORE) &&
- ieee80211_has_a4(((struct ieee80211_hdr
*)first_hdr)->frame_control)) {
- /* The QCA99X0 4 address mode pad 2 bytes at the
-* beginning of MSDU
-*/
- hdr = (struct ieee80211_hdr *)(msdu->data + 2);
- /* The skb length need be extended 2 as the 2 bytes at the tail
-* be excluded due to the padding
-*/
- skb_put(msdu, 2);
- } else {
- hdr = (struct ieee80211_hdr *)(msdu->data);
- }
+ rxd = (void *)msdu->data - sizeof(*rxd);
+
+ l3_pad_bytes = ath10k_rx_desc_get_l3_pad_bytes(&ar->hw_params, rxd);
+ skb_put(msdu, l3_pad_bytes);
+
+ hdr = (struct ieee80211_hdr *)(msdu->data + l3_pad_bytes);
hdr_len = ath10k_htt_rx_nwifi_hdrlen(ar, hdr);
ether_addr_copy(da, ieee80211_get_DA(hdr));
@@ -1151,6 +1146,8 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k *ar,
void *rfc1042;
u8 da[ETH_ALEN];
u8 sa[ETH_ALEN];
+ int l3_pad_bytes;
+ struct htt_rx_desc *rxd;
/* Delivered decapped frame:
* [eth header] <-- replaced with 802.11 hdr & rfc1042/llc
@@ -1161,6 +1158,11 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k
*ar,
if (WARN_ON_ONCE(!rfc1042))
return;
+ rxd = (void *)msdu->data - sizeof(*rxd);
+ l3_pad_bytes = ath10k_rx_desc_get_l3_pad_bytes(&ar->hw_params, rxd);
+ skb_put(msdu, l3_pad_bytes);
+ skb_pull(msdu, l3_pad_bytes);
+
/* pull decapped header and copy SA & DA */
eth = (struct ethhdr *)msdu->data;
ether_addr_copy(da, eth->h_dest);
@@ -1191,6 +1193,8 @@ static void ath10k_htt_rx_h_undecap_snap(struct ath10k
*ar,
{
struct ieee80211_hdr *hdr;
size_t hdr_len;
+ int l3_pad_bytes;
+ struct htt_rx_desc *rxd;
/* Delivered decapped frame:
* [amsdu header] <-- replaced with 802.11 hdr
@@ -1198,7 +1202,11 @@ static void ath10k_htt_rx_h_undecap_snap(struct ath10k
*ar,
* [payload]
*/
- skb_pull(msdu, sizeof(struct amsdu_subframe_hdr));
+ rxd = (void *)msdu->data - sizeof(*rxd);
+ l3_pad_bytes = ath10k_rx_desc_get_l3_pad_bytes(&ar->hw_params, rxd);
+
+ skb_put(msdu, l3_pad_bytes);
+ skb_pull(msdu, sizeof(struct amsdu_subframe_hdr) + l3_pad_bytes);
hdr = (struct ieee80211_hdr *)first_hdr;
hdr_len = ieee80211_hdrlen(hdr->frame_control);
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index a281544..cdd2ce4 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -423,6 +423,15 @@ struct ath10k_hw_rx_desc_ops {
extern const struct ath10k_hw_rx_desc_ops qca988x_rx_desc_ops;
extern const struct ath10k_hw_rx_desc_ops qca99x0_rx_desc_ops;
+static inline int
+ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
+ struct htt_rx_desc *rxd)
+{
+ if (hw->hw_rx_desc_ops->rx_desc_get_l3_pad_bytes)
+ return hw->hw_rx_desc_ops->rx_desc_get_l3_pad_bytes(rxd);
+ return 0;
+}
+
/* Target specific defines for MAIN firmware */
#define TARGET_NUM_VDEVS 8
#define TARGET_NUM_PEER_AST2
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
On 27 July 2016 at 14:36, Vasanthakumar Thiagarajan
wrote:
> There are slight differences in Rx hw descriptor information
> among different chips. So far driver does not use those new
> information for any functionalities, but there is one important
> information which is available from QCA99X0 onwards to indicate
> the number of bytes that hw padded at the begining of the rx
> payload and this information is needed to undecap the rx
> packet. Add an abstraction for Rx desc to make use of the
> new desc information available. The callback that this patch
> defines to retrieve the padding bytes will be used in follow-up
> patch.
>
> Signed-off-by: Vasanthakumar Thiagarajan
> ---
> drivers/net/wireless/ath/ath10k/core.c | 12
> drivers/net/wireless/ath/ath10k/hw.c | 13 +
> drivers/net/wireless/ath/ath10k/hw.h | 12
> 3 files changed, 37 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c
> b/drivers/net/wireless/ath/ath10k/core.c
> index e889829..9c5e93b 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -68,6 +68,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> .board_size = QCA988X_BOARD_DATA_SZ,
> .board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
> },
> + .hw_rx_desc_ops = &qca988x_rx_desc_ops,
[...]
> +struct ath10k_hw_rx_desc_ops {
> + int (*rx_desc_get_l3_pad_bytes)(struct htt_rx_desc *rxd);
> +};
Benjamin is trying to implement coverage class by poking hw registers
over firmware's head [1]. I'm thinking the hw_rx_desc_ops could be
generalized to hw_ops so it can be used for doing hw-specific hacks as
well. What do you think?
[1]: http://lists.infradead.org/pipermail/ath10k/2016-July/008107.html
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ath10k: Remove 4-addr padding related hw_param configuration
hw_4addr_pad was added to handle different types of padding
in 4-address rx frame. But this padding is not very specific
to 4-address, it can happen even with three address + ethernet
decap mode. Since the padding information can be obtained
through Rx desc for QCA99X0 and newer chips, this hw_param
is not needed any more.
Signed-off-by: Vasanthakumar Thiagarajan
---
drivers/net/wireless/ath/ath10k/core.c | 9 -
drivers/net/wireless/ath/ath10k/hw.h | 8
2 files changed, 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 9c5e93b..74d0ace 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -60,7 +60,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
.cal_data_len = 2116,
.fw = {
.dir = QCA988X_HW_2_0_FW_DIR,
@@ -80,7 +79,6 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
.cal_data_len = 2116,
.fw = {
.dir = QCA9887_HW_1_0_FW_DIR,
@@ -117,7 +115,6 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
.cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_2_1_FW_DIR,
@@ -136,7 +133,6 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
.cal_data_len = 8124,
.fw = {
.dir = QCA6174_HW_3_0_FW_DIR,
@@ -155,7 +151,6 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.otp_exe_param = 0,
.channel_counters_freq_hz = 88000,
.max_probe_resp_desc_thres = 0,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_AFTER,
.cal_data_len = 8124,
.fw = {
/* uses same binaries as hw3.0 */
@@ -177,7 +172,6 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
.tx_chain_mask = 0xf,
.rx_chain_mask = 0xf,
.max_spatial_stream = 4,
@@ -201,7 +195,6 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
.tx_chain_mask = 0xf,
.rx_chain_mask = 0xf,
.max_spatial_stream = 4,
@@ -224,7 +217,6 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.continuous_frag_desc = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
.tx_chain_mask = 3,
.rx_chain_mask = 3,
.max_spatial_stream = 2,
@@ -285,7 +277,6 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 125000,
.max_probe_resp_desc_thres = 24,
- .hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
.tx_chain_mask = 0x3,
.rx_chain_mask = 0x3,
.max_spatial_stream = 2,
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index cdd2ce4..1620e76 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -338,11 +338,6 @@ enum ath10k_hw_rate_rev2_cck {
ATH10K_HW_RATE_REV2_CCK_SP_11M,
};
-enum ath10k_hw_4addr_pad {
- ATH10K_HW_4ADDR_PAD_AFTER,
- ATH10K_HW_4ADDR_PAD_BEFORE,
-};
-
enum ath10k_hw_cc_wraparound_type {
ATH10K_HW_CC_WRAP_DISABLED = 0,
@@ -395,9 +390,6 @@ struct ath10k_hw_params {
*/
u32 max_probe_resp_desc_thres;
- /* The padding bytes's location is different on various chips */
-
[PATCH 2/4] ath10k: Add provision for Rx descriptor abstraction
There are slight differences in Rx hw descriptor information
among different chips. So far driver does not use those new
information for any functionalities, but there is one important
information which is available from QCA99X0 onwards to indicate
the number of bytes that hw padded at the begining of the rx
payload and this information is needed to undecap the rx
packet. Add an abstraction for Rx desc to make use of the
new desc information available. The callback that this patch
defines to retrieve the padding bytes will be used in follow-up
patch.
Signed-off-by: Vasanthakumar Thiagarajan
---
drivers/net/wireless/ath/ath10k/core.c | 12
drivers/net/wireless/ath/ath10k/hw.c | 13 +
drivers/net/wireless/ath/ath10k/hw.h | 12
3 files changed, 37 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index e889829..9c5e93b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -68,6 +68,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.board_size = QCA988X_BOARD_DATA_SZ,
.board_ext_size = QCA988X_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA9887_HW_1_0_VERSION,
@@ -87,6 +88,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[]
= {
.board_size = QCA9887_BOARD_DATA_SZ,
.board_ext_size = QCA9887_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -104,6 +106,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA6174_HW_2_1_VERSION,
@@ -122,6 +125,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA6174_HW_3_0_VERSION,
@@ -140,6 +144,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA6174_HW_3_2_VERSION,
@@ -159,6 +164,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA6174_BOARD_DATA_SZ,
.board_ext_size = QCA6174_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA99X0_HW_2_0_DEV_VERSION,
@@ -182,6 +188,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca99x0_rx_desc_ops,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -205,6 +212,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca99x0_rx_desc_ops,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -227,6 +235,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca99x0_rx_desc_ops,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -244,6 +253,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA9377_BOARD_DATA_SZ,
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA9377_HW_1_1_DEV_VERSION,
@@ -261,6 +271,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board_size = QCA9377_BOARD_DATA_SZ,
.board_ext_size = QCA9377_BOARD_EXT_DATA_SZ,
},
+ .hw_rx_desc_ops = &qca988x_rx_desc_ops,
},
{
.id = QCA4019_HW_1_0_DEV_VERSION,
@@ -285,6 +2
[PATCH 1/4] ath10k: Move ath10k_hw_params definition to hw.h
This is to prepare for rx descriptor abstraction where we'll
be dereferencing ath10k_hw_params member in hw.h. Moreover
hw.h looks more suitable to house ath10k_hw_params definition
than core.h
Signed-off-by: Vasanthakumar Thiagarajan
---
drivers/net/wireless/ath/ath10k/core.h | 48 +-
drivers/net/wireless/ath/ath10k/hw.h | 48 ++
2 files changed, 49 insertions(+), 47 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 30ae5bf..5ace413 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -715,53 +715,7 @@ struct ath10k {
struct ath10k_htc htc;
struct ath10k_htt htt;
- struct ath10k_hw_params {
- u32 id;
- u16 dev_id;
- const char *name;
- u32 patch_load_addr;
- int uart_pin;
- u32 otp_exe_param;
-
- /* Type of hw cycle counter wraparound logic, for more info
-* refer enum ath10k_hw_cc_wraparound_type.
-*/
- enum ath10k_hw_cc_wraparound_type cc_wraparound_type;
-
- /* Some of chip expects fragment descriptor to be continuous
-* memory for any TX operation. Set continuous_frag_desc flag
-* for the hardware which have such requirement.
-*/
- bool continuous_frag_desc;
-
- /* CCK hardware rate table mapping for the newer chipsets
-* like QCA99X0, QCA4019 got revised. The CCK h/w rate values
-* are in a proper order with respect to the rate/preamble
-*/
- bool cck_rate_map_rev2;
-
- u32 channel_counters_freq_hz;
-
- /* Mgmt tx descriptors threshold for limiting probe response
-* frames.
-*/
- u32 max_probe_resp_desc_thres;
-
- /* The padding bytes's location is different on various chips */
- enum ath10k_hw_4addr_pad hw_4addr_pad;
-
- u32 tx_chain_mask;
- u32 rx_chain_mask;
- u32 max_spatial_stream;
- u32 cal_data_len;
-
- struct ath10k_hw_params_fw {
- const char *dir;
- const char *board;
- size_t board_size;
- size_t board_ext_size;
- } fw;
- } hw_params;
+ struct ath10k_hw_params hw_params;
/* contains the firmware images used with ATH10K_FIRMWARE_MODE_NORMAL */
struct ath10k_fw_components normal_mode_fw;
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index e014cd7..1315557 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -363,6 +363,54 @@ enum ath10k_hw_cc_wraparound_type {
ATH10K_HW_CC_WRAP_SHIFTED_EACH = 2,
};
+struct ath10k_hw_params {
+ u32 id;
+ u16 dev_id;
+ const char *name;
+ u32 patch_load_addr;
+ int uart_pin;
+ u32 otp_exe_param;
+
+ /* Type of hw cycle counter wraparound logic, for more info
+* refer enum ath10k_hw_cc_wraparound_type.
+*/
+ enum ath10k_hw_cc_wraparound_type cc_wraparound_type;
+
+ /* Some of chip expects fragment descriptor to be continuous
+* memory for any TX operation. Set continuous_frag_desc flag
+* for the hardware which have such requirement.
+*/
+ bool continuous_frag_desc;
+
+ /* CCK hardware rate table mapping for the newer chipsets
+* like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+* are in a proper order with respect to the rate/preamble
+*/
+ bool cck_rate_map_rev2;
+
+ u32 channel_counters_freq_hz;
+
+ /* Mgmt tx descriptors threshold for limiting probe response
+* frames.
+*/
+ u32 max_probe_resp_desc_thres;
+
+ /* The padding bytes's location is different on various chips */
+ enum ath10k_hw_4addr_pad hw_4addr_pad;
+
+ u32 tx_chain_mask;
+ u32 rx_chain_mask;
+ u32 max_spatial_stream;
+ u32 cal_data_len;
+
+ struct ath10k_hw_params_fw {
+ const char *dir;
+ const char *board;
+ size_t board_size;
+ size_t board_ext_size;
+ } fw;
+};
+
/* Target specific defines for MAIN firmware */
#define TARGET_NUM_VDEVS 8
#define TARGET_NUM_PEER_AST2
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ath10k: Padding related clean ups in rx
This patch set adds abstraction for rx_hw_desc processing so that we can make use of newer desc fields notifying padding information which is done on rx payload. "ath10k: Properly remove padding from the start of rx payload" fixes padding related bug in ethernet decap mode for QCA99X0, QCA9984 qnd QCA4019 but even fixing this bug will not make ethernet decap mode work, there needs to be some more fix wich would follow this patch series. Vasanthakumar Thiagarajan (4): ath10k: Move ath10k_hw_params definition to hw.h ath10k: Add provision for Rx descriptor abstraction ath10k: Properly remove padding from the start of rx payload ath10k: Remove 4-addr padding related hw_param configuration drivers/net/wireless/ath/ath10k/core.c | 21 ++ drivers/net/wireless/ath/ath10k/core.h | 48 + drivers/net/wireless/ath/ath10k/htt_rx.c | 36 +--- drivers/net/wireless/ath/ath10k/hw.c | 13 ++ drivers/net/wireless/ath/ath10k/hw.h | 71 +--- 5 files changed, 114 insertions(+), 75 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)
Al Viro wrote:
>
> Another thing (and if that works, it's *NOT* a proper fix - it would be
> papering over the problem, but at least it would show where to look for
> it) - try (on top of mainline) the following delta:
I tried it on top of v4.6.4 and on top of the very recent v4.7-2509-g59ebc44
from Linus, and still got corruption.
>
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index b7de71f..0ee5995 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -734,7 +734,7 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
> if (!chunk)
> return 0;
>
> - if (msg_data_left(msg) < chunk) {
> + if (iov_iter_single_seg_count(&msg->msg_iter) < chunk) {
> if (__skb_checksum_complete(skb))
> goto csum_error;
> if (skb_copy_datagram_msg(skb, hlen, msg, chunk))
>
--
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Allow setting coverage class
Hi, [auto build test ERROR on ath6kl/ath-next] [also build test ERROR on next-20160727] [cannot apply to v4.7] [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/Benjamin-Berg/ath10k-Allow-setting-coverage-class/20160727-163809 base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sparc64 All errors (new ones prefixed by >>): drivers/net/wireless/ath/ath10k/wmi.c: In function 'ath10k_ath9k_set_pdev_coverage_class': >> drivers/net/wireless/ath/ath10k/wmi.c:3176:2: error: expected ';' before >> 'timeout' timeout = timeout & ATH9K_MAC_TIME_OUT_ACK; ^ drivers/net/wireless/ath/ath10k/wmi.c:3181:2: error: expected ';' before 'timeout' timeout = timeout >> ATH9K_MAC_TIME_OUT_CTS_S; ^ drivers/net/wireless/ath/ath10k/wmi.c:3185:2: error: expected ';' before 'timeout' timeout = timeout & ATH9K_MAC_TIME_OUT_CTS; ^ vim +3176 drivers/net/wireless/ath/ath10k/wmi.c 3170 /* Update ack timeout (lower halfword). */ 3171 timeout = (timeout_reg & ATH9K_MAC_TIME_OUT_ACK); 3172 timeout = timeout >> ATH9K_MAC_TIME_OUT_ACK_S; 3173 timeout += 3 * value * counters_freq_mhz; 3174 timeout = min_t(u32, timeout, ATH9K_MAC_TIME_OUT_MAX); 3175 timeout = (timeout << ATH9K_MAC_TIME_OUT_ACK_S) > 3176 timeout = timeout & ATH9K_MAC_TIME_OUT_ACK; 3177 timeout_reg = (timeout_reg & ~ATH9K_MAC_TIME_OUT_ACK) | timeout; 3178 3179 /* Update cts timeout (upper halfword). */ --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH] ath10k: Allow setting coverage class
On 27 July 2016 at 10:33, Benjamin Berg wrote:
> Unfortunately ath10k does not generally allow modifying the coverage class
> with the stock firmware and Qualcomm has so far refused to implement this
> feature so that it can be properly supported in ath10k. If we however know
> the registers that need to be modified for proper operation with a higher
> coverage class, then we can do these modifications from the driver.
>
> This patch implements this hack for first generation cards which are based
> on a core that is similar to ath9k. The registers are modified in place and
> need to be re-written every time the firmware sets them. To achieve this
> the register status is verified after any event from the firmware.
"After any event from firmware" would also need to include HTT events
which your patch doesn't consider.
> The coverage class may not be modified temporarily right after the card
> re-initializes the registers. This is for example the case during scanning.
>
> A warning will be generated if the hack is not supported on the card or
> unexpected values are hit. There is no error reporting for userspace
> applications though (this is a limitation in the mac80211 driver
> interface).
With a recent change in ath10k the ieee80211_ops can be updated in
ar->ops so you can NULL-ify .set_coverage_class before registering to
mac80211. See how wake_tx_queue() is masked. You could use this to
mask it for WAVE2 devices that haven't been verified.
[...]
> @@ -257,6 +258,12 @@ extern const struct ath10k_hw_regs qca6174_regs;
> extern const struct ath10k_hw_regs qca99x0_regs;
> extern const struct ath10k_hw_regs qca4019_regs;
>
> +enum ath10k_hw_mac_core_rev {
> + ATH10K_HW_MAC_CORE_UNKNOWN = 0,
> + ATH10K_HW_MAC_CORE_ATH9K,
WAVE1 would be more appropriate.
> + ATH10K_HW_MAC_CORE_WAVE2,
> +};
> +
[...]
> +#define ATH9K_MAC_TIME_OUT 0x8014
> +#define ATH9K_MAC_TIME_OUT_MAX 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_ACK 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_ACK_S 0
> +#define ATH9K_MAC_TIME_OUT_CTS 0x3FFF
> +#define ATH9K_MAC_TIME_OUT_CTS_S 16
> +
> +#define ATH9K_MAC_IFS_SLOT 0x1070
> +#define ATH9K_MAC_IFS_SLOT_M 0x
> +#define ATH9K_MAC_IFS_SLOT_RESV0 0x
The prefix is wrong. It shouldn't be ATH9K.
Moreover FW refers to these register as PCU_ACK_CTS_TIMEOUT and
PCU_GBL_IFS_SLOT.
> +
> #endif /* _HW_H_ */
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 55c823f..a9b587e 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5372,6 +5372,15 @@ static void ath10k_bss_info_changed(struct
> ieee80211_hw *hw,
> mutex_unlock(&ar->conf_mutex);
> }
>
> +static void ath10k_set_coverage_class(struct ieee80211_hw *hw,
> + s16 value)
Wrong function prefix/name. Should be: ath10k_mac_op_set_coverage_class
> +{
> + struct ath10k *ar = hw->priv;
> +
> + if (ath10k_wmi_pdev_set_coverage_class(ar, value) == -EOPNOTSUPP)
> + ath10k_warn(ar, "Modification of coverage class is not
> supported!\n");
Warning doesn't match the style used in ath10k. "failed to set
coverage class: not supported\n".
[...]
> diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h
> b/drivers/net/wireless/ath/ath10k/wmi-ops.h
> index 64ebd30..3ebc57e 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
> @@ -52,6 +52,8 @@ struct wmi_ops {
> int (*pull_wow_event)(struct ath10k *ar, struct sk_buff *skb,
> struct wmi_wow_ev_arg *arg);
> enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
> + void (*set_pdev_coverage_class)(struct ath10k *ar,
> + s16 value);
WMI ops are used to generate and process events and command buffers.
These ops are not supposed to have side-effects but
"set_pdev_coverage_class" implies it does.
[...]
> /* MAIN WMI cmd track */
> static struct wmi_cmd_map wmi_cmd_map = {
> @@ -3096,6 +3097,121 @@ ath10k_wmi_op_pull_peer_kick_ev(struct ath10k *ar,
> struct sk_buff *skb,
> return 0;
> }
>
> +static void
> +ath10k_ath9k_set_pdev_coverage_class(struct ath10k *ar, s16 value)
The prefix is wrong. "ath9k" should be used here.
ath10k_wmi_ is appropriate for stuff in wmi.c
[...]
> + /* Do some sanity checks on the slottime register. */
> + if (unlikely(slottime_reg % counters_freq_mhz)) {
> + ath10k_warn(ar,
> + "Not adjusting coverage class timeouts, expected
> an integer microsecond slot time in HW register\n");
Wrong message style.
> +
> + goto store_regs;
> + }
> +
> + slottime = (slottime_reg & ATH9K_MAC_IFS_SLOT_M) / counters_freq_mhz;
> + if (unlikely(slottime != 9 && slotti
[PATCH] ath10k: Allow setting coverage class
Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.
This patch implements this hack for first generation cards which are based
on a core that is similar to ath9k. The registers are modified in place and
need to be re-written every time the firmware sets them. To achieve this
the register status is verified after any event from the firmware.
The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.
A warning will be generated if the hack is not supported on the card or
unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).
Thanks to Sebastian Gottschall for initially
working on a userspace support for this. This patch wouldn't have been
possible without this documentation.
Signed-off-by: Benjamin Berg
Signed-off-by: Simon Wunderlich
Signed-off-by: Mathias Kretschmer
---
drivers/net/wireless/ath/ath10k/core.h| 10 ++
drivers/net/wireless/ath/ath10k/hw.c | 9 ++
drivers/net/wireless/ath/ath10k/hw.h | 28 +-
drivers/net/wireless/ath/ath10k/mac.c | 10 ++
drivers/net/wireless/ath/ath10k/wmi-ops.h | 17
drivers/net/wireless/ath/ath10k/wmi.c | 151 ++
6 files changed, 224 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 9374bcd..781219b 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -935,6 +935,16 @@ struct ath10k {
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+ /* protected by data_lock */
+ struct {
+ s16 coverage_class;
+
+ u32 reg_slottime_conf;
+ u32 reg_slottime_orig;
+ u32 reg_ack_cts_timeout_conf;
+ u32 reg_ack_cts_timeout_orig;
+ } fw_coverage;
+
/* must be last */
u8 drv_priv[0] __aligned(sizeof(void *));
};
diff --git a/drivers/net/wireless/ath/ath10k/hw.c
b/drivers/net/wireless/ath/ath10k/hw.c
index f903d46..82249be 100644
--- a/drivers/net/wireless/ath/ath10k/hw.c
+++ b/drivers/net/wireless/ath/ath10k/hw.c
@@ -22,6 +22,7 @@ const struct ath10k_hw_regs qca988x_regs = {
.rtc_soc_base_address = 0x4000,
.rtc_wmac_base_address = 0x5000,
.soc_core_base_address = 0x9000,
+ .wlan_mac_base_address = 0x0002,
.ce_wrapper_base_address= 0x00057000,
.ce0_base_address = 0x00057400,
.ce1_base_address = 0x00057800,
@@ -48,6 +49,7 @@ const struct ath10k_hw_regs qca6174_regs = {
.rtc_soc_base_address = 0x0800,
.rtc_wmac_base_address = 0x1000,
.soc_core_base_address = 0x0003a000,
+ .wlan_mac_base_address = 0x0002,
.ce_wrapper_base_address= 0x00034000,
.ce0_base_address = 0x00034400,
.ce1_base_address = 0x00034800,
@@ -74,6 +76,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
.rtc_soc_base_address = 0x0008,
.rtc_wmac_base_address = 0x,
.soc_core_base_address = 0x00082000,
+ .wlan_mac_base_address = 0x0003,
.ce_wrapper_base_address= 0x0004d000,
.ce0_base_address = 0x0004a000,
.ce1_base_address = 0x0004a400,
@@ -109,6 +112,7 @@ const struct ath10k_hw_regs qca99x0_regs = {
const struct ath10k_hw_regs qca4019_regs = {
.rtc_soc_base_address = 0x0008,
.soc_core_base_address = 0x00082000,
+ .wlan_mac_base_address = 0x0003,
.ce_wrapper_base_address= 0x0004d000,
.ce0_base_address = 0x0004a000,
.ce1_base_address = 0x0004a400,
@@ -139,6 +143,7 @@ const struct ath10k_hw_regs qca4019_regs = {
};
const struct ath10k_hw_values qca988x_values = {
+ .mac_core_rev = ATH10K_HW_MAC_CORE_ATH9K,
.rtc_state_val_on = 3,
.ce_count = 8,
.msi_assign_ce_max = 7,
@@ -148,6 +153,7 @@ const struct ath10k_hw_values qca988x_values = {
};
const struct ath10k_hw_values qca6174_values = {
+ .mac_core_rev = ATH10K_HW_M
