* Re: Hang on wireless removal..
From: Sedat Dilek @ 2020-06-08 7:14 UTC (permalink / raw)
To: Johannes Berg
Cc: Linus Torvalds, David S. Miller, Jakub Kicinski, linux-wireless,
Netdev, Linux Kernel Mailing List
In-Reply-To: <5DD82C75-5868-4F2D-B90F-F6205CA85C66@sipsolutions.net>
On Sat, Jun 6, 2020 at 9:56 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Hi, sorry for the top post, on my phone.
>
> Yes, your analysis is spot on I think. I've got a fix for this in my jberg/mac80211 tree, there's a deadlock with a work struct and the rtnl.
>
> Sorry about that. My testing should've caught it, but that exact scenario didn't happen, and lockdep for disabled due to some unrelated issues at early boot,so this didn't show up... (I also sent fixes for the other issue in user mode Linux)
>
Is that the fix you are talking about?
commit 79ea1e12c0b8540100e89b32afb9f0e6503fad35
"cfg80211: fix management registrations deadlock"
- Sedat -
P.S.: I fixed up the top-post issue :-).
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=79ea1e12c0b8540100e89b32afb9f0e6503fad35
^ permalink raw reply
* Re: [PATCH] iwlwifi: mvm: fix interface bringup on non-ACPI configs
From: Luciano Coelho @ 2020-06-08 6:02 UTC (permalink / raw)
To: Wang Xuerui, linux-wireless; +Cc: Gil Adam
In-Reply-To: <20191121074832.6978-1-git@xen0n.name>
On Thu, 2019-11-21 at 15:48 +0800, Wang Xuerui wrote:
> Previously the non-ACPI stub of iwl_mvm_ppag_init unconditionally
> returned -ENOENT, that in turn blocked flow of iwl_mvm_up.
>
> Take the precedent of iwl_mvm_sar_geo_init, make iwl_mvm_ppag_init no-op
> on non-ACPI configs.
>
> Fixes: 6ce1e5c0c207 ("iwlwifi: support per-platform antenna gain")
> Cc: Gil Adam <gil.adam@intel.com>
> Cc: Luca Coelho <luciano.coelho@intel.com>
> Signed-off-by: Wang Xuerui <git@xen0n.name>
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> index d9eb2b286438..04ac47b7cae9 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> @@ -1169,7 +1169,7 @@ int iwl_mvm_ppag_send_cmd(struct iwl_mvm *mvm)
>
> static int iwl_mvm_ppag_init(struct iwl_mvm *mvm)
> {
> - return -ENOENT;
> + return 0;
> }
> #endif /* CONFIG_ACPI */
This was already fixed in another patch. Thanks anyway!
--
Cheers,
Luca.
^ permalink raw reply
* mt76 support for MT7668 SDIO?
From: Christian Hewitt @ 2020-06-08 4:45 UTC (permalink / raw)
To: Linux Wireless
I’m a maintainer for a distro that runs Kodi mediacentre on many popular ARM SBCs and Android STBs (replacing Android).
Similar to my request on RTL8822CS, I have a number of requests for WiFi support on Amlogic SoC devices using MT7668 chips. The BT side of the module is supported in mainline for sometime, but there is no mention of WiFi.
Is there any plan or timeline for MT7668 SDIO support in mt76? .. I’m struggling to even find vendor drivers for this chip.
Christian
^ permalink raw reply
* rtw88 SDIO support?
From: Christian Hewitt @ 2020-06-08 4:42 UTC (permalink / raw)
To: Linux Wireless
I’m a maintainer for a distro that runs Kodi mediacentre on many popular ARM SBCs and Android STBs (replacing Android).
I have a number of requests for WiFi support on Amlogic SoC devices using RTL8822CS chips which rtw88 supports on PCI, but not SDIO.
Can I ask if there is any timeline/plan for SDIO support? .. the out-of-tree vendor drivers are hassle for distro’s to maintain.
Christian
^ permalink raw reply
* Re: Many errors on dmesg and weak signal with driver rtw_8822be on Kubuntu 20.04
From: Larry Finger @ 2020-06-07 23:22 UTC (permalink / raw)
To: Lorenz Bonat, linux-wireless
In-Reply-To: <CABcAdhgcbNWMRh5t7_dH_d2-nrTV0xwjR-Zu3e8cfF29SnM4kg@mail.gmail.com>
On 6/7/20 3:39 PM, Lorenz Bonat wrote:
> To whom it may concern,
> I am using the last available driver on the lwfinger github
> repository(https://github.com/lwfinger/rtlwifi_new/) for the RTL8822be
> adapter. I am using kernel 5.7.0 and my laptop is an HP Envy x360
> ag000xx series. I persistently have struggled with the signal
> stability of this chip, and it continues to spit out errors into the
> dmesg log. The signal strength is lower than in Windows 10, and when I
> try to speedtest my internet connection I see a lot of variance
> between runs.
>
> The internet is unusable when surfing the web, and it is very annoying.
>
> I have opened an issue on the repository of lwfinger, i will link it
> for you because there are a lot of explanations there already.
> https://github.com/lwfinger/rtlwifi_new/issues/607
>
> I am attaching a file with all the dmesg entry outputted by the
> rtw_8822be module(dmesg | grep rtw). I have noticed that I receive a
> lot of "timed out to flush queue 1" errors and after a while the
> driver crashes and I receive a "purge skb(s) not reported by firmware"
> warning.
>
> If you need more information please let me know, and I will provide
> them. I am willing to test any experimental driver if you want to send
> me some material to test.
Lorenz,
I do not see any attached material. Did you forget?
For the rest of readers: The GitHub repo containing the rtw88 drivers is
essentially what is found at wireless-drivers-next with 2 exceptions: 1.
Conditional compilation needed to account for kernel API changes is added, and
2. I gnerally apply any patches sent by the Realtek authors as soon as they are
posted in this ML. When there are fixes due to reviews, I update the sources.
Larry
^ permalink raw reply
* Many errors on dmesg and weak signal with driver rtw_8822be on Kubuntu 20.04
From: Lorenz Bonat @ 2020-06-07 20:39 UTC (permalink / raw)
To: linux-wireless
To whom it may concern,
I am using the last available driver on the lwfinger github
repository(https://github.com/lwfinger/rtlwifi_new/) for the RTL8822be
adapter. I am using kernel 5.7.0 and my laptop is an HP Envy x360
ag000xx series. I persistently have struggled with the signal
stability of this chip, and it continues to spit out errors into the
dmesg log. The signal strength is lower than in Windows 10, and when I
try to speedtest my internet connection I see a lot of variance
between runs.
The internet is unusable when surfing the web, and it is very annoying.
I have opened an issue on the repository of lwfinger, i will link it
for you because there are a lot of explanations there already.
https://github.com/lwfinger/rtlwifi_new/issues/607
I am attaching a file with all the dmesg entry outputted by the
rtw_8822be module(dmesg | grep rtw). I have noticed that I receive a
lot of "timed out to flush queue 1" errors and after a while the
driver crashes and I receive a "purge skb(s) not reported by firmware"
warning.
If you need more information please let me know, and I will provide
them. I am willing to test any experimental driver if you want to send
me some material to test.
Best regards
Bonat Laurence
^ permalink raw reply
* pull request: mt76 2019-06-07
From: Felix Fietkau @ 2020-06-07 15:28 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
Hi Kalle,
here's another pull request for 5.8 with a few fixes
- Felix
The following changes since commit 1806c13dc2532090d742ce03847b22367fb20ad6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2020-05-31 17:48:46 -0700)
are available in the Git repository at:
https://github.com/nbd168/wireless tags/mt76-for-kvalo-2020-06-07
for you to fetch changes up to 7f88314321e20744114bc596b6528bb9d57ff46f:
mt76: overwrite qid for non-bufferable mgmt frames (2020-06-07 16:59:40 +0200)
----------------------------------------------------------------
mt76 patches for 5.8
* tx queueing fixes for mt7615/22/63
* locking fix
----------------------------------------------------------------
Lorenzo Bianconi (4):
mt76: add missing lock configuring coverage class
mt76: mt7615: fix lmac queue debugsfs entry
mt76: mt7615: fix hw queue mapping
mt76: overwrite qid for non-bufferable mgmt frames
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2 ++
drivers/net/wireless/mediatek/mt76/mt7615/debugfs.c | 9 +++++----
drivers/net/wireless/mediatek/mt76/mt7615/dma.c | 9 +++++----
drivers/net/wireless/mediatek/mt76/mt7615/mac.c | 20 +++++++-------------
drivers/net/wireless/mediatek/mt76/mt7615/mac.h | 15 ---------------
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 4 ++++
drivers/net/wireless/mediatek/mt76/mt7615/mmio.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h | 30 ++++++++++++++++++++++++++++++
drivers/net/wireless/mediatek/mt76/mt7615/usb.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7915/main.c | 3 +++
drivers/net/wireless/mediatek/mt76/tx.c | 7 +++++++
drivers/net/wireless/mediatek/mt76/usb.c | 17 +++++++++--------
13 files changed, 75 insertions(+), 46 deletions(-)
^ permalink raw reply
* [PATCH v2] mt76: mt7663: introduce ARP filter offload
From: Lorenzo Bianconi @ 2020-06-07 9:34 UTC (permalink / raw)
To: nbd; +Cc: ryder.lee, sean.wang, lorenzo.bianconi, linux-wireless,
linux-mediatek
From: Sean Wang <sean.wang@mediatek.com>
Introduce ARP filter offload
Co-developed-by: Wan-Feng Jiang <Wan-Feng.Jiang@mediatek.com>
Signed-off-by: Wan-Feng Jiang <Wan-Feng.Jiang@mediatek.com>
Co-developed-by: Soul Huang <Soul.Huang@mediatek.com>
Signed-off-by: Soul Huang <Soul.Huang@mediatek.com>
Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
Changes since v1:
- set limit for offload addresses to 4
---
.../net/wireless/mediatek/mt76/mt7615/main.c | 3 +
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 74 +++++++++++++++++++
.../net/wireless/mediatek/mt76/mt7615/mcu.h | 13 +++-
.../wireless/mediatek/mt76/mt7615/mt7615.h | 4 +-
4 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index beaca8127680..81fc4982a01f 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -491,6 +491,9 @@ static void mt7615_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_PS)
mt7615_mcu_set_vif_ps(dev, vif);
+ if (changed & BSS_CHANGED_ARP_FILTER)
+ mt7615_mcu_update_arp_filter(hw, vif, info);
+
mutex_unlock(&dev->mt76.mutex);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 6e869b8c5e26..b76ecc24f333 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -3542,6 +3542,32 @@ mt7615_mcu_set_gtk_rekey(struct mt7615_dev *dev,
&req, sizeof(req), true);
}
+static int
+mt7615_mcu_set_arp_filter(struct mt7615_dev *dev, struct ieee80211_vif *vif,
+ bool suspend)
+{
+ struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
+ struct {
+ struct {
+ u8 bss_idx;
+ u8 pad[3];
+ } __packed hdr;
+ struct mt7615_arpns_tlv arpns;
+ } req = {
+ .hdr = {
+ .bss_idx = mvif->idx,
+ },
+ .arpns = {
+ .tag = cpu_to_le16(UNI_OFFLOAD_OFFLOAD_ARP),
+ .len = cpu_to_le16(sizeof(struct mt7615_arpns_tlv)),
+ .mode = suspend,
+ },
+ };
+
+ return __mt76_mcu_send_msg(&dev->mt76, MCU_UNI_CMD_OFFLOAD,
+ &req, sizeof(req), true);
+}
+
void mt7615_mcu_set_suspend_iter(void *priv, u8 *mac,
struct ieee80211_vif *vif)
{
@@ -3554,6 +3580,7 @@ void mt7615_mcu_set_suspend_iter(void *priv, u8 *mac,
mt7615_mcu_set_bss_pm(phy->dev, vif, suspend);
mt7615_mcu_set_gtk_rekey(phy->dev, vif, suspend);
+ mt7615_mcu_set_arp_filter(phy->dev, vif, suspend);
mt7615_mcu_set_suspend_mode(phy->dev, vif, suspend, 1, true);
@@ -3653,6 +3680,53 @@ int mt7615_mcu_set_roc(struct mt7615_phy *phy, struct ieee80211_vif *vif,
sizeof(req), false);
}
+int mt7615_mcu_update_arp_filter(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_bss_conf *info)
+{
+ struct mt7615_vif *mvif = (struct mt7615_vif *)vif->drv_priv;
+ struct mt7615_dev *dev = mt7615_hw_dev(hw);
+ struct sk_buff *skb;
+ int i, len = min_t(int, info->arp_addr_cnt,
+ IEEE80211_BSS_ARP_ADDR_LIST_LEN);
+ struct {
+ struct {
+ u8 bss_idx;
+ u8 pad[3];
+ } __packed hdr;
+ struct mt7615_arpns_tlv arp;
+ } req_hdr = {
+ .hdr = {
+ .bss_idx = mvif->idx,
+ },
+ .arp = {
+ .tag = cpu_to_le16(UNI_OFFLOAD_OFFLOAD_ARP),
+ .len = cpu_to_le16(sizeof(struct mt7615_arpns_tlv)),
+ .ips_num = len,
+ .mode = 2, /* update */
+ .option = 1,
+ },
+ };
+
+ if (!mt7615_firmware_offload(dev))
+ return 0;
+
+ skb = mt76_mcu_msg_alloc(&dev->mt76, NULL,
+ sizeof(req_hdr) + len * sizeof(__be32));
+ if (!skb)
+ return -ENOMEM;
+
+ skb_put_data(skb, &req_hdr, sizeof(req_hdr));
+ for (i = 0; i < len; i++) {
+ u8 *addr = (u8 *)skb_put(skb, sizeof(__be32));
+
+ memcpy(addr, &info->arp_addr_list[i], sizeof(__be32));
+ }
+
+ return __mt76_mcu_skb_send_msg(&dev->mt76, skb,
+ MCU_UNI_CMD_OFFLOAD, true);
+}
+
int mt7615_mcu_set_p2p_oppps(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index 2314d0b23af1..64f7471a57bb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -545,6 +545,15 @@ struct mt7615_roc_tlv {
u8 rsv1[8];
} __packed;
+struct mt7615_arpns_tlv {
+ __le16 tag;
+ __le16 len;
+ u8 mode;
+ u8 ips_num;
+ u8 option;
+ u8 pad[1];
+} __packed;
+
/* offload mcu commands */
enum {
MCU_CMD_START_HW_SCAN = MCU_CE_PREFIX | 0x03,
@@ -580,8 +589,8 @@ enum {
};
enum {
- UNI_OFFLOAD_OFFLOAD_ARPNS_IPV4,
- UNI_OFFLOAD_OFFLOAD_ARPNS_IPV6,
+ UNI_OFFLOAD_OFFLOAD_ARP,
+ UNI_OFFLOAD_OFFLOAD_ND,
UNI_OFFLOAD_OFFLOAD_GTK_REKEY,
UNI_OFFLOAD_OFFLOAD_BMC_RPY_DETECT,
};
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
index 3e7d51bf42a4..a9513a456521 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h
@@ -585,7 +585,9 @@ void mt7615_mcu_set_suspend_iter(void *priv, u8 *mac,
int mt7615_mcu_update_gtk_rekey(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct cfg80211_gtk_rekey_data *key);
-
+int mt7615_mcu_update_arp_filter(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_bss_conf *info);
int __mt7663_load_firmware(struct mt7615_dev *dev);
/* usb */
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] ath10k: Move msa region map/unmap to init/deinit path
From: Govind Singh @ 2020-06-06 16:12 UTC (permalink / raw)
To: ath10k, manivannan.sadhasivam, sibis; +Cc: linux-wireless
In-Reply-To: <1591191231-31917-1-git-send-email-govinds@codeaurora.org>
Pls ignore this WAR as it does not fix all cases.
On 2020-06-03 19:03, Govind Singh wrote:
> With kernel qrtr switch from user space qrtr, fw crash is seen
> during reboot. During reboot modem rproc shutdown causes wlan qmi
> service exit and msa region gets unmapped. Since pdev is not suspended
> hw still accessing the msa region and this results in fw crash as
> msa region is unmapped.
>
> Decouple msa mapping from wlan qmi server arrive/exit to init/deinit
> path.
>
> Testing is pending with "0c2204a4ad71 net: qrtr: Migrate nameservice
> to kernel from userspace", only regression sanity performed with user
> space
> qrtr on QCS404/SC7180.
>
> Fixes: 0c2204a4ad71 net: qrtr: Migrate nameservice to kernel from
> userspace
> Signed-off-by: Govind Singh <govinds@codeaurora.org>
> ---
> drivers/net/wireless/ath/ath10k/qmi.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c
> b/drivers/net/wireless/ath/ath10k/qmi.c
> index 5ae829b46c3d..8b1291e28ba2 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -796,22 +796,16 @@ static void
> ath10k_qmi_event_server_arrive(struct ath10k_qmi *qmi)
> */
> msleep(20);
>
> - ret = ath10k_qmi_setup_msa_permissions(qmi);
> - if (ret)
> - return;
> -
> ret = ath10k_qmi_msa_ready_send_sync_msg(qmi);
> if (ret)
> - goto err_setup_msa;
> + return;
>
> ret = ath10k_qmi_cap_send_sync_msg(qmi);
> if (ret)
> - goto err_setup_msa;
> + return;
>
> return;
>
> -err_setup_msa:
> - ath10k_qmi_remove_msa_permission(qmi);
> }
>
> static int ath10k_qmi_fetch_board_file(struct ath10k_qmi *qmi)
> @@ -854,7 +848,6 @@ static void ath10k_qmi_event_server_exit(struct
> ath10k_qmi *qmi)
> struct ath10k *ar = qmi->ar;
> struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
>
> - ath10k_qmi_remove_msa_permission(qmi);
> ath10k_core_free_board_files(ar);
> if (!test_bit(ATH10K_SNOC_FLAG_UNREGISTERING, &ar_snoc->flags))
> ath10k_snoc_fw_crashed_dump(ar);
> @@ -1046,6 +1039,10 @@ int ath10k_qmi_init(struct ath10k *ar, u32
> msa_size)
> if (ret)
> goto err_qmi_lookup;
>
> + ret = ath10k_qmi_setup_msa_permissions(qmi);
> + if (ret)
> + goto err_qmi_lookup;
> +
> return 0;
>
> err_qmi_lookup:
> @@ -1064,6 +1061,7 @@ int ath10k_qmi_deinit(struct ath10k *ar)
> struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> struct ath10k_qmi *qmi = ar_snoc->qmi;
>
> + ath10k_qmi_remove_msa_permission(qmi);
> qmi_handle_release(&qmi->qmi_hdl);
> cancel_work_sync(&qmi->event_work);
> destroy_workqueue(qmi->event_wq);
^ permalink raw reply
* Re: Hang on wireless removal..
From: Johannes Berg @ 2020-06-06 7:56 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Jakub Kicinski
Cc: linux-wireless, Netdev, Linux Kernel Mailing List
In-Reply-To: <CAHk-=wj0QUaYcLHKG=_fw65NqhGbqvnU958SkHak9mg9qNwR+A@mail.gmail.com>
Hi, sorry for the top post, on my phone.
Yes, your analysis is spot on I think. I've got a fix for this in my jberg/mac80211 tree, there's a deadlock with a work struct and the rtnl.
Sorry about that. My testing should've caught it, but that exact scenario didn't happen, and lockdep for disabled due to some unrelated issues at early boot,so this didn't show up... (I also sent fixes for the other issue in user mode Linux)
Johannes
On 6 June 2020 00:41:27 CEST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>So I think there's something wrong with wireless networking, and
>(likely) in particular turning off wireless. And I think the problem
>came in this merge window, because now my machine hangs on shutdown.
>
>My new desktop is otherwise working fine, but it has some unnecessary
>wireless capability on the motherboard, in the form of a Intel Wi-Fi 6
>AX200 module that I don't use (since I end up using wired gig ethernet
>instead).
>
>And while debugging the shutdown hang (symptom: systemd waits forever
>for NetworkManager and WPA supplicant), I turned off the WiFi.
>
>And what do you know, things went all sideways.
>
>They went sideways because everything that wants the rtnl lock seems
>to just hang.
>
>Example:
>
> kworker/57:2 D 0 1592 2 0x80004080
> Workqueue: events_power_efficient reg_check_chans_work [cfg80211]
> Call Trace:
> __schedule+0x30b/0x4b0
> ? schedule+0x77/0xa0
> ? schedule_preempt_disabled+0xa/0x10
> ? __mutex_lock+0x264/0x410
> ? psi_group_change+0x44/0x260
> ? reg_check_chans_work+0x1d/0x300 [cfg80211]
> ? __switch_to_asm+0x42/0x70
> ? process_one_work+0x1fa/0x3f0
> ? worker_thread+0x25d/0x480
> ? kthread+0x121/0x130
> ? process_one_work+0x3f0/0x3f0
> ? kthread_blkcg+0x30/0x30
> ? ret_from_fork+0x22/0x30
> kworker/60:2 D 0 1926 2 0x80004000
> Workqueue: ipv6_addrconf addrconf_verify_work
> Call Trace:
> __schedule+0x30b/0x4b0
> ? schedule+0x77/0xa0
> ? schedule_preempt_disabled+0xa/0x10
> ? __mutex_lock+0x264/0x410
> ? addrconf_verify_work+0xa/0x20
> ? process_one_work+0x1fa/0x3f0
> ? worker_thread+0x25d/0x480
> ? kthread+0x121/0x130
> ? process_one_work+0x3f0/0x3f0
> ? kthread_blkcg+0x30/0x30
> ? ret_from_fork+0x22/0x30
> NetworkManager D 0 4329 1 0x00004000
> Call Trace:
> __schedule+0x30b/0x4b0
> ? schedule+0x77/0xa0
> ? schedule_preempt_disabled+0xa/0x10
> ? __mutex_lock+0x264/0x410
> ? __netlink_dump_start+0xa7/0x300
> ? rtnl_dellink+0x3c0/0x3c0
> ? rtnetlink_rcv_msg+0x375/0x3d0
> ? poll_freewait+0x35/0xa0
> ? do_sys_poll+0x58f/0x5f0
> ? rtnl_dellink+0x3c0/0x3c0
> ? __ia32_compat_sys_ppoll_time64+0x120/0x120
> ? ip_output+0x6a/0xd0
> ? ip_mc_finish_output+0x120/0x120
> ? avc_has_perm+0x34/0xa0
> ? rtnetlink_bind+0x30/0x30
> ? netlink_rcv_skb+0xfb/0x130
> ? netlink_unicast+0x1bf/0x2e0
> ? netlink_sendmsg+0x385/0x410
> ? __sys_sendto+0x21f/0x230
> ? move_addr_to_user+0x97/0xc0
> ? alloc_file_pseudo+0x9b/0xd0
> ? sock_alloc_file+0xc4/0x100
> ? __x64_sys_sendto+0x22/0x30
> ? do_syscall_64+0x5e/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
>and perhaps most interestingly, wpa_supplicant is waiting for some of
>those workqueues that are waiting for the lock:
>
> wpa_supplicant D 0 2162 1 0x00004000
> Call Trace:
> __schedule+0x30b/0x4b0
> ? schedule+0x77/0xa0
> ? schedule_timeout+0x22/0x150
> ? ttwu_queue+0xf4/0x120
> ? wait_for_common+0xac/0x110
> ? __flush_work+0x200/0x230
> ? put_pwq+0x70/0x70
> ? __cfg80211_unregister_wdev+0x95/0x130 [cfg80211]
> ? ieee80211_if_remove+0xa3/0xe0 [mac80211]
> ? ieee80211_del_iface+0xe/0x20 [mac80211]
> ? rdev_del_virtual_intf+0x2b/0xc0 [cfg80211]
> ? genl_rcv_msg+0x451/0x570
> ? genl_unbind+0xb0/0xb0
> ? netlink_rcv_skb+0xfb/0x130
> ? genl_rcv+0x24/0x40
> ? netlink_unicast+0x1bf/0x2e0
> ? netlink_sendmsg+0x385/0x410
> ? ____sys_sendmsg+0x26b/0x290
> ? __sys_sendmsg+0x128/0x180
> ? selinux_socket_setsockopt+0xc3/0xd0
> ? __cgroup_bpf_run_filter_setsockopt+0x99/0x290
> ? netlink_setsockopt+0x38/0x4d0
> ? __sys_setsockopt+0x11b/0x1b0
> ? do_syscall_64+0x5e/0xd0
> ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
>which explains why systemd waits for that one too.
>
>So something seems to have never released the rtnl lock.
>
>In fact, I suspect it's exactly that wpa_supplicant itself that
>deadlocks on it and holds the rntl lock while it does that
>"flush_work()". Which in turn waits for things to go away, but they'll
>never go away because they need the rtnl lock. That wpa_supplicant is
>holding.
>
>If I were a betting man, I'd suspect it's due to commit 6cd536fe62ef
>("cfg80211: change internal management frame registration API"), which
>seems to move that
>
> flush_work(&wdev->mgmt_registrations_update_wk);
>
>into __cfg80211_unregister_wdev(). But honestly, that's just a guess.
>
>I'd bisect this and verify things, but I'm really hoping I don't have
>to.
>
>I still have a number of pull requests for the merge window, so
>instead I'm sending this email out with my current guesses, and I hope
>someody will say "Yeah, you're right, the fix is already pending", or
>"No Linus, you're barking up completely the wrong tree, but I think I
>know what the problem is".
>
>Btw, I'm not a networking person, but I have to say, I've seen rtnl
>lock problems enough over time even as an outsider to have grown to
>really hate that thing. Am I wrong? It really seems to get involved
>much too much, and held in really awkward places.
>
>Am I wrong?
>
> Linus
--
Sent from my phone.
^ permalink raw reply
* iwlwifi-backports, ax200 FW crashes, station does not notice, no traffic.
From: Ben Greear @ 2020-06-05 23:05 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
It was suggested I try the iwlwifi-backports package since upstream ax200 is so broken.
I am using it on kernel 5.7.0+, iwlwifi-backports branch release/core52 (patched to compile against 5.7.0),
and with the version 55 firmware from linux-firmware repo. (Older firmware crashes too and in that case, radios
are often not recovered and so station cannot even be manually restarted.)
This does indeed work much better, but still some issues.
My test case is udp + tcp upload + download, full speed, on each of two
ax200 radios in this system.
AP is an Asus AX AP, configured for Open auth.
After a few minutes, the firmware crashes. The main issue in this case is that
the station does not appear to notice the FW crashes, does not reconnect, thinks
it is connected, but cannot pass any traffic. If I manually restart the station,
then it will start passing traffic again.
It is expected that the station is not disconnected when hardware fails?
[ 518.915963] wlan2: authenticate with 0c:9d:92:02:42:e4
[ 518.919968] wlan2: send auth to 0c:9d:92:02:42:e4 (try 1/3)
[ 519.049083] wlan2: send auth to 0c:9d:92:02:42:e4 (try 2/3)
[ 519.073761] wlan2: authenticated
[ 519.075073] wlan2: associate with 0c:9d:92:02:42:e4 (try 1/3)
[ 519.076510] wlan2: RX AssocResp from 0c:9d:92:02:42:e4 (capab=0x1001 status=0 aid=1)
[ 519.077509] iwlwifi 0000:12:00.0: Got NSS = 4 - trimming to 2
[ 519.079318] wlan2: associated
[ 519.080319] IPv6: ADDRCONF(NETDEV_CHANGE): wlan2: link becomes ready
[ 519.085553] wlan3: authenticate with 0c:9d:92:02:42:e4
[ 519.089146] wlan3: send auth to 0c:9d:92:02:42:e4 (try 1/3)
[ 519.125239] wlan2: Limiting TX power to 24 (24 - 0) dBm as advertised by 0c:9d:92:02:42:e4
[ 519.217193] wlan3: send auth to 0c:9d:92:02:42:e4 (try 2/3)
[ 519.232491] wlan3: authenticated
[ 519.233068] wlan3: associate with 0c:9d:92:02:42:e4 (try 1/3)
[ 519.238227] wlan3: RX AssocResp from 0c:9d:92:02:42:e4 (capab=0x1001 status=0 aid=2)
[ 519.239271] iwlwifi 0000:14:00.0: Got NSS = 4 - trimming to 2
[ 519.241150] wlan3: associated
[ 519.241910] IPv6: ADDRCONF(NETDEV_CHANGE): wlan3: link becomes ready
[ 519.330194] wlan3: Limiting TX power to 24 (24 - 0) dBm as advertised by 0c:9d:92:02:42:e4
[ 522.455935] ixgbe 0000:01:00.0: removed PHC on eth2
[ 522.852258] pps pps2: new PPS source ptp2
[ 522.852306] ixgbe 0000:01:00.0: registered PHC device on eth2
[ 522.974821] 8021q: adding VLAN 0 to HW filter on device eth2
[ 527.077758] ixgbe 0000:01:00.0 eth2: NIC Link is Up 1 Gbps, Flow Control: RX/TX
[ 527.078021] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[ 601.584303] kauditd_printk_skb: 8 callbacks suppressed
[ 601.584305] audit: type=1130 audit(1591396447.963:220): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 601.584309] audit: type=1131 audit(1591396447.963:221): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 702.600990] iwlwifi 0000:14:00.0: reached 10 old SN frames from 0c:9d:92:02:42:e4 on queue 3, stopping BA session on TID 0
[ 824.804107] iwlwifi 0000:12:00.0: Microcode SW error detected. Restarting 0x0.
[ 824.810427] iwlwifi 0000:12:00.0: Start IWL Error Log Dump:
[ 824.814871] iwlwifi 0000:12:00.0: Status: 0x00000040, count: 6
[ 824.819533] iwlwifi 0000:12:00.0: Loaded firmware version: 55.d9698065.0 cc-a0-55.ucode
[ 824.826389] iwlwifi 0000:12:00.0: 0x00000942 | ADVANCED_SYSASSERT
[ 824.832260] iwlwifi 0000:12:00.0: 0x00A0A210 | trm_hw_status0
[ 824.836972] iwlwifi 0000:12:00.0: 0x00000000 | trm_hw_status1
[ 824.841735] iwlwifi 0000:12:00.0: 0x004FA34A | branchlink2
[ 824.846165] iwlwifi 0000:12:00.0: 0x00000F86 | interruptlink1
[ 824.850914] iwlwifi 0000:12:00.0: 0x00000F86 | interruptlink2
[ 824.855669] iwlwifi 0000:12:00.0: 0xFFFD0020 | data1
[ 824.859540] iwlwifi 0000:12:00.0: 0x6A010201 | data2
[ 824.863414] iwlwifi 0000:12:00.0: 0x040C0606 | data3
[ 824.867265] iwlwifi 0000:12:00.0: 0xEA814B27 | beacon time
[ 824.871644] iwlwifi 0000:12:00.0: 0xEC2B9671 | tsf low
[ 824.875626] iwlwifi 0000:12:00.0: 0x0000001A | tsf hi
[ 824.879509] iwlwifi 0000:12:00.0: 0x00000000 | time gp1
[ 824.883617] iwlwifi 0000:12:00.0: 0x126CA954 | time gp2
[ 824.887714] iwlwifi 0000:12:00.0: 0x00000001 | uCode revision type
[ 824.892781] iwlwifi 0000:12:00.0: 0x00000037 | uCode version major
[ 824.897780] iwlwifi 0000:12:00.0: 0xD9698065 | uCode version minor
[ 824.902850] iwlwifi 0000:12:00.0: 0x00000340 | hw version
[ 824.907089] iwlwifi 0000:12:00.0: 0x18C89000 | board version
[ 824.911615] iwlwifi 0000:12:00.0: 0x8010FD25 | hcmd
[ 824.915356] iwlwifi 0000:12:00.0: 0xE6821010 | isr0
[ 824.918992] iwlwifi 0000:12:00.0: 0x00440000 | isr1
[ 824.922749] iwlwifi 0000:12:00.0: 0x08F80102 | isr2
[ 824.926487] iwlwifi 0000:12:00.0: 0x04C33B0D | isr3
[ 824.930305] iwlwifi 0000:12:00.0: 0x00000000 | isr4
[ 824.934057] iwlwifi 0000:12:00.0: 0x03AF001C | last cmd Id
[ 824.938522] iwlwifi 0000:12:00.0: 0x004EB008 | wait_event
[ 824.942847] iwlwifi 0000:12:00.0: 0x00000288 | l2p_control
[ 824.947218] iwlwifi 0000:12:00.0: 0x00010014 | l2p_duration
[ 824.951633] iwlwifi 0000:12:00.0: 0x00000000 | l2p_mhvalid
[ 824.955958] iwlwifi 0000:12:00.0: 0x000000EF | l2p_addr_match
[ 824.960590] iwlwifi 0000:12:00.0: 0x00000009 | lmpm_pmg_sel
[ 824.965042] iwlwifi 0000:12:00.0: 0x00000000 | timestamp
[ 824.969192] iwlwifi 0000:12:00.0: 0x00005848 | flow_handler
[ 824.973646] iwlwifi 0000:12:00.0: Start IWL Error Log Dump:
[ 824.978092] iwlwifi 0000:12:00.0: Status: 0x00000040, count: 7
[ 824.982846] iwlwifi 0000:12:00.0: 0x20000070 | NMI_INTERRUPT_LMAC_FATAL
[ 824.988359] iwlwifi 0000:12:00.0: 0x00000000 | umac branchlink1
[ 824.993139] iwlwifi 0000:12:00.0: 0x80465826 | umac branchlink2
[ 824.997952] iwlwifi 0000:12:00.0: 0x8048074C | umac interruptlink1
[ 825.002982] iwlwifi 0000:12:00.0: 0x8048074C | umac interruptlink2
[ 825.007981] iwlwifi 0000:12:00.0: 0x00000400 | umac data1
[ 825.012165] iwlwifi 0000:12:00.0: 0x8048074C | umac data2
[ 825.016376] iwlwifi 0000:12:00.0: 0x00000000 | umac data3
[ 825.020584] iwlwifi 0000:12:00.0: 0x00000037 | umac major
[ 825.024791] iwlwifi 0000:12:00.0: 0xD9698065 | umac minor
[ 825.029058] iwlwifi 0000:12:00.0: 0x126CA96B | frame pointer
[ 825.033563] iwlwifi 0000:12:00.0: 0xC0886270 | stack pointer
[ 825.038090] iwlwifi 0000:12:00.0: 0x0095010C | last host cmd
[ 825.042540] iwlwifi 0000:12:00.0: 0x00000000 | isr status reg
[ 825.047141] iwlwifi 0000:12:00.0: Fseq Registers:
[ 825.050613] iwlwifi 0000:12:00.0: 0x60000000 | FSEQ_ERROR_CODE
[ 825.055229] iwlwifi 0000:12:00.0: 0x80290021 | FSEQ_TOP_INIT_VERSION
[ 825.060412] iwlwifi 0000:12:00.0: 0x00050008 | FSEQ_CNVIO_INIT_VERSION
[ 825.065807] iwlwifi 0000:12:00.0: 0x0000A503 | FSEQ_OTP_VERSION
[ 825.070536] iwlwifi 0000:12:00.0: 0x80000003 | FSEQ_TOP_CONTENT_VERSION
[ 825.076022] iwlwifi 0000:12:00.0: 0x4552414E | FSEQ_ALIVE_TOKEN
[ 825.080756] iwlwifi 0000:12:00.0: 0x00100530 | FSEQ_CNVI_ID
[ 825.085089] iwlwifi 0000:12:00.0: 0x00000532 | FSEQ_CNVR_ID
[ 825.089510] iwlwifi 0000:12:00.0: 0x00100530 | CNVI_AUX_MISC_CHIP
[ 825.094474] iwlwifi 0000:12:00.0: 0x00000532 | CNVR_AUX_MISC_CHIP
[ 825.099406] iwlwifi 0000:12:00.0: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[ 825.106099] iwlwifi 0000:12:00.0: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[ 825.113704] iwlwifi 0000:12:00.0: WRT: Collecting data: ini trigger 4 fired.
[ 825.113710] ieee80211 wiphy2: Hardware restart was requested
[ 826.328717] iwlwifi 0000:12:00.0: Got NSS = 4 - trimming to 2
[ 826.328956] iwlwifi 0000:12:00.0: Got NSS = 4 - trimming to 2
[ 901.276085] audit: type=1130 audit(1591396747.658:222): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 901.276110] audit: type=1131 audit(1591396747.658:223): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-tmpfiles-clean comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 961.252627] audit: type=1130 audit(1591396807.635:224): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 961.252637] audit: type=1131 audit(1591396807.635:225): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 1561.307302] audit: type=1130 audit(1591397407.699:226): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 1561.307306] audit: type=1131 audit(1591397407.699:227): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[root@ct523c-0b29 backport-iwlwifi]# iw wlan2 info
Interface wlan2
ifindex 18
wdev 0x800000001
addr 5c:80:b6:5a:b4:6e
ssid asus11ax
type managed
wiphy 8
channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
txpower 22.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 0 0 0 0 0 0 0
[root@ct523c-0b29 backport-iwlwifi]# iw wlan2 station dump
Station 0c:9d:92:02:42:e4 (on wlan2)
inactive time: 350 ms
rx bytes: 9045670754
rx packets: 5930616
tx bytes: 1255064539
tx packets: 1090264
tx retries: 199
tx failed: 0
beacon loss: 0
beacon rx: 10455
rx drop misc: 3
signal: -36 [-40, -36] dBm
signal avg: 38 dBm
beacon signal avg: -36 dBm
tx bitrate: 245.0 MBit/s 80MHz
rx bitrate: 6.0 MBit/s
rx duration: 0 us
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 3
beacon interval:100
short slot time:yes
connected time: 1398 seconds
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Hang on wireless removal..
From: Linus Torvalds @ 2020-06-05 22:41 UTC (permalink / raw)
To: Johannes Berg, David S. Miller, Jakub Kicinski
Cc: linux-wireless, Netdev, Linux Kernel Mailing List
So I think there's something wrong with wireless networking, and
(likely) in particular turning off wireless. And I think the problem
came in this merge window, because now my machine hangs on shutdown.
My new desktop is otherwise working fine, but it has some unnecessary
wireless capability on the motherboard, in the form of a Intel Wi-Fi 6
AX200 module that I don't use (since I end up using wired gig ethernet
instead).
And while debugging the shutdown hang (symptom: systemd waits forever
for NetworkManager and WPA supplicant), I turned off the WiFi.
And what do you know, things went all sideways.
They went sideways because everything that wants the rtnl lock seems
to just hang.
Example:
kworker/57:2 D 0 1592 2 0x80004080
Workqueue: events_power_efficient reg_check_chans_work [cfg80211]
Call Trace:
__schedule+0x30b/0x4b0
? schedule+0x77/0xa0
? schedule_preempt_disabled+0xa/0x10
? __mutex_lock+0x264/0x410
? psi_group_change+0x44/0x260
? reg_check_chans_work+0x1d/0x300 [cfg80211]
? __switch_to_asm+0x42/0x70
? process_one_work+0x1fa/0x3f0
? worker_thread+0x25d/0x480
? kthread+0x121/0x130
? process_one_work+0x3f0/0x3f0
? kthread_blkcg+0x30/0x30
? ret_from_fork+0x22/0x30
kworker/60:2 D 0 1926 2 0x80004000
Workqueue: ipv6_addrconf addrconf_verify_work
Call Trace:
__schedule+0x30b/0x4b0
? schedule+0x77/0xa0
? schedule_preempt_disabled+0xa/0x10
? __mutex_lock+0x264/0x410
? addrconf_verify_work+0xa/0x20
? process_one_work+0x1fa/0x3f0
? worker_thread+0x25d/0x480
? kthread+0x121/0x130
? process_one_work+0x3f0/0x3f0
? kthread_blkcg+0x30/0x30
? ret_from_fork+0x22/0x30
NetworkManager D 0 4329 1 0x00004000
Call Trace:
__schedule+0x30b/0x4b0
? schedule+0x77/0xa0
? schedule_preempt_disabled+0xa/0x10
? __mutex_lock+0x264/0x410
? __netlink_dump_start+0xa7/0x300
? rtnl_dellink+0x3c0/0x3c0
? rtnetlink_rcv_msg+0x375/0x3d0
? poll_freewait+0x35/0xa0
? do_sys_poll+0x58f/0x5f0
? rtnl_dellink+0x3c0/0x3c0
? __ia32_compat_sys_ppoll_time64+0x120/0x120
? ip_output+0x6a/0xd0
? ip_mc_finish_output+0x120/0x120
? avc_has_perm+0x34/0xa0
? rtnetlink_bind+0x30/0x30
? netlink_rcv_skb+0xfb/0x130
? netlink_unicast+0x1bf/0x2e0
? netlink_sendmsg+0x385/0x410
? __sys_sendto+0x21f/0x230
? move_addr_to_user+0x97/0xc0
? alloc_file_pseudo+0x9b/0xd0
? sock_alloc_file+0xc4/0x100
? __x64_sys_sendto+0x22/0x30
? do_syscall_64+0x5e/0xd0
? entry_SYSCALL_64_after_hwframe+0x44/0xa9
and perhaps most interestingly, wpa_supplicant is waiting for some of
those workqueues that are waiting for the lock:
wpa_supplicant D 0 2162 1 0x00004000
Call Trace:
__schedule+0x30b/0x4b0
? schedule+0x77/0xa0
? schedule_timeout+0x22/0x150
? ttwu_queue+0xf4/0x120
? wait_for_common+0xac/0x110
? __flush_work+0x200/0x230
? put_pwq+0x70/0x70
? __cfg80211_unregister_wdev+0x95/0x130 [cfg80211]
? ieee80211_if_remove+0xa3/0xe0 [mac80211]
? ieee80211_del_iface+0xe/0x20 [mac80211]
? rdev_del_virtual_intf+0x2b/0xc0 [cfg80211]
? genl_rcv_msg+0x451/0x570
? genl_unbind+0xb0/0xb0
? netlink_rcv_skb+0xfb/0x130
? genl_rcv+0x24/0x40
? netlink_unicast+0x1bf/0x2e0
? netlink_sendmsg+0x385/0x410
? ____sys_sendmsg+0x26b/0x290
? __sys_sendmsg+0x128/0x180
? selinux_socket_setsockopt+0xc3/0xd0
? __cgroup_bpf_run_filter_setsockopt+0x99/0x290
? netlink_setsockopt+0x38/0x4d0
? __sys_setsockopt+0x11b/0x1b0
? do_syscall_64+0x5e/0xd0
? entry_SYSCALL_64_after_hwframe+0x44/0xa9
which explains why systemd waits for that one too.
So something seems to have never released the rtnl lock.
In fact, I suspect it's exactly that wpa_supplicant itself that
deadlocks on it and holds the rntl lock while it does that
"flush_work()". Which in turn waits for things to go away, but they'll
never go away because they need the rtnl lock. That wpa_supplicant is
holding.
If I were a betting man, I'd suspect it's due to commit 6cd536fe62ef
("cfg80211: change internal management frame registration API"), which
seems to move that
flush_work(&wdev->mgmt_registrations_update_wk);
into __cfg80211_unregister_wdev(). But honestly, that's just a guess.
I'd bisect this and verify things, but I'm really hoping I don't have to.
I still have a number of pull requests for the merge window, so
instead I'm sending this email out with my current guesses, and I hope
someody will say "Yeah, you're right, the fix is already pending", or
"No Linus, you're barking up completely the wrong tree, but I think I
know what the problem is".
Btw, I'm not a networking person, but I have to say, I've seen rtnl
lock problems enough over time even as an outsider to have grown to
really hate that thing. Am I wrong? It really seems to get involved
much too much, and held in really awkward places.
Am I wrong?
Linus
^ permalink raw reply
* [mac80211:master] BUILD SUCCESS 523f3ec030aa5bf4818ec8dee35b2646abf367fa
From: kernel test robot @ 2020-06-05 20:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git master
branch HEAD: 523f3ec030aa5bf4818ec8dee35b2646abf367fa mac80211: initialize return flags in HE 6 GHz operation parsing
elapsed time: 502m
configs tested: 127
configs skipped: 9
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
m68k m5249evb_defconfig
sh titan_defconfig
xtensa defconfig
powerpc cell_defconfig
mips rt305x_defconfig
sh rsk7264_defconfig
arc vdk_hs38_smp_defconfig
mips maltaup_xpa_defconfig
arm badge4_defconfig
m68k m5272c3_defconfig
m68k m5475evb_defconfig
nios2 10m50_defconfig
mips malta_kvm_defconfig
m68k mvme147_defconfig
arm imote2_defconfig
powerpc allyesconfig
powerpc mpc5200_defconfig
arc vdk_hs38_defconfig
sh se7724_defconfig
powerpc mpc512x_defconfig
sh sh7785lcr_32bit_defconfig
mips ip28_defconfig
sparc64 defconfig
arm s5pv210_defconfig
mips ip32_defconfig
sh polaris_defconfig
mips jmr3927_defconfig
arm spitz_defconfig
m68k apollo_defconfig
arm magician_defconfig
arm spear3xx_defconfig
mips tb0287_defconfig
ia64 generic_defconfig
arc nps_defconfig
s390 alldefconfig
h8300 defconfig
i386 allnoconfig
arm shannon_defconfig
mips malta_kvm_guest_defconfig
powerpc mgcoge_defconfig
mips bmips_stb_defconfig
arm alldefconfig
powerpc pasemi_defconfig
s390 allnoconfig
arm lpc32xx_defconfig
riscv allnoconfig
mips ath79_defconfig
alpha alldefconfig
parisc allnoconfig
arm mvebu_v5_defconfig
mips qi_lb60_defconfig
arm h3600_defconfig
sh se7712_defconfig
mips pistachio_defconfig
powerpc pmac32_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
c6x allyesconfig
c6x allnoconfig
openrisc defconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
riscv allyesconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] wlcore: mesh: handle failure case of pm_runtime_get_sync
From: Tony Lindgren @ 2020-06-05 16:49 UTC (permalink / raw)
To: Navid Emamdoost
Cc: Kalle Valo, David S. Miller, Johannes Berg, Thomas Gleixner,
Greg Kroah-Hartman, Hari Nagalla, Jason A. Donenfeld,
Emmanuel Grumbach, Maital Hahn, Fuqian Huang, linux-wireless,
netdev, linux-kernel, emamd001, wu000273, kjlu, smccaman
In-Reply-To: <20200605032733.49846-1-navid.emamdoost@gmail.com>
* Navid Emamdoost <navid.emamdoost@gmail.com> [200605 03:28]:
> Calling pm_runtime_get_sync increments the counter even in case of
> failure, causing incorrect ref count. Call pm_runtime_put if
> pm_runtime_get_sync fails.
Looks like we have a similar patch already in Linux next,
care to check?
Regards,
Tony
^ permalink raw reply
* [PATCH 9/9] net: fix wiki website url mac80211 and wireless files
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
In the files:
- net/mac80211/rx.c
- net/wireless/Kconfig
the wiki url is still the old "wireless.kernel.org"
instead of the new "wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
net/mac80211/rx.c | 2 +-
net/wireless/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 21854a61a2b7..a88ab6fb16f2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -4694,7 +4694,7 @@ void ieee80211_rx_napi(struct ieee80211_hw *hw, struct ieee80211_sta *pubsta,
* rate_idx is MCS index, which can be [0-76]
* as documented on:
*
- * http://wireless.kernel.org/en/developers/Documentation/ieee80211/802.11n
+ * https://wireless.wiki.kernel.org/en/developers/Documentation/ieee80211/802.11n
*
* Anything else would be some sort of driver or
* hardware error. The driver should catch hardware
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 813e93644ae7..d69558487041 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -31,7 +31,7 @@ config CFG80211
For more information refer to documentation on the wireless wiki:
- http://wireless.kernel.org/en/developers/Documentation/cfg80211
+ https://wireless.wiki.kernel.org/en/developers/Documentation/cfg80211
When built as a module it will be called cfg80211.
--
2.17.1
^ permalink raw reply related
* [PATCH 8/9] include: fix wiki website url in netlink interface header
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
The wiki url is still the old "wireless.kernel.org"
instead of the new "wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
include/uapi/linux/nl80211.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index dad8c8f8581f..4e6339ab1fce 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -794,7 +794,7 @@
* various triggers. These triggers can be configured through this
* command with the %NL80211_ATTR_WOWLAN_TRIGGERS attribute. For
* more background information, see
- * http://wireless.kernel.org/en/users/Documentation/WoWLAN.
+ * https://wireless.wiki.kernel.org/en/users/Documentation/WoWLAN.
* The @NL80211_CMD_SET_WOWLAN command can also be used as a notification
* from the driver reporting the wakeup reason. In this case, the
* @NL80211_ATTR_WOWLAN_TRIGGERS attribute will contain the reason
--
2.17.1
^ permalink raw reply related
* [PATCH 7/9] net: wireless: intersil: fix wiki website url
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
In some Intesil files, the wiki url is still the old
"wireless.kernel.org" instead of the new
"wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
drivers/net/wireless/intersil/Kconfig | 2 +-
drivers/net/wireless/intersil/p54/Kconfig | 6 +++---
drivers/net/wireless/intersil/p54/fwio.c | 5 +++--
drivers/net/wireless/intersil/p54/p54usb.c | 2 +-
drivers/net/wireless/intersil/prism54/islpci_hotplug.c | 3 ++-
5 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/intersil/Kconfig b/drivers/net/wireless/intersil/Kconfig
index 4e968912e27c..527604c13687 100644
--- a/drivers/net/wireless/intersil/Kconfig
+++ b/drivers/net/wireless/intersil/Kconfig
@@ -30,7 +30,7 @@ config PRISM54
For more information refer to the p54 wiki:
- http://wireless.kernel.org/en/users/Drivers/p54
+ https://wireless.wiki.kernel.org/en/users/Drivers/p54
Note: You need a motherboard with DMA support to use any of these cards
diff --git a/drivers/net/wireless/intersil/p54/Kconfig b/drivers/net/wireless/intersil/p54/Kconfig
index 26cd80732afa..67651164190a 100644
--- a/drivers/net/wireless/intersil/p54/Kconfig
+++ b/drivers/net/wireless/intersil/p54/Kconfig
@@ -10,7 +10,7 @@ config P54_COMMON
also need to be enabled in order to support any devices.
These devices require softmac firmware which can be found at
- <http://wireless.kernel.org/en/users/Drivers/p54>
+ <https://wireless.wiki.kernel.org/en/users/Drivers/p54>
If you choose to build a module, it'll be called p54common.
@@ -22,7 +22,7 @@ config P54_USB
This driver is for USB isl38xx based wireless cards.
These devices require softmac firmware which can be found at
- <http://wireless.kernel.org/en/users/Drivers/p54>
+ <https://wireless.wiki.kernel.org/en/users/Drivers/p54>
If you choose to build a module, it'll be called p54usb.
@@ -36,7 +36,7 @@ config P54_PCI
supported by the fullmac driver/firmware.
This driver requires softmac firmware which can be found at
- <http://wireless.kernel.org/en/users/Drivers/p54>
+ <https://wireless.wiki.kernel.org/en/users/Drivers/p54>
If you choose to build a module, it'll be called p54pci.
diff --git a/drivers/net/wireless/intersil/p54/fwio.c b/drivers/net/wireless/intersil/p54/fwio.c
index a5afcc865196..7f973bed792f 100644
--- a/drivers/net/wireless/intersil/p54/fwio.c
+++ b/drivers/net/wireless/intersil/p54/fwio.c
@@ -132,8 +132,9 @@ int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
if (priv->fw_var < 0x500)
wiphy_info(priv->hw->wiphy,
"you are using an obsolete firmware. "
- "visit http://wireless.kernel.org/en/users/Drivers/p54 "
- "and grab one for \"kernel >= 2.6.28\"!\n");
+ "visit https://wireless.wiki.kernel.org/en/users/"
+ "Drivers/p54 and grab one "
+ "for \"kernel >= 2.6.28\"!\n");
if (priv->fw_var >= 0x300) {
/* Firmware supports QoS, use it! */
diff --git a/drivers/net/wireless/intersil/p54/p54usb.c b/drivers/net/wireless/intersil/p54/p54usb.c
index ff0e30c0c14c..f09d95c5d7d4 100644
--- a/drivers/net/wireless/intersil/p54/p54usb.c
+++ b/drivers/net/wireless/intersil/p54/p54usb.c
@@ -36,7 +36,7 @@ static struct usb_driver p54u_driver;
* Note:
*
* Always update our wiki's device list (located at:
- * http://wireless.kernel.org/en/users/Drivers/p54/devices ),
+ * https://wireless.wiki.kernel.org/en/users/Drivers/p54/devices ),
* whenever you add a new device.
*/
diff --git a/drivers/net/wireless/intersil/prism54/islpci_hotplug.c b/drivers/net/wireless/intersil/prism54/islpci_hotplug.c
index 20291c0d962d..0e42242a4b68 100644
--- a/drivers/net/wireless/intersil/prism54/islpci_hotplug.c
+++ b/drivers/net/wireless/intersil/prism54/islpci_hotplug.c
@@ -26,7 +26,8 @@ module_param(init_pcitm, int, 0);
/* In this order: vendor, device, subvendor, subdevice, class, class_mask,
* driver_data
* If you have an update for this please contact prism54-devel@prism54.org
- * The latest list can be found at http://wireless.kernel.org/en/users/Drivers/p54 */
+ * The latest list can be found at:
+ * https://wireless.wiki.kernel.org/en/users/Drivers/p54
+ */
static const struct pci_device_id prism54_id_tbl[] = {
/* Intersil PRISM Duette/Prism GT Wireless LAN adapter */
{
--
2.17.1
^ permalink raw reply related
* [PATCH 6/9] net: wireless: intel: fix wiki website url
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
In some Intel files, the wiki url is still the old
"wireless.kernel.org" instead of the new
"wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
drivers/net/wireless/intel/iwlwifi/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/4965-mac.c b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
index da6d4202611c..ad9d7e702a29 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965-mac.c
@@ -1415,7 +1415,7 @@ il4965_hdl_c_stats(struct il_priv *il, struct il_rx_buf *rxb)
/*
* mac80211 queues, ACs, hardware queues, FIFOs.
*
- * Cf. http://wireless.kernel.org/en/developers/Documentation/mac80211/queues
+ * Cf. https://wireless.wiki.kernel.org/en/developers/Documentation/mac80211/queues
*
* Mac80211 uses the following numbers, which we get as from it
* by way of skb_get_queue_mapping(skb):
diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig b/drivers/net/wireless/intel/iwlwifi/Kconfig
index 091d621ad25f..dc69cdb84d53 100644
--- a/drivers/net/wireless/intel/iwlwifi/Kconfig
+++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
@@ -31,7 +31,7 @@ config IWLWIFI
In order to use this driver, you will need a firmware
image for it. You can obtain the microcode from:
- <http://wireless.kernel.org/en/users/Drivers/iwlwifi>.
+ <https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi>.
The firmware is typically installed in /lib/firmware. You can
look in the hotplug script /etc/hotplug/firmware.agent to
--
2.17.1
^ permalink raw reply related
* [PATCH 5/9] net: wireless: broadcom: fix wiki website url
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
In some b43 files, the wiki url is still the old
"wireless.kernel.org" instead of the new
"wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
drivers/net/wireless/broadcom/b43/main.c | 2 +-
drivers/net/wireless/broadcom/b43legacy/main.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireless/broadcom/b43/main.c
index 3ad94dad2d89..0c2ea12fca19 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -2164,7 +2164,7 @@ static void b43_print_fw_helptext(struct b43_wl *wl, bool error)
{
const char text[] =
"You must go to " \
- "http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware " \
+ "https://wireless.wiki.kernel.org/en/users/Drivers/b43#devicefirmware " \
"and download the correct firmware for this driver version. " \
"Please carefully read all instructions on this website.\n";
diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c
index 5208a39fd6f7..7bb6681fa882 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -1477,8 +1477,8 @@ static void b43legacy_release_firmware(struct b43legacy_wldev *dev)
static void b43legacy_print_fw_helptext(struct b43legacy_wl *wl)
{
- b43legacyerr(wl, "You must go to http://wireless.kernel.org/en/users/"
- "Drivers/b43#devicefirmware "
+ b43legacyerr(wl, "You must go to https://wireless.wiki.kernel.org/en/"
+ "users/Drivers/b43#devicefirmware "
"and download the correct firmware (version 3).\n");
}
--
2.17.1
^ permalink raw reply related
* [PATCH 4/9] net: wireless: atmel: fix wiki website url
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
In at76c50x-usb.c the wiki url is still the old
"wireless.kernel.org" instead of the new
"wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c b/drivers/net/wireless/atmel/at76c50x-usb.c
index 3b2680772f03..a63b5c2f1e17 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -17,7 +17,7 @@
*
* TODO list is at the wiki:
*
- * http://wireless.kernel.org/en/users/Drivers/at76c50x-usb#TODO
+ * https://wireless.wiki.kernel.org/en/users/Drivers/at76c50x-usb#TODO
*/
#include <linux/init.h>
--
2.17.1
^ permalink raw reply related
* [PATCH 3/9] net: wireless: ath: fix wiki website url
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
In some ath files, the wiki url is still the old
"wireless.kernel.org" instead of the new
"wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
drivers/net/wireless/ath/Kconfig | 4 ++--
drivers/net/wireless/ath/ath9k/Kconfig | 5 +++--
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/carl9170/Kconfig | 2 +-
drivers/net/wireless/ath/carl9170/usb.c | 2 +-
drivers/net/wireless/ath/wil6210/Kconfig | 2 +-
6 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/Kconfig b/drivers/net/wireless/ath/Kconfig
index b10972b6cba4..0138d415f4e1 100644
--- a/drivers/net/wireless/ath/Kconfig
+++ b/drivers/net/wireless/ath/Kconfig
@@ -15,11 +15,11 @@ config WLAN_VENDOR_ATH
For more information and documentation on this module you can visit:
- http://wireless.kernel.org/en/users/Drivers/ath
+ https://wireless.wiki.kernel.org/en/users/Drivers/ath
For information on all Atheros wireless drivers visit:
- http://wireless.kernel.org/en/users/Drivers/Atheros
+ https://wireless.wiki.kernel.org/en/users/Drivers/Atheros
if WLAN_VENDOR_ATH
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index 78620c6b64a2..28b46ca9ee3b 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -34,7 +34,7 @@ config ATH9K
APs that come with these cards refer to ath9k wiki
products page:
- http://wireless.kernel.org/en/users/Drivers/ath9k/products
+ https://wireless.wiki.kernel.org/en/users/Drivers/ath9k/products
If you choose to build a module, it'll be called ath9k.
@@ -185,7 +185,8 @@ config ATH9K_HTC
Support for Atheros HTC based cards.
Chipsets supported: AR9271
- For more information: http://wireless.kernel.org/en/users/Drivers/ath9k_htc
+ For more information:
+ https://wireless.wiki.kernel.org/en/users/Drivers/ath9k_htc
The built module will be ath9k_htc.
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 052deffb4c9d..8c97db73e34c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2410,7 +2410,7 @@ static u8 fixup_chainmask(u8 chip_chainmask, u8 eeprom_chainmask)
* of tests. The testing requirements are going to be documented. Desired
* test requirements are documented at:
*
- * http://wireless.kernel.org/en/users/Drivers/ath9k/dfs
+ * https://wireless.wiki.kernel.org/en/users/Drivers/ath9k/dfs
*
* Once a new chipset gets properly tested an individual commit can be used
* to document the testing for DFS for that chipset.
diff --git a/drivers/net/wireless/ath/carl9170/Kconfig b/drivers/net/wireless/ath/carl9170/Kconfig
index b1bce7aad399..b2d760873992 100644
--- a/drivers/net/wireless/ath/carl9170/Kconfig
+++ b/drivers/net/wireless/ath/carl9170/Kconfig
@@ -10,7 +10,7 @@ config CARL9170
It needs a special firmware (carl9170-1.fw), which can be downloaded
from our wiki here:
- <http://wireless.kernel.org/en/users/Drivers/carl9170>
+ <https://wireless.wiki.kernel.org/en/users/Drivers/carl9170>
If you choose to build a module, it'll be called carl9170.
diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c
index 486957a04bd1..ead79335823a 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -61,7 +61,7 @@ MODULE_ALIAS("arusb_lnx");
* Note:
*
* Always update our wiki's device list (located at:
- * http://wireless.kernel.org/en/users/Drivers/ar9170/devices ),
+ * https://wireless.wiki.kernel.org/en/users/Drivers/ar9170/devices ),
* whenever you add a new device.
*/
static const struct usb_device_id carl9170_usb_ids[] = {
diff --git a/drivers/net/wireless/ath/wil6210/Kconfig b/drivers/net/wireless/ath/wil6210/Kconfig
index 0d1a8dab30ed..8c9dd673b9e7 100644
--- a/drivers/net/wireless/ath/wil6210/Kconfig
+++ b/drivers/net/wireless/ath/wil6210/Kconfig
@@ -10,7 +10,7 @@ config WIL6210
wil6210 chip by Wilocity. It supports operation on the
60 GHz band, covered by the IEEE802.11ad standard.
- http://wireless.kernel.org/en/users/Drivers/wil6210
+ https://wireless.wiki.kernel.org/en/users/Drivers/wil6210
If you choose to build it as a module, it will be called
wil6210
--
2.17.1
^ permalink raw reply related
* [PATCH 2/9] net: wireless: fix wiki website url in main Kconfig
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
The wiki url is still the old "wireless.kernel.org"
instead of the new "wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
drivers/net/wireless/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 15b0ad171f4c..5db60612d734 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -14,7 +14,7 @@ menuconfig WLAN
device drivers. For a complete list of drivers and documentation
on them refer to the wireless wiki:
- http://wireless.kernel.org/en/users/Drivers
+ https://wireless.wiki.kernel.org/en/users/Drivers
if WLAN
--
2.17.1
^ permalink raw reply related
* [PATCH 1/9] doc: networking: wireless: fix wiki website url
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In-Reply-To: <20200605154112.16277-1-f.suligoi@asem.it>
In the files:
- regulatory.rst
- mac80211-injection.rst
the wiki url is still the old "wireless.kernel.org"
instead of the new "wireless.wiki.kernel.org"
Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
---
Documentation/networking/mac80211-injection.rst | 2 +-
Documentation/networking/regulatory.rst | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/mac80211-injection.rst b/Documentation/networking/mac80211-injection.rst
index be65f886ff1f..63ba6611fdff 100644
--- a/Documentation/networking/mac80211-injection.rst
+++ b/Documentation/networking/mac80211-injection.rst
@@ -101,6 +101,6 @@ interface), along the following lines:::
You can also find a link to a complete inject application here:
-http://wireless.kernel.org/en/users/Documentation/packetspammer
+https://wireless.wiki.kernel.org/en/users/Documentation/packetspammer
Andy Green <andy@warmcat.com>
diff --git a/Documentation/networking/regulatory.rst b/Documentation/networking/regulatory.rst
index 8701b91e81ee..16782a95b74a 100644
--- a/Documentation/networking/regulatory.rst
+++ b/Documentation/networking/regulatory.rst
@@ -9,7 +9,7 @@ regulatory infrastructure works.
More up to date information can be obtained at the project's web page:
-http://wireless.kernel.org/en/developers/Regulatory
+https://wireless.wiki.kernel.org/en/developers/Regulatory
Keeping regulatory domains in userspace
---------------------------------------
@@ -37,7 +37,7 @@ expected regulatory domains will be respected by the kernel.
A currently available userspace agent which can accomplish this
is CRDA - central regulatory domain agent. Its documented here:
-http://wireless.kernel.org/en/developers/Regulatory/CRDA
+https://wireless.wiki.kernel.org/en/developers/Regulatory/CRDA
Essentially the kernel will send a udev event when it knows
it needs a new regulatory domain. A udev rule can be put in place
@@ -58,7 +58,7 @@ Who asks for regulatory domains?
Users can use iw:
-http://wireless.kernel.org/en/users/Documentation/iw
+https://wireless.wiki.kernel.org/en/users/Documentation/iw
An example::
--
2.17.1
^ permalink raw reply related
* [PATCH 0/9] net: wireless: fix wireless wiki website url
From: Flavio Suligoi @ 2020-06-05 15:41 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Jakub Kicinski, Jonathan Corbet,
Kalle Valo, Christian Lamparter, Johan Hovold, Saurav Girepunje,
Larry Finger, Emmanuel Grumbach, Luca Coelho
Cc: linux-wireless, b43-dev, Intel Linux Wireless, netdev, linux-doc,
linux-kernel, Flavio Suligoi
In some files, related to the net wireless sub-system, the wireless wiki
URL is still the old "wireless.kernel.org" instead of the new
"wireless.wiki.kernel.org"
Flavio Suligoi (9):
doc: networking: wireless: fix wiki website url
net: wireless: fix wiki website url in main Kconfig
net: wireless: ath: fix wiki website url
net: wireless: atmel: fix wiki website url
net: wireless: broadcom: fix wiki website url
net: wireless: intel: fix wiki website url
net: wireless: intersil: fix wiki website url
include: fix wiki website url in netlink interface header
net: fix wiki website url mac80211 and wireless files
Documentation/networking/mac80211-injection.rst | 2 +-
Documentation/networking/regulatory.rst | 6 +++---
drivers/net/wireless/Kconfig | 2 +-
drivers/net/wireless/ath/Kconfig | 4 ++--
drivers/net/wireless/ath/ath9k/Kconfig | 5 +++--
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/carl9170/Kconfig | 2 +-
drivers/net/wireless/ath/carl9170/usb.c | 2 +-
drivers/net/wireless/ath/wil6210/Kconfig | 2 +-
drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
drivers/net/wireless/broadcom/b43/main.c | 2 +-
drivers/net/wireless/broadcom/b43legacy/main.c | 4 ++--
drivers/net/wireless/intel/iwlegacy/4965-mac.c | 2 +-
drivers/net/wireless/intel/iwlwifi/Kconfig | 2 +-
drivers/net/wireless/intersil/Kconfig | 2 +-
drivers/net/wireless/intersil/p54/Kconfig | 6 +++---
drivers/net/wireless/intersil/p54/fwio.c | 5 +++--
drivers/net/wireless/intersil/p54/p54usb.c | 2 +-
drivers/net/wireless/intersil/prism54/islpci_hotplug.c | 3 ++-
include/uapi/linux/nl80211.h | 2 +-
net/mac80211/rx.c | 2 +-
net/wireless/Kconfig | 2 +-
22 files changed, 33 insertions(+), 30 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH v2 2/5] rtw88: 8821c: add power tracking
From: Sebastian Andrzej Siewior @ 2020-06-05 14:30 UTC (permalink / raw)
To: yhchuang; +Cc: kvalo, linux-wireless, tehuang
In-Reply-To: <20200603094218.19942-3-yhchuang@realtek.com>
On 2020-06-03 17:42:15 [+0800], yhchuang@realtek.com wrote:
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
> index 904eb494ccad..aa2457046ad1 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
> @@ -61,6 +61,46 @@ static int rtw8821c_read_efuse(struct rtw_dev *rtwdev, u8 *log_map)
> return 0;
> }
>
> +static const u32 rtw8821c_txscale_tbl[] = {
> + 0x081, 0x088, 0x090, 0x099, 0x0a2, 0x0ac, 0x0b6, 0x0c0, 0x0cc, 0x0d8,
> + 0x0e5, 0x0f2, 0x101, 0x110, 0x120, 0x131, 0x143, 0x156, 0x16a, 0x180,
> + 0x197, 0x1af, 0x1c8, 0x1e3, 0x200, 0x21e, 0x23e, 0x261, 0x285, 0x2ab,
> + 0x2d3, 0x2fe, 0x32b, 0x35c, 0x38e, 0x3c4, 0x3fe
> +};
> +
> +static const u8 rtw8821c_get_swing_index(struct rtw_dev *rtwdev)
> +{
> + u8 i = 0;
> + u32 swing, table_value;
> +
> + swing = rtw_read32_mask(rtwdev, REG_TXSCALE_A, 0xffe00000);
> + for (i = 0; i < ARRAY_SIZE(rtw8821c_txscale_tbl); i++) {
> + table_value = rtw8821c_txscale_tbl[i];
> + if (swing == table_value)
> + break;
> + }
> +
> + return i;
> +}
This matches rtw8822b_get_swing_index() and rtw8822b_txscale_tbl. How
often are the lookups performed and how likely is it that the value is
not found?
With something like this:
static int rtw8821c_get_swing_index(unsigned int swing)
{
unsigned short val;
int start, end;
int candidate;
start = 0;
end = ARRAY_SIZE(rtw8821c_txscale_tbl);
while (start < end) {
candidate = start + (end - start) / 2;
val = rtw8821c_txscale_tbl[candidate];
if (swing == val)
return candidate;
if (swing < val)
end = candidate;
else
start = candidate + 1;
}
return -EINVAL;
}
you would end up with more less constant lookup time with ~6 lookups in worst
case. I guess it is not a hot path but still…
Can the table become u16?
…
> +const struct rtw_pwr_track_tbl rtw8821c_rtw_pwr_track_tbl = {
> + .pwrtrk_5gb_n[0] = rtw8821c_pwrtrk_5gb_n[0],
> + .pwrtrk_5gb_n[1] = rtw8821c_pwrtrk_5gb_n[1],
> + .pwrtrk_5gb_n[2] = rtw8821c_pwrtrk_5gb_n[2],
so the other driver use RTW_PWR_TRK_5G_1…3. Using constants here isn't
better because a line like
.pwrtrk_5gb_n[2] = rtw8821c_pwrtrk_5gb_n[22],
will not trigger a warning. This is just an observation.
Sebastian
^ permalink raw reply
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