Replace the bss_info_changed callback with vif_cfg_changed
and link_info_changed callbacks (for vif changes and link
changes).
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Start making some SMPS related code MLD-aware. This isn't
really done yet, but again cuts down our 'deflink' reliance.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Make the channel context code MLO aware, along with some
functions that it uses, so that the chan.c file is now
MLD-clean and no longer uses deflink/bss_conf/etc.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Split the bss_info_changed method to vif_cfg_changed and
link_info_changed, with the latter getting a link ID.
Also change the 'changed' parameter to u64 already, we
know we need that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In order to support multi-link operation with multiple links,
start adding some APIs. The notable addition here is to have
the link ID in a new nl80211 attribute, that will be used to
differentiate the links in many nl80211 operations.
So far, this patch adds the netlink NL80211_ATTR_MLO_LINK_ID
attribute (as well as the NL80211_ATTR_MLO_LINKS attribute)
and plugs it through the system in some places, checking the
validity etc. along with other infrastructure needed for it.
For now, I've decided to include only the over-the-air link
ID in the API. I know we discussed that we eventually need to
have to have other ways of identifying a link, but for local
AP mode and auth/assoc commands as well as set_key etc. we'll
use the OTA ID.
Also included in this patch is some refactoring of the data
structures in struct wireless_dev, splitting for the first
time the data into type dependent pieces, to make reasoning
about these things easier.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Avoid abusing the efivar layer by invoking it with locally constructed
efivar_entry instances, and instead, just call the EFI routines directly
if available.
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Using half of the efivar API with locally baked efivar_entry instances
is not the right way to use this API, and these uses impede planned work
on the efivar layer itself.
So switch to direct EFI variable store accesses: we don't need the
efivar layer anyway.
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
As per commit c4f135d643 ("workqueue: Wrap flush_workqueue() using
a macro") says, use per "struct ath6kl_usb" workqueue.
This is a blind conversion, and is only compile tested.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/f78ddbdc-8989-a1a7-2234-ce9ec3894625@I-love.SAKURA.ne.jp
I've changed *STAT_* macros a bit in previous patch and I seems like
they become really unreadable. Align these macros definitions to make
code cleaner and fix folllowing checkpatch warning
ERROR: Macros with complex values should be enclosed in parentheses
Also, statistics macros now accept an hif_dev as argument, since
macros that depend on having a local variable with a magic name
don't abide by the coding style.
No functional change
Suggested-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/ebb2306d06a496cd1b032155ae52fdc5fa8cc2c5.1655145743.git.paskripkin@gmail.com
Here's a first set of patches for v5.20. This is just a
queue flush, before we get things back from net-next that
are causing conflicts, and then can start merging a lot
of MLO (multi-link operation, part of 802.11be) code.
Lots of cleanups all over.
The only notable change is perhaps wilc1000 being the
first driver to disable WEP (while enabling WPA3).
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEH1e1rEeCd0AIMq6MB8qZga/fl8QFAmKjUdAACgkQB8qZga/f
l8RE0xAAhVNBB3r0n8bcZXNxmb/zswjyQcRV3BrSxRwfOGppB4iqHuTEx7U7iBOK
9hMacse+myVlFNncWzGnOiZ9XIIElepPATfHXYPlVOrUO5AzqvtuuZG/6cBShO+G
A1YrdVPYd87WiowTovY2x7tknZYMoQYeVeGmIMIEViM0RjULkXPC9AhpKbiHoV4I
Ayn97E0j2+6R/gCtlhYTm0ASvzbVVoIB9cHMwvopzEXtsIjcE5Tglgrhygtw0FI3
w2EZi5091c6IA2lc+kEmN2saAX72f6G3cewYID84/l8U2+VuwzdDUnXsyXYgGFF8
UM47qizFSrwAn7eSiUNpLK0b8um/C2+ryBBUDrhbCvlR6/8shwvV1YMSX5eo00Av
rPtC7/7wXF0ox8Os+FTTqAptyWDFQMI4dYkbQjZ4KsR7/jXssReIsYLLPlYGRgU5
zemdd1onofZN4N9QXMtMxR7xwoKvPBRGqZa0YgnbSGF7dSjL+fleVlRwuhLZsWvb
KJQyut9/InC9C2kKjsdK+bcv8lLmJE65PdFM5CZBLnEZvf7stOkeg2WcuqNSzjca
VO7UIv8yQeJV2cpSBgmC4XchAU21r2rEzViz7PDLTFB9ZfYgcBIad9G10Mx5u11L
2GHmDX5r2X1QD91nsTqOBCn0xO67jpcgxMpiGC31VReV7BTKvSc=
=E0Dx
-----END PGP SIGNATURE-----
Merge tag 'wireless-next-2022-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
wireless-next patches for v5.20
Here's a first set of patches for v5.20. This is just a
queue flush, before we get things back from net-next that
are causing conflicts, and then can start merging a lot
of MLO (multi-link operation, part of 802.11be) code.
Lots of cleanups all over.
The only notable change is perhaps wilc1000 being the
first driver to disable WEP (while enabling WPA3).
* tag 'wireless-next-2022-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (29 commits)
wifi: mac80211_hwsim: Directly use ida_alloc()/free()
wifi: mac80211: refactor some key code
wifi: mac80211: remove cipher scheme support
wifi: nl80211: fix typo in comment
wifi: virt_wifi: fix typo in comment
rtw89: add new state to CFO state machine for UL-OFDMA
rtw89: 8852c: add trigger frame counter
ieee80211: add trigger frame definition
wifi: wfx: Remove redundant NULL check before release_firmware() call
wifi: rtw89: support MULTI_BSSID and correct BSSID mask of H2C
wifi: ray_cs: Drop useless status variable in parse_addr()
wifi: ray_cs: Utilize strnlen() in parse_addr()
wifi: rtw88: use %*ph to print small buffer
wifi: wilc1000: add IGTK support
wifi: wilc1000: add WPA3 SAE support
wifi: wilc1000: remove WEP security support
wifi: wilc1000: use correct sequence of RESET for chip Power-UP/Down
wifi: rtlwifi: fix error codes in rtl_debugfs_set_write_h2c()
wifi: rtw88: Fix Sparse warning for rtw8821c_hw_spec
wifi: rtw88: Fix Sparse warning for rtw8723d_hw_spec
...
====================
Link: https://lore.kernel.org/r/20220610142838.330862-1-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Based on the normalized pattern:
this software file (the file ) is distributed by nxp under the terms
of the gnu general public license version 2 june 1991 (the license )
you may use redistribute and/or modify this file in accordance with
the terms and conditions of the license a copy of which is available
by writing to the free software foundation inc 51 franklin street
fifth floor boston ma 02110-1301 usa or on the worldwide web at
http://www gnu org/licenses/old-licenses/gpl-2 0 txt the file is
distributed as-is without warranty of any kind and the implied
warranties of merchantability or fitness for a particular purpose are
expressly disclaimed the license provides additional details about
this warranty disclaimer
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference.
Reviewed-by: Allison Randal <allison@lohutok.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add an new state, RTW89_PHY_DCFO_STATE_HOLD, to keep CFO acceleration
after CFO_PERIOD_CNT if the traffic is UL-OFDMA, which is calculated
based on RX trigger frame counter.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220608113224.11193-4-pkshih@realtek.com
Adding this allows us to maintain trigger frame statistics, which is
required for our CFO tracking decisions.
Signed-off-by: Po Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220608113224.11193-3-pkshih@realtek.com
release_firmware() checks for NULL pointers internally so checking
before calling it is redundant.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220606014237.290466-1-chi.minghao@zte.com.cn
The BSSID mask of H2C is used to match BSSID of receiving packets.
Normally, we set six bits BSSID mask to exactly match BSSID of packets
sent by target AP. After we support multiple BSSID, it could connect a
nontransmitted BSSID, so we can only match first five bytes of BSSID.
That means we could possibly receive other AP's packets if only the last
byte of BSSID is different from target AP.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220530112743.106857-1-pkshih@realtek.com
Fix warnings reported by checkpatch tool. Below are the errors fixed,
drivers/net/wireless/ath/ath11k/hal_rx.c:760: 'recevied' may be misspelled - perhaps 'received?
drivers/net/wireless/ath/ath11k/qmi.c:2232: Prefer strscpy over strlcpy
drivers/net/wireless/ath/ath11k/qmi.c:2238: Prefer strscpy over strlcpy
drivers/net/wireless/ath/ath11k/qmi.c:2662: Prefer strscpy over strlcpy
drivers/net/wireless/ath/ath11k/mac.c:7836: 'atleast' may be misspelled - perhaps 'at least'?
drivers/net/wireless/ath/ath11k/wmi.c:6566: 'succeded' may be misspelled - perhaps 'succeeded'?
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220602131350.29486-1-quic_mpubbise@quicinc.com
Currently ar->ht_cap_info is not set anywhere in the code, this could
result in LDPC config computed wrongly in the set_bitrate_mask() hook
and eventually sending wrong config to the target. Fix this by checking
the LDPC support from the band HT capabilities of the radio instead.
Furthermore, it looks like firmwares running on the ath11k hardware
do not set WMI_HT_CAP_LDPC for advertising the TX LDPC capability,
WMI_HT_CAP_TX_LDPC is set instead and this should be checked for
getting hardware's TX LDPC support. This is true for QCA6390, WCN6855
& WCN6750 hardware.
Also, remove unused variables ht_cap_info & vht_cap_info from
struct ath11k{}.
Found this during code review.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220602124142.29909-1-quic_mpubbise@quicinc.com
Currently when firmware recovery is in progress, we do not queue REO
commands to the firmware, instead -ESHUTDOWN will be returned to the
caller leading to a failure print on the console. The REO command in
the problem scenario is sent for all tids of a peer in which case we
will have 16 failure prints on the console for a single peer. For an
AP usecase, this count would be even higher in a worst case scenario.
Since these commands are bound to fail during firmware recovery, it
is better to avoid printing these failures and thereby avoid message
flooding on the console.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Fixes: 8ee8d38ca4 ("ath11k: Fix crash during firmware recovery on reo cmd ring access")
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220602122929.18896-1-quic_mpubbise@quicinc.com
Currently a couple of debug_mask entries are mapped to the same value,
this could enable unintended driver logging. If enabling DP_TX logs was
the intention, then this could also enable PCI logs flooding the dmesg
buffer or vice versa. Fix this by correctly assigning the debug masks.
Found during code review.
Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1
Fixes: aa2092a9ba ("ath11k: add raw mode and software crypto support")
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220602115621.15339-1-quic_mpubbise@quicinc.com
On htc_tx_completion error the skb is not dropped. This is wrong since
the completion_handler logic expect the skb to be consumed anyway even
when an error is triggered. Not freeing the skb on error is a memory
leak since the skb won't be freed anywere else. Correctly free the
packet on eid >= ATH11K_HTC_EP_COUNT before returning.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Fixes: f951380a60 ("ath11k: Disabling credit flow for WMI path")
Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220528142516.20819-2-ansuelsmth@gmail.com
Here is the "big" set of USB and Thunderbolt driver changes for
5.18-rc1. For the most part it's been a quiet development cycle for the
USB core, but there are the usual "hot spots" of development activity.
Included in here are:
- Thunderbolt driver updates:
- fixes for devices without displayport adapters
- lane bonding support and improvements
- other minor changes based on device testing
- dwc3 gadget driver changes. It seems this driver will never
be finished given that the IP core is showing up in zillions
of new devices and each implementation decides to do something
different with it...
- uvc gadget driver updates as more devices start to use and
rely on this hardware as well
- usb_maxpacket() api changes to remove an unneeded and unused
parameter.
- usb-serial driver device id updates and small cleanups
- typec cleanups and fixes based on device testing
- device tree updates for usb properties
- lots of other small fixes and driver updates.
All of these have been in linux-next for weeks with no reported
problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYpnZGw8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ymQhwCeLVANsQjBcL4ys4skl+1In17y28gAn3rEZ7rQ
Yv4uP9zadUqg3Cx0vjgf
=3s5s
-----END PGP SIGNATURE-----
Merge tag 'usb-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt updates from Greg KH:
"Here is the "big" set of USB and Thunderbolt driver changes for
5.18-rc1. For the most part it's been a quiet development cycle for
the USB core, but there are the usual "hot spots" of development
activity.
Included in here are:
- Thunderbolt driver updates:
- fixes for devices without displayport adapters
- lane bonding support and improvements
- other minor changes based on device testing
- dwc3 gadget driver changes.
It seems this driver will never be finished given that the IP core
is showing up in zillions of new devices and each implementation
decides to do something different with it...
- uvc gadget driver updates as more devices start to use and rely on
this hardware as well
- usb_maxpacket() api changes to remove an unneeded and unused
parameter.
- usb-serial driver device id updates and small cleanups
- typec cleanups and fixes based on device testing
- device tree updates for usb properties
- lots of other small fixes and driver updates.
All of these have been in linux-next for weeks with no reported
problems"
* tag 'usb-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (154 commits)
USB: new quirk for Dell Gen 2 devices
usb: dwc3: core: Add error log when core soft reset failed
usb: dwc3: gadget: Move null pinter check to proper place
usb: hub: Simplify error and success path in port_over_current_notify
usb: cdns3: allocate TX FIFO size according to composite EP number
usb: dwc3: Fix ep0 handling when getting reset while doing control transfer
usb: Probe EHCI, OHCI controllers asynchronously
usb: isp1760: Fix out-of-bounds array access
xhci: Don't defer primary roothub registration if there is only one roothub
USB: serial: option: add Quectel BG95 modem
USB: serial: pl2303: fix type detection for odd device
xhci: Allow host runtime PM as default for Intel Alder Lake N xHCI
xhci: Remove quirk for over 10 year old evaluation hardware
xhci: prevent U2 link power state if Intel tier policy prevented U1
xhci: use generic command timer for stop endpoint commands.
usb: host: xhci-plat: omit shared hcd if either root hub has no ports
usb: host: xhci-plat: prepare operation w/o shared hcd
usb: host: xhci-plat: create shared hcd after having added main hcd
xhci: prepare for operation w/o shared hcd
xhci: factor out parts of xhci_gen_setup()
...
Here is the big set of staging driver updates for 5.19-rc1.
Lots of forward progress happened this development cycle, one driver
(wfx wireless driver) got merged into the real portion of the kernel,
and another one (unisys) was removed as no one is around anymore to take
care of it and no one has the hardware. Combined with loads of tiny
driver cleanups overall we removed 13k lines of code from the tree, a
nice improvement.
Other than the wfx and unisys driver changes the major points of this
merge is:
- r8188eu driver cleanups. So many cleanups. It's amazing just
how many things have been cleaned up here, and yet, how many
remain to go. Lots of work happened here, and it doesn't look
to slow down any time soon.
- other wifi driver cleanups. Not as many as the r8188eu
driver, but still pretty impressive from a janitorial point of
view.
- bcm2853 driver cleanups
- other very minor driver cleanups
All of these have been in the linux-next tree for weeks with no reported
issues.
Note, you will have a merge conflict in the
drivers/net/wireless/silabs/wfx/sta.c file, please just take the change
that came in from the wifi tree. We thought as I had pulled the same
merge point from the wifi developers this type of conflict wouldn't have
happened, but for some reason git flags it as something to pay attention
to and couldn't resolve it itself.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYpnfqA8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ynbFQCfbr7wdJYsNfVd0nXlDUw9EQtbhR8AoM5Y31Ni
hBJs6fa/HMGfLnrmN2Xi
=BQyT
-----END PGP SIGNATURE-----
Merge tag 'staging-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver updates from Greg KH:
"Here is the big set of staging driver updates for 5.19-rc1.
Lots of forward progress happened this development cycle, one driver
(wfx wireless driver) got merged into the real portion of the kernel,
and another one (unisys) was removed as no one is around anymore to
take care of it and no one has the hardware. Combined with loads of
tiny driver cleanups overall we removed 13k lines of code from the
tree, a nice improvement.
Other than the wfx and unisys driver changes the major points of this
merge is:
- r8188eu driver cleanups. So many cleanups. It's amazing just how
many things have been cleaned up here, and yet, how many remain to
go. Lots of work happened here, and it doesn't look to slow down
any time soon.
- other wifi driver cleanups. Not as many as the r8188eu driver, but
still pretty impressive from a janitorial point of view.
- bcm2853 driver cleanups
- other very minor driver cleanups
All of these have been in the linux-next tree for weeks with no
reported issues"
* tag 'staging-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (363 commits)
staging: r8188eu: remove include/rtw_debug.h
staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan()
staging: r8188eu: delete rtw_wx_read/write32()
staging: r8188eu: Remove multiple assignments
staging: r8188eu: add check for kzalloc
staging: r8188eu: fix warnings in rtw_wlan_util
staging: r8188eu: fix warnings in rtw_pwrctrl
staging: r8188eu: fix warnings in rtw_p2p
staging: rtl8712: fix uninit-value in r871xu_drv_init()
staging: rtl8712: fix uninit-value in usb_read8() and friends
staging: rtl8712: add error handler in r8712_usbctrl_vendorreq()
staging: r8188eu: remove _drv_ defines from include/rtw_debug.h
staging: vc04_services: remove unused macro
staging: rtl8192u: remove null check after call container_of()
staging: rtl8192e: remove null check after call container_of()
staging: ks7010: remove null check after call container_of()
staging: r8188eu: remove HW_VAR_AC_PARAM_BE from SetHwReg8188EU()
staging: r8188eu: assoc_rsp and assoc_rsp_len are not used
staging: r8188eu: last_rx_mgnt_pkts is set but not used
staging: r8188eu: simplify error handling in recv_func_prehandle
...
When wlan load, firmware report the reg code with 0x6C for QCA6174,
it is world reg which checked by ath_is_world_regd(), then the reg
will be save into reg_world_copy of ath_common in ath_regd_init().
Later the regulatory of ath_common is updated to another country
code such as "US" in ath_reg_notifier_apply() by below call stack.
After that, regulatory_hint() is called in ath10k_mac_register()
and it lead "iw reg get" show two regdomain info as below.
global
country US: DFS-FCC
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#0
country US: DFS-FCC
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
[ 4255.704975] Call Trace:
[ 4255.704983] ath_reg_notifier_apply+0xa6/0xc5 [ath]
[ 4255.704991] ath10k_reg_notifier+0x2f/0xd2 [ath10k_core]
[ 4255.705010] wiphy_regulatory_register+0x5f/0x69 [cfg80211]
[ 4255.705020] wiphy_register+0x459/0x8f0 [cfg80211]
[ 4255.705042] ? ieee80211_register_hw+0x3a6/0x7d1 [mac80211]
[ 4255.705049] ? __kmalloc+0xf4/0x218
[ 4255.705058] ? ieee80211_register_hw+0x3a6/0x7d1 [mac80211]
[ 4255.705066] ? ath10k_mac_register+0x70/0xaab [ath10k_core]
[ 4255.705075] ieee80211_register_hw+0x51a/0x7d1 [mac80211]
[ 4255.705084] ath10k_mac_register+0x8b4/0xaab [ath10k_core]
[ 4255.705094] ath10k_core_register_work+0xa5e/0xb45 [ath10k_core]
[ 4255.705100] ? __schedule+0x61f/0x7d3
[ 4255.705105] process_one_work+0x1b7/0x392
[ 4255.705109] worker_thread+0x271/0x35d
[ 4255.705112] ? pr_cont_work+0x58/0x58
[ 4255.705116] kthread+0x13f/0x147
[ 4255.705119] ? pr_cont_work+0x58/0x58
[ 4255.705123] ? kthread_destroy_worker+0x62/0x62
[ 4255.705126] ret_from_fork+0x22/0x40
At this moment, the two regdomain info is same, when run "iw reg set KR",
the global regdomain info changed to KR, but the regdomain of phy#0
does not change again. It leads inconsistent values between global and
phy#0 as below.
global
country KR: DFS-JP
(2402 - 2482 @ 40), (N/A, 13), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 30), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57000 - 66000 @ 2160), (N/A, 43), (N/A)
phy#0
country US: DFS-FCC
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
The initial reg code is 0x6C which saved in reg_world_copy of ath_common,
and the code US is updated from cfg80211 later, so ath10k should also
check the initial reg code before regulatory_hint().
After this fix, regdomain info is same between "iw reg get" and "iw reg
set xx", it does not have the regdomain info of phy#0 again.
global
country KR: DFS-JP
(2402 - 2482 @ 40), (N/A, 13), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 30), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57000 - 66000 @ 2160), (N/A, 43), (N/A)
This does not effect the channel list and power which ath10k used.
When the country code for regulatory_hint() in ath10k_mac_register()
is same with the global country code, then reg_set_rd_driver() of
cfg80211 called from crda which return -EALREADY to set_regdom() and
then update_all_wiphy_regulatory() will not be called while wlan load.
When run "iw reg set xx", reg_get_regdomain() which used by function
handle_channel() in net/wirelss/reg.c always use the regdomain
returned by get_cfg80211_regdom() because the initiator of last
regulatory_request is NL80211_REGDOM_SET_BY_USER, get_cfg80211_regdom()
is the global regdomain, then all the ieee80211_channel info is updated
in handle_channel() with the global regdomain.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Tested-on: QCA9984 hw1.0 PCI 10.4-3.6-00104
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220525132247.23459-1-quic_wgong@quicinc.com
Currently mac80211 doesn't calculate average signal when RSS(Receive side
scaling) is enabled from the driver, so average signal isn't printed in
the station dump. To address this issue, calculate the average signal
from RSSI within driver and display in the station dump.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Signed-off-by: Thiraviyam Mariyappan <quic_tmariyap@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1652965061-30457-1-git-send-email-quic_tmariyap@quicinc.com
Make sure to clear the IRQ affinity hint also on shutdown to avoid
triggering a WARN_ON_ONCE() in __free_irq() when stopping MHI while
using a single MSI vector.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Fixes: e94b07493d ("ath11k: Set IRQ affinity to CPU0 in case of one MSI vector")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220523143258.24818-1-johan+linaro@kernel.org
Make sure to allocate resources needed before registering the device.
This specifically avoids having a racing open() trigger a BUG_ON() in
mod_timer() when ath11k_mac_op_start() is called before the
mon_reap_timer as been set up.
I did not see this issue with next-20220310, but I hit it on every probe
with next-20220511. Perhaps some timing changed in between.
Here's the backtrace:
[ 51.346947] kernel BUG at kernel/time/timer.c:990!
[ 51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
...
[ 51.578225] Call trace:
[ 51.583293] __mod_timer+0x298/0x390
[ 51.589518] mod_timer+0x14/0x20
[ 51.595368] ath11k_mac_op_start+0x41c/0x4a0 [ath11k]
[ 51.603165] drv_start+0x38/0x60 [mac80211]
[ 51.610110] ieee80211_do_open+0x29c/0x7d0 [mac80211]
[ 51.617945] ieee80211_open+0x60/0xb0 [mac80211]
[ 51.625311] __dev_open+0x100/0x1c0
[ 51.631420] __dev_change_flags+0x194/0x210
[ 51.638214] dev_change_flags+0x24/0x70
[ 51.644646] do_setlink+0x228/0xdb0
[ 51.650723] __rtnl_newlink+0x460/0x830
[ 51.657162] rtnl_newlink+0x4c/0x80
[ 51.663229] rtnetlink_rcv_msg+0x124/0x390
[ 51.669917] netlink_rcv_skb+0x58/0x130
[ 51.676314] rtnetlink_rcv+0x18/0x30
[ 51.682460] netlink_unicast+0x250/0x310
[ 51.688960] netlink_sendmsg+0x19c/0x3e0
[ 51.695458] ____sys_sendmsg+0x220/0x290
[ 51.701938] ___sys_sendmsg+0x7c/0xc0
[ 51.708148] __sys_sendmsg+0x68/0xd0
[ 51.714254] __arm64_sys_sendmsg+0x28/0x40
[ 51.720900] invoke_syscall+0x48/0x120
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Fixes: 840c36fa72 ("ath11k: dp: stop rx pktlog before suspend")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220517103436.15867-1-johan+linaro@kernel.org
Add support to handle IGTK keys which are required for MFP to FW. Index ID
4 and 5 are used to store the IGTK key.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524120606.9675-4-ajay.kathat@microchip.com
Enable SAE authentication for AP and STA mode. In STA mode, allow the
driver to pass the auth frames which are received from firmware to
userspace application(hostapd) so that SAE authentication is offloaded to
userspace.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524120606.9675-3-ajay.kathat@microchip.com
Deprecated WEP security for WILC driver as well as in firmware from
15.6 FW release onwards. After WEP security removal, freeup some codespace
which helped to add new features like WPA3 etc.
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524120606.9675-2-ajay.kathat@microchip.com
For power-up sequence, WILC expects RESET set to high 5ms after making
chip_en(enable) so corrected chip power-up sequence by making RESET high.
For Power-Down sequence, the correct sequence make RESET and CHIP_EN low
without any extra delay.
Fixes: ec031ac479 ("wilc1000: Add reset/enable GPIO support to SPI driver")
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524120606.9675-1-ajay.kathat@microchip.com
If the copy_from_user() fails or the user gives invalid date then the
correct thing to do is to return a negative error code. (Currently it
returns success).
I made a copy additional related cleanups:
1) There is no need to check "buffer" for NULL. That's handled by
copy_from_user().
2) The "h2c_len" variable cannot be negative because it is unsigned
and because sscanf() does not return negative error codes.
Fixes: 610247f46f ("rtlwifi: Improve debugging by using debugfs")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/YoOLnDkHgVltyXK7@kili
Sparse lists the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8821c.c
drivers/net/wireless/realtek/rtw88/rtw8821c.c:1880:22: warning: symbol 'rtw8821c_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8821c_hw_spec
occurs in rtw8821ce.h, which is not included in rtw8821c.h. That line is
moved, and the now empty file rtw8821ce.h is deleted.
Symbol 'rtw8821c_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153716.20450-1-Larry.Finger@lwfinger.net
Sparse lists the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8723d.c
drivers/net/wireless/realtek/rtw88/rtw8723d.c:2704:22: warning: symbol 'rtw8723d_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8723d_hw_spec
occurs in rtw8723de.h, which is not included in rtw8723d.h. That line is
moved, and the now empty file rtw8723de.h is deleted.
Symbol 'rtw8723d_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-4-Larry.Finger@lwfinger.net
Sparse reports the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8822c.c
drivers/net/wireless/realtek/rtw88/rtw8822c.c:5313:22: warning: symbol 'rtw8822c_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8822c_hw_spec
occurs in rtw8822ce.h, which is not included in rtw8822c.h. That line is
moved, and the now empty file rtw8822ce.h is deleted.
Symbol 'rtw8822c_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-3-Larry.Finger@lwfinger.net
Sparse lists the following for rtw88:
CHECK drivers/net/wireless/realtek/rtw88/rtw8822b.c
drivers/net/wireless/realtek/rtw88/rtw8822b.c:2500:22: warning: symbol 'rtw8822b_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8822b_hw_spec
occurs in rtw8822be.h, which is not included in rtw8822b.h. That line is
moved, and the now empty file rtw8822be.h is deleted.
Symbol 'rtw8822b_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-2-Larry.Finger@lwfinger.net
Add this check to avoid crash by dereferencing a null pointer. When hwscan
fails due to no memory or dma failure, the scan flag in ieee80211_local is
cleared. So mac80211 determine that it's not hw_scan then calls
sw_scan_complete() with null vif, which is also freed during the fail.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220520081523.45987-1-pkshih@realtek.com
