* Re: brcmfmac: bogus error messages during module unload
From: Arend Van Spriel @ 2019-03-02 7:05 UTC (permalink / raw)
To: Stefan Wahren, Chi-Hsien Lin, Franky Lin, Hante Meuleman,
Wright Feng
Cc: linux-wireless
In-Reply-To: <1125416917.128310.1551471017839@email.ionos.de>
Op 1 maart 2019 21:10:18 schreef Stefan Wahren <stefan.wahren@i2se.com>:
> Hi,
>
> this is some kind of older issue with brcmfmac. Everytime i unload the
> kernel module (e.g. v5.0-rc8 or next-20190301) on a Raspberry Pi 3
> (multi_v7_defconfig / arm64_defconfig) after the driver has successful
> probed, i'm getting such bogus error messages in the kernel log:
>
> [ 870.477114] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg
> failed w/status -5
> [ 870.477122] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
> [ 871.057074] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing
> to do.
> [ 871.057153] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing
> to do.
> [ 871.057870] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing
> to do.
> [ 871.057878] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
>
> Is there a chance to remove or at least reduce them?
These are triggered by user-space. Upon remove we can not communicate with
the device, but have not yet removed the network interfaces. So when
user-space does a request we fail. I will have a look at it.
Regards,
Arend
Verzonden met AquaMail voor Android
https://www.mobisystems.com/aqua-mail
^ permalink raw reply
* [PATCH 2/2] ath10k: Add xo calibration support for wifi rf clock
From: Govind Singh @ 2019-03-02 5:06 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, devicetree, Govind Singh
In-Reply-To: <20190302050635.17694-1-govinds@codeaurora.org>
PMIC XO is the clock source for wifi rf clock in integrated wifi
chipset ex: WCN3990. Due to board layout errors XO frequency drifts
can cause wifi rf clock inaccuracy.
XO calibration test tree in Factory Test Mode is used to find the
best frequency offset(for example +/-2KHz )by programming XO trim
register. This ensure system clock stays within required 20 ppm
WLAN rf clock.
Retrieve the xo trim offset via system firmware (e.g., device tree),
especially in the case where the device doesn't have a useful EEPROM
on which to store the calibrated XO offset (e.g., for integrated Wifi).
Calibrated XO offset is sent to fw, which compensate the clock drift
by programing the XO trim register.
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/qmi.c | 12 ++++++++++++
drivers/net/wireless/ath/ath10k/snoc.c | 10 ++++++++++
drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
3 files changed, 24 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 37b3bd629f48..99c140a6628d 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -302,10 +302,16 @@ static int ath10k_qmi_send_cal_report_req(struct ath10k_qmi *qmi)
struct wlfw_cal_report_resp_msg_v01 resp = {};
struct wlfw_cal_report_req_msg_v01 req = {};
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
struct qmi_txn txn;
int i, j = 0;
int ret;
+ if (ar_snoc->xo_cal_supported) {
+ req.xo_cal_data_valid = 1;
+ req.xo_cal_data = ar_snoc->xo_cal_data;
+ }
+
ret = qmi_txn_init(&qmi->qmi_hdl, &txn, wlfw_cal_report_resp_msg_v01_ei,
&resp);
if (ret < 0)
@@ -636,6 +642,7 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi *qmi)
struct wlfw_ind_register_resp_msg_v01 resp = {};
struct wlfw_ind_register_req_msg_v01 req = {};
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
struct qmi_txn txn;
int ret;
@@ -646,6 +653,11 @@ ath10k_qmi_ind_register_send_sync_msg(struct ath10k_qmi *qmi)
req.msa_ready_enable_valid = 1;
req.msa_ready_enable = 1;
+ if (ar_snoc->xo_cal_supported) {
+ req.xo_cal_enable_valid = 1;
+ req.xo_cal_enable = 1;
+ }
+
ret = qmi_txn_init(&qmi->qmi_hdl, &txn,
wlfw_ind_register_resp_msg_v01_ei, &resp);
if (ret < 0)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 54efe6be8f1d..7fa0f5c1d070 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -20,6 +20,7 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/regulator/consumer.h>
#include "ce.h"
@@ -1189,6 +1190,15 @@ static int ath10k_snoc_resource_init(struct ath10k *ar)
ar_snoc->ce_irqs[i].irq_line = res->start;
}
+ ret = device_property_read_u32(&pdev->dev, "xo-cal-data",
+ &ar_snoc->xo_cal_data);
+ ath10k_dbg(ar, ATH10K_DBG_SNOC, "snoc xo-cal-data return %d\n", ret);
+ if (ret == 0) {
+ ar_snoc->xo_cal_supported = true;
+ ath10k_dbg(ar, ATH10K_DBG_SNOC, "xo cal data %x\n",
+ ar_snoc->xo_cal_data);
+ }
+
out:
return ret;
}
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index 2b2f23cf7c5d..25383de8f17d 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -91,6 +91,8 @@ struct ath10k_snoc {
struct ath10k_clk_info *clk;
struct ath10k_qmi *qmi;
unsigned long int flags;
+ bool xo_cal_supported;
+ u32 xo_cal_data;
};
static inline struct ath10k_snoc *ath10k_snoc_priv(struct ath10k *ar)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 1/2] dt: bindings: add dt entry for XO calibration support
From: Govind Singh @ 2019-03-02 5:06 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, devicetree, Govind Singh
In-Reply-To: <20190302050635.17694-1-govinds@codeaurora.org>
Add dt binding to get xo calibration data support for wifi rf clock.
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index ae661e65354e..ab8042866e83 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -81,6 +81,7 @@ Optional properties:
Definition: Name of external front end module used. Some valid FEM names
for example: "microsemi-lx5586", "sky85703-11"
and "sky85803" etc.
+- xo-cal-data: xo cal offset to be configured in xo trim register.
Example (to supply PCI based wifi block details):
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 0/2] Add xo calibration support for wifi rf clock
From: Govind Singh @ 2019-03-02 5:06 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, devicetree, Govind Singh
PMIC XO is the clock source for wifi rf clock in integrated wifi
chipset ex: WCN3990. Due to board layout errors XO frequency drifts
can cause wifi rf clock inaccuracy.
XO calibration test tree in Factory Test Mode is used to find the
best frequency offset(for example +/-2KHz )by programming XO trim
register. This ensure system clock stays within required 20 ppm
WLAN rf clock.
Retrieve the xo trim offset via system firmware (e.g., device tree),
especially in the case where the device doesn't have a useful EEPROM
on which to store the calibrated XO offset (e.g., for integrated Wifi).
Calibrated XO offset is sent to fw, which compensate the clock drift
by programing the XO trim register.
Testing:
Tested on QCS404 platform(WCN3990 HW)
Tested FW: WLAN.HL.3.1-00959-QCAHLSWMTPLZ-1
Govind Singh (2):
dt: bindings: add dt entry for XO calibration support
ath10k: Add xo calibration support for wifi rf clock
.../devicetree/bindings/net/wireless/qcom,ath10k.txt | 1 +
drivers/net/wireless/ath/ath10k/qmi.c | 12 ++++++++++++
drivers/net/wireless/ath/ath10k/snoc.c | 10 ++++++++++
drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
4 files changed, 25 insertions(+)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] ath10k: Modify CE4 src buffer entries to 2048 for WCN3990
From: Govind Singh @ 2019-03-02 4:36 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Govind Singh
CE4 is host to target HTT tx pipe, tx completion are not served
on time when CPU is loaded and this cause ce src ring full condition
due to less no of src buffer entries.
To mitigate the issue increase CE4 src buffer entries to 2048.
Testing:
Tested on QCS404 platform(WCN3990 HW)
Tested FW: WLAN.HL.3.1-00784-QCAHLSWMTPLZ-1
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/snoc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index 7fa0f5c1d070..f0ea3c494fe6 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -176,7 +176,7 @@ static struct ce_attr host_ce_config_wlan[] = {
/* CE4: host->target HTT */
{
.flags = CE_ATTR_FLAGS | CE_ATTR_DIS_INTR,
- .src_nentries = 256,
+ .src_nentries = 2048,
.src_sz_max = 256,
.dest_nentries = 0,
.send_cb = ath10k_snoc_htt_tx_cb,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: Realtek r8822be kernel module does not negotiate 802.11ac connection
From: David R. Bergstein @ 2019-03-02 3:52 UTC (permalink / raw)
To: Larry Finger, Tony Chuang
Cc: Pkshih, linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <8706d34c-1fac-84ba-759d-18d96750636b@gmail.com>
Larry,
Sorry about all these extra replies. Shortly after I sent my last
message my access point started recognizing the connection as 802.11ac
with PHY Rate / Modulation Rate of 866.6 Mbps. What is somewhat
misleading is the information reported by iwconfig (see bit rate below).
$ iwconfig wlo1
wlo1 IEEE 802.11 ESSID:"XXXXXXXXXX-5G"
Mode:Managed Frequency:5.22 GHz Access Point:
xx:xx:xx:xx:xx:xx
Bit Rate=6.5 Mb/s Tx-Power=23 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=70/70 Signal level=-40 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:11 Missed beacon:0
Sincerely,
David R. Bergstein
On 3/1/19 10:16 PM, David R. Bergstein wrote:
> Larry,
>
> Please disregard my last message. The firmware is now installed and the
> rtw88 module is working with my wireless router. The next hurdle
> appears to be setting the speed to 802.11ac as it is currently
> connecting as an 802.11n client.
>
> Sincerely,
>
> David R. Bergstein
>
> On 3/1/19 9:55 PM, David R. Bergstein wrote:
>> Larry,
>>
>> Following up to your last reply, I blacklisted the r8822be module,
>> rebooted and was unable to bring up the wireless interface via rtw88.
>> Below are some errors recorded in my system log:
>>
>>
>> [ 267.509818] rtw_pci 0000:3d:00.0: Direct firmware load for
>> rtw88/rtw8822b_fw.bin failed with error -2
>> [ 267.509821] rtw_pci 0000:3d:00.0: failed to request firmware
>> [ 267.511068] rtw_pci 0000:3d:00.0: mac power on failed
>> [ 267.511072] rtw_pci 0000:3d:00.0: failed to power on mac
>> [ 267.511073] rtw_pci 0000:3d:00.0: failed to setup chip efuse info
>> [ 267.511075] rtw_pci 0000:3d:00.0: failed to setup chip information
>> [ 267.512817] rtw_pci: probe of 0000:3d:00.0 failed with error -114
>>
>> As directed, I used the rtwpci module to perform load/unload the rtw88
>> module before I saw the errors above. Do I still need to install firmware?
>>
>> Sincerely,
>>
>> David R. Bergstein
>>
>> On 3/1/19 8:46 PM, Larry Finger wrote:
>>> On 3/1/19 4:26 PM, David R. Bergstein wrote:
>>>> Larry,
>>>>
>>>> Thanks for the response and detailed instructions, which allowed me to
>>>> build and install the rtw88 kernel module. I cannot however seem to get
>>>> my system to actually use the module. Just to recap this is an HP Omen
>>>> laptop with secure boot disabled. Upon boot-up both the new rtw88 and
>>>> old r8822be modules are loaded. If I unload the r8822be module the wifi
>>>> network connection gets terminated, even if I unload/reload the rtw88
>>>> module.
>>>>
>>>> Is there something else I should be doing prior to invoking rtw88, e.g.,
>>>> blacklisting the old module?
>>> Yes, r8822be must be blacklisted. Use the lsmod command to see what
>>> modules are actually loaded. You load/unload rtw88 using the rtwpci
>>> module.
>>>
>>> Larry
>>>
^ permalink raw reply
* Re: Realtek r8822be kernel module does not negotiate 802.11ac connection
From: David R. Bergstein @ 2019-03-02 3:16 UTC (permalink / raw)
To: Larry Finger, Tony Chuang
Cc: Pkshih, linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <2e39892d-d206-e87f-c802-d427c54277cf@gmail.com>
Larry,
Please disregard my last message. The firmware is now installed and the
rtw88 module is working with my wireless router. The next hurdle
appears to be setting the speed to 802.11ac as it is currently
connecting as an 802.11n client.
Sincerely,
David R. Bergstein
On 3/1/19 9:55 PM, David R. Bergstein wrote:
> Larry,
>
> Following up to your last reply, I blacklisted the r8822be module,
> rebooted and was unable to bring up the wireless interface via rtw88.
> Below are some errors recorded in my system log:
>
>
> [ 267.509818] rtw_pci 0000:3d:00.0: Direct firmware load for
> rtw88/rtw8822b_fw.bin failed with error -2
> [ 267.509821] rtw_pci 0000:3d:00.0: failed to request firmware
> [ 267.511068] rtw_pci 0000:3d:00.0: mac power on failed
> [ 267.511072] rtw_pci 0000:3d:00.0: failed to power on mac
> [ 267.511073] rtw_pci 0000:3d:00.0: failed to setup chip efuse info
> [ 267.511075] rtw_pci 0000:3d:00.0: failed to setup chip information
> [ 267.512817] rtw_pci: probe of 0000:3d:00.0 failed with error -114
>
> As directed, I used the rtwpci module to perform load/unload the rtw88
> module before I saw the errors above. Do I still need to install firmware?
>
> Sincerely,
>
> David R. Bergstein
>
> On 3/1/19 8:46 PM, Larry Finger wrote:
>> On 3/1/19 4:26 PM, David R. Bergstein wrote:
>>> Larry,
>>>
>>> Thanks for the response and detailed instructions, which allowed me to
>>> build and install the rtw88 kernel module. I cannot however seem to get
>>> my system to actually use the module. Just to recap this is an HP Omen
>>> laptop with secure boot disabled. Upon boot-up both the new rtw88 and
>>> old r8822be modules are loaded. If I unload the r8822be module the wifi
>>> network connection gets terminated, even if I unload/reload the rtw88
>>> module.
>>>
>>> Is there something else I should be doing prior to invoking rtw88, e.g.,
>>> blacklisting the old module?
>> Yes, r8822be must be blacklisted. Use the lsmod command to see what
>> modules are actually loaded. You load/unload rtw88 using the rtwpci
>> module.
>>
>> Larry
>>
^ permalink raw reply
* Re: Realtek r8822be kernel module does not negotiate 802.11ac connection
From: David R. Bergstein @ 2019-03-02 2:55 UTC (permalink / raw)
To: Larry Finger, Tony Chuang
Cc: Pkshih, linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <487c350c-c455-b490-8de5-1d68760aa3dc@lwfinger.net>
Larry,
Following up to your last reply, I blacklisted the r8822be module,
rebooted and was unable to bring up the wireless interface via rtw88.
Below are some errors recorded in my system log:
[ 267.509818] rtw_pci 0000:3d:00.0: Direct firmware load for
rtw88/rtw8822b_fw.bin failed with error -2
[ 267.509821] rtw_pci 0000:3d:00.0: failed to request firmware
[ 267.511068] rtw_pci 0000:3d:00.0: mac power on failed
[ 267.511072] rtw_pci 0000:3d:00.0: failed to power on mac
[ 267.511073] rtw_pci 0000:3d:00.0: failed to setup chip efuse info
[ 267.511075] rtw_pci 0000:3d:00.0: failed to setup chip information
[ 267.512817] rtw_pci: probe of 0000:3d:00.0 failed with error -114
As directed, I used the rtwpci module to perform load/unload the rtw88
module before I saw the errors above. Do I still need to install firmware?
Sincerely,
David R. Bergstein
On 3/1/19 8:46 PM, Larry Finger wrote:
> On 3/1/19 4:26 PM, David R. Bergstein wrote:
>> Larry,
>>
>> Thanks for the response and detailed instructions, which allowed me to
>> build and install the rtw88 kernel module. I cannot however seem to get
>> my system to actually use the module. Just to recap this is an HP Omen
>> laptop with secure boot disabled. Upon boot-up both the new rtw88 and
>> old r8822be modules are loaded. If I unload the r8822be module the wifi
>> network connection gets terminated, even if I unload/reload the rtw88
>> module.
>>
>> Is there something else I should be doing prior to invoking rtw88, e.g.,
>> blacklisting the old module?
>
> Yes, r8822be must be blacklisted. Use the lsmod command to see what
> modules are actually loaded. You load/unload rtw88 using the rtwpci
> module.
>
> Larry
>
^ permalink raw reply
* Re: Realtek r8822be kernel module does not negotiate 802.11ac connection
From: Larry Finger @ 2019-03-02 1:46 UTC (permalink / raw)
To: David R. Bergstein, Tony Chuang
Cc: Pkshih, linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <6eb7af74-b1a8-d112-e027-6c14252af994@gmail.com>
On 3/1/19 4:26 PM, David R. Bergstein wrote:
> Larry,
>
> Thanks for the response and detailed instructions, which allowed me to
> build and install the rtw88 kernel module. I cannot however seem to get
> my system to actually use the module. Just to recap this is an HP Omen
> laptop with secure boot disabled. Upon boot-up both the new rtw88 and
> old r8822be modules are loaded. If I unload the r8822be module the wifi
> network connection gets terminated, even if I unload/reload the rtw88
> module.
>
> Is there something else I should be doing prior to invoking rtw88, e.g.,
> blacklisting the old module?
Yes, r8822be must be blacklisted. Use the lsmod command to see what modules are
actually loaded. You load/unload rtw88 using the rtwpci module.
Larry
^ permalink raw reply
* [PATCH 1/3] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer
From: Sebastian Andrzej Siewior @ 2019-03-01 22:48 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, tglx, Anna-Maria Gleixner, Johannes Berg,
linux-wireless, Kalle Valo, Sebastian Andrzej Siewior
In-Reply-To: <20190301224821.29843-1-bigeasy@linutronix.de>
From: Thomas Gleixner <tglx@linutronix.de>
Switch the timer to HRTIMER_MODE_REL_SOFT, which executed the timer callback in
softirq context and remove the hrtimer_tasklet.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/net/wireless/mac80211_hwsim.c | 46 ++++++++++++---------------
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 6359053bd0c78..f46999a9e8ca5 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -521,7 +521,7 @@ struct mac80211_hwsim_data {
unsigned int rx_filter;
bool started, idle, scanning;
struct mutex mutex;
- struct tasklet_hrtimer beacon_timer;
+ struct hrtimer beacon_timer;
enum ps_mode {
PS_DISABLED, PS_ENABLED, PS_AUTO_POLL, PS_MANUAL_POLL
} ps;
@@ -1458,7 +1458,7 @@ static void mac80211_hwsim_stop(struct ieee80211_hw *hw)
{
struct mac80211_hwsim_data *data = hw->priv;
data->started = false;
- tasklet_hrtimer_cancel(&data->beacon_timer);
+ hrtimer_cancel(&data->beacon_timer);
wiphy_dbg(hw->wiphy, "%s\n", __func__);
}
@@ -1581,14 +1581,12 @@ static enum hrtimer_restart
mac80211_hwsim_beacon(struct hrtimer *timer)
{
struct mac80211_hwsim_data *data =
- container_of(timer, struct mac80211_hwsim_data,
- beacon_timer.timer);
+ container_of(timer, struct mac80211_hwsim_data, beacon_timer);
struct ieee80211_hw *hw = data->hw;
u64 bcn_int = data->beacon_int;
- ktime_t next_bcn;
if (!data->started)
- goto out;
+ return HRTIMER_NORESTART;
ieee80211_iterate_active_interfaces_atomic(
hw, IEEE80211_IFACE_ITER_NORMAL,
@@ -1599,12 +1597,9 @@ mac80211_hwsim_beacon(struct hrtimer *timer)
bcn_int -= data->bcn_delta;
data->bcn_delta = 0;
}
-
- next_bcn = ktime_add(hrtimer_get_expires(timer),
- ns_to_ktime(bcn_int * 1000));
- tasklet_hrtimer_start(&data->beacon_timer, next_bcn, HRTIMER_MODE_ABS);
-out:
- return HRTIMER_NORESTART;
+ hrtimer_forward(&data->beacon_timer, hrtimer_get_expires(timer),
+ ns_to_ktime(bcn_int * NSEC_PER_USEC));
+ return HRTIMER_RESTART;
}
static const char * const hwsim_chanwidths[] = {
@@ -1678,15 +1673,15 @@ static int mac80211_hwsim_config(struct ieee80211_hw *hw, u32 changed)
mutex_unlock(&data->mutex);
if (!data->started || !data->beacon_int)
- tasklet_hrtimer_cancel(&data->beacon_timer);
- else if (!hrtimer_is_queued(&data->beacon_timer.timer)) {
+ hrtimer_cancel(&data->beacon_timer);
+ else if (!hrtimer_is_queued(&data->beacon_timer)) {
u64 tsf = mac80211_hwsim_get_tsf(hw, NULL);
u32 bcn_int = data->beacon_int;
u64 until_tbtt = bcn_int - do_div(tsf, bcn_int);
- tasklet_hrtimer_start(&data->beacon_timer,
- ns_to_ktime(until_tbtt * 1000),
- HRTIMER_MODE_REL);
+ hrtimer_start(&data->beacon_timer,
+ ns_to_ktime(until_tbtt * NSEC_PER_USEC),
+ HRTIMER_MODE_REL_SOFT);
}
return 0;
@@ -1749,7 +1744,7 @@ static void mac80211_hwsim_bss_info_changed(struct ieee80211_hw *hw,
info->enable_beacon, info->beacon_int);
vp->bcn_en = info->enable_beacon;
if (data->started &&
- !hrtimer_is_queued(&data->beacon_timer.timer) &&
+ !hrtimer_is_queued(&data->beacon_timer) &&
info->enable_beacon) {
u64 tsf, until_tbtt;
u32 bcn_int;
@@ -1757,9 +1752,10 @@ static void mac80211_hwsim_bss_info_changed(struct ieee80211_hw *hw,
tsf = mac80211_hwsim_get_tsf(hw, vif);
bcn_int = data->beacon_int;
until_tbtt = bcn_int - do_div(tsf, bcn_int);
- tasklet_hrtimer_start(&data->beacon_timer,
- ns_to_ktime(until_tbtt * 1000),
- HRTIMER_MODE_REL);
+
+ hrtimer_start(&data->beacon_timer,
+ ns_to_ktime(until_tbtt * NSEC_PER_USEC),
+ HRTIMER_MODE_REL_SOFT);
} else if (!info->enable_beacon) {
unsigned int count = 0;
ieee80211_iterate_active_interfaces_atomic(
@@ -1768,7 +1764,7 @@ static void mac80211_hwsim_bss_info_changed(struct ieee80211_hw *hw,
wiphy_dbg(hw->wiphy, " beaconing vifs remaining: %u",
count);
if (count == 0) {
- tasklet_hrtimer_cancel(&data->beacon_timer);
+ hrtimer_cancel(&data->beacon_timer);
data->beacon_int = 0;
}
}
@@ -2919,9 +2915,9 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
- tasklet_hrtimer_init(&data->beacon_timer,
- mac80211_hwsim_beacon,
- CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ hrtimer_init(&data->beacon_timer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_ABS_SOFT);
+ data->beacon_timer.function = mac80211_hwsim_beacon;
err = ieee80211_register_hw(hw);
if (err < 0) {
--
2.20.1
^ permalink raw reply related
* Re: Realtek r8822be kernel module does not negotiate 802.11ac connection
From: David R. Bergstein @ 2019-03-01 22:26 UTC (permalink / raw)
To: Larry Finger, Tony Chuang
Cc: Pkshih, linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <e68c6aae-8d71-266a-81fe-d078ac1ef38c@lwfinger.net>
Larry,
Thanks for the response and detailed instructions, which allowed me to
build and install the rtw88 kernel module. I cannot however seem to get
my system to actually use the module. Just to recap this is an HP Omen
laptop with secure boot disabled. Upon boot-up both the new rtw88 and
old r8822be modules are loaded. If I unload the r8822be module the wifi
network connection gets terminated, even if I unload/reload the rtw88
module.
Is there something else I should be doing prior to invoking rtw88, e.g.,
blacklisting the old module?
Sincerely,
David R. Bergstein
On 3/1/19 12:28 PM, Larry Finger wrote:
> On 2/28/19 8:32 PM, David R. Bergstein wrote:
>> Tony,
>>
>> Thanks for your response. Can you advise as to the availability of the
>> new rtw88 driver? As it appears to be under development, I could not
>> locate a copy of the code for local compilation.
>
> David,
>
> Use the command 'git clone http://github.com/lwfinger/rtlwifi_new.git
> -b rtw88' to get a copy of the new driver for RTL8822BE and RTL8822CE
> in a stand-alone form. All that is needed is 'cd rtlwifi_new && make
> && sudo make install'. This version will build on kernels v4.4 and
> newer. As I have time, I will be backporting to kernels at least as
> old as 4.0.
>
> I would appreciate your comments and bug reports.
>
> Larry
>
>
^ permalink raw reply
* [ANN] wireless-regdb: master-2019-03-01
From: Seth Forshee @ 2019-03-01 21:37 UTC (permalink / raw)
To: wireless-regdb; +Cc: linux-wireless
A new release of wireless-regdb (master-2019-03-01) is available at:
https://www.kernel.org/pub/software/network/wireless-regdb/wireless-regdb-2019.03.01.tar.gz
The short log of changes since the 2018-10-24 release is below.
Thanks,
Seth
---
Chaitanya Tata (1):
wireless-regdb: update 60ghz band rules for us
Felix Fietkau (1):
wireless-regdb: Sync IN with G.S.R. 1048(E), October 2018
Peter Lundkvist (1):
wireless-regdb: Update regulatory rules for Sweden (SE) on 2.4/5/60 GHz
Rui Salvaterra (1):
wireless-regdb: Add 5725-5875 MHz rule for Portugal (PT)
Seth Forshee (1):
wireless-regdb: update regulatory database based on preceding changes
Xose Vazquez Perez (2):
wireless-regdb: delete outdated comment for DE
wireless-regdb: add URLs in README
^ permalink raw reply
* Re: [RFC PATCH v3 03/12] mac80211: IEEE 802.11 Extended Key ID support
From: Alexander Wetzel @ 2019-03-01 20:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <767ada740d984e180d0ac799487722293a50367c.camel@sipsolutions.net>
>>> So here the reasoning for why I named them as they are and why I prefer
>>> the names used in the patch.
>>> First, many drivers will handle SET_KEY and SET_KEY_RX_ONLY with the
>>> same code and not differentiate between those at all. Using EXT_as a
>>> prefix for the "normal" command is therefore a nice way to imply the
>>> command can only be used with Extended Key ID and still link it to the
>>> original command.
>>> But more important for me was the clash between what the command spells
>>> and what it does in the COMPAT mode: SET_KEY_RX_ONLY would then be used
>>> to install a TX only key which never can be used by the card for Rx.
>>> So I decided to rename it to EXT_SET_KEY, just indicating that this
>>> command adds a new key to the card for Extended Key ID and drop the
>>> confusing reference to Rx.
> Wait, what? In compat mode SET_KEY_RX_ONLY installs a TX-only key? Ah,
> you mean before you changed this.
>
> Why don't we split out compat mode then?
>
> But I see where you're coming from with the EXT_ now. I need to think of
> it less as an "extension" now, but as "extended key ID". I'm not really
> entirely sure that makes sense - even what we think of as "extended key
> ID" now might be the new normal soon? But then again the spec does the
> same thing.
>
>>> Long story short: Using SET_KEY_RXONLY and SET_KEY_TX is not wrong, but
>>> I would rate them more confusing.
> Fair enough.
I've had second (or more like tenths..) thoughts about this API.
If you like any of the solutions below more than the others I'll use
that in the next patch, of course...
In a nutshell, the point of EXT_SET_KEY is to install a key, prepare it
for Tx but NOT use it for Tx. The driver can use it for Rx (NATIVE) or
just do nothing with the (in COMPAT mode) Tx only key till mac80211
starts using it for Tx later.
1) Assuming we keep the RX_ONLY key flag we could just drop EXT_SET_KEY
and use the "normal" SET_KEY with the flag moved to ieee80211_key_conf.
We really just want to install the key to the driver here, only drivers
like ath10k need a way to figure out it must not be used for Tx.
2) We also can drop the Rx only flag/extra command and simply use
SET_KEY. ath10k will then have to honor the keyID mac80211 prepared when
it want to support Extended Key ID. (ath10k seems to need a firmware
update either way, so that could be acceptable.)
That said I've now decided to simply name the calls in the next patch:
SET_KEY
-> no RX only flag!
SET_KEY_RX
-> SET_KEY, only key must not be used for Tx
DISABLE_KEY,
-> unchanged
ACTIVATE_KEY
-> so far named EXT_KEY_RX_TX
DISABLE_KEY_RX
-> so far named EXT_DISABLE_KEY_RX
We can then continue the discussion with a new patch and the other fixes
in it when needed.
To really clean that up we would have to change the existing names to
something like ADD_KEY, REMOVE_KEY. We could then name the new calls
ADD_KEY_RX, ACTIVATE_KEY and DISABLE_KEY_RX. But that seems to be overkill.
Alexander
Alexander
^ permalink raw reply
* brcmfmac: bogus error messages during module unload
From: Stefan Wahren @ 2019-03-01 20:10 UTC (permalink / raw)
To: Arend van Spriel, Chi-Hsien Lin, Franky Lin, Hante Meuleman,
Wright Feng
Cc: linux-wireless
Hi,
this is some kind of older issue with brcmfmac. Everytime i unload the kernel module (e.g. v5.0-rc8 or next-20190301) on a Raspberry Pi 3 (multi_v7_defconfig / arm64_defconfig) after the driver has successful probed, i'm getting such bogus error messages in the kernel log:
[ 870.477114] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -5
[ 870.477122] brcmfmac: brcmf_cfg80211_get_tx_power: error (-5)
[ 871.057074] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 871.057153] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 871.057870] brcmfmac: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 871.057878] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-5)
Is there a chance to remove or at least reduce them?
Thanks
Stefan
^ permalink raw reply
* Re: Realtek r8822be kernel module does not negotiate 802.11ac connection
From: Larry Finger @ 2019-03-01 17:28 UTC (permalink / raw)
To: David R. Bergstein, Tony Chuang
Cc: Pkshih, linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <b0518665-d5ca-7c94-9808-7cc0cf565814@gmail.com>
On 2/28/19 8:32 PM, David R. Bergstein wrote:
> Tony,
>
> Thanks for your response. Can you advise as to the availability of the
> new rtw88 driver? As it appears to be under development, I could not
> locate a copy of the code for local compilation.
David,
Use the command 'git clone http://github.com/lwfinger/rtlwifi_new.git -b rtw88'
to get a copy of the new driver for RTL8822BE and RTL8822CE in a stand-alone
form. All that is needed is 'cd rtlwifi_new && make && sudo make install'. This
version will build on kernels v4.4 and newer. As I have time, I will be
backporting to kernels at least as old as 4.0.
I would appreciate your comments and bug reports.
Larry
^ permalink raw reply
* Re: [PATCH] mac80211: do not call driver wake_tx_queue op during reconfig
From: Ben Greear @ 2019-03-01 17:21 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: johannes
In-Reply-To: <3bc506d5-8432-56d4-8588-afe7dea2eba3@nbd.name>
On 3/1/19 8:13 AM, Felix Fietkau wrote:
> On 2019-03-01 17:06, Felix Fietkau wrote:
>> On 2019-03-01 16:29, Ben Greear wrote:
>>> On 3/1/19 5:48 AM, Felix Fietkau wrote:
>>>> There are several scenarios in which mac80211 can call drv_wake_tx_queue
>>>> after ieee80211_restart_hw has been called and has not yet completed.
>>>> Driver private structs are considered uninitialized until mac80211 has
>>>> uploaded the vifs, stations and keys again, so using private tx queue
>>>> data during that time is not safe.
>>>>
>>>> The driver can also not rely on drv_reconfig_complete to figure out when
>>>> it is safe to accept drv_wake_tx_queue calls again, because it is only
>>>> called after all tx queues are woken again.
>>>>
>>>> To fix this, bail out early in drv_wake_tx_queue if local->in_reconfig
>>>> is set.
>>>
>>> This reminded me of a patch I posted back in 2016. The discussion just sort of
>>> ended on it, but curious if you have a new opinion on it after debugging the
>>> issue in this patch:
>>>
>>> https://patchwork.kernel.org/patch/9457709/
>>>
>>> For what its worth, I've been using the patch above since I posted it, and
>>> it seems to work well for ath9k and ath10k.
>> I agree with what Johannes wrote about that patch. Fixing this could
>> likely be as simple as clearing IEEE80211_SDATA_IN_DRIVER on all
>> interfaces before bringing any of them back up. That way the normal
>> interface add logic applies without nasty special cases.
>> The reconfig code checks for ieee80211_sdata_running (which is
>> unaffected), so I don't think we need to save the previous value of that
>> flag.
> How about this? (untested)
> ---
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -1956,7 +1956,6 @@ static void ieee80211_flush_completed_scan(struct ieee80211_local *local,
>
> static void ieee80211_handle_reconfig_failure(struct ieee80211_local *local)
> {
> - struct ieee80211_sub_if_data *sdata;
> struct ieee80211_chanctx *ctx;
>
> /*
> @@ -1980,9 +1979,6 @@ static void ieee80211_handle_reconfig_failure(struct ieee80211_local *local)
> */
> ieee80211_sched_scan_end(local);
>
> - list_for_each_entry(sdata, &local->interfaces, list)
> - sdata->flags &= ~IEEE80211_SDATA_IN_DRIVER;
> -
> /* Mark channel contexts as not being in the driver any more to avoid
> * removing them from the driver during the shutdown process...
> */
> @@ -2135,6 +2131,9 @@ int ieee80211_reconfig(struct ieee80211_local *local)
>
> local->started = false;
>
> + list_for_each_entry(sdata, &local->interfaces, list)
> + sdata->flags &= ~IEEE80211_SDATA_IN_DRIVER;
> +
> /*
> * Upon resume hardware can sometimes be goofy due to
> * various platform / driver / bus issues, so restarting
>
Let me see if anyone (Johannes?) has comments on this... I can test it out
a bit later if no one suggests changes.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] mt76: mt76x02: only update the base mac address if necessary
From: Felix Fietkau @ 2019-03-01 16:48 UTC (permalink / raw)
To: linux-wireless; +Cc: sgruszka
Also update the mask first before calculating the vif index.
Fixes an issue where adding back the same interfaces in a different order
fails because of duplicate vif index use
Fixes: 06662264ce2ad ("mt76x02: use mask for vifs")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
index 28eccb3119d1..cd072ac614f7 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_util.c
@@ -293,6 +293,12 @@ mt76x02_add_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
struct mt76x02_dev *dev = hw->priv;
unsigned int idx = 0;
+ /* Allow to change address in HW if we create first interface. */
+ if (!dev->vif_mask &&
+ (((vif->addr[0] ^ dev->mt76.macaddr[0]) & ~GENMASK(4, 1)) ||
+ memcmp(vif->addr + 1, dev->mt76.macaddr + 1, ETH_ALEN - 1)))
+ mt76x02_mac_setaddr(dev, vif->addr);
+
if (vif->addr[0] & BIT(1))
idx = 1 + (((dev->mt76.macaddr[0] ^ vif->addr[0]) >> 2) & 7);
@@ -315,10 +321,6 @@ mt76x02_add_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
if (dev->vif_mask & BIT(idx))
return -EBUSY;
- /* Allow to change address in HW if we create first interface. */
- if (!dev->vif_mask && !ether_addr_equal(dev->mt76.macaddr, vif->addr))
- mt76x02_mac_setaddr(dev, vif->addr);
-
dev->vif_mask |= BIT(idx);
mt76x02_vif_init(dev, vif, idx);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] mac80211: do not call driver wake_tx_queue op during reconfig
From: Felix Fietkau @ 2019-03-01 16:13 UTC (permalink / raw)
To: Ben Greear, linux-wireless; +Cc: johannes
In-Reply-To: <c39a8e18-4a6b-a4db-3b25-c7d9d417d247@nbd.name>
On 2019-03-01 17:06, Felix Fietkau wrote:
> On 2019-03-01 16:29, Ben Greear wrote:
>> On 3/1/19 5:48 AM, Felix Fietkau wrote:
>>> There are several scenarios in which mac80211 can call drv_wake_tx_queue
>>> after ieee80211_restart_hw has been called and has not yet completed.
>>> Driver private structs are considered uninitialized until mac80211 has
>>> uploaded the vifs, stations and keys again, so using private tx queue
>>> data during that time is not safe.
>>>
>>> The driver can also not rely on drv_reconfig_complete to figure out when
>>> it is safe to accept drv_wake_tx_queue calls again, because it is only
>>> called after all tx queues are woken again.
>>>
>>> To fix this, bail out early in drv_wake_tx_queue if local->in_reconfig
>>> is set.
>>
>> This reminded me of a patch I posted back in 2016. The discussion just sort of
>> ended on it, but curious if you have a new opinion on it after debugging the
>> issue in this patch:
>>
>> https://patchwork.kernel.org/patch/9457709/
>>
>> For what its worth, I've been using the patch above since I posted it, and
>> it seems to work well for ath9k and ath10k.
> I agree with what Johannes wrote about that patch. Fixing this could
> likely be as simple as clearing IEEE80211_SDATA_IN_DRIVER on all
> interfaces before bringing any of them back up. That way the normal
> interface add logic applies without nasty special cases.
> The reconfig code checks for ieee80211_sdata_running (which is
> unaffected), so I don't think we need to save the previous value of that
> flag.
How about this? (untested)
---
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1956,7 +1956,6 @@ static void ieee80211_flush_completed_scan(struct ieee80211_local *local,
static void ieee80211_handle_reconfig_failure(struct ieee80211_local *local)
{
- struct ieee80211_sub_if_data *sdata;
struct ieee80211_chanctx *ctx;
/*
@@ -1980,9 +1979,6 @@ static void ieee80211_handle_reconfig_failure(struct ieee80211_local *local)
*/
ieee80211_sched_scan_end(local);
- list_for_each_entry(sdata, &local->interfaces, list)
- sdata->flags &= ~IEEE80211_SDATA_IN_DRIVER;
-
/* Mark channel contexts as not being in the driver any more to avoid
* removing them from the driver during the shutdown process...
*/
@@ -2135,6 +2131,9 @@ int ieee80211_reconfig(struct ieee80211_local *local)
local->started = false;
+ list_for_each_entry(sdata, &local->interfaces, list)
+ sdata->flags &= ~IEEE80211_SDATA_IN_DRIVER;
+
/*
* Upon resume hardware can sometimes be goofy due to
* various platform / driver / bus issues, so restarting
^ permalink raw reply
* Re: [PATCH] mac80211: do not call driver wake_tx_queue op during reconfig
From: Felix Fietkau @ 2019-03-01 16:06 UTC (permalink / raw)
To: Ben Greear, linux-wireless; +Cc: johannes, stable
In-Reply-To: <09a12ed0-dd86-2077-9ecb-c62a52186952@candelatech.com>
On 2019-03-01 16:29, Ben Greear wrote:
> On 3/1/19 5:48 AM, Felix Fietkau wrote:
>> There are several scenarios in which mac80211 can call drv_wake_tx_queue
>> after ieee80211_restart_hw has been called and has not yet completed.
>> Driver private structs are considered uninitialized until mac80211 has
>> uploaded the vifs, stations and keys again, so using private tx queue
>> data during that time is not safe.
>>
>> The driver can also not rely on drv_reconfig_complete to figure out when
>> it is safe to accept drv_wake_tx_queue calls again, because it is only
>> called after all tx queues are woken again.
>>
>> To fix this, bail out early in drv_wake_tx_queue if local->in_reconfig
>> is set.
>
> This reminded me of a patch I posted back in 2016. The discussion just sort of
> ended on it, but curious if you have a new opinion on it after debugging the
> issue in this patch:
>
> https://patchwork.kernel.org/patch/9457709/
>
> For what its worth, I've been using the patch above since I posted it, and
> it seems to work well for ath9k and ath10k.
I agree with what Johannes wrote about that patch. Fixing this could
likely be as simple as clearing IEEE80211_SDATA_IN_DRIVER on all
interfaces before bringing any of them back up. That way the normal
interface add logic applies without nasty special cases.
The reconfig code checks for ieee80211_sdata_running (which is
unaffected), so I don't think we need to save the previous value of that
flag.
- Felix
^ permalink raw reply
* Re: [PATCH] mac80211: do not call driver wake_tx_queue op during reconfig
From: Ben Greear @ 2019-03-01 15:29 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: johannes, stable
In-Reply-To: <20190301134837.88087-1-nbd@nbd.name>
On 3/1/19 5:48 AM, Felix Fietkau wrote:
> There are several scenarios in which mac80211 can call drv_wake_tx_queue
> after ieee80211_restart_hw has been called and has not yet completed.
> Driver private structs are considered uninitialized until mac80211 has
> uploaded the vifs, stations and keys again, so using private tx queue
> data during that time is not safe.
>
> The driver can also not rely on drv_reconfig_complete to figure out when
> it is safe to accept drv_wake_tx_queue calls again, because it is only
> called after all tx queues are woken again.
>
> To fix this, bail out early in drv_wake_tx_queue if local->in_reconfig
> is set.
This reminded me of a patch I posted back in 2016. The discussion just sort of
ended on it, but curious if you have a new opinion on it after debugging the
issue in this patch:
https://patchwork.kernel.org/patch/9457709/
For what its worth, I've been using the patch above since I posted it, and
it seems to work well for ath9k and ath10k.
Thanks,
Ben
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> net/mac80211/driver-ops.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
> index 28d022a3eee3..ae4f0be3b393 100644
> --- a/net/mac80211/driver-ops.h
> +++ b/net/mac80211/driver-ops.h
> @@ -1195,6 +1195,9 @@ static inline void drv_wake_tx_queue(struct ieee80211_local *local,
> {
> struct ieee80211_sub_if_data *sdata = vif_to_sdata(txq->txq.vif);
>
> + if (local->in_reconfig)
> + return;
> +
> if (!check_sdata_in_driver(sdata))
> return;
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* pull-request: wireless-drivers-next 2019-03-01
From: Kalle Valo @ 2019-03-01 14:55 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
as Linus gave us one more week here are few more patches to net-next for
5.1. Please let me know if there are any problems.
Kalle
The following changes since commit bd16693f359bbab8776541c06a6df32f3996638e:
net: fix double-free in bpf_lwt_xmit_reroute (2019-02-24 22:24:50 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2019-03-01
for you to fetch changes up to 501faf710230b67e470b314868110357cf3a554d:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2019-02-28 11:50:40 +0200)
----------------------------------------------------------------
wireless-drivers-next patches for 5.1
Last set of patches. A new hardware support for mt76 otherwise quite
normal.
Major changes:
mt76
* add driver for MT7603E/MT7628
ath10k
* more preparation for SDIO support
wil6210
* support up to 20 stations in AP mode
----------------------------------------------------------------
Abhishek Ambure (3):
ath10k: add support for ack rssi value of management tx packets
ath10k: add support for ack rssi value of data tx packets
ath10k: update the max num of peers supported for WCN3990
Ahmad Masri (2):
wil6210: support up to 20 stations in AP mode
wil6210: accessing 802.3 addresses via utility functions
Alagu Sankar (3):
ath10k: sdio: set hi_acs_flags
ath10k: sdio: disable fwlog prints
ath10k: don't report unset rssi values to mac80211
Alexei Avshalom Lazar (1):
wil6210: check null pointer in _wil_cfg80211_merge_extra_ies
Andrea Greco (1):
ath9k: debugfs: Fix SPUR-DOWN field
Colin Ian King (1):
rsi: fix missing null pointer check from a failed ieee80211_probereq_get call
Dedy Lansky (2):
wil6210: add option to drop Tx packets when Tx ring is full
wil6210: fix invalid sta statistics update
Felix Fietkau (11):
mt76: mt76x02: fix TSF sync mode
mt76: mt76x02: fix beacon timer drift adjustment
mt76: mt76x02: fix beacon timer issue
mt76: mt76x02: only reset beacon drift counter when enabling beacons
mt76: mt76x02: issue watchdog reset on MCU request timeout
mt76: mt76x02: fix ED/CCA enabling/disabling
mt76: mt76x2: unify mt76x2[u]_mac_resume
mt76: mt76x02: set MT_TXOP_HLDR_TX40M_BLK_EN for mt76x2
mt76: add driver callback for when a sta is associated
dt-bindings: net: mt76: update binding for mt7603 driver
mt76: add driver for MT7603E and MT7628/7688
Kalle Valo (2):
Merge tag 'mt76-for-kvalo-2019-02-26' of https://github.com/nbd168/wireless
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
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
Lorenzo Bianconi (6):
mt76: usb: fix warning in mt76u_buf_free
mt76: usb: introduce mt76u_fill_bulk_urb routine
mt76: usb: simplify rx buffer allocation
mt76: usb: simplify mt76u_tx_build_sg routine
mt76: usb: check urb->num_sgs limit in mt76u_process_rx_entry
mt76: remove no longer used routine declarations
Maya Erez (2):
wil6210: remove rtap_include_phy_info module param
wil6210: ignore HALP ICR if already handled
Rafał Miłecki (2):
brcmfmac: fix size of the struct msgbuf_ring_status
brcmfmac: print firmware reported general status errors
Rakesh Pillai (2):
ath10k: fix descriptor size in ce tx completion for WCN3990
ath10k: enhance logging for vdev pdev & peer set param
Stanislaw Gruszka (3):
mt76usb: allow mt76u_bulk_msg be used for reads
mt76usb: use synchronous msg for mcu command responses
mt76usb: remove usb_mcu.c
Surabhi Vishnoi (6):
ath10k: Fix length of wmi tlv command for protected mgmt frames
ath10k: Fix the incorrect updation of NSS data in tx stats
ath10k: Fix the wrong updation of BW in tx_stats debugfs entry
ath10k: Fix the wrong updation of SGI in tx_stats debugfs
ath10k: Fix the wrong calculation ht_idx and idx of rate table for tx_stats
ath10k: Fill rx duration for each peer in fw_stats for WCN3990
Toke Høiland-Jørgensen (1):
ath9k: Make sure to zero status.tx_time before reporting TX status
Wen Gong (2):
ath10k: sdio: reset chip on power_down()
ath10k: remove the calibration data fetch for sdio
Wen Yang (1):
mt76: fix a leaked reference by adding a missing of_node_put
Yu Wang (1):
ath10k: correct the format of host memory chunks in wmi init command
YueHaibing (4):
ath9k: remove set but not used variable 'acq'
rtlwifi: rtl8723be: Remove set but not used variable 'b_last_is_cur_rdlstate'
rtlwifi: rtl8723ae: Remove set but not used variable 'bt_retry_cnt'
rtlwifi: rtl8192se: Remove set but not used variable 'seg_ptr'
.../bindings/net/wireless/mediatek,mt76.txt | 19 +
drivers/net/wireless/ath/ath10k/ce.c | 66 +-
drivers/net/wireless/ath/ath10k/ce.h | 2 +
drivers/net/wireless/ath/ath10k/core.c | 29 +-
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 3 +
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 7 +-
drivers/net/wireless/ath/ath10k/htt.h | 86 +
drivers/net/wireless/ath/ath10k/htt_rx.c | 50 +-
drivers/net/wireless/ath/ath10k/hw.c | 32 +-
drivers/net/wireless/ath/ath10k/hw.h | 28 +-
drivers/net/wireless/ath/ath10k/sdio.c | 24 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 109 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 45 +
drivers/net/wireless/ath/ath10k/wmi.c | 44 +-
drivers/net/wireless/ath/ath10k/wmi.h | 21 +-
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 9 +-
drivers/net/wireless/ath/ath9k/xmit.c | 3 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 20 +-
drivers/net/wireless/ath/wil6210/debugfs.c | 23 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 12 +-
drivers/net/wireless/ath/wil6210/main.c | 13 +-
drivers/net/wireless/ath/wil6210/rx_reorder.c | 10 +-
drivers/net/wireless/ath/wil6210/trace.h | 3 +-
drivers/net/wireless/ath/wil6210/txrx.c | 254 +--
drivers/net/wireless/ath/wil6210/txrx.h | 51 +-
drivers/net/wireless/ath/wil6210/txrx_edma.c | 11 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 16 +-
drivers/net/wireless/ath/wil6210/wmi.c | 83 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 26 +-
drivers/net/wireless/mediatek/mt76/Kconfig | 1 +
drivers/net/wireless/mediatek/mt76/Makefile | 3 +-
drivers/net/wireless/mediatek/mt76/eeprom.c | 24 +-
drivers/net/wireless/mediatek/mt76/mac80211.c | 5 +
drivers/net/wireless/mediatek/mt76/mt76.h | 29 +-
drivers/net/wireless/mediatek/mt76/mt7603/Kconfig | 9 +
drivers/net/wireless/mediatek/mt76/mt7603/Makefile | 6 +
drivers/net/wireless/mediatek/mt76/mt7603/beacon.c | 186 +++
drivers/net/wireless/mediatek/mt76/mt7603/core.c | 73 +
.../net/wireless/mediatek/mt76/mt7603/debugfs.c | 56 +
drivers/net/wireless/mediatek/mt76/mt7603/dma.c | 215 +++
drivers/net/wireless/mediatek/mt76/mt7603/eeprom.c | 168 ++
drivers/net/wireless/mediatek/mt76/mt7603/eeprom.h | 86 +
drivers/net/wireless/mediatek/mt76/mt7603/init.c | 578 +++++++
drivers/net/wireless/mediatek/mt76/mt7603/mac.c | 1749 ++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt7603/mac.h | 242 +++
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 709 ++++++++
drivers/net/wireless/mediatek/mt76/mt7603/mcu.c | 483 ++++++
drivers/net/wireless/mediatek/mt76/mt7603/mcu.h | 110 ++
drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h | 253 +++
drivers/net/wireless/mediatek/mt76/mt7603/pci.c | 80 +
drivers/net/wireless/mediatek/mt76/mt7603/regs.h | 774 +++++++++
drivers/net/wireless/mediatek/mt76/mt7603/soc.c | 85 +
drivers/net/wireless/mediatek/mt76/mt76x0/init.c | 2 +
drivers/net/wireless/mediatek/mt76/mt76x0/main.c | 2 +
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c | 6 +-
drivers/net/wireless/mediatek/mt76/mt76x0/usb.c | 16 -
drivers/net/wireless/mediatek/mt76/mt76x02.h | 1 +
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 9 +-
drivers/net/wireless/mediatek/mt76/mt76x02_mcu.c | 1 +
drivers/net/wireless/mediatek/mt76/mt76x02_mmio.c | 42 +-
.../net/wireless/mediatek/mt76/mt76x02_usb_mcu.c | 36 +-
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 9 +-
drivers/net/wireless/mediatek/mt76/mt76x2/mac.c | 3 +
drivers/net/wireless/mediatek/mt76/mt76x2/mac.h | 8 +-
.../net/wireless/mediatek/mt76/mt76x2/mt76x2u.h | 1 -
.../net/wireless/mediatek/mt76/mt76x2/pci_init.c | 7 -
.../net/wireless/mediatek/mt76/mt76x2/pci_phy.c | 7 +-
drivers/net/wireless/mediatek/mt76/mt76x2/usb.c | 11 -
.../net/wireless/mediatek/mt76/mt76x2/usb_init.c | 5 -
.../net/wireless/mediatek/mt76/mt76x2/usb_mac.c | 13 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_main.c | 5 +-
.../net/wireless/mediatek/mt76/mt76x2/usb_phy.c | 3 +-
drivers/net/wireless/mediatek/mt76/usb.c | 154 +-
drivers/net/wireless/mediatek/mt76/usb_mcu.c | 57 -
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 -
.../wireless/realtek/rtlwifi/rtl8192c/dm_common.c | 6 +-
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8192c/main.c | 1 -
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 1 +
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 7 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 1 +
.../net/wireless/realtek/rtlwifi/rtl8192ce/table.c | 1 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 8 +
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 9 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.h | 4 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 8 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.h | 3 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 7 +
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.h | 2 -
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.c | 6 +-
.../wireless/realtek/rtlwifi/rtl8723ae/hal_btc.c | 2 -
.../net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 3 -
drivers/net/wireless/realtek/rtlwifi/usb.c | 3 +
drivers/net/wireless/realtek/rtlwifi/usb.h | 5 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 351 ++--
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 4 +
103 files changed, 7121 insertions(+), 768 deletions(-)
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/Kconfig
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/Makefile
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/beacon.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/core.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/debugfs.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/dma.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/eeprom.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/eeprom.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/init.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/mac.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/mac.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/main.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/mcu.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/mcu.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/mt7603.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/pci.c
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/regs.h
create mode 100644 drivers/net/wireless/mediatek/mt76/mt7603/soc.c
delete mode 100644 drivers/net/wireless/mediatek/mt76/usb_mcu.c
--
Kalle Valo
^ permalink raw reply
* [PATCH] ath10k: Move board id and fw version logging to info level
From: Govind Singh @ 2019-03-01 14:50 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Govind Singh
Board id and fw version is not printed by default in qmi
cap response message. Move board id and fw version logging
to info level for default logging.
[ 34.005399] ath10k_snoc a000000.wifi: qmi chip_id 0x30b chip_family 0x4001 board_id 0xff soc_id 0x40070000
[ 34.005432] ath10k_snoc a000000.wifi: qmi fw_version 0x3106836b fw_build_timestamp 2019-02-13 10:24 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.1-00875-QCAHLSWMTPL-1
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/qmi.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 54f783ceb147..2b086fa16040 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -523,6 +523,7 @@ static int ath10k_qmi_cap_send_sync_msg(struct ath10k_qmi *qmi)
struct wlfw_cap_resp_msg_v01 *resp;
struct wlfw_cap_req_msg_v01 req = {};
struct ath10k *ar = qmi->ar;
+ struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
struct qmi_txn txn;
int ret;
@@ -577,13 +578,13 @@ static int ath10k_qmi_cap_send_sync_msg(struct ath10k_qmi *qmi)
strlcpy(qmi->fw_build_id, resp->fw_build_id,
MAX_BUILD_ID_LEN + 1);
- ath10k_dbg(ar, ATH10K_DBG_QMI,
- "qmi chip_id 0x%x chip_family 0x%x board_id 0x%x soc_id 0x%x",
- qmi->chip_info.chip_id, qmi->chip_info.chip_family,
- qmi->board_info.board_id, qmi->soc_info.soc_id);
- ath10k_dbg(ar, ATH10K_DBG_QMI,
- "qmi fw_version 0x%x fw_build_timestamp %s fw_build_id %s",
- qmi->fw_version, qmi->fw_build_timestamp, qmi->fw_build_id);
+ if (!test_bit(ATH10K_SNOC_FLAG_REGISTERED, &ar_snoc->flags)) {
+ ath10k_info(ar, "qmi chip_id 0x%x chip_family 0x%x board_id 0x%x soc_id 0x%x",
+ qmi->chip_info.chip_id, qmi->chip_info.chip_family,
+ qmi->board_info.board_id, qmi->soc_info.soc_id);
+ ath10k_info(ar, "qmi fw_version 0x%x fw_build_timestamp %s fw_build_id %s",
+ qmi->fw_version, qmi->fw_build_timestamp, qmi->fw_build_id);
+ }
kfree(resp);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH] mt76x02: fix hdr pointer in write txwi for USB
From: Felix Fietkau @ 2019-03-01 14:23 UTC (permalink / raw)
To: Stanislaw Gruszka, Kalle Valo; +Cc: linux-wireless, Lorenzo Bianconi
In-Reply-To: <1551366666-28477-1-git-send-email-sgruszka@redhat.com>
On 2019-02-28 16:11, Stanislaw Gruszka wrote:
> Since we add txwi at the begining of skb->data, it no longer point
> to ieee80211_hdr. This breaks settings TS bit for probe response and
> beacons.
>
> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Applied, thanks.
- Felix
^ permalink raw reply
* Re: [PATCH v2] mt76: introduce q->stopped parameter
From: Felix Fietkau @ 2019-03-01 14:22 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, sgruszka, lorenzo.bianconi
In-Reply-To: <803f9e01a21ef024ce66d1fda96debe278b0a398.1551360035.git.lorenzo@kernel.org>
On 2019-02-28 14:31, Lorenzo Bianconi wrote:
> Introduce mt76_queue stopped parameter in order to run
> ieee80211_wake_queue only when mac80211 queues have been
> previously stopped and avoid to disable interrupts when
> it is not necessary
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Applied, thanks.
- Felix
^ permalink raw reply
* [PATCH 2/3] mt76: mt76x02: when setting a key, use PN from mac80211
From: Felix Fietkau @ 2019-03-01 14:20 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20190301142023.18179-1-nbd@nbd.name>
Preparation for full device restart support
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
index 91ff6598eccf..8109bac5aee6 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_mac.c
@@ -73,6 +73,7 @@ int mt76x02_mac_wcid_set_key(struct mt76x02_dev *dev, u8 idx,
enum mt76x02_cipher_type cipher;
u8 key_data[32];
u8 iv_data[8];
+ u64 pn;
cipher = mt76x02_mac_get_key_info(key, key_data);
if (cipher == MT_CIPHER_NONE && key)
@@ -85,9 +86,22 @@ int mt76x02_mac_wcid_set_key(struct mt76x02_dev *dev, u8 idx,
if (key) {
mt76_rmw_field(dev, MT_WCID_ATTR(idx), MT_WCID_ATTR_PAIRWISE,
!!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE));
+
+ pn = atomic64_read(&key->tx_pn);
+
iv_data[3] = key->keyidx << 6;
- if (cipher >= MT_CIPHER_TKIP)
+ if (cipher >= MT_CIPHER_TKIP) {
iv_data[3] |= 0x20;
+ put_unaligned_le32(pn >> 16, &iv_data[4]);
+ }
+
+ if (cipher == MT_CIPHER_TKIP) {
+ iv_data[0] = (pn >> 8) & 0xff;
+ iv_data[1] = (iv_data[0] | 0x20) & 0x7f;
+ iv_data[2] = pn & 0xff;
+ } else if (cipher >= MT_CIPHER_AES_CCMP) {
+ put_unaligned_le16((pn & 0xffff), &iv_data[0]);
+ }
}
mt76_wr_copy(dev, MT_WCID_IV(idx), iv_data, sizeof(iv_data));
--
2.17.0
^ 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