- 25 Aug, 2023 1 commit
-
-
Wang Ming authored
The debugfs_create_dir() function returns error pointers, it never returns NULL. Most incorrect error checks were fixed, but the one in ath9k_htc_init_debug() was forgotten. Fix the remaining error check. Fixes: e5facc75 ("ath9k_htc: Cleanup HTC debugfs") Signed-off-by:
Wang Ming <machel@vivo.com> Acked-by:
Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20230713030358.12379-1-machel@vivo.com
-
- 23 Aug, 2023 13 commits
-
-
Rajat Soni authored
Currently when ath12k_dp_cc_desc_init() is called we allocate memory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), during descriptor cleanup rx_descs and tx_descs memory is not freed. This is cause of memory leak. These allocated memory should be freed in ath12k_dp_cc_cleanup. In ath12k_dp_cc_desc_init(), we can save base address of rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs and tx_descs memory using their base address. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by:
Rajat Soni <quic_rajson@quicinc.com> Signed-off-by:
-
Mahmoud Maatuq authored
coccinielle reported the following: ./drivers/net/wireless/ath/ath5k/phy.c:1573:25-26: WARNING opportunity for swap() while trying to fix the above warning, it reveals that ath5k_hw_get_median_noise_floor() had open-coded sort() functionality. Since ath5k_hw_get_median_noise_floor() only executes once every 10 seconds, any extra overhead due to sort() calling its "compare" and "swap" functions can be ignored, so replace the existing logic with a call to sort(). Signed-off-by:
Mahmoud Maatuq <mahmoudmatook.mm@gmail.com> Suggested-by:
Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
This has never been used since the driver was merged, but it now causes a W=1 warning in recent clang versions drivers/net/wireless/ath/ath9k/main.c:1566:21: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] drivers/net/wireless/ath/ath9k/htc_drv_main.c:1258:25: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] drivers/net/wireless/ath/ath5k/mac80211-ops.c:367:62: error: parameter 'changed_flags' set but not used [-Werror,-Wunused-but-set-parameter] Remove the bit manipulation on the otherwise unused parameter. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by:
-
Yue Haibing authored
Commit 2c3960c2 ("ath11k: setup ce tasklet for control path") declared but never implemented ath11k_ce_map_service_to_pipe(). Commit e3396b8b ("ath11k: ce: support different CE configurations") declared but never implemented ath11k_ce_attr_attach(). Commit d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") declared but never implemented ath11k_qmi_event_work()/ath11k_qmi_msg_recv_work(). Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Acked-by:
-
Krzysztof Kozlowski authored
'hw_rev' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: ath10k/ahb.c:736:11: error: cast to smaller integer type 'enum ath10k_hw_rev' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
-
Krzysztof Kozlowski authored
'hw_rev' is an enum, thus cast of pointer on 64-bit compile test with W=1 causes: h11k/ahb.c:1124:11: error: cast to smaller integer type 'enum ath11k_hw_rev' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast] Signed-off-by:
-
Yang Yingliang authored
The init/exit() of driver only calls platform_driver_register/unregister, it can be simpilfied with module_platform_driver. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Jeff Johnson authored
Fix a few issues flagged by 'codespell'. Signed-off-by:
-
Jeff Johnson authored
Fix a few issues flagged by 'codespell'. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Jeff Johnson authored
Fix a few issues flagged by 'codespell'. Signed-off-by:
-
Jeff Johnson authored
Helper function ath11k_vif_to_arvif() exists to retrieve a struct ath11k_vif from a struct ieee80211_vif. However, in multiple places this logic is open-coded with inline typecasting. Since the typecasting prevents the compiler from type-checking the source and destination, update the driver to consistently use the helper function. No functional changes, compile tested only. Signed-off-by:
-
Sven Eckelmann authored
When a function is using functions from mac80211 to free an skb then it should do it consistently and not switch to the generic dev_kfree_skb_any (or similar functions). Otherwise (like in the error handlers), mac80211 will will not be aware of the freed skb and thus not clean up related information in its internal data structures. Not doing so lead in the past to filled up structure which then prevented new clients to connect. Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Fixes: 6257c702 ("wifi: ath11k: fix tx status reporting in encap offload mode") Cc: stable@vger.kernel.org Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
-
Sven Eckelmann authored
When a station idles for a long time, hostapd will try to send a QoS Null frame to the station as "poll". NL80211_CMD_PROBE_CLIENT is used for this purpose. And the skb will be added to ack_status_frame - waiting for a completion via ieee80211_report_ack_skb(). But when the peer was already removed before the tx_complete arrives, the peer will be missing. And when using dev_kfree_skb_any (instead of going through mac80211), the entry will stay inside ack_status_frames. This IDR will therefore run full after 8K request were generated for such clients. At this point, the access point will then just stall and not allow any new clients because idr_alloc() for ack_status_frame will fail. ieee80211_free_txskb() on the other hand will (when required) call ieee80211_report_ack_skb() and make sure that (when required) remove the entry from the ack_status_frame. Tested-on: IPQ6018 hw1.0 WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1 Fixes: 6257c702 ("wifi: ath11k: fix tx status reporting in encap offload mode") Fixes: 94739d45 ("ath11k: switch to using ieee80211_tx_status_ext()") Cc: stable@vger.kernel.org Signed-off-by:
-
- 22 Aug, 2023 7 commits
-
-
Yue Haibing authored
Commit b57ba3b2 ("ath9k: move ath9k_reload_chainmask_settings to common") removed the implementation ath9k_reload_chainmask_settings() but not the declaration. Also commit 978f78bf ("ath9k_hw: Move bt_stomp to hw from common.") left behind ath9k_cmn_btcoex_bt_stomp() declaration. Signed-off-by:
-
Ruan Jinjie authored
Ther are a little ternary operators, the true or false judgement of which is unnecessary in C language semantics. Signed-off-by:
Ruan Jinjie <ruanjinjie@huawei.com> Acked-by:
-
Dmitry Antipov authored
Use 'kstrtoul_from_user()' and 'kstrtobool_from_user()' where appropriate and thus avoid some code duplication. Signed-off-by:
Dmitry Antipov <dmantipov@yandex.ru> Acked-by:
-
Minjie Du authored
Make IS_ERR() judge the debugfs_create_dir() function return in ath9k_init_debug() Signed-off-by:
Minjie Du <duminjie@vivo.com> Acked-by:
-
Fedor Pchelkin authored
If ath9k_wmi_cmd() has exited with a timeout, it is possible that during next ath9k_wmi_cmd() call the wmi_rsp callback for previous wmi command writes to new wmi->cmd_rsp_buf and makes a completion. This results in an invalid ath9k_wmi_cmd() return value. Move the replacement of WMI command response buffer and length under wmi_lock. Note that last_seq_id value is updated there, too. Thus, the buffer cannot be written to by a belated wmi_rsp callback because that path is properly rejected by the last_seq_id check. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: fb9987d0 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by:
Fedor Pchelkin <pchelkin@ispras.ru> Acked-by:
-
Fedor Pchelkin authored
Currently, the synchronization between ath9k_wmi_cmd() and ath9k_wmi_ctrl_rx() is exposed to a race condition which, although being rather unlikely, can lead to invalid behaviour of ath9k_wmi_cmd(). Consider the following scenario: CPU0 CPU1 ath9k_wmi_cmd(...) mutex_lock(&wmi->op_mutex) ath9k_wmi_cmd_issue(...) wait_for_completion_timeout(...) --- timeout --- /* the callback is being processed * before last_seq_id became zero */ ath9k_wmi_ctrl_rx(...) spin_lock_irqsave(...) /* wmi->last_seq_id check here * doesn't detect timeout yet */ spin_unlock_irqrestore(...) /* last_seq_id is zeroed to * indicate there was a timeout */ wmi->last_seq_id = 0 mutex_unlock(&wmi->op_mutex) return -ETIMEDOUT ath9k_wmi_cmd(...) mutex_lock(&wmi->op_mutex) /* the buffer is replaced with * another one */ wmi->cmd_rsp_buf = rsp_buf wmi->cmd_rsp_len = rsp_len ath9k_wmi_cmd_issue(...) spin_lock_irqsave(...) spin_unlock_irqrestore(...) wait_for_completion_timeout(...) /* the continuation of the * callback left after the first * ath9k_wmi_cmd call */ ath9k_wmi_rsp_callback(...) /* copying data designated * to already timeouted * WMI command into an * inappropriate wmi_cmd_buf */ memcpy(...) complete(&wmi->cmd_wait) /* awakened by the bogus callback * => invalid return result */ mutex_unlock(&wmi->op_mutex) return 0 To fix this, update last_seq_id on timeout path inside ath9k_wmi_cmd() under the wmi_lock. Move ath9k_wmi_rsp_callback() under wmi_lock inside ath9k_wmi_ctrl_rx() so that the wmi->cmd_wait can be completed only for initially designated wmi_cmd call, otherwise the path would be rejected with last_seq_id check. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: fb9987d0 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: -
Ruan Jinjie authored
There is no need to call the dev_err() function directly to print a custom message when handling an error from platform_get_irq() function as it is going to display an appropriate error message in case of a failure. Signed-off-by:
-
- 21 Aug, 2023 3 commits
-
-
Yang Li authored
Fix some kernel-doc comments to silence the warnings: drivers/net/ethernet/amd/pds_core/auxbus.c:18: warning: Function parameter or member 'pf' not described in 'pds_client_register' drivers/net/ethernet/amd/pds_core/auxbus.c:18: warning: Excess function parameter 'pf_pdev' description in 'pds_client_register' drivers/net/ethernet/amd/pds_core/auxbus.c:58: warning: Function parameter or member 'pf' not described in 'pds_client_unregister' drivers/net/ethernet/amd/pds_core/auxbus.c:58: warning: Excess function parameter 'pf_pdev' description in 'pds_client_unregister' Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
sk_getsockopt() runs locklessly. This means sk->sk_lingertime can be read while other threads are changing its value. Other reads also happen without socket lock being held, and must be annotated. Remove preprocessor logic using BITS_PER_LONG, compilers are smart enough to figure this by themselves. v2: fixed a clang W=1 (-Wtautological-constant-out-of-range-compare) warning (Jakub) Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Hangbin Liu authored
Add extack info for IPv4 address add/delete, which would be useful for users to understand the problem without having to read kernel code. No extack message for the ifa_local checking in __inet_insert_ifa() as it has been checked in find_matching_ifa(). Suggested-by:
Ido Schimmel <idosch@idosch.org> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
- 20 Aug, 2023 12 commits
-
-
Furong Xu authored
1. XGMAC Core does not have hash_filter definition, it uses vlhash(VLAN Hash Filtering) instead, skip hash_filter when XGMAC. 2. Show exact size of Hash Table instead of raw register value. 3. Show full description of safety features defined by Synopsys Databook. 4. When safety feature is configured with no parity, or ECC only, keep FSM Parity Checking disabled. Signed-off-by:
Furong Xu <0x1207@gmail.com> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
David S. Miller authored
Hangbin Liu says: ==================== ipv6: update route when delete source address Currently, when remove an address, the IPv6 route will not remove the prefer source address when the address is bond to other device. Fix this issue and add related tests as Ido and David suggested. ==================== Signed-off-by: -
Hangbin Liu authored
Add a test case for IPv6 source address delete. As David suggested, add tests: - Single device using src address - Two devices with the same source address - VRF with single device using src address - VRF with two devices using src address As Ido points out, in IPv6, the preferred source address is looked up in the same VRF as the first nexthop device. This will give us similar results to IPv4 if the route is installed in the same VRF as the nexthop device, but not when the nexthop device is enslaved to a different VRF. So add tests: - src address and nexthop dev in same VR - src address and nexthop device in different VRF The link local address delete logic is different from the global address. It should only affect the associate device it bonds to. So add tests cases for link local address testing. Here is the test result: IPv6 delete address route tests Single device using src address TEST: Prefsrc removed when src address removed on other device [ OK ] Two devices with the same source address TEST: Prefsrc not removed when src address exist on other device [ OK ] TEST: Prefsrc removed when src address removed on all devices [ OK ] VRF with single device using src address TEST: Prefsrc removed when src address removed on other device [ OK ] VRF with two devices using src address TEST: Prefsrc not removed when src address exist on other device [ OK ] TEST: Prefsrc removed when src address removed on all devices [ OK ] src address and nexthop dev in same VRF TEST: Prefsrc removed from VRF when source address deleted [ OK ] TEST: Prefsrc in default VRF not removed [ OK ] TEST: Prefsrc not removed from VRF when source address exist [ OK ] TEST: Prefsrc in default VRF removed [ OK ] src address and nexthop device in different VRF TEST: Prefsrc not removed from VRF when nexthop dev in diff VRF [ OK ] TEST: Prefsrc not removed in default VRF [ OK ] TEST: Prefsrc removed from VRF when nexthop dev in diff VRF [ OK ] TEST: Prefsrc removed in default VRF [ OK ] Table ID 0 TEST: Prefsrc removed from default VRF when source address deleted [ OK ] Link local source route TEST: Prefsrc not removed when delete ll addr from other dev [ OK ] TEST: Prefsrc removed when delete ll addr [ OK ] TEST: Prefsrc not removed when delete ll addr from other dev [ OK ] TEST: Prefsrc removed even ll addr still exist on other dev [ OK ] Tests passed: 19 Tests failed: 0 Suggested-by: -
Hangbin Liu authored
After deleting an IPv6 address on an interface and cleaning up the related preferred source entries, it is important to ensure that all routes associated with the deleted address are properly cleared. The current implementation of rt6_remove_prefsrc() only checks the preferred source addresses bound to the current device. However, there may be routes that are bound to other devices but still utilize the same preferred source address. To address this issue, it is necessary to also delete entries that are bound to other interfaces but share the same source address with the current device. Failure to delete these entries would leave routes that are bound to the deleted address unclear. Here is an example reproducer (I have omitted unrelated routes): + ip link add dummy1 type dummy + ip link add dummy2 type dummy + ip link set dummy1 up + ip link set dummy2 up + ip addr add 1:2:3:4::5/64 dev dummy1 + ip route add 7:7:7:0::1 dev dummy1 src 1:2:3:4::5 + ip route add 7:7:7:0::2 dev dummy2 src 1:2:3:4::5 + ip -6 route show 1:2:3:4::/64 dev dummy1 proto kernel metric 256 pref medium 7:7:7::1 dev dummy1 src 1:2:3:4::5 metric 1024 pref medium 7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium + ip addr del 1:2:3:4::5/64 dev dummy1 + ip -6 route show 7:7:7::1 dev dummy1 metric 1024 pref medium 7:7:7::2 dev dummy2 src 1:2:3:4::5 metric 1024 pref medium As Ido reminds, in IPv6, the preferred source address is looked up in the same VRF as the first nexthop device, which is different with IPv4. So, while removing the device checking, we also need to add an ipv6_chk_addr() check to make sure the address does not exist on the other devices of the rt nexthop device's VRF. After fix: + ip addr del 1:2:3:4::5/64 dev dummy1 + ip -6 route show 7:7:7::1 dev dummy1 metric 1024 pref medium 7:7:7::2 dev dummy2 metric 1024 pref medium Reported-by:
Thomas Haller <thaller@redhat.com> Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2170513Reviewed-by:
-
Hangbin Liu authored
As the initial commit 1a017276 ("selftests: Add VRF route leaking tests") said, the IPv6 MTU test fails as source address selection picking ::1. Every time we run the selftest this one report failed. There seems not much meaning to keep reporting a failure for 3 years that no one plan to fix/update. Let't just skip this one first. We can add it back when the issue fixed. Signed-off-by:
-
Patrick Rohr authored
addrconf_prefix_rcv returned early without releasing the inet6_dev pointer when the PIO lifetime is less than accept_ra_min_lft. Fixes: 5027d54a ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes") Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: David Ahern <dsahern@kernel.org> Cc: Simon Horman <horms@kernel.org> Reviewed-by:
Maciej Żenczykowski <maze@google.com> Signed-off-by:
Patrick Rohr <prohr@google.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
Eric Dumazet authored
Setting IP_RECVERR and IPV6_RECVERR options to zero currently purges the socket error queue, which was probably not expected for zerocopy and tx_timestamp users. I discovered this issue while preparing commit 6b5f43ea ("inet: move inet->recverr to inet->inet_flags"), I presume this change does not need to be backported to stable kernels. Add skb_errqueue_purge() helper to purge error messages only. Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
David S. Miller authored
Ruan Jinjie says: ==================== net: Return PTR_ERR() for fixed_phy_register() fixed_phy_register() returns not only -EIO or -ENODEV, but also -EPROBE_DEFER, -EINVAL and -EBUSY. The Best practice is to return these error codes with PTR_ERR(). ==================== Signed-off-by: -
Ruan Jinjie authored
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY, etc, in addition to -EIO. The Best practice is to return these error codes with PTR_ERR(). Signed-off-by:
-
Ruan Jinjie authored
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY, etc, in addition to -ENODEV. The Best practice is to return these error codes with PTR_ERR(). Signed-off-by:
Doug Berger <opendmb@gmail.com> Signed-off-by:
-
Ruan Jinjie authored
fixed_phy_register() returns -EPROBE_DEFER, -EINVAL and -EBUSY, etc, in addition to -ENODEV. The best practice is to return these error codes with PTR_ERR(). Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King (Oracle) authored
The user ports use RSGMII, but we don't have that, and DT doesn't specify a phy interface mode, so phylib defaults to GMII. These support 1G, 100M and 10M with flow control. It is unknown whether asymetric pause is supported at all speeds. The CPU port uses MII/GMII/RGMII/REVMII by hardware pin strapping, and support speeds specific to each, with full duplex only supported in some modes. Flow control may be supported again by hardware pin strapping, and theoretically is readable through a register but no information is given in the datasheet for that. So, we do a best efforts - and be lenient. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 19 Aug, 2023 4 commits
-
-
David S. Miller authored
Ruan Jinjie says: ==================== net: Update and fix return value check for vcap_get_rule() As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), which would be more cleaner. So se IS_ERR() to update the return value and fix the issue in lan966x_ptp_add_trap(). Changes in v2: - Update vcap_get_rule() to always return an ERR_PTR(). - Update the return value fix in lan966x_ptp_add_trap(). - Update the return value check in sparx5_tc_free_rule_resources(). ==================== Reviewed-by:
-
Ruan Jinjie authored
As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), so use IS_ERR() to check the return value. Signed-off-by:
-
Ruan Jinjie authored
As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), so use IS_ERR() to fix the return value issue. Fixes: 72df3489 ("net: lan966x: Add ptp trap rules") Signed-off-by:
-
Ruan Jinjie authored
As Simon Horman suggests, update vcap_get_rule() to always return an ERR_PTR() and update the error detection conditions to use IS_ERR(), which would be more cleaner in this case. Signed-off-by:
-
