summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-26platform/x86: x86-android-tablets: convert Wacom devices to GPIO referencesDmitry Torokhov
Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Wacom touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://patch.msgid.link/20250920200713.20193-3-hansg@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-26platform/x86: x86-android-tablets: convert Goodix devices to GPIO referencesDmitry Torokhov
Now that gpiolib supports software nodes to describe GPIOs, switch the driver away from using GPIO lookup tables for Goodix touchscreens to using PROPERTY_ENTRY_GPIO() to keep all touchscreen properties together. Since the tablets are using either Baytrail or Cherryview GPIO controllers x86_dev_info structure has been extended to carry gpiochip type information so that the code can instantiate correct set of software nodes representing the GPIO chip. Because this adds a new point of failure in x86_android_tablet_probe(), x86_android_tablet_remove() is rearranged to handle cases where battery swnode has not been registered yet, and registering of GPIO lookup tables is moved earlier as it can not fail. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Hans de Goede <hansg@kernel.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://patch.msgid.link/20250920200713.20193-2-hansg@kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-26platform/x86:intel/pmc: Replace dev_warn() with dev_dbg()Xi Pardee
Replace dev_warn() with dev_dbg() to reduce unnecessary warning messages. When the low power mode priority register contains invalid data, the Intel PMC Core driver can still utilize the default priority list. This scenario is more suited for debug information rather than warning. Signed-off-by: Xi Pardee <xi.pardee@linux.intel.com> Link: https://patch.msgid.link/20250916191339.1748512-1-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-26arm64: dts: qcom: x1e80100-t14s: add ECSebastian Reichel
Describe ThinkPad Embedded Controller in the T14s device tree, which adds LED and special key support. Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Sebastian Reichel <sre@kernel.org> Link: https://patch.msgid.link/20250918-thinkpad-t14s-ec-v5-3-ac0bc6382c5c@collabora.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-26platform: arm64: thinkpad-t14s-ec: new driverSebastian Reichel
Introduce EC driver for the ThinkPad T14s Gen6 Snapdragon, which is in theory compatible with ThinkPad ACPI. On Linux the system is booted with device tree, which is not supported by the ThinkPad ACPI driver (drivers/platform/x86/lenovo/thinkpad_acpi.c). Also most of the hardware compatibility is handled via ACPI tables, which are obviously not used when booting via device tree. Thus adding DT compatibility to the existing driver is not worth it as there is almost no code sharing. The driver currently exposes features, which are not available via other means: * Extra Keys * System LEDs * Keyboard Backlight Control The driver has been developed by reading the ACPI DSDT. There are some more features around thermal control, which are not yet supported by the driver. The speaker mute and mic mute LEDs need some additional changes in the ALSA UCM to be set automatically. Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Sebastian Reichel <sre@kernel.org> Link: https://patch.msgid.link/20250918-thinkpad-t14s-ec-v5-2-ac0bc6382c5c@collabora.com [ij: folded in patch from Chen Ni <nichen@iscas.ac.cn>] Link: https://patch.msgid.link/20250926091302.817919-1-nichen@iscas.ac.cn [ij: folded in patch from Lukas Bulwahn <lbulwahn@redhat.com>] Link: https://patch.msgid.link/20250926071859.138396-1-lukas.bulwahn@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-09-26slab: add opt-in caching layer of percpu sheavesVlastimil Babka
Specifying a non-zero value for a new struct kmem_cache_args field sheaf_capacity will setup a caching layer of percpu arrays called sheaves of given capacity for the created cache. Allocations from the cache will allocate via the percpu sheaves (main or spare) as long as they have no NUMA node preference. Frees will also put the object back into one of the sheaves. When both percpu sheaves are found empty during an allocation, an empty sheaf may be replaced with a full one from the per-node barn. If none are available and the allocation is allowed to block, an empty sheaf is refilled from slab(s) by an internal bulk alloc operation. When both percpu sheaves are full during freeing, the barn can replace a full one with an empty one, unless over a full sheaves limit. In that case a sheaf is flushed to slab(s) by an internal bulk free operation. Flushing sheaves and barns is also wired to the existing cpu flushing and cache shrinking operations. The sheaves do not distinguish NUMA locality of the cached objects. If an allocation is requested with kmem_cache_alloc_node() (or a mempolicy with strict_numa mode enabled) with a specific node (not NUMA_NO_NODE), the sheaves are bypassed. The bulk operations exposed to slab users also try to utilize the sheaves as long as the necessary (full or empty) sheaves are available on the cpu or in the barn. Once depleted, they will fallback to bulk alloc/free to slabs directly to avoid double copying. The sheaf_capacity value is exported in sysfs for observability. Sysfs CONFIG_SLUB_STATS counters alloc_cpu_sheaf and free_cpu_sheaf count objects allocated or freed using the sheaves (and thus not counting towards the other alloc/free path counters). Counters sheaf_refill and sheaf_flush count objects filled or flushed from or to slab pages, and can be used to assess how effective the caching is. The refill and flush operations will also count towards the usual alloc_fastpath/slowpath, free_fastpath/slowpath and other counters for the backing slabs. For barn operations, barn_get and barn_put count how many full sheaves were get from or put to the barn, the _fail variants count how many such requests could not be satisfied mainly because the barn was either empty or full. While the barn also holds empty sheaves to make some operations easier, these are not as critical to mandate own counters. Finally, there are sheaf_alloc/sheaf_free counters. Access to the percpu sheaves is protected by local_trylock() when potential callers include irq context, and local_lock() otherwise (such as when we already know the gfp flags allow blocking). The trylock failures should be rare and we can easily fallback. Each per-NUMA-node barn has a spin_lock. When slub_debug is enabled for a cache with sheaf_capacity also specified, the latter is ignored so that allocations and frees reach the slow path where debugging hooks are processed. Similarly, we ignore it with CONFIG_SLUB_TINY which prefers low memory usage to performance. [boot failure: https://lore.kernel.org/all/583eacf5-c971-451a-9f76-fed0e341b815@linux.ibm.com/ ] Reported-and-tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com> Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-09-26slab: simplify init_kmem_cache_nodes() error handlingVlastimil Babka
We don't need to call free_kmem_cache_nodes() immediately when failing to allocate a kmem_cache_node, because when we return 0, do_kmem_cache_create() calls __kmem_cache_release() which also performs free_kmem_cache_nodes(). Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-09-26gpio: mpfs: fix setting gpio direction to outputConor Dooley
mpfs_gpio_direction_output() actually sets the line to input mode. Use the correct register settings for output mode so that this function actually works as intended. This was a copy-paste mistake made when converting to regmap during the driver submission process. It went unnoticed because my test for output mode is toggling LEDs on an Icicle kit which functions with the incorrect code. The internal reporter has yet to test the patch, but on their system the incorrect setting may be the reason for failures to drive the GPIO lines on the BeagleV-fire board. CC: stable@vger.kernel.org Fixes: a987b78f3615e ("gpio: mpfs: add polarfire soc gpio support") Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250925-boogieman-carrot-82989ff75d10@spud Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-09-26locking/local_lock: Expose dep_map in local_trylock_t.Alexei Starovoitov
lockdep_is_held() macro assumes that "struct lockdep_map dep_map;" is a top level field of any lock that participates in LOCKDEP. Make it so for local_trylock_t. Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Reviewed-by: Harry Yoo <harry.yoo@oracle.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2025-09-26Merge branches 'edac-drivers' and 'edac-misc' into edac-updatesBorislav Petkov (AMD)
* edac-drivers: EDAC/versalnet: Return the correct error in mc_probe() EDAC/mc_sysfs: Increase legacy channel support to 16 EDAC/amd64: Add support for AMD family 1Ah-based newer models EDAC: Add a driver for the AMD Versal NET DDR controller dt-bindings: memory-controllers: Add support for Versal NET EDAC RAS: Export log_non_standard_event() to drivers cdx: Export Symbols for MCDI RPC and Initialization cdx: Split mcdi.h and reorganize headers EDAC/skx_common: Use topology_physical_package_id() instead of open coding EDAC/altera: Use dev_fwnode() EDAC/skx_common: Remove unused *NUM*_IMC macros EDAC/i10nm: Reallocate skx_dev list if preconfigured cnt != runtime cnt EDAC/skx_common: Remove redundant upper bound check for res->imc EDAC/skx_common: Make skx_dev->imc[] a flexible array EDAC/skx_common: Swap memory controller index mapping EDAC/skx_common: Move mc_mapping to be a field inside struct skx_imc EDAC/{skx_common,skx}: Use configuration data, not global macros EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller EDAC/ie31200: Add two more Intel Alder Lake-S SoCs for EDAC support dt-bindings: arm: cpus: Add edac-enabled property EDAC: Add EDAC driver for ARM Cortex A72 cores * edac-misc: EDAC: Fix wrong executable file modes for C source files MAINTAINERS: EDAC: Drop inactive reviewers Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
2025-09-26fcntl: trim argumentsKanchan Joshi
Remove superfluous argument from fcntl_{get/set}_rw_hint. No functional change. Signed-off-by: Kanchan Joshi <joshi.k@samsung.com> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-09-26listmount: don't call path_put() under namespace semaphoreChristian Brauner
Massage listmount() and make sure we don't call path_put() under the namespace semaphore. If we put the last reference we're fscked. Fixes: b4c2bea8ceaa ("add listmount(2) syscall") Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-09-26statmount: don't call path_put() under namespace semaphoreChristian Brauner
Massage statmount() and make sure we don't call path_put() under the namespace semaphore. If we put the last reference we're fscked. Fixes: 46eae99ef733 ("add statmount(2) syscall") Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-09-26netfs: fix reference leakMax Kellermann
Commit 20d72b00ca81 ("netfs: Fix the request's work item to not require a ref") modified netfs_alloc_request() to initialize the reference counter to 2 instead of 1. The rationale was that the requet's "work" would release the second reference after completion (via netfs_{read,write}_collection_worker()). That works most of the time if all goes well. However, it leaks this additional reference if the request is released before the I/O operation has been submitted: the error code path only decrements the reference counter once and the work item will never be queued because there will never be a completion. This has caused outages of our whole server cluster today because tasks were blocked in netfs_wait_for_outstanding_io(), leading to deadlocks in Ceph (another bug that I will address soon in another patch). This was caused by a netfs_pgpriv2_begin_copy_to_cache() call which failed in fscache_begin_write_operation(). The leaked netfs_io_request was never completed, leaving `netfs_inode.io_count` with a positive value forever. All of this is super-fragile code. Finding out which code paths will lead to an eventual completion and which do not is hard to see: - Some functions like netfs_create_write_req() allocate a request, but will never submit any I/O. - netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read() and then netfs_put_request(); however, netfs_unbuffered_read() can also fail early before submitting the I/O request, therefore another netfs_put_request() call must be added there. A rule of thumb is that functions that return a `netfs_io_request` do not submit I/O, and all of their callers must be checked. For my taste, the whole netfs code needs an overhaul to make reference counting easier to understand and less fragile & obscure. But to fix this bug here and now and produce a patch that is adequate for a stable backport, I tried a minimal approach that quickly frees the request object upon early failure. I decided against adding a second netfs_put_request() each time because that would cause code duplication which obscures the code further. Instead, I added the function netfs_put_failed_request() which frees such a failed request synchronously under the assumption that the reference count is exactly 2 (as initially set by netfs_alloc_request() and never touched), verified by a WARN_ON_ONCE(). It then deinitializes the request object (without going through the "cleanup_work" indirection) and frees the allocation (with RCU protection to protect against concurrent access by netfs_requests_seq_start()). All code paths that fail early have been changed to call netfs_put_failed_request() instead of netfs_put_request(). Additionally, I have added a netfs_put_request() call to netfs_unbuffered_read() as explained above because the netfs_put_failed_request() approach does not work there. Fixes: 20d72b00ca81 ("netfs: Fix the request's work item to not require a ref") Signed-off-by: Max Kellermann <max.kellermann@ionos.com> Signed-off-by: David Howells <dhowells@redhat.com> cc: Paulo Alcantara <pc@manguebit.org> cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org cc: stable@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-09-26Merge branches 'apple/dart', 'ti/omap', 'riscv', 'intel/vt-d' and ↵Joerg Roedel
'amd/amd-vi' into next
2025-09-26iommu/vt-d: Disallow dirty tracking if incoherent page walkLu Baolu
Dirty page tracking relies on the IOMMU atomically updating the dirty bit in the paging-structure entry. For this operation to succeed, the paging- structure memory must be coherent between the IOMMU and the CPU. In another word, if the iommu page walk is incoherent, dirty page tracking doesn't work. The Intel VT-d specification, Section 3.10 "Snoop Behavior" states: "Remapping hardware encountering the need to atomically update A/EA/D bits in a paging-structure entry that is not snooped will result in a non- recoverable fault." To prevent an IOMMU from being incorrectly configured for dirty page tracking when it is operating in an incoherent mode, mark SSADS as supported only when both ecap_slads and ecap_smpwc are supported. Fixes: f35f22cc760e ("iommu/vt-d: Access/Dirty bit support for SS domains") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/20250924083447.123224-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2025-09-26i2c: designware: Add disabling clocks when probe failsKunihiko Hayashi
After an error occurs during probing state, dw_i2c_plat_pm_cleanup() is called. However, this function doesn't disable clocks and the clock-enable count keeps increasing. Should disable these clocks explicitly. Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM") Co-developed-by: Kohei Ito <ito.kohei@socionext.com> Signed-off-by: Kohei Ito <ito.kohei@socionext.com> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-26i2c: designware: Fix clock issue when PM is disabledKunihiko Hayashi
When the driver is removed, the clocks are first enabled by calling pm_runtime_get_sync(), and then disabled with pm_runtime_put_sync(). If CONFIG_PM=y, clocks for this controller are disabled when it's in the idle state. So the clocks are properly disabled when the driver exits. Othewise, the clocks are always enabled and the PM functions have no effect. Therefore, the driver exits without disabling the clocks. # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count 18 # echo 1214a000.i2c > /sys/bus/platform/drivers/i2c_designware/bind # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count 20 # echo 1214a000.i2c > /sys/bus/platform/drivers/i2c_designware/unbind # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count 20 To ensure that the clocks can be disabled correctly even without CONFIG_PM=y, should add the following fixes: - Replace with pm_runtime_put_noidle(), which only decrements the runtime PM usage count. - Call i2c_dw_prepare_clk(false) to explicitly disable the clocks. Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM") Co-developed-by: Kohei Ito <ito.kohei@socionext.com> Signed-off-by: Kohei Ito <ito.kohei@socionext.com> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-26btrfs: avoid potential out-of-bounds in btrfs_encode_fh()Anderson Nascimento
The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data. Fixes: be6e8dc0ba84 ("NFS support for btrfs - v3") CC: stable@vger.kernel.org # 3.0+ Signed-off-by: Anderson Nascimento <anderson@allelesecurity.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2025-09-26rust: usb: keep usb::Device private for nowDanilo Krummrich
The USB abstractions target to support USB interface drivers. While internally the abstraction has to deal with the interface's parent USB device, there shouldn't be a need for users to deal with the parent USB device directly. Functions, such as for preparing and sending USB URBs, can be implemented for the usb::Interface structure directly. Whether this internal implementation has to deal with the parent USB device can remain transparent to USB interface drivers. Hence, keep the usb::Device structure private for now, in order to avoid confusion for users and to make it less likely to accidentally expose APIs with unnecessary indirections. Should we start supporting USB device drivers, or need it for any other reason we do not foresee yet, it should be trivial to make it public again. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250925190400.144699-2-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-26rust: usb: don't retain device context for the interface parentDanilo Krummrich
When deriving the parent USB device (struct usb_device) from a USB interface (struct usb_interface), do not retain the device context. For the Bound context, as pointed out by Alan in [1], it is not guaranteed that the parent USB device is always bound when the interface is bound. The bigger problem, however, is that we can't infer the Core context, since eventually it indicates that the device lock is held. However, there is no guarantee that if the device lock of the interface is held, also the device lock of the parent USB device is held. Hence, fix this by not inferring any device context information; while at it, fix up the (affected) safety comments. Link: https://lore.kernel.org/all/0ff2a825-1115-426a-a6f9-df544cd0c5fc@rowland.harvard.edu/ [1] Fixes: e7e2296b0ecf ("rust: usb: add basic USB abstractions") Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250925190400.144699-1-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-26drm/i915/psr: Deactivate PSR only on LNL and when selective fetch enabledJouni Högander
Using intel_psr_exit in frontbuffer flush on older platforms seems to be causing problems. Sending single full frame update using intel_psr_force_update is anyways more optimal compared to psr deactivate/activate -> move back to this approach on PSR1, PSR HW tracking and Panel Replay full frame update and use deactivate/activate only on LunarLake and only when selective fetch is enabled. Tested-by: Lemen <lemen@lemen.xyz> Tested-by: Koos Vriezen <koos.vriezen@gmail.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14946 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://lore.kernel.org/r/20250922102725.2752742-1-jouni.hogander@intel.com
2025-09-26Merge tag 'drm-xe-fixes-2025-09-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes - Don't expose sysfs attributes not applicable for VFs (Michal) - Fix build with CONFIG_MODULES=n (Lucas) - Don't copy pinned kernel bos twice on suspend (Thomas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/aNU-FkJEcA3T4aDB@intel.com
2025-09-26Merge tag 'drm-misc-fixes-2025-09-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes A CPU stall fix for ast, a NULL pointer dereference fix for gma500, an OOB and overflow fixes for fbcon, and a race condition fix for panthor. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://lore.kernel.org/r/20250925-smilodon-of-luxurious-genius-4ebee7@penduick
2025-09-26Merge tag 'drm-intel-fixes-2025-09-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes - Set O_LARGEFILE in __create_shmem() (Taotao Chen) - Guard reg_val against a INVALID_TRANSCODER [ddi] (Suraj Kandpal) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tursulin@igalia.com> Link: https://lore.kernel.org/r/aNTxWfhsMkFZ3Q-a@linux
2025-09-26Merge tag 'amd-drm-fixes-6.17-2025-09-24' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.17-2025-09-24: amdgpu: - Backlight fix - DC preblend fix - DCN 3.5 fix - Cleanup output_tf_change Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://lore.kernel.org/r/20250924200632.531102-1-alexander.deucher@amd.com
2025-09-26Merge tag 'drm-habanalabs-next-2025-09-25' of ↵Dave Airlie
https://github.com/HabanaAI/drivers.accel.habanalabs.kernel into drm-next This tag contains habanalabs driver changes for v6.18. It continues the previous upstream work from tags/drm-habanalabs-next-2024-06-23, Including improvements in debug and visibility, alongside general code cleanups, and new features such as vmalloc-backed coherent mmap, HLDIO infrastructure, etc. Signed-off-by: Dave Airlie <airlied@redhat.com> From: "Elbaz, Koby" <koby.elbaz@intel.com> Link: https://lore.kernel.org/r/da02d370-9967-49d2-9eef-7aeaa40c987c@intel.com
2025-09-25tools/power x86_energy_perf_policy.8: Emphasize preference for SW interfacesLen Brown
This tool was originally written when Linux had no standard interface for EPB, or HWP support. Retain the capability to manage a system w/o any kernel PM support, but prefer the standard kernel interfaces, when avaialble. (not doing so led to a confusing conflict between a p-state limit request made via cpufreq and modified by the intel-pstate driver, versus the raw MSR write made by this utility) Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power x86_energy_perf_policy: Add make snapshot targetLen Brown
$ make snapshot creates x86_energy_perf_policy-$(DATE).tar.gz Which can be transported to a target machine without needing a kernel tree to build on the target. Useful for creating debug versions. Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power x86_energy_perf_policy: Prefer driver HWP limitsLen Brown
When we are successful in using cpufreq min/max limits, skip setting the raw MSR limits entirely. This is necessary to avoid undoing any modification that the cpufreq driver makes to our sysfs request. eg. intel_pstate may take our request for a limit that is valid according to HWP.CAP.MIN/MAX and clip it to be within the range available in PLATFORM_INFO. Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power x86_energy_perf_policy: EPB access is only via sysfsLen Brown
Comprehend that EPB writes are now only via sysfs by moving it out of the _msr specific path. No functional change. Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power x86_energy_perf_policy: Prepare for MSR/sysfs refactoringLen Brown
Rename routines to make "_msr" and "_sysfs" access methods clear No functional change Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power x86_energy_perf_policy: Enhance HWP enableLen Brown
On enabling HWP, preserve the reserved bits in MSR_PM_ENABLE. Also, skip writing the MSR_PM_ENABLE if HWP is already enabled. Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power x86_energy_perf_policy: Enhance HWP enabled checkLen Brown
Verify that all CPUs have HWP enabled, not just cpu0. Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power x86_energy_perf_policy: Fix incorrect fopen mode usageKaushlendra Kumar
The fopen_or_die() function was previously hardcoded to open files in read-only mode ("r"), ignoring the mode parameter passed to it. This patch corrects fopen_or_die() to use the provided mode argument, allowing for flexible file access as intended. Additionally, the call to fopen_or_die() in err_on_hypervisor() incorrectly used the mode "ro", which is not a valid fopen mode. This is fixed to use the correct "r" mode. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-25tools/power turbostat: Fix incorrect sorting of PMT telemetryKaushlendra Kumar
The pmt_telemdir_sort() comparison function was returning a boolean value (0 or 1) instead of the required negative, zero, or positive value for proper sorting. This caused unpredictable and incorrect ordering of telemetry directories named telem0, telem1, ..., telemN. Update the comparison logic to return -1, 0, or 1 based on the numerical value extracted from the directory name, ensuring correct numerical ordering when using scandir. This change improves stability and correctness when iterating PMT telemetry directories. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2025-09-26Merge tag 'drm-misc-next-fixes-2025-09-25' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Short summary of fixes pull: bridge: - waveshare-dsi: Fix error handling in probe function pixpaper: - select GEM SHMEM helpers Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250925064257.GA9107@linux.fritz.box
2025-09-25ext4: correctly handle queries for metadata mappingsOjaswin Mujoo
Currently, our handling of metadata is _ambiguous_ in some scenarios, that is, we end up returning unknown if the range only covers the mapping partially. For example, in the following case: $ xfs_io -c fsmap -d 0: 254:16 [0..7]: static fs metadata 8 1: 254:16 [8..15]: special 102:1 8 2: 254:16 [16..5127]: special 102:2 5112 3: 254:16 [5128..5255]: special 102:3 128 4: 254:16 [5256..5383]: special 102:4 128 5: 254:16 [5384..70919]: inodes 65536 6: 254:16 [70920..70967]: unknown 48 ... $ xfs_io -c fsmap -d 24 33 0: 254:16 [24..39]: unknown 16 <--- incomplete reporting $ xfs_io -c fsmap -d 24 33 (With patch) 0: 254:16 [16..5127]: special 102:2 5112 This is because earlier in ext4_getfsmap_meta_helper, we end up ignoring any extent that starts before our queried range, but overlaps it. While the man page [1] is a bit ambiguous on this, this fix makes the output make more sense since we are anyways returning an "unknown" extent. This is also consistent to how XFS does it: $ xfs_io -c fsmap -d ... 6: 254:16 [104..127]: free space 24 7: 254:16 [128..191]: inodes 64 ... $ xfs_io -c fsmap -d 137 150 0: 254:16 [128..191]: inodes 64 <-- full extent returned [1] https://man7.org/linux/man-pages/man2/ioctl_getfsmap.2.html Reported-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Cc: stable@kernel.org Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Message-ID: <023f37e35ee280cd9baac0296cbadcbe10995cab.1757058211.git.ojaswin@linux.ibm.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2025-09-25ACPI: support BGRT table on RISC-VHeinrich Schuchardt
The BGRT table is used to display a vendor logo in the boot process. There is no good reason why RISC-V should not support it. Remove the architecture constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Link: https://lore.kernel.org/r/20250729131535.522205-3-heinrich.schuchardt@canonical.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25MAINTAINERS: Add entry for RISC-V RPMI and MPXY driversAnup Patel
Add Rahul and myself as maintainers for RISC-V RPMI and MPXY drivers. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-25-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25RISC-V: Enable GPIO keyboard and event device in RV64 defconfigAnup Patel
The GPIO keyboard and event device can be used to receive graceful shutdown or reboot input keys so let us enable it by default for RV64 (just like ARM64). Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-24-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25irqchip/riscv-rpmi-sysmsi: Add ACPI supportSunil V L
Add ACPI support for the RISC-V RPMI system MSI based irqchip driver. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-23-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25mailbox/riscv-sbi-mpxy: Add ACPI supportSunil V L
Add ACPI support for the RISC-V SBI message proxy (MPXY) based mailbox driver. Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20250818040920.272664-22-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25irqchip/irq-riscv-imsic-early: Export imsic_acpi_get_fwnode()Sunil V L
ACPI based loadable drivers which need MSIs will also need imsic_acpi_get_fwnode() to update the device MSI domain so export this function. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20250818040920.272664-21-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: RISC-V: Add RPMI System MSI to GSI mappingSunil V L
The RPMI System MSI device will provide GSIs to downstream devices (such as GED) so add it to the RISC-V GSI to fwnode mapping. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-20-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: RISC-V: Add support to update gsi rangeSunil V L
Some RISC-V interrupt controllers like RPMI based system MSI interrupt controllers do not have MADT entry defined. These interrupt controllers exist only in the namespace. ACPI spec defines _GSB method to get the GSI base of the interrupt controller, However, there is no such standard method to get the GSI range. To support such interrupt controllers, set the GSI range of such interrupt controllers to non-overlapping range and provide API for interrupt controller driver to update it with proper value. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-19-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: RISC-V: Create interrupt controller list in sorted orderSunil V L
Currently, the interrupt controller list is created without any order. Create the list sorted with the GSI base of the interrupt controllers. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-18-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: scan: Update honor list for RPMI System MSISunil V L
The RPMI System MSI interrupt controller (just like PLIC and APLIC) needs to probed prior to devices like GED which use interrupts provided by it. Also, it has dependency on the SBI MPXY mailbox device. Add HIDs of RPMI System MSI and SBI MPXY mailbox devices to the honor list so that those dependencies are handled. Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-17-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: Add support for nargs_prop in acpi_fwnode_get_reference_args()Sunil V L
Currently, ACPI does not support the use of a nargs_prop (e.g., associated with a reference in fwnode_property_get_reference_args(). Instead, ACPI expects the number of arguments (nargs) to be explicitly passed or known. This behavior diverges from Open Firmware (OF), which allows the use of a #*-cells property in the referenced node to determine the number of arguments. Since fwnode_property_get_reference_args() is a common interface used across both OF and ACPI firmware paradigms, it is desirable to have a unified calling convention that works seamlessly for both. Add the support for ACPI to parse a nargs_prop from the referenced fwnode, aligning its behavior with the OF backend. This allows drivers and subsystems using fwnode_property_get_reference_args() to work in a firmware-agnostic way without having to hardcode or special-case argument counts for ACPI. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-16-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25dt-bindings: hwmon: (lm75) allow interrupt for ti,tmp75Frank Li
Allow interrupt for ti,tmp75 because chip has open drain ALERT signal. Signed-off-by: Frank Li <Frank.Li@nxp.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250925192219.303825-1-Frank.Li@nxp.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
generated by cgit v1.3 (git 2.53.0) at 2026-11-12 15:58:13 +0000