summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-06-05Merge tag 'ovpn-net-20250603' of https://github.com/OpenVPN/ovpn-net-nextPaolo Abeni11-108/+128
Antonio Quartulli says: ==================== In this batch you can find the following bug fixes: Patch 1: when releasing a UDP socket we were wrongly invoking setup_udp_tunnel_sock() with an empty config. This was not properly shutting down the UDP encap state. With this patch we simply undo what was done during setup. Patch 2: ovpn was holding a reference to a 'struct socket' without increasing its reference counter. This was intended and worked as expected until we hit a race condition where user space tries to close the socket while kernel space is also releasing it. In this case the (struct socket *)->sk member would disappear under our feet leading to a null-ptr-deref. This patch fixes this issue by having struct ovpn_socket hold a reference directly to the sk member while also increasing its reference counter. Patch 3: in case of errors along the TCP RX path (softirq) we want to immediately delete the peer, but this operation may sleep. With this patch we move the peer deletion to a scheduled worker. Patch 4 and 5 are instead fixing minor issues in the ovpn kselftests. * tag 'ovpn-net-20250603' of https://github.com/OpenVPN/ovpn-net-next: selftest/net/ovpn: fix missing file selftest/net/ovpn: fix TCP socket creation ovpn: avoid sleep in atomic context in TCP RX error path ovpn: ensure sk is still valid during cleanup ovpn: properly deconfigure UDP-tunnel ==================== Link: https://patch.msgid.link/20250603111110.4575-1-antonio@openvpn.net/ Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05s390/mm: Fix in_atomic() handling in do_secure_storage_access()Heiko Carstens1-0/+2
Kernel user spaces accesses to not exported pages in atomic context incorrectly try to resolve the page fault. With debug options enabled call traces like this can be seen: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0 ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90 INFO: lockdep is turned off. It is not allowed to take the mmap_lock while in atomic context. Therefore handle such a secure storage access fault as if the accessed page is not mapped: the uaccess function will return -EFAULT, and the caller has to deal with this. Usually this means that the access is retried in process context, which allows to resolve the page fault (or in this case export the page). Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Link: https://lore.kernel.org/r/20250603134936.1314139-1-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2025-06-05net: wwan: mhi_wwan_mbim: use correct mux_id for multiplexingDaniele Palmas1-6/+3
Recent Qualcomm chipsets like SDX72/75 require MBIM sessionId mapping to muxId in the range (0x70-0x8F) for the PCIe tethered use. This has been partially addressed by the referenced commit, mapping the default data call to muxId = 112, but the multiplexed data calls scenario was not properly considered, mapping sessionId = 1 to muxId 1, while it should have been 113. Fix this by moving the session_id assignment logic to mhi_mbim_newlink, in order to map sessionId = n to muxId = n + WDS_BIND_MUX_DATA_PORT_MUX_ID. Fixes: 65bc58c3dcad ("net: wwan: mhi: make default data link id configurable") Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20250603091204.2802840-1-dnlplm@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05Merge tag 'iwlwifi-fixes-2025-06-04' of ↵Johannes Berg4-8/+9
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi fixes ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-05wifi: cfg80211/mac80211: correctly parse S1G beacon optional elementsLachlan Hodges4-32/+83
S1G beacons are not traditional beacons but a type of extension frame. Extension frames contain the frame control and duration fields, followed by zero or more optional fields before the frame body. These optional fields are distinct from the variable length elements. The presence of optional fields is indicated in the frame control field. To correctly locate the elements offset, the frame control must be parsed to identify which optional fields are present. Currently, mac80211 parses S1G beacons based on fixed assumptions about the frame layout, without inspecting the frame control field. This can result in incorrect offsets to the "variable" portion of the frame. Properly parse S1G beacon frames by using the field lengths defined in IEEE 802.11-2024, section 9.3.4.3, ensuring that the elements offset is calculated accurately. Fixes: 9eaffe5078ca ("cfg80211: convert S1G beacon to scan results") Fixes: cd418ba63f0c ("mac80211: convert S1G beacon to scan results") Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com> Link: https://patch.msgid.link/20250603053538.468562-1-lachlan.hodges@morsemicro.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-05um: remove "extern" from implementation of sigchld_handlerBenjamin Berg1-2/+2
There is no need to mark the function as extern in the implementation. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506051226.X8r7X5aa-lkp@intel.com/ Fixes: 8420e08fe3a5 ("um: Track userspace children dying in SECCOMP mode") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20250605050325.1077208-2-benjamin@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-05um: fix unused variable warningBenjamin Berg1-3/+0
The code was updated to access the PID of the userspace stub process in a different way, making the local cpu variable obsolete. Remove it. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506050008.AwXLNxQX-lkp@intel.com/ Fixes: 406d17c6c370 ("um: Implement kernel side of SECCOMP based process handling") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Link: https://patch.msgid.link/20250605050325.1077208-1-benjamin@sipsolutions.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-05Merge branch 'net-dsa-b53-fix-rgmii-ports'Paolo Abeni1-36/+22
Jonas Gorski says: ==================== net: dsa: b53: fix RGMII ports RGMII ports on BCM63xx were not really working, especially with PHYs that support EEE and are capable of configuring their own RGMII delays. So let's make them work, and fix additional minor rgmii related issues found while working on it. With a BCM96328BU-P300: Before: [ 3.580000] b53-switch 10700000.switch GbE3 (uninitialized): validation of rgmii with support 0000000,00000000,00000000,000062ff and advertisement 0000000,00000000,00000000,000062ff failed: -EINVAL [ 3.600000] b53-switch 10700000.switch GbE3 (uninitialized): failed to connect to PHY: -EINVAL [ 3.610000] b53-switch 10700000.switch GbE3 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 4 [ 3.620000] b53-switch 10700000.switch GbE1 (uninitialized): validation of rgmii with support 0000000,00000000,00000000,000062ff and advertisement 0000000,00000000,00000000,000062ff failed: -EINVAL [ 3.640000] b53-switch 10700000.switch GbE1 (uninitialized): failed to connect to PHY: -EINVAL [ 3.650000] b53-switch 10700000.switch GbE1 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 5 [ 3.660000] b53-switch 10700000.switch GbE4 (uninitialized): validation of rgmii with support 0000000,00000000,00000000,000062ff and advertisement 0000000,00000000,00000000,000062ff failed: -EINVAL [ 3.680000] b53-switch 10700000.switch GbE4 (uninitialized): failed to connect to PHY: -EINVAL [ 3.690000] b53-switch 10700000.switch GbE4 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 6 [ 3.700000] b53-switch 10700000.switch GbE5 (uninitialized): validation of rgmii with support 0000000,00000000,00000000,000062ff and advertisement 0000000,00000000,00000000,000062ff failed: -EINVAL [ 3.720000] b53-switch 10700000.switch GbE5 (uninitialized): failed to connect to PHY: -EINVAL [ 3.730000] b53-switch 10700000.switch GbE5 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 7 After: [ 3.700000] b53-switch 10700000.switch GbE3 (uninitialized): PHY [mdio_mux-0.1:00] driver [Broadcom BCM54612E] (irq=POLL) [ 3.770000] b53-switch 10700000.switch GbE1 (uninitialized): PHY [mdio_mux-0.1:01] driver [Broadcom BCM54612E] (irq=POLL) [ 3.850000] b53-switch 10700000.switch GbE4 (uninitialized): PHY [mdio_mux-0.1:18] driver [Broadcom BCM54612E] (irq=POLL) [ 3.920000] b53-switch 10700000.switch GbE5 (uninitialized): PHY [mdio_mux-0.1:19] driver [Broadcom BCM54612E] (irq=POLL) ==================== Link: https://patch.msgid.link/20250602193953.1010487-1-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05net: dsa: b53: do not touch DLL_IQQD on bcm53115Jonas Gorski1-3/+5
According to OpenMDK, bit 2 of the RGMII register has a different meaning for BCM53115 [1]: "DLL_IQQD 1: In the IDDQ mode, power is down0: Normal function mode" Configuring RGMII delay works without setting this bit, so let's keep it at the default. For other chips, we always set it, so not clearing it is not an issue. One would assume BCM53118 works the same, but OpenMDK is not quite sure what this bit actually means [2]: "BYPASS_IMP_2NS_DEL #1: In the IDDQ mode, power is down#0: Normal function mode1: Bypass dll65_2ns_del IP0: Use dll65_2ns_del IP" So lets keep setting it for now. [1] https://github.com/Broadcom-Network-Switching-Software/OpenMDK/blob/master/cdk/PKG/chip/bcm53115/bcm53115_a0_defs.h#L19871 [2] https://github.com/Broadcom-Network-Switching-Software/OpenMDK/blob/master/cdk/PKG/chip/bcm53118/bcm53118_a0_defs.h#L14392 Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Link: https://patch.msgid.link/20250602193953.1010487-6-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05net: dsa: b53: allow RGMII for bcm63xx RGMII portsJonas Gorski1-0/+4
Add RGMII to supported interfaces for BCM63xx RGMII ports so they can be actually used in RGMII mode. Without this, phylink will fail to configure them: [ 3.580000] b53-switch 10700000.switch GbE3 (uninitialized): validation of rgmii with support 0000000,00000000,00000000,000062ff and advertisement 0000000,00000000,00000000,000062ff failed: -EINVAL [ 3.600000] b53-switch 10700000.switch GbE3 (uninitialized): failed to connect to PHY: -EINVAL [ 3.610000] b53-switch 10700000.switch GbE3 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 4 Fixes: ce3bf94871f7 ("net: dsa: b53: add support for BCM63xx RGMIIs") Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Link: https://patch.msgid.link/20250602193953.1010487-5-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05net: dsa: b53: do not configure bcm63xx's IMP port interfaceJonas Gorski1-14/+8
The IMP port is not a valid RGMII interface, but hard wired to internal, so we shouldn't touch the undefined register B53_RGMII_CTRL_IMP. While this does not seem to have any side effects, let's not touch it at all, so limit RGMII configuration on bcm63xx to the actual RGMII ports. Fixes: ce3bf94871f7 ("net: dsa: b53: add support for BCM63xx RGMIIs") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250602193953.1010487-4-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05net: dsa: b53: do not enable RGMII delay on bcm63xxJonas Gorski1-18/+1
bcm63xx's RGMII ports are always in MAC mode, never in PHY mode, so we shouldn't enable any delays and let the PHY handle any delays as necessary. This fixes using RGMII ports with normal PHYs like BCM54612E, which will handle the delay in the PHY. Fixes: ce3bf94871f7 ("net: dsa: b53: add support for BCM63xx RGMIIs") Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250602193953.1010487-3-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05net: dsa: b53: do not enable EEE on bcm63xxJonas Gorski1-1/+4
BCM63xx internal switches do not support EEE, but provide multiple RGMII ports where external PHYs may be connected. If one of these PHYs are EEE capable, we may try to enable EEE for the MACs, which then hangs the system on access of the (non-existent) EEE registers. Fix this by checking if the switch actually supports EEE before attempting to configure it. Fixes: 22256b0afb12 ("net: dsa: b53: Move EEE functions to b53") Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Link: https://patch.msgid.link/20250602193953.1010487-2-jonas.gorski@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05net: ti: icssg-prueth: Fix swapped TX stats for MII interfaces.Meghana Malladi1-0/+8
In MII mode, Tx lines are swapped for port0 and port1, which means Tx port0 receives data from PRU1 and the Tx port1 receives data from PRU0. This is an expected hardware behavior and reading the Tx stats needs to be handled accordingly in the driver. Update the driver to read Tx stats from the PRU1 for port0 and PRU0 for port1. Fixes: c1e10d5dc7a1 ("net: ti: icssg-prueth: Add ICSSG Stats") Signed-off-by: Meghana Malladi <m-malladi@ti.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250603052904.431203-1-m-malladi@ti.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-06-05selftests: netfilter: nft_nat.sh: add test for reverse clash with natFlorian Westphal1-5/+76
This will fail without the previous bug fix because we erronously believe that the clashing entry went way. However, the clash exists in the opposite direction due to an existing nat mapping: PASS: IP statless for ns2-LgTIuS ERROR: failed to test udp ns1-x4iyOW to ns2-LgTIuS with dnat rule step 2, result: "" This is partially adapted from test instructions from the below ubuntu tracker. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2109889 Signed-off-by: Florian Westphal <fw@strlen.de> Tested-by: Shaun Brady <brady.1345@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-06-05netfilter: nf_nat: also check reverse tuple to obtain clashing entryFlorian Westphal1-3/+9
The logic added in the blamed commit was supposed to only omit nat source port allocation if neither the existing nor the new entry are subject to NAT. However, its not enough to lookup the conntrack based on the proposed tuple, we must also check the reverse direction. Otherwise there are esoteric cases where the collision is in the reverse direction because that colliding connection has a port rewrite, but the new entry doesn't. In this case, we only check the new entry and then erronously conclude that no clash exists anymore. The existing (udp) tuple is: a:p -> b:P, with nat translation to s:P, i.e. pure daddr rewrite, reverse tuple in conntrack table is s:P -> a:p. When another UDP packet is sent directly to s, i.e. a:p->s:P, this is correctly detected as a colliding entry: tuple is taken by existing reply tuple in reverse direction. But the colliding conntrack is only searched for with unreversed direction, and we can't find such entry matching a:p->s:P. The incorrect conclusion is that the clashing entry has timed out and that no port address translation is required. Such conntrack will then be discarded at nf_confirm time because the proposed reverse direction clashes with an existing mapping in the conntrack table. Search for the reverse tuple too, this will then check the NAT bits of the colliding entry and triggers port reallocation. Followp patch extends nft_nat.sh selftest to cover this scenario. The IPS_SEQ_ADJUST change is also a bug fix: Instead of checking for SEQ_ADJ this tested for SEEN_REPLY and ASSURED by accident -- _BIT is only for use with the test_bit() API. This bug has little consequence in practice, because the sequence number adjustments are only useful for TCP which doesn't support clash resolution. The existing test case (conntrack_reverse_clash.sh) exercise a race condition path (parallel conntrack creation on different CPUs), so the colliding entries have neither SEEN_REPLY nor ASSURED set. Thanks to Yafang Shao and Shaun Brady for an initial investigation of this bug. Fixes: d8f84a9bc7c4 ("netfilter: nf_nat: don't try nat source port reallocation for reverse dir clash") Closes: https://bugzilla.netfilter.org/show_bug.cgi?id=1795 Reported-by: Yafang Shao <laoar.shao@gmail.com> Reported-by: Shaun Brady <brady.1345@gmail.com> Signed-off-by: Florian Westphal <fw@strlen.de> Tested-by: Yafang Shao <laoar.shao@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-06-05selftests: netfilter: nft_concat_range.sh: add datapath check for map fill bugFlorian Westphal1-4/+58
commit 0935ee6032df ("selftests: netfilter: add test case for recent mismatch bug") added a regression check for incorrect initial fill of the result map that was fixed with 791a615b7ad2 ("netfilter: nf_set_pipapo: fix initial map fill"). The test used 'nft get element', i.e., control plane checks for match/nomatch results. The control plane however doesn't use avx2 version, so we need to send+match packets. As the additional packet match/nomatch is slow, don't do this for every element added/removed: add and use maybe_send_(no)match helpers and use them. Signed-off-by: Florian Westphal <fw@strlen.de> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-06-05selftests: netfilter: nft_concat_range.sh: prefer per element counters for ↵Florian Westphal1-10/+30
testing The selftest uses following rule: ... @test counter name "test" Then sends a packet, then checks if the named counter did increment or not. This is fine for the 'no-match' test case: If anything matches the counter increments and the test fails as expected. But for the 'should match' test cases this isn't optimal. Consider buggy matching, where the packet matches entry x, but it should have matched entry y. In that case the test would erronously pass. Rework the selftest to use per-element counters to avoid this. After sending packet that should have matched entry x, query the relevant element via 'nft reset element' and check that its counter had incremented. The 'nomatch' case isn't altered, no entry should match so the named counter must be 0, changing it to the per-element counter would then pass if another entry matches. The downside of this change is a slight increase in test run-time by a few seconds. Signed-off-by: Florian Westphal <fw@strlen.de> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-06-05netfilter: nf_set_pipapo_avx2: fix initial map fillFlorian Westphal1-1/+20
If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map. The early fix was incomplete and did only fix up the generic C implementation. A followup patch adds a test case to nft_concat_range.sh. Fixes: 791a615b7ad2 ("netfilter: nf_set_pipapo: fix initial map fill") Signed-off-by: Florian Westphal <fw@strlen.de> Reviewed-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2025-06-05Merge tag 'asoc-fix-v6.16-merge-window' of ↵Takashi Iwai20-68/+184
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v6.16 A bunch of fixes, including a big batch for the Intel AVS driver, and one new device ID. It's all device specific.
2025-06-05drm/panel-simple: fix the warnings for the Evervision VGG644804Michael Walle1-2/+3
The panel lacked the connector type which causes a warning. Adding the connector type reveals wrong bus_flags and bits per pixel. Fix all of it. Fixes: 1319f2178bdf ("drm/panel-simple: add Evervision VGG644804 panel entry") Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250520074110.655114-1-mwalle@kernel.org
2025-06-05Merge tag 'rust-6.16' of ↵Linus Torvalds69-387/+1973
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust updates from Miguel Ojeda: "Toolchain and infrastructure: - KUnit '#[test]'s: - Support KUnit-mapped 'assert!' macros. The support that landed last cycle was very basic, and the 'assert!' macros panicked since they were the standard library ones. Now, they are mapped to the KUnit ones in a similar way to how is done for doctests, reusing the infrastructure there. With this, a failing test like: #[test] fn my_first_test() { assert_eq!(42, 43); } will report: # my_first_test: ASSERTION FAILED at rust/kernel/lib.rs:251 Expected 42 == 43 to be true, but is false # my_first_test.speed: normal not ok 1 my_first_test - Support tests with checked 'Result' return types. The return value of test functions that return a 'Result' will be checked, thus one can now easily catch errors when e.g. using the '?' operator in tests. With this, a failing test like: #[test] fn my_test() -> Result { f()?; Ok(()) } will report: # my_test: ASSERTION FAILED at rust/kernel/lib.rs:321 Expected is_test_result_ok(my_test()) to be true, but is false # my_test.speed: normal not ok 1 my_test - Add 'kunit_tests' to the prelude. - Clarify the remaining language unstable features in use. - Compile 'core' with edition 2024 for Rust >= 1.87. - Workaround 'bindgen' issue with forward references to 'enum' types. - objtool: relax slice condition to cover more 'noreturn' functions. - Use absolute paths in macros referencing 'core' and 'kernel' crates. - Skip '-mno-fdpic' flag for bindgen in GCC 32-bit arm builds. - Clean some 'doc_markdown' lint hits -- we may enable it later on. 'kernel' crate: - 'alloc' module: - 'Box': support for type coercion, e.g. 'Box<T>' to 'Box<dyn U>' if 'T' implements 'U'. - 'Vec': implement new methods (prerequisites for nova-core and binder): 'truncate', 'resize', 'clear', 'pop', 'push_within_capacity' (with new error type 'PushError'), 'drain_all', 'retain', 'remove' (with new error type 'RemoveError'), insert_within_capacity' (with new error type 'InsertError'). In addition, simplify 'push' using 'spare_capacity_mut', split 'set_len' into 'inc_len' and 'dec_len', add type invariant 'len <= capacity' and simplify 'truncate' using 'dec_len'. - 'time' module: - Morph the Rust hrtimer subsystem into the Rust timekeeping subsystem, covering delay, sleep, timekeeping, timers. This new subsystem has all the relevant timekeeping C maintainers listed in the entry. - Replace 'Ktime' with 'Delta' and 'Instant' types to represent a duration of time and a point in time. - Temporarily add 'Ktime' to 'hrtimer' module to allow 'hrtimer' to delay converting to 'Instant' and 'Delta'. - 'xarray' module: - Add a Rust abstraction for the 'xarray' data structure. This abstraction allows Rust code to leverage the 'xarray' to store types that implement 'ForeignOwnable'. This support is a dependency for memory backing feature of the Rust null block driver, which is waiting to be merged. - Set up an entry in 'MAINTAINERS' for the XArray Rust support. Patches will go to the new Rust XArray tree and then via the Rust subsystem tree for now. - Allow 'ForeignOwnable' to carry information about the pointed-to type. This helps asserting alignment requirements for the pointer passed to the foreign language. - 'container_of!': retain pointer mut-ness and add a compile-time check of the type of the first parameter ('$field_ptr'). - Support optional message in 'static_assert!'. - Add C FFI types (e.g. 'c_int') to the prelude. - 'str' module: simplify KUnit tests 'format!' macro, convert 'rusttest' tests into KUnit, take advantage of the '-> Result' support in KUnit '#[test]'s. - 'list' module: add examples for 'List', fix path of 'assert_pinned!' (so far unused macro rule). - 'workqueue' module: remove 'HasWork::OFFSET'. - 'page' module: add 'inline' attribute. 'macros' crate: - 'module' macro: place 'cleanup_module()' in '.exit.text' section. 'pin-init' crate: - Add 'Wrapper<T>' trait for creating pin-initializers for wrapper structs with a structurally pinned value such as 'UnsafeCell<T>' or 'MaybeUninit<T>'. - Add 'MaybeZeroable' derive macro to try to derive 'Zeroable', but not error if not all fields implement it. This is needed to derive 'Zeroable' for all bindgen-generated structs. - Add 'unsafe fn cast_[pin_]init()' functions to unsafely change the initialized type of an initializer. These are utilized by the 'Wrapper<T>' implementations. - Add support for visibility in 'Zeroable' derive macro. - Add support for 'union's in 'Zeroable' derive macro. - Upstream dev news: streamline CI, fix some bugs. Add new workflows to check if the user-space version and the one in the kernel tree have diverged. Use the issues tab [1] to track them, which should help folks report and diagnose issues w.r.t. 'pin-init' better. [1] https://github.com/rust-for-linux/pin-init/issues Documentation: - Testing: add docs on the new KUnit '#[test]' tests. - Coding guidelines: explain that '///' vs. '//' applies to private items too. Add section on C FFI types. - Quick Start guide: update Ubuntu instructions and split them into "25.04" and "24.04 LTS and older". And a few other cleanups and improvements" * tag 'rust-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (78 commits) rust: list: Fix typo `much` in arc.rs rust: check type of `$ptr` in `container_of!` rust: workqueue: remove HasWork::OFFSET rust: retain pointer mut-ness in `container_of!` Documentation: rust: testing: add docs on the new KUnit `#[test]` tests Documentation: rust: rename `#[test]`s to "`rusttest` host tests" rust: str: take advantage of the `-> Result` support in KUnit `#[test]`'s rust: str: simplify KUnit tests `format!` macro rust: str: convert `rusttest` tests into KUnit rust: add `kunit_tests` to the prelude rust: kunit: support checked `-> Result`s in KUnit `#[test]`s rust: kunit: support KUnit-mapped `assert!` macros in `#[test]`s rust: make section names plural rust: list: fix path of `assert_pinned!` rust: compile libcore with edition 2024 for 1.87+ rust: dma: add missing Markdown code span rust: task: add missing Markdown code spans and intra-doc links rust: pci: fix docs related to missing Markdown code spans rust: alloc: add missing Markdown code span rust: alloc: add missing Markdown code spans ...
2025-06-05Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds2-6/+6
Pull bpf fixes from Alexei Starovoitov: "Two small fixes to selftests" * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: selftests/bpf: Fix selftest btf_tag/btf_type_tag_percpu_vmlinux_helper failure selftests/bpf: Fix bpf selftest build error
2025-06-05Merge tag 'drm-msm-fixes-2025-06-04' of ↵Dave Airlie2-6/+10
https://gitlab.freedesktop.org/drm/msm into drm-next Just some mailmap/MAINTAINER email address updates Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://lore.kernel.org/r/CAF6AEGuW1kpUijxzLCc4TKph72-PfXvHTttNu214_1GB-R8qwg@mail.gmail.com
2025-06-05Merge tag '6.16-rc-ksmbd-server-fixes' of git://git.samba.org/ksmbdLinus Torvalds10-93/+53
Pull smb server updates from Steve French: "Four smb3 server fixes: - Fix for special character handling when mounting with "posix" - Fix for mounts from Mac for fs that don't provide unique inode numbers - Two cleanup patches (e.g. for crypto calls)" * tag '6.16-rc-ksmbd-server-fixes' of git://git.samba.org/ksmbd: ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension ksmbd: provide zero as a unique ID to the Mac client ksmbd: remove unnecessary softdep on crc32 ksmbd: use SHA-256 library API instead of crypto_shash API
2025-06-05Merge tag 'bcachefs-2025-06-04' of git://evilpiepirate.org/bcachefsLinus Torvalds98-1757/+2323
Pull more bcachefs updates from Kent Overstreet: "More bcachefs updates: - More stack usage improvements (~600 bytes) - Define CLASS()es for some commonly used types, and convert most rcu_read_lock() uses to the new lock guards - New introspection: - Superblock error counters are now available in sysfs: previously, they were only visible with 'show-super', which doesn't provide a live view - New tracepoint, error_throw(), which is called any time we return an error and start to unwind - Repair - check_fix_ptrs() can now repair btree node roots - We can now repair when we've somehow ended up with the journal using a superblock bucket - Revert some leftovers from the aborted directory i_size feature, and add repair code: some userspace programs (e.g. sshfs) were getting confused It seems in 6.15 there's a bug where i_nlink on the vfs inode has been getting incorrectly set to 0, with some unfortunate results; list_journal analysis showed bch2_inode_rm() being called (by bch2_evict_inode()) when it clearly should not have been. - bch2_inode_rm() now runs "should we be deleting this inode?" checks that were previously only run when deleting unlinked inodes in recovery - check_subvol() was treating a dangling subvol (pointing to a missing root inode) like a dangling dirent, and deleting it. This was the really unfortunate one: check_subvol() will now recreate the root inode if necessary This took longer to debug than it should have, and we lost several filesystems unnecessarily, because users have been ignoring the release notes and blindly running 'fsck -y'. Debugging required reconstructing what happened through analyzing the journal, when ideally someone would have noticed 'hey, fsck is asking me if I want to repair this: it usually doesn't, maybe I should run this in dry run mode and check what's going on?' As a reminder, fsck errors are being marked as autofix once we've verified, in real world usage, that they're working correctly; blindly running 'fsck -y' on an experimental filesystem is playing with fire Up to this incident we've had an excellent track record of not losing data, so let's try to learn from this one This is a community effort, I wouldn't be able to get this done without the help of all the people QAing and providing excellent bug reports and feedback based on real world usage. But please don't ignore advice and expect me to pick up the pieces If an error isn't marked as autofix, and it /is/ happening in the wild, that's also something I need to know about so we can check it out and add it to the autofix list if repair looks good. I haven't been getting those reports, and I should be; since we don't have any sort of telemetry yet I am absolutely dependent on user reports Now I'll be spending the weekend working on new repair code to see if I can get a filesystem back for a user who didn't have backups" * tag 'bcachefs-2025-06-04' of git://evilpiepirate.org/bcachefs: (69 commits) bcachefs: add cond_resched() to handle_overwrites() bcachefs: Make journal read log message a bit quieter bcachefs: Fix subvol to missing root repair bcachefs: Run may_delete_deleted_inode() checks in bch2_inode_rm() bcachefs: delete dead code from may_delete_deleted_inode() bcachefs: Add flags to subvolume_to_text() bcachefs: Fix oops in btree_node_seq_matches() bcachefs: Fix dirent_casefold_mismatch repair bcachefs: Fix bch2_fsck_rename_dirent() for casefold bcachefs: Redo bch2_dirent_init_name() bcachefs: Fix -Wc23-extensions in bch2_check_dirents() bcachefs: Run check_dirents second time if required bcachefs: Run snapshot deletion out of system_long_wq bcachefs: Make check_key_has_snapshot safer bcachefs: BCH_RECOVERY_PASS_NO_RATELIMIT bcachefs: bch2_require_recovery_pass() bcachefs: bch_err_throw() bcachefs: Repair code for directory i_size bcachefs: Kill un-reverted directory i_size code bcachefs: Delete redundant fsck_err() ...
2025-06-05riscv: misaligned: add a function to check misalign trap delegabilityClément Léger2-2/+21
Checking for the delegability of the misaligned access trap is needed for the KVM FWFT extension implementation. Add a function to get the delegability of the misaligned trap exception. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-11-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: misaligned: move emulated access uniformity check in a functionClément Léger1-6/+14
Split the code that check for the uniformity of misaligned accesses performance on all cpus from check_unaligned_access_emulated_all_cpus() to its own function which will be used for delegation check. No functional changes intended. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-10-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: misaligned: declare misaligned_access_speed under CONFIG_RISCV_MISALIGNEDClément Léger2-3/+4
While misaligned_access_speed was defined in a file compile with CONFIG_RISCV_MISALIGNED, its definition was under CONFIG_RISCV_SCALAR_MISALIGNED. This resulted in compilation problems when using it in a file compiled with CONFIG_RISCV_MISALIGNED. Move the declaration under CONFIG_RISCV_MISALIGNED so that it can be used unconditionnally when compiled with that config and remove the check for that variable in traps_misaligned.c. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20250523101932.1594077-9-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: misaligned: use on_each_cpu() for scalar misaligned access probingClément Léger1-2/+6
schedule_on_each_cpu() was used without any good reason while documented as very slow. This call was in the boot path, so better use on_each_cpu() for scalar misaligned checking. Vector misaligned check still needs to use schedule_on_each_cpu() since it requires irqs to be enabled but that's less of a problem since this code is ran in a kthread. Add a comment to explicit that. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-8-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: misaligned: request misaligned exception from SBIClément Léger3-5/+77
Now that the kernel can handle misaligned accesses in S-mode, request misaligned access exception delegation from SBI. This uses the FWFT SBI extension defined in SBI version 3.0. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20250523101932.1594077-7-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: sbi: add SBI FWFT extension callsClément Léger1-1/+19
Add FWFT extension calls. This will be ratified in SBI V3.0 hence, it is provided as a separate commit that can be left out if needed. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-6-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: sbi: add FWFT extension interfaceClément Léger2-0/+74
This SBI extensions enables supervisor mode to control feature that are under M-mode control (For instance, Svadu menvcfg ADUE bit, Ssdbltrp DTE, etc). Add an interface to set local features for a specific cpu mask as well as for the online cpu mask. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-5-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: sbi: add new SBI error mappingsClément Léger1-0/+10
A few new errors have been added with SBI V3.0, maps them as close as possible to errno values. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-4-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: sbi: remove useless parenthesisClément Léger1-3/+3
A few parenthesis in check for SBI version/extension were useless, remove them. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-3-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-05riscv: sbi: add Firmware Feature (FWFT) SBI extensions definitionsClément Léger1-0/+33
The Firmware Features extension (FWFT) was added as part of the SBI 3.0 specification. Add SBI definitions to use this extension. Signed-off-by: Clément Léger <cleger@rivosinc.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Tested-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20250523101932.1594077-2-cleger@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-06-04pidfs: never refuse ppid == 0 in PIDFD_GET_INFOMike Yuan1-1/+1
In systemd we spotted an issue after switching to ioctl(PIDFD_GET_INFO) for obtaining pid number the pidfd refers to, that for processes with a parent from outer pidns PIDFD_GET_INFO unexpectedly yields -ESRCH [1]. It turned out that there's an arbitrary check blocking this, which is not really sensible given getppid() happily returns 0 for such processes. Just drop the spurious check and userspace ought to handle ppid == 0 properly everywhere. [1] https://github.com/systemd/systemd/issues/37715 Fixes: cdda1f26e74b ("pidfd: add ioctl to retrieve pid info") Signed-off-by: Mike Yuan <me@yhndnzj.com> Link: https://lore.kernel.org/20250604150238.42664-1-me@yhndnzj.com Cc: Christian Brauner <brauner@kernel.org> Cc: Luca Boccassi <luca.boccassi@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-04bcachefs: add cond_resched() to handle_overwrites()Kent Overstreet1-0/+2
Fix soft lockup warnings in btree nodes can. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Make journal read log message a bit quieterKent Overstreet1-5/+5
Users seem to be assuming that the 'dropped unflushed entries' message at the end of journal read indicates some sort of problem, when it does not - we expect there to be entries in the journal that weren't commited, it's purely informational so that we can correlate journal sequence numbers elsewhere when debugging. Shorten the log message a bit to hopefully make this clearer. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Fix subvol to missing root repairKent Overstreet1-4/+14
We had a bug where the root inode of a subvolume was erronously deleted: bch2_evict_inode() called bch2_inode_rm(), meaning the VFS inode's i_nlink was somehow set to 0 when it shouldn't have - the inode in the btree indicated it clearly was not unlinked. This has been addressed with additional safety checks in bch2_inode_rm() - pulling in the safety checks we already were doing when deleting unlinked inodes in recovery - but the really disastrous bug was in check_subvols(), which on finding a dangling subvol (subvol with a missing root inode) would delete the subvolume. I assume this bug dates from early check_directory_structure() code, which originally handled subvolumes and normal paths - the idea being that still live contents of the subvolume would get reattached somewhere. But that's incorrect, and disastrously so; deleting a subvolume triggers deleting the snapshot ID it points to, deleting the entire contents. The correct way to repair is to recreate the root inode if it's missing; then any contents will get reattached under that subvolume's lost+found. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Run may_delete_deleted_inode() checks in bch2_inode_rm()Kent Overstreet4-19/+62
We had a bug where bch2_evict_inode() incorrectly called bch2_inode_rm() - the journal clearly showed the inode was not unlinked. We've got checks that we use in recovery when cleaning up deleted inodes, lift them to bch2_inode_rm() as well. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: delete dead code from may_delete_deleted_inode()Kent Overstreet1-12/+3
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Add flags to subvolume_to_text()Kent Overstreet1-0/+7
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Fix oops in btree_node_seq_matches()Kent Overstreet1-2/+21
btree_update_nodes_written() needs to wait on in-flight writes to old nodes before marking them as freed. But it has no reason to pin those old nodes in memory, so some trickyness ensues. The update we're completing deleted references to those nodes from the btree, so we know if they've been evicted they can't be pulled back in. We just have to check if the nodes we have pointers to are still those old nodes, and haven't been reused. To do that we check the node's "sequence number" (actually a random 64 bit cookie), but that lives in the node's data buffer. 'struct btree' can't be freed until filesystem shutdown (as they're quite small), but the data buffers can be freed or swapped around. Commit 1f88c3567495, which was fixing a kmsan warning, assumed that we could safely do this locklessly with just a READ_ONCE() - if we've got a non-null ptr it would be safe to read from. But that's not true if the data buffer is a vmalloc allocation, so we need to restore the locking that commit deleted (or alternatively RCU free those data buffers, but there's no other reason for that). Fixes: 1f88c3567495 ("bcachefs: Fix a KMSAN splat in btree_update_nodes_written()") Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Fix dirent_casefold_mismatch repairKent Overstreet5-118/+162
Instead of simply recreating a mis-casefolded dirent, use the str_hash repair code, which will rename it if necessary - the dirent might have been created again with the correct casefolding. Factor out out bch2_str_hash_repair key() from __bch2_str_hash_check_key() for the new path to use, and export bch2_dirent_create_key() as well. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Fix bch2_fsck_rename_dirent() for casefoldKent Overstreet3-13/+25
bch2_fsck_renamed_dirent was creating bch_dirent keys open-coded - but we need to use the appropriate helper, if the directory is casefolded. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Redo bch2_dirent_init_name()Kent Overstreet2-70/+66
Redo (and simplify somewhat) how casefolded and non casefolded dirents are initialized, and export this to be used by fsck_rename_dirent(). Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04bcachefs: Fix -Wc23-extensions in bch2_check_dirents()Nathan Chancellor1-1/+2
Clang warns (or errors with CONFIG_WERROR=y): fs/bcachefs/fsck.c:2325:2: error: label followed by a declaration is a C23 extension [-Werror,-Wc23-extensions] 2325 | int ret = bch2_trans_run(c, | ^ On clang-17 and older, this is an unconditional error: fs/bcachefs/fsck.c:2325:2: error: expected expression 2325 | int ret = bch2_trans_run(c, | ^ Move the declaration of ret to the top of the function to resolve both ways this issue manifests. Fixes: c72def523799 ("bcachefs: Run check_dirents second time if required") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
2025-06-04MAINTAINERS: .mailmap: update Rob Clark's email addressRob Clark2-3/+5
Remap historical email addresses to @oss.qualcomm.com. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/656974/
2025-06-04mailmap: Update entry for Akhil P OommenAkhil P Oommen1-1/+2
A new policy within qualcomm requires me to use a new email address for all future contributions to Linux kernel. Update the mailmap to map my old email addresses to the new one, ie akhilpo@oss.qualcomm.com Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Link: https://lore.kernel.org/lkml/20250603121508.296678-1-quic_akhilpo@quicinc.com Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-03 17:51:58 +0300