aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2025-09-27Bluetooth: hci_core: Detect if an ISO link has stalledLuiz Augusto von Dentz3-8/+28
This attempts to detect if an ISO link has been waiting for an ISO buffer for longer than the maximum allowed transport latency then proceed to use hci_link_tx_to which prints an error and disconnects. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: ISO: Use sk_sndtimeo as conn_timeoutLuiz Augusto von Dentz3-18/+28
This aligns the usage of socket sk_sndtimeo as conn_timeout when initiating a connection and then use it when scheduling the resulting HCI command, similar to what has been done in bf98feea5b65 ("Bluetooth: hci_conn: Always use sk_timeo as conn_timeout"). Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: HCI: Fix using LE/ACL buffers for ISO packetsLuiz Augusto von Dentz3-21/+8
ISO packets shall not use LE/ACL buffer pool, that feature seem to be exclusive to LE-ACL only. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: ISO: Don't initiate CIS connections if there are no buffersLuiz Augusto von Dentz1-0/+7
If the controller has no buffers left return -ENOBUFF to indicate that iso_cnt might be out of sync. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27MAINTAINERS: add a sub-entry for the Qualcomm bluetooth driverBartosz Golaszewski1-0/+7
Patches modifying drivers/bluetooth/hci_qca.c should be Cc'ed to the linux-arm-msm mailing list so that Qualcomm maintainers and reviewers can get notified about proposed changes to it. Add a sub-entry that adds the mailing list to the list of addresses returned by get_maintainer.pl. Acked-by: Konrad Dybcio <konradybcio@kernel.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Refactor Device CoredumpKiran K2-145/+77
As device coredumps are not HCI traces, maintain the device coredump at the driver level and eliminate the dependency on hdev_devcd*() Signed-off-by: Kiran K <kiran.k@intel.com> Fixes: 07e6bddb54b4 ("Bluetooth: btintel_pcie: Add support for device coredump") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Use strscpy() instead of strscpy_pad()Thorsten Blum1-2/+3
kzalloc() already zero-initializes the destination buffer 'data', making strscpy() sufficient for safely copying 'name'. The additional NUL-padding performed by strscpy_pad() is unnecessary. Add a new local variable to store the length of 'name' and reuse it instead of recalculating the same length. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: Annotate struct hci_drv_rp_read_info with __counted_by_le()Thorsten Blum1-1/+1
Add the __counted_by_le() compiler attribute to the flexible array member 'supported_commands' to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Define hdev->wakeup() callbackChandrashekar Devegowda1-0/+8
Implement hdev->wakeup() callback to support Wake On BT feature. Test steps: 1. echo enabled > /sys/bus/pci/devices/0000:00:14.7/power/wakeup 2. connect bluetooth hid device 3. put the system to suspend - rtcwake -m mem -s 300 4. press any key on hid to wake up the system Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1Zenm Chen1-0/+2
Add USB ID 2001:332a for D-Link AX9U rev. A1 which is based on a Realtek RTL8851BU chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=332a Rev= 0.00 S: Manufacturer=Realtek S: Product=802.11ax WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtw89_8851bu_git E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: stable@vger.kernel.org # 6.12.x Signed-off-by: Zenm Chen <zenmchen@gmail.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Move model comment before its definitionLuiz Augusto von Dentz1-4/+8
This prevents the comments going over 80 columns which is still required for Bluetooth code. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Add id of Scorpious, Panther Lake-H484Kiran K1-0/+1
sudo lspci -v -k -d 8086:e376 00:14.7 Bluetooth: Intel Corporation Device e376 Subsystem: Intel Corporation Device 0011 Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 14 Memory at 14815368000 (64-bit, non-prefetchable) [size=16K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [80] MSI-X: Enable+ Count=32 Masked- Capabilities: [100] Latency Tolerance Reporting Kernel driver in use: btintel_pcie Kernel modules: btintel_pcie Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Add Bluetooth core/platform as commentsKiran K1-3/+3
Add Bluetooth CNVi core and platform names to the PCI device table for each device ID as a comment. Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel_pcie: Add support for _suspend() / _resume()Chandrashekar Devegowda1-0/+89
This patch implements _suspend() and _resume() functions for the Bluetooth controller. When the system enters a suspended state, the driver notifies the controller to perform necessary housekeeping tasks by writing to the sleep control register and waits for an alive interrupt. The firmware raises the alive interrupt when it has transitioned to the D3 state. The same flow occurs when the system resumes. Command to test host initiated wakeup after 60 seconds sudo rtcwake -m mem -s 60 dmesg log (tested on Whale Peak2 on Panther Lake platform) On system suspend: [Fri Jul 25 11:05:37 2025] Bluetooth: hci0: device entered into d3 state from d0 in 80 us On system resume: [Fri Jul 25 11:06:36 2025] Bluetooth: hci0: device entered into d0 state from d3 in 7117 us Signed-off-by: Chandrashekar Devegowda <chandrashekar.devegowda@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27Bluetooth: btintel: Add support for BlazarIW coreKiran K2-0/+4
Add support for the BlazarIW Bluetooth core used in the Wildcat Lake platform. HCI traces: < HCI Command: Intel Read Version (0x3f|0x0005) plen 1 Requested Type: All Supported Types(0xff) > HCI Event: Command Complete (0x0e) plen 122 Intel Read Version (0x3f|0x0005) ncmd 1 Status: Success (0x00) ..... CNVi BT(18): 0x00223700 - BlazarIW(0x22) ..... ..... Signed-off-by: Vijay Satija <vijay.satija@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2025-09-27selftests/bpf: Add test case for different expected_attach_typeDaniel Borkmann2-1/+59
Add a small test case which adds two programs - one calling the other through a tailcall - and check that BPF rejects them in case of different expected_attach_type values: # ./vmtest.sh -- ./test_progs -t xdp_devmap [...] #641/1 xdp_devmap_attach/DEVMAP with programs in entries:OK #641/2 xdp_devmap_attach/DEVMAP with frags programs in entries:OK #641/3 xdp_devmap_attach/Verifier check of DEVMAP programs:OK #641/4 xdp_devmap_attach/DEVMAP with programs in entries on veth:OK #641 xdp_devmap_attach:OK Summary: 2/4 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20250926171201.188490-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-09-27bpf: Enforce expected_attach_type for tailcall compatibilityDaniel Borkmann2-0/+6
Yinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object. The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as the entry point for bpf_prog_test_run_xdp() and its expected_attach_type can neither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slot of a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAP to pass xdp_is_valid_access() validation. The program returns struct xdp_md's egress_ifindex, and the latter is only allowed to be accessed under mentioned expected_attach_type. progB is then inserted into the tailcall which progA calls. The underlying issue goes beyond XDP though. Another example are programs of type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as well as sock_addr_func_proto() have different logic depending on the programs' expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAME should not be allowed doing a tailcall into a program which calls bpf_bind() out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT. In short, specifying expected_attach_type allows to open up additional functionality or restrictions beyond what the basic bpf_prog_type enables. The use of tailcalls must not violate these constraints. Fix it by enforcing expected_attach_type in __bpf_prog_map_compatible(). Note that we only enforce this for tailcall maps, but not for BPF devmaps or cpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() and cpu_map_bpf_prog_run*() which set up a new environment / context and therefore these situations are not prone to this issue. Fixes: 5e43f899b03a ("bpf: Check attach type at prog load time") Reported-by: Yinhao Hu <dddddd@hust.edu.cn> Reported-by: Kaiyan Mei <M202472210@hust.edu.cn> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20250926171201.188490-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-09-27tracing: fgraph: Protect return handler from recursion loopMasami Hiramatsu (Google)1-0/+12
function_graph_enter_regs() prevents itself from recursion by ftrace_test_recursion_trylock(), but __ftrace_return_to_handler(), which is called at the exit, does not prevent such recursion. Therefore, while it can prevent recursive calls from fgraph_ops::entryfunc(), it is not able to prevent recursive calls to fgraph from fgraph_ops::retfunc(), resulting in a recursive loop. This can lead an unexpected recursion bug reported by Menglong. is_endbr() is called in __ftrace_return_to_handler -> fprobe_return -> kprobe_multi_link_exit_handler -> is_endbr. To fix this issue, acquire ftrace_test_recursion_trylock() in the __ftrace_return_to_handler() after unwind the shadow stack to mark this section must prevent recursive call of fgraph inside user-defined fgraph_ops::retfunc(). This is essentially a fix to commit 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer"), because before that fgraph was only used from the function graph tracer. Fprobe allowed user to run any callbacks from fgraph after that commit. Reported-by: Menglong Dong <menglong8.dong@gmail.com> Closes: https://lore.kernel.org/all/20250918120939.1706585-1-dongml2@chinatelecom.cn/ Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Cc: stable@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/175852292275.307379.9040117316112640553.stgit@devnote2 Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Tested-by: Menglong Dong <menglong8.dong@gmail.com> Acked-by: Menglong Dong <menglong8.dong@gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-279p: sysfs_init: don't hardcode error to ENOMEMRandall P. Embry1-2/+5
v9fs_sysfs_init() always returned -ENOMEM on failure; return the actual sysfs_create_group() error instead. Signed-off-by: Randall P. Embry <rpembry@gmail.com> Message-ID: <20250926-v9fs_misc-v1-3-a8b3907fc04d@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-09-279p: fix /sys/fs/9p/caches overwriting itselfRandall P. Embry1-1/+1
caches_show() overwrote its buffer on each iteration, so only the last cache tag was visible in sysfs output. Properly append with snprintf(buf + count, …). Signed-off-by: Randall P. Embry <rpembry@gmail.com> Message-ID: <20250926-v9fs_misc-v1-2-a8b3907fc04d@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-09-279p: clean up comment typosRandall P. Embry1-4/+3
Fix a few minor typos in comments (e.g. "trasnport" → "transport"). Signed-off-by: Randall P. Embry <rpembry@gmail.com> Message-ID: <20250926-v9fs_misc-v1-1-a8b3907fc04d@codewreck.org> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
2025-09-27PM: sleep: Do not wait on SYNC_STATE_ONLY device linksPin-yen Lin3-3/+6
Device links with DL_FLAG_SYNC_STATE_ONLY should not affect system suspend and resume, and functions like device_reorder_to_tail() and device_link_add() don't try to reorder the consumers with that flag. However, dpm_wait_for_consumers() and dpm_wait_for_suppliers() don't check thas flag before triggering dpm_wait(), leading to potential hang during suspend/resume. This can be reproduced on MT8186 Corsola Chromebook with devicetree like: usb-a-connector { compatible = "usb-a-connector"; port { usb_a_con: endpoint { remote-endpoint = <&usb_hs>; }; }; }; usb_host { compatible = "mediatek,mt8186-xhci", "mediatek,mtk-xhci"; port { usb_hs: endpoint { remote-endpoint = <&usb_a_con>; }; }; }; In this case, the two nodes form a cycle and a SYNC_STATE_ONLY devlink between usb_host (supplier) and usb-a-connector (consumer) is created. Address this by exporting device_link_flag_is_sync_state_only() and making dpm_wait_for_consumers() and dpm_wait_for_suppliers() use it when deciding if dpm_wait() should be called. Fixes: 05ef983e0d65a ("driver core: Add device link support for SYNC_STATE_ONLY flag") Signed-off-by: Pin-yen Lin <treapking@chromium.org> Link: https://patch.msgid.link/20250926102320.4053167-1-treapking@chromium.org [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-27ALSA: hda/realtek: Add quirk for HP Spectre 14t-ea100Takashi Iwai1-0/+1
HP-Spectre 14t-ea100 model has no speaker output unless booting previously from Windows on dual boot, a reboot while on Linux will stop the speakers working. Applying the existing quirk for HP Spectre X360 EU0xxx seems fixing this speaker problem. Reported-by: Kaden Berger <kadenb816@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/aMxdGAmfOQ6VPNU8@archlinux Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-09-27PM: runtime: Update kerneldoc return codesBrian Norris1-25/+31
APIs based on __pm_runtime_idle() (pm_runtime_idle(), pm_request_idle()) do not return 1 when already suspended. They return -EAGAIN. This is already covered in the docs, so the entry for "1" is redundant and conflicting. (pm_runtime_put() and pm_runtime_put_sync() were previously incorrect, but that's fixed in "PM: runtime: pm_runtime_put{,_sync}() returns 1 when already suspended", to ensure consistency with APIs like pm_runtime_put_autosuspend().) RPM_GET_PUT APIs based on __pm_runtime_suspend() do return 1 when already suspended, but the language is a little unclear -- it's not really an "error", so it seems better to list as a clarification before the 0/success case. Additionally, they only actually return 1 when the refcount makes it to 0; if the usage counter is still non-zero, we return 0. pm_runtime_put(), etc., also don't appear at first like they can ever see "-EAGAIN: Runtime PM usage_count non-zero", because in non-racy conditions, pm_runtime_put() would drop its reference count, see it's non-zero, and return early (in __pm_runtime_idle()). However, it's possible to race with another actor that increments the usage_count afterward, since rpm_idle() is protected by a separate lock; in such a case, we may see -EAGAIN. Because this case is only seen in the presence of concurrent actors, it makes sense to clarify that this is when "usage_count **became** non-zero", by way of some racing actor. Lastly, pm_runtime_put_sync_suspend() duplicated some -EAGAIN language. Fix that. Fixes: 271ff96d6066 ("PM: runtime: Document return values of suspend-related API functions") Link: https://lore.kernel.org/linux-pm/aJ5pkEJuixTaybV4@google.com/ Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: 6.17+ <stable@vger.kernel.org> # 6.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-27PM: runtime: Make put{,_sync}() return 1 when already suspendedBrian Norris2-1/+4
The pm_runtime.h docs say pm_runtime_put() and pm_runtime_put_sync() return 1 when already suspended, but this is not true -- they return -EAGAIN. On the other hand, pm_runtime_put_sync_suspend() and pm_runtime_put_sync_autosuspend() *do* return 1. This is an artifact of the fact that the former are built on rpm_idle(), whereas the latter are built on rpm_suspend(). There are precious few pm_runtime_put()/pm_runtime_put_sync() callers that check the return code at all, but most of them only log errors, and usually only for negative error codes. None of them should be treating this as an error, so: * at best, this may fix some case where a driver treats this condition as an error, when it shouldn't; * at worst, this should make no effect; and * somewhere in between, we could potentially clear up non-fatal log messages. Fix the pm_runtime_already_suspended_test() while tweaking the behavior. The test makes a lot more sense when these all return 1 when the device is already suspended: pm_runtime_put_sync(dev); pm_runtime_suspend(dev); pm_runtime_autosuspend(dev); pm_request_autosuspend(dev); pm_runtime_put_sync_autosuspend(dev); Notably, I've avoided testing the return codes for these, since they really should be ignored by callers, and we may make them 'void' altogether: pm_runtime_put(dev); pm_runtime_put_autosuspend(dev); Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Dhruva Gole <d-gole@ti.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-27PM: runtime: Add basic kunit tests for API contractsBrian Norris3-0/+260
In exploring the various return codes and failure modes of runtime PM APIs, I found it helpful to verify and codify many of them in unit tests, especially given that even the kerneldoc can be rather complex to reason through, and it also has had subtle errors of its own. Notably, I avoid testing the return codes for pm_runtime_put() and pm_runtime_put_autosuspend(), since code that checks them is probably wrong, and we're considering making them return 'void' altogether. I still test the sync() variants, since those have a bit more meaning to them. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-27bpftool: Remove duplicate string.h headerJiapeng Chong1-1/+0
./tools/bpf/bpftool/sign.c: string.h is included more than once. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=25502 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Acked-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/r/20250926095240.3397539-2-jiapeng.chong@linux.alibaba.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-09-27bpf: Remove duplicate crypto/sha2.h headerJiapeng Chong1-1/+0
./include/linux/bpf.h: crypto/sha2.h is included more than once. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=25501 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Acked-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/r/20250926095240.3397539-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-09-27rtla/actions: Fix condition for buffer reallocationWander Lairson Costa1-1/+1
The condition to check if the actions buffer needs to be resized was incorrect. The check `self->size >= self->len` would evaluate to true on almost every call to `actions_new()`, causing the buffer to be reallocated unnecessarily each time an action was added. Fix the condition to `self->len >= self.size`, ensuring that the buffer is only resized when it is actually full. Cc: John Kacur <jkacur@redhat.com> Cc: Luis Goncalves <lgoncalv@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Chang Yin <cyin@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Cc: Crystal Wood <crwood@redhat.com> Cc: Gabriele Monaco <gmonaco@redhat.com> Link: https://lore.kernel.org/20250915181101.52513-1-wander@redhat.com Fixes: 6ea082b171e00 ("rtla/timerlat: Add action on threshold feature") Signed-off-by: Wander Lairson Costa <wander@redhat.com> Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27rtla: Fix buffer overflow in actions_parseIvan Pravdin1-1/+1
Currently, tests 3 and 13-22 in tests/timerlat.t fail with error: *** buffer overflow detected ***: terminated timeout: the monitored command dumped core The result of running `sudo make check` is tests/timerlat.t (Wstat: 0 Tests: 22 Failed: 11) Failed tests: 3, 13-22 Files=3, Tests=34, 140 wallclock secs ( 0.07 usr 0.01 sys + 27.63 cusr 27.96 csys = 55.67 CPU) Result: FAIL Fix buffer overflow in actions_parse to avoid this error. After this change, the tests results are tests/hwnoise.t ... ok tests/osnoise.t ... ok tests/timerlat.t .. ok All tests successful. Files=3, Tests=34, 186 wallclock secs ( 0.06 usr 0.01 sys + 41.10 cusr 44.38 csys = 85.55 CPU) Result: PASS Link: https://lore.kernel.org/164ffc2ec8edacaf1295789dad82a07817b6263d.1757034919.git.ipravdin.official@gmail.com Fixes: 6ea082b171e0 ("rtla/timerlat: Add action on threshold feature") Signed-off-by: Ivan Pravdin <ipravdin.official@gmail.com> Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27tools/rtla: Add remaining support for osnoise actionsCrystal Wood15-74/+168
The basic functionality came with the consolidation; now hook up the command line options, and add documentation and tests. Cc: John Kacur <jkacur@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Link: https://lore.kernel.org/20250907022325.243930-8-crwood@redhat.com Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27tools/rtla: Add test engine support for unexpected outputCrystal Wood1-8/+18
Add a check() parameter to indicate which text must not appear in the output. Simplify the code so that we can print failures as they happen rather than trying to figure out what went wrong after printing "not ok". This also means that "not ok" gets printed after the info rather than before, which seems more intuitive anyway. Cc: John Kacur <jkacur@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Link: https://lore.kernel.org/20250907022325.243930-7-crwood@redhat.com Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27tools/rtla: Fix -A option name in test commentCrystal Wood1-2/+2
This was changed to --on-threshold when the patches were applied. Cc: John Kacur <jkacur@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Link: https://lore.kernel.org/20250907022325.243930-6-crwood@redhat.com Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27tools/rtla: Consolidate code between osnoise/timerlat and hist/topCrystal Wood12-1194/+792
Currently a lot of code is duplicated between the different rtla tools, making maintenance more difficult, and encouraging divergence such as features that are only implemented for certain tools even though they could be more broadly applicable. Merge the various main() functions into a common run_tool() with an ops struct for tool-specific details. Implement enough support for actions on osnoise to not need to keep the old params->trace_output path. Cc: John Kacur <jkacur@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Link: https://lore.kernel.org/20250907022325.243930-5-crwood@redhat.com Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27tools/rtla: Create common_apply_config()Crystal Wood9-150/+142
Merge the common bits of osnoise_apply_config() and timerlat_apply_config(). Put the result in a new common.c, and move enough things to common.h so that common.c does not need to include osnoise.h. Cc: John Kacur <jkacur@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Link: https://lore.kernel.org/20250907022325.243930-4-crwood@redhat.com Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27tools/rtla: Move top/hist params into common structCrystal Wood8-163/+152
The hist members were very similar between timerlat and top, so just use one common hist struct. output_divisor, quiet, and pretty printing are pretty generic concepts that can go in the main struct even if not every specific tool (currently) uses them. Cc: John Kacur <jkacur@redhat.com> Cc: Costa Shulyupin <costa.shul@redhat.com> Link: https://lore.kernel.org/20250907022325.243930-3-crwood@redhat.com Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-27tools/rtla: Consolidate common parameters into shared structureCosta Shulyupin10-252/+253
timerlat_params and osnoise_params structures contain 15 identical fields. Introduce a new header common.h and define a common_params structure to consolidate shared fields, reduce code duplication, and enhance maintainability. Cc: John Kacur <jkacur@redhat.com> Link: https://lore.kernel.org/20250907022325.243930-2-crwood@redhat.com Reviewed-by: Tomas Glozar <tglozar@redhat.com> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com> Signed-off-by: Crystal Wood <crwood@redhat.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-09-26Merge branch 'net-macb-various-fixes'Jakub Kicinski3-75/+69
Théo Lebrun says: ==================== net: macb: various fixes Fix a few disparate topics in MACB: [PATCH net v6 1/5] dt-bindings: net: cdns,macb: allow tsu_clk without tx_clk [PATCH net v6 2/5] net: macb: remove illusion about TBQPH/RBQPH being per-queue [PATCH net v6 3/5] net: macb: move ring size computation to functions [PATCH net v6 4/5] net: macb: single dma_alloc_coherent() for DMA descriptors [PATCH net v6 5/5] net: macb: avoid dealing with endianness in macb_set_hwaddr() Patch 3/5 is a rework that simplifies patch 4/5. It is the only non-fix. Pending series on MACB are: (1) many cleanup patches, (2) patches for EyeQ5 support and (3) XDP work. Those will be sent targeting net-next/main once this series lands there, aiming to minimise merge conflicts. Old version of(1) and (2) are visible in the V2 revision [0]. [0]: https://lore.kernel.org/lkml/20250627-macb-v2-0-ff8207d0bb77@bootlin.com/ ==================== Link: https://patch.msgid.link/20250923-macb-fixes-v6-0-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: macb: avoid dealing with endianness in macb_set_hwaddr()Théo Lebrun1-2/+2
bp->dev->dev_addr is of type `unsigned char *`. Casting it to a u32 pointer and dereferencing implies dealing manually with endianness, which is error-prone. Replace by calls to get_unaligned_le32|le16() helpers. This was found using sparse: ⟩ make C=2 drivers/net/ethernet/cadence/macb_main.o warning: incorrect type in assignment (different base types) expected unsigned int [usertype] bottom got restricted __le32 [usertype] warning: incorrect type in assignment (different base types) expected unsigned short [usertype] top got restricted __le16 [usertype] ... Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-5-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: macb: single dma_alloc_coherent() for DMA descriptorsThéo Lebrun1-39/+41
Move from 2*NUM_QUEUES dma_alloc_coherent() for DMA descriptor rings to 2 calls overall. Issue is with how all queues share the same register for configuring the upper 32-bits of Tx/Rx descriptor rings. Taking Tx, notice how TBQPH does *not* depend on the queue index: #define GEM_TBQP(hw_q) (0x0440 + ((hw_q) << 2)) #define GEM_TBQPH(hw_q) (0x04C8) queue_writel(queue, TBQP, lower_32_bits(queue->tx_ring_dma)); #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT if (bp->hw_dma_cap & HW_DMA_CAP_64B) queue_writel(queue, TBQPH, upper_32_bits(queue->tx_ring_dma)); #endif To maximise our chances of getting valid DMA addresses, we do a single dma_alloc_coherent() across queues. This improves the odds because alloc_pages() guarantees natural alignment. Other codepaths (IOMMU or dev/arch dma_map_ops) don't give high enough guarantees (even page-aligned isn't enough). Two consideration: - dma_alloc_coherent() gives us page alignment. Here we remove this constraint meaning each queue's ring won't be page-aligned anymore. - This can save some tiny amounts of memory. Fewer allocations means (1) less overhead (constant cost per alloc) and (2) less wasted bytes due to alignment constraints. Example for (2): 4 queues, default ring size (512), 64-bit DMA descriptors, 16K pages: - Before: 8 allocs of 8K, each rounded to 16K => 64K wasted. - After: 2 allocs of 32K => 0K wasted. Fixes: 02c958dd3446 ("net/macb: add TX multiqueue support for gem") Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com> # on sam9x75 Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-4-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: macb: move ring size computation to functionsThéo Lebrun1-11/+16
The tx/rx ring size calculation is somewhat complex and partially hidden behind a macro. Move that out of the {RX,TX}_RING_BYTES() macros and macb_{alloc,free}_consistent() functions into neat separate functions. In macb_free_consistent(), we drop the size variable and directly call the size helpers in the arguments list. In macb_alloc_consistent(), we keep the size variable that is used by netdev_dbg() calls. Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-3-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26net: macb: remove illusion about TBQPH/RBQPH being per-queueThéo Lebrun2-37/+24
The MACB driver acts as if TBQPH/RBQPH are configurable on a per queue basis; this is a lie. A single register configures the upper 32 bits of each DMA descriptor buffers for all queues. Concrete actions: - Drop GEM_TBQPH/GEM_RBQPH macros which have a queue index argument. Only use MACB_TBQPH/MACB_RBQPH constants. - Drop struct macb_queue->TBQPH/RBQPH fields. - In macb_init_buffers(): do a single write to TBQPH and RBQPH for all queues instead of a write per queue. - In macb_tx_error_task(): drop the write to TBQPH. - In macb_alloc_consistent(): if allocations give different upper 32-bits, fail. Previously, it would have lead to silent memory corruption as queues would have used the upper 32 bits of the alloc from queue 0 and their own low 32 bits. - In macb_suspend(): if we use the tie off descriptor for suspend, do the write once for all queues instead of once per queue. Fixes: fff8019a08b6 ("net: macb: Add 64 bit addressing support for GEM") Fixes: ae1f2a56d273 ("net: macb: Added support for many RX queues") Reviewed-by: Sean Anderson <sean.anderson@linux.dev> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250923-macb-fixes-v6-2-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26dt-bindings: net: cdns,macb: allow tsu_clk without tx_clkThéo Lebrun1-1/+1
Allow providing tsu_clk without a tx_clk as both are optional. This is about relaxing unneeded constraints. It so happened that in the past HW that needed a tsu_clk always needed a tx_clk. Fixes: 4e5b6de1f46d ("dt-bindings: net: cdns,macb: Convert to json-schema") Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com> Link: https://patch.msgid.link/20250923-macb-fixes-v6-1-772d655cdeb6@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26Merge branch 'selftests-mark-auto-deferring-functions-clearly'Jakub Kicinski18-237/+225
Petr Machata says: ==================== selftests: Mark auto-deferring functions clearly selftests/net/lib.sh contains a suite of iproute2 wrappers that automatically schedule the corresponding cleanup through defer. The fact they do so is however not immediately obvious, one needs to know which functions are handling the deferral behind the scenes, and which expect the caller to handle cleanups themselves. A convention for these auto-deferring functions would help both writing and patch review. This patchset does so by marking these functions with an adf_ prefix. We already have a few such functions: forwarding/lib.sh has adf_mcd_start() and a few selftests add private helpers that conform to this convention. Patches #1 to #8 gradually convert individual functions, one per patch. Patch #9 renames an auto-deferring private helpers named dfr_* to adf_*. The plan is not to retro-rename all private helpers, but I happened to know about this one. Patches #10 to #12 introduce several autodefer helpers for commonly used forwarding/lib.sh functions, and opportunistically convert straightforward instances of 'action; defer counteraction' to the new helpers. Patch #13 adds some README verbiage to pitch defer and the adf_* convention. ==================== Link: https://patch.msgid.link/cover.1758821127.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26selftests: forwarding: README: Mention defer, adf_Petr Machata1-0/+15
Mention how it would be nice if new code used defer. Also if it does that in dirtying helpers, how it would be nice if these were named adf_*. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/0764bdb9266cd516da23ddeec110e01118cf981e.1758821127.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26selftests: forwarding: lib: Add an autodefer variant of forwarding_enable()Petr Machata4-9/+9
Most forwarding tests invoke forwarding_enable() to enable the router and forwarding_restore() to restore the original configuration. Add a helper, adf_forwarding_enable(), which is like forwarding_enable(), but takes care of scheduling the cleanup automatically. Convert the tests that currently use defer to schedule the cleanup. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/78b752c40069cde21c44dcf4c7b966a76a0eef2c.1758821127.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26selftests: forwarding: lib: Add an autodefer variant of simple_if_init()Petr Machata13-52/+31
Most forwarding tests invoke simple_if_init() to set up a VRF-based "host" and simple_if_fini() to tear it down again. Add a helper, adf_simple_if_init(), which is like simple_if_fini(), but takes care of scheduling the cleanup automatically. Convert the tests that currently use defer to schedule the cleanup. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/6b9ee1a7946a36fd32a47fdb1aa9325198ffc695.1758821127.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26selftests: forwarding: lib: Add an autodefer variant of vrf_prepare()Petr Machata13-24/+18
Most forwarding tests invoke vrf_prepare() to set up VRF forwarding and vrf_cleanup() to restore the original configuration. Add a helper, adf_vrf_prepare(), which is like vrf_prepare(), but takes care of scheduling the cleanup automatically. Convert a number of tests that currently use defer to schedule the cleanup. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/2f2000e54ae700d560a8d6128322dade3bd2207e.1758821127.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26selftests: net: vlan_bridge_binding: Rename dfr_set_binding_*() to adf_*Petr Machata1-4/+4
This test contains two autodefer-like helpers, but namespaces them as dfr_* instead of adf_* like this patchset. Rename them. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/5f0c81b39e9e1f56f706cc4b53f82238a1d1e2f9.1758821127.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-26selftests: net: lib: Rename bridge_vlan_add() to adf_*Petr Machata4-23/+23
Rename this function to mark it as autodefer. For details, see the discussion in the cover letter. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/93526ce79e635a3ec34753c796edf0c96711547d.1758821127.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>