- 21 Sep, 2023 3 commits
-
-
Prasurjya Rohan Saikia authored
Add an algorithm to backoff the Tx Task when low memory scenario is triggered at firmware. During high data transfer from host, the firmware runs out of VMM memory, which is used to hold the frames from the host. So, adding the flow control delays the transmit from host side when there is not enough space to accommodate frames in firmware side. Signed-off-by: Prasurjya Rohan Saikia <prasurjya.rohansaikia@microchip.com> Acked-by: Ajay Singh <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230915175946.4361-1-prasurjya.rohansaikia@microchip.com
-
Víctor Gonzalo authored
The mwifiex_pcie driver is missing the MODULE_FIRMWARE macro to add the firmware files needed to the module metadata. Signed-off-by: Víctor Gonzalo <victor.gonzalo@anddroptable.net> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230914211938.28395-1-victor.gonzalo@anddroptable.net
-
Dmitry Antipov authored
Drop filled with NULL pointers but otherwise unused 'skb_arr' array of 'struct mwifiex_sdio_mpa_rx', adjust related code. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230821115254.167552-1-dmantipov@yandex.ru
-
- 20 Sep, 2023 3 commits
-
-
Jinjie Ruan authored
Since debugfs_create_file() return ERR_PTR and never return NULL, so use IS_ERR() to check it instead of checking NULL. Fixes: e3037485 ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230919050651.962694-1-ruanjinjie@huawei.com
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct brcmf_fw_request. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Arend van Spriel <aspriel@gmail.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Hector Martin <marcan@marcan.st> Cc: "Alvin Šipraga" <alsi@bang-olufsen.dk> Cc: Hans de Goede <hdegoede@redhat.com> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: SHA-cyfmac-dev-list@infineon.com Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230915200552.never.642-kees@kernel.org
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct brcmf_gscan_config. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Arend van Spriel <aspriel@gmail.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Hector Martin <marcan@marcan.st> Cc: Ryohei Kondo <ryohei.kondo@cypress.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: SHA-cyfmac-dev-list@infineon.com Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230915200542.never.417-kees@kernel.org
-
- 18 Sep, 2023 18 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. wlcore_remove() returned zero unconditionally. With that converted to return void instead, the wl12xx and wl18xx driver can be converted to .remove_new trivially. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230912171249.755901-1-u.kleine-koenig@pengutronix.de
-
Zenm Chen authored
According to the driver provided by EDIMAX, the device ID 0x7392:0xb722 belongs to EDIMAX EW-7722UTn V3, so add a comment about this. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230912053614.10644-1-zenmchen@gmail.com
-
Ping-Ke Shih authored
Using mac_gen pointer to reuse the code with WiFi 7 chips, and define MAC ports registers for WiFi 7 chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230911082049.33541-7-pkshih@realtek.com
-
Ping-Ke Shih authored
MAC port is a design to support virtual interface on single MAC hardware. For next generation chips, register addresses are changed but definitions are the same, so move registers together to be easier to reuse codes. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230911082049.33541-6-pkshih@realtek.com
-
Ping-Ke Shih authored
For existing chips, size of TX WD info is 6 words, but upcoming WiFi 7 chips become 8 words, so add a chip_info to reuse the code. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230911082049.33541-5-pkshih@realtek.com
-
Ping-Ke Shih authored
The format v2 of TX descriptor contains 8-word body and 8-word info, and fields include packet size, MAC_ID, security key ID and etc. By design, it can possibly only fill body to reduce overhead, but this driver keeps thing simple, so always fill body and info currently. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230911082049.33541-4-pkshih@realtek.com
-
Ping-Ke Shih authored
This kind of TX descriptor is used to download firmware or send firmware command. Because we want to reduce descriptor overhead and this only needs two fields 'size' and 'type', hardware designers choose short form of RX descriptor for it. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230911082049.33541-3-pkshih@realtek.com
-
Ping-Ke Shih authored
RX descriptor is used to provide meta data of received data. The WiFi 7 chips use different RX descriptor format, so add this parser along with hardware design. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230911082049.33541-2-pkshih@realtek.com
-
Zong-Zhe Yang authored
In MCC STA+GO mode, we calculate NoA information and fill it into the beacon of P2P GO. Since NoA uses only 32 bits to describe time things, we need to deal with renewal when TSF[63:32] is carried. We trigger FW to notify that. Then, we can update NoA information for new time period once we get notification from FW. 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/20230908031145.20931-9-pkshih@realtek.com
-
Zong-Zhe Yang authored
When receiving request of adjusting BT slot from coex. mechanism, we need to fetch the new BT slot and use the new one to calculate MCC (multi-channel concurrency) pattern. Then, we update the new MCC pattern to FW. 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/20230908031145.20931-8-pkshih@realtek.com
-
Zong-Zhe Yang authored
MCC fills duration limit of a role according to NoA description. If P2P PS changes during MCC, we don't process P2P PS via normal flow. Instead, we re-fill duration limit of the role for new NoA description, and then we do MCC update. 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/20230908031145.20931-7-pkshih@realtek.com
-
Zong-Zhe Yang authored
In MCC STA+GC mode, the offset between TBTTs of remote AP and remote GO might change. If the change is larger than tolerance, we should update MCC after re-calculating parameters for new things. So, we track that in rtw89_track_work() now. And, we add MCC update flow to tell FW either to change durations of roles or to replace entire pattern according to how MCC plans BT slot. 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/20230908031145.20931-6-pkshih@realtek.com
-
Zong-Zhe Yang authored
Each MCC (multi-channel concurrency) role maintains a bitmap of mac IDs. The bitmap is supposed to contain the two points below. * mac ID of itself * mac ID(s) of STA(s) connecting to it Under STA+GC mode, the bitmaps of both roles should not change. However, under STA+GO mode, the bitmap of GO may change due to P2P clients which connect/disconnect to/from it. FW controls (TDMA-based) MCC things via mac IDs in bitmap of each role. For example, mac IDs are required by FW when it wants to pause role1's TX in role0 slot. So, to sync between driver and FW, we update the new mac ID bitmap of GO to FW once it's changed. 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/20230908031145.20931-5-pkshih@realtek.com
-
Zong-Zhe Yang authored
DPK is one kind of RF calibration. When MCC (multi-channel concurrency) start/stop, DPK needs to do extra things to be off/on. We add a chanctx callback type, RTW89_CHANCTX_CALLBACK_RFK, and register it for RTL8852C to deal with DPK according to MCC states. 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/20230908031145.20931-4-pkshih@realtek.com
-
Zong-Zhe Yang authored
After MCC (multi-channel concurrency) is started, FW will control channel changes and use the corresponding backup of RF calibration result. And, driver RF calibration (RF-K) won't be able to keep up with the speed at which the channels are changing. So, even if we keep tracking it in driver, the RF-K result might not be good either. To save these unnecessary things, we disable driver RF-K tracking during MCC. 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/20230908031145.20931-3-pkshih@realtek.com
-
Zong-Zhe Yang authored
RF calibration will notify FW to backup the calibration result after it is done on a channel. For MCC (multi-channel concurrency) flow, when we at RTW89_ENTITY_MODE_MCC_PREPARE mode, RF calibration should execute on second channel of MCC, i.e. RTW89_SUB_ENTITY_1, and then, notify FW to backup the result for the second one. Originally, the RF calibration flow only fit single channel case. We are planning to support MCC on RTL8852C, so we refine its RF calibration flow to fit MCC 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@kernel.org> Link: https://lore.kernel.org/r/20230908031145.20931-2-pkshih@realtek.com
-
Jeff Johnson authored
While converting struct ieee80211_tim_ie::virtual_map to be a flexible array it was observed that the TIM IE processing in cw1200_rx_cb() could potentially process a malformed IE in a manner that could result in a buffer over-read. Add logic to verify that the TIM IE length is large enough to hold a valid TIM payload before processing it. Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230831-ieee80211_tim_ie-v3-1-e10ff584ab5d@quicinc.com
-
Wen Gong authored
6 GHz regulatory domains introduces Power Spectral Density (PSD). The PSD value of the regulatory rule should be taken into effect for the ieee80211_channels falling into that particular regulatory rule. Save the values in the channel which has PSD value and add nl80211 attributes accordingly to handle it. Co-developed-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Link: https://lore.kernel.org/r/20230914082026.3709-1-quic_wgong@quicinc.com [use hole in chan flags, reword docs] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 14 Sep, 2023 1 commit
-
-
Johannes Berg authored
Now that I fixed the function name, we see the parameters are wrong as well. Fix that too. Change-Id: I1a4cfea446875998a5a242ca36acc8244991a199 Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
- 13 Sep, 2023 15 commits
-
-
Ping-Ke Shih authored
We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] In this case, simply return an error instead, to indicate that no data is available. Cc: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/r/20230203023636.4418-1-pkshih@realtek.comSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Stephen Douthit authored
If the driver doesn't fill NL80211_STA_INFO_TX_BITRATE in sta_set_sinfo() then as a fallback sta->deflink.tx_stats.last_rate is used. Unfortunately there's no guarantee that this has actually been set before it's used. Originally found when 'iw <dev> link' would always return a tx rate of 6Mbps regardless of actual link speed for the QCA9337 running firmware WLAN.TF.2.1-00021-QCARMSWP-1 in my netbook. Use the sanity check logic from ieee80211_fill_rx_status() and refactor that to use the new inline function. Signed-off-by: Stephen Douthit <stephen.douthit@gmail.com> Link: https://lore.kernel.org/r/20230213204024.3377-1-stephen.douthit@gmail.com [change to bool ..._rate_valid() instead of int ..._rate_invalid()] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
Getting a BAR can be an explanation if we're chasing packet loss. Add a print with the relevant debug level in that code path. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.913e989a1751.I6bff9020e339d91b61b5ad6aede27bcf8c7e6819@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This can be moved to constants, while at it also rename it to have a better name with MVM_ prefix. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.59823deebfda.Ied68b11ca40771d1cfc8c82ee8f9f2b9ea27da65@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Miri Korenblit authored
Transition to d3 is much faster if there is no power save during the transition. Therefore a new flag was added to the device power cmd to indicate the power save isn't allowed until the transition is completed. Set this flag in _iwl_mvm_suspend, when the transition begins. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.ced036106507.Ib5ed5a47ee35f624902bd8882dde3e559285965b@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Some new fields were added to the context info structure, define them for future use. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.ef1553ab5178.I326ac8719566e04f799d294d8e863383cff87eaa@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
If the firmware crashes in the de-activation / re-activation of the link during CSA, we will not have a valid phy_ctxt pointer in mvmvif. This is a legit case, but when mac80211 removes the station to cleanup our state during the re-configuration, we need to make sure we clear ap_sta otherwise we won't re-add the station after the firmware has been restarted. Later on, we'd activate the link, try to send a TLC command crash again on ASSERT 3508. Fix this by properly cleaning up our state. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.2651e6f6a55a.I4cd50e88ee5c23c1c8dd5b157a800e4b4c96f236@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Miri Korenblit authored
Currently we are setting the rate in the tx cmd for mgmt frames (e.g. during connection establishment). This was problematic when sending mgmt frames in eSR mode, as we don't know what link this frame will be sent on (This is decided by the FW), so we don't know what is the lowest rate. Fix this by not setting the rate in tx cmd and rely on FW to choose the right one. Set rate only for injected frames with fixed rate, or when no sta is given. Also set for important frames (EAPOL etc.) the High Priority flag. Fixes: 055b22e7 ("iwlwifi: mvm: Set Tx rate and flags when there is not station") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.6c7e59620ee0.I6eaed3ccdd6dd62b9e664facc484081fc5275843@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Shaul Triebitz authored
If the channel bandwidth is greater or equal than 80MHz, enable FILS DF transmittion, even if the control channel is non-PSC. That's because that in 80MHz there must be a sub 20MHz PSC channel, and since the FILS DF is duplicated on all sub 20MHz channels, within the 80MHz (hence it will be sent on a PSC channel). Also, if FILS DF Tx is enabled, always configure the firmware with the actual channel bandwidth, even before there is a connected client (rather than the minimum bandwidth e.g. 20MHz), since FILS DF transmission on a PSC channel take presedent over power consumption. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.83b9a76fc6c4.I6703111cc6befcd0e9cd9adf3cb127a648dbb7b1@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the device initialized with ME active, this would indeed work, since the NVM information would be obtained from ME. However, in the much more likely case that ME isn't active and the firmware takes actions requiring the sync, this was not working correctly when the firmware is only run at init to obtain NVM data, since mac80211 isn't even initialized. Fix this by moving the 'pldr_sync' handling to a different place. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.45a94d480e56.Id9277f1df6a63ab0dfca0d0c0f448c759e1b8e73@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Emmanuel Grumbach authored
When we drop frames we want to have something printed in the logger. This won't be printed by default of course. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.c2f02fecf66f.Ib472f9fd92856c6e5b5a99b68fdca0f694a531e9@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Gregory Greenman authored
Disable firmware debug asserts, which are used for internal firmware testing purposes only. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.8feafd9b17be.Ia7bec82ac25897caab581692d67055aa1aca2ed2@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Miri Korenblit authored
This condition will never be true. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.56ff0569d16c.I455839fad0f4f05043815aee884fab9ec7323f7d@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Enable the TOP (HW part) fatal error interrupt and add a print when it happens. Currently FW always adds also the SW error interrupt, but for >= Bz we'll need to do PLDR in case this is asserted, so leave a TODO item already. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.127d914a4d0d.I41ea409df63474554ef727c49382d0b5bf15939e@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
If the hardware is not responding, as indicated by (currently) five consecutive HW errors during reading, then just give up and fail, rather than attempting forever and forever for this to not return any useful data anyway. Even though we no longer completely deadlock the machine if it takes a long time, we still make it pretty much unusable since we'll eventually hold the RTNL while waiting for this process to finish. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230913145231.345af79f431c.I5ecde6b76b1e3a1572bd59d3cf8f827e767cedeb@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-