| Age | Commit message (Collapse) | Author |
|---|
|
I updated to sparse v0.6.4 and it warns:
drivers/net/wireless/ath/ath10k/wmi.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h):
drivers/net/wireless/ath/ath10k/wmi.h:3481:34: warning: array of flexible structures
Fix it by changing the type to u8 array, in struct wmi_phyerr_hdr_arg it's
stored as a void pointer anyway.
Compile tested only.
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211209091545.6098-2-kvalo@kernel.org
|
|
I updated to sparse v0.6.4 and it warns:
drivers/net/wireless/ath/ath10k/hw.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h):
drivers/net/wireless/ath/ath10k/htt.h:1503:41: warning: array of flexible structures
drivers/net/wireless/ath/ath10k/htt_rx.c: note: in included file (through drivers/net/wireless/ath/ath10k/core.h):
drivers/net/wireless/ath/ath10k/htt.h:1503:41: warning: array of flexible structures
The structure is unused in ath10k so let's just remove it.
Compile tested only.
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211209091545.6098-1-kvalo@kernel.org
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are a bunch of small char/misc and other driver subsystem fixes.
Included in here are:
- iio driver fixes for reported problems
- phy driver fixes for a number of reported problems
- mhi resume bugfix for broken hardware
- nvmem driver fix
- rtsx driver fix for irq issues
- fastrpc packet parsing fix
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-5.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (33 commits)
bus: mhi: core: Add support for forced PM resume
iio: trigger: stm32-timer: fix MODULE_ALIAS
misc: rtsx: Avoid mangling IRQ during runtime PM
nvmem: eeprom: at25: fix FRAM byte_len
misc: fastrpc: fix improper packet size calculation
MAINTAINERS: add maintainer for Qualcomm FastRPC driver
bus: mhi: pci_generic: Fix device recovery failed issue
iio: adc: stm32: fix null pointer on defer_probe error
phy: HiSilicon: Fix copy and paste bug in error handling
dt-bindings: phy: zynqmp-psgtr: fix USB phy name
phy: ti: omap-usb2: Fix the kernel-doc style
phy: qualcomm: ipq806x-usb: Fix kernel-doc style
iio: at91-sama5d2: Fix incorrect sign extension
iio: adc: axp20x_adc: fix charging current reporting on AXP22x
iio: gyro: adxrs290: fix data signedness
phy: ti: tusb1210: Fix the kernel-doc warn
phy: qualcomm: usb-hsic: Fix the kernel-doc warn
phy: qualcomm: qmp: Add missing struct documentation
phy: mvebu-cp110-utmi: Fix kernel-doc warns
iio: ad7768-1: Call iio_trigger_notify_done() on error
...
|
|
For whatever reason, some devices like QCA6390, WCN6855 using ath11k
are not in M3 state during PM resume, but still functional. The
mhi_pm_resume should then not fail in those cases, and let the higher
level device specific stack continue resuming process.
Add an API mhi_pm_resume_force(), to force resuming irrespective of the
current MHI state. This fixes a regression with non functional ath11k WiFi
after suspend/resume cycle on some machines.
Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=214179
Link: https://lore.kernel.org/regressions/871r5p0x2u.fsf@codeaurora.org/
Fixes: 020d3b26c07a ("bus: mhi: Early MHI resume failure in non M3 state")
Cc: stable@vger.kernel.org #5.13
Reported-by: Kalle Valo <kvalo@codeaurora.org>
Reported-by: Pengyu Ma <mapengyu@gmail.com>
Tested-by: Kalle Valo <kvalo@kernel.org>
Acked-by: Kalle Valo <kvalo@kernel.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
[mani: Switched to API, added bug report, reported-by tags and CCed stable]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20211209131633.4168-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The unnamed struct sucks and is in the way of further cleanups. Stick the
PCI related MSI data into a real data structure and cleanup all users.
No functional change.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211206210224.374863119@linutronix.de
|
|
When scan request on channel 1, it also receive beacon from other
channels, and the beacon also indicate to mac80211 and wpa_supplicant,
and then the bss info appears in radio measurement report of radio
measurement sent from wpa_supplicant, thus lead RRM case fail.
This is to drop the beacon and probe response which is not the same
channel of scanning.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211208061752.16564-1-quic_wgong@quicinc.com
|
|
Currently there is no validation on the spectral/CFR report
over the db ring buffers from the hardware. Improper/incomplete
DMA by the target can result in invalid data received by host.
Due to this we may populate incorrect data to user space.
This buffer validation support fix this issues by filling some
magic value in the buffer during buffer replenish and check for
the magic value in the buffer received by the target. If host
detect magic value in the received buffer it will drop the buffer.
Tested-on: IPQ8074 WLAN.HK.2.4.0.1-01467-QCAHKSWPL_SILICONZ-1
Signed-off-by: Venkateswara Naralasetty <quic_vnaralas@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1637312901-10279-2-git-send-email-quic_vnaralas@quicinc.com
|
|
In full monitor mode, monitor destination ring is read before monitor
status ring. mon_dst_ring has ppdu id, reap till the end of PPDU. Add
all the MPDUs to list. Start processing the status ring, if PPDU id in
status ring is lagging behind, reap the status ring, once the PPDU ID
matches, deliver the MSDU to upper layer. If status PPDU id leading,
reap the mon_dst_ring.
The advantage with full monitor mode is hardware has status buffers
available for all the MPDUs in mon_dst_ring, which makes it possible
to deliver more frames to be seen on sniffer.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638881695-22155-4-git-send-email-akolli@codeaurora.org
|
|
In full monitor mode, monitor destination ring is read in
software monitor ring descriptor format instead of
reo_entrance_ring format. Add new sw_mon_ring descriptor.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638881695-22155-3-git-send-email-akolli@codeaurora.org
|
|
A new hw_param full_monitor_mode is added to enable full
monitor support for QCN9074.
HTT_H2T_MSG_TYPE_RX_FULL_MONITOR_MODE cmd is sent to FW
to enable the full monitor mode.
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.4.0.1-01734-QCAHKSWPL_SILICONZ-1
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638881695-22155-2-git-send-email-akolli@codeaurora.org
|
|
In builds with -Warray-bounds, casts from smaller objects to larger
objects will produce warnings. These can be overly conservative, but since
-Warray-bounds has been finding legitimate bugs, it is desirable to turn
it on globally. Instead of casting a u32 to a larger object, redefine
the u32 portion of the header to a separate struct that can be used for
both u32 operations and the distinct header fields. Silences this warning:
drivers/net/wireless/ath/ath6kl/htc_mbox.c: In function 'htc_wait_for_ctrl_msg':
drivers/net/wireless/ath/ath6kl/htc_mbox.c:2275:20: error: array subscript 'struct htc_frame_hdr[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
2275 | if (htc_hdr->eid != ENDPOINT_0)
| ^~
drivers/net/wireless/ath/ath6kl/htc_mbox.c:2264:13: note: while referencing 'look_ahead'
2264 | u32 look_ahead;
| ^~~~~~~~~~
This change results in no executable instruction differences.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211207063538.2767954-1-keescook@chromium.org
|
|
Currently mac80211 will send 3 scan request for each scan of WCN6855,
they are 2.4 GHz/5 GHz/6 GHz band scan. Firmware of WCN6855 will
cache the RNR IE(Reduced Neighbor Report element) which exist in the
beacon of 2.4 GHz/5 GHz of the AP which is co-located with 6 GHz,
and then use the cache to scan in 6 GHz band scan if the 6 GHz scan
is in the same scan with the 2.4 GHz/5 GHz band, this will helpful to
search more AP of 6 GHz. Also it will decrease the time cost of scan
because firmware will use dual-band scan for the 2.4 GHz/5 GHz, it
means the 2.4 GHz and 5 GHz scans are doing simultaneously.
Set the flag IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS for WCN6855 since
it supports 2.4 GHz/5 GHz/6 GHz and it is single pdev which means
all the 2.4 GHz/5 GHz/6 GHz exist in the same wiphy/ieee80211_hw.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Tested-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211129101309.2931-1-quic_wgong@quicinc.com
|
|
If cfg80211 is providing extraie's for a scanning process then ath11k will
copy that over to the firmware. The extraie.len is a 32 bit value in struct
element_info and describes the amount of bytes for the vendor information
elements.
The WMI_TLV packet is having a special WMI_TAG_ARRAY_BYTE section. This
section can have a (payload) length up to 65535 bytes because the
WMI_TLV_LEN can store up to 16 bits. The code was missing such a check and
could have created a scan request which cannot be parsed correctly by the
firmware.
But the bigger problem was the allocation of the buffer. It has to align
the TLV sections by 4 bytes. But the code was using an u8 to store the
newly calculated length of this section (with alignment). And the new
calculated length was then used to allocate the skbuff. But the actual code
to copy in the data is using the extraie.len and not the calculated
"aligned" length.
The length of extraie with IEEE80211_HW_SINGLE_SCAN_ON_ALL_BANDS enabled
was 264 bytes during tests with a QCA Milan card. But it only allocated 8
bytes (264 bytes % 256) for it. As consequence, the code to memcpy the
extraie into the skb was then just overwriting data after skb->end. Things
like shinfo were therefore corrupted. This could usually be seen by a crash
in skb_zcopy_clear which tried to call a ubuf_info callback (using a bogus
address).
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Cc: stable@vger.kernel.org
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211207142913.1734635-1-sven@narfation.org
|
|
The earlier __packed annotations added in commit d71038c05970 ("libertas:
Fix alignment issues in libertas core") were not duplicated when
libertas_af was added in commit 7670e62c7ed6 ("libertas_tf: header file"),
even though they share several structure definitions. Add the missing
annotations which commit 642a57475b30 ("libertas_tf: Use struct_group()
for memcpy() region") exposed. Quoting the prior libertas fix: "Data
structures that come over the wire from the WLAN firmware must be
packed."
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/linux-mm/202111302102.apaePz2J-lkp@intel.com
Fixes: 642a57475b30 ("libertas_tf: Use struct_group() for memcpy() region")
Fixes: 7670e62c7ed6 ("libertas_tf: header file")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201173234.578124-3-keescook@chromium.org
|
|
Build testing of the newly added struct_group() usage missed smaller
architecture width tests for changes to pahole output. Add the missed
__packed annotation with struct_group() usage in a __packed struct.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/linux-mm/202111302102.apaePz2J-lkp@intel.com
Fixes: 5fd32ae0433a ("libertas: Use struct_group() for memcpy() region")
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201173234.578124-2-keescook@chromium.org
|
|
Quoting Jia-Ju Bai <baijiaju1990@gmail.com>:
mwifiex_dequeue_tx_packet()
spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 1432 (Lock A)
mwifiex_send_addba()
spin_lock_bh(&priv->sta_list_spinlock); --> Line 608 (Lock B)
mwifiex_process_sta_tx_pause()
spin_lock_bh(&priv->sta_list_spinlock); --> Line 398 (Lock B)
mwifiex_update_ralist_tx_pause()
spin_lock_bh(&priv->wmm.ra_list_spinlock); --> Line 941 (Lock A)
Similar report for mwifiex_process_uap_tx_pause().
While the locking expectations in this driver are a bit unclear, the
Fixed commit only intended to protect the sta_ptr, so we can drop the
lock as soon as we're done with it.
IIUC, this deadlock cannot actually happen, because command event
processing (which calls mwifiex_process_sta_tx_pause()) is
sequentialized with TX packet processing (e.g.,
mwifiex_dequeue_tx_packet()) via the main loop (mwifiex_main_process()).
But it's good not to leave this potential issue lurking.
Fixes: f0f7c2275fb9 ("mwifiex: minor cleanups w/ sta_list_spinlock in cfg80211.c")
Cc: Douglas Anderson <dianders@chromium.org>
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Link: https://lore.kernel.org/linux-wireless/0e495b14-efbb-e0da-37bd-af6bd677ee2c@gmail.com/
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/YaV0pllJ5p/EuUat@google.com
|
|
This eliminates warning message:
SPI driver WILC_SPI has no spi_device_id for microchip,wilc1000
and makes device-tree autoloading work.
Signed-off-by: David Mosberger-Tang <davidm@egauge.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211202045001.2901903-1-davidm@egauge.net
|
|
This is found by Smatch static checker warning:
drivers/net/wireless/realtek/rtw89/mac80211.c:31 rtw89_ops_tx()
error: uninitialized symbol 'qsel'.
The warning is because 'qsel' isn't filled by rtw89_core_tx_write() due to
failed to write. The way to fix it is to avoid kicking off TX DMA, so add
'return' to the failure case.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201093816.13806-1-pkshih@realtek.com
|
|
Originally, cch_by_bw recorded center channels of each available
bandwidths under current bandwidth. And the plan was to iterate
cch_by_bw as parameters to query other configurations. However,
we have not used it for the time being. Keeping it will disturb
the follow-up things, such as bandwidth 160 MHz, so we remove it
for now. If it's really needed at some point, we will redesign it.
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@kernel.org>
Link: https://lore.kernel.org/r/20211201080901.12125-1-pkshih@realtek.com
|
|
With wrong rtwsta->mac_id, it can't send out ack properly when we receive
assoc response occasionally. Then, it failed to connect an AP.
The cause is that we store 'sta' and use it somewhere. To correct this,
remove the variable and use mac_id in drv_priv of 'sta' or 'vif' passed
by mac80211.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211201080607.11211-1-pkshih@realtek.com
|
|
Show channel and bandwidth in debugfs tx_pwr_tbl to make it easier
to understand which tx power table is shown currently, and to reduce
additional checks through other ways.
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@kernel.org>
Link: https://lore.kernel.org/r/20211129020626.6384-1-pkshih@realtek.com
|
|
It is useful to fix the bit rate of TX packets. For example, if
someone is measuring the TX power, or debugging with the issues
of the TX throughput on the field.
To set the value of fixed rate, one should input corresponding
desc rate index (ex, 0x0b for DESC_RATE54M to fix at 54 Mbps).
Set a value larger than DESC_RATE_MAX will disable fix rate, so
the rate adaptive mechanism can resume to work.
Example,
To fix rate at MCS 1:
echo 0x0d > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
To not to fix rate:
echo 0xff > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
To know which rate was fixed at:
cat /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211129020506.6273-1-pkshih@realtek.com
|
|
We used to fill in rx skbs' frequency field by mac80211's current
channel value. In some cases, mac80211 switches channel before all
rx packets have been processed. This results in incorrect bss info.
We fix this by filling in frequency field with channel index obtained
from hardware, then fix potential cck missing issue by skb's original
hw rate. After all fix is done, convert hw rate back to the supported
band rate index.
Signed-off-by: Po Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211111023706.14154-3-pkshih@realtek.com
|
|
Update scan_mac_addr to address CAM as A1, so hardware can ACK probe
response properly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211111023706.14154-2-pkshih@realtek.com
|
|
In order to use compiler to check if we do improper cast of const* on
arguments of inline function.
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@kernel.org>
Link: https://lore.kernel.org/r/20211119054512.10620-4-pkshih@realtek.com
|
|
Add 'const' to be clear that this is a read-only access, and this patch
doesn't change logic at all.
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@kernel.org>
Link: https://lore.kernel.org/r/20211119054512.10620-3-pkshih@realtek.com
|
|
After mt7921s got added, there are two possible build problems:
a) mt7921s does not get built at all if mt7921e is not also enabled
b) there is a link error when mt7921e is a loadable module, but mt7921s
configured as built-in:
ERROR: modpost: "mt7921_mac_sta_add" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_assoc" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_remove" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_write_txwi" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_drv_pmctrl" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_fill_message" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_parse_response" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_ops" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_queue_rx_skb" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_update_channel" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
Fix both by making sure that Kbuild enters the subdirectory when
either one is enabled.
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211204173848.873293-3-arnd@kernel.org
|
|
This is now the only driver that selects the LEDS_CLASS framework,
which is normally user-selectable. While it doesn't strictly cause
a bug, rework the Kconfig logic to be more consistent with what
other drivers do, and only enable LED support in brcmsmac if the
dependencies are all there, rather than using 'select' to enable
what it needs.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211204173848.873293-2-arnd@kernel.org
|
|
The dependencies for LED configuration are highly inconsistent and too
complicated at the moment. One of the results is a randconfig failure I
get very rarely when LEDS_CLASS is in a loadable module, but the wireless
core is built-in:
WARNING: unmet direct dependencies detected for MAC80211_LEDS
Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
Selected by [m]:
- IWLEGACY [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y]
- IWLWIFI_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y] && IWLWIFI [=m] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=IWLWIFI [=m]) && (IWLMVM [=m] || IWLDVM [=m])
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_register_led':
led.c:(.text+0x60): undefined reference to `led_classdev_register_ext'
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_unregister_leds':
led.c:(.text+0x200): undefined reference to `led_classdev_unregister'
For iwlwifi, the dependency is wrong, since this config prevents the
MAC80211_LEDS code from being part of a built-in MAC80211 driver.
For iwlegacy, this is worse because the driver tries to force-enable
the other subsystems, which is both a layering violation and a bug
because it will still fail with MAC80211=y and IWLEGACY=m, leading
to LEDS_CLASS being a module as well.
The actual link failure in the ath5k driver is a result of MAC80211_LEDS
being enabled but not usable. With the Kconfig logic fixed in the
Intel drivers, the ath5k driver works as expected again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211204173848.873293-1-arnd@kernel.org
|
|
If we get to the WARN_ONCE(..., "Got a HT rate (...)", ...)
here with a NULL sta, then we crash because mvmsta is bad
and we try to dereference it. Fix that by printing -1 as the
state if no station was given.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes: 6761a718263a ("iwlwifi: mvm: add explicit check for non-data frames in get Tx rate")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/iwlwifi.20211203140410.1a1541d7dcb5.I606c746e11447fe168cf046376b70b04e278c3b4@changeid
|
|
When request scan with duration 120ms on channel 1, it failed with
scan abort easily. Because scan_timeout is set to 130ms for the scan
in ath10k_hw_scan(), and timed out before scan complete, so lead
scan abort.
failed log of ath10k:
2021-04-14T14:43:29.936058Z DEBUG kernel: [67384.594846] ath10k_sdio mmc1:0001:1: wmi tlv start scan
2021-04-14T14:43:29.937896Z DEBUG kernel: [67384.595820] ath10k_sdio mmc1:0001:1: scan event started type 1 reason 7 freq 2437 req_id 40961 scan_id 40960 vdev_id 0 state starting (1)
2021-04-14T14:43:29.938357Z DEBUG kernel: [67384.596761] ath10k_sdio mmc1:0001:1: scan event bss channel type 4 reason 7 freq 2437 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
2021-04-14T14:43:29.992497Z DEBUG kernel: [67384.651013] ath10k_sdio mmc1:0001:1: scan event foreign channel type 8 reason 7 freq 2412 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
2021-04-14T14:43:30.063530Z DEBUG kernel: [67384.722139] ath10k_sdio mmc1:0001:1: wmi tlv stop scan
2021-04-14T14:43:30.066592Z DEBUG kernel: [67384.724403] ath10k_sdio mmc1:0001:1: scan event completed [cancelled] type 2 reason 1 freq 2412 req_id 40961 scan_id 40960 vdev_id 0 state aborting (3)
failed log of wpa_supplicant:
2021-04-14T14:43:29.981842Z DEBUG wpa_supplicant[887]: wlan0: nl80211: scan request
2021-04-14T14:43:29.981988Z DEBUG wpa_supplicant[887]: nl80211: Passive scan requested
2021-04-14T14:43:29.982202Z DEBUG wpa_supplicant[887]: nl80211: Add NL80211_SCAN_FLAG_FLUSH
2021-04-14T14:43:29.982339Z DEBUG wpa_supplicant[887]: Scan requested (ret=0) - scan timeout 30 seconds
2021-04-14T14:43:29.982491Z DEBUG wpa_supplicant[887]: nl80211: Drv Event 33 (NL80211_CMD_TRIGGER_SCAN) received for wlan0
2021-04-14T14:43:29.982629Z DEBUG wpa_supplicant[887]: wlan0: nl80211: Scan trigger
2021-04-14T14:43:29.982779Z DEBUG wpa_supplicant[887]: wlan0: Event SCAN_STARTED (47) received
2021-04-14T14:43:29.982920Z DEBUG wpa_supplicant[887]: wlan0: Own scan request started a scan in 0.000175 seconds
2021-04-14T14:43:30.082401Z DEBUG wpa_supplicant[887]: nl80211: Drv Event 35 (NL80211_CMD_SCAN_ABORTED) received for wlan0
2021-04-14T14:43:30.082704Z DEBUG wpa_supplicant[887]: wlan0: nl80211: Scan aborted
2021-04-14T14:43:30.082905Z DEBUG wpa_supplicant[887]: nl80211: Scan included frequencies: 2412
2021-04-14T14:43:30.083123Z DEBUG wpa_supplicant[887]: wlan0: Event SCAN_RESULTS (3) received
2021-04-14T14:43:30.083310Z DEBUG wpa_supplicant[887]: wlan0: Scan completed in 0.128655 seconds
This is to increase the scan_timeout with 200ms for this situation,
then scan will not timed out for this situation.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211026025902.26621-1-quic_wgong@quicinc.com
|
|
While running stress tests in roaming scenarios (switching ap's every 5
seconds, we discovered a issue which leads to tx hangings of exactly 5
seconds while or after scanning for new accesspoints. We found out that
this hanging is triggered by ath10k_mac_wait_tx_complete since the
empty_tx_wq was not wake when the num_tx_pending counter reaches zero.
To fix this, we simply move the wake_up call to htt_tx_dec_pending,
since this call was missed on several locations within the ath10k code.
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20210505085806.11474-1-s.gottschall@dd-wrt.com
|
|
South Korea manufacturer, Samsung, has extended South Korea
regulatory domain pair with 0x5F and has used it for their
devices such as Samsung Galaxy book. Hence add support
0x5F as a regulatory domain pair along with extended country
code, 413.
Signed-off-by: Peter Oh <ebmajor.dev@gmail.com>
Signed-off-by: Andreas Tepe <andreas.tepe@debitel.net>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20210915185611.6195-1-ebmajor.dev@gmail.com
|
|
In ath11k, tx of management packet is doing in a work queue. Sometimes
the workqueue does not finish tx immediately, then it lead after the next
step of vdev delete finished, it start to send the management packet to
firmware and lead firmware crash.
ieee80211_set_disassoc() have logic of ieee80211_flush_queues() after
it send_deauth_disassoc() to ath11k, its purpose is make sure the
deauth was actually sent, so it need to change ath11k to match the
purpose of mac80211.
To address these issue wait for tx mgmt as well as tx data packets.
dmesg log of connect/disconnect to AP:
[ 307.522226] wls1: authenticate with 62:66:e4:e9:6a:a9
[ 307.586565] wls1: send auth to 62:66:e4:e9:6a:a9 (try 1/3)
[ 307.586581] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0
[ 307.586922] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0
[ 307.590179] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0
[ 307.590181] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0
[ 307.598699] wls1: authenticated
[ 307.599483] wls1: associate with 62:66:e4:e9:6a:a9 (try 1/3)
[ 307.599506] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0
[ 307.599519] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0
[ 307.603059] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0
[ 307.603063] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0
[ 307.637105] wls1: associated
[ 317.365239] wls1: deauthenticating from 62:66:e4:e9:6a:a9 by local choice (Reason: 3=DEAUTH_LEAVING)
[ 317.368104] ath11k_pci 0000:05:00.0: mac tx mgmt frame, buf id 0
[ 317.372622] ath11k_pci 0000:05:00.0: mac tx mgmt frame, vdev_id 0
[ 317.378320] ath11k_pci 0000:05:00.0: wmi mgmt tx comp pending 0 desc id 0
[ 317.378330] ath11k_pci 0000:05:00.0: mgmt tx compl ev pdev_id 2, desc_id 0, status 0
[ 317.378359] ath11k_pci 0000:05:00.0: mac mgmt tx flush mgmt pending 0
[ 317.421066] ath11k_pci 0000:05:00.0: mac mgmt tx flush mgmt pending 0
[ 317.421427] ath11k_pci 0000:05:00.0: mac remove interface (vdev 0)
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01230-QCAHSTSWPLZ_V2_TO_X86-1
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 <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211202063705.14321-1-quic_wgong@quicinc.com
|
|
Use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some
open-coded arithmetic in allocator arguments.
Note, that this 'bitmap_zalloc()' divides by BITS_PER_LONG the amount of
memory allocated.
The 'roundup()' used to computed the number of needed long should have
been a DIV_ROUND_UP.
Also change the corresponding 'kfree()' into 'bitmap_free()' to keep
consistency.
Use 'bitmap_zero()' to avoid hand writing it.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1fe18fb73f71d855043c40c83865ad539f326478.1638396221.git.christophe.jaillet@wanadoo.fr
|
|
Kernel test robot reported:drivers/net/wireless/ath/wcn36xx/smd.c:943:33:
sparse: sparse: cast truncates bits from constant value (780 becomes 80)
The 'channels' field is not a simple u8 array but an array of
channel_params. Using sizeof for retrieving the max number of
channels is then wrong.
In practice, it was not an issue, because the sizeof returned
value is 780, which is truncated in min_t (u8) to 80, which is
the value we expect...
Fix that properly using ARRAY_SIZE instead of sizeof.
Fixes: d707f812bb05 ("wcn36xx: Channel list update before hardware scan")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/1638435732-14657-1-git-send-email-loic.poulain@linaro.org
|
|
Add handler for WMI_11D_NEW_COUNTRY_EVENTID, WMI_11D_SCAN_START_CMDID,
WMI_11D_SCAN_STOP_CMDID.
After vdev create for STATION, send WMI_11D_SCAN_START_CMDID to firmware
and wait firmware complete it, the scan from mac80211 also need to wait
the 11d scan finished, and send WMI_11D_SCAN_STOP_CMDID to firmware
before vdev delete for STATION.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01230-QCAHSTSWPLZ_V2_TO_X86-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211201071745.17746-4-quic_wgong@quicinc.com
|
|
Add handler to send WMI_SET_CURRENT_COUNTRY_CMDID to firmware which
is used for QCA6390 and WCN6855.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
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 <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211201071745.17746-3-quic_wgong@quicinc.com
|
|
When enable debug config, it print below warning while shut down wlan
interface shuh as run "ifconfig wlan0 down".
The reason is because ar->regd_update_work is ran once, and it is will
call wiphy_lock(ar->hw->wiphy) in function ath11k_regd_update() which
is running in workqueue of ieee80211_local queued by ieee80211_queue_work().
Another thread from "ifconfig wlan0 down" will also accuqire the lock
by wiphy_lock(sdata->local->hw.wiphy) in function ieee80211_stop(), and
then it call ieee80211_stop_device() to flush_workqueue(local->workqueue),
this will wait the workqueue of ieee80211_local finished. Then deadlock
will happen easily if the two thread run meanwhile.
Below warning disappeared after this change.
[ 914.088798] ath11k_pci 0000:05:00.0: mac remove interface (vdev 0)
[ 914.088806] ath11k_pci 0000:05:00.0: mac stop 11d scan
[ 914.088810] ath11k_pci 0000:05:00.0: mac stop 11d vdev id 0
[ 914.088827] ath11k_pci 0000:05:00.0: htc ep 2 consumed 1 credits (total 0)
[ 914.088841] ath11k_pci 0000:05:00.0: send 11d scan stop vdev id 0
[ 914.088849] ath11k_pci 0000:05:00.0: htc insufficient credits ep 2 required 1 available 0
[ 914.088856] ath11k_pci 0000:05:00.0: htc insufficient credits ep 2 required 1 available 0
[ 914.096434] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 16
[ 914.096442] ath11k_pci 0000:05:00.0: htc ep 2 got 1 credits (total 1)
[ 914.096481] ath11k_pci 0000:05:00.0: htc ep 2 consumed 1 credits (total 0)
[ 914.096491] ath11k_pci 0000:05:00.0: WMI vdev delete id 0
[ 914.111598] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 16
[ 914.111628] ath11k_pci 0000:05:00.0: htc ep 2 got 1 credits (total 1)
[ 914.114659] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 20
[ 914.114742] ath11k_pci 0000:05:00.0: htc rx completion ep 2 skb pK-error
[ 914.115977] ath11k_pci 0000:05:00.0: vdev delete resp for vdev id 0
[ 914.116685] ath11k_pci 0000:05:00.0: vdev 00:03:7f:29:61:11 deleted, vdev_id 0
[ 914.117583] ======================================================
[ 914.117592] WARNING: possible circular locking dependency detected
[ 914.117600] 5.16.0-rc1-wt-ath+ #1 Tainted: G OE
[ 914.117611] ------------------------------------------------------
[ 914.117618] ifconfig/2805 is trying to acquire lock:
[ 914.117628] ffff9c00a62bb548 ((wq_completion)phy0){+.+.}-{0:0}, at: flush_workqueue+0x87/0x470
[ 914.117674]
but task is already holding lock:
[ 914.117682] ffff9c00baea07d0 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_stop+0x38/0x180 [mac80211]
[ 914.117872]
which lock already depends on the new lock.
[ 914.117880]
the existing dependency chain (in reverse order) is:
[ 914.117888]
-> #3 (&rdev->wiphy.mtx){+.+.}-{4:4}:
[ 914.117910] __mutex_lock+0xa0/0x9c0
[ 914.117930] mutex_lock_nested+0x1b/0x20
[ 914.117944] reg_process_self_managed_hints+0x3a/0xb0 [cfg80211]
[ 914.118093] wiphy_regulatory_register+0x47/0x80 [cfg80211]
[ 914.118229] wiphy_register+0x84f/0x9c0 [cfg80211]
[ 914.118353] ieee80211_register_hw+0x6b1/0xd90 [mac80211]
[ 914.118486] ath11k_mac_register+0x6af/0xb60 [ath11k]
[ 914.118550] ath11k_core_qmi_firmware_ready+0x383/0x4a0 [ath11k]
[ 914.118598] ath11k_qmi_driver_event_work+0x347/0x4a0 [ath11k]
[ 914.118656] process_one_work+0x228/0x670
[ 914.118669] worker_thread+0x4d/0x440
[ 914.118680] kthread+0x16d/0x1b0
[ 914.118697] ret_from_fork+0x22/0x30
[ 914.118714]
-> #2 (rtnl_mutex){+.+.}-{4:4}:
[ 914.118736] __mutex_lock+0xa0/0x9c0
[ 914.118751] mutex_lock_nested+0x1b/0x20
[ 914.118767] rtnl_lock+0x17/0x20
[ 914.118783] ath11k_regd_update+0x15a/0x260 [ath11k]
[ 914.118841] ath11k_regd_update_work+0x15/0x20 [ath11k]
[ 914.118897] process_one_work+0x228/0x670
[ 914.118909] worker_thread+0x4d/0x440
[ 914.118920] kthread+0x16d/0x1b0
[ 914.118934] ret_from_fork+0x22/0x30
[ 914.118948]
-> #1 ((work_completion)(&ar->regd_update_work)){+.+.}-{0:0}:
[ 914.118972] process_one_work+0x1fa/0x670
[ 914.118984] worker_thread+0x4d/0x440
[ 914.118996] kthread+0x16d/0x1b0
[ 914.119010] ret_from_fork+0x22/0x30
[ 914.119023]
-> #0 ((wq_completion)phy0){+.+.}-{0:0}:
[ 914.119045] __lock_acquire+0x146d/0x1cf0
[ 914.119057] lock_acquire+0x19b/0x360
[ 914.119067] flush_workqueue+0xae/0x470
[ 914.119084] ieee80211_stop_device+0x3b/0x50 [mac80211]
[ 914.119260] ieee80211_do_stop+0x5d7/0x830 [mac80211]
[ 914.119409] ieee80211_stop+0x45/0x180 [mac80211]
[ 914.119557] __dev_close_many+0xb3/0x120
[ 914.119573] __dev_change_flags+0xc3/0x1d0
[ 914.119590] dev_change_flags+0x29/0x70
[ 914.119605] devinet_ioctl+0x653/0x810
[ 914.119620] inet_ioctl+0x193/0x1e0
[ 914.119631] sock_do_ioctl+0x4d/0xf0
[ 914.119649] sock_ioctl+0x262/0x340
[ 914.119665] __x64_sys_ioctl+0x96/0xd0
[ 914.119678] do_syscall_64+0x3d/0xd0
[ 914.119694] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 914.119709]
other info that might help us debug this:
[ 914.119717] Chain exists of:
(wq_completion)phy0 --> rtnl_mutex --> &rdev->wiphy.mtx
[ 914.119745] Possible unsafe locking scenario:
[ 914.119752] CPU0 CPU1
[ 914.119758] ---- ----
[ 914.119765] lock(&rdev->wiphy.mtx);
[ 914.119778] lock(rtnl_mutex);
[ 914.119792] lock(&rdev->wiphy.mtx);
[ 914.119807] lock((wq_completion)phy0);
[ 914.119819]
*** DEADLOCK ***
[ 914.119827] 2 locks held by ifconfig/2805:
[ 914.119837] #0: ffffffffba3dc010 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock+0x17/0x20
[ 914.119872] #1: ffff9c00baea07d0 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_stop+0x38/0x180 [mac80211]
[ 914.120039]
stack backtrace:
[ 914.120048] CPU: 0 PID: 2805 Comm: ifconfig Tainted: G OE 5.16.0-rc1-wt-ath+ #1
[ 914.120064] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011
[ 914.120074] Call Trace:
[ 914.120084] <TASK>
[ 914.120094] dump_stack_lvl+0x73/0xa4
[ 914.120119] dump_stack+0x10/0x12
[ 914.120135] print_circular_bug.isra.44+0x221/0x2e0
[ 914.120165] check_noncircular+0x106/0x150
[ 914.120203] __lock_acquire+0x146d/0x1cf0
[ 914.120215] ? __lock_acquire+0x146d/0x1cf0
[ 914.120245] lock_acquire+0x19b/0x360
[ 914.120259] ? flush_workqueue+0x87/0x470
[ 914.120286] ? lockdep_init_map_type+0x6b/0x250
[ 914.120310] flush_workqueue+0xae/0x470
[ 914.120327] ? flush_workqueue+0x87/0x470
[ 914.120344] ? lockdep_hardirqs_on+0xd7/0x150
[ 914.120391] ieee80211_stop_device+0x3b/0x50 [mac80211]
[ 914.120565] ? ieee80211_stop_device+0x3b/0x50 [mac80211]
[ 914.120736] ieee80211_do_stop+0x5d7/0x830 [mac80211]
[ 914.120906] ieee80211_stop+0x45/0x180 [mac80211]
[ 914.121060] __dev_close_many+0xb3/0x120
[ 914.121081] __dev_change_flags+0xc3/0x1d0
[ 914.121109] dev_change_flags+0x29/0x70
[ 914.121131] devinet_ioctl+0x653/0x810
[ 914.121149] ? __might_fault+0x77/0x80
[ 914.121179] inet_ioctl+0x193/0x1e0
[ 914.121194] ? inet_ioctl+0x193/0x1e0
[ 914.121218] ? __might_fault+0x77/0x80
[ 914.121238] ? _copy_to_user+0x68/0x80
[ 914.121266] sock_do_ioctl+0x4d/0xf0
[ 914.121283] ? inet_stream_connect+0x60/0x60
[ 914.121297] ? sock_do_ioctl+0x4d/0xf0
[ 914.121329] sock_ioctl+0x262/0x340
[ 914.121347] ? sock_ioctl+0x262/0x340
[ 914.121362] ? exit_to_user_mode_prepare+0x13b/0x280
[ 914.121388] ? syscall_enter_from_user_mode+0x20/0x50
[ 914.121416] __x64_sys_ioctl+0x96/0xd0
[ 914.121430] ? br_ioctl_call+0x90/0x90
[ 914.121445] ? __x64_sys_ioctl+0x96/0xd0
[ 914.121465] do_syscall_64+0x3d/0xd0
[ 914.121482] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 914.121497] RIP: 0033:0x7f0ed051737b
[ 914.121513] Code: 0f 1e fa 48 8b 05 15 3b 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e5 3a 0d 00 f7 d8 64 89 01 48
[ 914.121527] RSP: 002b:00007fff7be38b98 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[ 914.121544] RAX: ffffffffffffffda RBX: 00007fff7be38ba0 RCX: 00007f0ed051737b
[ 914.121555] RDX: 00007fff7be38ba0 RSI: 0000000000008914 RDI: 0000000000000004
[ 914.121566] RBP: 00007fff7be38c60 R08: 000000000000000a R09: 0000000000000001
[ 914.121576] R10: 0000000000000000 R11: 0000000000000202 R12: 00000000fffffffe
[ 914.121586] R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
[ 914.121620] </TASK>
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 <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211201071745.17746-2-quic_wgong@quicinc.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for v5.17
First set of patches for v5.17. The biggest change is the iwlmei
driver for Intel's AMT devices. Also now WCN6855 support in ath11k
should be usable.
Major changes:
ath10k
* fetch (pre-)calibration data via nvmem subsystem
ath11k
* enable 802.11 power save mode in station mode for qca6390 and wcn6855
* trace log support
* proper board file detection for WCN6855 based on PCI ids
* BSS color change support
rtw88
* add debugfs file to force lowest basic rate
* add quirk to disable PCI ASPM on HP 250 G7 Notebook PC
mwifiex
* add quirk to disable deep sleep with certain hardware revision in
Surface Book 2 devices
iwlwifi
* add iwlmei driver for co-operating with Intel's Active Management
Technology (AMT) devices
* tag 'wireless-drivers-next-2021-12-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next: (87 commits)
iwlwifi: mei: fix linking when tracing is not enabled
rtlwifi: rtl8192de: Style clean-ups
mwl8k: Use named struct for memcpy() region
intersil: Use struct_group() for memcpy() region
libertas_tf: Use struct_group() for memcpy() region
libertas: Use struct_group() for memcpy() region
wlcore: no need to initialise statics to false
rsi: Fix out-of-bounds read in rsi_read_pkt()
rsi: Fix use-after-free in rsi_rx_done_handler()
brcmfmac: Configure keep-alive packet on suspend
wilc1000: remove '-Wunused-but-set-variable' warning in chip_wakeup()
iwlwifi: mvm: read the rfkill state and feed it to iwlmei
iwlwifi: mvm: add vendor commands needed for iwlmei
iwlwifi: integrate with iwlmei
iwlwifi: mei: add debugfs hooks
iwlwifi: mei: add the driver to allow cooperation with CSME
mei: bus: add client dma interface
mwifiex: Ignore BTCOEX events from the 88W8897 firmware
mwifiex: Ensure the version string from the firmware is 0-terminated
mwifiex: Add quirk to disable deep sleep with certain hardware revision
...
====================
Link: https://lore.kernel.org/r/20211207144211.A9949C341C1@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
If the iwlmei code is a loadable module, the main iwlwifi driver
cannot be built-in:
x86_64-linux-ld: drivers/net/wireless/intel/iwlwifi/pcie/trans.o: in function `iwl_pcie_prepare_card_hw':
trans.c:(.text+0x4158): undefined reference to `iwl_mei_is_connected'
Unfortunately, Kconfig enforces the opposite, forcing the MEI driver to
not be built-in if iwlwifi is a module.
To work around this, decouple iwlmei from iwlwifi and add the
dependency in the other direction.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211207151447.3338818-1-arnd@kernel.org
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Normally, when we hit an assert, we print out all the
assert data. However, in certain tests, when we trigger
it from debugfs intentionally, that can be useless and
confusing.
Allow writing the string "nolog\n" to the fw_nmi and
fw_restart files suppressing the assert dump as well
as - in the case of fw_restart - the
iwlwifi 0000:00:00.0: FW error in SYNC CMD REPLY_ERROR
message.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.75e29a2ab68d.Id3064feda2ce7a77c116c6d6e71ce5ff447c6e86@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Add new Qu-Hr killer device id.
Signed-off-by: Yaara Baruch <yaara.baruch@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.997c250b9edc.Id50730e3e342297432eed47cdf9678ee16cf6d17@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
This is part of the "device memory" type, but with the
subtypes we can now detect it properly, rather than
having to make assumptions on the ID.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.91d33aa9dd3d.Ifb48e21fbb92ea25360856b5cc2afbb9b485d6b3@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
On Bz devices, UREG_DOORBELL_TO_ISR6_NMI_BIT no longer actually
triggers an NMI. So instead of setting BIT(0) | BIT(1) for the
reset flow, we need to just set BIT(1) and then force the NMI
in the new way.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.6b56e7ee1773.I71cba66e17cc0daabc5ad7abd88763674b625c82@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Add new Qu-Hr device ID.
Signed-off-by: Yaara Baruch <yaara.baruch@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.c68af5f8d7ce.I37894e98080161c3bca6f33b99a5b8812166ee41@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Fix FW name for gl use the crf fm and not fm7, since the
later no longer exists.
Signed-off-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.497b2f2c587d.If71fa8cbed043c15f927bb78cb8a695625a362dd@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Yoyo based debug is not applicable for 8000 and below old devices.
The check added in code has 9000 and below familiy which is corrected.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.b6176a5bc198.Ib8e4b1e60e0b6c1538cc4f384dcf681b3db097ce@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Support reading the SAR Geographic Offset Mapping (SGOM) table from UEFI
to allow OEMs to override the values according to geographical regions.
Signed-off-by: Ayala Barazani <ayala.barazani@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174546.e6dfd8b5dd40.Ibc9a8fe2bfde345f49df5d57ec56663da6a53dc4@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
In most cases, unless shutting down the NIC, we really need
to retake ownership after doing a software reset of the NIC.
Encode that into the API so we "automatically" do it, even
in case of workarounds, and don't keep forgetting it like a
few of the places we have did.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204174545.458f9d98ac21.I40b9a22df1ab8178cc838fc83d5190e689dfac6a@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
