Ping-Ke Shih [Mon, 7 Mar 2022 06:04:52 +0000 (14:04 +0800)]
rtw89: add chip_info::{h2c,c2h}_reg to support more chips
This is a register-based H2C/C2H interface to exchange data with firmware.
Since the register addresses of 8852A and 8852C are different, add fields
to chip_info to support this.
Ping-Ke Shih [Mon, 7 Mar 2022 06:04:50 +0000 (14:04 +0800)]
rtw89: add power_{on/off}_func
New chipset uses individual power_{on/off} functions to replace old power
sequences, because it is hard to represent new complicated flow in a
sequence table.
Ping-Ke Shih [Mon, 7 Mar 2022 06:04:48 +0000 (14:04 +0800)]
rtw89: pci: use a struct to describe all registers address related to DMA channel
We have had a struct rtw89_pci_ch_dma_addr to describe register address,
so use it as regular. Since the addresses should be changed dynamically
according to operating mode, I don't change it to be constant.
These changes don't affect the logic, so I put them in this separated
patch.
Colin Ian King [Thu, 3 Mar 2022 08:58:41 +0000 (08:58 +0000)]
bcma: gpio: remove redundant re-assignment of chip->owner
There are two identical assignments of chip->owner to the same value,
the second assignment is redundant and can be removed.
Cleans up cppcheck warning:
drivers/bcma/driver_gpio.c:184:15: style: Variable 'chip->owner' is
reassigned a value before the old one has been used. [redundantAssignment]
Chin-Yen Lee [Fri, 25 Feb 2022 03:08:51 +0000 (11:08 +0800)]
rtw89: add tx_wake notify for low ps mode
We found management frames get stuck when wifi chip
enters low ps mode. So we add one notify wake function
to trigger wifi chip into normal mode before forwarding
management frames.
Po Hao Huang [Fri, 25 Feb 2022 03:08:50 +0000 (11:08 +0800)]
rtw89: 8852a: add ieee80211_ops::hw_scan
Declare this function allows us to use customized scanning policy, so
each scan takes less time. This is a similar implementation to hw_scan
in rtw88, except that we offload more items to firmware and extend the
maximum IE length. For backward compatibility, we fallback to sw_scan
when firmware does not support this feature.
Ping-Ke Shih [Tue, 22 Feb 2022 03:21:03 +0000 (11:21 +0800)]
rtw89: get channel parameters of 160MHz bandwidth
Calculate the offset of center and primary frequencies to get hardware
indices of center channel and primary channel, and then use them to
configure hardware to a specific channel.
Felix Fietkau [Thu, 24 Feb 2022 13:34:33 +0000 (14:34 +0100)]
mt76: fix dfs state issue with 160 MHz channels
When operating on a mix of DFS and non-DFS channels, the driver only checks
the CAC status of the control channel. This causes beacons/tx to fail if the
control channel is on a non-DFS channel.
Fix this by calling cfg80211_reg_can_beacon to determine the DFS status of
all affected channels
Nicolas Cavallari [Mon, 7 Feb 2022 17:37:47 +0000 (18:37 +0100)]
mt76: mt7915e: Enable thermal management by default
By default, mt7915e does not enable thermal management until the default
thermal zone does not reach a trip point. If the rest of the system
have better cooling than the wireless hardware, then it is possible that
the wireless chip can overheat while the rest of the system is fine.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Nicolas Cavallari [Mon, 7 Feb 2022 17:37:46 +0000 (18:37 +0100)]
mt76: mt7915e: Add a hwmon attribute to get the actual throttle state.
The firmware-controlled actual throttle state was previously available
by reading the cooling_device, but this confused the thermal subsystem.
Add a hwmon attribute to get it instead.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Nicolas Cavallari [Mon, 7 Feb 2022 17:37:45 +0000 (18:37 +0100)]
mt76: mt7915e: Fix degraded performance after temporary overheat
mt7915e registers a cooling_device with wrong semantics:
1. cooling_device expect that higher states values should cool more, but
mt7915e did the opposite... with the exception of state == 0, which
should "disable thermal management", but does not seem to have any
effect since the previous state is kept.
The result is that when the thermal zone heats up a bit and bumps the
cooling_device state from 0 to 1 to cool a bit, the performance is
destroyed, and when going back from 1 to 0, the performance stays bad.
2. Reading the cooling_device state does not always return the last
written state, but can return the actual hardware throttle state,
which is different.
This is a problem because the mt7915 firmware actually implement the
equivalent of a thermal zone with trip points. Setting the cooling
device state actually changes the throttles at each trip point, so the
following could occur if the first issue is fixed:
- thermal subsystem set state to 100% power (state=0)
- mt7915e driver set trip throttles to [100%, 50%, 25%, 12%]
- hardware heats up and decides to switch to 50% power
- thermal subsystem see that power is 50% (state=50), decide to increase
it to 60% (state=40) because the rest of the system is cool.
- mt7915e driver set trip throttle to [60%, 30%, 15%, 7%]
- hardware thus switches to 30% power
[race to the bottom continues...]
This patch corrects the semantics of the cooling_device to the one that
the thermal subsystem expect it.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Fri, 4 Feb 2022 19:11:01 +0000 (20:11 +0100)]
mt76: improve signal strength reporting
Instead of just taking the maximum per-chain signal strength values,
add an approximation for the sum of the combined signal.
This should more accurately reflect the real signal strength, especially
if the per-chain signal strength values are close to each other
MeiChia Chiu [Tue, 15 Feb 2022 08:48:58 +0000 (16:48 +0800)]
mt76: mt7915: fix the muru tlv issue
The muru enable/disable are only set after the first station connection.
Without this patch, the firmware couldn't enable muru
if the first connected station is non-HE type.
Fixes: 16bff457dd33a ("mt76: mt7915: rework mt7915_mcu_sta_muru_tlv()") Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: MeiChia Chiu <meichia.chiu@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Chad Monroe [Sat, 12 Feb 2022 18:04:26 +0000 (10:04 -0800)]
mt76: connac: adjust wlan_idx size from u8 to u16
Newer chips such as MT7915 require up to 16-bits for this field.
Fixes: 49126ac1f8d26 ("mt76: connac: move mt76_connac_mcu_bss_basic_tlv in connac module") Signed-off-by: Chad Monroe <chad.monroe@smartrg.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Fri, 11 Feb 2022 17:14:00 +0000 (18:14 +0100)]
mt76: mt7915: fix endianness warnings in mt7915_mac_tx_free()
Fix the following sparse warning in mt7915_mac_tx_free routine:
warning: incorrect type in assignment (different base types)
expected unsigned int [usertype] *cur_info
got restricted __le32 *
warning: cast to restricted __le32
Fixes: c17780e7b21ec ("mt76: mt7915: add txfree event v3") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Fri, 11 Feb 2022 17:12:50 +0000 (18:12 +0100)]
mt76: mt7915: fix endianness warnings in mt7915_debugfs_rx_fw_monitor
Fix the following sparse warnings:
warning: incorrect type in initializer (different base types)
expected restricted __le16 [usertype] msg_type
got int
warning: incorrect type in assignment (different base types)
expected restricted __le32 [usertype] timestamp
got unsigned int
Fixes: 988845c9361a0 ("mt76: mt7915: add support for passing chip/firmware debug data to user space") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Deren Wu [Fri, 11 Feb 2022 02:54:55 +0000 (10:54 +0800)]
mt76: mt7615: fix compiler warning on frame size
The following error is see from the compiler:
mt7615/debugfs.c: In function ‘mt7615_ext_mac_addr_read’:
mt7615/debugfs.c:465:1: warning: the frame size of 1072 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
The issue is due to allocating a buffer as string storage.
Fix by converting to a dynamical allocation of the buffer.
Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Bo Jiao [Wed, 9 Feb 2022 06:11:57 +0000 (14:11 +0800)]
mt76: mt7915: introduce band_idx in mt7915_phy
The wfsys of MT7986 has only single adie chip for non-dbdc devices,
and it binds to band1 by default. Hence this patch adds band_idx to
explicitly configure phy accordingly.
Co-developed-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com> Co-developed-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Reviewed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Bo Jiao [Wed, 9 Feb 2022 06:11:56 +0000 (14:11 +0800)]
mt76: mt7915: add support for MT7986
This adds MT7986 SoC integrated multi-band 4x4 WiFi 6/6E.
Co-developed-by: Peter Chiu <chui-hao.chiu@mediatek.com> Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Co-developed-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by: Bo Jiao <Bo.Jiao@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
found in the function ath10k_htt_rx_amsdu_pop in the file htt_rx.c
i think the original author
(who is also the one who added rx_desc tracing capabilities
in a0883cf7e75a) just wanted to trace the rx_desc contents,
ignoring the fw_rx_desc_base info field
(which is the part being skipped over).
But the trace_ath10k_htt_rx_desc later added
don't care about skipping it, so it may be good
to uniform this call to the others in the file.
But this would change the output of the trace and
thus it may be a problem for tools that rely on it.
Therefore I propose until further discussion
to just keep it as it is and just fix the pointer arithmetic bug.
Add missing void* cast to rx descriptor pointer in order to
properly skip the initial 4 bytes of the rx descriptor
when passing it to trace_ath10k_htt_rx_desc trace function.
This fixes the pointer arithmetic error detected
by Dan Carpenter's static analysis tool.
Gustavo A. R. Silva [Wed, 16 Feb 2022 19:49:55 +0000 (13:49 -0600)]
carl9170: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
Venkateswara Naralasetty [Sun, 20 Feb 2022 14:07:39 +0000 (19:37 +0530)]
ath11k: add dbring debug support
Target copies spectral report and CFR report through dbring to
host for further processing. This mechanism involves ring and
buffer management in the Host, FW, and uCode, where improper
tail pointer update issues are seen.
This dbring debug support help to debug such issues by tracking
head and tail pointer movement along with the timestamp at which
each buffer is received and replenished.
Provide a debugfs interface to enalbe/disable dbring debug
support and dump the dbring debug entries.
Also introduced a new hardware param to add dbring debugfs support
for few hardwares which are using dbings.
Translate HE status to radiotap format. This uses HE radiotap
definitions from include/net/ieee80211_radiotap.h.
Co-developed-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217012112.31211-4-pradeepc@codeaurora.org
Add new bitmasks and macro definitions required for parsing HE
status tlvs. Decode HE status tlvs, which will used in dumping
ppdu stats as well as updating radiotap headers.
Co-developed-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217012112.31211-3-pradeepc@codeaurora.org
This allows us to pass HE rates down into the stack.
Co-developed-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: Miles Hu <milehu@codeaurora.org> Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220217012112.31211-2-pradeepc@codeaurora.org
Peter Chiu [Wed, 9 Feb 2022 06:11:55 +0000 (14:11 +0800)]
dt-bindings: net: wireless: mt76: document bindings for MT7986
Add an entry for MT7986 SoC.
Signed-off-by: Peter Chiu <chui-hao.chiu@mediatek.com> Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Deren Wu [Wed, 9 Feb 2022 01:40:27 +0000 (09:40 +0800)]
mt76: mt7921s: fix missing fc type/sub-type for 802.11 pkts
For non-mmio devices, should set fc values to proper txwi config
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support") Tested-by: Sean Wang <sean.wang@mediatek.com> Co-developed-by: Leon Yen <Leon.Yen@mediatek.com> Signed-off-by: Leon Yen <Leon.Yen@mediatek.com> Signed-off-by: Deren Wu <deren.wu@mediatek.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sun, 6 Feb 2022 18:53:23 +0000 (19:53 +0100)]
mt76: fix endianness errors in reverse_frag0_hdr_trans
Fix ht ctl field size in mt{7615,7915,7921}_reverse_frag0_hdr_trans.
Fix the following endianness warnings in mt{7615,7915,7921}_reverse_frag0_hdr_trans:
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: cast to restricted __le32
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:29: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: expected restricted __le16 [usertype] frame_control
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:417:27: got unsigned long
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: cast to restricted __le32
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:24: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: expected restricted __le16 [usertype] seq_ctrl
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:418:22: got unsigned long
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: cast to restricted __le32
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:20: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: expected restricted __le32 [usertype] qos_ctrl
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:419:18: got unsigned long
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: cast to restricted __le32
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:19: warning: restricted __le32 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: expected restricted __le32 [usertype] ht_ctrl
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:420:17: got unsigned long
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:25: warning: restricted __be16 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:448:38: warning: restricted __be16 degrades to integer
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: expected unsigned int [usertype] *cur_info
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1450:23: got restricted __le32 *
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1451:34: warning: cast to restricted __le32
Fixes: dc5399a50b45f ("mt76: reverse the first fragmented frame to 802.11") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Johan Almbladh [Fri, 4 Feb 2022 15:47:30 +0000 (16:47 +0100)]
mt76: mt7915: fix injected MPDU transmission to not use HW A-MSDU
Before, the hardware would be allowed to transmit injected 802.11 MPDUs
as A-MSDU. This resulted in corrupted frames being transmitted. Now,
injected MPDUs are transmitted as-is, without A-MSDU.
The fix was verified with frame injection on MT7915 hardware, both with
and without the injected frame being encrypted.
If the hardware cannot do A-MSDU aggregation on MPDUs, this problem
would also be present in the TX path where mac80211 does the 802.11
encapsulation. However, I have not observed any such problem when
disabling IEEE80211_HW_SUPPORTS_TX_ENCAP_OFFLOAD to force that mode.
Therefore this fix is isolated to injected frames only.
The same A-MSDU logic is also present in the mt7921 driver, so it is
likely that this fix should be applied there too. I do not have access
to mt7921 hardware so I have not been able to test that.
Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Ping-Ke Shih [Fri, 18 Feb 2022 03:55:27 +0000 (11:55 +0800)]
rtw88: change rtw_info() to proper message level
Larry reported funny log entries [1] when he used rtl8821ce. These
messages are not harmless, but not useful for users, so change them to
rtw_dbg() level. By the way, I review all rtw_info() and change others
to rtw_warn().
Zong-Zhe Yang [Fri, 18 Feb 2022 03:40:42 +0000 (11:40 +0800)]
rtw89: phy: handle txpwr lmt/lmt_ru of 160M bandwidth
Add handling to fill struct rtw89_txpwr_limit and rtw89_txpwr_limit_ru
for 160Mhz bandwidth case. And enlarge RTW89_5G_BW_NUM because the chip
under planning can support 160Mhz bandwidth on 5G band.
Moreover, refine the filling of OFDM entry of struct rtw89_txpwr_limit
by using the value corresponding to primary channel.
E.g. center channel 38 (40Mhz bandwidth case)
Originally OFDM entry was filled by value corresponding to 'ch - 2' (36)
Now, we consider that it could be 36 or 40.
E.g. cneter channel 42 (80Mhz bandwidth case)
Originally OFDM entry was filled by value corresponding to 'ch - 6' (36)
Now, we consider that it could be 36, 40, 44, or 48.
Zong-Zhe Yang [Fri, 18 Feb 2022 03:40:16 +0000 (11:40 +0800)]
rtw89: phy: handle txpwr lmt/lmt_ru of 6G band
Add declarations of 6G stuff and extend rtw89_channel_to_idx() to
map 6G's channels to 6G channel indexes. While 6G, correspondingly
read 6G's entry for tx power limit and limit_ru.
After this, we should pay attention to chip_info::support_bands.
If a chip declares 6G support, it must configure txpwr_lmt_6g and
txpwr_lmt_ru_6g in case accessing NULL pointer while setting tx power
limit/limit_ru on 6G band.
Kalle Valo [Tue, 22 Feb 2022 15:23:23 +0000 (17:23 +0200)]
Merge tag 'iwlwifi-next-for-kalle-2022-02-18' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
iwlwifi patches for v5.18
* Support UHB TAS enablement via BIOS;
* Remove a bunch of W=1 warnings;
* Add support for channel switch offload;
* Support a new FW API command version;
* Support 32 Rx AMPDU sessions in newer devices;
* Support a few new FW API command versions;
* Some debugging infra fixes;
* A few fixes in the HE functionality;
* Add a few new devices;
* A bunch of fixes for W=1 and W=3 warnings;
* Add support for a couple of new devices;
* Fix a potential buffer underflow;
* W=1 warnings clean up continues;
* Some improvements and fixes in scanning;
* More work on the Bz family of devices;
* Add support for band disablement via BIOS;
* Bump FW API version;
* Fix config structure for one device;
* Support a new FW API command version;
* Support new queue allocation command;
* Some more debugging improvements;
* Some other small fixes, clean-ups and improvements.
With above info the issue is clear: First wmi_mgmt_tx_work is inserted
to local->workqueue after sdata->work inserted, then wpa_supplicant
acquires wdev->mtx in nl80211_deauthenticate and finally calls
ath11k_mac_op_flush where it waits all mgmt. frames to be sent out by
wmi_mgmt_tx_work. Meanwhile, sdata->work is blocked by wdev->mtx in
ieee80211_sta_work, as a result wmi_mgmt_tx_work has no chance to run.
Change to use ab->workqueue instead of local->workqueue to fix this issue.
Seevalamuthu Mariappan [Thu, 17 Feb 2022 06:26:35 +0000 (11:56 +0530)]
ath11k: Handle failure in qmi firmware ready
In some scenarios like firmware crashes during init time
and hardware gets restarted after qmi firmware ready event.
During restart, ath11k_core_qmi_firmware_ready() returns timeout.
But, this failure is not handled and ATH11K_FLAG_REGISTERED is set.
When hardware restart completed, firmware sends firmware ready event
again. Since ATH11K_FLAG_REGISTERED is already set, ath11k handles
this as core restart. Inits are not done because of previous timeout.
But ath11k_core_restart does deinit's which causes NULL pointer crash.
Fix this by handling failure from ath11k_core_qmi_firmware_ready().
Rameshkumar Sundaram [Wed, 16 Feb 2022 08:32:34 +0000 (14:02 +0530)]
ath11k: Invalidate cached reo ring entry before accessing it
REO2SW ring descriptor is currently allocated in cacheable memory.
While reaping reo ring entries on second trial after updating head
pointer, first entry is not invalidated before accessing it.
This results in host reaping and using cached descriptor which is
already overwritten in memory by DMA device (HW).
Since the contents of descriptor(buffer id, peer info and other information
bits) are outdated host throws errors like below while parsing corresponding
MSDU's and drops them.
[347712.048904] ath11k_pci 0004:01:00.0: msdu_done bit in attention is not set
[349173.355503] ath11k_pci 0004:01:00.0: frame rx with invalid buf_id 962
Move the try_again: label above ath11k_hal_srng_access_begin()
so that first entry will be invalidated and prefetched.
Gustavo A. R. Silva [Wed, 16 Feb 2022 19:49:15 +0000 (13:49 -0600)]
ath: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
Gustavo A. R. Silva [Wed, 16 Feb 2022 19:48:57 +0000 (13:48 -0600)]
ath6kl: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
Gustavo A. R. Silva [Wed, 16 Feb 2022 19:48:36 +0000 (13:48 -0600)]
ath11k: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
Gustavo A. R. Silva [Wed, 16 Feb 2022 19:48:07 +0000 (13:48 -0600)]
ath10k: Replace zero-length array with flexible-array member
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
Jason A. Donenfeld [Wed, 16 Feb 2022 11:33:23 +0000 (12:33 +0100)]
ath9k: use hw_random API instead of directly dumping into random.c
Hardware random number generators are supposed to use the hw_random
framework. This commit turns ath9k's kthread-based design into a proper
hw_random driver.
Cc: Toke Høiland-Jørgensen <toke@redhat.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: Rui Salvaterra <rsalvaterra@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Tested-by: Rui Salvaterra <rsalvaterra@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/20220216113323.53332-1-Jason@zx2c4.com
Carl Huang [Mon, 14 Feb 2022 17:53:16 +0000 (19:53 +0200)]
ath11k: fix invalid m3 buffer address
This is to fix m3 buffer reuse issue as m3_mem->size isn't set to
ZERO in free function, which leads invalid m3 downloading to
firmware and firmware crashed.
Gustavo A. R. Silva [Wed, 16 Feb 2022 19:50:47 +0000 (13:50 -0600)]
rtw89: core.h: Replace zero-length array with flexible-array member
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
Gustavo A. R. Silva [Wed, 16 Feb 2022 19:49:35 +0000 (13:49 -0600)]
brcmfmac: Replace zero-length arrays with flexible-array members
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use “flexible array members”[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].
Tom Rix [Sun, 13 Feb 2022 21:31:21 +0000 (13:31 -0800)]
bcma: cleanup comments
Remove the second 'info'.
Replacements
'adventages' with 'advantages'
'strenth' with 'strength'
'atleast' with 'at least'
'thr'u'' with 'through'
'capabilty' with 'capability'
'controll' with 'control'
'ourself' with 'ourselves'
'noone' with 'no one'
'cores' to 'core's' and 'core'
Jiri Kosina [Tue, 15 Feb 2022 19:37:51 +0000 (20:37 +0100)]
rtw89: fix RCU usage in rtw89_core_txq_push()
ieee80211_tx_h_select_key() is performing a series of RCU dereferences,
but rtw89_core_txq_push() is calling it (via ieee80211_tx_dequeue_ni())
without RCU read-side lock held; fix that.
This addresses the splat below.
=============================
WARNING: suspicious RCU usage 5.17.0-rc4-00003-gccad664b7f14 #3 Tainted: G E
-----------------------------
net/mac80211/tx.c:593 suspicious rcu_dereference_check() usage!
Ching-Te Ku [Tue, 15 Feb 2022 00:48:53 +0000 (08:48 +0800)]
rtw88: coex: Add WLAN MIMO power saving for Bluetooth gaming controller
To keep high sensitivity reaction, Bluetooth gaming controller will send
packet very frequently, it will make WLAN performance very poor. To solve
this situation, MIMO PS mechanism makes WLAN/BT own an antenna itself, WLAN
quits 2SS performance but it can get a stable 1SS performance and Bluetooth
gaming controller can keep sensitivity reaction at the same time.
Chin-Yen Lee [Tue, 15 Feb 2022 00:48:50 +0000 (08:48 +0800)]
rtw88: 8822ce: add support for TX/RX 1ss mode
In some case, wifi chip need to be configed to be TX/RX 1ss mode.
For this mode, wifi components, such as MAC/BB/RF, need to be
specially set, and driver need to send SMPS action frame to inform AP.
iwlwifi: dbg_ini: Split memcpy() to avoid multi-field write
To avoid a run-time false positive in the stricter FORTIFY_SOURCE
memcpy() checks, split the memcpy() into the struct and the data.
Additionally switch the data member to a flexible array to follow
modern language conventions.
Dan Carpenter [Mon, 16 Aug 2021 18:39:30 +0000 (21:39 +0300)]
iwlwifi: mvm: Fix an error code in iwl_mvm_up()
Return -ENODEV instead of success on this error path.
Fixes: dd36a507c806 ("iwlwifi: mvm: look for the first supported channel when add/remove phy ctxt") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20210816183930.GA2068@kili Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Colin Ian King [Tue, 7 Sep 2021 10:46:58 +0000 (11:46 +0100)]
iwlwifi: Fix -EIO error code that is never returned
Currently the error -EIO is being assinged to variable ret when
the READY_BIT is not set but the function iwlagn_mac_start returns
0 rather than ret. Fix this by returning ret instead of 0.
Addresses-Coverity: ("Unused value") Fixes: 7335613ae27a ("iwlwifi: move all mac80211 related functions to one place") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210907104658.14706-1-colin.king@canonical.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Miri Korenblit [Thu, 10 Feb 2022 16:22:33 +0000 (18:22 +0200)]
iwlwifi: mvm: move only to an enabled channel
During disassociation we're decreasing the phy's ref count.
If the ref count becomes 0, we're configuring the phy ctxt
to the default channel (the lowest channel which the device
can operate on). Currently we're not checking whether the
the default channel is enabled or not. Fix it by configuring
the phy ctxt to the lowest channel which is enabled.
Johannes Berg [Thu, 10 Feb 2022 16:22:32 +0000 (18:22 +0200)]
iwlwifi: mvm: update BAID allocation command again
Due to some issues found in integration, the command now has
the (old) station mask and TID in modify/remove instead of
the BAID, adjust accordingly.
Since we don't use modify yet (and never will with v1 of the
API), just add v1 remove inside the existing union, and use
that, this way we don't have to duplicate everything, only
the remove code.
Johannes Berg [Thu, 10 Feb 2022 16:22:30 +0000 (18:22 +0200)]
iwlwifi: support new queue allocation command
Newer firmware versions will support a new queue allocation
command, in order to deal with MLD where multiple stations
are used for a single queue. Add support for the new command.
This requires some refactoring of the queue allocation API,
which now gets
- the station mask instead of the station ID
- the flags without the "enable" flag, since that's no longer
used in the new API
Additionally, this new API now requires that we remove queues
before removing a station, the firmware will no longer do that
internally. Also add support for that.
Mukesh Sisodiya [Thu, 10 Feb 2022 16:22:29 +0000 (18:22 +0200)]
iwlwifi: yoyo: support dump policy for the dump size
Support dump size limitation based on the TLV by firmware.
This is needed for limited memory systems so only the most
important dumps are sent by driver.
Johannes Berg [Thu, 10 Feb 2022 16:22:25 +0000 (18:22 +0200)]
iwlwifi: remove command ID argument from queue allocation
The command ID here is always hard-coded to the same, so we
can remove it. In the future we actually need to make this
configurable, but that doesn't need to be on each call, it
can be done through the transport configuration.
projects / users / dwmw2 / linux.git / log