summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-11ipv4: icmp: Pass IPv4 control block structure as an argument to __icmp_send()Ido Schimmel
__icmp_send() is used to generate ICMP error messages in response to various situations such as MTU errors (i.e., "Fragmentation Required") and too many hops (i.e., "Time Exceeded"). The skb that generated the error does not necessarily come from the IPv4 layer and does not always have a valid IPv4 control block in skb->cb. Therefore, commit 9ef6b42ad6fd ("net: Add __icmp_send helper.") changed the function to take the IP options structure as argument instead of deriving it from the skb's control block. Some callers of this function such as icmp_send() pass the IP options structure from the skb's control block as in these call paths the control block is known to be valid, but other callers simply pass a zeroed structure. A subsequent patch will need __icmp_send() to access more information from the IPv4 control block (specifically, the ifindex of the input interface). As a preparation for this change, change the function to take the IPv4 control block structure as an argument instead of the IP options structure. This makes the function similar to its IPv6 counterpart that already takes the IPv6 control block structure as an argument. No functional changes intended. Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250908073238.119240-3-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11ipv4: cipso: Simplify IP options handling in cipso_v4_error()Ido Schimmel
When __ip_options_compile() is called with an skb, the IP options are parsed from the skb data into the provided IP option argument. This is in contrast to the case where the skb argument is NULL and the options are parsed from opt->__data. Given that cipso_v4_error() always passes an skb to __ip_options_compile(), there is no need to allocate an extra 40 bytes (maximum IP options size). Therefore, simplify the function by removing these extra bytes and make the function similar to ipv4_send_dest_unreach() which also calls both __ip_options_compile() and __icmp_send(). This is a preparation for changing the arguments being passed to __icmp_send(). No functional changes intended. Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: David Ahern <dsahern@kernel.org> Acked-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250908073238.119240-2-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11x86/mce: Define BSP-only initYazen Ghannam
Currently, MCA initialization is executed identically on each CPU as they are brought online. However, a number of MCA initialization tasks only need to be done once. Define a function to collect all 'global' init tasks and call this from the BSP only. Start with CPU features. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Tested-by: Tony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/20250908-wip-mca-updates-v6-0-eef5d6c74b9c@amd.com
2025-09-11x86/mce: Set CR4.MCE last during initYazen Ghannam
Set the CR4.MCE bit as the last step during init. This brings the MCA init order closer to what is described in the x86 docs. x86 docs: AMD Intel MCG_CTL MCA_CONFIG MCG_EXT_CTL MCi_CTL MCi_CTL MCG_CTL CR4.MCE CR4.MCE Current Linux: AMD Intel CR4.MCE CR4.MCE MCG_CTL MCG_CTL MCA_CONFIG MCG_EXT_CTL MCi_CTL MCi_CTL Updated Linux: AMD Intel MCG_CTL MCG_CTL MCA_CONFIG MCG_EXT_CTL MCi_CTL MCi_CTL CR4.MCE CR4.MCE The new init flow will match Intel's docs, but there will still be a mismatch for AMD regarding MCG_CTL. However, there is no known issue with this ordering, so leave it for now. Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com> Link: https://lore.kernel.org/20250908-wip-mca-updates-v6-0-eef5d6c74b9c@amd.com
2025-09-11Merge branch 'net-xdp-handle-frags-with-unreadable-memory'Paolo Abeni
Jakub Kicinski says: ==================== net: xdp: handle frags with unreadable memory Make XDP helpers compatible with unreadable memory. This is very similar to how we handle pfmemalloc frags today. Record the info in xdp_buf flags as frags get added and then update the skb once allocated. This series adds the unreadable memory metadata tracking to drivers using xdp_build_skb_from*() with no changes on the driver side - hence the only driver changes here are refactoring. Obviously, unreadable memory is incompatible with XDP today, but thanks to xdp_build_skb_from_buf() increasing number of drivers have a unified datapath, whether XDP is enabled or not. RFC: https://lore.kernel.org/20250812161528.835855-1-kuba@kernel.org ==================== Link: https://patch.msgid.link/20250905221539.2930285-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11net: xdp: handle frags with unreadable memoryJakub Kicinski
We don't expect frags with unreadable memory to be presented to XDP programs today, but the XDP helpers are designed to be usable whether XDP is enabled or not. Support handling frags with unreadable memory. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Link: https://patch.msgid.link/20250905221539.2930285-3-kuba@kernel.org Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11net: xdp: pass full flags to xdp_update_skb_shared_info()Jakub Kicinski
xdp_update_skb_shared_info() needs to update skb state which was maintained in xdp_buff / frame. Pass full flags into it, instead of breaking it out bit by bit. We will need to add a bit for unreadable frags (even tho XDP doesn't support those the driver paths may be common), at which point almost all call sites would become: xdp_update_skb_shared_info(skb, num_frags, sinfo->xdp_frags_size, MY_PAGE_SIZE * num_frags, xdp_buff_is_frag_pfmemalloc(xdp), xdp_buff_is_frag_unreadable(xdp)); Keep a helper for accessing the flags, in case we need to transform them somehow in the future (e.g. to cover up xdp_buff vs xdp_frame differences). While we are touching call callers - rename the helper to xdp_update_skb_frags_info(), previous name may have implied that it's shinfo that's updated. We are updating flags in struct sk_buff based on frags that got attched. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Link: https://patch.msgid.link/20250905221539.2930285-2-kuba@kernel.org Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11Merge branch 'hsr-fix-lock-warnings'Paolo Abeni
Hangbin Liu says: ==================== hsr: fix lock warnings hsr_for_each_port is called in many places without holding the RCU read lock, this may trigger warnings on debug kernels like: [ 40.457015] [ T201] WARNING: suspicious RCU usage [ 40.457020] [ T201] 6.17.0-rc2-virtme #1 Not tainted [ 40.457025] [ T201] ----------------------------- [ 40.457029] [ T201] net/hsr/hsr_main.c:137 RCU-list traversed in non-reader section!! [ 40.457036] [ T201] other info that might help us debug this: [ 40.457040] [ T201] rcu_scheduler_active = 2, debug_locks = 1 [ 40.457045] [ T201] 2 locks held by ip/201: [ 40.457050] [ T201] #0: ffffffff93040a40 (&ops->srcu){.+.+}-{0:0}, at: rtnl_link_ops_get+0xf2/0x280 [ 40.457080] [ T201] #1: ffffffff92e7f968 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_newlink+0x5e1/0xb20 [ 40.457102] [ T201] stack backtrace: [ 40.457108] [ T201] CPU: 2 UID: 0 PID: 201 Comm: ip Not tainted 6.17.0-rc2-virtme #1 PREEMPT(full) [ 40.457114] [ T201] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 40.457117] [ T201] Call Trace: [ 40.457120] [ T201] <TASK> [ 40.457126] [ T201] dump_stack_lvl+0x6f/0xb0 [ 40.457136] [ T201] lockdep_rcu_suspicious.cold+0x4f/0xb1 [ 40.457148] [ T201] hsr_port_get_hsr+0xfe/0x140 [ 40.457158] [ T201] hsr_add_port+0x192/0x940 [ 40.457167] [ T201] ? __pfx_hsr_add_port+0x10/0x10 [ 40.457176] [ T201] ? lockdep_init_map_type+0x5c/0x270 [ 40.457189] [ T201] hsr_dev_finalize+0x4bc/0xbf0 [ 40.457204] [ T201] hsr_newlink+0x3c3/0x8f0 [ 40.457212] [ T201] ? __pfx_hsr_newlink+0x10/0x10 [ 40.457222] [ T201] ? rtnl_create_link+0x173/0xe40 [ 40.457233] [ T201] rtnl_newlink_create+0x2cf/0x750 [ 40.457243] [ T201] ? __pfx_rtnl_newlink_create+0x10/0x10 [ 40.457247] [ T201] ? __dev_get_by_name+0x12/0x50 [ 40.457252] [ T201] ? rtnl_dev_get+0xac/0x140 [ 40.457259] [ T201] ? __pfx_rtnl_dev_get+0x10/0x10 [ 40.457285] [ T201] __rtnl_newlink+0x22c/0xa50 [ 40.457305] [ T201] rtnl_newlink+0x637/0xb20 Adding rcu_read_lock() for all hsr_for_each_port() looks confusing. Introduce a new helper, hsr_for_each_port_rtnl(), that assumes the RTNL lock is held. This allows callers in suitable contexts to iterate ports safely without explicit RCU locking. Other code paths that rely on RCU protection continue to use hsr_for_each_port() with rcu_read_lock(). ==================== Link: https://patch.msgid.link/20250905091533.377443-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11hsr: hold rcu and dev lock for hsr_get_port_ndevHangbin Liu
hsr_get_port_ndev calls hsr_for_each_port, which need to hold rcu lock. On the other hand, before return the port device, we need to hold the device reference to avoid UaF in the caller function. Suggested-by: Paolo Abeni <pabeni@redhat.com> Fixes: 9c10dd8eed74 ("net: hsr: Create and export hsr_get_port_ndev()") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250905091533.377443-4-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11hsr: use hsr_for_each_port_rtnl in hsr_port_get_hsrHangbin Liu
hsr_port_get_hsr() iterates over ports using hsr_for_each_port(), but many of its callers do not hold the required RCU lock. Switch to hsr_for_each_port_rtnl(), since most callers already hold the rtnl lock. After review, all callers are covered by either the rtnl lock or the RCU lock, except hsr_dev_xmit(). Fix this by adding an RCU read lock there. Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250905091533.377443-3-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11hsr: use rtnl lock when iterating over portsHangbin Liu
hsr_for_each_port is called in many places without holding the RCU read lock, this may trigger warnings on debug kernels. Most of the callers are actually hold rtnl lock. So add a new helper hsr_for_each_port_rtnl to allow callers in suitable contexts to iterate ports safely without explicit RCU locking. This patch only fixed the callers that is hold rtnl lock. Other caller issues will be fixed in later patches. Fixes: c5a759117210 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250905091533.377443-2-liuhangbin@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11drm/panthor: assign unique names to queuesChia-I Wu
Userspace relies on the ring field of gpu_scheduler tracepoints to identify a drm_gpu_scheduler. The value of the ring field is taken from sched->name. Because we typically have multiple schedulers running in parallel in each process, assign unique names to schedulers such that userspace can distinguish them. Signed-off-by: Chia-I Wu <olvaffe@gmail.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250902200624.428175-1-olvaffe@gmail.com
2025-09-11firmware: exynos-acpm: fix PMIC returned errnoTudor Ambarus
ACPM PMIC command handlers returned a u8 value when they should have returned either zero or negative error codes. Translate the APM PMIC errno to linux errno. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-input/aElHlTApXj-W_o1r@stanley.mountain/ Fixes: a88927b534ba ("firmware: add Exynos ACPM protocol driver") Cc: stable@vger.kernel.org Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-09-11optee: smc abi: dynamic protected memory allocationJens Wiklander
Add support in the OP-TEE backend driver for dynamic protected memory allocation using the SMC ABI. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11optee: FF-A: dynamic protected memory allocationJens Wiklander
Add support in the OP-TEE backend driver dynamic protected memory allocation with FF-A. The protected memory pools for dynamically allocated protected memory are instantiated when requested by user-space. This instantiation can fail if OP-TEE doesn't support the requested use-case of protected memory. Restricted memory pools based on a static carveout or dynamic allocation can coexist for different use-cases. We use only dynamic allocation with FF-A. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11optee: support protected memory allocationJens Wiklander
Add support in the OP-TEE backend driver for protected memory allocation. The support is limited to only the SMC ABI and for secure video buffers. OP-TEE is probed for the range of protected physical memory and a memory pool allocator is initialized if OP-TEE have support for such memory. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11tee: add tee_shm_alloc_dma_mem()Jens Wiklander
Add tee_shm_alloc_dma_mem() to allocate DMA memory. The memory is represented by a tee_shm object using the new flag TEE_SHM_DMA_MEM to identify it as DMA memory. The allocated memory will later be lent to the TEE to be used as protected memory. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11tee: new ioctl to a register tee_shm from a dmabuf file descriptorEtienne Carriere
Add a userspace API to create a tee_shm object that refers to a dmabuf reference. Userspace registers the dmabuf file descriptor as in a tee_shm object. The registration is completed with a tee_shm returned file descriptor. Userspace is free to close the dmabuf file descriptor after it has been registered since all the resources are now held via the new tee_shm object. Closing the tee_shm file descriptor will eventually release all resources used by the tee_shm object when all references are released. The new IOCTL, TEE_IOC_SHM_REGISTER_FD, supports dmabuf references to physically contiguous memory buffers. Dmabuf references acquired from the TEE DMA-heap can be used as protected memory for Secure Video Path and such use cases. It depends on the TEE and the TEE driver if dmabuf references acquired by other means can be used. A new tee_shm flag is added to identify tee_shm objects built from a registered dmabuf, TEE_SHM_DMA_BUF. Signed-off-by: Etienne Carriere <etienne.carriere@foss.st.com> Signed-off-by: Olivier Masse <olivier.masse@nxp.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11tee: refactor params_from_user()Jens Wiklander
Break out the memref handling into a separate helper function. No change in behavior. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11tee: implement protected DMA-heapJens Wiklander
Implement DMA heap for protected DMA-buf allocation in the TEE subsystem. Protected memory refers to memory buffers behind a hardware enforced firewall. It is not accessible to the kernel during normal circumstances but rather only accessible to certain hardware IPs or CPUs executing in higher or differently privileged mode than the kernel itself. This interface allows to allocate and manage such protected memory buffers via interaction with a TEE implementation. The protected memory is allocated for a specific use-case, like Secure Video Playback, Trusted UI, or Secure Video Recording where certain hardware devices can access the memory. The DMA-heaps are enabled explicitly by the TEE backend driver. The TEE backend drivers needs to implement protected memory pool to manage the protected memory. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11dma-buf: dma-heap: export declared functionsJens Wiklander
Export the dma-buf heap functions to allow them to be used by the OP-TEE driver. The OP-TEE driver wants to register and manage specific secure DMA heaps with it. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: T.J. Mercier <tjmercier@google.com> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11optee: sync secure world ABI headersJens Wiklander
Update the header files describing the secure world ABI, both with and without FF-A. The ABI is extended to deal with protected memory, but as usual backward compatible. Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2025-09-11drm/i915/backlight: Honor VESA eDP backlight luminance control capabilityAaron Ma
The VESA AUX backlight fails to be enable luminance based backlight mainpulation becaused luminance_set is false by default. Fix it by using luminance support control capabitliy. Fixes: e13af5166a359 ("drm/i915/backlight: Use drm helper to initialize edp backlight") Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://lore.kernel.org/r/20250823121647.275834-1-aaron.ma@canonical.com
2025-09-11selftests: net: Add tests to verify team driver option set and get.Marc Harvey
There are currently no kernel tests that verify setting and getting options of the team driver. In the future, options may be added that implicitly change other options, which will make it useful to have tests like these that show nothing breaks. There will be a follow up patch to this that adds new "rx_enabled" and "tx_enabled" options, which will implicitly affect the "enabled" option value and vice versa. The tests use teamnl to first set options to specific values and then gets them to compare to the set values. Signed-off-by: Marc Harvey <marcharvey@google.com> Link: https://patch.msgid.link/20250905040441.2679296-1-marcharvey@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-11arm64: dts: rockchip: enable the Mali GPU on RK3328 boardsAlex Bee
Add a gpu node to the rock64 board to enable the Mali GPU and move the existing node from roc-pc to the shared roc dtsi to enable it also for the roc-cc board. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64 Link: https://lore.kernel.org/r/20250906120810.1833016-2-christianshewitt@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-09-11arm64: dts: rockchip: add GPU powerdomain, opps, and cooling to rk3328Alex Bee
Add GPU powerdomain, opp-table, and cooling map nodes for the Mali GPU on the RK3328 SoC. Opp-table frequencies are sourced from the Rockchip Linux v4.4 vendor kernel while voltages have been derived from practical use and support work: keeping voltage above 1075mV and disabling the 500MHz opp-point avoids instability and crashes. Signed-off-by: Alex Bee <knaerzche@gmail.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64 Link: https://lore.kernel.org/r/20250906120810.1833016-1-christianshewitt@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-09-11arm64: dts: rockchip: Fix network on rk3576 evb1 boardSebastian Reichel
The RK3576 EVB1 has a RTL8211F PHY for each GMAC interface with a dedicated reset line and the 25MHz clock provided by the SoC. The current description results in non-working Ethernet as the clocks are only enabled by the PHY driver, but probing the right PHY driver currently requires that the PHY ID register can be read for automatic identification. This fixes up the network description to get the network functionality working reliably and cleans up usage of deprecated DT properties while at it. Fixes: f135a1a07352 ("arm64: dts: rockchip: Add rk3576 evb1 board") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20250910-rk3576-evb-network-v1-1-68ed4df272a2@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-09-11arm64: dts: rockchip: add mipi csi-2 dphy nodes to rk3588Michael Riesch
The Rockchip RK3588 features two MIPI CSI-2 DPHYs. Add the device tree nodes for them. Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-7-a4f340a7f0cf@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-09-11dt-bindings: soc: rockchip: add rk3588 csidphy grf sysconMichael Riesch
Add CSIDPHY GRF syscon compatible for the Rockchip RK3588. Acked-by: "Rob Herring (Arm)" <robh@kernel.org> Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-1-a4f340a7f0cf@collabora.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-09-11platform/x86:intel/pmc: Enable SSRAM support for Panther LakeXi Pardee
Enable Panther Lake platforms to achieve PMC information from Intel PMC SSRAM Telemetry driver and substate requirements data from telemetry region. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20250910210629.11198-6-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86:intel/pmc: Show substate requirement for S0ix blockersXi Pardee
Add support to read and show S0ix blocker substate requirements. Starting from Panther Lake, substate requirement data is provided based on S0ix blockers instead of all low power mode requirements. For platforms that support this new feature, add support to display substate requirements based on S0ix blockers. Change the "substate_requirements" attribute of Intel PMC Core driver to show the substate requirements for each S0ix blocker and the corresponding S0ix blocker value. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20250910210629.11198-5-xi.pardee@linux.intel.com [ij: rename pmc_index -> pmc_idx] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86:intel/pmc: Improve function to show substate headerXi Pardee
Refactor pmc_core_substate_req_header_show() to accept a new argument. This is a preparation patch to introduce a new way to show Low Power Mode substate requirement data for platforms starting from Panther Lake. Increased the size for the name column as the Low Power Mode requirement register name is longer in newer platforms. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20250910210629.11198-4-xi.pardee@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86:intel/pmc: Move telemetry endpoint register handlingXi Pardee
Move telemetry endpoint handling to pmc_core_get_telem_info(). This is a preparation patch to introduce a new table to obtain Low Power Mode substate requirement data for platforms starting from Panther Lake. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20250910210629.11198-3-xi.pardee@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86:intel/pmc: Enable SSRAM support for Lunar LakeXi Pardee
Enable Lunar Lake platforms to achieve PMC information from Intel PMC SSRAM Telemetry driver and substate requirements data from telemetry region. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://patch.msgid.link/20250910210629.11198-2-xi.pardee@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Add debug logs for pending requests and custom BIOS inputsShyam Sundar S K
This patch adds debug logging capabilities to monitor early pending requests and their associated custom BIOS inputs during runtime. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-10-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Call enact function sooner to process early pending ↵Shyam Sundar S K
requests Call the amd_pmf_invoke_cmd_enact() function to manage early pending requests and their associated custom BIOS inputs. Add a return statement for cases of failure. The PMF driver will adjust power settings according to custom BIOS inputs after assessing the policy conditions. Also, add a new common routine amd_pmf_handle_early_preq() to handle early BIOS pending requests for both v1 and v2 variants. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-9-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Preserve custom BIOS inputs for evaluating the policiesShyam Sundar S K
The current code fails to send multiple BIOS input data to the PMF-TA for policy condition evaluation. Only the most recent BIOS input data is properly sent to the PMF-TA, while previous inputs are overwritten with the zeros. To address this issue, the BIOS input data should be stored and passed on to the PMF-TA. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-8-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Add custom BIOS input support for AMD_CPU_ID_PSShyam Sundar S K
The PMF ACPI Specification (APMF) has been revised to version 1.3 to allow for additional custom BIOS inputs, enabling OEMs to have more precise thermal management of the system. This update includes adding support to the driver using the new data structure received from the BIOS through the existing APMF interfaces. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-7-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Add helper to verify BIOS input notifications are ↵Shyam Sundar S K
enable/disable Implement a helper function to check if BIOS input notifications are enabled or disabled. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-6-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Update ta_pmf_action structure memberShyam Sundar S K
The latest PMF TA has been updated with the additional structure members for internal evaluation. Since this same structure is utilized in the driver, it also needs to be updated on the driver side. Otherwise, there will be a mismatch in the byte sizes when copying data from shared memory. Suggested-by: Yijun Shen <Yijun.Shen@dell.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-5-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Extend custom BIOS inputs for more policiesShyam Sundar S K
The existing amd_pmf driver is limited to supporting just two custom BIOS inputs. However, with the updates to the latest PMF TA, there's a requirement to broaden this capacity to handle 10 inputs, aligning with the TA firmware's capabilities. The necessary logic should be implemented to facilitate this expansion of functionality. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-4-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Fix the custom bios input handling mechanismShyam Sundar S K
Originally, the 'amd_pmf_get_custom_bios_inputs()' function was written under the assumption that the BIOS would only send a single pending request for the driver to process. However, following OEM enablement, it became clear that multiple pending requests for custom BIOS inputs might be sent at the same time, a scenario that the current code logic does not support when it comes to handling multiple custom BIOS inputs. To address this, the code logic needs to be improved to not only manage multiple simultaneous custom BIOS inputs but also to ensure it is scalable for future additional inputs. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-3-Shyam-sundar.S-k@amd.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11platform/x86/amd/pmf: Add support for adjusting PMF PPT and PPT APU thresholdsShyam Sundar S K
The most recent PMF Trusted Application includes enhanced features that allow for modifications to PMF thermal parameters such as PPT and PPT APU. This update introduces the necessary driver support to utilize these capabilities. Co-developed-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Signed-off-by: Patil Rajesh Reddy <Patil.Reddy@amd.com> Tested-by: Yijun Shen <Yijun.Shen@Dell.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> Link: https://patch.msgid.link/20250901110140.2519072-2-Shyam-sundar.S-k@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-11dt-bindings: arm: fsl: add TQMa91xx SOM seriesAlexander Stein
TQMa91xx series is using NXP i.MX91 CPU on an LGA or socketable type board. MBa91xxCA is a starterkit base board for TQMa91xx on an adapter board. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-09-11dt-bindings: fsl: fsl,imx7ulp-smc1: Allow clocks and clock-namesFrank Li
Allow clocks and clock-names to match existed dts file. 'hsrun_divcore' should be 'hsrun-divcore'. But use '_' to keep old dts back compatible. Fix below CHECK_DTBS warnings: arch/arm/boot/dts/nxp/imx/imx7ulp-com.dtb: clock-controller@40410000 (fsl,imx7ulp-smc1): '#clock-cells', 'clock-names', 'clocks' do not match any of the regexes: '^pinctrl-[0-9]+$' from schema $id: http://devicetree.org/schemas/arm/freescale/fsl,imx7ulp-pm.yaml# Signed-off-by: Frank Li <Frank.Li@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-09-11dt-bindings: arm: fsl: Add bindings for SolidRun i.MX8MP SoM and boardsJosua Mayer
Add bindings for SolidRun i.MX8M Plus System on Module based boards: - CuBox-M is a complete produc with enclosure including the SoM - HummingBoard Mate/Pro/Pulse/Ripple are evaluation boards with common design but different available interfaces. Signed-off-by: Josua Mayer <josua@solid-run.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-09-11wifi: mwifiex: fix endianness handling in mwifiex_send_rgpower_tableStefan Kerkmann
The length of the host command is a u16 stored in little endian byte order, which needs byte order conversion to work correctly on big endian systems. Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-wireless/aLqZI4FfOI4iJZtf@stanley.mountain Fixes: 7b6f16a25806 ("wifi: mwifiex: add rgpower table loading support") Signed-off-by: Stefan Kerkmann <s.kerkmann@pengutronix.de> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20250910-for-next-v1-1-3ee311706231@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-11wifi: nl80211: completely disable per-link stats for nowJohannes Berg
After commit 8cc71fc3b82b ("wifi: cfg80211: Fix "no buffer space available" error in nl80211_get_station() for MLO"), the per-link data is only included in station dumps, where the size limit is somewhat less of an issue. However, it's still an issue, depending on how many links a station has and how much per-link data there is. Thus, for now, disable per-link statistics entirely. A complete fix will need to take this into account, make it opt-in by userspace, and change the dump format to be able to split a single station's data across multiple netlink dump messages, which all together is too much development for a fix. Fixes: 82d7f841d9bd ("wifi: cfg80211: extend to embed link level statistics in NL message") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-09-11media: redrat3: use int type to store negative error codesQianfeng Rong
Change "ret" from u8 to int type in redrat3_enable_detector() to store negative error codes or zero returned by redrat3_send_cmd() and usb_submit_urb() - this better aligns with the coding standards and maintains code consistency. No effect on runtime. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-11media: rc: fix races with imon_disconnect()Larshin Sergey
Syzbot reports a KASAN issue as below: BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline] BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465 CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 __create_pipe include/linux/usb.h:1945 [inline] send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627 vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991 vfs_write+0x2d7/0xdd0 fs/read_write.c:576 ksys_write+0x127/0x250 fs/read_write.c:631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The iMON driver improperly releases the usb_device reference in imon_disconnect without coordinating with active users of the device. Specifically, the fields usbdev_intf0 and usbdev_intf1 are not protected by the users counter (ictx->users). During probe, imon_init_intf0 or imon_init_intf1 increments the usb_device reference count depending on the interface. However, during disconnect, usb_put_dev is called unconditionally, regardless of actual usage. As a result, if vfd_write or other operations are still in progress after disconnect, this can lead to a use-after-free of the usb_device pointer. Thread 1 vfd_write Thread 2 imon_disconnect ... if usb_put_dev(ictx->usbdev_intf0) else usb_put_dev(ictx->usbdev_intf1) ... while send_packet if pipe = usb_sndintpipe( ictx->usbdev_intf0) UAF else pipe = usb_sndctrlpipe( ictx->usbdev_intf0, 0) UAF Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by checking ictx->disconnected in all writer paths. Add early return with -ENODEV in send_packet(), vfd_write(), lcd_write() and display_open() if the device is no longer present. Set and read ictx->disconnected under ictx->lock to ensure memory synchronization. Acquire the lock in imon_disconnect() before setting the flag to synchronize with any ongoing operations. Ensure writers exit early and safely after disconnect before the USB core proceeds with cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Reported-by: syzbot+f1a69784f6efe748c3bf@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f1a69784f6efe748c3bf Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver") Cc: stable@vger.kernel.org Signed-off-by: Larshin Sergey <Sergey.Larshin@kaspersky.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
generated by cgit v1.3 (git 2.53.0) at 2026-11-14 17:34:10 +0000