summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-09ACPI: processor: Do not expose global variable acpi_idle_driverHuisong Li
Move the cpuidle driver check from __acpi_processor_start() to acpi_processor_power_init() which allows variable acpi_idle_driver to become static. No intentional functional impact. Signed-off-by: Huisong Li <lihuisong@huawei.com> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251223100914.2407069-7-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09ACPI: processor: idle: Rearrange declarations in header fileHuisong Li
Group all of the declarations of functions that belong to the ACPI processor idle driver together in one place in processor.h. While at it, drop the unnecessary extern modifier from the declaraions of two functions. Signed-off-by: Huisong Li <lihuisong@huawei.com> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251223100914.2407069-6-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09ACPI: processor: idle: Redefine two functions as voidRafael J. Wysocki
Notice that acpi_processor_power_init() and acpi_processor_power_exit() don't need to return any values because their callers don't check them anyway, so redefine those functions as void. While at it, rearrange the code in acpi_processor_power_init() to reduce the indentation level, get rid of a redundant local variable in that function, and rephrase a code comment in it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251223100914.2407069-5-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09ACPI: processor: Update cpuidle driver check in __acpi_processor_start()Rafael J. Wysocki
Commit 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") moved the ACPI idle driver registration to acpi_processor_driver_init() and acpi_processor_power_init() does not register an idle driver any more. Accordingly, the cpuidle driver check in __acpi_processor_start() needs to be updated to avoid calling acpi_processor_power_init() without a cpuidle driver, in which case the registration of the cpuidle device in that function would lead to a NULL pointer dereference in __cpuidle_register_device(). Fixes: 7a8c994cbb2d ("ACPI: processor: idle: Optimize ACPI idle driver registration") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251223100914.2407069-4-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09ACPI: processor: Remove unused empty stubs of some functionsHuisong Li
Empty stubs are defined in processor.h for some functions provided by the ACPI processor idle driver, but those functions are only used in the main ACPI processor driver which requires the ACPI processor idle driver to be present (selecting CONFIG_ACPI_PROCESSOR causes CONFIG_ACPI_PROCESSOR_IDLE to be selected too automatically). This means that the empty stubs in question are not really necessary and if both CONFIG_ACPI_PROCESSOR and CONFIG_ACPI_PROCESSOR_IDLE are unset, the compiler complains that they are defined, but not used. Drop them to get rid of the compiler warning. Signed-off-by: Huisong Li <lihuisong@huawei.com> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20251223100914.2407069-3-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09ACPI: processor: idle: Optimize ACPI idle driver registrationHuisong Li
Currently, the ACPI idle driver is registered from within a CPU hotplug callback. Although this didn't cause any functional issues, this is questionable and confusing. And it is better to register the cpuidle driver when all of the CPUs have been brought up. So add a new function to initialize acpi_idle_driver based on the power management information of an available CPU and register cpuidle driver in acpi_processor_driver_init(). This commit has four changes under the commit 7a8c994cbb2d (ACPI: processor: idle: Optimize ACPI idle driver registration): 1) move acpi_processor_register_idle_driver() ahead of the driver_register(). 2) add acpi_processor_cstate_first_run_checks() before calling acpi_processor_get_power_info(). 3) squash the commit 9d68320b2bca (ACPI: processor: idle: Fix function defined but not used warning) into this change. 4) use for_each_possible_cpu(cpu) to scan all possible cpus. Signed-off-by: Huisong Li <lihuisong@huawei.com> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> [ rjw: New comment edits, changelog tweak ] Link: https://patch.msgid.link/20251223100914.2407069-2-lihuisong@huawei.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09audit: move the compat_xxx_class[] extern declarations to audit_arch.hBen Dooks
The comapt_xxx_class symbols aren't declared in anything that lib/comapt_audit.c is including (arm64 build) which is causing the following sparse warnings: lib/compat_audit.c:7:10: warning: symbol 'compat_dir_class' was not declared. Should it be static? lib/compat_audit.c:12:10: warning: symbol 'compat_read_class' was not declared. Should it be static? lib/compat_audit.c:17:10: warning: symbol 'compat_write_class' was not declared. Should it be static? lib/compat_audit.c:22:10: warning: symbol 'compat_chattr_class' was not declared. Should it be static? lib/compat_audit.c:27:10: warning: symbol 'compat_signal_class' was not declared. Should it be static? Trying to fix this by chaning compat_audit.c to inclde <linux/audit.h> does not work on arm64 due to compile errors with the extra includes that changing this header makes. The simpler thing would be just to move the definitons of these symbols out of <linux/audit.h> into <linux/audit_arch.h> which is included. Fixes: 4b58841149dca ("audit: Add generic compat syscall support") Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> [PM: rewrite subject line, fixed line length in description] Signed-off-by: Paul Moore <paul@paul-moore.com>
2026-01-09Bluetooth: hci_sync: enable PA Sync Lost eventYang Li
Enable the PA Sync Lost event mask to ensure PA sync loss is properly reported and handled. Fixes: 485e0626e587 ("Bluetooth: hci_event: Fix not handling PA Sync Lost event") Signed-off-by: Yang Li <yang.li@amlogic.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-01-09MAINTAINERS: Add myself as cpuidle reviewerChristian Loehle
I've been reviewing cpuidle changes, for governors in particular, for the last couple of years and will continue to do so. Signed-off-by: Christian Loehle <christian.loehle@arm.com> Link: https://patch.msgid.link/71f63cb7-2d9b-49a3-9b04-a47e2edef5e0@arm.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09cpuidle: menu: Remove incorrect unlikely() annotationBreno Leitao
The unlikely() annotation on the early-return condition in menu_select() is incorrect on systems with only one idle state (e.g., ARM64 servers with a single ACPI LPI state). Branch profiling shows 100% misprediction on such systems since drv->state_count <= 1 is always true. On platforms where only state0 is available, this path is the common case, not an unlikely edge case. Remove the misleading annotation to let the branch predictor learn the actual behavior. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260105-annotated_idle-v1-1-10ddf0771b58@debian.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09PM: EM: Add dump to get-perf-domains in the EM YNL specChangwoo Min
Add dump to get-perf-domains, so that a user can fetch either information about a specific performance domain with do or information about all performance domains with dump. Share the reply format of do and dump using perf-domain-attrs, so remove perf-domains. The YNL spec, autogenerated files, and the do implementation are updated, and the dump implementation is added. Suggested-by: Donald Hunter <donald.hunter@gmail.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: Changwoo Min <changwoo@igalia.com> Link: https://patch.msgid.link/20260108053212.642478-5-changwoo@igalia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09PM: EM: Change cpus' type from string to u64 array in the EM YNL specChangwoo Min
Previously, the cpus attribute was a string format which was a "%*pb" stringification of a bitmap. That is not very consumable for a UAPI, so let’s change it to an u64 array of CPU ids. Suggested-by: Donald Hunter <donald.hunter@gmail.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: Changwoo Min <changwoo@igalia.com> Link: https://patch.msgid.link/20260108053212.642478-4-changwoo@igalia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09PM: EM: Rename em.yaml to dev-energymodel.yamlChangwoo Min
The EM YNL specification used many acronyms, including ‘em’, ‘pd’, ‘ps’, etc. While the acronyms are short and convenient, they could be confusing. So, let’s spell them out to be more specific. The following changes were made in the spec. Note that the protocol name cannot exceed GENL_NAMSIZ (16). em -> dev-energymodel pds -> perf-domains pd -> perf-domain pd-id -> perf-domain-id pd-table -> perf-table ps -> perf-state get-pds -> get-perf-domains get-pd-table -> get-perf-table pd-created -> perf-domain-created pd-updated -> perf-domain-updated pd-deleted -> perf-domain-deleted In addition. doc strings were added to the spec. based on the comments in energy_model.h. Two flag attributes (perf-state-flags and perf-domain-flags) were added for easily interpreting the bit flags. Finally, the autogenerated files and em_netlink.c were updated accordingly to reflect the name changes. Suggested-by: Donald Hunter <donald.hunter@gmail.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: Changwoo Min <changwoo@igalia.com> Link: https://patch.msgid.link/20260108053212.642478-3-changwoo@igalia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09PM: EM: Fix yamllint warnings in the EM YNL specChangwoo Min
The energy model YNL spec has the following two warnings when checking with yamlint: 3:1 warning missing document start "---" (document-start) 107:13 error wrong indentation: expected 10 but found 12 (indentation) So let’s fix whose lint warnings. Fixes: bd26631ccdfd ("PM: EM: Add em.yaml and autogen files") Suggested-by: Donald Hunter <donald.hunter@gmail.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Signed-off-by: Changwoo Min <changwoo@igalia.com> Link: https://patch.msgid.link/20260108053212.642478-2-changwoo@igalia.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-01-09PCI: Add ASPEED vendor ID to pci_ids.hNirmoy Das
Add PCI_VENDOR_ID_ASPEED to the shared pci_ids.h header and remove the duplicate local definition from ehci-pci.c. This prepares for adding a PCI quirk for ASPEED devices. Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://patch.msgid.link/20251217154529.377586-1-nirmoyd@nvidia.com
2026-01-09clk: rockchip: Fix error pointer check after rockchip_clk_register_gate_link()Miaoqian Lin
Replace NULL check with IS_ERR_OR_NULL() check after calling rockchip_clk_register_gate_link() since this function returns error pointers (ERR_PTR). Fixes: c62fa612cfa6 ("clk: rockchip: implement linked gate clock support") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Link: https://patch.msgid.link/20250805030358.3665878-1-linmq006@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576Detlev Casanova
Add the vdpu383 Video Decoder variant to the RK3576 device tree. Also allow using the dedicated SRAM as a pool. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://patch.msgid.link/20251020212009.8852-3-detlev.casanova@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588Detlev Casanova
Add the vdpu381 Video Decoders to the rk3588-base devicetree. The RK3588 based SoCs all embed 2 vdpu381 decoders. This also adds the dedicated IOMMU controllers. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://patch.msgid.link/20251020212009.8852-2-detlev.casanova@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Drop unsupported propertiesRob Herring (Arm)
"pinctrl-names" is not valid without a pinctrl-N property. "max-freq" is not a defined property name. Maybe it was supposed to be "spi-max-frequency", but changing to that would be a change in behavior. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108230607.1348879-1-robh@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Fix gpio pinctrl node namesRob Herring (Arm)
The pinctrl node names "gpios" or with "-gpio" suffix collide with GPIO property names creating false warnings. Add a "-pins?" suffix to avoid the issue. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108230623.1349310-1-robh@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Fix pinctrl property typo on rk3326-odroid-go3Rob Herring (Arm)
"pinctrl" is not a defined property name. The correct name is "pinctrl-0". Signed-off-by: Rob Herring (Arm) <robh@kernel.org> [added missing pinctrl-names property] Link: https://patch.msgid.link/20260108230613.1349060-1-robh@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Drop "sitronix,st7789v" fallback compatible from ↵Rob Herring (Arm)
rk3568-wolfvision "sitronix,st7789v" is not a defined fallback for "jasonic,jt240mhqs-hwt-ek-e3", so drop it. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108230600.1348699-1-robh@kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: qcom: hamoa-iot-evk: Enable TPM (ST33) on SPI11Khalid Faisal Ansari
Enable ST33HTPM TPM over SPI11 on the Hamoa IoT EVK by adding the required SPI and TPM nodes. Signed-off-by: Khalid Faisal Ansari <khalid.ansari@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251112-arm64-dts-qcom-hamoa-iot-evk-enable-st33-tpm-on-spi11-v3-1-39b19eb55cc3@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09arm64: dts: rockchip: Add rk3588s-orangepi-cm5-base device treeLaurent Pinchart
The Orange Pi CM5 Base board is a carrier board for the Orange Pi CM5 compute module. It has 3 ethernet ports, 2 USB ports, one HDMI output and 4 CSI-2 inputs. The device tree is split in two files, a .dtsi for the compute module and a .dts for the carrier board. All the devices present on the carrier board are enabled and tested, with the exception of the IR receiver due to missing support for input capture in the PWM device's DT binding (and driver). This work is based on a combination of the Orange Pi 5 device tree from the upstream kernel and the Orange Pi CM5 device tree from the BSP kernel. All nodes and properties have been carefully checked to the best of my abilities against the schematics of the carrier board. The schematics of the compute module is not available publicly, so the configuration of the PMIC hasn't been double-checked. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20251027215637.20715-3-laurent.pinchart@ideasonboard.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09dt-bindings: arm: rockchip: Add Orange Pi CM5 BaseLaurent Pinchart
The Orange Pi CM5 Base board is a carrier board for the Orange Pi CM5 compute module. It has 3 ethernet ports, 2 USB ports, one HDMI output and 4 CSI-2 inputs. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251027215637.20715-2-laurent.pinchart@ideasonboard.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Enable second HDMI output on CM3588David Petry
Enable the second HDMI output port found on FriendlyElec CM3588 and CM3588 Plus Signed-off-by: David Petry <petry103@gmail.com> Link: https://patch.msgid.link/20251021160603.96934-1-petry103@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09arm64: dts: rockchip: Add HDMI to Gameforce AceChris Morgan
Add support for the HDMI port for the Gameforce Ace. The HDMI port has no HPD pin present (the manufacturer's devicetree states the pin is reused for an additional face button) so add the attribute of no-hpd to poll for connected devices. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://patch.msgid.link/20251119225526.70588-4-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-09drm/bridge: dw-hdmi-qp: Add support for missing HPDChris Morgan
Add support for the dw-hdmi-qp driver to handle devices with missing HPD pins. Since in this situation we are now polling for the EDID data via i2c change the error message to a rate limited debug message when we are unable to complete an i2c read, as a disconnected device would otherwise fill dmesg with i2c read errors. Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251119225526.70588-3-macroalpha82@gmail.com
2026-01-09dt-bindings: display: rockchip: Add no-hpd for dw-hdmi-qp controllerChris Morgan
Add an attribute of "no-hpd" for the Rockchip dw-hdmi-qp controller. This is used to describe implementations where the HPD pin is not connected or used for other purposes, such as in the RK3588S based Gameforce Ace which repurposed the GPIO for an additional face button. The "no-hpd" option was chosen to be consistent with other devices which already define this parameter for broken or missing hpd functionality. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251119225526.70588-2-macroalpha82@gmail.com
2026-01-09drm/rockchip: replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251031104846.119503-3-marco.crivellari@suse.com
2026-01-09drm/rockchip: replace use of system_unbound_wq with system_dfl_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. The old system_unbound_wq will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20251031104846.119503-2-marco.crivellari@suse.com
2026-01-09arm64: dts: qcom: talos: Add PMU supportYuanjie Yang
Add the PMU node for talos platforms. Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260108092542.1371-3-yuanjie.yang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09arm64: dts: qcom: talos: switch to interrupt-cells 4 to add PPI partitionsYuanjie Yang
The ARM PMUs shares the same per-cpu (PPI) interrupt, so we need to switch to interrupt-cells = <4> in the GIC node to allow adding an interrupt partition map phandle as the 4th cell value for GIC_PPI interrupts. Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260108092542.1371-2-yuanjie.yang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09bpftool: Make skeleton C++ compatible with explicit castsWanLi Niu
Fix C++ compilation errors in generated skeleton by adding explicit pointer casts and use char * subtraction for offset calculation error: invalid conversion from 'void*' to '<obj_name>*' [-fpermissive] | skel = skel_alloc(sizeof(*skel)); | ~~~~~~~~~~^~~~~~~~~~~~~~~ | | | void* error: arithmetic on pointers to void | skel->ctx.sz = (void *)&skel->links - (void *)skel; | ~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~ error: assigning to 'struct <obj_name>__<ident> *' from incompatible type 'void *' | skel-><ident> = skel_prep_map_data((void *)data, 4096, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | sizeof(data) - 1); | ~~~~~~~~~~~~~~~~~ error: assigning to 'struct <obj_name>__<ident> *' from incompatible type 'void *' | skel-><ident> = skel_finalize_map_data(&skel->maps.<ident>.initial_value, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 4096, PROT_READ | PROT_WRITE, skel->maps.<ident>.map_fd); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Minimum reproducer: $ cat test.bpf.c int val; // placed in .bss section #include "vmlinux.h" #include <bpf/bpf_helpers.h> SEC("raw_tracepoint/sched_wakeup_new") int handle(void *ctx) { return 0; } $ cat test.cpp #include <cerrno> extern "C" { #include "test.bpf.skel.h" } $ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h $ clang -g -O2 -target bpf -c test.bpf.c -o test.bpf.o $ bpftool gen skeleton test.bpf.o -L > test.bpf.skel.h $ g++ -c test.cpp -I. Co-developed-by: Menglong Dong <dongml2@chinatelecom.cn> Signed-off-by: WanLi Niu <niuwl1@chinatelecom.cn> Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20260106023123.2928-1-kiraskyler@163.com
2026-01-09arm64: dts: qcom: ipq9574: Complete USB DWC3 wrapper interruptsKrzysztof Kozlowski
Complete interrupts for DWC3 node to match what is required by Devicetree bindings, as reported by dtbs_check: ipq9574-rdp433.dtb: usb@8af8800 (qcom,ipq9574-dwc3): interrupt-names: ['pwr_event'] is too short The actual interrupt numbers are taken from reference manual of similar chip, but not IPQ9574, due to lack of access to it. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Tested-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260106185123.19929-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09arm64: dts: qcom: ipq5018: Correct USB DWC3 wrapper interruptsKrzysztof Kozlowski
Interrupts for DWC3 node were completely mixed up - SPI interrupt 62 is not listed in reference manual at all. It was also causing dtbs_check warnings: ipq5018-rdp432-c2.dtb: usb@8af8800 (qcom,ipq5018-dwc3): interrupt-names:0: 'pwr_event' was expected ipq5018-rdp432-c2.dtb: usb@8af8800 (qcom,ipq5018-dwc3): interrupt-names: ['hs_phy_irq'] is too short Warning itself was introduced by commit 53c6d854be4e ("dt-bindings: usb: dwc3: Clean up hs_phy_irq in binding"), but this was trying to bring sanity to the interrupts overall, although did a mistake for IPQ5018. IPQ5018 does not have QUSB2 PHY and its interrupts should rather match ones used in IPQ5332. Correct it by using interrupts matching the bindings and reference manual. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Tested-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20260106185123.19929-3-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09clk: qcom: alpha-pll: convert from divider_round_rate() to ↵Brian Masney
divider_determine_rate() The divider_round_rate() function is now deprecated, so let's migrate to divider_determine_rate() instead so that this deprecated API can be removed. Note that when the main function itself was migrated to use determine_rate, this was mistakenly converted to: req->rate = divider_round_rate(...) This is invalid in the case when an error occurs since it can set the rate to a negative value. Fixes: 0e56e3369b60 ("clk: qcom: alpha-pll: convert from round_rate() to determine_rate()") Signed-off-by: Brian Masney <bmasney@redhat.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-14-535a3ed73bf3@redhat.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09arm64: dts: qcom: monaco: Add CTCU and ETR nodesJie Gan
Add CTCU and ETR nodes in DT to enable expected functionalities. Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251103-enable-ctcu-for-monaco-v4-2-92ff83201584@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09arm64: dts: qcom: Add PCIe3 and PCIe5 regulators for HAMAO-IOT-EVK boardZiyue Zhang
HAMAO IoT EVK uses PCIe5 to connect an SDX65 module for WWAN functionality and PCIe3 to connect a SATA controller. These interfaces require multiple voltage rails: PCIe5 needs 3.3V supplied by vreg_wwan, while PCIe3 requires 12V, 3.3V, and 3.3V AUX rails, controlled via PMIC GPIOs. Add the required fixed regulators with related pin configuration, and connect them to the PCIe3 and PCIe5 ports to ensure proper power for the SDX65 module and SATA controller. Move reset and wake GPIO properties from RC nodes to port nodes. Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260109104504.3147745-4-ziyue.zhang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09arm64: dts: qcom: Add PCIe3 and PCIe5 support for HAMOA-IOT-SOM platformZiyue Zhang
HAMOA IoT SOM requires PCIe3 and PCIe5 connectivity for SATA controller and SDX65. Add the required sideband signals (PERST#, WAKE#, CLKREQ#), pinctrl states and power supply properties in the device tree, which PCIe3 and PCIe5 require. Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260109104504.3147745-3-ziyue.zhang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes ↵Ziyue Zhang
and add port Nodes for all PCIe ports Since describing the PCIe PHY directly under the RC node is now deprecated, move the references to the respective PCIe port nodes, creating them where necessary.Also add port nodes for PCIe5 and PCIe6a with proper PHY references. And also move the PCIe PERST and wake GPIOs from the controller nodes to the corresponding PCIe port nodes on Hamoa-based platforms: - x1e001de-devkit - x1e78100-lenovo-thinkpad-t14s - x1e80100-asus-vivobook-s15 - x1e80100-asus-zenbook-a14 - x1e80100-dell-xps13-9345 - x1e80100-lenovo-yoga-slim7x - x1e80100-microsoft-romulus - x1e80100-qcp Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260109104504.3147745-2-ziyue.zhang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-09security: Add KUnit tests for kuid_root_in_ns and vfsuid_root_in_currentnsRyan Foster
Add comprehensive KUnit tests for the namespace-related capability functions that Serge Hallyn refactored in commit 9891d2f79a9f ("Clarify the rootid_owns_currentns"). The tests verify: - Basic functionality: UID 0 in init namespace, invalid vfsuid, non-zero UIDs - Actual namespace traversal: Creating user namespaces with different UID mappings where uid 0 maps to different kuids (e.g., 1000, 2000, 3000) - Hierarchy traversal: Testing multiple nested namespaces to verify correct namespace hierarchy traversal This addresses the feedback to "test the actual functionality" by creating real user namespaces with different values for the namespace's uid 0, rather than just basic input validation. The test file is included at the end of commoncap.c when CONFIG_SECURITY_COMMONCAP_KUNIT_TEST is enabled, following the standard kernel pattern (e.g., scsi_lib.c, ext4/mballoc.c). This allows tests to access static functions in the same compilation unit without modifying production code based on test configuration. The tests require CONFIG_USER_NS to be enabled since they rely on user namespace mapping functionality. The Kconfig dependency ensures the tests only build when this requirement is met. All 7 tests pass: - test_vfsuid_root_in_currentns_init_ns - test_vfsuid_root_in_currentns_invalid - test_vfsuid_root_in_currentns_nonzero - test_kuid_root_in_ns_init_ns_uid0 - test_kuid_root_in_ns_init_ns_nonzero - test_kuid_root_in_ns_with_mapping - test_kuid_root_in_ns_with_different_mappings Updated MAINTAINER capabilities to include commoncap test Signed-off-by: Ryan Foster <foster.ryan.r@gmail.com> Signed-off-by: Serge Hallyn <sergeh@kernel.org>
2026-01-09drm/dp: Add byte-by-byte fallback for broken USB-C adaptersChia-Lin Kao (AceLan)
Some USB-C hubs and adapters have buggy firmware where multi-byte AUX reads consistently timeout, while single-byte reads from the same address work correctly. Known affected devices that exhibit this issue: - Lenovo USB-C to VGA adapter (VIA VL817 chipset) idVendor=17ef, idProduct=7217 - Dell DA310 USB-C mobile adapter hub idVendor=413c, idProduct=c010 Analysis of the failure pattern shows: - Single-byte probes to 0xf0000 (LTTPR) succeed - Single-byte probes to 0x00102 (TRAINING_AUX_RD_INTERVAL) succeed - Multi-byte reads from 0x00000 (DPCD capabilities) timeout with -ETIMEDOUT - Retrying does not help - the failure is consistent across all attempts The issue appears to be a firmware bug in the AUX transaction handling that specifically affects multi-byte reads. Add a fallback mechanism in drm_dp_dpcd_read_data() that attempts byte-by-byte reading when the normal multi-byte read fails. This workaround only activates for adapters that fail the standard read path, ensuring no impact on correctly functioning hardware. Tested with: - Lenovo USB-C to VGA adapter (VIA VL817) - now works with fallback - Dell DA310 USB-C hub - now works with fallback - Dell/Analogix Slimport adapter - continues to work with normal path Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20251204024647.1462866-1-acelan.kao@canonical.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-01-09idpf: Fix kernel-doc descriptions to avoid warningsAndy Shevchenko
In many functions the Return section is missing. Fix kernel-doc descriptions to address that and other warnings. Before the change: $ scripts/kernel-doc -none -Wreturn drivers/net/ethernet/intel/idpf/idpf_txrx.c 2>&1 | wc -l 85 Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-01-09idpf: update idpf_up_complete() return type to voidSreedevi Joshi
idpf_up_complete() function always returns 0 and no callers use this return value. Although idpf_vport_open() checks the return value, it only handles error cases which never occur. Change the return type to void to simplify the code. Signed-off-by: Sreedevi Joshi <sreedevi.joshi@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-01-09ice: use netif_get_num_default_rss_queues()Michal Swiatkowski
On some high-core systems (like AMD EPYC Bergamo, Intel Clearwater Forest) loading ice driver with default values can lead to queue/irq exhaustion. It will result in no additional resources for SR-IOV. In most cases there is no performance reason for more than half num_cpus(). Limit the default value to it using generic netif_get_num_default_rss_queues(). Still, using ethtool the number of queues can be changed up to num_online_cpus(). It can be done by calling: $ethtool -L ethX combined $(nproc) This change affects only the default queue amount. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-01-09ixgbe: Add 10G-BX supportBirger Koblitz
Add support for 10G-BX modules, i.e. 10GBit Ethernet over a single strand Single-Mode fiber. The initialization of a 10G-BX SFP+ is the same as for a 10G SX/LX module, and is identified according to SFF-8472 table 5-3, footnote 3 by the 10G Ethernet Compliance Codes field being empty, the Nominal Bit Rate being compatible with 12.5GBit, and the module being a fiber module with a Single Mode fiber link length. This was tested using a Lightron WSPXG-HS3LC-IEA 1270/1330nm 10km transceiver: $ sudo ethtool -m enp1s0f1 Identifier : 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC) Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Encoding : 0x01 (8B/10B) BR Nominal : 10300MBd Rate identifier : 0x00 (unspecified) Length (SMF) : 10km Length (OM2) : 0m Length (OM1) : 0m Length (Copper or Active cable) : 0m Length (OM3) : 0m Laser wavelength : 1330nm Vendor name : Lightron Inc. Vendor OUI : 00:13:c5 Vendor PN : WSPXG-HS3LC-IEA Vendor rev : 0000 Option values : 0x00 0x1a Option : TX_DISABLE implemented BR margin max : 0% BR margin min : 0% Vendor SN : S142228617 Date code : 140611 Optical diagnostics support : Yes Signed-off-by: Birger Koblitz <mail@birger-koblitz.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-01-09ice: unify PHY FW loading status handler for E800 devicesGrzegorz Nitka
Unify handling of PHY firmware load delays across all E800 family devices. There is an existing mechanism to poll GL_MNG_FWSM_FW_LOADING_M bit of GL_MNG_FWSM register in order to verify whether PHY FW loading completed or not. Previously, this logic was limited to E827 variants only. Also, inform a user of possible delay in initialization process, by dumping informational message in dmesg log ("Link initialization is blocked by PHY FW initialization. Link initialization will continue after PHY FW initialization completes."). Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-01-09Merge tag 'for-6.19-rc4-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - fix potential NULL pointer dereference when replaying tree log after an error - release path before initializing extent tree to avoid potential deadlock when allocating new inode - on filesystems with block size > page size - fix potential read out of bounds during encoded read of an inline extent - only enforce free space tree if v1 cache is required - print correct tree id in error message * tag 'for-6.19-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: show correct warning if can't read data reloc tree btrfs: fix NULL pointer dereference in do_abort_log_replay() btrfs: force free space tree for bs > ps cases btrfs: only enforce free space tree if v1 cache is required for bs < ps cases btrfs: release path before initializing extent tree in btrfs_read_locked_inode() btrfs: avoid access-beyond-folio for bs > ps encoded writes
2026-01-09Merge branch 'tools-ynl-clean-up-pylint-issues'Jakub Kicinski
Donald Hunter says: ==================== tools: ynl: clean up pylint issues pylint tools/net/ynl/pyynl reports >850 issues, with a rating of 8.59/10. It's hard to spot new issues or genuine code smells in all that noise. Fix the easily fixable issues and suppress the noisy warnings. pylint tools/net/ynl/pyynl ************* Module pyynl.ethtool tools/net/ynl/pyynl/ethtool.py:159:5: W0511: TODO: --show-tunnels tunnel-info-get (fixme) tools/net/ynl/pyynl/ethtool.py:160:5: W0511: TODO: --show-module module-get (fixme) tools/net/ynl/pyynl/ethtool.py:161:5: W0511: TODO: --get-plca-cfg plca-get (fixme) tools/net/ynl/pyynl/ethtool.py:162:5: W0511: TODO: --get-plca-status plca-get-status (fixme) tools/net/ynl/pyynl/ethtool.py:163:5: W0511: TODO: --show-mm mm-get (fixme) tools/net/ynl/pyynl/ethtool.py:164:5: W0511: TODO: --show-fec fec-get (fixme) tools/net/ynl/pyynl/ethtool.py:165:5: W0511: TODO: --dump-module-eerpom module-eeprom-get (fixme) tools/net/ynl/pyynl/ethtool.py:166:5: W0511: TODO: pse-get (fixme) tools/net/ynl/pyynl/ethtool.py:167:5: W0511: TODO: rss-get (fixme) tools/net/ynl/pyynl/ethtool.py:179:9: W0511: TODO: parse the bitmask (fixme) tools/net/ynl/pyynl/ethtool.py:196:9: W0511: TODO: parse the bitmask (fixme) tools/net/ynl/pyynl/ethtool.py:321:9: W0511: TODO: pass id? (fixme) tools/net/ynl/pyynl/ethtool.py:330:17: W0511: TODO: support passing the bitmask (fixme) tools/net/ynl/pyynl/ethtool.py:459:5: W0511: TODO: wol-get (fixme) ------------------------------------------------------------------ Your code has been rated at 9.97/10 (previous run: 8.59/10, +1.38) ==================== Link: https://patch.msgid.link/20260108161339.29166-1-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>