summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2022-09-22wifi: rndis_wlan: fix array of flexible structures warningJohannes Berg1-2/+3
Use "u8 bssid_data[]" with an appropriate cast. No binary changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220904212910.0e7ce5fdbcfb.I972158734def3f93b93a3858a087cbc2cca6337e@changeid
2022-09-22wifi: ipw2x00: fix array of flexible structures warningsJohannes Berg2-12/+11
There are a number of these here, fix them by using appropriate casts. No binary changes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220904212910.645346411660.I471e8fadce54ea262920828f25b8e84545bcd07e@changeid
2022-09-22mwifiex: fix sleep in atomic context bugs caused by dev_coredumpvDuoming Zhou3-8/+10
There are sleep in atomic context bugs when uploading device dump data in mwifiex. The root cause is that dev_coredumpv could not be used in atomic contexts, because it calls dev_set_name which include operations that may sleep. The call tree shows execution paths that could lead to bugs: (Interrupt context) fw_dump_timer_fn mwifiex_upload_device_dump dev_coredumpv(..., GFP_KERNEL) dev_coredumpm() kzalloc(sizeof(*devcd), gfp); //may sleep dev_set_name kobject_set_name_vargs kvasprintf_const(GFP_KERNEL, ...); //may sleep kstrdup(s, GFP_KERNEL); //may sleep The corresponding fail log is shown below: [ 135.275938] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start [ 135.281029] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265 ... [ 135.293613] Call Trace: [ 135.293613] <IRQ> [ 135.293613] dump_stack_lvl+0x57/0x7d [ 135.293613] __might_resched.cold+0x138/0x173 [ 135.293613] ? dev_coredumpm+0xca/0x2e0 [ 135.293613] kmem_cache_alloc_trace+0x189/0x1f0 [ 135.293613] ? devcd_match_failing+0x30/0x30 [ 135.293613] dev_coredumpm+0xca/0x2e0 [ 135.293613] ? devcd_freev+0x10/0x10 [ 135.293613] dev_coredumpv+0x1c/0x20 [ 135.293613] ? devcd_match_failing+0x30/0x30 [ 135.293613] mwifiex_upload_device_dump+0x65/0xb0 [ 135.293613] ? mwifiex_dnld_fw+0x1b0/0x1b0 [ 135.293613] call_timer_fn+0x122/0x3d0 [ 135.293613] ? msleep_interruptible+0xb0/0xb0 [ 135.293613] ? lock_downgrade+0x3c0/0x3c0 [ 135.293613] ? __next_timer_interrupt+0x13c/0x160 [ 135.293613] ? lockdep_hardirqs_on_prepare+0xe/0x220 [ 135.293613] ? mwifiex_dnld_fw+0x1b0/0x1b0 [ 135.293613] __run_timers.part.0+0x3f8/0x540 [ 135.293613] ? call_timer_fn+0x3d0/0x3d0 [ 135.293613] ? arch_restore_msi_irqs+0x10/0x10 [ 135.293613] ? lapic_next_event+0x31/0x40 [ 135.293613] run_timer_softirq+0x4f/0xb0 [ 135.293613] __do_softirq+0x1c2/0x651 ... [ 135.293613] RIP: 0010:default_idle+0xb/0x10 [ 135.293613] RSP: 0018:ffff888006317e68 EFLAGS: 00000246 [ 135.293613] RAX: ffffffff82ad8d10 RBX: ffff888006301cc0 RCX: ffffffff82ac90e1 [ 135.293613] RDX: ffffed100d9ff1b4 RSI: ffffffff831ad140 RDI: ffffffff82ad8f20 [ 135.293613] RBP: 0000000000000003 R08: 0000000000000000 R09: ffff88806cff8d9b [ 135.293613] R10: ffffed100d9ff1b3 R11: 0000000000000001 R12: ffffffff84593410 [ 135.293613] R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff11000c62fd2 ... [ 135.389205] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end This patch uses delayed work to replace timer and moves the operations that may sleep into a delayed work in order to mitigate bugs, it was tested on Marvell 88W8801 chip whose port is usb and the firmware is usb8801_uapsta.bin. The following is the result after using delayed work to replace timer. [ 134.936453] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start [ 135.043344] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end As we can see, there is no bug now. Fixes: f5ecd02a8b20 ("mwifiex: device dump support for usb interface") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Reviewed-by: Brian Norris <briannorris@chromium.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/5cfa5c473ff6d069cb67760ffa04a2f84ef450a8.1661252818.git.duoming@zju.edu.cn
2022-09-19wifi: ath11k: Add WoW support for WCN6750Manikanta Pubbisetty7-1/+191
Add support for WoW on WCN6750 chipset. Unlike other chips where WoW exit happens after sending WoW wakeup WMI command, exit from WoW suspend in the case of WCN6750 happens upon sending a WoW exit SMP2P (Shared memory point to point) message to the firmware. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220902112520.24804-3-quic_mpubbise@quicinc.com
2022-09-19wifi: ath11k: Include STA_KEEPALIVE_ARP_RESPONSE TLV header by defaultBaochen Qiang2-5/+6
In current code STA_KEEPALIVE_ARP_RESPONSE TLV header is included only when ARP method is used, this causes firmware always to crash when wowlan is enabled because firmware needs it to be present no matter ARP method is used or not. Fix this issue by including STA_KEEPALIVE_ARP_RESPONSE TLV header by default. Also fix below typo: s/WMI_TAG_STA_KEEPALVE_ARP_RESPONSE/WMI_TAG_STA_KEEPALIVE_ARP_RESPONSE/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: 0f84a156aa3b ("ath11k: Handle keepalive during WoWLAN suspend and resume") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220913044358.2037-1-quic_bqiang@quicinc.com
2022-09-19wifi: wcn36xx: fix repeated words in commentsJilin Yuan1-1/+1
Delete the redundant word 'that'. Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220915030428.38510-1-yuanjilin@cdjrlc.com
2022-09-19wifi: wcn36xx: Add RX frame SNR as a source of system entropyBryan O'Donoghue1-0/+4
The signal-to-noise-ratio SNR is returned by the wcn36xx firmware for each received frame. SNR represents all of the unwanted interference signal after filtering out the fundamental frequency and harmonics of the frequency. Noise can come from various electromagnetic sources, from temperature affecting the performance hardware components or quantization effects converting from analog to digital domains. The SNR value returned by the WiFi firmware then is a good source of entropy. Other WiFi drivers offer up the noise component of the FFT as an entropy source for the random pool e.g. commit 2aa56cca3571 ("ath9k: Mix the received FFT bins to the random pool") I attended Jason's talk on sources of randomness at Plumbers and it occurred to me that SNR is a reasonable candidate to add. Cc: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220915004117.1562703-2-bryan.odonoghue@linaro.org
2022-09-19wifi: rtw89: uninitialized variable on error in ↵Dan Carpenter1-1/+1
rtw89_early_fw_feature_recognize() If request_partial_firmware_into_buf() fails then "firmware" is not initialized and the release_firmware(firmware) will crash. Fixes: deebea35d699 ("wifi: rtw89: early recognize FW feature to decide if chanctx") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/YyMzDtX/3fUBnonC@kili
2022-09-19wifi: rt2x00: Fix "Error - Attempt to send packet over invalid queue 2"Hans de Goede1-1/+4
Even though ieee80211_hw.queues is set to 2, the ralink rt2x00 driver is seeing tx skbs submitted to it with the queue-id set to 2 / set to IEEE80211_AC_BE on a rt2500 card when associating with an access-point. This causes rt2x00queue_get_tx_queue() to return NULL and the following error to be logged: "ieee80211 phy0: rt2x00mac_tx: Error - Attempt to send packet over invalid queue 2", after which association with the AP fails. This patch works around this by mapping QID_AC_BE and QID_AC_BK to QID_AC_VI when there are only 2 tx_queues. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220908173618.155291-2-hdegoede@redhat.com
2022-09-19wifi: rtw89: 8852c: add multi-port ID to TX descriptorPo-Hao Huang1-1/+2
Update tx descriptor settings so broadcast packets on other ports can be issued properly when DTIM count is 0. Before this, all broadcast packets are sent via port 0 and won't be transmitted correctly. 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/20220916033811.13862-8-pkshih@realtek.com
2022-09-19wifi: rtw89: fix rx filter after scanPo-Hao Huang1-7/+5
In monitor mode we should be able to received all packets even if it's not destined to us. But after scan, the configuration was wrongly set, so we fix it. 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/20220916033811.13862-7-pkshih@realtek.com
2022-09-19wifi: rtw89: free unused skb to prevent memory leakPo-Hao Huang1-0/+1
This avoid potential memory leak under power saving mode. 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/20220916033811.13862-6-pkshih@realtek.com
2022-09-19wifi: rtw89: reset halt registers before turn on wifi CPUPing-Ke Shih1-0/+2
Reset these registers to prevent firmware get false alarm after wifi CPU is running. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220916033811.13862-5-pkshih@realtek.com
2022-09-19wifi: rtw89: pci: update LTR settingsPing-Ke Shih2-4/+5
Modify PCI LTR control flow and LTR idle latency to improve power save efficiency. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220916033811.13862-4-pkshih@realtek.com
2022-09-19wifi: rtw89: mac: set NAV upper to 25msPing-Ke Shih2-1/+2
NAV upper register is to limit the maximum NAV value to prevent unexpected NAV, but the old setting is too small to reflect NAV from AP transmiting big MPDU at once. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220916033811.13862-3-pkshih@realtek.com
2022-09-19wifi: rtw89: initialize DMA of CMACPing-Ke Shih2-0/+47
8852C needs this to change CMAC dma to full mode to keep receiving packets after RX full event being resolved. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220916033811.13862-2-pkshih@realtek.com
2022-09-19wifi: rtw89: support SER L1 simulationZong-Zhe Yang5-16/+61
SER (system error recovery) can deal with different crash types by different levels of processes. Previous FW crash simulation triggers a CPU exception which is one kind of SER L2 type. It can verify SER L2 flow which includes HW/FW restart. Now, we want to increase crash simulation types. A debug function is added to trigger control error in purpose for SER L1 simulation/verification. And, debugfs fw_crash is extended to accept different parameters. echo 1 > fw_crash: simulate CPU exception as before (keep 1 for compatibility with previous) It will be catched and handled by SER L2. (this requires HW/FW restart) echo 2 > fw_crash: simulate control error It will be catched and handled by SER L1. (driver and FW cooperate to recover this) Besides, in order to apply to the above two cases, rename RTW89_FLAG_RESTART_TRIGGER to RTW89_FLAG_CRASH_SIMULATING and adjust where SER flow clears this bit for both L1 and L2. 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/20220914035034.14521-5-pkshih@realtek.com
2022-09-19wifi: rtw89: 8852c: support fw crash simulationZong-Zhe Yang3-2/+3
With FW >= v0.27.40.0, 8852C FW has feature to handle crash simulation. Besides, use RTW89_WCPU_BASE_MASK to replace use of RTW89_WCPU_BASE_ADDR and work for both 8852A and 8852C. 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/20220914035034.14521-4-pkshih@realtek.com
2022-09-19wifi: rtw89: introudce functions to drop packetsZong-Zhe Yang6-1/+183
Introudce a H2C feature to drop packets according to given parameters. And, we implement instances to drop packets from BE, BK, VI, VO queues by vif or sta. Then, we refine our callback of ieee80211_ops::flush to deal with the case of drop=true via this feature. 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/20220914035034.14521-3-pkshih@realtek.com
2022-09-19wifi: rtw89: unify use of rtw89_h2c_tx()Ping-Ke Shih1-62/+123
Seaprate calling of rtw89_h2c_tx() out of if-expression, and bypass the return value to upper caller. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220914035034.14521-2-pkshih@realtek.com
2022-09-19wifi: rtw89: pci: concentrate control function of TX DMA channelChin-Yen Lee4-14/+39
Different chips use different register and mask for tx dma channels, so concentrate them. Signed-off-by: Chin-Yen Lee <timlee@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/20220912071706.13619-4-pkshih@realtek.com
2022-09-19wifi: rtw89: correct enable functions of HCI/PCI DMAChin-Yen Lee4-79/+79
Some PCI and MAC registers are changed for different chips and correct them accordingly. And HCI MAD functions belongs to MAC core, so move it to mac.h/.c. Signed-off-by: Chin-Yen Lee <timlee@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/20220912071706.13619-3-pkshih@realtek.com
2022-09-19wifi: rtw89: 8852c: L1 DMA reset has offloaded to FWZong-Zhe Yang1-0/+6
For 8852C, rtw89_pci_lv1rst_stop_dma() and rtw89_pci_lv1rst_start_dma() are offloaded to FW L1 reset flow. So, driver no longer needs to do them. 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/20220912071706.13619-2-pkshih@realtek.com
2022-09-19wifi: rtw89: support for setting TID specific configurationKuan-Chung Chen3-13/+88
Add ops set_tid_config to support TID specific configuration. We currently only support ampdu setting. The command example is: iw wlan0 set tidconf tids 0x3 ampdu off iw wlan0 set tidconf peer xx:xx:xx:xx:xx:xx tids 0x2 ampdu on Signed-off-by: Kuan-Chung Chen <damon.chen@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/20220912070014.10018-3-pkshih@realtek.com
2022-09-19wifi: rtw89: support for setting HE GI and LTFKuan-Chung Chen4-1/+54
Support setting HE GI and LTF values to the kernel via nl80211. We currently only support some GI and LTF values settings. The command example is: iw wlan0 set bitrates he-gi-2.4 0.8 he-ltf-2.4 2 Signed-off-by: Kuan-Chung Chen <damon.chen@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/20220912070014.10018-2-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: show connecting state in debug messagePing-Ke Shih1-2/+2
The variable cnt_connecting is to indicate if we are connecting to an AP. This is an important clue for coexistence to assign more time slot to WiFi side in this situation to ensure WiFi can establish connection. Without this patch, compiler warns: drivers/net/wireless/realtek/rtw89/coex.c:3244:25: warning: variable 'cnt_connecting' set but not used [-Wunused-but-set-variable] Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220912021009.6011-1-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: Combine set grant WL/BT and correct the debug logChing-Te Ku3-105/+118
To reduce register IO, combine set_gnt_wl/set_gnt_bt to set the same register one time. Because RTL8852C use different register to control antenna path, so make correction of path control related debug logs. Signed-off-by: Ching-Te Ku <ku920601@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/20220913092546.43722-8-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: Remove trace_step at COEX-MECH control structure for RTL8852CChing-Te Ku1-1/+3
RTL8852C don't need to send the data trace_step which used to tell firmware how many TDMA steps should record. Remove the member. Signed-off-by: Ching-Te Ku <ku920601@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/20220913092546.43722-7-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: Parsing Wi-Fi firmware TDMA info from reportsChing-Te Ku1-1/+5
Show TDMA information containing TDMA policy and time slot of Wi-Fi/BT in debug message to check things are in expected. The v1 format contains additional header, and remaining part is the same as original. So 8852CE selects v1 version, and then everything like original. Signed-off-by: Ching-Te Ku <ku920601@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/20220913092546.43722-6-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: Parsing Wi-Fi firmware error message from reportsChing-Te Ku1-6/+16
Parsing firmware error message from original version and v1 reports to show up exception counter of commands from firmware in debug message. Then, we can make sure exchange commands are correct totally. In the later version Wi-Fi firmware(v1), the report format was changed. With this update, we can yield correct report from proper struct. Signed-off-by: Ching-Te Ku <ku920601@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/20220913092546.43722-5-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: Move coexistence firmware buffer size parameter to chip infoChing-Te Ku4-3/+5
Because RTL8852A/RTL8852C use different firmware buffer size to send C2H packet, it's necessary to use different size to parse C2H report. Signed-off-by: Ching-Te Ku <ku920601@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/20220913092546.43722-4-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: Add v1 Wi-Fi firmware power-saving null data reportChing-Te Ku2-22/+74
The later version Wi-Fi firmware will report null data TX times, so the structure is different from before. Signed-off-by: Ching-Te Ku <ku920601@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/20220913092546.43722-3-pkshih@realtek.com
2022-09-19wifi: rtw89: coex: use void pointer as temporal type to copy reportPing-Ke Shih1-16/+17
With void pointer, we don't need to cast to 'u8 *' by one by. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220913092546.43722-2-pkshih@realtek.com
2022-09-19wifi: brcmfmac: pcie: Add IDs/properties for BCM4378Hector Martin3-0/+12
This chip is present on Apple M1 (t8103) platforms: * atlantisb (apple,j274): Mac mini (M1, 2020) * honshu (apple,j293): MacBook Pro (13-inch, M1, 2020) * shikoku (apple,j313): MacBook Air (M1, 2020) * capri (apple,j456): iMac (24-inch, 4x USB-C, M1, 2020) * santorini (apple,j457): iMac (24-inch, 2x USB-C, M1, 2020) Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDoD-0077ax-AI@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: pcie: Support PCIe core revisions >= 64Hector Martin1-20/+105
These newer PCIe core revisions include new sets of registers that must be used instead of the legacy ones. Introduce a brcmf_pcie_reginfo to hold the specific register offsets and values to use for a given platform, and change all the register accesses to indirect through it. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDo8-0077aq-6I@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: msgbuf: Increase RX ring sizes to 1024Hector Martin1-2/+2
Newer chips used on Apple platforms have a max_rxbufpost greater than 512, which causes warnings when brcmf_msgbuf_rxbuf_data_fill tries to put more entries in the ring than will fit. Increase the ring sizes to 1024. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDo3-0077ak-2h@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: firmware: Allow platform to override macaddrHector Martin1-2/+30
On Device Tree platforms, it is customary to be able to set the MAC address via the Device Tree, as it is often stored in system firmware. This is particularly relevant for Apple ARM64 platforms, where this information comes from system configuration and passed through by the bootloader into the DT. Implement support for this by fetching the platform MAC address and adding or replacing the macaddr= property in nvram. This becomes the dongle's default MAC address. On platforms with an SROM MAC address, this overrides it. On platforms without one, such as Apple ARM64 devices, this is required for the firmware to boot (it will fail if it does not have a valid MAC at all). Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnx-0077ae-VK@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: pcie: Perform firmware selection for Apple platformsHector Martin1-2/+38
On Apple platforms, firmware selection uses the following elements: Property Example Source ============== ======= ======================== * Chip name 4378 Device ID * Chip revision B1 OTP * Platform shikoku DT (ARM64) or ACPI (x86) * Module type RASP OTP * Module vendor m OTP * Module version 6.11 OTP * Antenna SKU X3 DT (ARM64) or ACPI (x86) In macOS, these firmwares are stored using filenames in this format under /usr/share/firmware/wifi: C-4378__s-B1/P-shikoku-X3_M-RASP_V-m__m-6.11.txt To prepare firmwares for Linux, we rename these to a scheme following the existing brcmfmac convention: brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<mod_type>-\ <mod_vendor>-<mod_version>-<antenna_sku>.txt The NVRAM uses all the components, while the firmware and CLM blob only use the chip/revision/platform/antenna_sku: brcmfmac<chip><lower(rev)>-pcie.apple,<platform>-<antenna_sku>.bin e.g. brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.bin In addition, since there are over 1000 files in total, many of which are symlinks or outright duplicates, we deduplicate and prune the firmware tree to reduce firmware filenames to fewer dimensions. For example, the shikoku platform (MacBook Air M1 2020) simplifies to just 4 files: brcm/brcmfmac4378b1-pcie.apple,shikoku.clm_blob brcm/brcmfmac4378b1-pcie.apple,shikoku.bin brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-u.txt This reduces the total file count to around 170, of which 75 are symlinks and 95 are regular files: 7 firmware blobs, 27 CLM blobs, and 61 NVRAM config files. We also slightly process NVRAM files to correct some formatting issues. To handle this, the driver must try the following path formats when looking for firmware files: brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11-X3.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m-6.11.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP-m.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-RASP.txt brcm/brcmfmac4378b1-pcie.apple,shikoku-X3.txt * brcm/brcmfmac4378b1-pcie.apple,shikoku.txt * Not relevant for NVRAM, only for firmware/CLM. The chip revision nominally comes from OTP on Apple platforms, but it can be mapped to the PCI revision number, so we ignore the OTP revision and continue to use the existing PCI revision mechanism to identify chip revisions, as the driver already does for other chips. Unfortunately, the mapping is not consistent between different chip types, so this has to be determined experimentally. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDns-0077aY-Qn@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: of: Fetch Apple propertiesHector Martin2-1/+12
On Apple ARM64 platforms, firmware selection requires two properties that come from system firmware: the module-instance (aka "island", a codename representing a given hardware platform) and the antenna-sku. We map Apple's module codenames to board_types in the form "apple,<module-instance>". The mapped board_type is added to the DTS file in that form, while the antenna-sku is forwarded by our bootloader from the Apple Device Tree into the FDT. Grab them from the DT so firmware selection can use them. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnn-0077aS-NA@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: pcie: Read Apple OTP informationHector Martin1-0/+218
On Apple platforms, the One Time Programmable ROM in the Broadcom chips contains information about the specific board design (module, vendor, version) that is required to select the correct NVRAM file. Parse this OTP ROM and extract the required strings. Note that the user OTP offset/size is per-chip. This patch does not add any chips yet. Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDni-0077aM-I6@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: firmware: Support passing in multiple board_typesHector Martin4-14/+49
Apple platforms have firmware and config files identified with multiple dimensions. We want to be able to find the most specific firmware available for any given platform, progressively trying more general firmwares. To do this, first add support for passing in multiple board_types, which will be tried in sequence. Since this will cause more log spam due to missing firmwares, also switch the secondary firmware fecthes to use the _nowarn variant, which will not log if the firmware is not found. Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnd-0077aG-Dk@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: pcie/sdio/usb: Get CLM blob via standard firmware mechanismHector Martin6-62/+69
Now that the firmware fetcher can handle per-board CLM files, load the CLM blob alongside the other firmware files and change the bus API to just return the existing blob, instead of fetching the filename. This enables per-board CLM blobs, which are required on Apple platforms. Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnY-0077aA-8f@rmk-PC.armlinux.org.uk
2022-09-19wifi: brcmfmac: firmware: Handle per-board clm_blob filesHector Martin1-13/+20
Teach brcm_alt_fw_paths to correctly split off variable length extensions, and enable alt firmware lookups for the CLM blob firmware requests. Apple platforms have per-board CLM blob files. Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/E1oZDnT-0077a4-4k@rmk-PC.armlinux.org.uk
2022-09-18wifi: iwlwifi: mvm: d3: parse keys from wowlan info notificationNaftali Goldstein1-83/+88
This notification replaces the WOWLAN_GET_STATUSES command-and-response, so it's required to parse all the keys in the notification just like what happened when that command was used. Move around a few required static functions in order to avoid forward declarations. Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.ca3fb23cab81.I0a9fe7729af4567b98813bc51bad13ee5512a0ae@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: iterate over interfaces after an assert in d3Yedidya Benshimol1-7/+11
In recent patches notifications based d3 resume flow was added, and the resume flow was changed. Currently, when resuming from d3 during which an assert was thrown, the resume flow skips the iteration over active interfaces preventing the sta to reconnect to the ap. Perform the iteration in case an assert was thrown to fix it. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.ad888cc6cd91.Ib56e416fce17df089edf76d22896430df5ebe080@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: trigger resume flow before wait for notificationsHaim, Dreyfuss1-34/+43
We have recently enabled resume flow based on notifications. These notifications are sent by the FW when completing the resume flow. From IWL_DEVICE_FAMILY_AX210 the resume flow is triggered by the transport layer on iwl_trans_d3_resume. On IWL_DEVICE_FAMILY_22000 and earlier we trigger the resume flow by sending the D0I3 command. Currently, we are waiting for the notifications before sending the command, the notifications won't be sent by the FW since there is no resume trigger to piggyback on. Send the command before starting the wait flow to fix it. Signed-off-by: Haim, Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.5f0f251edf9c.Ia49ab73105af6f52aa7d318f4984edecd3b0671a@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: Add handling for scan offload match info notificationIlan Peer4-59/+166
To support FW versions that send the scan match information as an asynchronous notification. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.bbc5602d0b6f.I1329c231f82e7bf18f7dba0ccbd9f2d4080cbfc1@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: enable resume based on notificationsHaim Dreyfuss1-2/+11
We have recently added support for resume based on notifications. Enable it. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.a6344ba23df5.I09fce8cf5aac1d46b40ae81b1abcf7a0e54af196@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: Add support for d3 end notificationHaim Dreyfuss4-4/+44
Due to IMR, when host returns from hibernate, commands cannot be sent as part of the resume flow, and so after ending d3 the FW needs to send notifications instead of responses. This notification indicates whether a fw reset is required. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.898ecba881b2.I13eb69bb5af08b9ac33043647eaed6b8d50e8659@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
2022-09-18wifi: iwlwifi: mvm: Add support for wowlan wake packet notificationHaim Dreyfuss4-28/+118
The wowlan info notification is quite big. (~750 bytes without the wake packet itself). The max FW notification size is ~2K. There might be cases where the wake packet gets truncated because of this limit. Separating the wake packet from the wowlan info notification allows us to get more data without trimming it. Note: we currently limit the wake packet to 1600 bytes. Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20220906161827.06d1e6aecf10.Ib3d6a46ffe71d10cbc69bdb5654e6b14c28df245@changeid Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-28 06:12:06 +0300