* [PATCH][next] rsi: fix missing null pointer check from a failed ieee80211_probereq_get call
From: Colin King @ 2019-02-21 12:35 UTC (permalink / raw)
To: Amitkumar Karwar, Siva Rebbagondla, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The call to ieee80211_probereq_get can return NULL if a skb allocation
fails, so add a null pointer check and free an earlier skb on the error
exit return path.
Fixes: 7fdcb8e12660 ("rsi: add support for hardware scan offload")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 8c17842ac507..844f2fac298f 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -1726,6 +1726,10 @@ int rsi_send_bgscan_probe_req(struct rsi_common *common,
probereq_skb = ieee80211_probereq_get(common->priv->hw, vif->addr, ssid,
ssid_len, scan_req->ie_len);
+ if (!probereq_skb) {
+ dev_kfree_skb(skb);
+ return -ENOMEM;
+ }
memcpy(&skb->data[frame_len], probereq_skb->data, probereq_skb->len);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Toke Høiland-Jørgensen @ 2019-02-21 15:42 UTC (permalink / raw)
To: Grant Grundler, Kan Yan
Cc: Johannes Berg, wgong, wgong, ath10k, linux-wireless
In-Reply-To: <CANEJEGuBoRMBJBOrFOYyPtiJSMfTahrVgTfxZ2ift6Q5uGazFA@mail.gmail.com>
Grant Grundler <grundler@google.com> writes:
> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Grant Grundler <grundler@google.com> writes:
>>
>> >> And, well, Grant's data is from a single test in a noisy
>> >> environment where the time series graph shows that throughput is all over
>> >> the place for the duration of the test; so it's hard to draw solid
>> >> conclusions from (for instance, for the 5-stream test, the average
>> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>> >> used in this test, so I can't go verify it myself; so the only thing I
>> >> can do is grumble about it here... :)
>> >
>> > It's a fair complaint and I agree with it. My counter argument is the
>> > opposite is true too: most ideal benchmarks don't measure what most
>> > users see. While the data wgong provided are way more noisy than I
>> > like, my overall "confidence" in the "conclusion" I offered is still
>> > positive.
>>
>> Right. I guess I would just prefer a slightly more comprehensive
>> evaluation to base a 4x increase in buffer size on...
>
> Kalle, is this why you didn't accept this patch? Other reasons?
>
> Toke, what else would you like to see evaluated?
>
> I generally want to see three things measured when "benchmarking"
> technologies: throughput, latency, cpu utilization
> We've covered those three I think "reasonably".
Hmm, going back and looking at this (I'd completely forgotten about this
patch), I think I had two main concerns:
1. What happens in a degraded signal situation, where the throughput is
limited by the signal conditions, or by contention with other devices.
Both of these happen regularly, and I worry that latency will be
badly affected under those conditions.
2. What happens with old hardware that has worse buffer management in
the driver->firmware path (especially drivers without push/pull mode
support)? For these, the lower-level queueing structure is less
effective at controlling queueing latency.
Getting the queue size limit patches from ChromeOS ported would
alleviate point 2. I do believe Kan said he'd look into that once the
airtime patches were merged. So Kan, any progress on that front? :)
> What does a "4x increase in memory" mean here? Wen, how much more
> memory does this cause ath10k to use?
I didn't say "memory", I said "buffer size"... :)
I.e., it's the latency impact of the increased buffering I'm worried
about (see above), not the system memory usage.
-Toke
^ permalink raw reply
* Re: [PATCH wireless-drivers-next 2/2] brcmfmac: print firmware reported general status errors
From: Rafał Miłecki @ 2019-02-21 11:13 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Rafał Miłecki, Kalle Valo, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list
In-Reply-To: <e644a5b7-c70d-056a-740e-997c931863c2@broadcom.com>
On 2019-02-21 11:45, Arend Van Spriel wrote:
> On 2/21/2019 11:33 AM, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> Firmware may report general errors using a special message type. Add
>> basic support for it by simply decoding & printing an error number.
>>
>> A sample situation in which firmware reports a buf error:
>> CONSOLE: 027084.733 no host response IOCTL buffer available..so fail
>> the request
>> will now produce a "Firmware reported general error: 9" on the host.
>
> Could have meaningful message instead of a number. I can do that in
> follow up patch if you do not have the information.
That would be nice, thanks!
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Kalle Valo @ 2019-02-21 16:10 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Grant Grundler, Kan Yan, linux-wireless, Johannes Berg, wgong,
ath10k, wgong
In-Reply-To: <87r2c1i1vj.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@toke.dk> writes:
> Grant Grundler <grundler@google.com> writes:
>
>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>
>>> Grant Grundler <grundler@google.com> writes:
>>>
>>> >> And, well, Grant's data is from a single test in a noisy
>>> >> environment where the time series graph shows that throughput is all over
>>> >> the place for the duration of the test; so it's hard to draw solid
>>> >> conclusions from (for instance, for the 5-stream test, the average
>>> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>>> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>>> >> used in this test, so I can't go verify it myself; so the only thing I
>>> >> can do is grumble about it here... :)
>>> >
>>> > It's a fair complaint and I agree with it. My counter argument is the
>>> > opposite is true too: most ideal benchmarks don't measure what most
>>> > users see. While the data wgong provided are way more noisy than I
>>> > like, my overall "confidence" in the "conclusion" I offered is still
>>> > positive.
>>>
>>> Right. I guess I would just prefer a slightly more comprehensive
>>> evaluation to base a 4x increase in buffer size on...
>>
>> Kalle, is this why you didn't accept this patch? Other reasons?
>>
>> Toke, what else would you like to see evaluated?
>>
>> I generally want to see three things measured when "benchmarking"
>> technologies: throughput, latency, cpu utilization
>> We've covered those three I think "reasonably".
>
> Hmm, going back and looking at this (I'd completely forgotten about this
> patch), I think I had two main concerns:
>
> 1. What happens in a degraded signal situation, where the throughput is
> limited by the signal conditions, or by contention with other devices.
> Both of these happen regularly, and I worry that latency will be
> badly affected under those conditions.
>
> 2. What happens with old hardware that has worse buffer management in
> the driver->firmware path (especially drivers without push/pull mode
> support)? For these, the lower-level queueing structure is less
> effective at controlling queueing latency.
Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377
PCI devices, which IIRC do not even support push/pull mode. All the
rest, including QCA988X and QCA9984 are unaffected.
--
Kalle Valo
^ permalink raw reply
* [PATCH 0/4] ath10k: small fixes for SDIO support
From: Kalle Valo @ 2019-02-21 16:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Wen has refactored some of the Alagu's fixes and wrote one of his own. I then
cleaned up the commit logs.
Alagu Sankar (3):
ath10k: sdio: set hi_acs_flags
ath10k: sdio: disable fwlog prints
ath10k: don't report unset rssi values to mac80211
Wen Gong (1):
ath10k: sdio: reset chip on power_down()
drivers/net/wireless/ath/ath10k/core.c | 19 ++++++++++++++++---
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 +++++++++---
drivers/net/wireless/ath/ath10k/sdio.c | 24 ++++++++++++++++--------
3 files changed, 41 insertions(+), 14 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/4] ath10k: sdio: set hi_acs_flags
From: Kalle Valo @ 2019-02-21 16:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Alagu Sankar, Wen Gong
In-Reply-To: <1550766118-31703-1-git-send-email-kvalo@codeaurora.org>
From: Alagu Sankar <alagusankar@silex-india.com>
The SDIO firmware does not allow transmitting packets with the
reduced tx completion HI_ACS option. SDIO firmware uses 1544 as
alternate credit size, which is not big enough for the maximum sized
mac80211 frames. Disable both these HI_ACS flags for SDIO.
Co-developed-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index ac2cf3f1c7b4..0c62a61b5eac 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -637,10 +637,16 @@ static void ath10k_init_sdio(struct ath10k *ar)
ath10k_bmi_write32(ar, hi_mbox_isr_yield_limit, 99);
ath10k_bmi_read32(ar, hi_acs_flags, ¶m);
- param |= (HI_ACS_FLAGS_SDIO_SWAP_MAILBOX_SET |
- HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET |
- HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE);
+ /* Data transfer is not initiated, when reduced Tx completion
+ * is used for SDIO. disable it until fixed
+ */
+ param &= ~HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET;
+ /* Alternate credit size of 1544 as used by SDIO firmware is
+ * not big enough for mac80211 / native wifi frames. disable it
+ */
+ param &= ~HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE;
+ param |= HI_ACS_FLAGS_SDIO_SWAP_MAILBOX_SET;
ath10k_bmi_write32(ar, hi_acs_flags, param);
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] ath10k: sdio: disable fwlog prints
From: Kalle Valo @ 2019-02-21 16:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Alagu Sankar, Wen Gong
In-Reply-To: <1550766118-31703-1-git-send-email-kvalo@codeaurora.org>
From: Alagu Sankar <alagusankar@silex-india.com>
The SDIO firmware may turn it on based on scratch registers so disable the
firmware log to avoid that.
Co-developed-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 0c62a61b5eac..7ccd6741c5b0 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -648,6 +648,13 @@ static void ath10k_init_sdio(struct ath10k *ar)
param &= ~HI_ACS_FLAGS_ALT_DATA_CREDIT_SIZE;
param |= HI_ACS_FLAGS_SDIO_SWAP_MAILBOX_SET;
ath10k_bmi_write32(ar, hi_acs_flags, param);
+
+ /* Explicitly set fwlog prints to zero as target may turn it on
+ * based on scratch registers.
+ */
+ ath10k_bmi_read32(ar, hi_option_flag, ¶m);
+ param |= HI_OPTION_DISABLE_DBGLOG;
+ ath10k_bmi_write32(ar, hi_option_flag, param);
}
static int ath10k_init_configure_target(struct ath10k *ar)
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] ath10k: sdio: reset chip on power_down()
From: Kalle Valo @ 2019-02-21 16:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Wen Gong
In-Reply-To: <1550766118-31703-1-git-send-email-kvalo@codeaurora.org>
From: Wen Gong <wgong@codeaurora.org>
The target device needs to be reset during power_down(), otherwise only the
first power_up() will work. And as ath10k calls power_up() during driver
initialisation the driver would be otherwise unusable.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00005-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/sdio.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c
index d62502f386f2..fae56c67766f 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -1382,6 +1382,12 @@ static int ath10k_sdio_hif_power_up(struct ath10k *ar,
ath10k_dbg(ar, ATH10K_DBG_BOOT, "sdio power on\n");
+ ret = ath10k_sdio_config(ar);
+ if (ret) {
+ ath10k_err(ar, "failed to config sdio: %d\n", ret);
+ return ret;
+ }
+
sdio_claim_host(func);
ret = sdio_enable_func(func);
@@ -1419,11 +1425,19 @@ static void ath10k_sdio_hif_power_down(struct ath10k *ar)
/* Disable the card */
sdio_claim_host(ar_sdio->func);
+
ret = sdio_disable_func(ar_sdio->func);
- sdio_release_host(ar_sdio->func);
+ if (ret) {
+ ath10k_warn(ar, "unable to disable sdio function: %d\n", ret);
+ sdio_release_host(ar_sdio->func);
+ return;
+ }
+ ret = mmc_hw_reset(ar_sdio->func->card->host);
if (ret)
- ath10k_warn(ar, "unable to disable sdio function: %d\n", ret);
+ ath10k_warn(ar, "unable to reset sdio: %d\n", ret);
+
+ sdio_release_host(ar_sdio->func);
ar_sdio->is_disabled = true;
}
@@ -2028,12 +2042,6 @@ static int ath10k_sdio_probe(struct sdio_func *func,
ath10k_sdio_set_mbox_info(ar);
- ret = ath10k_sdio_config(ar);
- if (ret) {
- ath10k_err(ar, "failed to config sdio: %d\n", ret);
- goto err_free_wq;
- }
-
bus_params.dev_type = ATH10K_DEV_TYPE_HL;
/* TODO: don't know yet how to get chip_id with SDIO */
bus_params.chip_id = 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] ath10k: don't report unset rssi values to mac80211
From: Kalle Valo @ 2019-02-21 16:21 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Alagu Sankar, Wen Gong
In-Reply-To: <1550766118-31703-1-git-send-email-kvalo@codeaurora.org>
From: Alagu Sankar <alagusankar@silex-india.com>
The SDIO firmware does not provide RSSI value to the host, it's only set to
zero. In that case don't report the value to mac80211. One risk here is that
value zero might be a valid value with other firmware, currently there's no way
to detect that.
Without the fix, the rssi value indicated by iw changes between the actual
value and -95.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00005-QCARMSWP-1.
Co-developed-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 4fc885617de1..62479b037210 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2119,9 +2119,15 @@ static bool ath10k_htt_rx_proc_rx_ind_hl(struct ath10k_htt *htt,
hdr = (struct ieee80211_hdr *)skb->data;
rx_status = IEEE80211_SKB_RXCB(skb);
rx_status->chains |= BIT(0);
- rx_status->signal = ATH10K_DEFAULT_NOISE_FLOOR +
- rx->ppdu.combined_rssi;
- rx_status->flag &= ~RX_FLAG_NO_SIGNAL_VAL;
+ if (rx->ppdu.combined_rssi == 0) {
+ /* SDIO firmware does not provide signal */
+ rx_status->signal = 0;
+ rx_status->flag |= RX_FLAG_NO_SIGNAL_VAL;
+ } else {
+ rx_status->signal = ATH10K_DEFAULT_NOISE_FLOOR +
+ rx->ppdu.combined_rssi;
+ rx_status->flag &= ~RX_FLAG_NO_SIGNAL_VAL;
+ }
spin_lock_bh(&ar->data_lock);
ch = ar->scan_channel;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Ben Greear @ 2019-02-21 16:22 UTC (permalink / raw)
To: Kalle Valo, Toke Høiland-Jørgensen
Cc: Grant Grundler, Kan Yan, linux-wireless, Johannes Berg, wgong,
ath10k, wgong
In-Reply-To: <871s41nmvx.fsf@kamboji.qca.qualcomm.com>
On 2/21/19 8:10 AM, Kalle Valo wrote:
> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>> Grant Grundler <grundler@google.com> writes:
>>
>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>
>>>> Grant Grundler <grundler@google.com> writes:
>>>>
>>>>>> And, well, Grant's data is from a single test in a noisy
>>>>>> environment where the time series graph shows that throughput is all over
>>>>>> the place for the duration of the test; so it's hard to draw solid
>>>>>> conclusions from (for instance, for the 5-stream test, the average
>>>>>> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>>>>>> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>>>>>> used in this test, so I can't go verify it myself; so the only thing I
>>>>>> can do is grumble about it here... :)
>>>>>
>>>>> It's a fair complaint and I agree with it. My counter argument is the
>>>>> opposite is true too: most ideal benchmarks don't measure what most
>>>>> users see. While the data wgong provided are way more noisy than I
>>>>> like, my overall "confidence" in the "conclusion" I offered is still
>>>>> positive.
>>>>
>>>> Right. I guess I would just prefer a slightly more comprehensive
>>>> evaluation to base a 4x increase in buffer size on...
>>>
>>> Kalle, is this why you didn't accept this patch? Other reasons?
>>>
>>> Toke, what else would you like to see evaluated?
>>>
>>> I generally want to see three things measured when "benchmarking"
>>> technologies: throughput, latency, cpu utilization
>>> We've covered those three I think "reasonably".
>>
>> Hmm, going back and looking at this (I'd completely forgotten about this
>> patch), I think I had two main concerns:
>>
>> 1. What happens in a degraded signal situation, where the throughput is
>> limited by the signal conditions, or by contention with other devices.
>> Both of these happen regularly, and I worry that latency will be
>> badly affected under those conditions.
>>
>> 2. What happens with old hardware that has worse buffer management in
>> the driver->firmware path (especially drivers without push/pull mode
>> support)? For these, the lower-level queueing structure is less
>> effective at controlling queueing latency.
>
> Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377
> PCI devices, which IIRC do not even support push/pull mode. All the
> rest, including QCA988X and QCA9984 are unaffected.
Just as a note, at least kernels such as 4.14.whatever perform poorly when
running ath10k on 9984 when acting as TCP endpoints. This makes them not
really usable for stuff like serving video to lots of clients.
Tweaking TCP (I do it a bit differently, but either way) can significantly
improve performance.
Recently I helped a user that could get barely 70 stations streaming at 1Mbps
on stock kernel (using one wave1 on 2.4, one wave-2 on 5Ghz),
and we got 110 working with a tweaked TCP stack. These were /n stations too.
I think it is lame that it _still_ requires out of tree patches to make TCP work
well on ath10k...even if you want to default to current behaviour, you should
allow users to tweak it to work with their use case.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Toke Høiland-Jørgensen @ 2019-02-21 16:28 UTC (permalink / raw)
To: Kalle Valo
Cc: Grant Grundler, Kan Yan, linux-wireless, Johannes Berg, wgong,
ath10k, wgong
In-Reply-To: <871s41nmvx.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>> Grant Grundler <grundler@google.com> writes:
>>
>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>
>>>> Grant Grundler <grundler@google.com> writes:
>>>>
>>>> >> And, well, Grant's data is from a single test in a noisy
>>>> >> environment where the time series graph shows that throughput is all over
>>>> >> the place for the duration of the test; so it's hard to draw solid
>>>> >> conclusions from (for instance, for the 5-stream test, the average
>>>> >> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>>>> >> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>>>> >> used in this test, so I can't go verify it myself; so the only thing I
>>>> >> can do is grumble about it here... :)
>>>> >
>>>> > It's a fair complaint and I agree with it. My counter argument is the
>>>> > opposite is true too: most ideal benchmarks don't measure what most
>>>> > users see. While the data wgong provided are way more noisy than I
>>>> > like, my overall "confidence" in the "conclusion" I offered is still
>>>> > positive.
>>>>
>>>> Right. I guess I would just prefer a slightly more comprehensive
>>>> evaluation to base a 4x increase in buffer size on...
>>>
>>> Kalle, is this why you didn't accept this patch? Other reasons?
>>>
>>> Toke, what else would you like to see evaluated?
>>>
>>> I generally want to see three things measured when "benchmarking"
>>> technologies: throughput, latency, cpu utilization
>>> We've covered those three I think "reasonably".
>>
>> Hmm, going back and looking at this (I'd completely forgotten about this
>> patch), I think I had two main concerns:
>>
>> 1. What happens in a degraded signal situation, where the throughput is
>> limited by the signal conditions, or by contention with other devices.
>> Both of these happen regularly, and I worry that latency will be
>> badly affected under those conditions.
>>
>> 2. What happens with old hardware that has worse buffer management in
>> the driver->firmware path (especially drivers without push/pull mode
>> support)? For these, the lower-level queueing structure is less
>> effective at controlling queueing latency.
>
> Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377
> PCI devices, which IIRC do not even support push/pull mode. All the
> rest, including QCA988X and QCA9984 are unaffected.
Ah, right; I did not go all the way back and look at the actual patch,
so missed that :)
But in that case, why are the latency results that low? Were these tests
done with the ChromeOS queue limit patches?
-Toke
^ permalink raw reply
* RE: [BUG] ath10k firmware crash 100% recreated this way
From: Chaoxing Lin @ 2019-02-21 16:33 UTC (permalink / raw)
To: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <E0249DC1E88AC941A5535F80928B4ADF1246381D@EXCHMBX01.rock.corp>
Hello ath10k firmware maintainers,
What I describe is just a definite way to crash ath10k firmware.
It does NOT mean that the firmware crash only happens in such scenario.
I saw firmware crash once a while.
Is there a plan to fix the firmware crash issue? If not, is it possible to get ath10k firmware source code? We can sign any NDA if needed. We will contribute back if we have a fix for this firmware crash.
Thanks,
Chaoxing
-----Original Message-----
From: Chaoxing Lin
Sent: Friday, February 15, 2019 10:46 AM
To: ath10k@lists.infradead.org; linux-wireless@vger.kernel.org
Subject: [BUG] ath10k firmware crash 100% recreated this way
Hello ath10k firmware maintainers,
I saw ath10k firmware crash very often (~170 times in 20hours) on our wireless AP/bridge environment below:
arm64 board
kernel 4.14.16
hostapd-2.6 run in 4-address mode
Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter
ath10k_core.ko in software crypto mode
running RSTP (Rapid Spanning Tree Protocol)
I also consistently recreated this firmware crash on Linux PC acting as AP as follows. Please take a look.
"must" conditions:
1. ath10k_core.ko MUST be in software crypto mode
("modprobe ath10k_core cryptmode=1")
2. MUST run our proprietary RSTP bridge module 3ebridge.ko
(I can provide binary complied for kernel 4.14.16 on X86_64 PC)
3. STP must be on.
("brctl stp brg0 on", by default 3ebridge.ko would turn STP on. Just a note
that if STP is turned off, you won't see firmware crash)
4. hostapd-2.6 MUST be configured in 4-address mode
(put "wds_sta=1" in hostapd.conf)
5. Linux PC wireless client must be in 4-address mode.
(run "iw wlan0 set 4addr on" before starting wpa_supplicant)
To 100% recreate this firmware crash RIGHT AWAY, use the following WiFi
client.
root@Dell-D620:~# lspci
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG
[Golan] Network Connection (rev 02)
You can find such radio card in very old (~15 years old) laptop.
I can send you this radio card if you cannot find it.
ath10k firmware crashes right away when this 4-address client associates with the PC acting as AP.
FYI: What's known special about this wireless client?
Our experiments show this client does not really work in 4 address mode.
It successfully associates with AP but no traffic is possible in
4-address mode.
Packets sniffed in the air show that this client (when in 4 address mode)
does NOT send ACK packets to AP on receiving from AP packet whose RA is
client MAC and DA is multicast MAC (e.g. BPDU)
NOTE: Don't be distracted by what I saw about this wireless client.
It may not be related to the firmware crash.
The following are DONT-CARE in re-creating the firmware crash.
1. WiFi encryption:
The firmare crash happens even in bypass/no-encryption mode, although
ath10k_core.ko MUST be put in software crypto mode to see the crash.
2. ath10k firmware version:
As long as it supports software crypto mode (i.e. support raw mode),
the above procedure can crash it. I tried various firmware versions from
the initial version that supports raw mode to the latest
firmware-5.bin_10.2.4.70.69 dated 18-Dec-2018. They all crashed.
3. Linux wireless client distribution/OS is a don't care.
As long as the WiFi adapter is "Intel Corporation PRO/Wireless 3945AB"
Tried distributions below. They both make firmare crash right away on
PC AP side
Slackware 14.2 (kernel 4.4.14-smp)
Ubuntu 18.04.01 live (kernel 4.15.0-29-generic)
4. Radio channel setting is a don't care.
Tried with/without 11n/11ac/ and different channel width.
They all crash firmware.
I can provide all configurations/binary as below.
hostapd.conf [see later in this message]
wpa_supplicant.conf [see later in this message]
3ebridge.ko (RSTP bridge binary compiled for
mainline kernel 4.14.16 X86_64.
Please "modprobe -r bridge" before "insmod 3ebridge.ko")
Below is the syslog/messages related to the ath10k firmware crash.
For easier reading, Timestamps are removed. line edited just to wrap around at 80char
/var/log/messages
---------------------------------------------------------------------------
ath10k_pci 0000:03:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
ath10k_pci 0000:03:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff
sub 0000:0000
ath10k_pci 0000:03:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0
ath10k_pci 0000:03:00.0: firmware ver 10.2.4.70.69 api 5 features no-p2p,
raw-mode,mfp,allows-mesh-bcast crc32 edfb196a
ath10k_pci 0000:03:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
ath10k_pci 0000:03:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128
raw 1 hwcrypto 0
ath10k_pci 0000:03:00.0 wlan50: renamed from wlan0
ath10k_pci 0000:03:00.0 wlan4: renamed from wlan50
IPv6: ADDRCONF(NETDEV_UP): phy0ap: link is not ready
device phy0ap entered promiscuous mode
IPv6: ADDRCONF(NETDEV_CHANGE): phy0ap: link becomes ready
device phy0ap.sta1 entered promiscuous mode
ath10k_pci 0000:03:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff
sub 0000:0000
ath10k_pci 0000:03:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0
ath10k_pci 0000:03:00.0: firmware ver 10.2.4.70.69 api 5 features no-p2p,
raw-mode,mfp,allows-mesh-bcast crc32 edfb196a
ath10k_pci 0000:03:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
ath10k_pci 0000:03:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128
raw 1 hwcrypto 0
ieee80211 phy0: Hardware restart was requested
ath10k_pci 0000:03:00.0: device successfully recovered
/var/log/syslog
----------------------------------------------------------------------------
ath10k_pci 0000:03:00.0: firmware crashed!
(guid 64627eb3-5b90-491a-8181-6972fc50d317)
ath10k_pci 0000:03:00.0: firmware register dump:
ath10k_pci 0000:03:00.0: [00]: 0x4100016C 0x000015B3 0x0099901F 0x00955B31
ath10k_pci 0000:03:00.0: [04]: 0x0099901F 0x00060130 0x00000020 0x000FFFFF
ath10k_pci 0000:03:00.0: [08]: 0x00427D80 0x00000003 0x00000000 0x00401C3C
ath10k_pci 0000:03:00.0: [12]: 0x00000009 0xFFFFFFFF 0x00958360 0x0095836B
ath10k_pci 0000:03:00.0: [16]: 0x00958080 0x0094085D 0x00000000 0x00000000
ath10k_pci 0000:03:00.0: [20]: 0x4099901F 0x0040AA94 0x00000001 0x00100000
ath10k_pci 0000:03:00.0: [24]: 0x80996254 0x0040AAF4 0x00409418 0xC099901F
ath10k_pci 0000:03:00.0: [28]: 0x8099A4BD 0x0040AB44 0x00427D80 0x00439BC0
ath10k_pci 0000:03:00.0: [32]: 0x8099A62C 0x0040ACE4 0x00000000 0x0042E648
ath10k_pci 0000:03:00.0: [36]: 0x8099A5BC 0x0040AD14 0x00000002 0x0042E648
ath10k_pci 0000:03:00.0: [40]: 0x8099A7AC 0x0040AD44 0x00439BC0 0x0042E648
ath10k_pci 0000:03:00.0: [44]: 0x8099885F 0x0040AD64 0x00439BC0 0x00000002
ath10k_pci 0000:03:00.0: [48]: 0x8099AF6D 0x0040AD84 0x0042066C 0x0042621C
ath10k_pci 0000:03:00.0: [52]: 0x809BF051 0x0040AEE4 0x00424D5C 0x00000002
ath10k_pci 0000:03:00.0: [56]: 0x80940F18 0x0040AF14 0x00000005 0x004039E4
ath10k_pci 0000:03:00.0: Copy Engine register dump:
ath10k_pci 0000:03:00.0: [00]: 0x00057400 1 1 3 3
ath10k_pci 0000:03:00.0: [01]: 0x00057800 14 14 241 242
ath10k_pci 0000:03:00.0: [02]: 0x00057c00 56 56 55 56
ath10k_pci 0000:03:00.0: [03]: 0x00058000 12 12 14 12
ath10k_pci 0000:03:00.0: [04]: 0x00058400 24 24 62 22
ath10k_pci 0000:03:00.0: [05]: 0x00058800 7 7 326 327
ath10k_pci 0000:03:00.0: [06]: 0x00058c00 19 19 19 19
ath10k_pci 0000:03:00.0: [07]: 0x00059000 0 0 0 0
phy0ap.sta1: Failed check-sdata-in-driver check, flags: 0x0
------------[ cut here ]------------
WARNING: CPU: 1 PID: 30409 at net/mac80211/driver-ops.h:18
ieee80211_assign_chanctx.part.16+0x15e/0x170 [mac80211]
Modules linked in: ath10k_pci ath10k_core ath mac80211 cfg80211 3ebridge(O)
nfnetlink_queue nfnetlink_log nfnetlink bluetooth ecdh_generic rfkill ipv6
fuse hid_generic usbhid hid i2c_dev dell_wmi dell_smbios sparse_keymap
gpio_ich wmi_bmof ppdev evdev dcdbas snd_hda_codec_analog snd_hda_codec_generic
coretemp snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm kvm_intel
kvm snd_timer hwmon psmouse irqbypass serio_raw snd i915 i2c_i801 uhci_hcd
video drm_kms_helper drm lpc_ich i2c_algo_bit fb_sys_fops syscopyarea
sysfillrect sysimgblt i2c_core ehci_pci e100 mii tpm_tis tpm_tis_core tpm wmi
soundcore parport_pc parport ehci_hcd intel_agp intel_gtt button agpgart
shpchp e1000e acpi_cpufreq loop [last unloaded: cfg80211]
CPU: 1 PID: 30409 Comm: kworker/1:2 Tainted: G W O 4.14.16 #2
Hardware name: Dell Inc. OptiPlex 780 /0C27VV, BIOS A05 08/11/2010
Workqueue: events_freezable ieee80211_restart_work [mac80211]
task: ffff8ed6d13b0c80 task.stack: ffffaec64372c000
RIP: 0010:ieee80211_assign_chanctx.part.16+0x15e/0x170 [mac80211]
RSP: 0018:ffffaec64372fdb0 EFLAGS: 00010282
RAX: 000000000000003c RBX: ffff8ed682380780 RCX: 0000000000000000
RDX: ffff8ed6fd85d130 RSI: ffff8ed6fd855518 RDI: ffff8ed6fd855518
RBP: ffff8ed682380780 R08: 0000000000000001 R09: 0000000000000779
R10: ffff8ed682381560 R11: 0000000000000779 R12: ffff8ed6f5b0e8c0
R13: ffff8ed682381198 R14: ffff8ed6f5b92f58 R15: ffff8ed6f5b0e8c0
FS: 0000000000000000(0000) GS:ffff8ed6fd840000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe13bcba00a CR3: 000000005d140000 CR4: 00000000000406e0
Call Trace:
ieee80211_reconfig+0xc7f/0x1300 [mac80211]
? try_to_del_timer_sync+0x3d/0x50
ieee80211_restart_work+0x99/0xc0 [mac80211]
process_one_work+0x139/0x400
worker_thread+0x47/0x430
kthread+0xfc/0x130
? process_one_work+0x400/0x400
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x35/0x40
Code: 45 31 e4 e9 46 ff ff ff 49 8b 84 24 00 04 00 00 49 8d b4 24 20 04 00 00 48 c7 c7 70 71 77 c0 48 85 c0 48 0f 45 f0 e8 0d 19 9b df <0f> ff e9 26 ff ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 66 66 66
---[ end trace d5e6e93890bc3ea5 ]---
hostapd.conf
---------------------------------------------------------------------------
interface=phy0ap
bridge=brg0
driver=nl80211
logger_syslog=-1
logger_syslog_level=4
logger_stdout=-1
logger_stdout_level=4
country_code=US
ieee80211d=1
hw_mode=a
wds_sta=1
channel=36
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
beacon_int=200
ap_table_max_size=63
ap_table_expiration_time=300
local_pwr_constraint=3
ieee80211h=1
bssid=04:f0:21:3b:2f:78
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=4-addr-ap
dtim_period=2
max_num_sta=64
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wmm_enabled=1
ap_max_inactivity=300
ieee80211w=0
ieee8021x=0
#---------end of hostapd.conf---------------------------------------------
wpa_supplicant.conf
#------------------------------------------------------------------------
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="4-addr-ap"
scan_ssid=1
key_mgmt=NONE
}
#---------end of wpa_supplicant.conf------------------------------------
BTW: The Linux distribution should not matter. I use Slackware Linux on the PC
acting as AP because Slackware Linux use exact mainline kernel source
without any patching. Kernel source from kernel.org can be just compiled
and dropped in.
I can also send you the radio card "Intel
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Toke Høiland-Jørgensen @ 2019-02-21 16:37 UTC (permalink / raw)
To: Ben Greear, Kalle Valo
Cc: Grant Grundler, Kan Yan, linux-wireless, Johannes Berg, wgong,
ath10k, wgong
In-Reply-To: <ecc20e01-1515-d227-62d8-377f3c35e449@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 2/21/19 8:10 AM, Kalle Valo wrote:
>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>>
>>> Grant Grundler <grundler@google.com> writes:
>>>
>>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>>
>>>>> Grant Grundler <grundler@google.com> writes:
>>>>>
>>>>>>> And, well, Grant's data is from a single test in a noisy
>>>>>>> environment where the time series graph shows that throughput is all over
>>>>>>> the place for the duration of the test; so it's hard to draw solid
>>>>>>> conclusions from (for instance, for the 5-stream test, the average
>>>>>>> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>>>>>>> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>>>>>>> used in this test, so I can't go verify it myself; so the only thing I
>>>>>>> can do is grumble about it here... :)
>>>>>>
>>>>>> It's a fair complaint and I agree with it. My counter argument is the
>>>>>> opposite is true too: most ideal benchmarks don't measure what most
>>>>>> users see. While the data wgong provided are way more noisy than I
>>>>>> like, my overall "confidence" in the "conclusion" I offered is still
>>>>>> positive.
>>>>>
>>>>> Right. I guess I would just prefer a slightly more comprehensive
>>>>> evaluation to base a 4x increase in buffer size on...
>>>>
>>>> Kalle, is this why you didn't accept this patch? Other reasons?
>>>>
>>>> Toke, what else would you like to see evaluated?
>>>>
>>>> I generally want to see three things measured when "benchmarking"
>>>> technologies: throughput, latency, cpu utilization
>>>> We've covered those three I think "reasonably".
>>>
>>> Hmm, going back and looking at this (I'd completely forgotten about this
>>> patch), I think I had two main concerns:
>>>
>>> 1. What happens in a degraded signal situation, where the throughput is
>>> limited by the signal conditions, or by contention with other devices.
>>> Both of these happen regularly, and I worry that latency will be
>>> badly affected under those conditions.
>>>
>>> 2. What happens with old hardware that has worse buffer management in
>>> the driver->firmware path (especially drivers without push/pull mode
>>> support)? For these, the lower-level queueing structure is less
>>> effective at controlling queueing latency.
>>
>> Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377
>> PCI devices, which IIRC do not even support push/pull mode. All the
>> rest, including QCA988X and QCA9984 are unaffected.
>
> Just as a note, at least kernels such as 4.14.whatever perform poorly when
> running ath10k on 9984 when acting as TCP endpoints. This makes them not
> really usable for stuff like serving video to lots of clients.
>
> Tweaking TCP (I do it a bit differently, but either way) can significantly
> improve performance.
Differently how? Did you have to do more than fiddle with the pacing_shift?
> Recently I helped a user that could get barely 70 stations streaming
> at 1Mbps on stock kernel (using one wave1 on 2.4, one wave-2 on 5Ghz),
> and we got 110 working with a tweaked TCP stack. These were /n
> stations too.
>
> I think it is lame that it _still_ requires out of tree patches to
> make TCP work well on ath10k...even if you want to default to current
> behaviour, you should allow users to tweak it to work with their use
> case.
Well if TCP is broken to the point of being unusable I do think we
should fix it; but I think "just provide a configuration knob" should be
the last resort...
-Toke
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Ben Greear @ 2019-02-21 16:57 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Kalle Valo
Cc: Grant Grundler, Kan Yan, linux-wireless, Johannes Berg, wgong,
ath10k, wgong
In-Reply-To: <87ftshhzby.fsf@toke.dk>
On 2/21/19 8:37 AM, Toke Høiland-Jørgensen wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 2/21/19 8:10 AM, Kalle Valo wrote:
>>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>>>
>>>> Grant Grundler <grundler@google.com> writes:
>>>>
>>>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>>>
>>>>>> Grant Grundler <grundler@google.com> writes:
>>>>>>
>>>>>>>> And, well, Grant's data is from a single test in a noisy
>>>>>>>> environment where the time series graph shows that throughput is all over
>>>>>>>> the place for the duration of the test; so it's hard to draw solid
>>>>>>>> conclusions from (for instance, for the 5-stream test, the average
>>>>>>>> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>>>>>>>> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>>>>>>>> used in this test, so I can't go verify it myself; so the only thing I
>>>>>>>> can do is grumble about it here... :)
>>>>>>>
>>>>>>> It's a fair complaint and I agree with it. My counter argument is the
>>>>>>> opposite is true too: most ideal benchmarks don't measure what most
>>>>>>> users see. While the data wgong provided are way more noisy than I
>>>>>>> like, my overall "confidence" in the "conclusion" I offered is still
>>>>>>> positive.
>>>>>>
>>>>>> Right. I guess I would just prefer a slightly more comprehensive
>>>>>> evaluation to base a 4x increase in buffer size on...
>>>>>
>>>>> Kalle, is this why you didn't accept this patch? Other reasons?
>>>>>
>>>>> Toke, what else would you like to see evaluated?
>>>>>
>>>>> I generally want to see three things measured when "benchmarking"
>>>>> technologies: throughput, latency, cpu utilization
>>>>> We've covered those three I think "reasonably".
>>>>
>>>> Hmm, going back and looking at this (I'd completely forgotten about this
>>>> patch), I think I had two main concerns:
>>>>
>>>> 1. What happens in a degraded signal situation, where the throughput is
>>>> limited by the signal conditions, or by contention with other devices.
>>>> Both of these happen regularly, and I worry that latency will be
>>>> badly affected under those conditions.
>>>>
>>>> 2. What happens with old hardware that has worse buffer management in
>>>> the driver->firmware path (especially drivers without push/pull mode
>>>> support)? For these, the lower-level queueing structure is less
>>>> effective at controlling queueing latency.
>>>
>>> Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377
>>> PCI devices, which IIRC do not even support push/pull mode. All the
>>> rest, including QCA988X and QCA9984 are unaffected.
>>
>> Just as a note, at least kernels such as 4.14.whatever perform poorly when
>> running ath10k on 9984 when acting as TCP endpoints. This makes them not
>> really usable for stuff like serving video to lots of clients.
>>
>> Tweaking TCP (I do it a bit differently, but either way) can significantly
>> improve performance.
>
> Differently how? Did you have to do more than fiddle with the pacing_shift?
This one, or a slightly tweaked version that applies to different kernels:
https://github.com/greearb/linux-ct-4.16/commit/3e14e8491a5b31ce994fb2752347145e6ab7eaf5
>> Recently I helped a user that could get barely 70 stations streaming
>> at 1Mbps on stock kernel (using one wave1 on 2.4, one wave-2 on 5Ghz),
>> and we got 110 working with a tweaked TCP stack. These were /n
>> stations too.
>>
>> I think it is lame that it _still_ requires out of tree patches to
>> make TCP work well on ath10k...even if you want to default to current
>> behaviour, you should allow users to tweak it to work with their use
>> case.
>
> Well if TCP is broken to the point of being unusable I do think we
> should fix it; but I think "just provide a configuration knob" should be
> the last resort...
So, it has been broken for years, and waiting for a perfect solution has not
gotten the problem fixed.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Toke Høiland-Jørgensen @ 2019-02-21 17:15 UTC (permalink / raw)
To: Ben Greear, Kalle Valo
Cc: Grant Grundler, Kan Yan, linux-wireless, Johannes Berg, wgong,
ath10k, wgong
In-Reply-To: <587631dd-f96a-999a-d61d-e5df5796766f@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 2/21/19 8:37 AM, Toke Høiland-Jørgensen wrote:
>> Ben Greear <greearb@candelatech.com> writes:
>>
>>> On 2/21/19 8:10 AM, Kalle Valo wrote:
>>>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>>>>
>>>>> Grant Grundler <grundler@google.com> writes:
>>>>>
>>>>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>>>>
>>>>>>> Grant Grundler <grundler@google.com> writes:
>>>>>>>
>>>>>>>>> And, well, Grant's data is from a single test in a noisy
>>>>>>>>> environment where the time series graph shows that throughput is all over
>>>>>>>>> the place for the duration of the test; so it's hard to draw solid
>>>>>>>>> conclusions from (for instance, for the 5-stream test, the average
>>>>>>>>> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>>>>>>>>> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>>>>>>>>> used in this test, so I can't go verify it myself; so the only thing I
>>>>>>>>> can do is grumble about it here... :)
>>>>>>>>
>>>>>>>> It's a fair complaint and I agree with it. My counter argument is the
>>>>>>>> opposite is true too: most ideal benchmarks don't measure what most
>>>>>>>> users see. While the data wgong provided are way more noisy than I
>>>>>>>> like, my overall "confidence" in the "conclusion" I offered is still
>>>>>>>> positive.
>>>>>>>
>>>>>>> Right. I guess I would just prefer a slightly more comprehensive
>>>>>>> evaluation to base a 4x increase in buffer size on...
>>>>>>
>>>>>> Kalle, is this why you didn't accept this patch? Other reasons?
>>>>>>
>>>>>> Toke, what else would you like to see evaluated?
>>>>>>
>>>>>> I generally want to see three things measured when "benchmarking"
>>>>>> technologies: throughput, latency, cpu utilization
>>>>>> We've covered those three I think "reasonably".
>>>>>
>>>>> Hmm, going back and looking at this (I'd completely forgotten about this
>>>>> patch), I think I had two main concerns:
>>>>>
>>>>> 1. What happens in a degraded signal situation, where the throughput is
>>>>> limited by the signal conditions, or by contention with other devices.
>>>>> Both of these happen regularly, and I worry that latency will be
>>>>> badly affected under those conditions.
>>>>>
>>>>> 2. What happens with old hardware that has worse buffer management in
>>>>> the driver->firmware path (especially drivers without push/pull mode
>>>>> support)? For these, the lower-level queueing structure is less
>>>>> effective at controlling queueing latency.
>>>>
>>>> Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377
>>>> PCI devices, which IIRC do not even support push/pull mode. All the
>>>> rest, including QCA988X and QCA9984 are unaffected.
>>>
>>> Just as a note, at least kernels such as 4.14.whatever perform poorly when
>>> running ath10k on 9984 when acting as TCP endpoints. This makes them not
>>> really usable for stuff like serving video to lots of clients.
>>>
>>> Tweaking TCP (I do it a bit differently, but either way) can significantly
>>> improve performance.
>>
>> Differently how? Did you have to do more than fiddle with the pacing_shift?
>
> This one, or a slightly tweaked version that applies to different kernels:
>
> https://github.com/greearb/linux-ct-4.16/commit/3e14e8491a5b31ce994fb2752347145e6ab7eaf5
Right; but the current mac80211 default (pacing shift 8) corresponds to
setting your sysctl to 4...
>>> Recently I helped a user that could get barely 70 stations streaming
>>> at 1Mbps on stock kernel (using one wave1 on 2.4, one wave-2 on 5Ghz),
>>> and we got 110 working with a tweaked TCP stack. These were /n
>>> stations too.
>>>
>>> I think it is lame that it _still_ requires out of tree patches to
>>> make TCP work well on ath10k...even if you want to default to current
>>> behaviour, you should allow users to tweak it to work with their use
>>> case.
>>
>> Well if TCP is broken to the point of being unusable I do think we
>> should fix it; but I think "just provide a configuration knob" should be
>> the last resort...
>
> So, it has been broken for years, and waiting for a perfect solution
> has not gotten the problem fixed.
Well, the current default should at least be closer to something that
works well.
I do think I may have erred on the wrong side of the optimum when I
submitted the original patch to set the default to 8; that should
probably have been 7 (i.e., 8 ms; the optimum in the evaluation we did
was around 6 ms, which is sadly not a power of two). Maybe changing that
default is actually better than having to redo the testing for all the
different devices as we're discussing in the context of this patch.
Maybe I should just send a patch to do that...
-Toke
^ permalink raw reply
* Re: [PATCH v2 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips
From: Ben Greear @ 2019-02-21 17:29 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Kalle Valo
Cc: Grant Grundler, Kan Yan, linux-wireless, Johannes Berg, wgong,
ath10k, wgong
In-Reply-To: <87d0nlhxl9.fsf@toke.dk>
On 2/21/19 9:15 AM, Toke Høiland-Jørgensen wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 2/21/19 8:37 AM, Toke Høiland-Jørgensen wrote:
>>> Ben Greear <greearb@candelatech.com> writes:
>>>
>>>> On 2/21/19 8:10 AM, Kalle Valo wrote:
>>>>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>>>>>
>>>>>> Grant Grundler <grundler@google.com> writes:
>>>>>>
>>>>>>> On Thu, Sep 6, 2018 at 3:18 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>>>>>>>
>>>>>>>> Grant Grundler <grundler@google.com> writes:
>>>>>>>>
>>>>>>>>>> And, well, Grant's data is from a single test in a noisy
>>>>>>>>>> environment where the time series graph shows that throughput is all over
>>>>>>>>>> the place for the duration of the test; so it's hard to draw solid
>>>>>>>>>> conclusions from (for instance, for the 5-stream test, the average
>>>>>>>>>> throughput for 6 is 331 and 379 Mbps for the two repetitions, and for 7
>>>>>>>>>> it's 326 and 371 Mbps) . Unfortunately I don't have the same hardware
>>>>>>>>>> used in this test, so I can't go verify it myself; so the only thing I
>>>>>>>>>> can do is grumble about it here... :)
>>>>>>>>>
>>>>>>>>> It's a fair complaint and I agree with it. My counter argument is the
>>>>>>>>> opposite is true too: most ideal benchmarks don't measure what most
>>>>>>>>> users see. While the data wgong provided are way more noisy than I
>>>>>>>>> like, my overall "confidence" in the "conclusion" I offered is still
>>>>>>>>> positive.
>>>>>>>>
>>>>>>>> Right. I guess I would just prefer a slightly more comprehensive
>>>>>>>> evaluation to base a 4x increase in buffer size on...
>>>>>>>
>>>>>>> Kalle, is this why you didn't accept this patch? Other reasons?
>>>>>>>
>>>>>>> Toke, what else would you like to see evaluated?
>>>>>>>
>>>>>>> I generally want to see three things measured when "benchmarking"
>>>>>>> technologies: throughput, latency, cpu utilization
>>>>>>> We've covered those three I think "reasonably".
>>>>>>
>>>>>> Hmm, going back and looking at this (I'd completely forgotten about this
>>>>>> patch), I think I had two main concerns:
>>>>>>
>>>>>> 1. What happens in a degraded signal situation, where the throughput is
>>>>>> limited by the signal conditions, or by contention with other devices.
>>>>>> Both of these happen regularly, and I worry that latency will be
>>>>>> badly affected under those conditions.
>>>>>>
>>>>>> 2. What happens with old hardware that has worse buffer management in
>>>>>> the driver->firmware path (especially drivers without push/pull mode
>>>>>> support)? For these, the lower-level queueing structure is less
>>>>>> effective at controlling queueing latency.
>>>>>
>>>>> Do note that this patch changes behaviour _only_ for QCA6174 and QCA9377
>>>>> PCI devices, which IIRC do not even support push/pull mode. All the
>>>>> rest, including QCA988X and QCA9984 are unaffected.
>>>>
>>>> Just as a note, at least kernels such as 4.14.whatever perform poorly when
>>>> running ath10k on 9984 when acting as TCP endpoints. This makes them not
>>>> really usable for stuff like serving video to lots of clients.
>>>>
>>>> Tweaking TCP (I do it a bit differently, but either way) can significantly
>>>> improve performance.
>>>
>>> Differently how? Did you have to do more than fiddle with the pacing_shift?
>>
>> This one, or a slightly tweaked version that applies to different kernels:
>>
>> https://github.com/greearb/linux-ct-4.16/commit/3e14e8491a5b31ce994fb2752347145e6ab7eaf5
>
> Right; but the current mac80211 default (pacing shift 8) corresponds to
> setting your sysctl to 4...
>
>>>> Recently I helped a user that could get barely 70 stations streaming
>>>> at 1Mbps on stock kernel (using one wave1 on 2.4, one wave-2 on 5Ghz),
>>>> and we got 110 working with a tweaked TCP stack. These were /n
>>>> stations too.
>>>>
>>>> I think it is lame that it _still_ requires out of tree patches to
>>>> make TCP work well on ath10k...even if you want to default to current
>>>> behaviour, you should allow users to tweak it to work with their use
>>>> case.
>>>
>>> Well if TCP is broken to the point of being unusable I do think we
>>> should fix it; but I think "just provide a configuration knob" should be
>>> the last resort...
>>
>> So, it has been broken for years, and waiting for a perfect solution
>> has not gotten the problem fixed.
>
> Well, the current default should at least be closer to something that
> works well.
>
> I do think I may have erred on the wrong side of the optimum when I
> submitted the original patch to set the default to 8; that should
> probably have been 7 (i.e., 8 ms; the optimum in the evaluation we did
> was around 6 ms, which is sadly not a power of two). Maybe changing that
> default is actually better than having to redo the testing for all the
> different devices as we're discussing in the context of this patch.
> Maybe I should just send a patch to do that...
It is hubris to think one setting works well for everyone. Sure, set a good
default, but also let people tune the value.
And send the patches to stable so that users on older kernels can have good
performance.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] mac80211: Change default tx_sk_pacing_shift to 7
From: Toke Høiland-Jørgensen @ 2019-02-21 17:29 UTC (permalink / raw)
To: linux-wireless
Cc: Ben Greear, Grant Grundler, Kalle Valo, wgong, ath10k, wgong,
Johannes Berg, Kan Yan, Toke Høiland-Jørgensen
In-Reply-To: <87d0nlhxl9.fsf@toke.dk>
When we did the original tests for the optimal value of sk_pacing_shift, we
came up with 6 ms of buffering as the default. Sadly, 6 is not a power of
two, so when picking the shift value I erred on the size of less buffering
and picked 4 ms instead of 8. This was probably wrong; those 2 ms of extra
buffering makes a larger difference than I thought.
So, change the default pacing shift to 7, which corresponds to 8 ms of
buffering. The point of diminishing returns really kicks in after 8 ms, and
so having this as a default should cut down on the need for extensive
per-device testing and overrides needed in the drivers.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
---
net/mac80211/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5055aeba5c5a..800e67615e2a 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -617,13 +617,13 @@ struct ieee80211_hw *ieee80211_alloc_hw_nm(size_t priv_data_len,
* We need a bit of data queued to build aggregates properly, so
* instruct the TCP stack to allow more than a single ms of data
* to be queued in the stack. The value is a bit-shift of 1
- * second, so 8 is ~4ms of queued data. Only affects local TCP
+ * second, so 7 is ~8ms of queued data. Only affects local TCP
* sockets.
* This is the default, anyhow - drivers may need to override it
* for local reasons (longer buffers, longer completion time, or
* similar).
*/
- local->hw.tx_sk_pacing_shift = 8;
+ local->hw.tx_sk_pacing_shift = 7;
/* set up some defaults */
local->hw.queues = 1;
--
2.20.1
^ permalink raw reply related
* [bug report] libertas_tf: don't defer firmware loading until start()
From: Dan Carpenter @ 2019-02-21 18:29 UTC (permalink / raw)
To: lkundrak; +Cc: linux-wireless
Hello Lubomir Rintel,
This is a semi-automatic email about new static checker warnings.
The patch baa0280f08c7: "libertas_tf: don't defer firmware loading
until start()" from Feb 20, 2019, leads to the following Smatch
complaint:
drivers/net/wireless/marvell/libertas_tf/if_usb.c:256 if_usb_disconnect()
warn: variable dereferenced before check 'priv' (see line 254)
drivers/net/wireless/marvell/libertas_tf/if_usb.c
253
254 if_usb_reset_device(priv);
^^^^^
The patch introduces a new dereference (inside the function).
255
256 if (priv)
^^^^
Old code assumes "priv" could be NULL.
257 lbtf_remove_card(priv);
258
regards,
dan carpenter
^ permalink raw reply
* [PATCH 0/8] rtlwifi: Fix some cosmetic errors
From: Larry Finger @ 2019-02-21 19:31 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
This set of patches fix some of the cosmetic checks, errors, or
warnings reported by checkpatch.pl. None of these affect the
generated code.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry Finger (8):
rtlwifi: Fix errors in spacing in wifi.h
rtlwifi: Fix problems with block comments in wifi.h
rtlwifi: Fix alignment errors in wifi.h
rtlwifi: Fix blank line errors in main header files
rtlwifi: Fix all blank line irregularities in main code files
rtlwifi: rtl8192ce: Fix missing blank lines
rtlwifi: rtl8192cu: Fix problems with blank lines
rtlwifi: rtl8192com: Fix blank line problems
drivers/net/wireless/realtek/rtlwifi/base.c | 7 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 8 +
drivers/net/wireless/realtek/rtlwifi/efuse.c | 8 +-
drivers/net/wireless/realtek/rtlwifi/ps.c | 1 +
drivers/net/wireless/realtek/rtlwifi/rc.c | 2 +
drivers/net/wireless/realtek/rtlwifi/regd.c | 1 -
.../realtek/rtlwifi/rtl8192c/dm_common.c | 6 +-
.../realtek/rtlwifi/rtl8192c/fw_common.c | 5 +-
.../wireless/realtek/rtlwifi/rtl8192c/main.c | 1 -
.../realtek/rtlwifi/rtl8192c/phy_common.c | 1 +
.../wireless/realtek/rtlwifi/rtl8192ce/hw.c | 7 +-
.../wireless/realtek/rtlwifi/rtl8192ce/phy.c | 1 +
.../realtek/rtlwifi/rtl8192ce/table.c | 1 -
.../wireless/realtek/rtlwifi/rtl8192ce/trx.c | 8 +
.../wireless/realtek/rtlwifi/rtl8192cu/hw.c | 9 +-
.../wireless/realtek/rtlwifi/rtl8192cu/hw.h | 4 -
.../wireless/realtek/rtlwifi/rtl8192cu/mac.c | 8 +-
.../wireless/realtek/rtlwifi/rtl8192cu/mac.h | 3 -
.../wireless/realtek/rtlwifi/rtl8192cu/trx.c | 7 +
.../wireless/realtek/rtlwifi/rtl8192cu/trx.h | 2 -
drivers/net/wireless/realtek/rtlwifi/usb.c | 3 +
drivers/net/wireless/realtek/rtlwifi/usb.h | 5 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 351 +++++++++---------
23 files changed, 245 insertions(+), 204 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH 1/8] rtlwifi: Fix errors in spacing in wifi.h
From: Larry Finger @ 2019-02-21 19:31 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190221193115.30848-1-Larry.Finger@lwfinger.net>
Checkpatch.pl report problems in wifi.h where spaces are missing, as well
as extraneous spaces.
There are no changes in the generated code.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 170 ++++++++++----------
1 file changed, 85 insertions(+), 85 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 1ad71fb0ebf2..858cd798d5cb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -413,8 +413,8 @@ enum hw_variables {
HW_VAR_MULTICAST_REG = 0x1,
HW_VAR_BASIC_RATE = 0x2,
HW_VAR_BSSID = 0x3,
- HW_VAR_MEDIA_STATUS= 0x4,
- HW_VAR_SECURITY_CONF= 0x5,
+ HW_VAR_MEDIA_STATUS = 0x4,
+ HW_VAR_SECURITY_CONF = 0x5,
HW_VAR_BEACON_INTERVAL = 0x6,
HW_VAR_ATIM_WINDOW = 0x7,
HW_VAR_LISTEN_INTERVAL = 0x8,
@@ -431,7 +431,7 @@ enum hw_variables {
HW_VAR_ACK_PREAMBLE = 0x13,
HW_VAR_CW_CONFIG = 0x14,
HW_VAR_CW_VALUES = 0x15,
- HW_VAR_RATE_FALLBACK_CONTROL= 0x16,
+ HW_VAR_RATE_FALLBACK_CONTROL = 0x16,
HW_VAR_CONTENTION_WINDOW = 0x17,
HW_VAR_RETRY_COUNT = 0x18,
HW_VAR_TR_SWITCH = 0x19,
@@ -1456,15 +1456,15 @@ struct rtl_io {
/*PCI IO map */
unsigned long pci_base_addr; /*device I/O address */
- void (*write8_async) (struct rtl_priv *rtlpriv, u32 addr, u8 val);
- void (*write16_async) (struct rtl_priv *rtlpriv, u32 addr, u16 val);
- void (*write32_async) (struct rtl_priv *rtlpriv, u32 addr, u32 val);
+ void (*write8_async)(struct rtl_priv *rtlpriv, u32 addr, u8 val);
+ void (*write16_async)(struct rtl_priv *rtlpriv, u32 addr, u16 val);
+ void (*write32_async)(struct rtl_priv *rtlpriv, u32 addr, u32 val);
void (*writen_sync)(struct rtl_priv *rtlpriv, u32 addr, void *buf,
u16 len);
- u8(*read8_sync) (struct rtl_priv *rtlpriv, u32 addr);
- u16(*read16_sync) (struct rtl_priv *rtlpriv, u32 addr);
- u32(*read32_sync) (struct rtl_priv *rtlpriv, u32 addr);
+ u8 (*read8_sync)(struct rtl_priv *rtlpriv, u32 addr);
+ u16 (*read16_sync)(struct rtl_priv *rtlpriv, u32 addr);
+ u32 (*read32_sync)(struct rtl_priv *rtlpriv, u32 addr);
};
@@ -2210,44 +2210,44 @@ struct rtl_int {
};
struct rtl_hal_ops {
- int (*init_sw_vars) (struct ieee80211_hw *hw);
- void (*deinit_sw_vars) (struct ieee80211_hw *hw);
+ int (*init_sw_vars)(struct ieee80211_hw *hw);
+ void (*deinit_sw_vars)(struct ieee80211_hw *hw);
void (*read_chip_version)(struct ieee80211_hw *hw);
- void (*read_eeprom_info) (struct ieee80211_hw *hw);
- void (*interrupt_recognized) (struct ieee80211_hw *hw,
+ void (*read_eeprom_info)(struct ieee80211_hw *hw);
+ void (*interrupt_recognized)(struct ieee80211_hw *hw,
struct rtl_int *intvec);
- int (*hw_init) (struct ieee80211_hw *hw);
- void (*hw_disable) (struct ieee80211_hw *hw);
- void (*hw_suspend) (struct ieee80211_hw *hw);
- void (*hw_resume) (struct ieee80211_hw *hw);
- void (*enable_interrupt) (struct ieee80211_hw *hw);
- void (*disable_interrupt) (struct ieee80211_hw *hw);
- int (*set_network_type) (struct ieee80211_hw *hw,
+ int (*hw_init)(struct ieee80211_hw *hw);
+ void (*hw_disable)(struct ieee80211_hw *hw);
+ void (*hw_suspend)(struct ieee80211_hw *hw);
+ void (*hw_resume)(struct ieee80211_hw *hw);
+ void (*enable_interrupt)(struct ieee80211_hw *hw);
+ void (*disable_interrupt)(struct ieee80211_hw *hw);
+ int (*set_network_type)(struct ieee80211_hw *hw,
enum nl80211_iftype type);
void (*set_chk_bssid)(struct ieee80211_hw *hw,
bool check_bssid);
- void (*set_bw_mode) (struct ieee80211_hw *hw,
+ void (*set_bw_mode)(struct ieee80211_hw *hw,
enum nl80211_channel_type ch_type);
- u8(*switch_channel) (struct ieee80211_hw *hw);
- void (*set_qos) (struct ieee80211_hw *hw, int aci);
- void (*set_bcn_reg) (struct ieee80211_hw *hw);
- void (*set_bcn_intv) (struct ieee80211_hw *hw);
- void (*update_interrupt_mask) (struct ieee80211_hw *hw,
+ u8 (*switch_channel)(struct ieee80211_hw *hw);
+ void (*set_qos)(struct ieee80211_hw *hw, int aci);
+ void (*set_bcn_reg)(struct ieee80211_hw *hw);
+ void (*set_bcn_intv)(struct ieee80211_hw *hw);
+ void (*update_interrupt_mask)(struct ieee80211_hw *hw,
u32 add_msr, u32 rm_msr);
- void (*get_hw_reg) (struct ieee80211_hw *hw, u8 variable, u8 *val);
- void (*set_hw_reg) (struct ieee80211_hw *hw, u8 variable, u8 *val);
- void (*update_rate_tbl) (struct ieee80211_hw *hw,
+ void (*get_hw_reg)(struct ieee80211_hw *hw, u8 variable, u8 *val);
+ void (*set_hw_reg)(struct ieee80211_hw *hw, u8 variable, u8 *val);
+ void (*update_rate_tbl)(struct ieee80211_hw *hw,
struct ieee80211_sta *sta, u8 rssi_leve,
bool update_bw);
void (*pre_fill_tx_bd_desc)(struct ieee80211_hw *hw, u8 *tx_bd_desc,
u8 *desc, u8 queue_index,
struct sk_buff *skb, dma_addr_t addr);
- void (*update_rate_mask) (struct ieee80211_hw *hw, u8 rssi_level);
+ void (*update_rate_mask)(struct ieee80211_hw *hw, u8 rssi_level);
u16 (*rx_desc_buff_remained_cnt)(struct ieee80211_hw *hw,
u8 queue_index);
void (*rx_check_dma_ok)(struct ieee80211_hw *hw, u8 *header_desc,
u8 queue_index);
- void (*fill_tx_desc) (struct ieee80211_hw *hw,
+ void (*fill_tx_desc)(struct ieee80211_hw *hw,
struct ieee80211_hdr *hdr, u8 *pdesc_tx,
u8 *pbd_desc_tx,
struct ieee80211_tx_info *info,
@@ -2256,68 +2256,68 @@ struct rtl_hal_ops {
struct rtl_tcb_desc *ptcb_desc);
void (*fill_fake_txdesc)(struct ieee80211_hw *hw, u8 *pdesc,
u32 buffer_len, bool bsspspoll);
- void (*fill_tx_cmddesc) (struct ieee80211_hw *hw, u8 *pdesc,
+ void (*fill_tx_cmddesc)(struct ieee80211_hw *hw, u8 *pdesc,
bool firstseg, bool lastseg,
struct sk_buff *skb);
void (*fill_tx_special_desc)(struct ieee80211_hw *hw,
u8 *pdesc, u8 *pbd_desc,
struct sk_buff *skb, u8 hw_queue);
- bool (*query_rx_desc) (struct ieee80211_hw *hw,
+ bool (*query_rx_desc)(struct ieee80211_hw *hw,
struct rtl_stats *stats,
struct ieee80211_rx_status *rx_status,
u8 *pdesc, struct sk_buff *skb);
- void (*set_channel_access) (struct ieee80211_hw *hw);
- bool (*radio_onoff_checking) (struct ieee80211_hw *hw, u8 *valid);
- void (*dm_watchdog) (struct ieee80211_hw *hw);
- void (*scan_operation_backup) (struct ieee80211_hw *hw, u8 operation);
- bool (*set_rf_power_state) (struct ieee80211_hw *hw,
+ void (*set_channel_access)(struct ieee80211_hw *hw);
+ bool (*radio_onoff_checking)(struct ieee80211_hw *hw, u8 *valid);
+ void (*dm_watchdog)(struct ieee80211_hw *hw);
+ void (*scan_operation_backup)(struct ieee80211_hw *hw, u8 operation);
+ bool (*set_rf_power_state)(struct ieee80211_hw *hw,
enum rf_pwrstate rfpwr_state);
- void (*led_control) (struct ieee80211_hw *hw,
+ void (*led_control)(struct ieee80211_hw *hw,
enum led_ctl_mode ledaction);
void (*set_desc)(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name, u8 *val);
u64 (*get_desc)(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name);
- bool (*is_tx_desc_closed) (struct ieee80211_hw *hw,
+ bool (*is_tx_desc_closed)(struct ieee80211_hw *hw,
u8 hw_queue, u16 index);
- void (*tx_polling) (struct ieee80211_hw *hw, u8 hw_queue);
- void (*enable_hw_sec) (struct ieee80211_hw *hw);
- void (*set_key) (struct ieee80211_hw *hw, u32 key_index,
+ void (*tx_polling)(struct ieee80211_hw *hw, u8 hw_queue);
+ void (*enable_hw_sec)(struct ieee80211_hw *hw);
+ void (*set_key)(struct ieee80211_hw *hw, u32 key_index,
u8 *macaddr, bool is_group, u8 enc_algo,
bool is_wepkey, bool clear_all);
- void (*init_sw_leds) (struct ieee80211_hw *hw);
- void (*deinit_sw_leds) (struct ieee80211_hw *hw);
- u32 (*get_bbreg) (struct ieee80211_hw *hw, u32 regaddr, u32 bitmask);
- void (*set_bbreg) (struct ieee80211_hw *hw, u32 regaddr, u32 bitmask,
+ void (*init_sw_leds)(struct ieee80211_hw *hw);
+ void (*deinit_sw_leds)(struct ieee80211_hw *hw);
+ u32 (*get_bbreg)(struct ieee80211_hw *hw, u32 regaddr, u32 bitmask);
+ void (*set_bbreg)(struct ieee80211_hw *hw, u32 regaddr, u32 bitmask,
u32 data);
- u32 (*get_rfreg) (struct ieee80211_hw *hw, enum radio_path rfpath,
+ u32 (*get_rfreg)(struct ieee80211_hw *hw, enum radio_path rfpath,
u32 regaddr, u32 bitmask);
- void (*set_rfreg) (struct ieee80211_hw *hw, enum radio_path rfpath,
+ void (*set_rfreg)(struct ieee80211_hw *hw, enum radio_path rfpath,
u32 regaddr, u32 bitmask, u32 data);
- void (*linked_set_reg) (struct ieee80211_hw *hw);
- void (*chk_switch_dmdp) (struct ieee80211_hw *hw);
- void (*dualmac_easy_concurrent) (struct ieee80211_hw *hw);
- void (*dualmac_switch_to_dmdp) (struct ieee80211_hw *hw);
- bool (*phy_rf6052_config) (struct ieee80211_hw *hw);
- void (*phy_rf6052_set_cck_txpower) (struct ieee80211_hw *hw,
+ void (*linked_set_reg)(struct ieee80211_hw *hw);
+ void (*chk_switch_dmdp)(struct ieee80211_hw *hw);
+ void (*dualmac_easy_concurrent)(struct ieee80211_hw *hw);
+ void (*dualmac_switch_to_dmdp)(struct ieee80211_hw *hw);
+ bool (*phy_rf6052_config)(struct ieee80211_hw *hw);
+ void (*phy_rf6052_set_cck_txpower)(struct ieee80211_hw *hw,
u8 *powerlevel);
- void (*phy_rf6052_set_ofdm_txpower) (struct ieee80211_hw *hw,
+ void (*phy_rf6052_set_ofdm_txpower)(struct ieee80211_hw *hw,
u8 *ppowerlevel, u8 channel);
- bool (*config_bb_with_headerfile) (struct ieee80211_hw *hw,
+ bool (*config_bb_with_headerfile)(struct ieee80211_hw *hw,
u8 configtype);
- bool (*config_bb_with_pgheaderfile) (struct ieee80211_hw *hw,
+ bool (*config_bb_with_pgheaderfile)(struct ieee80211_hw *hw,
u8 configtype);
- void (*phy_lc_calibrate) (struct ieee80211_hw *hw, bool is2t);
- void (*phy_set_bw_mode_callback) (struct ieee80211_hw *hw);
- void (*dm_dynamic_txpower) (struct ieee80211_hw *hw);
- void (*c2h_command_handle) (struct ieee80211_hw *hw);
- void (*bt_wifi_media_status_notify) (struct ieee80211_hw *hw,
+ void (*phy_lc_calibrate)(struct ieee80211_hw *hw, bool is2t);
+ void (*phy_set_bw_mode_callback)(struct ieee80211_hw *hw);
+ void (*dm_dynamic_txpower)(struct ieee80211_hw *hw);
+ void (*c2h_command_handle)(struct ieee80211_hw *hw);
+ void (*bt_wifi_media_status_notify)(struct ieee80211_hw *hw,
bool mstate);
- void (*bt_coex_off_before_lps) (struct ieee80211_hw *hw);
- void (*fill_h2c_cmd) (struct ieee80211_hw *hw, u8 element_id,
+ void (*bt_coex_off_before_lps)(struct ieee80211_hw *hw);
+ void (*fill_h2c_cmd)(struct ieee80211_hw *hw, u8 element_id,
u32 cmd_len, u8 *p_cmdbuffer);
void (*set_default_port_id_cmd)(struct ieee80211_hw *hw);
- bool (*get_btc_status) (void);
+ bool (*get_btc_status)(void);
bool (*is_fw_header)(struct rtlwifi_firmware_header *hdr);
void (*add_wowlan_pattern)(struct ieee80211_hw *hw,
struct rtl_wow_pattern *rtl_pattern,
@@ -2330,24 +2330,24 @@ struct rtl_hal_ops {
struct rtl_intf_ops {
/*com */
void (*read_efuse_byte)(struct ieee80211_hw *hw, u16 _offset, u8 *pbuf);
- int (*adapter_start) (struct ieee80211_hw *hw);
- void (*adapter_stop) (struct ieee80211_hw *hw);
+ int (*adapter_start)(struct ieee80211_hw *hw);
+ void (*adapter_stop)(struct ieee80211_hw *hw);
bool (*check_buddy_priv)(struct ieee80211_hw *hw,
struct rtl_priv **buddy_priv);
- int (*adapter_tx) (struct ieee80211_hw *hw,
+ int (*adapter_tx)(struct ieee80211_hw *hw,
struct ieee80211_sta *sta,
struct sk_buff *skb,
struct rtl_tcb_desc *ptcb_desc);
void (*flush)(struct ieee80211_hw *hw, u32 queues, bool drop);
- int (*reset_trx_ring) (struct ieee80211_hw *hw);
- bool (*waitq_insert) (struct ieee80211_hw *hw,
+ int (*reset_trx_ring)(struct ieee80211_hw *hw);
+ bool (*waitq_insert)(struct ieee80211_hw *hw,
struct ieee80211_sta *sta,
struct sk_buff *skb);
/*pci */
- void (*disable_aspm) (struct ieee80211_hw *hw);
- void (*enable_aspm) (struct ieee80211_hw *hw);
+ void (*disable_aspm)(struct ieee80211_hw *hw);
+ void (*enable_aspm)(struct ieee80211_hw *hw);
/*usb */
};
@@ -2666,30 +2666,30 @@ struct bt_coexist_info {
};
struct rtl_btc_ops {
- void (*btc_init_variables) (struct rtl_priv *rtlpriv);
+ void (*btc_init_variables)(struct rtl_priv *rtlpriv);
void (*btc_init_variables_wifi_only)(struct rtl_priv *rtlpriv);
void (*btc_deinit_variables)(struct rtl_priv *rtlpriv);
- void (*btc_init_hal_vars) (struct rtl_priv *rtlpriv);
+ void (*btc_init_hal_vars)(struct rtl_priv *rtlpriv);
void (*btc_power_on_setting)(struct rtl_priv *rtlpriv);
- void (*btc_init_hw_config) (struct rtl_priv *rtlpriv);
+ void (*btc_init_hw_config)(struct rtl_priv *rtlpriv);
void (*btc_init_hw_config_wifi_only)(struct rtl_priv *rtlpriv);
- void (*btc_ips_notify) (struct rtl_priv *rtlpriv, u8 type);
+ void (*btc_ips_notify)(struct rtl_priv *rtlpriv, u8 type);
void (*btc_lps_notify)(struct rtl_priv *rtlpriv, u8 type);
- void (*btc_scan_notify) (struct rtl_priv *rtlpriv, u8 scantype);
+ void (*btc_scan_notify)(struct rtl_priv *rtlpriv, u8 scantype);
void (*btc_scan_notify_wifi_only)(struct rtl_priv *rtlpriv,
u8 scantype);
- void (*btc_connect_notify) (struct rtl_priv *rtlpriv, u8 action);
- void (*btc_mediastatus_notify) (struct rtl_priv *rtlpriv,
+ void (*btc_connect_notify)(struct rtl_priv *rtlpriv, u8 action);
+ void (*btc_mediastatus_notify)(struct rtl_priv *rtlpriv,
enum rt_media_status mstatus);
- void (*btc_periodical) (struct rtl_priv *rtlpriv);
+ void (*btc_periodical)(struct rtl_priv *rtlpriv);
void (*btc_halt_notify)(struct rtl_priv *rtlpriv);
- void (*btc_btinfo_notify) (struct rtl_priv *rtlpriv,
+ void (*btc_btinfo_notify)(struct rtl_priv *rtlpriv,
u8 *tmp_buf, u8 length);
void (*btc_btmpinfo_notify)(struct rtl_priv *rtlpriv,
u8 *tmp_buf, u8 length);
- bool (*btc_is_limited_dig) (struct rtl_priv *rtlpriv);
- bool (*btc_is_disable_edca_turbo) (struct rtl_priv *rtlpriv);
- bool (*btc_is_bt_disabled) (struct rtl_priv *rtlpriv);
+ bool (*btc_is_limited_dig)(struct rtl_priv *rtlpriv);
+ bool (*btc_is_disable_edca_turbo)(struct rtl_priv *rtlpriv);
+ bool (*btc_is_bt_disabled)(struct rtl_priv *rtlpriv);
void (*btc_special_packet_notify)(struct rtl_priv *rtlpriv,
u8 pkt_type);
void (*btc_switch_band_notify)(struct rtl_priv *rtlpriv, u8 type,
--
2.20.1
^ permalink raw reply related
* [PATCH 2/8] rtlwifi: Fix problems with block comments in wifi.h
From: Larry Finger @ 2019-02-21 19:31 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190221193115.30848-1-Larry.Finger@lwfinger.net>
Checkpatch.pl reports a number of problems with block comments.
These changes do not affect the generated code.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 93 +++++++++++----------
1 file changed, 50 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 858cd798d5cb..9fe137fa5ead 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -598,7 +598,8 @@ enum ht_channel_width {
};
/* Ref: 802.11i sepc D10.0 7.3.2.25.1
-Cipher Suites Encryption Algorithms */
+ * Cipher Suites Encryption Algorithms
+ */
enum rt_enc_alg {
NO_ENCRYPTION = 0,
WEP40_ENCRYPTION = 1,
@@ -748,7 +749,8 @@ enum rtl_var_map {
RTL_IMR_ROK, /*Receive DMA OK Interrupt */
RTL_IMR_HSISR_IND, /*HSISR Interrupt*/
RTL_IBSS_INT_MASKS, /*(RTL_IMR_BCNINT | RTL_IMR_TBDOK |
- * RTL_IMR_TBDER) */
+ * RTL_IMR_TBDER)
+ */
RTL_IMR_C2HCMD, /*fw interrupt*/
/*CCK Rates, TxHT = 0 */
@@ -845,8 +847,9 @@ enum band_type {
BANDMAX
};
-/*aci/aifsn Field.
-Ref: WMM spec 2.2.2: WME Parameter Element, p.12.*/
+/* aci/aifsn Field.
+ * Ref: WMM spec 2.2.2: WME Parameter Element, p.12.
+ */
union aci_aifsn {
u8 char_data;
@@ -1062,7 +1065,8 @@ struct rtl_probe_rsp {
__le16 beacon_interval;
__le16 capability;
/*SSID, supported rates, FH params, DS params,
- CF params, IBSS params, TIM (if beacon), RSN */
+ * CF params, IBSS params, TIM (if beacon), RSN
+ */
struct rtl_info_element info_element[0];
} __packed;
@@ -1136,7 +1140,8 @@ struct wireless_stats {
long rx_snr_db[4];
/*Correct smoothed ss in Dbm, only used
- in driver to report real power now. */
+ * in driver to report real power now.
+ */
long recv_signal_power;
long signal_quality;
long last_sigstrength_inpercent;
@@ -1144,8 +1149,9 @@ struct wireless_stats {
u32 rssi_calculate_cnt;
u32 pwdb_all_cnt;
- /*Transformed, in dbm. Beautified signal
- strength for UI, not correct. */
+ /* Transformed, in dbm. Beautified signal
+ * strength for UI, not correct.
+ */
long signal_strength;
u8 rx_rssi_percentage[4];
@@ -1689,7 +1695,8 @@ struct rtl_hal {
bool during_mac1init_radioa;
bool reloadtxpowerindex;
/* True if IMR or IQK have done
- for 2.4G in scan progress */
+ * for 2.4G in scan progress
+ */
bool load_imrandiqk_setting_for2g;
bool disable_amsdu_8k;
@@ -1728,12 +1735,14 @@ struct rtl_security {
u32 hwsec_cam_bitmap;
u8 hwsec_cam_sta_addr[TOTAL_CAM_ENTRY][ETH_ALEN];
/*local Key buffer, indx 0 is for
- pairwise key 1-4 is for agoup key. */
+ * pairwise key 1-4 is for agoup key.
+ */
u8 key_buf[KEY_BUF_SIZE][MAX_KEY_LEN];
u8 key_len[KEY_BUF_SIZE];
/*The pointer of Pairwise Key,
- it always points to KeyBuf[4] */
+ * it always points to KeyBuf[4]
+ */
u8 *pairwise_key;
};
@@ -1997,11 +2006,10 @@ struct rtl_ps_ctl {
bool rfchange_inprogress;
bool swrf_processing;
bool hwradiooff;
- /*
- * just for PCIE ASPM
+ /* just for PCIE ASPM
* If it supports ASPM, Offset[560h] = 0x40,
* otherwise Offset[560h] = 0x00.
- * */
+ */
bool support_aspm;
bool support_backdoor;
@@ -2081,10 +2089,9 @@ struct rtl_stats {
u8 nic_type;
u16 length;
u8 signalquality; /*in 0-100 index. */
- /*
- * Real power in dBm for this packet,
+ /* Real power in dBm for this packet,
* no beautification and aggregation.
- * */
+ */
s32 recvsignalpower;
s8 rxpower; /*in dBm Translate from PWdB */
u8 signalstrength; /*in 0-100 index. */
@@ -2425,7 +2432,8 @@ struct rtl_hal_cfg {
enum rtl_spec_ver spec_ver;
/*this map used for some registers or vars
- defined int HAL but used in MAIN */
+ * defined int HAL but used in MAIN
+ */
u32 maps[RTL_VAR_MAP_MAX];
};
@@ -2587,7 +2595,8 @@ struct dig_t {
struct rtl_global_var {
/* from this list we can get
- * other adapter's rtl_priv */
+ * other adapter's rtl_priv
+ */
struct list_head glb_priv_list;
spinlock_t glb_list_lock;
};
@@ -2775,16 +2784,16 @@ struct rtl_priv {
struct rtl_debug dbg;
int max_fw_size;
- /*
- *hal_cfg : for diff cards
- *intf_ops : for diff interrface usb/pcie
+ /* hal_cfg : for diff cards
+ * intf_ops : for diff interrface usb/pcie
*/
struct rtl_hal_cfg *cfg;
const struct rtl_intf_ops *intf_ops;
- /*this var will be set by set_bit,
- and was used to indicate status of
- interface or hardware */
+ /* this var will be set by set_bit,
+ * and was used to indicate status of
+ * interface or hardware
+ */
unsigned long status;
/* tables for dm */
@@ -2820,10 +2829,11 @@ struct rtl_priv {
#ifdef CONFIG_PM
struct wiphy_wowlan_support wowlan;
#endif
- /*This must be the last item so
- that it points to the data allocated
- beyond this structure like:
- rtl_pci_priv or rtl_usb_priv */
+ /* This must be the last item so
+ * that it points to the data allocated
+ * beyond this structure like:
+ * rtl_pci_priv or rtl_usb_priv
+ */
u8 priv[0] __aligned(sizeof(void *));
};
@@ -2834,9 +2844,7 @@ struct rtl_priv {
#define rtl_psc(rtlpriv) (&((rtlpriv)->psc))
-/***************************************
- Bluetooth Co-existence Related
-****************************************/
+/* Bluetooth Co-existence Related */
enum bt_ant_num {
ANT_X2 = 0,
@@ -2887,12 +2895,12 @@ enum bt_radio_shared {
/****************************************
- mem access macro define start
- Call endian free function when
- 1. Read/write packet content.
- 2. Before write integer to IO.
- 3. After read integer from IO.
-****************************************/
+ * mem access macro define start
+ * Call endian free function when
+ * 1. Read/write packet content.
+ * 2. Before write integer to IO.
+ * 3. After read integer from IO.
+ ****************************************/
/* Convert little data endian to host ordering */
#define EF1BYTE(_val) \
((u8)(_val))
@@ -2948,8 +2956,9 @@ enum bt_radio_shared {
(EF1BYTE(*((u8 *)(__pstart))))
/*Description:
-Translate subfield (continuous bits in little-endian) of 4-byte
-value to host byte ordering.*/
+ * Translate subfield (continuous bits in little-endian) of 4-byte
+ * value to host byte ordering.
+ */
#define LE_BITS_TO_4BYTE(__pstart, __bitoffset, __bitlen) \
( \
(LE_P4BYTE_TO_HOST_4BYTE(__pstart) >> (__bitoffset)) & \
@@ -3011,9 +3020,7 @@ value to host byte ordering.*/
#define N_BYTE_ALIGMENT(__value, __aligment) ((__aligment == 1) ? \
(__value) : (((__value + __aligment - 1) / __aligment) * __aligment))
-/****************************************
- mem access macro define end
-****************************************/
+/* mem access macro define end */
#define byte(x, n) ((x >> (8 * n)) & 0xff)
--
2.20.1
^ permalink raw reply related
* [PATCH 3/8] rtlwifi: Fix alignment errors in wifi.h
From: Larry Finger @ 2019-02-21 19:31 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190221193115.30848-1-Larry.Finger@lwfinger.net>
The instances where statement continuations are improperly aligned have
been fixed.
There are no changes to generated code.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/wifi.h | 84 ++++++++++-----------
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 9fe137fa5ead..88f94662c072 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -1466,7 +1466,7 @@ struct rtl_io {
void (*write16_async)(struct rtl_priv *rtlpriv, u32 addr, u16 val);
void (*write32_async)(struct rtl_priv *rtlpriv, u32 addr, u32 val);
void (*writen_sync)(struct rtl_priv *rtlpriv, u32 addr, void *buf,
- u16 len);
+ u16 len);
u8 (*read8_sync)(struct rtl_priv *rtlpriv, u32 addr);
u16 (*read16_sync)(struct rtl_priv *rtlpriv, u32 addr);
@@ -2222,7 +2222,7 @@ struct rtl_hal_ops {
void (*read_chip_version)(struct ieee80211_hw *hw);
void (*read_eeprom_info)(struct ieee80211_hw *hw);
void (*interrupt_recognized)(struct ieee80211_hw *hw,
- struct rtl_int *intvec);
+ struct rtl_int *intvec);
int (*hw_init)(struct ieee80211_hw *hw);
void (*hw_disable)(struct ieee80211_hw *hw);
void (*hw_suspend)(struct ieee80211_hw *hw);
@@ -2230,22 +2230,22 @@ struct rtl_hal_ops {
void (*enable_interrupt)(struct ieee80211_hw *hw);
void (*disable_interrupt)(struct ieee80211_hw *hw);
int (*set_network_type)(struct ieee80211_hw *hw,
- enum nl80211_iftype type);
+ enum nl80211_iftype type);
void (*set_chk_bssid)(struct ieee80211_hw *hw,
- bool check_bssid);
+ bool check_bssid);
void (*set_bw_mode)(struct ieee80211_hw *hw,
- enum nl80211_channel_type ch_type);
+ enum nl80211_channel_type ch_type);
u8 (*switch_channel)(struct ieee80211_hw *hw);
void (*set_qos)(struct ieee80211_hw *hw, int aci);
void (*set_bcn_reg)(struct ieee80211_hw *hw);
void (*set_bcn_intv)(struct ieee80211_hw *hw);
void (*update_interrupt_mask)(struct ieee80211_hw *hw,
- u32 add_msr, u32 rm_msr);
+ u32 add_msr, u32 rm_msr);
void (*get_hw_reg)(struct ieee80211_hw *hw, u8 variable, u8 *val);
void (*set_hw_reg)(struct ieee80211_hw *hw, u8 variable, u8 *val);
void (*update_rate_tbl)(struct ieee80211_hw *hw,
- struct ieee80211_sta *sta, u8 rssi_leve,
- bool update_bw);
+ struct ieee80211_sta *sta, u8 rssi_leve,
+ bool update_bw);
void (*pre_fill_tx_bd_desc)(struct ieee80211_hw *hw, u8 *tx_bd_desc,
u8 *desc, u8 queue_index,
struct sk_buff *skb, dma_addr_t addr);
@@ -2255,74 +2255,74 @@ struct rtl_hal_ops {
void (*rx_check_dma_ok)(struct ieee80211_hw *hw, u8 *header_desc,
u8 queue_index);
void (*fill_tx_desc)(struct ieee80211_hw *hw,
- struct ieee80211_hdr *hdr, u8 *pdesc_tx,
- u8 *pbd_desc_tx,
- struct ieee80211_tx_info *info,
- struct ieee80211_sta *sta,
- struct sk_buff *skb, u8 hw_queue,
- struct rtl_tcb_desc *ptcb_desc);
+ struct ieee80211_hdr *hdr, u8 *pdesc_tx,
+ u8 *pbd_desc_tx,
+ struct ieee80211_tx_info *info,
+ struct ieee80211_sta *sta,
+ struct sk_buff *skb, u8 hw_queue,
+ struct rtl_tcb_desc *ptcb_desc);
void (*fill_fake_txdesc)(struct ieee80211_hw *hw, u8 *pdesc,
u32 buffer_len, bool bsspspoll);
void (*fill_tx_cmddesc)(struct ieee80211_hw *hw, u8 *pdesc,
- bool firstseg, bool lastseg,
- struct sk_buff *skb);
+ bool firstseg, bool lastseg,
+ struct sk_buff *skb);
void (*fill_tx_special_desc)(struct ieee80211_hw *hw,
u8 *pdesc, u8 *pbd_desc,
struct sk_buff *skb, u8 hw_queue);
bool (*query_rx_desc)(struct ieee80211_hw *hw,
- struct rtl_stats *stats,
- struct ieee80211_rx_status *rx_status,
- u8 *pdesc, struct sk_buff *skb);
+ struct rtl_stats *stats,
+ struct ieee80211_rx_status *rx_status,
+ u8 *pdesc, struct sk_buff *skb);
void (*set_channel_access)(struct ieee80211_hw *hw);
bool (*radio_onoff_checking)(struct ieee80211_hw *hw, u8 *valid);
void (*dm_watchdog)(struct ieee80211_hw *hw);
void (*scan_operation_backup)(struct ieee80211_hw *hw, u8 operation);
bool (*set_rf_power_state)(struct ieee80211_hw *hw,
- enum rf_pwrstate rfpwr_state);
+ enum rf_pwrstate rfpwr_state);
void (*led_control)(struct ieee80211_hw *hw,
- enum led_ctl_mode ledaction);
+ enum led_ctl_mode ledaction);
void (*set_desc)(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name, u8 *val);
u64 (*get_desc)(struct ieee80211_hw *hw, u8 *pdesc, bool istx,
u8 desc_name);
bool (*is_tx_desc_closed)(struct ieee80211_hw *hw,
- u8 hw_queue, u16 index);
+ u8 hw_queue, u16 index);
void (*tx_polling)(struct ieee80211_hw *hw, u8 hw_queue);
void (*enable_hw_sec)(struct ieee80211_hw *hw);
void (*set_key)(struct ieee80211_hw *hw, u32 key_index,
- u8 *macaddr, bool is_group, u8 enc_algo,
- bool is_wepkey, bool clear_all);
+ u8 *macaddr, bool is_group, u8 enc_algo,
+ bool is_wepkey, bool clear_all);
void (*init_sw_leds)(struct ieee80211_hw *hw);
void (*deinit_sw_leds)(struct ieee80211_hw *hw);
u32 (*get_bbreg)(struct ieee80211_hw *hw, u32 regaddr, u32 bitmask);
void (*set_bbreg)(struct ieee80211_hw *hw, u32 regaddr, u32 bitmask,
- u32 data);
+ u32 data);
u32 (*get_rfreg)(struct ieee80211_hw *hw, enum radio_path rfpath,
- u32 regaddr, u32 bitmask);
+ u32 regaddr, u32 bitmask);
void (*set_rfreg)(struct ieee80211_hw *hw, enum radio_path rfpath,
- u32 regaddr, u32 bitmask, u32 data);
+ u32 regaddr, u32 bitmask, u32 data);
void (*linked_set_reg)(struct ieee80211_hw *hw);
void (*chk_switch_dmdp)(struct ieee80211_hw *hw);
void (*dualmac_easy_concurrent)(struct ieee80211_hw *hw);
void (*dualmac_switch_to_dmdp)(struct ieee80211_hw *hw);
bool (*phy_rf6052_config)(struct ieee80211_hw *hw);
void (*phy_rf6052_set_cck_txpower)(struct ieee80211_hw *hw,
- u8 *powerlevel);
+ u8 *powerlevel);
void (*phy_rf6052_set_ofdm_txpower)(struct ieee80211_hw *hw,
- u8 *ppowerlevel, u8 channel);
+ u8 *ppowerlevel, u8 channel);
bool (*config_bb_with_headerfile)(struct ieee80211_hw *hw,
- u8 configtype);
+ u8 configtype);
bool (*config_bb_with_pgheaderfile)(struct ieee80211_hw *hw,
- u8 configtype);
+ u8 configtype);
void (*phy_lc_calibrate)(struct ieee80211_hw *hw, bool is2t);
void (*phy_set_bw_mode_callback)(struct ieee80211_hw *hw);
void (*dm_dynamic_txpower)(struct ieee80211_hw *hw);
void (*c2h_command_handle)(struct ieee80211_hw *hw);
void (*bt_wifi_media_status_notify)(struct ieee80211_hw *hw,
- bool mstate);
+ bool mstate);
void (*bt_coex_off_before_lps)(struct ieee80211_hw *hw);
void (*fill_h2c_cmd)(struct ieee80211_hw *hw, u8 element_id,
- u32 cmd_len, u8 *p_cmdbuffer);
+ u32 cmd_len, u8 *p_cmdbuffer);
void (*set_default_port_id_cmd)(struct ieee80211_hw *hw);
bool (*get_btc_status)(void);
bool (*is_fw_header)(struct rtlwifi_firmware_header *hdr);
@@ -2343,14 +2343,14 @@ struct rtl_intf_ops {
struct rtl_priv **buddy_priv);
int (*adapter_tx)(struct ieee80211_hw *hw,
- struct ieee80211_sta *sta,
- struct sk_buff *skb,
- struct rtl_tcb_desc *ptcb_desc);
+ struct ieee80211_sta *sta,
+ struct sk_buff *skb,
+ struct rtl_tcb_desc *ptcb_desc);
void (*flush)(struct ieee80211_hw *hw, u32 queues, bool drop);
int (*reset_trx_ring)(struct ieee80211_hw *hw);
bool (*waitq_insert)(struct ieee80211_hw *hw,
- struct ieee80211_sta *sta,
- struct sk_buff *skb);
+ struct ieee80211_sta *sta,
+ struct sk_buff *skb);
/*pci */
void (*disable_aspm)(struct ieee80211_hw *hw);
@@ -2689,11 +2689,11 @@ struct rtl_btc_ops {
u8 scantype);
void (*btc_connect_notify)(struct rtl_priv *rtlpriv, u8 action);
void (*btc_mediastatus_notify)(struct rtl_priv *rtlpriv,
- enum rt_media_status mstatus);
+ enum rt_media_status mstatus);
void (*btc_periodical)(struct rtl_priv *rtlpriv);
void (*btc_halt_notify)(struct rtl_priv *rtlpriv);
void (*btc_btinfo_notify)(struct rtl_priv *rtlpriv,
- u8 *tmp_buf, u8 length);
+ u8 *tmp_buf, u8 length);
void (*btc_btmpinfo_notify)(struct rtl_priv *rtlpriv,
u8 *tmp_buf, u8 length);
bool (*btc_is_limited_dig)(struct rtl_priv *rtlpriv);
@@ -3155,7 +3155,7 @@ static inline void rtl_set_bbreg(struct ieee80211_hw *hw, u32 regaddr,
}
static inline void rtl_set_bbreg_with_dwmask(struct ieee80211_hw *hw,
- u32 regaddr, u32 data)
+ u32 regaddr, u32 data)
{
rtl_set_bbreg(hw, regaddr, 0xffffffff, data);
}
@@ -3226,7 +3226,7 @@ static inline struct ieee80211_sta *get_sta(struct ieee80211_hw *hw,
}
static inline struct ieee80211_sta *rtl_find_sta(struct ieee80211_hw *hw,
- u8 *mac_addr)
+ u8 *mac_addr)
{
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
return ieee80211_find_sta(mac->vif, mac_addr);
--
2.20.1
^ permalink raw reply related
* [PATCH 4/8] rtlwifi: Fix blank line errors in main header files
From: Larry Finger @ 2019-02-21 19:31 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190221193115.30848-1-Larry.Finger@lwfinger.net>
The errors consist of multiple blank lines, and a missing blank line
after the declarations.
There are no code changes.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/usb.h | 5 +----
drivers/net/wireless/realtek/rtlwifi/wifi.h | 4 +---
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.h b/drivers/net/wireless/realtek/rtlwifi/usb.h
index 09bbcdbe0dbf..3bf85b23eec1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.h
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.h
@@ -17,7 +17,6 @@
#define USB_HIGH_SPEED_BULK_SIZE 512
#define USB_FULL_SPEED_BULK_SIZE 64
-
#define RTL_USB_MAX_TXQ_NUM 4 /* max tx queue */
#define RTL_USB_MAX_EP_NUM 6 /* max ep number */
#define RTL_USB_MAX_TX_URBS_NUM 8
@@ -53,11 +52,11 @@ static inline void _rtl_install_trx_info(struct rtl_usb *rtlusb,
u32 ep_num)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+
info->rate_driver_data[0] = rtlusb;
info->rate_driver_data[1] = (void *)(__kernel_size_t)ep_num;
}
-
/* Add suspend/resume later */
enum rtl_usb_state {
USB_STATE_STOP = 0,
@@ -133,8 +132,6 @@ struct rtl_usb_priv {
#define rtl_usbpriv(hw) (((struct rtl_usb_priv *)(rtl_priv(hw))->priv))
#define rtl_usbdev(usbpriv) (&((usbpriv)->dev))
-
-
int rtl_usb_probe(struct usb_interface *intf,
const struct usb_device_id *id,
struct rtl_hal_cfg *rtl92cu_hal_cfg);
diff --git a/drivers/net/wireless/realtek/rtlwifi/wifi.h b/drivers/net/wireless/realtek/rtlwifi/wifi.h
index 88f94662c072..e32e9ffa3192 100644
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -2143,7 +2143,6 @@ struct rtl_stats {
u32 macid_valid_entry[2];
};
-
struct rt_link_detect {
/* count for roaming */
u32 bcn_rx_inperiod;
@@ -2843,7 +2842,6 @@ struct rtl_priv {
#define rtl_efuse(rtlpriv) (&((rtlpriv)->efuse))
#define rtl_psc(rtlpriv) (&((rtlpriv)->psc))
-
/* Bluetooth Co-existence Related */
enum bt_ant_num {
@@ -2893,7 +2891,6 @@ enum bt_radio_shared {
BT_RADIO_INDIVIDUAL = 1,
};
-
/****************************************
* mem access macro define start
* Call endian free function when
@@ -3229,6 +3226,7 @@ static inline struct ieee80211_sta *rtl_find_sta(struct ieee80211_hw *hw,
u8 *mac_addr)
{
struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
+
return ieee80211_find_sta(mac->vif, mac_addr);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 5/8] rtlwifi: Fix all blank line irregularities in main code files
From: Larry Finger @ 2019-02-21 19:31 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190221193115.30848-1-Larry.Finger@lwfinger.net>
The types of problems fixed are as follows:
WARNING: Missing a blank line after declarations
CHECK: Please use a blank line after function/struct/union/enum declarations
CHECK: Please don't use multiple blank lines
There are no code changes.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/base.c | 7 +++++--
drivers/net/wireless/realtek/rtlwifi/core.c | 8 ++++++++
drivers/net/wireless/realtek/rtlwifi/efuse.c | 8 +++++---
drivers/net/wireless/realtek/rtlwifi/ps.c | 1 +
drivers/net/wireless/realtek/rtlwifi/rc.c | 2 ++
drivers/net/wireless/realtek/rtlwifi/regd.c | 1 -
drivers/net/wireless/realtek/rtlwifi/usb.c | 3 +++
7 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
index 28d47e3e79fa..f128be46755c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -430,6 +430,7 @@ static void _rtl_init_mac80211(struct ieee80211_hw *hw)
SET_IEEE80211_PERM_ADDR(hw, rtlefuse->dev_addr);
} else {
u8 rtlmac1[] = { 0x00, 0xe0, 0x4c, 0x81, 0x92, 0x00 };
+
get_random_bytes((rtlmac1 + (ETH_ALEN - 1)), 1);
SET_IEEE80211_PERM_ADDR(hw, rtlmac1);
}
@@ -459,7 +460,6 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
(void *)rtl_fwevt_wq_callback);
INIT_DELAYED_WORK(&rtlpriv->works.c2hcmd_wq,
(void *)rtl_c2hcmd_wq_callback);
-
}
void rtl_deinit_deferred_work(struct ieee80211_hw *hw, bool ips_wq)
@@ -618,6 +618,7 @@ static void _rtl_query_shortgi(struct ieee80211_hw *hw,
u8 rate_flag = info->control.rates[0].flags;
u8 sgi_40 = 0, sgi_20 = 0, bw_40 = 0;
u8 sgi_80 = 0, bw_80 = 0;
+
tcb_desc->use_shortgi = false;
if (sta == NULL)
@@ -1850,6 +1851,7 @@ int rtl_rx_agg_stop(struct ieee80211_hw *hw,
return 0;
}
+
int rtl_tx_agg_oper(struct ieee80211_hw *hw,
struct ieee80211_sta *sta, u16 tid)
{
@@ -2073,7 +2075,6 @@ void rtl_watchdog_wq_callback(void *data)
* busytraffic we don't change channel
*/
if (mac->link_state >= MAC80211_LINKED) {
-
/* (1) get aver_rx_cnt_inperiod & aver_tx_cnt_inperiod */
for (idx = 0; idx <= 2; idx++) {
rtlpriv->link_info.num_rx_in4period[idx] =
@@ -2233,6 +2234,7 @@ void rtl_watch_dog_timer_callback(struct timer_list *t)
mod_timer(&rtlpriv->works.watchdog_timer,
jiffies + MSECS(RTL_WATCH_DOG_TIME));
}
+
void rtl_fwevt_wq_callback(void *data)
{
struct rtl_works *rtlworks =
@@ -2385,6 +2387,7 @@ void rtl_easy_concurrent_retrytimer_callback(struct timer_list *t)
rtlpriv->cfg->ops->dualmac_easy_concurrent(hw);
}
+
/*********************************************************
*
* frame process functions
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index 0913f02b7ff1..f73e690bbe8e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -188,6 +188,7 @@ static void rtl_op_tx(struct ieee80211_hw *hw,
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw));
struct rtl_tcb_desc tcb_desc;
+
memset(&tcb_desc, 0, sizeof(struct rtl_tcb_desc));
if (unlikely(is_hal_stop(rtlhal) || ppsc->rfpwr_state != ERFON))
@@ -346,12 +347,14 @@ static void rtl_op_remove_interface(struct ieee80211_hw *hw,
mutex_unlock(&rtlpriv->locks.conf_mutex);
}
+
static int rtl_op_change_interface(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum nl80211_iftype new_type, bool p2p)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
int ret;
+
rtl_op_remove_interface(hw, vif);
vif->type = new_type;
@@ -881,6 +884,7 @@ static void rtl_op_configure_filter(struct ieee80211_hw *hw,
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
(u8 *)(&mac->rx_conf));
}
+
static int rtl_op_sta_add(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta)
@@ -933,6 +937,7 @@ static int rtl_op_sta_remove(struct ieee80211_hw *hw,
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_sta_info *sta_entry;
+
if (sta) {
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_DMESG,
"Remove sta addr is %pM\n", sta->addr);
@@ -945,6 +950,7 @@ static int rtl_op_sta_remove(struct ieee80211_hw *hw,
}
return 0;
}
+
static int _rtl_get_hal_qnum(u16 queue)
{
int qnum;
@@ -1066,6 +1072,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
/*TODO: reference to enum ieee80211_bss_change */
if (changed & BSS_CHANGED_ASSOC) {
u8 mstatus;
+
if (bss_conf->assoc) {
struct ieee80211_sta *sta = NULL;
u8 keep_alive = 10;
@@ -1294,6 +1301,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
* set in sta_add, and will be NULL here */
if (vif->type == NL80211_IFTYPE_STATION) {
struct rtl_sta_info *sta_entry;
+
sta_entry = (struct rtl_sta_info *)sta->drv_priv;
sta_entry->wireless_mode = mac->mode;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
index de0437b3cb95..e68340dfd980 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
@@ -474,6 +474,7 @@ bool efuse_shadow_update(struct ieee80211_hw *hw)
if (word_en != 0x0F) {
u8 tmpdata[8];
+
memcpy(tmpdata,
&rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base],
8);
@@ -487,7 +488,6 @@ bool efuse_shadow_update(struct ieee80211_hw *hw)
break;
}
}
-
}
efuse_power_switch(hw, true, false);
@@ -662,6 +662,7 @@ static int efuse_one_byte_write(struct ieee80211_hw *hw, u16 addr, u8 data)
static void efuse_read_all_map(struct ieee80211_hw *hw, u8 *efuse)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
+
efuse_power_switch(hw, false, true);
read_efuse(hw, 0, rtlpriv->cfg->maps[EFUSE_HWSET_MAX_SIZE], efuse);
efuse_power_switch(hw, false, false);
@@ -812,6 +813,7 @@ static void efuse_write_data_case1(struct ieee80211_hw *hw, u16 *efuse_addr,
if (0x0F != (badworden & 0x0F)) {
u8 reorg_offset = offset;
u8 reorg_worden = badworden;
+
efuse_pg_packet_write(hw, reorg_offset,
reorg_worden,
originaldata);
@@ -901,6 +903,7 @@ static void efuse_write_data_case2(struct ieee80211_hw *hw, u16 *efuse_addr,
if (0x0F != (badworden & 0x0F)) {
u8 reorg_offset = tmp_pkt.offset;
u8 reorg_worden = badworden;
+
efuse_pg_packet_write(hw, reorg_offset,
reorg_worden,
originaldata);
@@ -957,7 +960,6 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
while (continual && (efuse_addr < (EFUSE_MAX_SIZE -
rtlpriv->cfg->maps[EFUSE_OOB_PROTECT_BYTES_LEN]))) {
-
if (write_state == PG_STATE_HEADER) {
dataempty = true;
badworden = 0x0F;
@@ -1114,7 +1116,6 @@ void efuse_power_switch(struct ieee80211_hw *hw, u8 write, u8 pwrstate)
u16 tmpv16;
if (pwrstate && (rtlhal->hw_type != HARDWARE_TYPE_RTL8192SE)) {
-
if (rtlhal->hw_type != HARDWARE_TYPE_RTL8192CE &&
rtlhal->hw_type != HARDWARE_TYPE_RTL8192DE) {
rtl_write_byte(rtlpriv,
@@ -1219,6 +1220,7 @@ static u16 efuse_get_current_size(struct ieee80211_hw *hw)
static u8 efuse_calculate_word_cnts(u8 word_en)
{
u8 word_cnts = 0;
+
if (!(word_en & BIT(0)))
word_cnts++;
if (!(word_en & BIT(1)))
diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c b/drivers/net/wireless/realtek/rtlwifi/ps.c
index dca70d239760..70f04c2f5b17 100644
--- a/drivers/net/wireless/realtek/rtlwifi/ps.c
+++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
@@ -718,6 +718,7 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void *data,
static u8 p2p_oui_ie_type[4] = {0x50, 0x6f, 0x9a, 0x09};
u8 noa_num, index , i, noa_index = 0;
bool find_p2p_ie = false , find_p2p_ps_ie = false;
+
pos = (u8 *)mgmt->u.beacon.variable;
end = data + len;
ie = NULL;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rc.c b/drivers/net/wireless/realtek/rtlwifi/rc.c
index 8fa76eab61d2..cf8e42a01015 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rc.c
@@ -236,6 +236,7 @@ static void rtl_tx_status(void *ppriv,
!(skb->protocol == cpu_to_be16(ETH_P_PAE))) {
if (ieee80211_is_data_qos(fc)) {
u8 tid = rtl_get_tid(skb);
+
if (_rtl_tx_aggr_check(rtlpriv, sta_entry,
tid)) {
sta_entry->tids[tid].agg.agg_state =
@@ -293,6 +294,7 @@ static void rtl_rate_free_sta(void *rtlpriv,
struct ieee80211_sta *sta, void *priv_sta)
{
struct rtl_rate_priv *rate_priv = priv_sta;
+
kfree(rate_priv);
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
index c7048830decd..6ccb5b93a595 100644
--- a/drivers/net/wireless/realtek/rtlwifi/regd.c
+++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
@@ -41,7 +41,6 @@ static struct country_code_to_enum_rd all_countries[] = {
NL80211_RRF_PASSIVE_SCAN | \
NL80211_RRF_NO_OFDM)
-
/* 5G chan 36 - chan 64*/
#define RTL819x_5GHZ_5150_5350 \
REG_RULE(5150-10, 5350+10, 80, 0, 30, 0)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 525f72bad433..e24fda5e9087 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -267,6 +267,7 @@ static int _rtl_usb_init_tx(struct ieee80211_hw *hw)
for (i = 0; i < __RTL_TXQ_NUM; i++) {
u32 ep_num = rtlusb->ep_map.ep_mapping[i];
+
if (!ep_num) {
RT_TRACE(rtlpriv, COMP_INIT, DBG_DMESG,
"Invalid endpoint map setting!\n");
@@ -331,6 +332,7 @@ static int _rtl_usb_init(struct ieee80211_hw *hw)
rtlusb->out_ep_nums = rtlusb->in_ep_nums = 0;
for (epidx = 0; epidx < epnums; epidx++) {
struct usb_endpoint_descriptor *pep_desc;
+
pep_desc = &usb_intf->cur_altsetting->endpoint[epidx].desc;
if (usb_endpoint_dir_in(pep_desc))
@@ -753,6 +755,7 @@ static int rtl_usb_start(struct ieee80211_hw *hw)
return err;
}
+
/**
*
*
--
2.20.1
^ permalink raw reply related
* [PATCH 6/8] rtlwifi: rtl8192ce: Fix missing blank lines
From: Larry Finger @ 2019-02-21 19:31 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190221193115.30848-1-Larry.Finger@lwfinger.net>
The problems filed include the following:
WARNING: Missing a blank line after declarations
CHECK: Please don't use multiple blank lines
There are no code changes.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 7 ++++++-
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 1 +
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/table.c | 1 -
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 8 ++++++++
4 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index 7c94cabc19a6..10d85c2c7867 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -144,6 +144,7 @@ void rtl92ce_set_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val)
case HW_VAR_BASIC_RATE:{
u16 rate_cfg = ((u16 *) val)[0];
u8 rate_index = 0;
+
rate_cfg &= 0x15f;
rate_cfg |= 0x01;
rtl_write_byte(rtlpriv, REG_RRSR, rate_cfg & 0xff);
@@ -197,6 +198,7 @@ void rtl92ce_set_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val)
case HW_VAR_ACK_PREAMBLE:{
u8 reg_tmp;
u8 short_preamble = (bool)*val;
+
reg_tmp = (mac->cur_40_prime_sc) << 5;
if (short_preamble)
reg_tmp |= 0x80;
@@ -293,6 +295,7 @@ void rtl92ce_set_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val)
}
case HW_VAR_AC_PARAM:{
u8 e_aci = *(val);
+
rtl92c_dm_init_edca_turbo(hw);
if (rtlpci->acm_method != EACMWAY2_SW)
@@ -456,6 +459,7 @@ void rtl92ce_set_hw_reg(struct ieee80211_hw *hw, u8 variable, u8 *val)
break;
case HW_VAR_AID:{
u16 u2btmp;
+
u2btmp = rtl_read_word(rtlpriv, REG_BCN_PSR_RPT);
u2btmp &= 0xC000;
rtl_write_word(rtlpriv, REG_BCN_PSR_RPT, (u2btmp |
@@ -661,6 +665,7 @@ static bool _rtl92ce_init_mac(struct ieee80211_hw *hw)
rtl_write_byte(rtlpriv, REG_RSV_CTRL, 0x00);
if (rtlpriv->btcoexist.bt_coexistence) {
u32 value32;
+
value32 = rtl_read_dword(rtlpriv, REG_APS_FSMCO);
value32 |= (SOP_ABG | SOP_AMB | XOP_BTCK);
rtl_write_dword(rtlpriv, REG_APS_FSMCO, value32);
@@ -1245,6 +1250,7 @@ int rtl92ce_set_network_type(struct ieee80211_hw *hw, enum nl80211_iftype type)
void rtl92ce_set_qos(struct ieee80211_hw *hw, int aci)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
+
rtl92c_dm_init_edca_turbo(hw);
switch (aci) {
case AC1_BK:
@@ -2279,7 +2285,6 @@ void rtl8192ce_bt_reg_init(struct ieee80211_hw *hw)
rtlpriv->btcoexist.reg_bt_sco = 0;
}
-
void rtl8192ce_bt_hw_init(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c
index 8d18210dd5c8..f6574f31fa3b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/phy.c
@@ -443,6 +443,7 @@ static bool _rtl92ce_phy_set_rf_power_state(struct ieee80211_hw *hw,
RT_IN_PS_LEVEL(ppsc, RT_RF_OFF_LEVL_HALT_NIC)) {
bool rtstatus;
u32 initializecount = 0;
+
do {
initializecount++;
RT_TRACE(rtlpriv, COMP_RF, DBG_DMESG,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/table.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/table.c
index e258b0803699..58878db404ed 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/table.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/table.c
@@ -3,7 +3,6 @@
#include "table.h"
-
u32 RTL8192CEPHY_REG_2TARRAY[PHY_REG_2TARRAY_LENGTH] = {
0x024, 0x0011800f,
0x028, 0x00ffdb83,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
index b08fb1bf6709..18a0ab59631a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
@@ -36,6 +36,7 @@ static u8 _rtl92c_query_rxpwrpercentage(s8 antpower)
static u8 _rtl92c_evm_db_to_percentage(s8 value)
{
s8 ret_val;
+
ret_val = value;
if (ret_val >= 0)
@@ -109,6 +110,7 @@ static void _rtl92ce_query_rxphystatus(struct ieee80211_hw *hw,
if (is_cck_rate) {
u8 report, cck_highpwr;
+
cck_buf = (struct phy_sts_cck_8192s_t *)p_drvinfo;
if (ppsc->rfpwr_state == ERFON)
@@ -120,6 +122,7 @@ static void _rtl92ce_query_rxphystatus(struct ieee80211_hw *hw,
if (!cck_highpwr) {
u8 cck_agc_rpt = cck_buf->cck_agc_rpt;
+
report = cck_buf->cck_agc_rpt & 0xc0;
report = report >> 6;
switch (report) {
@@ -138,6 +141,7 @@ static void _rtl92ce_query_rxphystatus(struct ieee80211_hw *hw,
}
} else {
u8 cck_agc_rpt = cck_buf->cck_agc_rpt;
+
report = p_drvinfo->cfosho[0] & 0x60;
report = report >> 5;
switch (report) {
@@ -182,6 +186,7 @@ static void _rtl92ce_query_rxphystatus(struct ieee80211_hw *hw,
/* (3) Get Signal Quality (EVM) */
if (packet_match_bssid) {
u8 sq;
+
if (pstats->rx_pwdb_all > 40)
sq = 100;
else {
@@ -318,6 +323,7 @@ bool rtl92ce_rx_query_desc(struct ieee80211_hw *hw,
struct rx_desc_92c *pdesc = (struct rx_desc_92c *)p_desc;
struct ieee80211_hdr *hdr;
u32 phystatus = GET_RX_DESC_PHYST(pdesc);
+
stats->length = (u16) GET_RX_DESC_PKT_LEN(pdesc);
stats->rx_drvinfo_size = (u8) GET_RX_DESC_DRV_INFO_SIZE(pdesc) *
RX_DRV_INFO_SIZE_UNIT;
@@ -497,6 +503,7 @@ void rtl92ce_tx_fill_desc(struct ieee80211_hw *hw,
if (sta) {
u8 ampdu_density = sta->ht_cap.ampdu_density;
+
SET_TX_DESC_AMPDU_DENSITY(pdesc, ampdu_density);
}
@@ -733,6 +740,7 @@ bool rtl92ce_is_tx_desc_closed(struct ieee80211_hw *hw,
void rtl92ce_tx_polling(struct ieee80211_hw *hw, u8 hw_queue)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
+
if (hw_queue == BEACON_QUEUE) {
rtl_write_word(rtlpriv, REG_PCIE_CTRL_REG, BIT(4));
} else {
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox