- 17 Feb, 2023 4 commits
-
-
Yang Li authored
The return value from the call to idr_alloc() is int. However, the return value is being assigned to an unsigned int variable 'buf_id', so making 'buf_id' an int. Eliminate the following warning: ./drivers/net/wireless/ath/ath12k/dp_mon.c:1300:15-21: WARNING: Unsigned expression compared with zero: buf_id < 0 Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4060Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230215011453.73466-1-yang.lee@linux.alibaba.com
-
Colin Ian King authored
There are quite a few spelling mistakes in warning messages and a lot of the comments. Fix these. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Alexey V. Vissarionov authored
Although the "param" pointer occupies more or equal space compared to "*param", the allocation size should use the size of variable itself. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bdcd8170 ("Add ath6kl cleaned up driver") Signed-off-by:
Alexey V. Vissarionov <gremlin@altlinux.org> Signed-off-by:
-
Tamizh Chelvam Raja authored
Set the WMI_SCAN_FLAG_EXT_PASSIVE_SCAN_START_TIME_ENHANCE flag while sending the scan command. If this flag is enabled when the incoming scan request comes with a strict start time and its duration overlaps with next TBTT, then target adjust the start time accordingly for passive scan. Target supporting this feature will advertise WMI_TLV_SERVICE_PASSIVE_SCAN_START_TIME_ENHANCE. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01467-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> Signed-off-by:
-
- 15 Feb, 2023 10 commits
-
-
Johannes Berg authored
This documentation wasn't added in the original patch, add it now. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 6e4c0d04 ("wifi: mac80211: add a workaround for receiving non-standard mesh A-MSDU") Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Lorenzo Bianconi authored
Get rid of gfp parameter from cfg80211_obss_color_collision_notify routine description. Fixes: 935ef47b ("wifi: cfg80211: get rid of gfp in cfg80211_bss_color_notify") Reported-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/2da652e2cd5c7903191091ae9757718f1be802a1.1676453359.git.lorenzo@kernel.orgSigned-off-by:
-
Johannes Berg authored
When we have multiple interfaces receiving the same frame, such as a multicast frame, one interface might have a sta and the other not. In this case, link_sta would be set but not cleared again. Always set link_sta, so we keep an invariant that link_sta and sta are either both set or both not set. Signed-off-by: -
Johannes Berg authored
There's at least one case in ieee80211_rx_for_interface() where we might pass &((struct sta_info *)NULL)->sta to it only to then do container_of(), and then checking the result for NULL, but checking the result of container_of() for NULL looks really odd. Fix this by just passing the struct sta_info * instead. Fixes: e66b7920 ("wifi: mac80211: fix initialization of rx->link and rx->link_sta") Signed-off-by:
-
Marc Bornand authored
When a connection was established without going through NL80211_CMD_CONNECT, the ssid was never set in the wireless_dev struct. Now we set it in __cfg80211_connect_result() when it is not already set. When using a userspace configuration that does not call cfg80211_connect() (can be checked with breakpoints in the kernel), this patch should allow `networkctl status device_name` to output the SSID instead of null. Cc: stable@vger.kernel.org Reported-by:
Yohan Prod'homme <kernel@zoddo.fr> Fixes: 7b0a0e3c (wifi: cfg80211: do some rework towards MLO link APIs) Link: https://bugzilla.kernel.org/show_bug.cgi?id=216711Signed-off-by:
Marc Bornand <dev.mbornand@systemb.ch> Signed-off-by:
-
Chin-Yen Lee authored
The H2C of del_pkt_offload must be called before polling FW status ready, otherwise the following downloading normal FW will fail. Fixes: 5c12bb66 ("wifi: rtw89: refine packet offload flow") 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/20230214114314.5268-1-pkshih@realtek.com
-
Ping-Ke Shih authored
For normal (successful) flow, it must return 0. The original code uses 'return ret', and then we need to backward reference to initial value to know 'ret = 0'. Changing them to 'return 0', because it will be more readable and intuitive. This patch doesn't change logic at all. Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/202302101023.ctlih5q0-lkp@intel.com/Signed-off-by:
-
Sascha Hauer authored
Now that we send URBs with the URB_ZERO_PACKET flag set we no longer need to make sure that the URB sizes are not multiple of the bulkout_size. Drop the check. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by:
-
Sascha Hauer authored
Zero length packets are necessary when sending URBs with size multiple of bulkout_size, otherwise the hardware just stalls. Fixes: a82dfd33 ("wifi: rtw88: Add common USB chip support") Signed-off-by:
-
Sascha Hauer authored
We have to extract qsel from the skb before doing skb_push() on it, otherwise qsel will always be 0. Fixes: a82dfd33 ("wifi: rtw88: Add common USB chip support") Signed-off-by:
-
- 14 Feb, 2023 26 commits
-
-
Johannes Berg authored
The convention for find_first_bit() is 0-based, while ffs() is 1-based, so this is now off-by-one. I cannot reproduce the gcc-9 problem, but since the -1 is now removed, I'm hoping it will still avoid the original issue. Reported-by:
Alexander Lobakin <alexandr.lobakin@intel.com> Fixes: 1d8d4af4 ("wifi: mac80211: avoid u32_encode_bits() warning") Signed-off-by:
-
Gilad Itzkovitch authored
The ieee80211_accept_frame() function performs a number of early checks to decide whether or not further processing needs to be done on a frame. One of those checks is the ieee80211_is_robust_mgmt_frame() function. It requires to peek into the frame payload, but because defragmentation does not occur until later on in the receive path, this peek is invalid for any fragment other than the first one. Also, in this scenario there is no STA and so the fragmented frame will be dropped later on in the process and will not reach the upper stack. This can happen with large action frames at low rates, for example, we see issues with DPP on S1G. This change will only check if the frame is robust if it's the first fragment. Invalid fragmented packets will be discarded later after defragmentation is completed. Signed-off-by:
Gilad Itzkovitch <gilad.itzkovitch@morsemicro.com> Link: https://lore.kernel.org/r/20221124005336.1618411-1-gilad.itzkovitch@morsemicro.comSigned-off-by:
-
Arnd Bergmann authored
gcc-9 triggers a false-postive warning in ieee80211_mlo_multicast_tx() for u32_encode_bits(ffs(links) - 1, ...), since ffs() can return zero on an empty bitmask, and the negative argument to u32_encode_bits() is then out of range: In file included from include/linux/ieee80211.h:21, from include/net/cfg80211.h:23, from net/mac80211/tx.c:23: In function 'u32_encode_bits', inlined from 'ieee80211_mlo_multicast_tx' at net/mac80211/tx.c:4437:17, inlined from 'ieee80211_subif_start_xmit' at net/mac80211/tx.c:4485:3: include/linux/bitfield.h:177:3: error: call to '__field_overflow' declared with attribute error: value doesn't fit into mask 177 | __field_overflow(); \ | ^~~~~~~~~~~~~~~~~~ include/linux/bitfield.h:197:2: note: in expansion of macro '____MAKE_OP' 197 | ____MAKE_OP(u##size,u##size,,) | ^~~~~~~~~~~ include/linux/bitfield.h:200:1: note: in expansion of macro '__MAKE_OP' 200 | __MAKE_OP(32) | ^~~~~~~~~ Newer compiler versions do not cause problems with the zero argument because they do not consider this a __builtin_constant_p(). It's also harmless since the hweight16() check already guarantees that this cannot be 0. Replace the ffs() with an equivalent find_first_bit() check that matches the later for_each_set_bit() style and avoids the warning. Fixes: 963d0e8d ("wifi: mac80211: optionally implement MLO multicast TX") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230214132025.1532147-1-arnd@kernel.orgSigned-off-by:
-
Andrei Otcheretianski authored
MLD address translation should be done only for individually addressed frames. Otherwise, AAD calculation would be wrong and the decryption would fail. Fixes: e66b7920 ("wifi: mac80211: fix initialization of rx->link and rx->link_sta") Signed-off-by:
Andrei Otcheretianski <andrei.otcheretianski@intel.com> Link: https://lore.kernel.org/r/20230214101048.792414-1-andrei.otcheretianski@intel.comSigned-off-by:
-
Wen Gong authored
Currently the regulatory driver does not call the regulatory callback reg_notifier for self managed wiphys. Sometimes driver needs cfg80211 to calculate the info of ieee80211_channel such as flags and power, and driver needs to get the info of ieee80211_channel after hint of driver, but driver does not know when calculation of the info of ieee80211_channel become finished, so add notify to driver in reg_process_self_managed_hint() from cfg80211 is a good way, then driver could get the correct info in callback of reg_notifier. Signed-off-by:
Wen Gong <quic_wgong@quicinc.com> Link: https://lore.kernel.org/r/20230201065313.27203-1-quic_wgong@quicinc.comSigned-off-by:
-
Lorenzo Bianconi authored
Since cfg80211_bss_color_notify() is now always run in non-atomic context, get rid of gfp_t flags in the routine signature and always use GFP_KERNEL for netlink message allocation. Signed-off-by:
-
Vinay Gannevaram authored
Wi-Fi Aware R4 specification defines NAN Pairing which uses PASN handshake to authenticate the peer and generate keys. Hence allow to register and transmit the PASN authentication frames on NAN interface and set the keys to driver or underlying modules on NAN interface. The driver needs to configure the feature flag NL80211_EXT_FEATURE_SECURE_NAN, which also helps userspace modules to know if the driver supports secure NAN. Signed-off-by:
Vinay Gannevaram <quic_vganneva@quicinc.com> Link: https://lore.kernel.org/r/1675519179-24174-1-git-send-email-quic_vganneva@quicinc.comSigned-off-by:
-
Karthikeyan Periyasamy authored
Non-MLO station frames are dropped in Rx path due to the condition check in ieee80211_rx_is_valid_sta_link_id(). In multi-link AP scenario, non-MLO stations try to connect in any of the valid links in the ML AP, where the station valid_links and link_id params are valid in the ieee80211_sta object. But ieee80211_rx_is_valid_sta_link_id() always return false for the non-MLO stations by the assumption taken is valid_links and link_id are not valid in non-MLO stations object (ieee80211_sta), this assumption is wrong. Due to this assumption, non-MLO station frames are dropped which leads to failure in association. Fix it by removing the condition check and allow the link validation check for the non-MLO stations. Fixes: e66b7920 ("wifi: mac80211: fix initialization of rx->link and rx->link_sta") Signed-off-by:
Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Link: https://lore.kernel.org/r/20230206160330.1613-1-quic_periyasa@quicinc.comSigned-off-by:
-
Rameshkumar Sundaram authored
Stations can update bandwidth/NSS change in VHT action frame with action type Operating Mode Notification. (IEEE Std 802.11-2020 - 9.4.1.53 Operating Mode field) For Operating Mode Notification, an RX NSS change to a value greater than AP's maximum NSS should not be allowed. During fuzz testing, by forcefully sending VHT Op. mode notif. frames from STA with random rx_nss values, it is found that AP accepts rx_nss values greater that APs maximum NSS instead of discarding such NSS change. Hence allow NSS change only up to maximum NSS that is negotiated and capped to AP's capability during association. Signed-off-by:
Rameshkumar Sundaram <quic_ramess@quicinc.com> Link: https://lore.kernel.org/r/20230207114146.10567-1-quic_ramess@quicinc.comSigned-off-by:
-
Felix Fietkau authored
At least ath10k and ath11k supported hardware (maybe more) does not implement mesh A-MSDU aggregation in a standard compliant way. 802.11-2020 9.3.2.2.2 declares that the Mesh Control field is part of the A-MSDU header (and little-endian). As such, its length must not be included in the subframe length field. Hardware affected by this bug treats the mesh control field as part of the MSDU data and sets the length accordingly. In order to avoid packet loss, keep track of which stations are affected by this and take it into account when converting A-MSDU to 802.3 + mesh control packets. Signed-off-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230213100855.34315-5-nbd@nbd.nameSigned-off-by:
-
Felix Fietkau authored
The current mac80211 mesh A-MSDU receive path fails to parse A-MSDU packets on mesh interfaces, because it assumes that the Mesh Control field is always directly after the 802.11 header. 802.11-2020 9.3.2.2.2 Figure 9-70 shows that the Mesh Control field is actually part of the A-MSDU subframe header. This makes more sense, since it allows packets for multiple different destinations to be included in the same A-MSDU, as long as RA and TID are still the same. Another issue is the fact that the A-MSDU subframe length field was apparently accidentally defined as little-endian in the standard. In order to fix this, the mesh forwarding path needs happen at a different point in the receive path. ieee80211_data_to_8023_exthdr is changed to ignore the mesh control field and leave it in after the ethernet header. This also affects the source/dest MAC address fields, which now in the case of mesh point to the mesh SA/DA. ieee80211_amsdu_to_8023s is changed to deal with the endian difference and to add the Mesh Control length to the subframe length, since it's not covered by the MSDU length field. With these changes, the mac80211 will get the same packet structure for converted regular data packets and unpacked A-MSDU subframes. The mesh forwarding checks are now only performed after the A-MSDU decap. For locally received packets, the Mesh Control header is stripped away. For forwarded packets, a new 802.11 header gets added. Signed-off-by:
-
Felix Fietkau authored
Now that all drivers use iTXQ, it does not make sense to check to drop tx forwarding packets when the driver has stopped the queues. fq_codel will take care of dropping packets when the queues fill up Signed-off-by:
-
Felix Fietkau authored
The same check is done in multiple places, unify it. Signed-off-by:
-
Felix Fietkau authored
When parsing the outer A-MSDU header, don't check for inner bridge tunnel or RFC1042 headers. This is handled by ieee80211_amsdu_to_8023s already. Signed-off-by:
-
Shayne Chen authored
The value of last_rate in ieee80211_sta_rx_stats is degraded from u32 to u16 after being assigned to rate variable, which causes information loss in STA_STATS_FIELD_TYPE and later bitfields. Signed-off-by:
Shayne Chen <shayne.chen@mediatek.com> Link: https://lore.kernel.org/r/20230209110659.25447-1-shayne.chen@mediatek.com Fixes: 41cbb0f5 ("mac80211: add support for HE") Signed-off-by:
-
Bo Liu authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
Bo Liu <liubo03@inspur.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230206081641.3193-1-liubo03@inspur.comSigned-off-by:
-
Rameshkumar Sundaram authored
Currently action frames TX only with ML address as A3(BSSID) are allowed in an ML AP, but TX for a non-ML Station can happen in any link of an ML BSS with link BSS address as A3. In case of an MLD, if User-space has provided a valid link_id in action frame TX request, allow transmission of the frame in that link. Signed-off-by:
-
Aloka Dixit authored
- Configure the bitmap in link_conf and notify the driver. - Modify 'change' in ieee80211_start_ap() from u32 to u64 to support BSS_CHANGED_EHT_PUNCTURING. - Propagate the bitmap in channel switch events to userspace. Signed-off-by:
Aloka Dixit <quic_alokad@quicinc.com> Signed-off-by:
Muna Sinada <quic_msinada@quicinc.com> Link: https://lore.kernel.org/r/20230131001227.25014-5-quic_alokad@quicinc.comSigned-off-by:
-
Aloka Dixit authored
Add puncturing bitmap in channel switch notifications and corresponding trace functions. Signed-off-by:
-
Aloka Dixit authored
- New feature flag, NL80211_EXT_FEATURE_PUNCT, to advertise driver support for preamble puncturing in AP mode. - New attribute, NL80211_ATTR_PUNCT_BITMAP, to receive a puncturing bitmap from the userspace during AP bring up (NL80211_CMD_START_AP) and channel switch (NL80211_CMD_CHANNEL_SWITCH) operations. Each bit corresponds to a 20 MHz channel in the operating bandwidth, lowest bit for the lowest channel. Bit set to 1 indicates that the channel is punctured. Higher 16 bits are reserved. - New members added to structures cfg80211_ap_settings and cfg80211_csa_settings to propagate the bitmap to the driver after validation. Signed-off-by:
-
Aloka Dixit authored
- Move ieee80211_valid_disable_subchannel_bitmap() from mlme.c to chan.c, rename it as cfg80211_valid_disable_subchannel_bitmap() and export it. - Modify the prototype to include struct cfg80211_chan_def instead of only bandwidth to support a check which returns false if the primary channel is punctured. Signed-off-by:
-
Jaewan Kim authored
Add an error message to the missing frequency case to have all -EINVAL in nl80211_parse_chandef() return a better error. Signed-off-by:
Jaewan Kim <jaewan@google.com> Link: https://lore.kernel.org/r/20230130074514.1560021-1-jaewan@google.com [rewrite commit message] Signed-off-by:
-
Jaewan Kim authored
It is a frequent mistake to confuse the netlink port identifier with a process identifier. Try to reduce this confusion by renaming that hold port identifiers portid instead of pid. This change replicates following commit: commit 15e47304 ("netlink: Rename pid to portid to avoid confusion") Signed-off-by:
-
Alvin Šipraga authored
nl80211_send_ap_stopped() can be called multiple times on the same netdev for each link when using Multi-Link Operation. Add the MLO_LINK_ID attribute to the event to allow userspace to distinguish which link the event is for. Signed-off-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Link: https://lore.kernel.org/r/20230128125844.2407135-2-alvin@pqrs.dkSigned-off-by:
-
Alvin Šipraga authored
Userspace processes such as network daemons may wish to be informed when any AP interface is brought up on the system, for example to initiate a (re)configuration of IP settings or to start a DHCP server. Currently nl80211 does not broadcast any such event on its multicast groups, leaving userspace only two options: 1. the process must be the one that actually issued the NL80211_CMD_START_AP request, so that it can react on the response to that request; 2. the process must react to RTM_NEWLINK events indicating a change in carrier state, and may query for further information about the AP and react accordingly. Option (1) is robust, but it does not cover all scenarios. It is easy to imagine a situation where this is not the case (e.g. hostapd + systemd-networkd). Option (2) is not robust, because RTM_NEWLINK events may be silently discarded by the linkwatch logic (cf. linkwatch_fire_event()). Concretely, consider a scenario in which the carrier state flip-flops in the following way: ^ carrier state (high/low = carrier/no carrier) | | _______ _______ ... | | | | | ______| "foo" |____| "bar" (SSID in "quotes") | +-------A-------B----C---------> time If the time interval between (A) and (C) is less than 1 second, then linkwatch may emit only a single RTM_NEWLINK event indicating carrier gain. This is problematic because it is possible that the network configuration that should be applied is a function of the AP's properties such as SSID (cf. SSID= in systemd.network(5)). As illustrated in the above diagram, it may be that the AP with SSID "bar" ends up being configured as though it had SSID "foo". Address the above issue by having nl80211 emit an NL80211_CMD_START_AP message on the MLME nl80211 multicast group. This allows for arbitrary processes to be reliably informed. Signed-off-by:
-
Johannes Berg authored
Handle the Puncturing info received from the AP in the EHT Operation element in beacons. If the info is invalid: - during association: disable EHT connection for the AP - after association: disconnect This commit includes many (internal) bugfixes and spec updates various people. Co-developed-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by:
-
