aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-04-23wl18xx: debugfs: use pm_runtime_resume_and_get() instead of pm_runtime_get_sync()Minghao Chi1-12/+6
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413093356.2538192-1-chi.minghao@zte.com.cn
2022-04-23interconnect: qcom: constify qcom_icc_bcm pointersKrzysztof Kozlowski10-90/+90
Pointers to struct qcom_icc_bcm are not modified, so they can be made const for safety. The contents of struct qcom_icc_bcm must stay non-const. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220412102623.227607-3-krzysztof.kozlowski@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-04-23interconnect: qcom: constify icc_node pointersKrzysztof Kozlowski21-143/+143
Pointers to struct qcom_icc_node (and similar structures) are not modified, so they can be made const for safety. The contents of struct qcom_icc_node must stay non-const. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220412102623.227607-2-krzysztof.kozlowski@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-04-23interconnect: qcom: constify qcom_icc_descKrzysztof Kozlowski12-96/+96
struct qcom_icc_desc is not modified so it can be made const for safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220412102623.227607-1-krzysztof.kozlowski@linaro.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
2022-04-23Merge branch 'dsa-selftests'David S. Miller14-20/+687
Vladimir Oltean says: ==================== DSA selftests When working on complex new features or reworks it becomes increasingly difficult to ensure there aren't regressions being introduced, and therefore it would be nice if we could go over the functionality we already have and write some tests for it. Verbally I know from Tobias Waldekranz that he has been working on some selftests for DSA, yet I have never seen them, so here I am adding some tests I have written which have been useful for me. The list is by no means complete (it only covers elementary functionality), but it's still good to have as a starting point. I also borrowed some refactoring changes from Joachim Wiberg that he submitted for his "net: bridge: forwarding of unknown IPv4/IPv6/MAC BUM traffic" series, but not the entirety of his selftests. I now think that his selftests have some overlap with bridge_vlan_unaware.sh and bridge_vlan_aware.sh and they should be more tightly integrated with each other - yet I didn't do that either :). Another issue I had with his selftests was that they jumped straight ahead to configure brport flags on br0 (a radical new idea still at RFC status) while we have bigger problems, and we don't have nearly enough coverage for the *existing* functionality. One idea introduced here which I haven't seen before is the symlinking of relevant forwarding selftests to the selftests/drivers/net/<my-driver>/ folder, plus a forwarding.config file. I think there's some value in having things structured this way, since the forwarding dir has so many selftests that aren't relevant to DSA that it is a bit difficult to find the ones that are. While searching for applications that I could use for multicast testing (not my domain of interest/knowledge really), I found Joachim Wiberg's mtools, mcjoin and omping, and I tried them all with various degrees of success. In particular, I was going to use mcjoin, but I faced some issues getting IPv6 multicast traffic to work in a VRF, and I bothered David Ahern about it here: https://lore.kernel.org/netdev/97eaffb8-2125-834e-641f-c99c097b6ee2@gmail.com/t/ It seems that the problem is that this application should use SO_BINDTODEVICE, yet it doesn't. So I ended up patching the bare-bones mtools (msend, mreceive) forked by Joachim from the University of Virginia's Multimedia Networks Group to include IPv6 support, and to use SO_BINDTODEVICE. This is what I'm using now for IPv6. Note that mausezahn doesn't appear to do a particularly good job of supporting IPv6 really, and I needed a program to emit the actual IP_ADD_MEMBERSHIP calls, for dev_mc_add(), so I could test RX filtering. Crafting the IGMP/MLD reports by hand doesn't really do the trick. While extremely bare-bones, the mreceive application now seems to do what I need it to. Feedback appreciated, it is very likely that I could have done things in a better way. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: drivers: dsa: add a subset of forwarding selftestsVladimir Oltean10-0/+11
This adds an initial subset of forwarding selftests which I considered to be relevant for DSA drivers, along with a forwarding.config that makes it easier to run them (disables veth pair creation, makes sure MAC addresses are unique and stable). The intention is to request driver writers to run these selftests during review and make sure that the tests pass, or at least that the problems are known. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: forwarding: add a test for local_termination.shVladimir Oltean1-0/+299
This tests the capability of switch ports to filter out undesired traffic. Different drivers are expected to have different capabilities here (so some may fail and some may pass), yet the test still has some value, for example to check for regressions. There are 2 kinds of failures, one is when a packet which should have been accepted isn't (and that should be fixed), and the other "failure" (as reported by the test) is when a packet could have been filtered out (for being unnecessary) yet it was received. The bridge driver fares particularly badly at this test: TEST: br0: Unicast IPv4 to primary MAC address [ OK ] TEST: br0: Unicast IPv4 to macvlan MAC address [ OK ] TEST: br0: Unicast IPv4 to unknown MAC address [FAIL] reception succeeded, but should have failed TEST: br0: Unicast IPv4 to unknown MAC address, promisc [ OK ] TEST: br0: Unicast IPv4 to unknown MAC address, allmulti [FAIL] reception succeeded, but should have failed TEST: br0: Multicast IPv4 to joined group [ OK ] TEST: br0: Multicast IPv4 to unknown group [FAIL] reception succeeded, but should have failed TEST: br0: Multicast IPv4 to unknown group, promisc [ OK ] TEST: br0: Multicast IPv4 to unknown group, allmulti [ OK ] TEST: br0: Multicast IPv6 to joined group [ OK ] TEST: br0: Multicast IPv6 to unknown group [FAIL] reception succeeded, but should have failed TEST: br0: Multicast IPv6 to unknown group, promisc [ OK ] TEST: br0: Multicast IPv6 to unknown group, allmulti [ OK ] mainly because it does not implement IFF_UNICAST_FLT. Yet I still think having the test (with the failures) is useful in case somebody wants to tackle that problem in the future, to make an easy before-and-after comparison. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: forwarding: add a no_forwarding.sh testVladimir Oltean1-0/+261
Bombard a standalone switch port with various kinds of traffic to ensure it is really standalone and doesn't leak packets to other switch ports. Also check for switch ports in different bridges, and switch ports in a VLAN-aware bridge but having different pvids. No forwarding should take place in either case. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: forwarding: add helper for retrieving IPv6 link-local address of interfaceVladimir Oltean1-0/+9
Pinging an IPv6 link-local multicast address selects the link-local unicast address of the interface as source, and we'd like to monitor for that in tcpdump. Add a helper to the forwarding library which retrieves the link-local IPv6 address of an interface, to make that task easier. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: forwarding: add helpers for IP multicast group joins/leavesVladimir Oltean1-0/+38
Extend the forwarding library with calls to some small C programs which join an IP multicast group and send some packets to it. Both IPv4 and IPv6 groups are supported. Use cases range from testing IGMP/MLD snooping, to RX filtering, to multicast routing. Testing multicast traffic using msend/mreceive is intended to be done using tcpdump. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: forwarding: multiple instances in tcpdump helperJoachim Wiberg2-19/+31
Extend tcpdump_start() & C:o to handle multiple instances. Useful when observing bridge operation, e.g., unicast learning/flooding, and any case of multicast distribution (to these ports but not that one ...). This means the interface argument is now a mandatory argument to all tcpdump_*() functions, hence the changes to the ocelot flower test. Signed-off-by: Joachim Wiberg <troglobit@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: forwarding: add TCPDUMP_EXTRA_FLAGS to lib.shJoachim Wiberg1-1/+2
For some use-cases we may want to change the tcpdump flags used in tcpdump_start(). For instance, observing interfaces without the PROMISC flag, e.g. to see what's really being forwarded to the bridge interface. Signed-off-by: Joachim Wiberg <troglobit@gmail.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: forwarding: add option to run tests with stable MAC addressesVladimir Oltean1-0/+36
By default, DSA switch ports inherit their MAC address from the DSA master. This works well for practical situations, but some selftests like bridge_vlan_unaware.sh loop back 2 standalone DSA ports with 2 bridged DSA ports, and require the bridge to forward packets between the standalone ports. Due to the bridge seeing that the MAC DA it needs to forward is present as a local FDB entry (it coincides with the MAC address of the bridge ports), the test packets are not forwarded, but terminated locally on br0. In turn, this makes the ping and ping6 tests fail. Address this by introducing an option to have stable MAC addresses. When mac_addr_prepare is called, the current addresses of the netifs are saved and replaced with 00:01:02:03:04:${netif number}. Then when mac_addr_restore is called at the end of the test, the original MAC addresses are restored. This ensures that the MAC addresses are unique, which makes the test pass even for DSA ports. The usage model is for the behavior to be opt-in via STABLE_MAC_ADDRS, which DSA should set to true, all others behave as before. By hooking the calls to mac_addr_prepare and mac_addr_restore within the forwarding lib itself, we do not need to patch each individual selftest, the only requirement is that pre_cleanup is called. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23topology: Fix up build warning in topology_is_visible()Greg Kroah-Hartman1-3/+1
Commit aa63a74d4535 ("topology/sysfs: Hide PPIN on systems that do not support it.") caused a build warning on some configurations: drivers/base/topology.c: In function 'topology_is_visible': drivers/base/topology.c:158:24: warning: unused variable 'dev' [-Wunused-variable] 158 | struct device *dev = kobj_to_dev(kobj); Fix this up by getting rid of the variable entirely. Fixes: aa63a74d4535 ("topology/sysfs: Hide PPIN on systems that do not support it.") Cc: Tony Luck <tony.luck@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20220422062653.3899972-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23Merge branch 'mptcp-tcp-fallback'David S. Miller10-31/+121
Mat Martineau says: ==================== mptcp: TCP fallback for established connections RFC 8684 allows some MPTCP connections to fall back to regular TCP when the MPTCP DSS checksum detects middlebox interference, there is only a single subflow, and there is no unacknowledged out-of-sequence data. When this condition is detected, the stack sends a MPTCP DSS option with an "infinite mapping" to signal that a fallback is happening, and the peers will stop sending MPTCP options in their TCP headers. The Linux MPTCP stack has not yet supported this type of fallback, instead closing the connection when the MPTCP checksum fails. This series adds support for fallback to regular TCP in a more limited scenario, for only MPTCP connections that have never connected additional subflows or transmitted out-of-sequence data. The selftests are also updated to check new MIBs that track infinite mappings. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23selftests: mptcp: add infinite map mibs checkGeliang Tang1-1/+35
This patch adds a function chk_infi_nr() to check the mibs for the infinite mapping. Invoke it in chk_join_nr() when validate_checksum is set. Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23mptcp: dump infinite_map field in mptcp_dump_mpextGeliang Tang1-2/+4
In trace event class mptcp_dump_mpext, dump the newly added infinite_map field of struct mptcp_dump_mpext too. Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23mptcp: add mib for infinite map sendingGeliang Tang3-0/+3
This patch adds a new mib named MPTCP_MIB_INFINITEMAPTX, increase it when a infinite mapping has been sent out. Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23mptcp: infinite mapping receivingGeliang Tang1-1/+3
This patch adds the infinite mapping receiving logic. When the infinite mapping is received, set the map_data_len of the subflow to 0. In subflow_check_data_avail(), only reset the subflow when the map_data_len of the subflow is non-zero. Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23mptcp: infinite mapping sendingGeliang Tang5-3/+43
This patch adds the infinite mapping sending logic. Add a new flag send_infinite_map in struct mptcp_subflow_context. Set it true when a single contiguous subflow is in use and the allow_infinite_fallback flag is true in mptcp_pm_mp_fail_received(). In mptcp_sendmsg_frag(), if this flag is true, call the new function mptcp_update_infinite_map() to set the infinite mapping. Add a new flag infinite_map in struct mptcp_ext, set it true in mptcp_update_infinite_map(), and check this flag in a new helper mptcp_check_infinite_map(). In mptcp_update_infinite_map(), set data_len to 0, and clear the send_infinite_map flag, then do fallback. In mptcp_established_options(), use the helper mptcp_check_infinite_map() to let the infinite mapping DSS can be sent out in the fallback mode. Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23mptcp: track and update contiguous data statusGeliang Tang3-1/+7
This patch adds a new member allow_infinite_fallback in mptcp_sock, which is initialized to 'true' when the connection begins and is set to 'false' on any retransmit or successful MP_JOIN. Only do infinite mapping fallback if there is a single subflow AND there have been no retransmissions AND there have never been any MP_JOINs. Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23mptcp: add the fallback checkGeliang Tang1-21/+24
This patch adds the fallback check in subflow_check_data_avail(). Only do the fallback when the msk hasn't fallen back yet. Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23mptcp: don't send RST for single subflowGeliang Tang1-5/+5
When a bad checksum is detected and a single subflow is in use, don't send RST + MP_FAIL, send data_ack + MP_FAIL instead. So invoke tcp_send_active_reset() only when mptcp_has_another_subflow() is true. Signed-off-by: Geliang Tang <geliang.tang@suse.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-23ath9k: fix QCA9561 PA bias levelThibaut VARÈNE1-1/+1
This patch fixes an invalid TX PA DC bias level on QCA9561, which results in a very low output power and very low throughput as devices are further away from the AP (compared to other 2.4GHz APs). This patch was suggested by Felix Fietkau, who noted[1]: "The value written to that register is wrong, because while the mask definition AR_CH0_TOP2_XPABIASLVL uses a different value for 9561, the shift definition AR_CH0_TOP2_XPABIASLVL_S is hardcoded to 12, which is wrong for 9561." In real life testing, without this patch the 2.4GHz throughput on Yuncore XD3200 is around 10Mbps sitting next to the AP, and closer to practical maximum with the patch applied. [1] https://lore.kernel.org/all/91c58969-c60e-2f41-00ac-737786d435ae@nbd.name Signed-off-by: Thibaut VARÈNE <hacks+kernel@slashdirt.org> Acked-by: Felix Fietkau <nbd@nbd.name> 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/20220417145145.1847-1-hacks+kernel@slashdirt.org
2022-04-23ath9k_htc: fix potential out of bounds access with invalid rxstatus->rs_keyixDan Carpenter1-0/+8
The "rxstatus->rs_keyix" eventually gets passed to test_bit() so we need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' Fixes: 4ed1a8d4a257 ("ath9k_htc: use ath9k_cmn_rx_accept") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.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/20220409061225.GA5447@kili
2022-04-23wil6210: use pm_runtime_resume_and_get() instead of pm_runtime_get_sync()Minghao Chi1-3/+2
Using pm_runtime_resume_and_get() is more appropriate for simplifing code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220411013602.2517086-1-chi.minghao@zte.com.cn
2022-04-23ath11k: Fix build warning without CONFIG_IPV6YueHaibing1-0/+2
drivers/net/wireless/ath/ath11k/mac.c:8175:13: error: ‘ath11k_mac_op_ipv6_changed’ defined but not used [-Werror=unused-function] static void ath11k_mac_op_ipv6_changed(struct ieee80211_hw *hw, ^~~~~~~~~~~~~~~~~~~~~~~~~~ Wrap it with #ifdef block to fix this. Fixes: c3c36bfe998b ("ath11k: support ARP and NS offload") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220411020843.10284-1-yuehaibing@huawei.com
2022-04-23ath11k: fix missing unlock on error in ath11k_wow_op_resume()Yang Yingliang1-1/+1
Add the missing unlock before return from function ath11k_wow_op_resume() in the error handling case. Fixes: 90bf5c8d0f7e ("ath11k: purge rx pktlog when entering WoW") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220408030912.3087293-1-yangyingliang@huawei.com
2022-04-23ath11k: Add support for SARBaochen Qiang6-0/+192
Add ath11k_mac_op_set_bios_sar_specs() to ath11k_ops, this function is called when user space application calls NL80211_CMD_SET_SAR_SPECS. ath11k also registers SAR type and frequency ranges to wiphy so user space can query SAR capabilities. This feature is currently enabled for WCN6855. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-02431-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220401120948.1312956-3-quic_bqiang@quicinc.com
2022-04-23ath11k: add support for extended wmi service bitWen Gong2-34/+56
When the WMI service bits are reported from firmware they are divided into multiple segments, with 128 bits in each segment. The first segment is processed by ath11k_wmi_service_bitmap_copy(), the second segment is processed by ath11k_service_available_event() with WMI_TAG_SERVICE_AVAILABLE_EVENT. When the service bit exceed 256 bits, then firmware reports it by tag WMI_TAG_ARRAY_UINT32 in WMI_SERVICE_AVAILABLE_EVENTID. Currently ath11k does not process the third segment. Upcoming features need to know if firmware support is available for the features, so add processing of the third segment. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20220401120948.1312956-2-quic_bqiang@quicinc.com
2022-04-23Merge tag 'usb-serial-5.18-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linusGreg Kroah-Hartman3-3/+16
Johan writes: USB-serial fixes for 5.18-rc4 Here's a fix for a potential overflow issue in the whiteheat driver when using the old ARM ABI. Included are also some new modem device ids. All have been in linux-next with no reported issues. * tag 'usb-serial-5.18-rc4' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: whiteheat: fix heap overflow in WHITEHEAT_GET_DTR_RTS USB: serial: cp210x: add PIDs for Kamstrup USB Meter Reader USB: serial: option: add support for Cinterion MV32-WA/MV32-WB USB: serial: option: add Telit 0x1057, 0x1058, 0x1075 compositions
2022-04-23usb: rework usb_maxpacket() using usb_pipe_endpoint()Vincent Mailhol1-7/+1
Rework the body of usb_maxpacket() and just rely on the usb_pipe_endpoint() helper function to retrieve the host endpoint instead of doing it by hand. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-10-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23usb: remove third argument of usb_maxpacket()Vincent Mailhol1-2/+1
Now that all users of usb_maxpacket() have been migrated to only use two arguments, remove the third variadic argument which was introduced for the transition. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-9-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23sound: usb: remove third argument of usb_maxpacket()Vincent Mailhol5-9/+9
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Jaroslav Kysela <perex@perex.cz> CC: Takashi Iwai <tiwai@suse.com> CC: Clemens Ladisch <clemens@ladisch.de> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-8-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23usb: remove third argument of usb_maxpacket()Vincent Mailhol18-44/+33
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Duncan Sands <duncan.sands@free.fr> CC: Alan Stern <stern@rowland.harvard.edu> CC: Olav Kongas <ok@artecdesign.ee> CC: Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-7-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23net: remove third argument of usb_maxpacket()Vincent Mailhol6-10/+10
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Oliver Neukum <oliver@neukum.org> CC: David S. Miller <davem@davemloft.net> CC: Jakub Kicinski <kuba@kernel.org> CC: Woojung Huh <woojung.huh@microchip.com> CC: Felix Fietkau <nbd@nbd.name> CC: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> CC: Ryder Lee <ryder.lee@mediatek.com> CC: Kalle Valo <kvalo@kernel.org> CC: Matthias Brugger <matthias.bgg@gmail.com> CC: Stanislaw Gruszka <stf_xl@wp.pl> CC: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-6-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23media: remove third argument of usb_maxpacket()Vincent Mailhol7-8/+8
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Sean Young <sean@mess.org> CC: Mauro Carvalho Chehab <mchehab@kernel.org> CC: Benjamin Valentin <benpicco@googlemail.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-5-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23Input: remove third argument of usb_maxpacket()Vincent Mailhol6-6/+6
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Ville Syrjala <syrjala@sci.fi> CC: Dmitry Torokhov <dmitry.torokhov@gmail.com> CC: Henk Vergonet <Henk.Vergonet@gmail.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-4-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23HID: usbhid: remove third argument of usb_maxpacket()Vincent Mailhol3-3/+3
The third argument of usb_maxpacket(): in_out has been deprecated because it could be derived from the second argument (e.g. using usb_pipeout(pipe)). N.B. function usb_maxpacket() was made variadic to accommodate the transition from the old prototype with three arguments to the new one with only two arguments (so that no renaming is needed). The variadic argument is to be removed once all users of usb_maxpacket() get migrated. CC: Jiri Kosina <jikos@kernel.org> CC: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-3-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23usb: deprecate the third argument of usb_maxpacket()Vincent Mailhol1-11/+5
This is a transitional patch with the ultimate goal of changing the prototype of usb_maxpacket() from: | static inline __u16 | usb_maxpacket(struct usb_device *udev, int pipe, int is_out) into: | static inline u16 usb_maxpacket(struct usb_device *udev, int pipe) The third argument of usb_maxpacket(): is_out gets removed because it can be derived from its second argument: pipe using usb_pipeout(pipe). Furthermore, in the current version, ubs_pipeout(pipe) is called regardless in order to sanitize the is_out parameter. In order to make a smooth change, we first deprecate the is_out parameter by simply ignoring it (using a variadic function) and will remove it later, once all the callers get updated. The body of the function is reworked accordingly and is_out is replaced by usb_pipeout(pipe). The WARN_ON() calls become unnecessary and get removed. Finally, the return type is changed from __u16 to u16 because this is not a UAPI function. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/20220317035514.6378-2-mailhol.vincent@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23USB: hcd-pci: Fully suspend across freeze/thaw cycleEvan Green1-2/+2
The documentation for the freeze() method says that it "should quiesce the device so that it doesn't generate IRQs or DMA". The unspoken consequence of not doing this is that MSIs aimed at non-boot CPUs may get fully lost if they're sent during the period where the target CPU is offline. The current callbacks for USB HCD do not fully quiesce interrupts, specifically on XHCI. Change to use the full suspend/resume flow for freeze/thaw to ensure interrupts are fully quiesced. This fixes issues where USB devices fail to thaw during hibernation because XHCI misses its interrupt and cannot recover. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20220421103751.v3.2.I8226c7fdae88329ef70957b96a39b346c69a914e@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23USB: core: Disable remote wakeup for freeze/quiesceEvan Green1-12/+13
The PM_EVENT_FREEZE and PM_EVENT_QUIESCE messages should cause the device to stop generating interrupts. USB core was previously allowing devices that were already runtime suspended to keep remote wakeup enabled if they had gone down that way. This violates the contract with pm, and can potentially cause MSI interrupts to be lost. Change that so that if a device is runtime suspended with remote wakeups enabled, it will be resumed to ensure remote wakeup is always disabled across a freeze. Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20220421103751.v3.1.I2c636c4decc358f5e6c27b810748904cc69beada@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23usb: dwc3: pci: Fix pm_runtime_get_sync() error checkingZheng Yongjun1-1/+1
If the device is already in a runtime PM enabled state pm_runtime_get_sync() will return 1, so a test for negative value should be used to check for errors. Fixes: 8eed00b237a28 ("usb: dwc3: pci: Runtime resume child device from wq") Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Link: https://lore.kernel.org/r/20220422062652.10575-1-zhengyongjun3@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23drivers: usb: host: Fix deadlock in oxu_bus_suspend()Duoming Zhou1-0/+2
There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20220417120305.64577-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23usb: dwc3: gadget: Replace list_for_each_entry_safe() if using givebackWesley Cheng1-4/+16
The list_for_each_entry_safe() macro saves the current item (n) and the item after (n+1), so that n can be safely removed without corrupting the list. However, when traversing the list and removing items using gadget giveback, the DWC3 lock is briefly released, allowing other routines to execute. There is a situation where, while items are being removed from the cancelled_list using dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable routine is running in parallel (due to UDC unbind). As the cleanup routine removes n, and the pullup disable removes n+1, once the cleanup retakes the DWC3 lock, it references a request who was already removed/handled. With list debug enabled, this leads to a panic. Ensure all instances of the macro are replaced where gadget giveback is used. Example call stack: Thread#1: __dwc3_gadget_ep_set_halt() - CLEAR HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list] ->spin_unlock ->Thread#2 executes ... ->dwc3_gadget_giveback(n+1) ->Already removed! Thread#2: dwc3_gadget_pullup() ->waiting for dwc3 spin_lock ... ->Thread#1 released lock ->dwc3_stop_active_transfers() ->dwc3_remove_requests() ->fetches n+1 item from cancelled_list (n removed by Thread#1) ->dwc3_gadget_giveback() ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list] ->spin_unlock Fixes: d4f1afe5e896 ("usb: dwc3: gadget: move requests to cancelled_list") Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20220414183521.23451-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23usb: dwc3: EP clear halt leading to clearing of delayed_statusWesley Cheng3-1/+7
The usb_ep_clear_halt() API can be called from the function driver, and translates to dwc3_gadget_ep_set_halt(). This routine is shared with when the host issues a clear feature ENDPOINT_HALT, and is differentiated by the protocol argument. If the following sequence occurs, there can be a situation where the delayed_status flag is improperly cleared for the wrong SETUP transaction: 1. Vendor specific control transfer returns USB_GADGET_DELAYED_STATUS. 2. DWC3 gadget sets dwc->delayed_status to '1'. 3. Another function driver issues a usb_ep_clear_halt() call. 4. DWC3 gadget issues dwc3_stop_active_transfer() and sets DWC3_EP_PENDING_CLEAR_STALL. 5. EP command complete interrupt triggers for the end transfer, and dwc3_ep0_send_delayed_status() is allowed to run, as delayed_status is '1' due to step#1. 6. STATUS phase is sent, and delayed_status is cleared. 7. Vendor specific control transfer is finished being handled, and issues usb_composite_setup_continue(). This results in queuing of a data phase. Cache the protocol flag so that DWC3 gadget is aware of when the clear halt is due to a SETUP request from the host versus when it is sourced from a function driver. This allows for the EP command complete interrupt to know if it needs to issue a delayed status phase. Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> Link: https://lore.kernel.org/r/20220414073902.21960-1-quic_wcheng@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-23wlcore: cmd: using pm_runtime_resume_and_get() instead of pm_runtime_get_sync()Minghao Chi1-4/+2
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and pm_runtime_put_noidle. This change is just to simplify the code, no actual functional changes. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220420090141.2588553-1-chi.minghao@zte.com.cn
2022-04-23wlcore: sdio: using pm_runtime_resume_and_get() instead of pm_runtime_get_sync()Minghao Chi1-2/+1
Using pm_runtime_resume_and_get() to replace pm_runtime_get_sync and pm_runtime_put_noidle. This change is just to simplify the code, no actual functional changes. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220419110445.2574424-1-chi.minghao@zte.com.cn
2022-04-23wlcore: vendor_cmd: use pm_runtime_resume_and_get() instead of pm_runtime_get_sync()Minghao Chi1-12/+6
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413093939.2538825-1-chi.minghao@zte.com.cn
2022-04-23wlcore: testmode: use pm_runtime_resume_and_get() instead of pm_runtime_get_sync()Minghao Chi1-8/+4
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413093502.2538316-1-chi.minghao@zte.com.cn