- 08 Feb, 2024 6 commits
-
-
Johannes Berg authored
In the code we currently check for support 80+80, 160 and 320 channel widths, but really the way this should be (and is otherwise) handled is that we compute the highest channel bandwidth given there, and then cut it down to what we support. This is also needed for wider bandwidth OFDMA support. Change the code to remove this limitation and always parse the highest possible channel width. Reviewed-by:
Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240129194108.d06f85082e29.I47e68ed3d97b0a2f4ee61e5d8abfcefc8a5b9c08@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Rewrite the station-side connection handling. The connection flags (IEEE80211_DISABLE_*) are rather confusing, and they're not always maintained well. Additionally, for wider-bandwidth OFDMA support we need to know the precise bandwidth of the AP, which is currently somewhat difficult. Rewrite this to have a 'mode' (S1G/legacy/HT/...) and a limit on the bandwidth. This is not entirely clean because some of those modes aren't completely sequenced (as this assumes in some places), e.g. VHT doesn't exist on 2.4 GHz, but HE does. However, it still simplifies things and gives us a good idea what we're operating as, so we can parse elements accordingly etc. This leaves a FIXME for puncturing, this is addressed in a later patch. Reviewed-by:
Ilan Peer <ilan.peer@intel.com> Reviewed-by:
-
Johannes Berg authored
Most devices now do duration calculations, so we don't hit this code at all any more. Clearly the approach of warning at compile time here when new bands are added didn't work, the new bands were just added with "TODO". Clean it up, it won't matter for new bands since they'll just not have any need to calculate durations in software. While at it, also clean up and unify the code a bit. Link: https://msgid.link/20240129194108.70a97bd69265.Icdd8b0ac60a382244466510090eb0f5868151f39@changeidSigned-off-by:
-
Johannes Berg authored
Not sure how this happened or how nothing complained, but this variable already exists in the outer function scope with the same value (and the SKB isn't changed either.) Remove the extra one. Signed-off-by: -
Johannes Berg authored
This got unused when the tracing was converted to dynamic strings, so the define can be removed. Signed-off-by: -
Johannes Berg authored
There are some changes coming to wireless-next that will otherwise cause conflicts, pull wireless in first to be able to resolve that when applying the individual changes rather than having to do merge resolution later. Signed-off-by:
-
- 06 Feb, 2024 19 commits
-
-
Martin Kaistra authored
Until now, rtl8xxxu_watchdog_callback() only fetches RSSI and updates the rate mask in station mode. This means, in AP mode only the default rate mask is used. In order to have the rate mask reflect the actual connection quality, extend rtl8xxxu_watchdog_callback() to iterate over every sta. Like in the rtw88 driver, add a function to collect all currently present stas and then iterate over a list of copies to ensure no RCU lock problems for register access via USB. Remove the existing RCU lock in rtl8xxxu_refresh_rate_mask(). Since the currently used ieee80211_ave_rssi() is only for 'vif', add driver-level tracking of RSSI per sta. Signed-off-by:
Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240205093040.1941140-1-martin.kaistra@linutronix.de
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the bcma_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ricardo B. Marliere <ricardo@marliere.net> Reviewed-by:
-
Ricardo B. Marliere authored
Now that the driver core can properly handle constant struct bus_type, move the ssb_bustype variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by:
Michael Büsch <m@bues.ch> Reviewed-by:
-
Jérôme Pouiller authored
Kmemleak reported this error: unreferenced object 0xd73d1180 (size 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................ backtrace: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [<f965b9b6>] netlink_sendmsg+0x1e8/0x428 [<aadb8231>] ____sys_sendmsg+0x1e0/0x274 [<d2b5212d>] ___sys_sendmsg+0x80/0xb4 [<69954f45>] __sys_sendmsg+0x64/0xa8 unreferenced object 0xce087000 (size 1024): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74 [<a2c61343>] __alloc_skb+0xa0/0x170 [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [<f965b9b6>] netlink_sendmsg+0x1e8/0x428 [<aadb8231>] ____sys_sendmsg+0x1e0/0x274 [<d2b5212d>] ___sys_sendmsg+0x80/0xb4 However, since the kernel is build optimized, it seems the stack is not accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue is obvious in this function: memory allocated by ieee80211_beacon_get() is never released. Fixing this leak makes kmemleak happy. Reported-by:Ulrich Mohr <u.mohr@semex-engcon.com> Co-developed-by:
Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by:
-
Ping-Ke Shih authored
Since firmware header contains multiple secure sections, we need to trim ignored sections, and then download firmware header with single one secure section. For secure boot, when downloading secure section, copy security key data from MSS poll by key_idx read from efuse. If non-secure boot, no need this extra copy. +---------------------------+ -\ | firmware header | | | | | | +-----------------------+ | | only preserve single one secure | | section type/size * N | | | section | | ... | | | | +-----------------------+ | | +---------------------------+ -/ : : +---------------------------+ -\ | secure section type (ID:9)| | | | | +----|-> [ security key data ] | | | +---------------------------+ -/ | |MSS Pool for above section | | | [ security key data 0 ] | +----|- [ security key data 1 ] | by key_idx | [ security key data 2 ] | | ... | +---------------------------+ Signed-off-by: -
Ping-Ke Shih authored
A firmware file can contains more than one section with secure type, so use secure information from efuse to choose the one with matched cryptography method. Then choose key data from MSS poll (multiple security section pool; see below picture) according to key_index from efuse. Note that the size of MSS pool isn't included in section size defined in firmware header, so we also need to parse header of MSS pool to get its size as shift to parse next section. If secure boot isn't supported by current hardware, the first secure section will be adopted, and no need additional process to key data. +---------------------------+ | firmware header | | | | +-----------------------+ | | | section type/size * N-|-|-------+ | | ... | | | | +-----------------------+ | | +---------------------------+ | : : | +---------------------------+ -\ | | secure section type (ID:9)| | | | | | <--+ | | | +---------------------------+ -/ |MSS Pool for above section | | | | | +---------------------------+ Signed-off-by:
-
Ping-Ke Shih authored
To support firmware secure boot, read secure information from efuse to know if current hardware module can support secure boot with certain cryptography method. This information should be prepared before downloading firmware, so read efuse right after power on at probe stage. The secure information includes secure cryptography method and secure key index that are used to choose proper key material when downloading firmware. Signed-off-by:
-
Ping-Ke Shih authored
The newer firmware file provides security data with checksum, so we need to consider the length. Otherwise it will fail to validate total firmware length resulting in failed to probe. Signed-off-by:
-
Ping-Ke Shih authored
Add a chip_ops for WiFi 7 chips to set additional RF configurations including MLO and PLL settings. Signed-off-by:
-
Ping-Ke Shih authored
The RF calibrations are moved into firmware, so we trigger calibrations by H2C commands and wait for C2H completion events. However, these events can be received only after HCI (i.e. PCI for now) starts, so we should do initial RF calibrations after that. Signed-off-by:
-
Ping-Ke Shih authored
Calling RF calibrations when interface up, connection, switching bands and going to scan. For 8922AE, RF calibrations are moved to firmware, so use H2C commands to trigger RF calibrations and wait for a C2H event to indicate completion. Then, do next RF calibration. Signed-off-by:
-
Ping-Ke Shih authored
TSSI is short for transmitter signal strength indication, which is a close-loop hardware circuit to feedback actual transmitting power as a reference to adjust power for next transmission. When connecting and switching bands or channels, do TSSI calibration and reset hardware status to output expected power. Signed-off-by:
-
Ping-Ke Shih authored
TXGAPK stands for TX power gap calibration. Use this calibration to compensate TX power gap to output expected power. Signed-off-by:
-
Ping-Ke Shih authored
DACK (digital-to-analog converters calibration) is used to calibrate DAC to output signals with expected quality. Signed-off-by:
-
Ping-Ke Shih authored
DPK is short for digital pre-distortion calibration. It can adjusts digital waveform according to PA linear characteristics dynamically to enhance TX EVM. Signed-off-by:
-
Ping-Ke Shih authored
RX DCK is receiver DC calibration. This will calibrate DC offset to reflect correct received signal strength indicator, so mechanisms like CCA can have normalized values. Signed-off-by:
-
Ping-Ke Shih authored
IQ signal calibration is a basic and important calibration to yield good RF performance. Do this calibration on AP channel if we are going to connect. During scanning phase, it transmits with low data rate, so without IQK RF performance is still acceptable. Signed-off-by:
-
Ping-Ke Shih authored
We are going to do RF calibrations in firmware, so driver needs to provide channel information for calibrations, which can do the same things as they did in driver. Signed-off-by:
-
Ping-Ke Shih authored
The RF calibrations should be executed one by one, so add a completion to ensure one is finish before next. The report from C2H event contains state and optional version, and we only check the state for now. We also care about the time a RF calibration takes, so record start time before asking firmware to do calibration and get the delta time when receiving report. Consider SER recovery, we can't receive C2H event, use half of argument 'ms' as fixed delay that is 2 times of measured maximum time of calibrations. Signed-off-by:
-
- 05 Feb, 2024 12 commits
-
-
David Lechner authored
Calling spi_sync() unconditionally sets the spi field of struct spi_message. Therefore setting msg.spi = spi before calling spi_sync() has no effect and can be removed. (spi_message_add_tail() does not access this field.) Signed-off-by:
David Lechner <dlechner@baylibre.com> Signed-off-by:
-
Linus Walleij authored
The CW1200 uses two GPIOs to control the powerup and reset pins, get these from GPIO descriptors instead of being passed as platform data from boardfiles. The RESET line will need to be marked as active low as we will let gpiolib handle the polarity inversion. The SDIO case is a bit special since the "card" need to be powered up before it gets detected on the SDIO bus and properly probed. Fix this by using board-specific GPIOs assigned to device "NULL". There are currently no in-tree users. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
The driver includes the legacy GPIO header <linux/gpio.h> but does not use any symbols from it. Drop the include. Signed-off-by:
-
Linus Walleij authored
The mwifiex driver include two legacy GPIO headers but does not use symbols from any of them. The driver does contain some "gpio" handling code, but this is some custom GPIO interface, not the Linux GPIO. Signed-off-by:
-
Linus Walleij authored
The driver is using all the modern abstractions to obtain and use GPIOs and the legacy <linux/gpio.h> header is unused, so drop it. Fixes: a8e59744 ("gpiolib: split linux/gpio/driver.h out of linux/gpio.h") Signed-off-by:
-
Linus Walleij authored
The file is including the legacy GPIO header <linux/gpio.h> but is not using any symbols from it, drop the header. Signed-off-by:
-
Kalle Valo authored
Sparse warns: drivers/net/wireless/st/cw1200/cw1200_spi.c:83:17: got restricted __le16 [usertype] drivers/net/wireless/st/cw1200/cw1200_spi.c:148:17: warning: incorrect type in assignment (different base types) drivers/net/wireless/st/cw1200/cw1200_spi.c:148:17: expected unsigned short [addressable] [assigned] [usertype] regaddr drivers/net/wireless/st/cw1200/cw1200_spi.c:148:17: got restricted __le16 [usertype] These cpu_to_le16() calls are not really making any sense to me. On a big endian system we first convert regaddr from big to little using cpu_to_le16() but immediately after we convert them back to big endian? So just remove them. Compile tested only. Signed-off-by:
-
Kalle Valo authored
drivers/net/wireless/rsi/rsi_91x_usb.c:235:27: warning: restricted __le32 degrades to integer drivers/net/wireless/rsi/rsi_91x_usb.c:236:27: warning: restricted __le32 degrades to integer drivers/net/wireless/rsi/rsi_91x_usb.c:237:27: warning: restricted __le32 degrades to integer drivers/net/wireless/rsi/rsi_91x_usb.c:238:27: warning: restricted __le32 degrades to integer drivers/net/wireless/rsi/rsi_91x_usb.c:244:36: warning: restricted __le32 degrades to integer drivers/net/wireless/rsi/rsi_91x_usb.c:245:35: warning: restricted __le32 degrades to integer These cpu_to_le32() are not making sense. With usb_reg_buf we handle the values byte at a time to make sure usb_reg_buf is in little endian so no need to convert anything. And usb_control_msg() expects to have the values in native endian anyway. So just remove these so they are not spamming our logs. Compile tested only. Signed-off-by:
-
Kalle Valo authored
Sparse warns: drivers/net/wireless/zydas/zd1211rw/zd_usb.c:383:24: warning: implicit cast from nocast type drivers/net/wireless/zydas/zd1211rw/zd_usb.c:419:24: warning: implicit cast from nocast type This is an ancient driver which has not have any meaningfuli changes for a long time and hopefully removed soon. So just remove the __nocast to get rid of the sparse warnings. Compile tested only. Signed-off-by:
-
Chun Qiu authored
TP-Link TL-WN823N V2 (2357:0135) is based on rtl8192fu and has been tested to work with the rtl8xxxu driver. Signed-off-by:
Chun Qiu <cqca@cock.lu> Signed-off-by:
-
Zhipeng Lu authored
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). Fixes: 876c9d3a ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver") Signed-off-by:
Zhipeng Lu <alexious@zju.edu.cn> Signed-off-by:
-
Felix Fietkau authored
Copy cck and ofdm separately in order to avoid __read_overflow2_field warning. Fixes: f75e4779 ("wifi: mt76: mt7996: add txpower setting support") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
- 04 Feb, 2024 3 commits
-
-
Johannes Berg authored
These can only be exported if cfg80211's kunit is enabled, since they're otherwise static. kunit itself can be enabled even if cfg80211's kunit isn't. Fix that by using the right macro. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402040534.6AEKtZ7Y-lkp@intel.com/ Fixes: 45d43937 ("wifi: cfg80211: add a kunit test for 6 GHz colocated AP parsing") Signed-off-by:
-
Johannes Berg authored
dmi_get_system_info() will statically return NULL when the kernel is compiled without CONFIG_DMI, leading to compiler warnings. Fix that by printing "<unknown>" in that case. Fixes: c3f40c3e ("iwlwifi: mvm: add US/CA to TAS block list if OEM isn't allowed") Fixes: 9457077d ("wifi: iwlwifi: mvm: Add debugfs to get TAS status") Signed-off-by:
-
Johannes Berg authored
When the system is compiled without CONFIG_DMI, the function here statically returns NULL, leading to a compiler warning. Catch that and print "<unknown>" in that case. While at it, fix some indentation in the function. Reported-by:
-
