It's easier to use and understand, and to extend for EHT later,
if we use the values here instead of the shifted values.
Unfortunately, we need to add _POS so that we can use it in
places like iwlwifi/mvm where constants are needed.
While at it, fix the typo ("NOMIMAL") which also helps catch any
conflicts.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://lore.kernel.org/r/20211126104817.7c29a05b8eb5.I2ca9faf06e177e3035bec91e2ae53c2f91d41774@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove unused variables to avoid the below warnings:
drivers/net/wireless/microchip/wilc1000/wlan.c: In function 'chip_wakeup':
>> drivers/net/wireless/microchip/wilc1000/wlan.c:620:34: warning: variable 'to_host_from_fw_bit' set but not used [-Wunused-but-set-variable]
620 | u32 to_host_from_fw_reg, to_host_from_fw_bit;
| ^~~~~~~~~~~~~~~~~~~
>> drivers/net/wireless/microchip/wilc1000/wlan.c:620:13: warning: variable 'to_host_from_fw_reg' set but not used [-Wunused-but-set-variable]
620 | u32 to_host_from_fw_reg, to_host_from_fw_bit;
| ^~~~~~~~~~~~~~~~~~~
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ajay Singh <ajay.kathat@microchip.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211115102809.1408267-1-ajay.kathat@microchip.com
Read the rfkill state upon boot, mac start and mac stop.
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-6-emmanuel.grumbach@intel.com
Add the vendor commands that must be used by the network manager
to allow proper operation of iwlmei.
* Send information on the AP CSME is connected to
* Notify the userspace when roaming is forbidden
* Allow the userspace to require ownership
Co-Developed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
v6: remove the VENDOR_CMDS Kconfig option and make the whole infra
depend on IWLMEI directly
v7: remove // comments
remove an unneeded function
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-5-emmanuel.grumbach@intel.com
iwlmei needs to know about the follwing events:
* Association
* De-association
* Country Code change
* SW Rfkill change
* SAR table changes
iwlmei can take the device away from us, so report the new
rfkill type when this happens.
Advertise the required data from the CSME firmware to the
usersapce: mostly, the AP that the CSME firmware is currently
associated to in case there is an active link protection
session.
Generate the HOST_ASSOC / HOST_DISSASSOC messages.
Don't support WPA1 (non-RSNA) for now.
Don't support shared wep either.
We can then determine the AUTH parameter by checking the AKM.
Feed the cipher from the key installation.
SW Rfkill will be implemented later when cfg80211 will
allow us to read the SW Rfkill state.
Co-Developed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
v7: Ayala added her signed-off
remove pointless function declaration
fix a bug due to merge conflict in the HOST_ASSOC message
v8: leave a print if we have a SAP connection on a device we do
not support (yet)
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-4-emmanuel.grumbach@intel.com
Add three debugfs hooks:
* status: Check if we have a connection with the CSME
firwmare. This hook is a read only.
* req_ownership: Send a SAP command to request ownership. This
flow should be triggered by iwlwifi (from user space through
vendor commands really), but being able to trigger an ownership
request from debugfs allows us to request ownership without
connecting afterwards. This is an "error" flow that the CSME
firmware is designed to handle this way:
+ Grant ownership since the host asked for it
+ Wait 3 seconds to let the host connect
+ If the host didn't connect, take the device back (forcefully).
+ Don't grant any new ownership request in the following 30
seconds.
This debugfs hook allows us to test this flow.
* send_start_message: Restart the communication with the CSME
firmware from the very beginning. At the very beginning (upon
iwlwifi start), iwlmei send a special message: SAP_ME_MSG_START.
This hook allows to send it again and this will retrigger the
whole flow. It is important to test this restart in the middle
of normal operation since it can happen (in case the CSME
firmware decided to reset for example).
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-3-emmanuel.grumbach@intel.com
CSME in two words
-----------------
CSME stands for Converged Security and Management Engine. It is
a CPU on the chipset and runs a dedicated firmware.
AMT (Active Management Technology) is one of the applications
that run on that CPU. AMT allows to control the platform remotely.
Here is a partial list of the use cases:
* View the screen of the plaform, with keyboard and mouse (KVM)
* Attach a remote IDE device
* Have a serial console to the device
* Query the state of the platform
* Reset / shut down / boot the platform
Networking in CSME
------------------
For those uses cases, CSME's firmware has an embedded network
stack and is able to use the network devices of the system: LAN
and WLAN. This is thanks to the CSME's firmware WLAN driver.
One can add a profile (SSID / key / certificate) to the CSME's OS
and CSME will connect to that profile. Then, one can use the WLAN
link to access the applications that run on CSME (AMT is one of
them). Note that CSME is active during power state and power state
transitions. For example, it is possible to have a KVM session
open to the system while the system is rebooting and actually
configure the BIOS remotely over WLAN thanks to AMT.
How all this is related to Linux
--------------------------------
In Linux, there is a driver that allows the OS to talk to the
CSME firmware, this driver is drivers/misc/mei. This driver
advertises a bus that allows other kernel drivers or even user
space) to talk to components inside the CSME firmware.
In practice, the system advertises a PCI device that allows
to send / receive data to / from the CSME firmware. The mei
bus drivers in drivers/misc/mei is an abstration on top of
this PCI device.
The driver being added here is called iwlmei and talks to the
WLAN driver inside the CSME firmware through the mei bus driver.
Note that the mei bus driver only gives bus services, it doesn't
define the content of the communication.
Why do we need this driver?
--------------------------
CSME uses the same WLAN device that the OS is expecting to see
hence we need an arbitration mechanism. This is what iwlmei is
in charge of. iwlmei maintains the communication with the CSME
firmware's WLAN driver. The language / protocol that is used
between the CSME's firmware WLAN driver and iwlmei is OS agnostic
and is called SAP which stands for Software Abritration Protocol.
With SAP, iwlmei will be able to tell the CSME firmware's WLAN
driver:
1) Please give me the device.
2) Please note that the SW/HW rfkill state change.
3) Please note that I am now associated to X.
4) Please note that I received this packet.
etc...
There are messages that go the opposite direction as well:
1) Please note that AMT is en/disable.
2) Please note that I believe the OS is broken and hence I'll take
the device *now*, whether you like it or not, to make sure that
connectivity is preserved.
3) Please note that I am willing to give the device if the OS
needs it.
4) Please give me any packet that is sent on UDP / TCP on IP address
XX.XX.XX.XX and an port ZZ.
5) Please send this packet.
etc...
Please check drivers/net/wireless/intel/iwlwifi/mei/sap.h for the
full protocol specification.
Arbitration is not the only purpose of iwlmei and SAP. SAP also
allows to maintain the AMT's functionality even when the OS owns
the device. To connect to AMT, one needs to initiate an HTTP
connection to port 16992. iwlmei will listen to the Rx path and
forward (through SAP) to the CSME firmware the data it got. Then,
the embedded HTTP server in the chipset will reply to the request
and send a SAP notification to ask iwlmei to send the reply.
This way, AMT running on the CSME can still work.
In practice this means that all the use cases quoted above (KVM,
remote IDE device, etc...) will work even when the OS uses the
WLAN device.
How to disable all this?
---------------------------
iwlmei won't be able to do anything if the CSME's networking stack
is not enabled. By default, CSME's networking stack is disabled (this
is a BIOS setting).
In case the CSME's networking stack is disabled, iwlwifi will just
get access to the device because there is no contention with any other
actor and, hence, no arbitration is needed.
In this patch, I only add the iwlmei driver. Integration with
iwlwifi will be implemented in the next one.
Co-Developed-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
v2: fix a few warnings raised by the different bots
v3: rewrite the commit message
v4: put the debugfs content in a different patch
v5: fix a NULL pointer dereference upon DHCP TX if SAP is connected
since we now have the required cfg80211 bits in wl-drv-next, add
the RFKILL handling patch to this series.
v6: change the SAP API to inherit the values from iwl-mei.h removing
the need to ensure the values are equal with a BUILD_BUG_ON.
This was suggested by Arend
v7: * fix a locking issue in case of CSME firmware reset:
When the CSME firmware resets, we need to unregister the
netdev, first take the mutex, and only then, rely on it
being taken.
* Add a comment to explain why it is ok to have static variables
(iwlmei can't have more than a single instance).
* Add a define for 26 + 8 + 8
* Add a define SEND_SAP_MAX_WAIT_ITERATION
* make struct const
* Reword a bit the Kconfig help message
* Ayala added her Signed-off
* fixed an RCU annotation
v8: do not require ownership upfront, use NIC_OWNER instead. This fixes
a deadlock when CSME does not have the right WiFi FW.
Add more documentation about the owernship transition
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211112062814.7502-2-emmanuel.grumbach@intel.com
The firmware of the 88W8897 PCIe+USB card sends those events very
unreliably, sometimes bluetooth together with 2.4ghz-wifi is used and no
COEX event comes in, and sometimes bluetooth is disabled but the
coexistance mode doesn't get disabled.
This means we sometimes end up capping the rx/tx window size while
bluetooth is not enabled anymore, artifically limiting wifi speeds even
though bluetooth is not being used.
Since we can't fix the firmware, let's just ignore those events on the
88W8897 device. From some Wireshark capture sessions it seems that the
Windows driver also doesn't change the rx/tx window sizes when bluetooth
gets enabled or disabled, so this is fairly consistent with the Windows
driver.
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211103205827.14559-1-verdre@v0yd.nl
We assume at a few places that priv->version_str is 0-terminated, but
right now we trust the firmware that this is the case with the version
string we get from it.
Let's rather ensure this ourselves and replace the last character with
'\0'.
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211103201800.13531-4-verdre@v0yd.nl
The 88W8897 PCIe+USB card in the hardware revision 20 apparently has a
hardware issue where the card wakes up from deep sleep randomly and very
often, somewhat depending on the card activity, maybe the hardware has a
floating wakeup pin or something. This was found by comparing two MS
Surface Book 2 devices, where one devices wifi card experienced spurious
wakeups, while the other one didn't.
Those continuous wakeups prevent the card from entering host sleep when
the computer suspends. And because the host won't answer to events from
the card anymore while it's suspended, the firmwares internal power
saving state machine seems to get confused and the card can't sleep
anymore at all after that.
Since we can't work around that hardware bug in the firmware, let's
get the hardware revision string from the firmware and match it with
known bad revisions. Then disable auto deep sleep for those revisions,
which makes sure we no longer get those spurious wakeups.
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211103201800.13531-3-verdre@v0yd.nl
Since the version string we get from the firmware is always 128
characters long, use a define for this size instead of having the number
128 copied all over the place.
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211103201800.13531-2-verdre@v0yd.nl
Currently, with an unknown recv_type, mwifiex_usb_recv
just return -1 without restoring the skb. Next time
mwifiex_usb_rx_complete is invoked with the same skb,
calling skb_put causes skb_over_panic.
The bug is triggerable with a compromised/malfunctioning
usb device. After applying the patch, skb_over_panic
no longer shows up with the same input.
Attached is the panic report from fuzzing.
skbuff: skb_over_panic: text:000000003bf1b5fa
len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8
tail:0x844 end:0x840 dev:<NULL>
kernel BUG at net/core/skbuff.c:109!
invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60
RIP: 0010:skb_panic+0x15f/0x161
Call Trace:
<IRQ>
? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb]
skb_put.cold+0x24/0x24
mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb]
__usb_hcd_giveback_urb+0x1e4/0x380
usb_giveback_urb_bh+0x241/0x4f0
? __hrtimer_run_queues+0x316/0x740
? __usb_hcd_giveback_urb+0x380/0x380
tasklet_action_common.isra.0+0x135/0x330
__do_softirq+0x18c/0x634
irq_exit+0x114/0x140
smp_apic_timer_interrupt+0xde/0x380
apic_timer_interrupt+0xf/0x20
</IRQ>
Reported-by: Brendan Dolan-Gavitt <brendandg@nyu.edu>
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YX4CqjfRcTa6bVL+@Zekuns-MBP-16.fios-router.home
8821CE causes random freezes on HP 250 G7 Notebook PC. Add a quirk
to disable pci ASPM capability.
Reported-by: rtl8821cerfe2 <rtl8821cerfe2@protonmail.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211119052437.8671-1-pkshih@realtek.com
The management frame with high rate e.g. 24M may not be transmitted
smoothly in long range environment.
Add a debugfs to force to use the lowest basic rate
in order to debug the reachability of transmitting management frame.
obtain current setting
cat /sys/kernel/debug/ieee80211/phyX/rtw88/force_lowest_basic_rate
force lowest rate:
echo 1 > /sys/kernel/debug/ieee80211/phyX/rtw88/force_lowest_basic_rate
Signed-off-by: Yu-Yen Ting <steventing@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211102022454.10944-2-pkshih@realtek.com
By default the driver uses the 1M and 6M rate for managemnt frames
in 2G and 5G bands respectively. But when the basic rates is
configured from the mac80211, we need to send the management frames
according to the basic rates.
This commit makes the driver use the lowest basic rates to send
the management frames.
Signed-off-by: Yu-Yen Ting <steventing@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211102022454.10944-1-pkshih@realtek.com
The AXIDMA is tx/rx packet transmission between PCIE host
and device, and TX FIFO is MAC TX data.
We dump them to verify that these memory buffers are correct.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211122021129.4339-1-pkshih@realtek.com
The RF register array is used to help firmware to restore RF settings.
The original code can potentially access out of range, if the size is
between (RTW89_H2C_RF_PAGE_SIZE * RTW89_H2C_RF_PAGE_NUM + 1) to
((RTW89_H2C_RF_PAGE_SIZE + 1) * RTW89_H2C_RF_PAGE_NUM). Fortunately,
current used size doesn't fall into the wrong case, and the size will not
change if we don't update RF parameter.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211119055729.12826-1-pkshih@realtek.com
Fix the following coccicheck review:
./drivers/net/wireless/realtek/rtw89/mac.c: 1096: 5-8: Unneeded variable
Remove unneeded variable used to store return value.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211110121135.151187-1-deng.changcheng@zte.com.cn
The conditional operator is unnecessary while assigning values to the
bool variables.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211104061119.1685-1-ye.guojin@zte.com.cn
Start to configure entries with RTW89_QATAR, RTW89_UKRAINE, RTW89_CN.
Adjust some entries with explicit rtw89_regulatory instead of RTW89_WW.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211101093106.28848-5-pkshih@realtek.com
Update tx power limit table and tx power limit_ru table to R54.
Configure entries for MEXICO, CN, QATAR, and adjust some values
of original entries.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211101093106.28848-4-pkshih@realtek.com
Support QATAR in rtw89_regulation_type and reorder the enum to align
realtek R58-R31 regulation definition. Besides, if an unassigned entry
of limit/limit_ru tables is read, return the corresponding WW value for
the unconfigured case.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211101093106.28848-3-pkshih@realtek.com
This modification just replaces the number filled in the regd field
with the corresponding enum. No assignment of a value in a table is
changed. Doing this first is because the follow-up patches may adjust
the order of enum declarations.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211101093106.28848-2-pkshih@realtek.com
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.
Use memset_after() so memset() doesn't get confused about writing
beyond the destination member that is intended to be the starting point
of zeroing through the end of the struct.
Additionally fix the common helper, ieee80211_tx_info_clear_status(),
which was not clearing ack_signal, but the open-coded versions
did. Johannes Berg points out this bug was introduced by commit
e3e1a0bcb3 ("mac80211: reduce IEEE80211_TX_MAX_RATES") but was harmless.
Also drops the associated unneeded BUILD_BUG_ON()s, and adds a note to
carl9170 about usage.
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Christian Lamparter <chunkeey@gmail.com> [both CARL9170+P54USB on real HW]
Link: https://lore.kernel.org/r/20211118203839.1289276-1-keescook@chromium.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since firmware uses its own sequence number counters, we need to
use firmware number as well when mac80211 generates the ADD_BA
request packet. Indeed the firmware sequence counters tend to
slightly drift from the mac80211 ones because of firmware offload
features like ARP responses. This causes the starting sequence
number field of the ADD_BA request to be unaligned, and can possibly
cause issues with strict/picky APs.
To fix this, we retrieve the current firmware sequence number for
a given TID through the smd_trigger_ba API, and use that number as
replacement of the mac80211 starting sequence number.
This change also ensures that any issue in the smd *ba procedures
will cause the ba action to properly fail, and remove useless call
to smd_trigger_ba() from IEEE80211_AMPDU_RX_START.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1637604251-11763-1-git-send-email-loic.poulain@linaro.org
CE interrupt configuration uses host ce parameters to assign/free
interrupts. Use host ce parameters to enable/disable interrupts.
This patch fixes below BUG,
BUG: KASAN: global-out-of-bounds in 0xffffffbffdfb035c at addr
ffffffbffde6eeac
Read of size 4 by task kworker/u8:2/132
Address belongs to variable ath11k_core_qmi_firmware_ready+0x1b0/0x5bc [ath11k]
OOB is due to ath11k_ahb_ce_irqs_enable() iterates ce_count(which is 12)
times and accessing 12th element in target_ce_config
(which has only 11 elements) from ath11k_ahb_ce_irq_enable().
With this change host ce configs are used to enable/disable interrupts.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-00471-QCAHKSWPL_SILICONZ-1
Fixes: 967c1d1131 ("ath11k: move target ce configs to hw_params")
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1637249558-12793-1-git-send-email-akolli@codeaurora.org
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.
Use memset_startat() so memset() doesn't get confused about writing
beyond the destination member that is intended to be the starting point
of zeroing through the end of the struct. Additionally split up a later
field-spanning memset() so that memset() can reason about the size.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211118202416.1286046-1-keescook@chromium.org
This reverts commit 46e46db313. Mark reported
that it breaks QCA6390 hw2.0 on Dell XPS 13 9310:
[ 5.537034] ath11k_pci 0000:72:00.0: chip_id 0x0 chip_family 0xb board_id 0xff soc_id 0xffffffff
[ 5.537038] ath11k_pci 0000:72:00.0: fw_version 0x101c06cc fw_build_timestamp 2020-06-24 19:50 fw_build_id
[ 5.537236] ath11k_pci 0000:72:00.0: failed to fetch board data for bus=pci,qmi-chip-id=0,qmi-board-id=255,variant=DE_1901 from ath11k/QCA6390/hw2.0/board-2.bin
[ 5.537255] ath11k_pci 0000:72:00.0: failed to fetch board-2.bin or board.bin from QCA6390/hw2.0
[ 5.537257] ath11k_pci 0000:72:00.0: qmi failed to fetch board file: -2
[ 5.537258] ath11k_pci 0000:72:00.0: failed to load board data file: -2
So we need to back to the drawing board and implement it so that backwards
compatiblity is not broken.
Reported-by: Mark Herbert <mark.herbert42@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211124094316.9096-1-kvalo@codeaurora.org
The partition size is used to tell hardware the size of piece we are going
to send a firmware. The old code updates the size in constant buffer of
firmware, and leads system crash.
To fix this, update the size on skb->data after we copy the firmware data
into skb.
Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1188303
Fixes: e3ec7017f6 ("rtw89: add Realtek 802.11ax driver")
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211119054512.10620-2-pkshih@realtek.com
Should an error occur (invalid TLV len or memory allocation failure), the
memory already allocated in 'reduce_power_data' should be freed before
returning, otherwise it is leaking.
Fixes: 9dad325f9d ("iwlwifi: support loading the reduced power table from UEFI")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1504cd7d842d13ddb8244e18004523128d5c9523.1636615284.git.christophe.jaillet@wanadoo.fr
Fix warnings produced by:
- lockdep_assert_wiphy() in function reg_process_self_managed_hint(),
- wiphy_dereference() in function iwl_mvm_init_fw_regd().
Both function are expected to be called in critical section.
The warnings were discovered when running v5.15 kernel
with debug options enabled:
1)
Hardware name: Google Delbin/Delbin
RIP: 0010:reg_process_self_managed_hint+0x254/0x347 [cfg80211]
...
Call Trace:
regulatory_set_wiphy_regd_sync+0x3d/0xb0
iwl_mvm_init_mcc+0x49d/0x5a2
iwl_op_mode_mvm_start+0x1b58/0x2507
? iwl_mvm_reprobe_wk+0x94/0x94
_iwl_op_mode_start+0x146/0x1a3
iwl_opmode_register+0xda/0x13d
init_module+0x28/0x1000
2)
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:263 suspicious rcu_dereference_protected() usage!
...
Hardware name: Google Delbin/Delbin, BIOS Google_Delbin
Call Trace:
dump_stack_lvl+0xb1/0xe6
iwl_mvm_init_fw_regd+0x2e7/0x379
iwl_mvm_init_mcc+0x2c6/0x5a2
iwl_op_mode_mvm_start+0x1b58/0x2507
? iwl_mvm_reprobe_wk+0x94/0x94
_iwl_op_mode_start+0x146/0x1a3
iwl_opmode_register+0xda/0x13d
init_module+0x28/0x100
Fixes: a05829a722 ("cfg80211: avoid holding the RTNL when calling the driver")
Signed-off-by: Łukasz Bartosik <lb@semihalf.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211110215744.5487-1-lukasz.bartosik@semihalf.com
In some very rare cases the init flow may fail. In many cases, this is
recoverable, so we can retry. Implement a loop to retry two more times
after the first attempt failed.
This can happen in two different situations, namely during probe and
during mac80211 start. For the first case, a simple loop is enough.
For the second case, we need to add a flag to prevent mac80211 from
trying to restart it as well, leaving full control with the driver.
Cc: <stable@vger.kernel.org>
Signed-off-by: Mordechay Goodstein <mordechay.goodstein@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211110150132.57514296ecab.I52a0411774b700bdc7dedb124d8b59bf99456eb2@changeid
The error code is missing in this code scenario, add the error code
'-EINVAL' to the return value 'ret'.
Eliminate the follow smatch warning:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c:1376 iwl_pci_probe() warn:
missing error code 'ret'.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes: 1f171f4f14 ("iwlwifi: Add support for getting rf id with blank otp")
Signed-off-by: chongjiapeng <jiapeng.chong@linux.alibaba.com>
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1635838727-128735-1-git-send-email-jiapeng.chong@linux.alibaba.com
Both gcc-11 and clang point out a potential issue with integer overflow when
the iwl_dev_info_table[] array is empty. This is what clang warns:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c:1344:42: error: implicit conversion from 'unsigned long' to 'int' changes value from 18446744073709551615 to -1 [-Werror,-Wconstant-conversion]
for (i = ARRAY_SIZE(iwl_dev_info_table) - 1; i >= 0; i--) {
~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
This is still harmless, as the loop correctly terminates, but adding
an extra range check makes that obvious to both readers and to the
compiler.
Fixes: 3f7320428f ("iwlwifi: pcie: simplify iwl_pci_find_dev_info()")
Reported-by: kernel test robot <lkp@intel.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211118142124.526901-1-arnd@kernel.org
In HE monitor capture, HAL_TLV_STATUS_PPDU_DONE is received
on processing multiple skb. Do not clear the ppdu_info
till the HAL_TLV_STATUS_PPDU_DONE is received.
This fixes below warning and packet drops in monitor mode.
"Rate marked as an HE rate but data is invalid: MCS: 6, NSS: 0"
WARNING: at
PC is at ieee80211_rx_napi+0x624/0x840 [mac80211]
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01693-QCAHKSWPL_SILICONZ-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1637249433-10316-1-git-send-email-akolli@codeaurora.org
This is to read variant from SMBIOS such as read from DT, the variant
string will be used to one part of string which used to search board
data from board-2.bin.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211118100033.8384-1-quic_wgong@quicinc.com
The ath11k driver currently sends vdev down to the firmware before
updating the channel context, which is followed by a vdev restart
command.
Sending vdev down is not required before sending a vdev restart,
because the firmware internally does vdev down when ath11k sends
a vdev restart command.
Firmware will happen crash while channel switch without this change.
Hence skip the vdev down command sending when updating the channel
context and then fix the firmware crash issue.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211118095901.8271-1-quic_wgong@quicinc.com
The pdev id is set to 0 for single pdev configured hardware, the real
pdev id is not 0 in firmware, for example, its pdev id is 1 for 5G/6G
phy and 2 for 2G band phy. For HTT_H2T_MSG_TYPE_EXT_STATS_CFG message,
firmware parse the pdev_mask to its pdev id, ath11k set it to 0 for
single pdev, it is not correct, need set it with the real pdev id of
firmware.
Save the real pdev id report by firmware and set it correctly.
Below commands run success with this patch:
cat /sys/kernel/debug/ieee80211/phy0/ath11k/htt_stats
cat /sys/kernel/debug/ieee80211/phy0/netdev\:wls1/stations/00\:03\:7f\:75\:59\:85/htt_peer_stats
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211118095700.8149-1-quic_wgong@quicinc.com
When connected to 6G mode AP, it does not have VHT/HT capabilities,
so the NSS is not set, then it is 1 by default.
This patch is to calculate the NSS with supported HE-MCS and NSS set
of HE capabilities.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01280-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211118095453.8030-1-quic_wgong@quicinc.com
Some firmware versions for WCN6855 report the default regdomain with
alpha code "na" by default when load as a world wide regdomain, ath11k
should treat it as a world wide alpha code.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211118094848.7776-1-quic_wgong@quicinc.com
With VT-d disabled on Intel platform, ath11k gets only one MSI
vector. In that case, ath11k does not free IRQ when doing suspend,
hence the kernel has to migrate it to CPU0 (if it was affine to
other CPUs) and allocates a new MSI vector. However, ath11k has
no chance to reconfig it to HW srngs during this phase, thus
ath11k fails to resume.
This issue can be fixed by setting IRQ affinity to CPU0 before
request_irq is called. With such affinity, migration will not
happen and thus the vector keeps unchanged during suspend/resume.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211026041732.5323-1-bqiang@codeaurora.org
Current code enables ASPM by default, it allows MHI to enter M2 state.
In case of one MSI vector, system hang is observed if ath11k does MHI
register reading in this state. The issue was reported on Dell XPS 13
9310 but is seen also on XPS 15 and XPS 17 laptops.
The workaround here is to prevent MHI from entering M2 state, this can
be done by disabling ASPM if only one MSI vector is used. When using 32
vectors ASPM is enabled as before.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Link: https://lore.kernel.org/r/20211026041722.5271-1-bqiang@codeaurora.org
On some platforms it's not possible to allocate 32 MSI vectors for various
reasons, be it kernel configuration, VT-d disabled, buggy BIOS etc. So
ath11k was not able to use QCA6390 PCI devices on those platforms. Add
support for one MSI vector to solve that.
In case of one MSI vector, interrupt migration needs to be disabled. This
is because when interrupt migration happens, the msi_data may change.
However, msi_data is already programmed to rings during initial phase and
ath11k has no way to know that msi_data is changed during run time and
reprogram again.
In case of one MSI vector, MHI subsystem should not use IRQF_NO_SUSPEND
as QCA6390 doesn't set this flag too. Ath11k doesn't need to leave
IRQ enabled in suspend state.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Link: https://lore.kernel.org/r/20211026041714.5219-1-bqiang@codeaurora.org
This is to prepare for one MSI vector support. IRQ enable and disable
of CE and DP are done only in case of multiple MSI vectors.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Link: https://lore.kernel.org/r/20211026041705.5167-1-bqiang@codeaurora.org
Like ATH11K_PCI_IRQ_CE0_OFFSET, define ATH11K_PCI_IRQ_DP_OFFSET for
DP to save the IRQ instead of base_vector from MSI config.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Link: https://lore.kernel.org/r/20211026041655.5112-1-bqiang@codeaurora.org
This change adds two flags to indicate whether IRQ handler for CE
and DP can be called. This is because in one MSI vector case,
interrupt is not disabled in hif_stop and hif_irq_disable. Otherwise,
MHI interrupt is disabled too.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Carl Huang <cjhuang@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Baochen Qiang <bqiang@codeaurora.org>
Link: https://lore.kernel.org/r/20211026041646.5060-1-bqiang@codeaurora.org
