| Age | Commit message (Collapse) | Author |
|---|
|
A recent refactoring was identified by static analysis to
cause a potential NULL dereference, fix this!
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202410121505.nyghqEkK-lkp@intel.com/
Fixes: 2719a9e7156c ("wifi: cw1200: Convert to GPIO descriptors")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241028-cw1200-fix-v1-1-e092b6558d1e@linaro.org
|
|
dma_fxflush() has been unused since 2013's
commit 7b2385b95363 ("brcmsmac: rework of mac80211 .flush() callback
operation")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241025204651.244627-1-linux@treblig.org
|
|
The wfx_core_init() returns without checking the retval from
sdio_register_driver().
If the sdio_register_driver() failed, the module failed to install,
leaving the wfx_spi_driver not unregistered.
Fixes: a7a91ca5a23d ("staging: wfx: add infrastructure for new driver")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241022090453.84679-1-yuancan@huawei.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
ath.git patches for v6.13
This development cycle featured phase 1 of patches to ath12k to
support the new 802.11be MLO feature, along with other ath12k feature
patches. In older drivers, support for some additional devices were
added. And there was the usual set of bug fixes and cleanups across
most drivers.
Per-driver highlights:
ath12k
* Switch to using wiphy_lock() and remove ar->conf_mutex
* Convert struct ath12k_sta::update_wk to use struct wiphy_work
* Add phase 1 of 802.11be MLO support
* Add firmware coredump collection support
* Add debugfs support for a multitude of statistics
* Fix host representation of multiple hal_rx structs
* Fix use-after-free in ath12k_dp_cc_cleanup()
* Skip Rx TID cleanup for self peer
* Fix warning and crash when unloading in a VM
* Convert CE interrupt handling from tasklet to BH workqueue
* Fix A-MSDU indication in monitor mode
ath11k
* Fix double free issue during SRNG deinit
* Enable firmware diagnostic events for WCN6750
* Fix CE offset address calculation for WCN6750 during SSR
* Fix stack frame size warning in ath11k_vif_wow_set_wakeups()
* Document the inputs for ath11k on WCN6855
ath10k
* Fix multiple stack frame size warnings
* Fix invalid VHT parameters in supported_vht_mcs_rate_nss* structs
* Avoid NULL pointer error during SDIO remove
ath5k
* Add support for Arcadyan ARV45XX AR2417 & Gigaset SX76[23] AR241[34]A
|
|
pcim_iomap_table() and pcim_iomap_regions_request_all() have been
deprecated by the PCI subsystem in commit e354bb84a4c1 ("PCI: Deprecate
pcim_iomap_table(), pcim_iomap_regions_request_all()").
Replace these functions with their successors, pcim_iomap() and
pcim_request_all_regions().
Link: https://lore.kernel.org/r/20241030112743.104395-7-pstanner@redhat.com
Signed-off-by: Philipp Stanner <pstanner@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Kalle Valo <kvalo@kernel.org>
|
|
The RTL8812AU has a reception problem, maybe only in the 5 GHz band.
Sometimes, in some positions, it stops receiving anything even though
the distance to the AP is only ~3 meters and there are no obstacles.
Moving it a few centimeters fixes it.
Switch the initial gain to maximum coverage when there is beacon loss.
This only helps sometimes. This is similar to what the official driver
does.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/203f5043-4fe1-4f35-8b8f-d3b6f44e1fd9@gmail.com
|
|
The RTL8821AU firmware sends C2H_BT_INFO by itself when bluetooth
headphones are connected, but not when they are disconnected. This leads
to the coexistence code still using the A2DP algorithm long after the
headphones are disconnected, which means the wifi speeds are much lower
than they should be. Work around this by asking for updates every two
seconds if the chip is RTL8821AU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/358acdd2-6aae-46c1-9c66-fcce4e700b96@gmail.com
|
|
All the chips currently supported have a "scoreboard": the chip keeps
track of certain things related to bluetooth, for example, whether
bluetooth is active. The information can be read from register 0xaa.
RTL8821AU doesn't have this. Implement bluetooth activity detection in
rtw_coex_monitor_bt_enable() based on the bluetooth TX/RX counters.
This is mostly important for RTL8811AU, the version of RTL8821AU without
bluetooth. Without this change, the driver thinks bluetooth is active
and the wifi speeds are low.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/5058f23d-2086-42cd-82ad-eef31a348467@gmail.com
|
|
The driver is supposed to avoid entering LPS (power saving) when there
is beacon loss, but only RTL8822C detects the beacon loss (because it
has beacon filtering in the firmware).
Detect beacon loss with the other chips by checking if we received less
than half the expected number of beacons in the last 2-second interval.
This gets rid of the occasional "failed to get tx report from firmware"
warnings with RTL8821AU. It may also avoid some disconnections.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f52b2fcf-bf94-48bc-89bd-e55ebc3a2f2d@gmail.com
|
|
"ls" meaning "last segment". Without this RTL8812AU can't upload the
reserved page in USB 2 mode. (Somehow it's fine in USB 3 mode.)
Also tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8723DU, RTL8811AU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/e443f5d9-4b53-4f64-985c-64313ec80bef@gmail.com
|
|
RTL8812AU uses one set of TX power tracking tables for RFE 3, and
another set for everything else.
Move pwr_track_tbl from struct rtw_chip_info to struct rtw_rfe_def in
order to load the right set of tables for each RFE (RF front end) type.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/904d0ab1-c046-40cd-a3a3-d4fdcf663c9d@gmail.com
|
|
All the chips supported so far have a TX page size of 128 bytes.
Change the type of the page_size member of struct rtw_chip_info from u8
to u16 in order to support RTL8821AU (page size of 256 bytes) and
RTL8812AU (page size of 512 bytes). Also change the types of several
related variables and function parameters from u8 to u16.
The TX page size is used, among other things, to construct the beacon,
null data, QOS null data, and PS poll templates which are uploaded to
the chip's reserved page. Each template needs to be aligned on a
multiple of the TX page size. Power saving can't work if the TX page
size is wrong.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/acdefbb1-3daf-4349-9e03-9472754d5f1e@gmail.com
|
|
txagc_remnant_ofdm member of struct rtw_dm_info should be different for
each RF path, so make it an array of size RTW_RF_PATH_MAX (4).
Until now all the chips using this had only one RF path, but RTL8812AU
has two, and RTL8814AU has four.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/68571ba9-e504-4b2d-bfa1-62f468753649@gmail.com
|
|
RTL8811AU fails to perform the 4-way handshake when the AP is too far
because it transmits the EAPOL frames at MCS9 and when that doesn't
work it retries 48 times with the same rate, to no avail.
Retrying 48 times with the same rate seems pointless. Set the
appropriate field in the TX descriptor to allow it to use lower rates
when retrying.
Set it for RTL8723D and RTL8703B because they interpret this field the
same way as RTL8811A.
The newer RTL8822C, RTL8822B, RTL8821C seem to interpret this field in
the TX descriptor differently, so leave it alone for those chips.
Tested with RTL8811AU and RTL8723DU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/2b3e3e6f-541b-4a3b-8ca3-65b267e6a95a@gmail.com
|
|
RTL8821AU and RTL8812AU have to do some things differently, so let
them have full control.
The other chips use the same functions as before.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com
|
|
RTL8821A doesn't have this. Trying to use it results in error messages,
so don't try if ltecoex_addr is NULL.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/d1004817-1760-41d1-9136-3d799757c444@gmail.com
|
|
The chips supported so far only use the first condition, and so the
parsing code ignores the second condition. RTL8812AU's init tables use
the second condition also. Make the parsing code check it.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/1bee6b74-6eab-44a3-9f40-794ca006c72d@gmail.com
|
|
The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes.
Avoid the "invalid ra report c2h length" error.
Also, use a struct and u8_get_bits() to access the RA report C2H.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com
|
|
RTL8821AU and RTL8812AU don't support this. They hit the "failed to read
hw feature report" error.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/8becd851-8760-4480-8e8c-c4869ce72507@gmail.com
|
|
Add 8821A and 8812A chip type enums.
Add cck_high_power member to struct rtw_hal. This will be used to
calculate the RX signal strength of RTL8812AU.
Add various register definitions which will be used by the new drivers.
Move some existing register definitions from rtw8821c.h and rtw8822b.h.
They were duplicated in those headers and will also be used by the new
drivers.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/9279a9cd-6f86-4dc3-a095-7c36cb9b9d06@gmail.com
|
|
RTL8811CU doesn't report the signal strength for many (any?) data
frames. When the signal strength is not known, set
RX_FLAG_NO_SIGNAL_VAL in order to avoid reporting a signal
strength of 0.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/f7e1e448-2c9b-498f-b8b1-a14dd967d7d3@gmail.com
|
|
Extend FW and driver handling on RFK to support it on both HW bands.
Then, according to MLO cases, do the corresponding RF settings.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-6-pkshih@realtek.com
|
|
Setting of channel and TX power depend on channel contexts, but original
code cannot handle combination of MCC (multi-channel concurrency) and MLO
well. So according to active interfaces, we generate a table for current
channel contexts. And then based on entity mode, we get the corresponding
channel context to apply during channel or TX power setting. When MLO is
supported, there will be dual-PHY and we will apply the channel context of
the 2nd link to the 2nd PHY.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-5-pkshih@realtek.com
|
|
To set channel well for combination of MCC (multi-channel concurrency) and
impending MLO support, we need a method to manage relation between active
interfaces and channel contexts. If an interface owns at least one active
link, we call it an active interface. We add a list to manage active ones.
Basically, the list follows the active order except for the below case. To
be compatible with legacy behavior, the first interface that owns the first
channel context will put at the first entry in the list when recalculating.
Besides, MCC can also select and fill roles based on the above active list.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-4-pkshih@realtek.com
|
|
In order to make encryption/decryption work properly with MLO
connections, MLD address needs to be filled in so circuits can
operate with the correct information.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-3-pkshih@realtek.com
|
|
For MLO connections, this setting replaces 802.11 header addresses
to according link addresses based on each packet's destination.
The fields most likely to be replaced would be both A1 and A2.
For legacy connections, it's the same with or without the conversion.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241022083106.149252-2-pkshih@realtek.com
|
|
Currently in Ath12k, tasklet is used to handle the BH context of CE
interrupts. However the tasklet is marked deprecated and has some
design flaws. To replace tasklets, BH workqueue support has been
added. BH workqueue behaves similarly to regular workqueues except
that the queued work items are executed in the BH context.
Hence, convert the tasklet to BH workqueue for handling CE interrupts
in the BH context.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com>
Acked-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241022072406.3231450-1-quic_rajkbhag@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
|
|
If more than 255 colocated APs exist for the set of all
APs found during 2.4/5 GHz scanning, then the 6 GHz scan
construction will loop forever since the loop variable
has type u8, which can never reach the number found when
that's bigger than 255, and is stored in a u32 variable.
Also move it into the loops to have a smaller scope.
Using a u32 there is fine, we limit the number of APs in
the scan list and each has a limit on the number of RNR
entries due to the frame size. With a limit of 1000 scan
results, a frame size upper bound of 4096 (really it's
more like ~2300) and a TBTT entry size of at least 11,
we get an upper bound for the number of ~372k, well in
the bounds of a u32.
Cc: stable@vger.kernel.org
Fixes: eae94cf82d74 ("iwlwifi: mvm: add support for 6GHz")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219375
Link: https://patch.msgid.link/20241023091744.f4baed5c08a1.I8b417148bbc8c5d11c101e1b8f5bf372e17bf2a7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Revert commit dfdfe4be183b ("wifi: iwlwifi: remove retry loops in
start"), it turns out that there's an issue with the PNVM load
notification from firmware not getting processed, that this patch
has been somewhat successfully papering over. Since this is being
reported, revert the loop removal for now.
We will later at least clean this up to only attempt to retry if
there was a timeout, but currently we don't even bubble up the
failure reason to the correct layer, only returning NULL.
Fixes: dfdfe4be183b ("wifi: iwlwifi: remove retry loops in start")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20241022092212.4aa82a558a00.Ibdeff9c8f0d608bc97fc42024392ae763b6937b7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When we add the vif (and its default link) in fw restart we may
override the link that already exists. We take care of this but if
link 0 is a valid MLO link, then we will re-create a default link on
mvmvif->link[0] and we'll loose the real link we had there.
In non-MLO, we need to re-create the default link upon the interface
creation, this is fine. In MLO, we'll just wait for change_vif_links()
to re-build the links.
Fixes: bf976c814c86 ("wifi: iwlwifi: mvm: implement link change ops")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241010140328.385bfea1b2e9.I4a127312285ccb529cc95cc4edf6fbe1e0a136ad@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
1. The size of the response packet is not validated.
2. The response buffer is not freed.
Resolve these issues by switching to iwl_mvm_send_cmd_status(),
which handles both size validation and frees the buffer.
Fixes: f130bb75d881 ("iwlwifi: add FW recovery flow")
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241010140328.76c73185951e.Id3b6ca82ced2081f5ee4f33c997491d0ebda83f7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
SAR table format in ACPI and local data base are different,
So modified code to read data properly.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241010140328.f077aced4dee.I4dc618f12d01f7ad19f9f8881f6e09eea77e9a14@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When starting the suspend flow, HOST_D3_START triggers an _async_
firmware dump collection for debugging purposes. The async worker
may race with suspend flow and fail to get NIC access, resulting in
the following warning:
"Timeout waiting for hardware access (CSR_GP_CNTRL 0xffffffff)"
Fix this by switching to the sync version to ensure the dump
completes before proceeding with the suspend flow, avoiding
potential race issues.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241010140328.9aae318cd593.I4b322009f39489c0b1d8893495c887870f73ed9c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
iwl_mvm_send_ap_tx_power_constraint_cmd is a no-op if the link is not
active (we need to know the band etc.)
However, for the station case it will be called just before we set the
link to active (by calling iwl_mvm_link_changed with
the LINK_CONTEXT_MODIFY_ACTIVE bit set in the 'changed' flags and
active = true), so it will end up doing nothing.
Fix this by calling iwl_mvm_send_ap_tx_power_constraint_cmd before
iwl_mvm_link_changed.
Fixes: 6b82f4e119d1 ("wifi: iwlwifi: mvm: handle TPE advertised by AP")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241010140328.5c235fccd3f1.I2d40dea21e5547eba458565edcb4c354d094d82a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Release the link mapping resource in AP removal. This impacted devices
that do not support the MLD API (9260 and down).
On those devices, we couldn't start the AP again after the AP has been
already started and stopped.
Fixes: a8b5d4809b50 ("wifi: iwlwifi: mvm: Configure the link mapping for non-MLD FW")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241010140328.c54c42779882.Ied79e0d6244dc5a372e8b6ffa8ee9c6e1379ec1d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
wireless fixes for v6.12-rc5
The first set of wireless fixes for v6.12. We have been busy and have
not been able to send this earlier, so there are more fixes than
usual. The fixes are all over, both in stack and in drivers, but
nothing special really standing out.
|
|
We need to call mutex_unlock() on this error path.
Fixes: aad0394e7a02 ("wifi: rtw89: tweak driver architecture for impending MLO support")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/8683a712-ffc2-466b-8382-0b264719f8ef@stanley.mountain
|
|
There might be some racing between BT and WiFi after scan. Since
one of the TX related register will be modified by both FW and
rtw89_set_channel() in driver, which could cause Tx fail. Reorder
the calling sequence to only notify coexistence mechanism after
rtw89_set_channel() is called, so that there are no concurrent
operations.
Fixes: 5f499ce69b8d ("wifi: rtw89: pause/proceed MCC for ROC and HW scan")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241021063219.22613-1-pkshih@realtek.com
|
|
The priority table should be changed according to what the in using
Bluetooth application is. To avoid Bluetooth audio + HID (mouse) will
trigger the lag experience, update the priority table.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241019063131.9462-1-pkshih@realtek.com
|
|
This is one of three drivers that trigger -Wenum-compare-conditional warnings
with clang:
drivers/net/wireless/realtek/rtw89/core.c:1806:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1806 | return eht ? NL80211_RATE_INFO_EHT_GI_0_8 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1807 | NL80211_RATE_INFO_HE_GI_0_8;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1810:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1810 | return eht ? NL80211_RATE_INFO_EHT_GI_1_6 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1811 | NL80211_RATE_INFO_HE_GI_1_6;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1813:14: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1813 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1814 | NL80211_RATE_INFO_HE_GI_3_2;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/core.c:1818:15: error: conditional expression between different enumeration types ('enum nl80211_eht_gi' and 'enum nl80211_he_gi') [-Werror,-Wenum-compare-conditional]
1818 | return eht ? NL80211_RATE_INFO_EHT_GI_3_2 :
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1819 | NL80211_RATE_INFO_HE_GI_3_2;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this case, all four warnings can be easily avoided by splitting the
function into two separate ones, in a way that helps readability as well,
at the expense of a few extra source lines.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241018152311.4023979-1-arnd@kernel.org
|
|
Some used firmware are missing to be added to MODULE_FIRMWARE().
Add them accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241018055651.21166-1-pkshih@realtek.com
|
|
The previous implementation included an unnecessary else
condition paired with a continue statement. Since a check
is already performed to determine if the band is either
2G or 5G, the else condition will never be triggered.
We can remove this check.
Signed-off-by: Mohammed Anees <pvmohammedanees2003@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241017080638.13074-1-pvmohammedanees2003@gmail.com
|
|
If 6 GHz of a country is marked as N/A in our regd map,
we block 6 GHz channels now.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016134457.9375-1-pkshih@realtek.com
|
|
Specific PCI subsystem ID (SSID) of WiFi cards is used by specific
customer who want to enable various features with different arguments.
Define PCI SSID quirks tables to enable thermal protection with two kinds
of thermal values for 110 and 120 degree Celsius.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016133735.7571-3-pkshih@realtek.com
|
|
To prevent chip overheating, reduce TX duty as the mechanism of thermal
protection. When temperature is raising over a threshold, send a firmware
command to reduce TX duty. If temperature is still raising, higher level
is adopted to have lower active duration.
The equation and unit of thermal values are different from chip to chip,
so define constant thresholds of thermal value to corresponding absolute
temperature of 110 and 120 degree Celsius.
Latter patch will decide which thermal threshold is adopted, and current
is still not enable thermal protection.
For debugging, add a flag to disable_dm that thermal protection can be
disabled to clarify low throughput in field.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241016133735.7571-2-pkshih@realtek.com
|
|
In monitor mode, host will reap MSDUs and then the MSDUs with same PPDU
ID will be aggregated into an A-MSDU in ath12k_dp_mon_rx_merg_msdus().
However, ath12k_dp_mon_rx_merg_msdus() doesn't calculate the total
length of the A-MSDU. This causes Wireshark to display the A-MSDU
incorrectly.
Therefore, need to add calculation of the A-MSDU length.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: Kang Yang <quic_kangyang@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/20241022110831.974-9-quic_kangyang@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
|
|
When receiving a packet in monitor mode, hardware will fill status
information msdu_end for MSDUs. Then host can use these status
information to get specific information about this packet, such as
l3 offset, bandwidth, mcs, packet type.
If this packet is composed of multiple MSDUs, then hardware will only
fill status information for the last(tail) MSDU. At this time,
MSDU information is uncertain for others MSDUs. But current code use
the first MSDU in monitor mode, so will get the wrong information.
Fix it by getting msdu information from last(tail) msdu.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: Kang Yang <quic_kangyang@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/20241022110831.974-8-quic_kangyang@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
|
|
ath12k_mac_monitor_vdev_create() will set NSS and TX power to
firmware for monitor vdev.
But firmware doesn't need them for monitor mode.
So delete them as a cleanup.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Signed-off-by: Kang Yang <quic_kangyang@quicinc.com>
Link: https://patch.msgid.link/20241022110831.974-7-quic_kangyang@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
|
|
Current struct hal_rx_mpdu_start in hal_rx.h is not matched with
hardware descriptor definition. This hardware descriptor definition
is determined by hardware. Host shall follow it.
So update struct hal_rx_mpdu_start and related code.
Both QCN9274 and WCN7850 need this modification.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1
Signed-off-by: Kang Yang <quic_kangyang@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/20241022110831.974-6-quic_kangyang@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
|
|
Current struct hal_rx_phyrx_rssi_legacy_info in hal_rx.h is not matched
with hardware descriptor definition. This hardware descriptor definition
is determined by hardware. Host shall follow it.
So update struct hal_rx_phyrx_rssi_legacy_info and related code.
Both QCN9274 and WCN7850 need this modification.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00210-QCAHKSWPL_SILICONZ-1
Signed-off-by: Kang Yang <quic_kangyang@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://patch.msgid.link/20241022110831.974-5-quic_kangyang@quicinc.com
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
|
