aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-04-08Input: inport - remove driverDmitry Torokhov3-194/+0
Inport (ATI XL and Microsoft) mice use specialized bus interface implemented via an ISA add-in card. Have been superseded by PS/2 and then USB, and are historical curiosity by now. Remove the driver. Link: https://patch.msgid.link/20240808172733.1194442-2-dmitry.torokhov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Input: qt1070 - inline i2c_check_functionality checkThorsten Blum1-2/+1
Inline the i2c_check_functionality() check, since the function returns a boolean status rather than an error code. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260408141926.1181389-4-thorsten.blum@linux.dev Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08Input: qt1050 - inline i2c_check_functionality checkThorsten Blum1-2/+1
Inline the i2c_check_functionality() check, since the function returns a boolean status rather than an error code. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260408141926.1181389-3-thorsten.blum@linux.dev Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-08firmware: efi: Never declare sysfb_primary_display on x86Thomas Zimmermann1-1/+1
The x86 architecture comes with its own instance of the global state variable sysfb_primary_display. Never declare it in the EFI subsystem. Fix the test for CONFIG_FIRMWARE_EDID accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: e65ca1646311 ("efi: export sysfb_primary_display for EDID") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2026-04-08Merge tag 'md-7.1-20260407' of git://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux into for-7.1/blockJens Axboe7-62/+405
Pull MD changes from Yu Kuai: "Bug Fixes: - avoid a sysfs deadlock when clearing array state (Yu Kuai) - validate raid5 journal payloads before reading metadata (Junrui Luo) - fall back to the correct bitmap operations after version mismatches (Yu Kuai) - serialize overlapping writes on writemostly raid1 disks (Xiao Ni) - wake raid456 reshape waiters before suspend (Yu Kuai) - prevent retry_aligned_read() from triggering soft lockups (Chia-Ming Chang) Improvements: - switch raid0 strip zone and devlist allocations to kvmalloc helpers (Gregory Price) - track clean unwritten stripes for proactive RAID5 parity building (Yu Kuai) - speed up initial llbitmap sync with write_zeroes_unmap support (Yu Kuai) Cleanups: - remove the unused static md workqueue definition (Abd-Alrhman Masalkhi)" * tag 'md-7.1-20260407' of git://git.kernel.org/pub/scm/linux/kernel/git/mdraid/linux: md/raid5: fix soft lockup in retry_aligned_read() md: wake raid456 reshape waiters before suspend md/raid1: serialize overlap io for writemostly disk md/md-llbitmap: optimize initial sync with write_zeroes_unmap support md/md-llbitmap: add CleanUnwritten state for RAID-5 proactive parity building md: add fallback to correct bitmap_ops on version mismatch md/raid5: validate payload size before accessing journal metadata md: remove unused static md_wq workqueue md/raid0: use kvzalloc/kvfree for strip_zone and devlist allocations md: fix array_state=clear sysfs deadlock
2026-04-08drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeatSebastian Brzezinka1-8/+18
A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <TASK> <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] </TASK> ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15880 Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/d4c1c14255688dd07cc8044973c4f032a8d1559e.1775038106.git.sebastian.brzezinka@intel.com (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-04-08Merge branch kvm-arm64/pkvm-protected-guest into kvmarm-master/nextMarc Zyngier1-1/+1
* kvm-arm64/pkvm-protected-guest: (41 commits) : . : pKVM support for protected guests, implementing the very long : awaited support for anonymous memory, as the elusive guestmem : has failed to deliver on its promises despite a multi-year : effort. Patches courtesy of Will Deacon. From the initial cover : letter: : : "[...] this patch series implements support for protected guest : memory with pKVM, where pages are unmapped from the host as they are : faulted into the guest and can be shared back from the guest using pKVM : hypercalls. Protected guests are created using a new machine type : identifier and can be booted to a shell using the kvmtool patches : available at [2], which finally means that we are able to test the pVM : logic in pKVM. Since this is an incremental step towards full isolation : from the host (for example, the CPU register state and DMA accesses are : not yet isolated), creating a pVM requires a developer Kconfig option to : be enabled in addition to booting with 'kvm-arm.mode=protected' and : results in a kernel taint." : . KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim KVM: arm64: Allow get_pkvm_hyp_vm() to take a reference to a dying VM KVM: arm64: Prevent teardown finalisation of referenced 'hyp_vm' drivers/virt: pkvm: Add Kconfig dependency on DMA_RESTRICTED_POOL KVM: arm64: Rename PKVM_PAGE_STATE_MASK KVM: arm64: Extend pKVM page ownership selftests to cover guest hvcs KVM: arm64: Extend pKVM page ownership selftests to cover forced reclaim KVM: arm64: Register 'selftest_vm' in the VM table KVM: arm64: Extend pKVM page ownership selftests to cover guest donation KVM: arm64: Add some initial documentation for pKVM KVM: arm64: Allow userspace to create protected VMs when pKVM is enabled KVM: arm64: Implement the MEM_UNSHARE hypercall for protected VMs KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs KVM: arm64: Add hvc handler at EL2 for hypercalls from protected VMs KVM: arm64: Return -EFAULT from VCPU_RUN on access to a poisoned pte KVM: arm64: Reclaim faulting page from pKVM in spurious fault handler KVM: arm64: Introduce hypercall to force reclaim of a protected page KVM: arm64: Annotate guest donations with handle and gfn in host stage-2 KVM: arm64: Change 'pkvm_handle_t' to u16 KVM: arm64: Introduce host_stage2_set_owner_metadata_locked() ... Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-04-08Merge branch 'thermal-intel'Rafael J. Wysocki2-6/+21
Merge updates of Intel thermal drivers for 7.1: - Replace cpumask_weight() in intel_hfi_offline() with cpumask_empty() which is generally more efficient (Yury Norov) - Add support for reading DDR data rate from PCI config space on Nova Lake platforms to the int340x thermal driver (Srinivas Pandruvada) * thermal-intel: thermal: intel: hfi: use cpumask_empty() in intel_hfi_offline() thermal: intel: int340x: Read DDR data rate for Nova Lake
2026-04-08thermal: core: Suspend thermal zones later and resume them earlierRafael J. Wysocki2-42/+23
To avoid some undesirable interactions between thermal zone suspend and resume with user space that is running when those operations are carried out, move them closer to the suspend and resume of devices, respectively, by updating dpm_prepare() to carry out thermal zone suspend and dpm_complete() to start thermal zone resume (that will continue asynchronously). This also makes the code easier to follow by removing one, arguably redundant, level of indirection represented by the thermal PM notifier. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/2036875.PYKUYFuaPT@rafael.j.wysocki
2026-04-08thermal: core: Allocate thermal_class staticallyRafael J. Wysocki1-18/+12
Define thermal_class as a static structure to simplify thermal_init() and to simplify thermal class availability checks that will need to be carried out during the suspend and resume of thermal zones after subsequent changes. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/10831981.nUPlyArG6x@rafael.j.wysocki
2026-04-08thermal: core: Adjust thermal_wq allocation flagsRafael J. Wysocki1-2/+1
The thermal workqueue doesn't need to be freezable or per-CPU, so drop WQ_FREEZABLE and WQ_PERCPU from the flags when allocating it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [ rjw: Subject rewrite ] Link: https://patch.msgid.link/3413335.44csPzL39Z@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-08thermal: core: Drop redundant check from thermal_zone_device_update()Rafael J. Wysocki1-7/+1
Since __thermal_zone_device_update() checks if tz->state is TZ_STATE_READY and bails out immediately otherwise, it is not necessary to check the thermal_zone_is_present() return value in thermal_zone_device_update(). Namely, tz->state is equal to TZ_STATE_FLAG_INIT initially and that flag is only cleared in thermal_zone_init_complete() after adding tz to the list of thermal zones, and thermal_zone_exit() sets TZ_STATE_FLAG_EXIT in tz->state while removing tz from that list. Thus tz->state is not TZ_STATE_READY when tz is not in the list and the check mentioned above is redundant. Accordingly, drop the redundant thermal_zone_is_present() check from thermal_zone_device_update() and drop the former altogether because it has no more users. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/3406806.aeNJFYEL58@rafael.j.wysocki
2026-04-08thermal: core: Free thermal zone ID later during removalRafael J. Wysocki1-2/+4
The thermal zone removal ordering is different from the thermal zone registration rollback path ordering and the former is arguably problematic because freeing a thermal zone ID prematurely may cause it to be used during the registration of another thermal zone which may fail as a result. Prevent that from occurring by changing the thermal zone removal ordering to reflect the thermal zone registration rollback path ordering. Also more the ida_destroy() call from thermal_zone_device_unregister() to thermal_release() for consistency. Fixes: b31ef8285b19 ("thermal core: convert ID allocation to IDA") Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5063934.GXAFRqVoOG@rafael.j.wysocki
2026-04-08thermal: core: Fix thermal zone governor cleanup issuesRafael J. Wysocki1-3/+4
If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak. In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case. Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration. Fixes: e33df1d2f3a0 ("thermal: let governors have private data for each thermal zone") Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5092923.31r3eYUQgx@rafael.j.wysocki
2026-04-08pmdomain: qcom: rpmhpd: Add power domains for Hawi SoCFenglin Wu1-0/+38
Add the RPMh power domains required for the Hawi SoC. This includes new definitions for domains supplying specific hardware components: - DCX: supplies VDD_DISP - GBX: supplies VDD_GFX_BX Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-04-08pmdomain: qcom: cpr: add COMPILE_TEST supportRosen Penev1-1/+1
Allows the buildbots to build the driver on other platforms. There's nothing special arch specific thing going on here. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2026-04-08Merge tag 'rust-timekeeping-for-v7.1' of https://github.com/Rust-for-Linux/linux into rust-nextMiguel Ojeda361-2134/+3661
Pull timekeeping updates from Andreas Hindborg: - Expand the example section in the 'HrTimer' documentation. - Mark the 'ClockSource' trait as unsafe to ensure valid values for 'ktime_get()'. - Add 'Delta::from_nanos()'. This is a back merge since the pull request has a newer base -- we will avoid that in the future. And, given it is a back merge, it happens to resolve the "subtle" conflict around '--remap-path-{prefix,scope}' that I discussed in linux-next [1], plus a few other common conflicts. The result matches what we did for next-20260407. The actual diffstat (i.e. using a temporary merge of upstream first) is: rust/kernel/time.rs | 32 ++++- rust/kernel/time/hrtimer.rs | 336 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 362 insertions(+), 6 deletions(-) Link: https://lore.kernel.org/linux-next/CANiq72kdxB=W3_CV1U44oOK3SssztPo2wLDZt6LP94TEO+Kj4g@mail.gmail.com/ [1] * tag 'rust-timekeeping-for-v7.1' of https://github.com/Rust-for-Linux/linux: hrtimer: add usage examples to documentation rust: time: make ClockSource unsafe trait rust/time: Add Delta::from_nanos()
2026-04-08USB: serial: iuu_phoenix: fix iuutool author nameThorsten Blum1-1/+1
The original iuutool author is Juan Carlos Borrás - fix the spelling. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-04-08gpio: bd72720: handle missing regmapMatti Vaittinen1-0/+2
Currently the probe does not check whether getting the regmap succeeded. This can cause crash when regmap is used, if it wasn't successfully obtained. Failing to get the regmap is unlikely, especially since this driver is expected to be kicked by the MFD driver only after registering the regmap - but it is still better to handle this gracefully. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: e7eef0bd4075 ("regulator: bd71828-regulator.c: Fix LDON-HEAD mode") Link: https://patch.msgid.link/5bfffee380863bcf24f3062e48094c8eb7b1342f.1775565381.git.mazziesaccount@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-04-08wifi: ipw2x00: Use michael_mic() from cfg80211Eric Biggers2-116/+5
Just use the michael_mic() function from cfg80211 instead of a local implementation of it using the crypto_shash API. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260408030651.80336-6-ebiggers@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-08wifi: ath12k: Use michael_mic() from cfg80211Eric Biggers6-62/+8
Just use the michael_mic() function from cfg80211 instead of a local implementation of it using the crypto_shash API. Note: when the kernel is booted with fips=1, crypto_alloc_shash("michael_mic", 0, 0) always returned ERR_PTR(-ENOENT), because Michael MIC is not a "FIPS allowed" algorithm. For now, just preserve that behavior exactly, to ensure that TKIP is not allowed to be used in FIPS mode. This logic actually seems to disable the entire driver in FIPS mode and not just TKIP, but that was the existing behavior. Supporting this driver in FIPS mode, if anyone actually needs it there, should be a separate commit. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260408030651.80336-5-ebiggers@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-08wifi: ath11k: Use michael_mic() from cfg80211Eric Biggers4-57/+7
Just use the michael_mic() function from cfg80211 instead of a local implementation of it using the crypto_shash API. Note: when the kernel is booted with fips=1, crypto_alloc_shash("michael_mic", 0, 0) always returned ERR_PTR(-ENOENT), because Michael MIC is not a "FIPS allowed" algorithm. For now, just preserve that behavior exactly, to ensure that TKIP is not allowed to be used in FIPS mode. This logic actually seems to disable the entire driver in FIPS mode and not just TKIP, but that was the existing behavior. Supporting this driver in FIPS mode, if anyone actually needs it there, should be a separate commit. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260408030651.80336-4-ebiggers@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-08wifi: ipw2x00: Rename michael_mic() to libipw_michael_mic()Eric Biggers1-3/+3
Rename the driver-local michael_mic() function to libipw_michael_mic() to prevent a name conflict with the common michael_mic() function. Note that this code will be superseded later when libipw starts using the common michael_mic(). This commit just prevents a bisection hazard. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260408030651.80336-2-ebiggers@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-08Merge tag 'ath-next-20260407' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/athJohannes Berg16-46/+382
Jeff Johnson says: ================== ath.git patches for v7.1 (PR #3) Add ath12k support for IPQ5424. And of course there is the usual set of cleanups and bug fixes touching the ath10k and ath12k drivers. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-08wifi: libertas_tf: refactor endpoint lookupJohan Hovold1-24/+20
Use the common USB helpers for looking up bulk and interrupt endpoints (and determining max packet size) instead of open coding. Note that the driver has an implicit max packet size check which is kept. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260407151111.3187826-4-johan@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-08wifi: libertas: refactor endpoint lookupJohan Hovold1-17/+16
Use the common USB helpers for looking up bulk and interrupt endpoints (and determining max packet size) instead of open coding. Note that the driver has an implicit max packet size check which is kept. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260407151111.3187826-3-johan@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-08wifi: at76c50x: refactor endpoint lookupJohan Hovold1-18/+4
Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260407151111.3187826-2-johan@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-04-07Input: uinput - fix circular locking dependency with ff-coreMikhail Gavrilov1-7/+21
A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge) Fixes: ff462551235d ("Input: uinput - switch to the new FF interface") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/CABXGCsMoxag+kEwHhb7KqhuyxfmGGd0P=tHZyb1uKE0pLr8Hkg@mail.gmail.com/ Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Link: https://patch.msgid.link/20260407075031.38351-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-04-07net: stmmac: dwmac-motorcomm: fix eFUSE MAC address read failureJohan Alvarado1-0/+8
This patch fixes an issue where reading the MAC address from the eFUSE fails due to a race condition. The root cause was identified by comparing the driver's behavior with a custom U-Boot port. In U-Boot, the MAC address was read successfully every time because the driver was loaded later in the boot process, giving the hardware ample time to initialize. In Linux, reading the eFUSE immediately returns all zeros, resulting in a fallback to a random MAC address. Hardware cold-boot testing revealed that the eFUSE controller requires a short settling time to load its internal data. Adding a 2000-5000us delay after the reset ensures the hardware is fully ready, allowing the native MAC address to be read consistently. Fixes: 02ff155ea281 ("net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller") Reported-by: Georg Gottleuber <ggo@tuxedocomputers.com> Closes: https://lore.kernel.org/24cfefff-1233-4745-8c47-812b502d5d19@tuxedocomputers.com Signed-off-by: Johan Alvarado <contact@c127.dev> Reviewed-by: Yao Zi <me@ziyao.cc> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/fc5992a4-9532-49c3-8ec1-c2f8c5b84ca1@smtp-relay.sendinblue.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07net: sfp: add quirks for Hisense and HSGQ GPON ONT SFP modulesJohn Pavlick1-0/+16
Several GPON ONT SFP sticks based on Realtek RTL960x report 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X. On hosts capable of 2500base-X (e.g. Banana Pi R3 / MT7986), the kernel negotiates only 1G because it trusts the incorrect EEPROM data. Add quirks for: - Hisense-Leox LXT-010S-H - Hisense ZNID-GPON-2311NA - HSGQ HSGQ-XPON-Stick Each quirk advertises 2500base-X and ignores TX_FAULT during the module's ~40s Linux boot time. Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed 2.5Gbps link and full throughput with flow offloading. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Suggested-by: Marcin Nita <marcin.nita@leolabs.pl> Signed-off-by: John Pavlick <jspavlick@posteo.net> Link: https://patch.msgid.link/20260406132321.72563-1-jspavlick@posteo.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07wifi: ath12k: Enable IPQ5424 WiFi device supportSowmiya Sree Elavalagan3-14/+31
Currently, ath12k AHB (in IPQ5332) uses SCM calls to authenticate the firmware image to bring up userpd. From IPQ5424 onwards, Q6 firmware can directly communicate with the Trusted Management Engine - Lite (TME-L), eliminating the need for SCM calls for userpd bring-up. Hence, to enable IPQ5424 device support, use qcom_mdt_load_no_init() and skip the SCM call as Q6 will directly authenticate the userpd firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sowmiya Sree Elavalagan <sowmiya.elavalagan@oss.qualcomm.com> Co-developed-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com> Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com> Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260407-ath12k-ipq5424-v5-6-8e96aa660ec4@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: Add CE remap hardware parameters for IPQ5424Saravanakumar Duraisamy2-9/+26
Add CE remap hardware parameters for Ath12k AHB device IPQ5424. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260407-ath12k-ipq5424-v5-5-8e96aa660ec4@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: add ath12k_hw_regs for IPQ5424Saravanakumar Duraisamy4-1/+93
Add register addresses (ath12k_hw_regs) for ath12k AHB based WiFi 7 device IPQ5424. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260407-ath12k-ipq5424-v5-4-8e96aa660ec4@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424Raj Kumar Bhagat1-0/+7
Add a new ath12k_hw_version_map entry for the AHB based WiFi 7 device IPQ5424. Reuse most of the ath12k_hw_version_map fields such as hal_ops, hal_desc_sz, tcl_to_wbm_rbm_map, and hal_params from IPQ5332. The register addresses differ on IPQ5424, hence set hw_regs temporarily to NULL and populated it in a subsequent patch. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260407-ath12k-ipq5424-v5-3-8e96aa660ec4@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: Add ath12k_hw_params for IPQ5424Saravanakumar Duraisamy2-0/+80
Add ath12k_hw_params for the ath12k AHB-based WiFi 7 device IPQ5424. The WiFi device IPQ5424 is similar to IPQ5332. Most of the hardware parameters like hw_ops, wmi_init, ring_mask, etc., are the same between IPQ5424 and IPQ5332, hence use these same parameters for IPQ5424. Some parameters are specific to IPQ5424; initially set these to 0 or NULL, and populate them in subsequent patches. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1 Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com> Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260407-ath12k-ipq5424-v5-2-8e96aa660ec4@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath10k: fix station lookup failure during disconnectBaochen Qiang1-11/+15
Recent commit [1] moved station statistics collection to an earlier stage of the disconnect flow. With this change in place, ath10k fails to resolve the station entry when handling a peer stats event triggered during disconnect, resulting in log messages such as: wlp58s0: deauthenticating from 74:1a:e0:e7:b4:c8 by local choice (Reason: 3=DEAUTH_LEAVING) ath10k_pci 0000:3a:00.0: not found station for peer stats ath10k_pci 0000:3a:00.0: failed to parse stats info tlv: -22 The failure occurs because ath10k relies on ieee80211_find_sta_by_ifaddr() for station lookup. That function uses local->sta_hash, but by the time the peer stats request is triggered during disconnect, mac80211 has already removed the station from that hash table, leading to lookup failure. Before commit [1], this issue was not visible because the transition from IEEE80211_STA_NONE to IEEE80211_STA_NOTEXIST prevented ath10k from sending a peer stats request at all: ath10k_mac_sta_get_peer_stats_info() would fail early to find the peer and skip requesting statistics. Fix this by switching the lookup path to ath10k_peer_find(), which queries ath10k's internal peer table. At the point where the firmware emits the peer stats event, the peer entry is still present in the driver's list, ensuring lookup succeeds. Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00309-QCARMSWPZ-1 Fixes: a203dbeeca15 ("wifi: mac80211: collect station statistics earlier when disconnect") # [1] Reported-by: Paul Menzel <pmenzel@molgen.mpg.de> Closes: https://lore.kernel.org/ath10k/57671b89-ec9f-4e6c-992c-45eb8e75929c@molgen.mpg.de Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Tested-by: Paul Menzel <pmenzel@molgen.mpg.de> Link: https://patch.msgid.link/20260325-ath10k-station-lookup-failure-v1-1-2e0c970f25d5@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: Create symlink for each radio in a wiphyRoopni Devanathan4-8/+29
In single-wiphy design, when more than one radio is registered as a single-wiphy in the mac80211 layer, the following warnings are seen: 1. debugfs: File 'ath12k' in directory 'phy0' already present! 2. debugfs: File 'simulate_fw_crash' in directory 'pci-0000:57:00.0' already present! debugfs: File 'device_dp_stats' in directory 'pci-01777777777777777777777:57:00.0' already present! When more than one radio is registered as a single-wiphy, symlinks for all the radios are created in the same debugfs directory: /sys/kernel/debug/ieee80211/phyX/ath12k, resulting in warning 1. When a symlink is created for the first radio, since the 'ath12k' directory is not present, it will be created and no warning will be thrown. But when symlink is created for more than one radio, since the 'ath12k' directory was already created for symlink for radio 1, a warning is thrown complaining that 'ath12k' directory is already present. To resolve warning 1, create symlink for each radio in separate debugfs directories. For the first radio, the symlink will always be the 'ath12k' directory. This ensures that the existing directory structure is retained for single-wiphy and multi-wiphy architectures. In single-wiphy architecture with multiple radios, create symlink in separate debugfs directories introduced by mac80211. Existing debugfs directory in single-wiphy architecture: /sys/kernel/debug/ieee80211/phyX/ath12k is a symlink to /sys/kernel/debug/ath12k/pci-0001:01:00.0/macY Proposed debugfs directory in single-wiphy architecture with one radio: /sys/kernel/debug/ieee80211/phyX/ath12k is a symlink to /sys/kernel/debug/ath12k/pci-0001:01:00.0/mac0 Proposed debugfs directory in single-wiphy architecture with more than one radio: /sys/kernel/debug/ieee80211/phyX/radio0/ath12k is a symlink to /sys/kernel/debug/ath12k/pci-0001:01:00.0/mac0 and /sys/kernel/debug/ieee80211/phyX/radioY/ath12k is a symlink to /sys/kernel/debug/ath12k/pci-0001:01:00.0/macY Where X is phy index and Y is radio index, seen in 'iw phyX info | grep Idx'. Two symlinks for the first radio are to ensure compatibility with the existing design. Add radio_idx inside ar, to track the radio index in probing order. API ath12k_debugfs_pdev_create() that creates SoC entries is called more than once when hardware group starts up, resulting in warning 2. To resolve this warning, remove all other calls to this API and add one inside the ath12k_core_pdev_create(). This API carries all pdev-specific initializations and can conveniently hold a call to ath12k_debugfs_pdev_create(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Co-developed-by: Harshitha Prem <harshitha.prem@oss.qualcomm.com> Signed-off-by: Harshitha Prem <harshitha.prem@oss.qualcomm.com> Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260402051402.3903795-1-roopni.devanathan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: Skip adding inactive partner vdev infoAvula Sri Charan1-1/+1
Currently, a vdev that is created is considered active for partner link population. In case of an MLD station, non-associated link vdevs can be created but not started. Yet, they are added as partner links. This leads to the creation of stale FW partner entries which accumulate and cause assertions. To resolve this issue, check if the vdev is started and operating on a chosen frequency, i.e., arvif->is_started, instead of checking if the vdev is created, i.e., arvif->is_created. This determines if the vdev is active or not and skips adding it as a partner link if it's inactive. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1 Signed-off-by: Avula Sri Charan <quic_asrichar@quicinc.com> Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260330040732.1847263-1-roopni.devanathan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: Support channel change statsHarish Rachakonda2-0/+98
Add support to request channel change stats from the firmware through HTT stats type 76. These stats give channel switch details like the channel that the radio changed to, its center frequency, time taken for the switch, chainmask details, etc. Sample output: echo 76 > /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats_type cat /sys/kernel/debug/ath12k/pci-0000\:06\:00.0/mac0/htt_stats Channel Change Timings: |PRIMARY CHANNEL FREQ|BANDWIDTH CENTER FREQ|PHYMODE|TX_CHAINMASK|RX_CHAINMASK|SWITCH TIME(us)|INI(us)|TPC+CTL(us)|CAL(us)|MISC(us)|CTL(us)|SW PROFILE| | 5200| 5200| 24| 15| 15| 448850| 2410| 10546| 434593| 1071| 1100| 4| | 5240| 5240| 24| 15| 15| 450730| 4106| 10524| 434528| 1306| 1150| 4| | 5180| 5210| 26| 15| 15| 467894| 4764| 10438| 451101| 1337| 1508| 4| | 5200| 5200| 0| 15| 15| 13838| 2692| 1736| 8558| 686| 802| 6| | 5180| 5180| 0| 15| 15| 13465| 3207| 855| 8579| 578| 760| 6| | 5200| 5200| 24| 15| 15| 570321| 2441| 10439| 555661| 1574| 949| 4| Note: QCC2072 and WCN7850 firmware does not support HTT stats type 76. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1 Signed-off-by: Harish Rachakonda <quic_rachakon@quicinc.com> Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Link: https://patch.msgid.link/20260326050641.3066562-1-roopni.devanathan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-07wifi: ath12k: Rename hw_link_id to radio_idx in ath12k_ah_to_ar()Roopni Devanathan1-5/+5
ath12k_ah_to_ar() is returning radio from the given hardware based on the radio index passed. But, the variable that radio index is received at is wrongly named 'hw_link_id', which points to the hardware link index that comes from the firmware. This affects readability. Resolve this by renaming 'hw_link_id' to 'radio_idx'. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260331045834.1181924-1-roopni.devanathan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-04-08ttm/pool: track allocated_pages per numa node.Dave Airlie1-15/+47
This gets the memory sizes from the nodes and stores the limit as 50% of those. I think eventually we should drop the limits once we have memcg aware shrinking, but this should be more NUMA friendly, and I think seems like what people would prefer to happen on NUMA aware systems. Cc: Christian Koenig <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-04-08ttm/pool: make pool shrinker NUMA aware (v2)Dave Airlie1-17/+21
This enable NUMA awareness for the shrinker on the ttm pools. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Dave Chinner <david@fromorbit.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-04-08ttm/pool: drop numa specific poolsDave Airlie1-11/+2
The list_lru will now handle numa for us, so no need to keep separate pool types for it. Just consolidate into the global ones. This adds a debugfs change to avoid dumping non-existant orders due to this change. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-04-08ttm/pool: port to list_lru. (v2)Dave Airlie3-45/+79
This is an initial port of the TTM pools for write combined and uncached pages to use the list_lru. This makes the pool's more NUMA aware and avoids needing separate NUMA pools (later commit enables this). Cc: Christian Koenig <christian.koenig@amd.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Dave Chinner <david@fromorbit.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-04-08drm/ttm: use gpu mm stats to track gpu memory allocations. (v4)Dave Airlie1-6/+15
This uses the newly introduced per-node gpu tracking stats, to track GPU memory allocated via TTM and reclaimable memory in the TTM page pools. These stats will be useful later for system information and later when mem cgroups are integrated. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: linux-mm@kvack.org Cc: Andrew Morton <akpm@linux-foundation.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-04-08mm: add gpu active/reclaim per-node stat counters (v2)Dave Airlie1-0/+5
While discussing memcg intergration with gpu memory allocations, it was pointed out that there was no numa/system counters for GPU memory allocations. With more integrated memory GPU server systems turning up, and more requirements for memory tracking it seems we should start closing the gap. Add two counters to track GPU per-node system memory allocations. The first is currently allocated to GPU objects, and the second is for memory that is stored in GPU page pools that can be reclaimed, by the shrinker. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: linux-mm@kvack.org Cc: Andrew Morton <akpm@linux-foundation.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-04-07drm/xe: Fix bug in idledly unit conversionVinay Belgaumkar1-2/+1
We only need to convert to picosecond units before writing to RING_IDLEDLY. Fixes: 7c53ff050ba8 ("drm/xe: Apply Wa_16023105232") Cc: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Acked-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patch.msgid.link/20260401012710.4165547-1-vinay.belgaumkar@intel.com (cherry picked from commit 13743bd628bc9d9a0e2fe53488b2891aedf7cc74) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-04-07cpufreq/amd-pstate: Add POWER_SUPPLY select for dynamic EPPMario Limonciello1-0/+1
The dynamic EPP feature uses power_supply_reg_notifier() and power_supply_unreg_notifier() but doesn't declare a dependency on POWER_SUPPLY, causing linker errors when POWER_SUPPLY is not enabled. Add POWER_SUPPLY to the selects. Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com> Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202604040742.ySEdkuAa-lkp@intel.com/ Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20260407194949.310114-1-mario.limonciello@amd.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-07PCI: Remove no_pci_devices()Heiner Kallweit1-17/+0
After having removed the last usage of no_pci_devices(), this function can be removed. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/b0ce592d-c34c-4e0b-b389-4e346b3a0c44@gmail.com
2026-04-07Input: pc110pad - remove driverDmitry Torokhov3-171/+0
Palm Top PC 110 is a handheld personal computer with 80486SX CPU that was released exclusively in Japan in September 1995. While the kernel still supports 486 CPU it is highly unlikely that anyone is using this device with the latest kernel. Remove the driver. [bhelgaas: since this was posted, "x86/cpu: Remove M486/M486SX/ELAN support" has been queued for v7.1, so pc110pad is no longer relevant: https://lore.kernel.org/all/20251214084710.3606385-2-mingo@kernel.org/] Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20240808172733.1194442-4-dmitry.torokhov@gmail.com