Charlene Liu [Mon, 27 Apr 2026 23:09:02 +0000 (19:09 -0400)]
drm/amd/display: Allow power up when PG disallowed in driver
[Why]
Do not exit early dcn42 pg control functions on power up for pipe PG
failsafe.
Reviewed-by: Leo Chen <leo.chen@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ray Wu [Mon, 4 May 2026 06:32:13 +0000 (14:32 +0800)]
drm/amd/display: Use lockdep_assert_held() for dc_lock check
[Why]
mutex_is_locked() only tells whether *some* task holds the mutex, not
the current one, so the existing ASSERT can silently pass when the
caller violates the contract.
[How]
Use the kernel's lockdep debugging utility (include/linux/lockdep.h)
and replace ASSERT(mutex_is_locked(&dm->dc_lock)) with
lockdep_assert_held(&dm->dc_lock), which checks the current task's
held-lock stack.
Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ray Wu [Thu, 30 Apr 2026 02:08:16 +0000 (10:08 +0800)]
drm/amd/display: Fix ISM dc_lock deadlock during suspend
[Why]
System hang observed during suspend/resume while video is playing.
amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM
delayed work via disable_delayed_work_sync(). The work handlers
themselves take dc_lock, producing an ABBA deadlock when a worker is
in flight at suspend time.
[How]
Split the disable path into two phases with opposite locking
contracts:
1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold
dc_lock.
2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM
back to FULL_POWER_RUNNING, must hold dc_lock.
Reviewed-by: Sun peng (Leo) Li <sunpeng.li@amd.com> Signed-off-by: Ray Wu <ray.wu@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Aric Cyr [Tue, 5 May 2026 20:49:47 +0000 (16:49 -0400)]
drm/amd/display: Enable additional wait for pipe pending checks
[why]
In cases where there are two FULL updates within the same display frame,
it's possible for some blocks to be programmed a second time without having
been latched completely from the first programming.
DCN 3.5 and up already work around this with additional validation checks
for frame count and defer as needed via fsleep.
[how]
Enabled existing pipe checks generically for all DCN versions to avoid HW
programming hazards.
Also removed redundant max_frame_count which can be determined by the
register mask and shift.
Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Aric Cyr <Aric.Cyr@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Aric Cyr [Tue, 5 May 2026 20:27:29 +0000 (16:27 -0400)]
drm/amd/display: Fix assertion due to disable/enable CM blocks
[why]
Some dc state transitions can result in CM blocks being disabled, then
re-enabled. The disable will set a defer bit, but re-enable will not
clear it. When optimizing later, an assert will be hit due to incorrect
expected HW state.
[how]
Clear defer bits if the block is re-enabled before optimization is
executed.
Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Signed-off-by: Aric Cyr <Aric.Cyr@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Refactor PSR functionality into dedicated power_psr module
[Why]
Extract all PSR (Panel Self Refresh) related functions from power.c
into a new power_psr.c module for better code organization and
maintainability.
[How]
Create new power_psr.c file containing all PSR-related functions
moved from power.c. Remove static qualifier from shared functions
to enable cross-file access:
- psr_context_to_mod_power_psr_context: Convert PSR context to
module power PSR context
- map_index_from_stream: Map stream to power entity index
- delay_two_frames: Wait for two frame periods
Add function declarations to header. Maintain forward declaration of struct
core_power for type compatibility.
Reviewed-by: Anthony Koo <anthony.koo@amd.com> Signed-off-by: Lohita Mudimela <lohita.mudimela@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
cifs.spnego key descriptions contain authority-bearing fields such as
pid, uid, creduid, and upcall_target that cifs.upcall treats as
kernel-originating inputs. However, userspace can also create keys of
this type through request_key(2) or add_key(2), allowing those fields to
be supplied without CIFS origin.
Only accept cifs.spnego descriptions while CIFS is using its private
spnego_cred to request the key.
Fixes: f1d662a7d5e5 ("[CIFS] Add upcall files for cifs to use spnego/kerberos") Assisted-by: avom-custom-harness:gpt-5.5-qwen3.6-mod-mix Reviewed-by: David Howells <dhowells@redhat.com> Signed-off-by: Asim Viladi Oglu Manizada <manizada@pm.me> Signed-off-by: Steve French <stfrench@microsoft.com>
drm/xe/multi_queue: Fix secondary queue error case
If xe_lrc_create() fails, the secondary queue added to the
multi-queue group list is not removed before freeing the
queue. Fix error path handling for secondary queues by
removing it from the multi-queue group list at the right
place.
Reported-by: Sebastian Österlund <sebastian.osterlund@intel.com> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7979 Fixes: d716a5088c88 ("drm/xe/multi_queue: Handle tearing down of a multi queue") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260518191639.320890-2-niranjana.vishwanathapura@intel.com
(cherry picked from commit d2d23c12789cf69eddc35b8d38cd8eaabd0168f1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Marius Hoch [Sun, 17 May 2026 19:23:40 +0000 (21:23 +0200)]
efi: sysfb_efi: Extend quirk to cover IdeaPad Duet 3 10IGL5-LTE
The LTE enabled version of the IdeaPad Duet 3 10IGL5 needs the
same quirk as the non-LTE version. As these are the only two
IdeaPad Duet 3 10IGL5 versions, we can safely use non exact matching.
Tested on a IdeaPad Duet 3 10IGL5-LTE.
Signed-off-by: Marius Hoch <mail@mariushoch.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Ard Biesheuvel [Tue, 19 May 2026 08:03:00 +0000 (10:03 +0200)]
efi: Allocate runtime workqueue before ACPI init
Since commit
5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")
ACPI PRM calls are delegated to a workqueue which runs in a kernel
thread, making it easier to detect and mitigate faulting memory accesses
performed by the firmware.
Rafael reports that such PRM accesses may occur before efisubsys_init()
executes, which is where the workqueue is allocated, leading to NULL
pointer dereferences. Since acpi_init() [which triggers the early PRM
accesses] executes as a subsys_initcall() as well, and has its own
dependencies that may be sensitive to initcall ordering, deferring
acpi_init() is not an option.
So instead, split off the workqueue allocation into its own postcore
initcall, as this is the only missing piece to allow EFI runtime calls
to be made. This ensures that EFI runtime call (including PRM calls) are
accessible to all code running at subsys_initcall() level.
Cc: <stable@vger.kernel.org> Fixes: 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers") Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
ASoC: soc-utils: Add missing va_end in snd_soc_ret()
The default case in snd_soc_ret() use va_start without va_end to
cleanup "args" object which can cause undefined behavior. So, add
missing va_end to cleanup "args" object.
This is reported by Coverity Scan as "Missing varargs init or cleanup".
Linus Torvalds [Tue, 19 May 2026 14:49:33 +0000 (07:49 -0700)]
Merge tag 'mm-hotfixes-stable-2026-05-18-21-07' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Pull misc fixes from Andrew Morton:
"14 hotfixes. 9 are for MM. 10 are cc:stable and the remainder are for
post-7.1 issues or aren't deemed suitable for backporting.
There's a two-patch MAINTAINERS series from Mike Rapoport which
updates us for the new KEXEC/KDUMP/crash/LUO/etc arrangements. And
another two-patch series from Muchun Song to fix a couple of
memory-hotplug issues. Otherwise singletons, please see the changelogs
for details"
* tag 'mm-hotfixes-stable-2026-05-18-21-07' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
mm/memory: fix spurious warning when unmapping device-private/exclusive pages
mm: fix __vm_normal_page() to handle missing support for pmd_special()/pud_special()
drivers/base/memory: fix memory block reference leak in poison accounting
mm/memory_hotplug: fix memory block reference leak on remove
lib: kunit_iov_iter: fix test fail on powerpc
mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
MAINTAINERS: add kexec@ list to LIVE UPDATE ENTRY
MAINTAINERS: add tree for KDUMP and KEXEC
selftests/mm: run_vmtests.sh: fix destructive tests invocation
scripts/gdb: slab: update field names of struct kmem_cache
scripts/gdb: mm: cast untyped symbols in x86_page_ops
mm/damon: fix damos_stat tracepoint format for sz_applied
mm/damon/sysfs-schemes: call missing mem_cgroup_iter_break()
mm/migrate_device: fix spinlock leak in migrate_vma_insert_huge_pmd_page
x86/vdso: Fix incorrect size in munmap() on map_vdso() failure
In map_vdso(), if a failure occurs during the installation of the VVAR
mappings, the error path attempts to clean up previously allocated mappings
using do_munmap(). However, the cleanup for the VVAR mapping is incorrectly
using image->size (the size of the vDSO text) instead of the actual size
allocated for the VVAR area.
Replace the incorrect do_munmap() image->size parameter with the constant
VDSO_NR_PAGES * PAGE_SIZE. Ensure the unmap size exactly matches the size
used during the vdso_install_vvar_mapping() phase to provide a symmetrical
and complete teardown of the memory region.
Fixes: e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping") Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260503191609.551817-1-trintaeoitogc@gmail.com
When pwrctrl integration was added, the error message for
pci_pwrctrl_create_devices() failure was incorrectly added after the goto
statement, causing it to be skipped.
Move the goto statement after the dev_err_probe() call so that the
error message actually gets printed (or saved if probe is deferred).
Fixes: 1a152e21940a ("PCI: mediatek-gen3: Integrate new pwrctrl API") Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/all/adjNaKB5KGpl6qIp@stanley.mountain/ Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260512103347.1751080-1-wenst@chromium.org
Dan Carpenter [Tue, 12 May 2026 10:17:55 +0000 (13:17 +0300)]
PCI: dwc: Fix signedness bug in fault injection test code
The kstrtou32() function returns negative error code or zero on success.
However, in this case "val" is a u32 and the function returns signed long,
so negative error codes from kstrtou32() are returned as high positive
values.
Store the error code in an int instead.
Fixes: d20ee8e2dbd6 ("PCI: dwc: Add debugfs based Error Injection support for DWC") Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/agL-Uwfn26SI4Gb0@stanley.mountain
PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency
Program the Synopsys DesignWare PORT_AFR L1 entrance latency field from the
optional aspm-l1-entry-delay-ns device tree property (nanoseconds).
Convert delay to whole microseconds with ceiling division (DIV_ROUND_UP),
then derive the 3-bit hw encoding as the minimum of order_base_2(us) and 7.
If the property is not present or cannot be read, default to 7.
+--------------------------+----------+
| Advertised maximum | Code |
+--------------------------+----------+
| Maximum of 1 us | 000b |
+--------------------------+----------+
| Maximum of 2 us | 001b |
+--------------------------+----------+
| Maximum of 4 us | 010b |
+--------------------------+----------+
| Maximum of 8 us | 011b |
+--------------------------+----------+
| Maximum of 16 us | 100b |
+--------------------------+----------+
| Maximum of 32 us | 101b |
+--------------------------+----------+
| Maximum of 64 us | 110b |
+--------------------------+----------+
| Rest | 111b |
+--------------------------+----------+
Ahmed Yaseen [Sun, 17 May 2026 18:30:11 +0000 (18:30 +0000)]
platform/x86: asus-armoury: fix mini-LED mode get/set on MODE2 devices
The mini-LED current_value attribute does not work on devices that use
ASUS_WMI_DEVID_MINI_LED_MODE2 (2024 and newer models).
Reading is broken: mini_led_mode_current_value_show() fetches the mode
from the device but then decodes a literal 0 instead of the value it
just read:
mode = FIELD_GET(ASUS_MINI_LED_MODE_MASK, 0);
So mode is always 0, and the attribute always reports the same thing
regardless of the real hardware state.
Writing is broken too. The number a user writes is an index; the value
the firmware actually wants is looked up from that index in
mini_led_mode_map[]. mini_led_mode_current_value_store() skips that
lookup and passes the raw index straight to armoury_attr_uint_store().
On 2024 devices the firmware numbers its modes differently from the
index, so some writes are rejected with -EINVAL and the rest send the
wrong mode to the hardware.
Fix both paths: decode the value actually read from the device when
reading, and look up the firmware value before sending it when
writing. Older (MODE1) devices were unaffected because there the index
and the firmware value are the same.
Fixes: f99eb098090e ("platform/x86: asus-armoury: move existing tunings to asus-armoury module") Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260517182957.11069-1-yaseen@ghoul.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Nicolin Chen [Sun, 3 May 2026 13:54:12 +0000 (06:54 -0700)]
iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits
HTTU is introduced by utilizing the Dirty Bit Modifier (DBM) in the PTE.
When kernel maps a clean but writable page, it will set PTE_READONLY and
PTE_DBM (aka PTE_WRITE) at the same time. When a write occurs, an HTTU-
capable MMU will automatically clear the PTE_RDONLY bit without software
intervention.
On the other hand, SMMU has the same HTTU feature, yet it is not enabled
in the SVA CD. As a result, SMMU will not clear the PTE_RDONLY bit while
sharing the CPU page table, resulting in unnecessary stalls.
Thus, enable CTXDESC_CD_0_TCR_HA and CTXDESC_CD_0_TCR_HD in the SVA CD.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
Jason Gunthorpe [Wed, 13 May 2026 23:57:48 +0000 (20:57 -0300)]
iommu/arm-smmu-v3: Directly encode TLBI commands
TLBI is more complicated than all the other commands because the
invalidation loop builds a template command from the struct
arm_smmu_inv which is then expanded into many TLBI commands for the
invalidation.
Add a new command make function and convert all the places using
ATC_INV.
Split out full invalidation to directly make the cmd instead of
overloading size=0 to mean full invalidation.
In section "3.9.1 ATS Interface" of F.b the specification says:
When the SMMU returns an ATS Translation Completion for a request that
had a PASID, the Global bit of the Translation Completion Data Entry
must be zero.
Even though it faithfully forwards the G bit through to the ATS
invalidation command there is no way to create G mappings so there is
never any need to send a G invalidation. Thus don't expose global in the
new helpers and leave CMDQ_ATC_0_GLOBAL unused.
Convert all of these call sites to use the make function instead of
going through arm_smmu_cmdq_build_cmd(). Use a #define so the general
pattern is always:
Jason Gunthorpe [Wed, 13 May 2026 23:57:43 +0000 (20:57 -0300)]
iommu/arm-smmu-v3: Convert arm_smmu_cmdq_batch cmds to struct arm_smmu_cmd
Convert the batch's type to also get the remaining helper functions to
use the new type and complete replacing naked u64s with the new struct.
The low-level queue_write()/queue_read()/queue_remove_raw() functions
remain u64-based since they are shared by event and PRI queues which
have different entry sizes.
Jason Gunthorpe [Wed, 13 May 2026 23:57:42 +0000 (20:57 -0300)]
iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq submission functions
Continue removing struct arm_smmu_cmdq_ent in favour of the HW based
struct arm_smmu_cmd. Switch the lower level issue commands to work on
the native struct by lifting arm_smmu_cmdq_build_cmd() into all the
callers.
Following patches will revise each of the arm_smmu_cmdq_build_cmd()
call sites to replace it with the HW struct.
Jason Gunthorpe [Wed, 13 May 2026 23:57:41 +0000 (20:57 -0300)]
iommu/arm-smmu-v3: Use the HW arm_smmu_cmd in cmdq selection functions
Start removing the use of struct arm_smmu_cmdq_ent, starting at the
lower levels of the call chain. Change the functions that determine what
cmdq to issue the batch to into using struct arm_smmu_cmd directly.
Jason Gunthorpe [Wed, 13 May 2026 23:57:40 +0000 (20:57 -0300)]
iommu/arm-smmu-v3: Add struct arm_smmu_cmd to represent the HW format command
Like STE/CD, add a wrapper struct around the u64 array to represent the
already FIELD_PREP'd command data. Unlike the STE/CD this is a u64
because the command submission path will have the swap to le64.
This makes the API clearer when a u64 is referring to a formatted
command and makes the following changes easier to follow.
Move the command constants out of the struct and into an enum alongside
the rest of the constants defining the HW format so the entire HW format
is self contained and independent of struct arm_smmu_cmdq_ent.
Lukas Wunner [Thu, 14 May 2026 05:40:42 +0000 (07:40 +0200)]
platform/x86/intel/vsec: Fix enable_cnt imbalance on PCIe error recovery
After a PCIe Uncorrectable Error has been reported by a device with
Intel Vendor Specific Extended Capabilities and has been recovered
through a Secondary Bus Reset, its driver calls intel_vsec_pci_probe()
to rescan and reinitialize VSECs.
intel_vsec_pci_probe() invokes pcim_enable_device() and thereby adds
another devm action which calls pcim_disable_device() on driver unbind.
So once the driver unbinds, pcim_disable_device() will be called as many
times as an Uncorrectable Error occurred, plus one. This will lead to
an enable_cnt imbalance on driver unbind.
Additionally, since commit dc957ab6aa05 ("platform/x86/intel/vsec: Add
private data for per-device data"), a devm_kzalloc() allocation is
leaked on every Uncorrectable Error.
Avoid by splitting the VSEC rescan out of intel_vsec_pci_probe() into a
separate helper and calling that on PCIe error recovery.
Fixes: 936874b77dd0 ("platform/x86/intel/vsec: Add PCI error recovery support to Intel PMT") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v6.0+ Link: https://patch.msgid.link/bd594d09fa866dc51dddc9a447c3b23f9b1402cc.1778736835.git.lukas@wunner.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
ASoC: cs35l56: Use standard SoundWire regmap implementation
Use the regmap_sdw implementation for SoundWire instead of
re-implementing the low-level bus transactions in cs35l56-sdw.c
The cs35l56 registers are big-endian on I2C and SPI but little-endian
over SoundWire. The firmware files are all big-endian and contain opaque
blobs in big-endian order. So these must be endian-swapped to transfer
over SoundWire. A custom regmap bus implementation is used to do this
endian-swapping.
The original implementation of this custom regmap bus was a complete bus
backend, performing the endian swapping and low-level SoundWire bus
read/write.
This commit changes the custom regmap bus to only perform the endian-swap.
It uses an underlying simple uncached regmap_sdw bus to deal with
transferring the 32-bit registers over the SoundWire bus. Although this
adds a small amount of overhead, from passing through the regmap APIs
twice, it avoids having a local duplicate implementation of what regmap_sdw
already does.
The slow-read handling for OTP registers must access 8-bit SoundWire
registers so it still uses low-level SoundWire bus reads.
ASoC: cs35l56: Use reg_base to offset addresses on SoundWire
Set the reg_base member of regmap_config for SoundWire so that
the regmap core will apply the 0x8000 offset to addresses, instead
of doing it within our low-level regmap read/write callbacks.
ASoC: cs35l56-shared-test: Subtract reg_base offset in dummy regmap
Subtract the value of cs35l56 regmap_config->reg_base from addresses
passed into the mock regmap bus.
Chip register addresses transferred over SoundWire are offset by 0x8000
to move them after the address range reserved in the SoundWire spec.
This commit prepares for changing the cs35l56-sdw driver to use
regmap_config->reg_base to add this offset. When that is done the
addresses passed into the mock regmap_bus will include this offset.
Vladimir Murzin [Fri, 15 May 2026 13:37:29 +0000 (14:37 +0100)]
arm64: probes: Handle probes on hinted conditional branch instructions
BC.cond instructions introduced by FEAT_HBC cannot be executed
out-of-line, like other branch instructions. However, they can be
simulated in the same way as B.cond instructions.
Extend the B.cond decoder mask to match BC.cond instructions as well,
and handle them using the existing B.cond simulation path.
Fixes: 7f86d128e437 ("arm64: add HWCAP for FEAT_HBC (hinted conditional branches)") Cc: <stable@vger.kernel.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Armin Wolf [Tue, 12 May 2026 23:21:41 +0000 (01:21 +0200)]
platform/x86: uniwill-laptop: Do not enable the charging limit even when forced
It seems that on some older models (~2020) the battery charging limit
can permanently damage the battery. Prevent users from enabling this
feature thru the "force" module parameter to avoid causing permanent
hardware damage on such devices.
Armin Wolf [Tue, 12 May 2026 23:21:40 +0000 (01:21 +0200)]
platform/x86: uniwill-laptop: Fix behavior of "force" module param
Users might want to force-enable all possible features even on
machines with a valid device descriptor. Until now the "force"
module param was ignored on such machines. Fix this to make
it easier to test for support of new features.
Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260512232145.329260-4-W_Armin@gmx.de Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Armin Wolf [Tue, 12 May 2026 23:21:39 +0000 (01:21 +0200)]
platform/x86: uniwill-laptop: Accept charging threshold of 0
The power supply sysfs ABI states that:
Not all hardware is capable of setting this to an arbitrary
percentage. Drivers will round written values to the nearest
supported value. Reading back the value will show the actual
threshold set by the driver.
The driver currently violates this ABI by rejecting a charging
threshold of 0. Fix this by clamping this value to 1.
Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260512232145.329260-3-W_Armin@gmx.de Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The EC might initialize the charge threshold with 0 to signal that
said threshold is uninitialized. Detect this and replace said value
with 100 to signal the EC that we want to take control of battery
charging. Also set the threshold to 100 if the EC-provided value
is invalid.
Fixes: d050479693bb ("platform/x86: Add Uniwill laptop driver") Reviewed-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260512232145.329260-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
surfacepro3_button driver.
Fixes: d913a5a12b40 ("platform/surface: surfacepro3_button: Convert to a platform driver") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Chen Yu <yu.c.chen@intel.com> Link: https://patch.msgid.link/23119222.EfDdHjke4D@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: intel-vbtn: Check ACPI_HANDLE() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the
platform/x86 intel-vbtn driver.
Fixes: 26173179fae1 ("platform/x86: intel-vbtn: Eval VBDL after registering our notifier") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/3426431.aeNJFYEL58@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: intel_sar: Check ACPI_HANDLE() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the
platform/x86 intel_sar driver.
Fixes: dcfbd31ef4bc ("platform/x86: BIOS SAR driver for Intel M.2 Modem") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/14023870.uLZWGnKmhe@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: intel-hid: Check ACPI_HANDLE() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the
platform/x86 intel-hid driver.
Fixes: ecc83e52b28c ("intel-hid: new hid event driver for hotkeys") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/1971512.tdWV9SEqCh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: hp_accel: Check ACPI_COMPANION() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_COMPANION() check against NULL to the
platform/x86 hp_accel driver.
Fixes: 8ebcb6c94c71 ("platform/x86: hp_accel: Convert to be a platform driver") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2425918.ElGaqSPkdT@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
platform/x86: adv_swbutton: Check ACPI_HANDLE() against NULL
Every platform driver can be forced to match a device that doesn't match
its list of device IDs because of device_match_driver_override(), so
platform drivers that rely on the existence of a device's ACPI companion
object need to verify its presence.
Accordingly, add a requisite ACPI_HANDLE() check against NULL to the
platform/x86 adv_swbutton driver.
Fixes: 3d904005f686 ("platform/x86: add support for Advantech software defined button") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/5115425.31r3eYUQgx@rafael.j.wysocki Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
hp-wmi: fix support for thermal profile Omen 16-с0xxx laptops
The HP Omen 16-c0xxx (board ID: 8902) has the same WMI interface as
other Victus S boards, but requires additional quirks for correctly
switching thermal profile.
Add the DMI board name to victus_s_thermal_profile_boards[] table and
map it to the omen_v1_legacy_thermal_params quirk.
Testing on board 8902 confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.
Signed-off-by: Konenko Andrey Viktorovich <admin@aquinas.su> Link: https://patch.msgid.link/T3DTKbKwQzOgk_0eUG-kMg@aquinas.su Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Heechan Kang [Sun, 17 May 2026 06:22:32 +0000 (15:22 +0900)]
fwctl: pds: Validate RPC input size before parsing
The fwctl core allocates the device-specific RPC input buffer with
fwctl_rpc.in_len and passes that buffer to the driver callback.
pdsfc_fw_rpc() casts the buffer to struct fwctl_rpc_pds and then calls
pdsfc_validate_rpc(), which reads fields from that structure before
checking that the input buffer is large enough to contain it. A short
in_len can make pds_fwctl read beyond the allocation.
Reject pds RPC buffers that are smaller than struct fwctl_rpc_pds before
parsing any pds-specific fields.
Fixes: 92c66ee829b9 ("pds_fwctl: add rpc and query support") Link: https://patch.msgid.link/r/20260517062232.1858747-1-gganji11@naver.com Cc: stable@vger.kernel.org # v6.15+ Signed-off-by: Heechan Kang <gganji11@naver.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Paolo Abeni [Tue, 19 May 2026 13:36:38 +0000 (15:36 +0200)]
Merge branch 'mptcp-misc-fixes-for-v7-1-rc4'
Matthieu Baerts says:
====================
mptcp: misc fixes for v7.1-rc4
Here are various unrelated fixes:
- Patch 1: avoid dropping partial packets. A previous version has been
sent a few week ago. A fix for 5.10.
- Patches 2-3: stop ADD_ADDR timer when an ADD_ADDR can never been sent
due to insufficient option space. A fix for v5.10.
- Patch 4: reset rcv_wnd_sent on disconnect, just in case the next
connection falls back to TCP. A fix for 5.17.
- Patch 5: update window_clamp when SO_RCVBUF is set during the
connection. A fix similar to a recent one on TCP side, for v6.6.
- Patch 6: avoid wrong time being displayed in the selftests when using
uutils 0.8.0 which contains a regression with 'date +%3N'. It doesn't
fix an issue in the kernel selftests, but having the fix is helpful
for those using uutils 0.8.0.
selftests: mptcp: drop nanoseconds width specifier
Using the format specifier +%s%3N with GNU date is honoured, and only
prints 3 digits of the nanoseconds portion of the seconds since epoch,
which corresponds to the milliseconds.
The uutils implementation of date currently does not honour this, and
always prints all 9 digits. This is a known issue [1], but can be worked
around by adapting this test to use nanoseconds instead of microseconds,
and then divide it by 1e6.
This fix is similar to what has been done on systemd side [2], and it is
needed to run the selftests on Ubuntu 26.04, containing uutils 0.8.0.
Note that the Fixes tag is there even if this patch doesn't fix an issue
in the kernel selftests, but it is useful for those using uutils 0.8.0.
Gang Yan [Fri, 15 May 2026 04:27:36 +0000 (06:27 +0200)]
mptcp: update window_clamp on subflows when SO_RCVBUF is set
Add __mptcp_subflow_set_rcvbuf() helper to write the subflow sk_rcvbuf,
but also to call the recently added tcp_set_rcvbuf() helper to update
window_clamp. This is needed because the window clap is updated when
scaling_ratio changes, in tcp_measure_rcv_mss(). Until scaling_ratio
changes, the subflow is stuck with the old window clamp which may be
based on a small initial buffer.
Use this new helper in both mptcp_sol_socket_sync_intval() (setsockopt
path) and sync_socket_options() (new subflow creation path).
Note that this patch depends on commit b025461303d8 ("tcp: update
window_clamp when SO_RCVBUF is set"): it fixes the issue on TCP side,
but the same fix is needed on MPTCP side as well.
Paolo Abeni [Fri, 15 May 2026 04:27:35 +0000 (06:27 +0200)]
mptcp: reset rcv wnd on disconnect
If the MPTCP socket fallback to TCP before the MP handshake completion,
the IASN remain 0, and the rcv_wnd_sent field is not explicitly
initialized, just incremented over time with the data transfer.
At disconnect time such value is not cleared. If the next connection falls
back to TCP before the MP handshake completion, the data transfer will
keep incrementing the receive window end sequence starting from the last
value used in the previous connection: the announced window will be
unrelated from the actual receiver buffer size and likely too big.
Address the issue zeroing the field at disconnect time.
Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-4-701e96419f2f@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Li Xiasong [Fri, 15 May 2026 04:27:33 +0000 (06:27 +0200)]
mptcp: pm: fix ADD_ADDR timer infinite retry on option space insufficient
When TCP option space is insufficient (e.g., when sending ADD_ADDR with an
IPv6 address and port while tcp_timestamps is enabled), the original code
jumped to out_unlock without clearing the addr_signal flag. This caused
mptcp_pm_add_timer to keep rescheduling indefinitely, not sending ADD_ADDR,
preventing subsequent addresses in the endpoint list from being announced.
Handle this case by clearing the ADD_ADDR signal and skipping the matching
ADD_ADDR retransmission entry. The skip path cancels the matching timer
(with id check) and advances PM state progression, preserving forward
progress to subsequent PM work.
This cancellation is inherently best-effort. A concurrent add_timer
callback may already be running and may acquire pm.lock before the
cancel path updates entry state. In that case, one final ADD_ADDR
transmit attempt can still be executed.
Once the cancel path sets entry->retrans_times to ADD_ADDR_RETRANS_MAX,
the callback-side retrans_times check suppresses further ADD_ADDR
retransmissions.
Note that when an ADD_ADDR is being prepared, a pure-ACK is queued. On
the output side, it means that it is fine to skip non-pure-ACK packets,
when drop_other_suboptions is set: a pure-ACK will be processed soon
after.
Fixes: 00cfd77b9063 ("mptcp: retransmit ADD_ADDR when timeout") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong <lixiasong1@huawei.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260515-net-mptcp-misc-fixes-7-1-rc4-v2-2-701e96419f2f@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Shardul Bankar [Fri, 15 May 2026 04:27:32 +0000 (06:27 +0200)]
mptcp: do not drop partial packets
When a packet arrives with map_seq < ack_seq < end_seq, the beginning
of the packet has already been acknowledged but the end contains new
data. Currently the entire packet is dropped as "old data," forcing
the sender to retransmit.
Instead, skip the already-acked bytes by adjusting the skb offset and
enqueue only the new portion. Update bytes_received and ack_seq to
reflect the new data consumed.
A previous attempt at this fix has been sent by Paolo Abeni [1], but had
issues [2]: it also added a zero-window check and changed rcv_wnd_sent
initialization, which caused test regressions. This version addresses
only the partial packet handling without modifying receive window
accounting.
DURATION_INV_N3 is computed from BIT_ULL(31 + prescalar) divided
by the configured duration, and then written as a 32-bit RAM value.
Durations of 32 samples or less overflow that value, so reject them
and advertise the valid range through the fade duration control.
Validate the ALSA integer control value as a long before storing it in
the driver's u32 duration field. Use a u32 temporary for duration RAM
writes because the largest valid inverse value can still exceed INT_MAX.
Oliver White [Thu, 9 Apr 2026 03:43:47 +0000 (15:43 +1200)]
platform/surface: aggregator_registry: omit battery & AC nodes on Surface Laptop 7
Surface Laptop 7 exposes battery and AC status via Qualcomm PMIC GLINK
qcom_battmgr. Registering the standard SSAM battery and AC client
devices on this platform causes duplicate power-supply devices to
appear.
Drop the SSAM battery and AC nodes from the Surface Laptop 7 registry
group so that only the qcom_battmgr power supplies are instantiated.
Fixes: b27622f13172 ("platform/surface: Add OF support") Signed-off-by: Oliver White <oliverjwhite07@gmail.com> Link: https://patch.msgid.link/20260409034347.17381-1-oliverjwhite07@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Jie Gan [Mon, 11 May 2026 04:19:18 +0000 (12:19 +0800)]
coresight: platform: defer connection counter increment until alloc succeeds
coresight_add_out_conn() increments nr_outconns before calling
devm_krealloc_array() and again before devm_kmalloc(). If either
allocation fails, the counter is already bumped while the corresponding
array entry is NULL or uninitialized garbage.
coresight_add_in_conn() has the same problem with nr_inconns and
devm_krealloc_array().
In both cases the probe returns -ENOMEM, which causes
coresight_get_platform_data() to call coresight_release_platform_data()
for cleanup. That function iterates up to nr_outconns (or nr_inconns)
entries and dereferences each pointer unconditionally, hitting the NULL
or garbage entry and panicking instead of failing gracefully.
Fix by moving the counter increments to after all allocations succeed,
so the struct is always consistent on any error path.
Fixes: 3d4ff657e454 ("coresight: Dynamically add connections") Fixes: e3f4e68797a9 ("coresight: Store in-connections as well as out-connections") Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: James Clark <james.clark@linaro.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Link: https://lore.kernel.org/r/20260511-fix-ref-count-issue-v1-1-99d647810d3c@oss.qualcomm.com
dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
Many of SMMU on Qualcomm SoCs come in two flavors using the same front
compatible but a bit different fallback:
1. For application processor, usually without any controllable
clocks,
2. For the Adreno GPU, with some controllable clock(s) and using
additionally qcom,adreno-smmu fallback compatible.
Add missing constraints for Glymur SMMU on Adreno GPU and several other
Qualcomm SMMUs for application processors, to restrict the clocks
property to a specific length.
Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
Chenguang Zhao [Fri, 15 May 2026 03:25:50 +0000 (11:25 +0800)]
net/ethtool: drop duplicate TSCONFIG HWTSTAMP BUILD_BUG_ON from SET handler
BUILD_BUG_ON() is evaluated at compile time. The same three checks
for __HWTSTAMP_TX_CNT, __HWTSTAMP_FILTER_CNT and __HWTSTAMP_FLAG_CNT
are already present earlier in this file (tsconfig_reply_size()).
Repeating them at the start of ethnl_set_tsconfig() does not
strengthen the guarantee; remove the redundant block there and
keep a single occurrence.
Add tracepoints to the Qualcomm GENI (Generic Interface) SPI driver.
These trace events enable runtime debugging and performance analysis
of SPI operations.
The trace events capture SPI clock configuration, setup parameters,
transfer details, interrupt status.
Praveen Talari [Mon, 18 May 2026 17:00:52 +0000 (22:30 +0530)]
spi: qcom-geni: Add trace events for Qualcomm GENI SPI driver
Add tracepoints to the Qualcomm GENI (Generic Interface) SPI driver.
These trace events enable runtime debugging and performance analysis
of SPI operations.
The trace events capture SPI clock configuration, setup parameters,
transfer details, interrupt status.
Praveen Talari [Mon, 18 May 2026 17:00:51 +0000 (22:30 +0530)]
spi: qcom-geni: trace: Add trace events for Qualcomm GENI SPI
Add tracepoint support to the Qualcomm GENI SPI driver to provide
runtime visibility into driver behavior without requiring invasive debug
patches.
The trace events cover clock and setup parameter configuration,
transfer metadata, interrupt status to be making it easier to diagnose
communication issues in the field..
Mark Brown [Mon, 18 May 2026 15:07:29 +0000 (16:07 +0100)]
arm64/cpufeature: Define hwcaps for 2025 dpISA features
The features added by the 2025 dpISA are all straightforward instruction
only features so there is no state to manage, we can just expose hwcaps to
let userspace know they are available.
F16MM is slightly odd in that the feature is FEAT_F16MM but it is discovered
via ID_AA64FPFR0_EL1.F16MM2. We follow the feature name.
Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
Michał Grzelak [Thu, 16 Apr 2026 16:37:44 +0000 (18:37 +0200)]
drm/i915/aux: use polling when irqs are unavailable
PTL with physically disconnected display was observed to have 40s longer
execution time when testing xe_fault_injection@xe_guc_mmio_send_recv.
The issue has not been seen when reverting commit 40a9f77a28fa ("Revert
"drm/i915/dp: change aux_ctl reg read to polling read"").
Apparently the configuration suffers from not having AUX enabled when
using interrupts. One probable cause can be xe enabling interrupts too
late: interrupts need memory allocations which currently can't be done
before the display FB takeover is done.
As for now, use polling for AUX in case interrupts are unavailable.
Fixes: 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read"") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260416163744.288107-1-michal.grzelak@intel.com
Mika Westerberg [Tue, 12 Aug 2025 10:56:30 +0000 (13:56 +0300)]
thunderbolt: Add support for USB4STREAM
Introduce USB4STREAM protocol and Linux implementation. This allows two
(or more) hosts to transfer data directly over Thunderbolt/USB4 cable
through a character device without need to go through the network stack.
Any application that supports read(2) and write(2) in some form should
be able to use the device without changes. The data is sent out to the
other side over a tunnel inside Thunderbolt/USB4 fabric. The character
device is called /dev/tbstreamX where X is the minor number starting
from 0.
All stream devices need to be configured first. This is done through
ConfigFS interface. There can be multiple streams at the same time (this
depends on number of DMA rings and available HopIDs) and a single stream
supports traffic in both directions. For example there could be an
application that uses one stream as control channel and another one as
bi-directional data channel.
A real use-case for this is to take a backup as a part of recovery
initramfs tooling (no need to setup networking or have ssh or similar
tooling as part of the initramfs). Say we want to backup the disk of
host1 to host2. First Thunderbolt/USB4 cable is connected between the
hosts (there can be devices in the middle too) then the receiving side
configures the stream:
We use automatic HopID allocation (writing -1 to HopIDs) for simplicity.
From this point forward the /dev/tbstream0 can be used pretty much as
regular file:
Here we take advantage of the fact that host2 also announces the active
streams through XDomain properties so the name "backup" gives us the
HopIDs. It is also possible to configure them manually in the same way
we did for host2.
Then it is just a matter of copying the data over:
Once the streams are no longer needed they can be removed:
host1 # cd /sys/kernel/config/thunderbolt/stream/
host1 # rmdir -p 0-503.0/backup
host2 # cd /sys/kernel/config/thunderbolt/stream
host2 # rmdir -p 0-1.0/backup
Co-developed-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Tue, 12 Aug 2025 10:53:49 +0000 (13:53 +0300)]
thunderbolt: Add support for ConfigFS
This adds ConfigFS support to USB4/Thunderbolt bus. By itself this just
creates the subsystem but it exposes functions that can be used to
register groups under it.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Mika Westerberg [Tue, 23 Sep 2025 09:51:27 +0000 (12:51 +0300)]
thunderbolt: Allow service drivers to specify their own properties
The XDomain properties can be useful for service drivers, for example to
implement a registry for the services they expose. So far there has been
no need for service drivers to specify these but with the USB4STREAM
driver that we are going to use them.
This adds remote and local side properties that the service drivers have
access to. Remote side is read-only but the local side can be changed by
a service driver. Also provide a mechanism to notify the remote side
that there are changes.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Akhil P Oommen [Tue, 12 May 2026 19:21:20 +0000 (00:51 +0530)]
dt-bindings: arm-smmu: Update the description for Glymur GPU SMMU
Add the interconnects property to the common SMMU properties and extend
the sm8750 clock description section to also cover Glymur since it uses
the same single "hlos" vote clock.
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
Zeng Heng [Fri, 8 May 2026 16:23:41 +0000 (17:23 +0100)]
arm_mpam: Update architecture version check for MPAM MSC
In addition to updating the CPU MPAM version check, the MPAM MSC version
check also need to be updated. mpam_msc_check_aidr() is added to check
the MSC AIDR register, ensuring that both the major and minor version
numbers fall within the supported range of the MPAM architecture version.
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
[ morse: changed mpam_msc_check_aidr() to accept versions like v1.2 ] Signed-off-by: James Morse <james.morse@arm.com> Reviewed-by: Ben Horgan <ben.horgan@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
Zeng Heng [Fri, 8 May 2026 16:23:40 +0000 (17:23 +0100)]
arm64: cpufeature: Add support for the MPAM v0.1 architecture version
According to the MPAM spec [1], the supported architecture versions are
v1.0, v1.1 and v0.1. MPAM versions v0.1 and v1.1 are functionally
identical, but v0.1 additionally supports the FORCE_NS feature.
ID_AA64PR | ID_AA64PR | MPAM Extension | Notes
F0_EL1. | F1_EL1. | Architecture |
MPAM | MPAM_frac | version |
---------------------------------------------------------------------------
0b0000 | 0b0001 | v0.1 | MPAM v0.1 is implemented.
| | | MPAM v0.1 is the same as MPAM v1.1
| | | with FORCE_NS which is
| | | incompatible with MPAM v1.0.
---------------------------------------------------------------------------
0b0001 | 0b0000 | v1.0 | MPAM v1.0 is implemented.
---------------------------------------------------------------------------
0b0001 | 0b0001 | v1.1 | MPAM v1.1 is implemented.
| | | MPAM v1.1 includes all features of
| | | MPAM v1.0.
| | | It must not include FORCE_NS.
FORCE_NS is a feature that operates in EL3 mode. Consequently, the current
Linux MPAM driver is also compatible with MPAM v0.1. To support v0.1, the
existing driver which only checks ID_AA64PFR0_EL1.MPAM for the major
version needs to examine ID_AA64PFR1_EL1.MPAM_frac for the minor version
as well.
In particular, the address of a label is only expected to be used with a
computed goto.
While the generic version more or less works today, it is known to be
brittle and may break with current and future optimizations. For
example, Clang -O2 always returns 1 when this function is inlined:
Fix it by overriding _THIS_IP_ in <asm/linkage.h> (which is included by
<linux/instruction_pointer.h>) using an architecture-specific inline asm
version. Additionally, avoiding taking the address of a label prevents
compilers from emitting spurious indirect branch targets (e.g. ENDBR or
BTI) under control-flow integrity schemes.
Pierre Barre [Tue, 12 May 2026 13:20:32 +0000 (13:20 +0000)]
9p: invalidate readdir buffer on seek
The per-fid readdir buffer (fid->rdir) is populated lazily and only
refilled when fully drained (rdir->head == rdir->tail). userspace
lseek() on a directory fd updates file->f_pos via generic_file_llseek()
but does not touch the cached buffer, so the next getdents() iterates
the stale cache and emits entries from the previous position instead
of the one the caller asked for.
Track the file position the cached data corresponds to in
struct p9_rdir, and drop the cache on entry to iterate_shared when it
no longer matches ctx->pos. The 9p protocol's Tread/Treaddir already
take an arbitrary offset on every request, so a refill at the new
position is always legal; no .llseek override or seek restriction is
needed.
Pierre Barre [Tue, 12 May 2026 13:20:31 +0000 (13:20 +0000)]
9p: use kvzalloc for readdir buffer
The readdir buffer is sized to msize, so kzalloc() can fail under
fragmentation with a page allocation failure in v9fs_alloc_rdir_buf()
/ v9fs_dir_readdir_dotl().
The buffer is only a response sink and is never pack_sg_list()'d,
so kvzalloc() is safe for all transports, unlike the fcall buffers
fixed in e21d451a82f3 ("9p: Use kvmalloc for message buffers on
supported transports").
Signed-off-by: Pierre Barre <pierre@barre.sh>
Message-ID: <20260512132032.369281-1-pierre@barre.sh> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
'struct configfs_item_operations' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
25167 9336 256 34759 87c7 net/9p/trans_usbg.o
After:
=====
text data bss dec hex filename
25231 9272 256 34759 87c7 net/9p/trans_usbg.o
dt-bindings: arm-smmu: qcom: Add compatible for Qualcomm Shikra SoC
Qualcomm Shikra SoC includes an apps SMMU that implements arm,mmu-500,
which is used to translate device-visible virtual addresses to physical
addresses. Add compatible for it.
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
Paolo Abeni [Tue, 19 May 2026 11:51:08 +0000 (13:51 +0200)]
Merge tag 'ovpn-net-20260514' of https://github.com/OpenVPN/ovpn-net-next
Antonio Quartulli says:
====================
Included fixes:
* fix TCP selftest failures by reducing number of attempted pings
* fix RCU ptr deref outside of RCU read section
* fix UAF in case of TCP peer failed to be added to hashtable
* fix race condition between iface teardown and new peer being added
* ensure dstats are updated with BH disabled to avoid concurrency
* tag 'ovpn-net-20260514' of https://github.com/OpenVPN/ovpn-net-next:
ovpn: disable BHs when updating device stats
ovpn: fix race between deleting interface and adding new peer
ovpn: respect peer refcount in CMD_NEW_PEER error path
ovpn: tcp - use cached peer pointer in ovpn_tcp_close()
selftests: ovpn: reduce remaining ping flood counts
====================
Arnd Bergmann [Fri, 15 May 2026 09:12:06 +0000 (11:12 +0200)]
media: platform: amd: add DRM_AMDGPU dependency
With DRM_AMDGPU=m and DRM_AMD_ISP=y, it is possible to configura
VIDEO_AMD_ISP4_CAPTURE as built-in, but that fails to link:
aarch64-linux-ld: drivers/media/platform/amd/isp4/isp4_interface.o: in function `isp4if_gpu_mem_alloc.isra.0':
isp4_interface.c:(.text+0x1d0): undefined reference to `isp_kernel_buffer_alloc'
aarch64-linux-ld: drivers/media/platform/amd/isp4/isp4_interface.o: in function `isp4if_dealloc_fw_gpumem':
isp4_interface.c:(.text+0x26c): undefined reference to `isp_kernel_buffer_free'
Add a dependency on the tristate DRM_AMDGPU symbol in addition to
the boolean DRM_AMD_ISP=y, so this can only be built-in if
the ISP driver is also linked into the kernel itself.
Fixes: 9a54c285630c ("media: platform: amd: Introduce amd isp4 capture driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Bin Du <Bin.Du@amd.com> Tested-by: Bin Du <Bin.Du@amd.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Bin Du [Tue, 12 May 2026 03:21:14 +0000 (11:21 +0800)]
media: platform: amd: isp4: drop stale list reinit before free
Newer Smatch snapshots no longer report the false positive around
isp4if_send_fw_cmd(), so the extra list reinitialization before kfree()
is no longer needed.
Drop the stale list reinit and keep the cleanup path simpler.
Signed-off-by: Bin Du <Bin.Du@amd.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Arun T [Fri, 15 May 2026 17:45:12 +0000 (23:15 +0530)]
media: ov13b10: Support multiple regulators
The OV13B10 sensor driver currently handles a single regulator called
avdd, however the sensor can be supplied by up to three regulators.
Update the driver to handle all of them together using the regulator
bulk API.
Signed-off-by: Arun T <arun.t@intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Arun T [Fri, 15 May 2026 17:45:11 +0000 (23:15 +0530)]
platform/x86: int3472: Add TPS68470 board data for intel nvl
The Intel NVL platform uses IPU8 powered by a TPS68470 PMIC,
requiring board data to configure the GPIOs and regulators for
proper camera sensor operation.
Signed-off-by: Arun T <arun.t@intel.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Arun T [Fri, 15 May 2026 17:45:10 +0000 (23:15 +0530)]
platform/x86: int3472: Rename daisy-chain GPIO props to generic
Rename the MSI-specific daisy-chain GPIO properties and software node
to generic names so they can be reused by other platforms that also
require daisy-chain GPIO configuration for TPS68470.
Signed-off-by: Arun T <arun.t@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
projects / thirdparty / kernel / linux.git / log
