- 19 Jun, 2023 25 commits
-
-
Nicolas Cavallari authored
In mesh mode, ieee80211_chandef_he_6ghz_oper() is called by mesh_matches_local() for every received mesh beacon. On a 6 GHz mesh of a HE-only phy, this spams that the hardware does not have EHT capabilities, even if the received mesh beacon does not have an EHT element. Unlike HE, not supporting EHT in the 6 GHz band is not an error so do not print anything in this case. Fixes: 5dca295d ("mac80211: Add initial support for EHT and 320 MHz channels") Signed-off-by:
Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230614132648.28995-1-nicolas.cavallari@green-communications.frSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Anjaneyulu authored
Validate index before access iwl_rate_mcs to keep rate->index inside the valid boundaries. Use MCS_0_INDEX if index is less than MCS_0_INDEX and MCS_9_INDEX if index is greater then MCS_9_INDEX. Signed-off-by:
Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230614123447.79f16b3aef32.If1137f894775d6d07b78cbf3a6163ffce6399507@changeidSigned-off-by:
-
Anjaneyulu authored
Verify slots_num is valid in iwl_txq_alloc() Signed-off-by:
-
Anjaneyulu authored
Validate tid is less then MAX TID when it is used to access corresponding arrays. Signed-off-by:
-
Johannes Berg authored
If the AP is an AP MLD, then we shouldn't track just the BSSID but the MLD address. Just generally use ap_addr since it has the BSSID in the non-MLD case. Signed-off-by:
-
Johannes Berg authored
We skipped this in the past, but now we will need it for some platforms. Implement loading the PHY filter configuration IDs from the WPFC ACPI table. Note that the firmware must also be aware of the right filter configuration IDs (they're just the IDs of a filter configuration, not the actual configuration). Remove the useless hardcoded zeroes while at it. Signed-off-by:
-
Anjaneyulu authored
rxq can be NULL only when trans_pcie->rxq is NULL and entry->entry is zero. For the case when entry->entry is not equal to 0, rxq won't be NULL even if trans_pcie->rxq is NULL. Modify checker to check for trans_pcie->rxq. Fixes: abc599ef ("iwlwifi: pcie: don't crash when rx queues aren't allocated in interrupt") Signed-off-by:
-
Johannes Berg authored
When the firmware misbehaves (according to the driver), we often either ignore that, or WARN_ON, which is very noisy but doesn't really help. Add a little helper macro IWL_FW_CHECK() that can be used in place of WARN_ON() in conditions, and make it take a message that's printed in this case. We can also add more behaviour to this in the future. Signed-off-by:
-
Johannes Berg authored
The firmware technically only needs this when the link is newly added, but it's much easier for debugging if it's always available, so include it. Signed-off-by:
-
Johannes Berg authored
When calling iwl_mvm_set_fw_qos_params() we explicitly pass a pointer to the first array element, but the function will treat it as an array. Simplify and clarify the code and pass the array instead. Signed-off-by:
-
Johannes Berg authored
We have the data structure set up to store the parameters per link, but weren't using them. Fix that and store them in the right link. Signed-off-by:
-
Johannes Berg authored
Again, during some (botched) FW restart scenarios we can end up with a NULL link in the driver but mac80211 thinking all is still going OK. If we try to TX at the same time, we can crash there. Fix that by checking for a NULL link during TX. Signed-off-by:
-
Johannes Berg authored
We've observed that in some botched firmware restart scenarios when the firmware crashes again while we're reconfiguring, we can hit NULL pointer crashes here. The underlying issue is the botched restart which we need to fix separately, but until we can do that, don't crash hard here. Signed-off-by:
-
Ariel Malamud authored
On fw error dump, dmesg prints FSEQ register data. Add 4 additional prints in order to match those being dumped by Windows driver. Allows fw infra to correctly detect version mismatch. Signed-off-by:
Ariel Malamud <ariel.malamud@intel.com> Signed-off-by:
-
Johannes Berg authored
There are evidently cases where the firmware completes the reset but the interrupt isn't received correctly, so check for the interrupt again after the timeout, and don't dump the firmware error log if the right bit is set. Signed-off-by:
-
Johannes Berg authored
In mac80211, it's required that we pull from TXQs by calling ieee80211_tx_dequeue() only with softirqs disabled. However, in iwl_mvm_queue_state_change() we're often called with them enabled, e.g. from flush if anything was flushed, triggering a mac80211 warning. Fix that by disabling the softirqs across the TX call. Fixes: cfbc6c4c ("iwlwifi: mvm: support mac80211 TXQs model") Signed-off-by:
-
Johannes Berg authored
We have this helper now instead of open-coding the check for the dmi_tas_approved_list, so use it even here. It was added for debugfs use, but it's better to be consistent. Signed-off-by:
-
Johannes Berg authored
iwl_acpi_get_wifi_pkg_range(), iwl_acpi_get_wifi_pkg() and iwl_acpi_get_object() need not be exported etc., they're used only within the same file. Make them static. Signed-off-by:
-
Ilan Peer authored
If HT STBC is not supported, do not indicate support for VHT TX STBC. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
We can't just dereference the sband->iftype_data pointer, that's an array so we need to access the right entry. Use the previously introduced helper functions to do that. There are also cases, e.g. when loading with disable_11ax=1, where the pointer might be NULL but we still attempt to use it, causing a crash. Fixes: 529281bd ("iwlwifi: mvm: limit TLC according to our HE capabilities") Signed-off-by:
-
Mukesh Sisodiya authored
While vif pointers are protected by the corresponding "*active" fields, static checkers can get confused sometimes. Add an explicit check. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by:
-
Johannes Berg authored
The hardware isn't going to get fixed, so this mode cannot work in the foreseeable future. Remove it. Signed-off-by:
-
Ilan Peer authored
Add debugfs entry to report dormant (valid but disabled) links. Signed-off-by:
-
Ilan Peer authored
When the association is complete, do not configure disabled links, and track them as part of the interface data. Signed-off-by:
-
Johannes Berg authored
There are some locking changes that will later otherwise cause conflicts, so merge wireless into wireless-next to avoid those. Signed-off-by:
-
- 16 Jun, 2023 4 commits
-
-
Kalle Valo authored
GCC 12.2 with W=1 warns: drivers/net/wireless/legacy/ray_cs.c:630:17: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] The driver uses SSID as a string which is just wrong, it should be treated as a byte array instead. But as the driver is ancient and most likely there are no users so convert it to use strscpy(). This makes sure that the string is NUL-terminated and also the warning is fixed. Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230613140918.389690-5-kvalo@kernel.org
-
Kalle Valo authored
With GCC 13.1 and W=1 hostap has a warning: drivers/net/wireless/intersil/hostap/hostap_ioctl.c:3633:17: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation] fortify-string.h recommends not to use strncpy() so use strscpy() which fixes the warning. Also now it's guarenteed that the string is NUL-terminated. Compile tested only. Signed-off-by:
-
Kalle Valo authored
With GCC 13.1 and W=1 brcmsmac has warnings like this: ./include/trace/stages/stage5_get_offsets.h:23:31: warning: function 'trace_event_get_offsets_brcms_dbg' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] Add a workaround which disables -Wsuggest-attribute=format in brcms_trace_brcmsmac_msg.h. I see similar workarounds in other drivers as well. Compile tested only. Signed-off-by:
-
Kalle Valo authored
With GCC 13.1 and W=1 brcmfmac has warnings like this: ./include/trace/perf.h:26:16: warning: function 'perf_trace_brcmf_dbg' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format] Add a workaround which disables -Wsuggest-attribute=format in tracepoint.h. I see similar workarounds in other drivers as well. Compile tested only. Signed-off-by:
-
- 15 Jun, 2023 5 commits
-
-
Dmitry Antipov authored
Fix spelling typo of IQK debug messages. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Acked-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Dmitry Antipov authored
Drop useless '_iqk_track()' and 'rtw8852a_iqk_track()' (they just change 'thermal_rek_en' field which is set but unused and so removed as well) functions, set but unused 'kcount' field of 'struct rtw89_iqk_info', and convert 'thermal' to local variables where appropriate (it doesn't need to have longer storage duration because it is actually used for the debugging purposes only). Signed-off-by:
-
Dmitry Antipov authored
Remove a bunch of unused (and set but unused) fields from 'struct rtw89_btc_wl_nhm', 'struct rtw89_dle_info', 'struct rtw89_hal' and 'struct rtw89_env_monitor_info' driver-specific data structures, adjust related bits. Signed-off-by:
-
Azeem Shaikh authored
strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). Direct replacement is safe here since DEV_ASSIGN is only used by TRACE macros and the return values are ignored. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89Signed-off-by:
Azeem Shaikh <azeemshaikh38@gmail.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Deming Wang authored
Fix typo in the description of 'non-succesfull'. Signed-off-by:
Deming Wang <wangdeming@inspur.com> Acked-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
-
- 14 Jun, 2023 6 commits
-
-
Johannes Berg authored
When we restart the firmware, we shouldn't keep old debug data around. Since the "allocate" function might not reallocate the memory blocks (they're only freed when we unbind from the device), clear the memory to have a clean slate for debug data. This is a bit more complex since we normally don't enter into the allocation function, but duplicating the logic didn't seem enticing either, so rework the allocation a bit to always go into the individual block allocation, but there clear if it's already allocated, rather than allocating again. Signed-off-by:
-
Johannes Berg authored
The iwl_pcie_alloc_fw_monitor_block() function has an argument that's only ever hard-coded to 11, remove it and hard-code the value into the function itself with a comment. Signed-off-by:
-
Johannes Berg authored
When we restart the firmware, we shouldn't keep old debug data around. Since the "allocate" function might not reallocate the memory block (it's only freed when we unbind from the device), clear the memory to have a clean slate for debug data. Signed-off-by:
-
Johannes Berg authored
Given the existing code in iwl_dbg_tlv_update_drams(), the following can happen and cause firmware asserts, and even the device to become unusable: * We set the magic so the firmware will use the data; * we try to fill multiple allocation IDs, with at least one successful, but - crucially - one failing and thus not touching the data; * we don't clear the data since there was one success. This doesn't seem like much of a problem just yet, however, what happens now is that the allocation ID(s) that failed are not initialized. There are two additional things to know: * we never free these allocations across FW restart or interface down/up etc., in fact we never free them until the driver is unbound from the device (e.g. unloaded) * the firmware uses the DRAM info structure for real debug data when it has used it completely Given that, and the fact that we never initialize the data on restart, we can be unlucky and end up with an allocation that looks for the most part valid (valid ID, valid number of buffers, etc.) but has bad sizes - causing the firmware to throw an assert we can never recover from. Fixing the code to have the entire buffers cleared (which we should do so old debug data isn't sticking around) is a bit more complex, so as a first step make the actual code that fills the information more robust by clearing the structure first, and filling the magic values only if it actually succeeded for one, rather than doing it the other way around. Signed-off-by:
-
Emmanuel Grumbach authored
Newest firmware don't advertise the version of ADD_STA because it has been replaced by another command. There are old firmware images that also don't advertise it. Replace all the checks with a new inline, and in that check for either MLD API or the ADD_STA command version. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
The firmware only supports a single IGTK, and due to some changes it really doesn't like to have multiple programmed in later versions. Since only newer firmware cannot remove a key that isn't present any more, adjust only the MLD API code to keep track of the previous IGTK and remove it when a new one is added. Signed-off-by:
-
