Guenter Roeck [Tue, 5 May 2026 16:23:43 +0000 (09:23 -0700)]
watchdog: Remove AMD Elan SC520 processor watchdog driver
AMD Elan support was removed from the upstream kernel with commit 8b793a92d862 ("x86/cpu: Remove M486/M486SX/ELAN support"). Its
watchdog driver can no longer be enabled except for test builds.
Remove it.
Philipp Hahn [Tue, 5 May 2026 09:26:15 +0000 (11:26 +0200)]
watchdog: Separate kind of documentation
Currently there are several (sub-)documents for "Generic kernel
infrastructure API" and several "driver specific" documents. Put each
one into its own sub-section.
Philipp Hahn [Tue, 5 May 2026 09:26:13 +0000 (11:26 +0200)]
watchdog: Move `struct` before name
Write `struct ` before the structure name as Sphinx otherwise uses the
following word after it. See
https://docs.kernel.org/watchdog/watchdog-api.html#environmental-monitoring
Mark Pearson [Tue, 28 Apr 2026 12:49:44 +0000 (08:49 -0400)]
watchdog: lenovo_se10_wdt: Add support for SE10 Gen 2 platform
The Lenovo SE10 Gen 2 platform uses a watchdog chip from the same family.
Watchdog functionality is the same, so update the driver with the new chip
ID.
Add the Gen 2 MTM's to enable support on the platform.
CL Wang [Thu, 15 Jan 2026 08:14:43 +0000 (16:14 +0800)]
watchdog: atcwdt200: Add driver for Andes ATCWDT200
Add support for the Andes ATCWDT200 watchdog timer. The driver implements
programmable reset and interrupt timers, and includes automatic detection
of the supported IntTime bit-width.
Integrated with the Linux watchdog framework, it supports basic operations
including start, stop, ping, timeout configuration, and system reset via
the restart handler.
watchdog: at91sam9_wdt.h: Document WDDIS bit position per SoC family
AT91_WDT_WDDIS (bit 15) applies to SAMA5/AT91SAM9261 and
AT91_SAM9X60_WDDIS (bit 12) to SAM9X60/SAMA7G5/SAM9X75. Update
comments to reflect this and add SAMA7G5 and SAM9X75 datasheet
references to the file header.
watchdog: imx7ulp_wdt: Keep WDOG running until A55 enters WFI on i.MX94
On i.MX94, watchdog sources clock from bus clock that will be always on
during the lifecycle of Linux. There is a Low Power Clock Gating(LPCG)
between the bus clock and watchdog, but the LPCG is not exported for
software to control, it is hardware automatically controlled. When
Cortex-A55 executes WFI during suspend flow, the LPCG will automatically
gate off the clock to stop watchdog and resume clock when Cortex-A55 is
woke up.
So watchdog could always be alive to protect Linux, except Cortex-A
platform WFI is executed in Linux suspend flow.
Introduce a new hardware feature flag to indicate CPU low-power-mode
auto clock gating support, and use it to avoid stopping the watchdog
during suspend when LPCG can safely keep it running.
Add i.MX94-specific watchdog hardware data and DT compatible entry to
enable this behavior.
Signed-off-by: Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>
[peng.fan@nxp.com: rewrite commit log for clarity] Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20260206-imx94-wdog-v2-1-4dd725faec1f@nxp.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Judith Mendez [Fri, 6 Feb 2026 23:42:55 +0000 (17:42 -0600)]
watchdog: rti_wdt: Add reaction control
This configures the reaction between NMI and reset for WWD.
On K3 SoCs other than AM62L SoC [0], watchdog reset output is routed
to the ESM module which can subsequently route the signal to safety
master or SoC reset. On AM62L, the watchdog reset output is routed
to the SoC HW reset block. So, add a new compatible for AM62L to add
SoC data and configure reaction to reset instead of NMI.
Brian Masney [Sun, 22 Feb 2026 23:24:17 +0000 (18:24 -0500)]
watchdog: pic32-dmt: allow driver to be compiled on all architectures with COMPILE_TEST
This driver currently only supports builds against a PIC32 target, or
with COMPILE_TEST on MIPS. Now that commit 0f8a61ca78d6 ("watchdog:
pic32-dmt: update include to use pic32.h from platform_data") is merged,
it's possible to compile this driver on other architectures.
To avoid future breakage of this driver in the future, let's update the
Kconfig so that it can be built with COMPILE_TEST enabled on all
architectures.
Brian Masney [Sun, 22 Feb 2026 23:24:16 +0000 (18:24 -0500)]
watchdog: pic32-wdt: allow driver to be compiled on all architectures with COMPILE_TEST
This driver currently only supports builds against a PIC32 target, or
with COMPILE_TEST on MIPS. Now that commit 5aa5879eeebb ("watchdog:
pic32-wdt: update include to use pic32.h from platform_data") is merged,
it's possible to compile this driver on other architectures.
To avoid future breakage of this driver in the future, let's update the
Kconfig so that it can be built with COMPILE_TEST enabled on all
architectures.
Hyunwoo Kim [Fri, 8 May 2026 08:53:09 +0000 (17:53 +0900)]
rxrpc: Also unshare DATA/RESPONSE packets when paged frags are present
The DATA-packet handler in rxrpc_input_call_event() and the RESPONSE
handler in rxrpc_verify_response() copy the skb to a linear one before
calling into the security ops only when skb_cloned() is true. An skb
that is not cloned but still carries externally-owned paged fragments
(e.g. SKBFL_SHARED_FRAG set by splice() into a UDP socket via
__ip_append_data, or a chained skb_has_frag_list()) falls through to
the in-place decryption path, which binds the frag pages directly into
the AEAD/skcipher SGL via skb_to_sgvec().
Extend the gate to also unshare when skb_has_frag_list() or
skb_has_shared_frag() is true. This catches the splice-loopback vector
and other externally-shared frag sources while preserving the
zero-copy fast path for skbs whose frags are kernel-private (e.g. NIC
page_pool RX, GRO). The OOM/trace handling already in place is reused.
Fixes: d0d5c0cd1e71 ("rxrpc: Use skb_unshare() rather than skb_cow_data()") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Sun, 10 May 2026 15:10:47 +0000 (08:10 -0700)]
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk driver fixes from Stephen Boyd:
- Mark the DDR bus clk critical in the SpaceMiT driver so that
boot doesn't fail
- Fix boot on Mobile EyeQ by creating the auxiliary device for
the ethernet PHY
- Plug an OF node leak in Rockchip rk808 clk driver
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: rk808: fix OF node reference imbalance
MAINTAINERS: add myself as a reviewer for the clk subsystem
reset: eyeq: drop device_set_of_node_from_dev() done by parent
clk: eyeq: add EyeQ5 children auxiliary device for generic PHYs
clk: eyeq: use the auxiliary device creation helper
clk: spacemit: k3: mark top_dclk as CLK_IS_CRITICAL
ASoC: ti: rx51: remove stale reference to machine_is_nokia_rx51()
The rx51 driver relies on the machine_is_nokia_rx51() macro, which was
used with the legacy board file dropped in commit 9b7141d01a76 ("ARM:
OMAP2+: Drop legacy board file for n900"). The use of this macro
prevents the removal of machine IDs no longer used by the kernel from
arch/arm/tools/mach-types, because the machine_is_*() macros are
generated from mach-types. Drop this unused code.
Tested-by: Jarkko Nikula <jarkko.nikula@bitmer.com> # v1 Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Link: https://patch.msgid.link/20260510054214.564950-1-enelsonmoore@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Cássio Gabriel [Fri, 8 May 2026 04:20:50 +0000 (01:20 -0300)]
ASoC: docs: Fix stale and misspelled references
While reading some docs, I have found some minor
misspelled words and some parts that could be improved.
The ASoC USB documentation refers to the USB DPCM backend link as DCPM
in two places. The ASoC platform documentation still points readers to
the old DPCM.txt name. The ALSA configuration guide also has two
references that omit their current subdirectory.
Fix a few stale and misspelled references in the ALSA and ASoC
documentation and update the references and fix a typo in the ASoC index.
ASoC: ti: omap3pandora: update board check to use DT compatible
The omap3pandora driver contains a check for the ARM machine ID via the
machine_is_omap3_pandora() macro. The board concerned now supports
only FDT booting, which does not use machine IDs, and therefore the
code should be updated to check the DT compatible property instead. The
legacy board file for this machine was removed in commit 7fcf7e061edd
("ARM: OMAP2+: Remove legacy booting support for Pandora").
The presence of this machine ID check prevents the removal of machine
IDs no longer used by the kernel from arch/arm/tools/mach-types,
because the machine_is_*() macros are generated from mach-types. To
resolve this issue, use of_machine_is_compatible() instead.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Mark Brown <broonie@kernel.org>
Paolo Bonzini [Mon, 4 May 2026 08:52:27 +0000 (04:52 -0400)]
Merge branch 'kvm-vmenter' into HEAD
Move SPEC_CTRL handling for VMX entirely to vmenter.S, also improving
assembly code reuse between SVM and VMX.
The prototype of __vmx_vcpu_run() and __svm_vcpu_run() becomes
the same, with a set of bit flags for the second argument.
The register allocation also becomes very similar, with %edi/%rdi
pointing to the vmx (resp. svm) argument.
Thanks to this, the code to save and restore SPEC_CTRL values for the
host and guest is the same up to the register names and can be dropped
into a new header arch/x86/kvm/vmenter.h. APX enablement will also move
common code to load and save registers from VMX and SVM to vmenter.h.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Mon, 4 May 2026 08:44:52 +0000 (04:44 -0400)]
Merge branch 'kvm-mbec' into HEAD
This topic branch introduces support for two related features that
Hyper-V uses in its implementation of Virtual Secure Mode; these are
Intel Mode-Based Execute Control and AMD Guest Mode Execution Trap.
Both MBEC and GMET allow more granular control over execute permissions,
with different levels of separation between supervisor and user mode.
MBEC provides support for separate supervisor and user-mode bits in the
PTEs; GMET instead lacks supervisor-mode only execution (with NX=0,
"both" is represented by U=0 and user-mode only by U=1). GMET was
clearly inspired by SMEP though with some differences and annoyances.
The implementation starts from two changes to core MMU code, both
of which help making the actual feature almost trivial to implement:
- first, I'm cleaning up the implementation of nVMX exec-only, by
properly adding read permissions to the ACC_* constant and to the
permission bitmask machinery. Jon also had to add a fourth ACC_*
bit, but used it only in the special case of nested MBEC; here
instead ACC_READ_MASK is the normality, which simplifies testing
a lot and removes gratuitous complexity.
- second, I'm enforcing that KVM runs with MBEC/GMET enabled even in
non-nested mode, if it wants to provide the feature to nested
hypervisors. This makes the creation of SPTEs looks exactly the
same for L1 and L2 guests, despite only the latter using MBEC/GMET
fully; the difference lies only in the input access permissions.
This strategy adds a limited amount of complexity to the core is limited,
while providing for an almost entirely seamless support of nested
hypervisors.
Later patches have to use slightly different meanings for ACC_* in Intel
and AMD. On the Intel side, some work is needed in order to split
shadow_x_mask and ACC_EXEC_MASK in two; now that there is an actual
ACC_READ_MASK to be used for exec-only pages, ACC_USER_MASK is unused
and can be reused as ACC_USER_EXEC_MASK. However, unlike the older
ACC_USER_MASK hack these differences are backed by concrete concepts
of the page table format, and there is always a 1:1 mapping from ACC_*
bits to PT_*_MASK or shadow_*_mask:
On Intel, ACC_EXEC_MASK is used for kernel-mode execution and is tied to
shadow_xs_mask (when MBEC is disabled, ACC_USER_EXEC_MASK and the XU bit
are computed but ineffective). update_permission_bitmask() precomputes
all the necessary conditions. On the AMD side, the U bit maps to
ACC_USER_MASK but nNPT adjusts the permission bitmask to ignore it for
reads and writes when GMET is active. Despite the smaller scale of the
changes compared to MBEC, there are some changes to make to use GMET
for L1 guests, because the page tables have to be created with U=0.
This means that the root page has role.access != ACC_ALL and its
permissions have to be propagated down.
Note that with MBEC the user/supervisor distinction depends on the U
bit of the page tables rather than the CPL. Processors provide this
information to the hypervisor through the "advanced EPT violation
vmexit info" feature, which is a requirement for KVM to use MBEC,
and kvm-intel.ko passes it to the MMU in PFERR_USER_MASK (unlike
kvm-amd.ko which computes it from the CPL). This needs a small change
to pass the effective XWU permissions of the page tables down to
translate_nested_gpa().
The former "smep_andnot_wp" bit of cpu_role.base, now named "cr4_smep",
is repurposed for nested TDP to indicate that MBEC/GMET is on. The minor
pessimization for shadow page tables (toggling CR4.SMEP now always forces
building a separate version of the shadow page tables, even though that's
technically unnecessary if CR4.WP=1) is not really worth fretting about;
in practice, guests are not going to flip CR4.SMEP in a way that would
prevent efficient reuse of shadow page tables.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:17 +0000 (11:42 -0400)]
KVM: nSVM: enable GMET for guests
All that needs to be done is moving the GMET bit from vmcb12 to vmcb02.
The only new thing is that __nested_copy_vmcb_control_to_cache now
ensures that ignored-if-unavailable bits are zero in svm->nested.ctl.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:16 +0000 (11:42 -0400)]
KVM: SVM: work around errata 1218
According to AMD, the hypervisor may not be able to determine whether a
fault was a GMET fault or an NX fault based on EXITINFO1, and software
"must read the relevant VMCB to determine whether a fault was a GMET
fault or an NX fault". The APM further details that they meant the
CPL field.
KVM uses the page fault error code to distinguish the causes of a
nested page fault, so recalculate the PFERR_USER_MASK bit of the
vmexit information. Only do it for fetches and only if GMET is in
use, because KVM does not differentiate based on PFERR_USER_MASK
for other nested NPT page faults.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Mon, 27 Apr 2026 15:45:52 +0000 (11:45 -0400)]
KVM: x86/mmu: add support for GMET to NPT page table walks
GMET allows page table entries to be created with U=0 in NPT.
However, when GMET=1 U=0 only affects execution, not reads or
writes. Ignore user faults on non-fetch accesses for NPT GMET.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Mon, 27 Apr 2026 15:30:56 +0000 (11:30 -0400)]
KVM: x86/mmu: hard code more bits in kvm_init_shadow_npt_mmu
The host CR0 does not really reflect onto the NPT format because
hCR0.PG=1 must be set and hCR0.WP is ignored. Carve that in stone
by removing the cr0 argument from kvm_init_shadow_npt_mmu.
Pass in WP=1 as well; it does not matter for GMET disabled because
PFERR_USER_MASK is always set, but a cleared W bit in the nested page
tables cannot be overridden in supervisor mode when GMET is enabled,
either. In fact, since CR0.WP=0 is the weird "extra accesses allowed"
mode, it is acutally easier think about it being always set.
Likewise, clear X86_CR4_SMAP to avoid that KVM erroneously faults on
supervisor accesses to an U=1 page.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:13 +0000 (11:42 -0400)]
KVM: SVM: add GMET bit definitions
GMET (Guest Mode Execute Trap) is an AMD virtualization feature,
essentially the nested paging version of SMEP. Hyper-V uses it;
add it in preparation for making it available to hypervisors
running under KVM.
Acked-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:12 +0000 (11:42 -0400)]
KVM: x86/mmu: introduce cpu_role bit for availability of PFEC.I/D
While GMET looks a lot like SMEP, it has several annoying differences.
The main one is that the availability of the I/D bit in the page fault
error code still depends on the host CR4.SMEP and EFER.NXE bits. If the
base.cr4_smep bit of the cpu_role is (ab)used to enable GMET, there needs
to be another place where the host CR4.SMEP is read from; just merge it
with EFER.NXE into a new cpu_role bit that tells paging_tmpl.h whether
to set the I/D bit at all.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:11 +0000 (11:42 -0400)]
KVM: x86/mmu: propagate access mask from root pages down
Until now, all SPTEs have had all kinds of access allowed; however,
for GMET to be enabled all the pages have to have ACC_USER_MASK
disabled. By marking them as supervisor pages, the processor
allows execution from either user or supervisor mode (unlike
for normal paging, NPT ignores the U bit for reads and writes).
That will mean that the root page's role has ACC_USER_MASK
cleared and that has to be propagated down through the kvm_mmu_page
tree.
Do that, and pass the required access to the
kvm_mmu_spte_requested tracepoint since it's not ACC_ALL
anymore.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Jon Kohler [Wed, 8 Apr 2026 15:42:10 +0000 (11:42 -0400)]
KVM: nVMX: allow MBEC with EVMCS
Extend EVMCS1_SUPPORTED_2NDEXEC to allow MBEC and EVMCS to coexist.
Presenting both EVMCS and MBEC simultaneously causes KVM to filter out
MBEC and not present it as a supported control to the guest, preventing
performance gains from MBEC when Windows HVCI is enabled.
The guest may choose not to use MBEC (e.g., if the admin does not enable
Windows HVCI / Memory Integrity), but if they use traditional nested
virt (Hyper-V, WSL2, etc.), having EVMCS exposed is important for
improving nested guest performance. IOW allowing MBEC and EVMCS to
coexist provides maximum optionality to Windows users without
overcomplicating VM administration.
Signed-off-by: Jon Kohler <jon@nutanix.com>
Message-ID: <20251223054806.1611168-8-jon@nutanix.com> Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Jon Kohler [Wed, 8 Apr 2026 15:42:09 +0000 (11:42 -0400)]
KVM: nVMX: advertise MBEC to nested guests
Advertise SECONDARY_EXEC_MODE_BASED_EPT_EXEC (MBEC) to userspace, which
allows userspace to expose and advertise the feature to the guest.
When MBEC is enabled by the guest, it is passed to the MMU via cr4_smep,
and to the processor by the merging of vmcs12->secondary_vm_exec_control
into the VMCS02's secondary VM execution controls.
Signed-off-by: Jon Kohler <jon@nutanix.com>
Message-ID: <20251223054806.1611168-9-jon@nutanix.com> Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:08 +0000 (11:42 -0400)]
KVM: x86/mmu: add support for MBEC to EPT page table walks
Extend the page walker to support moving bit 10 of the PTEs
into ACC_USER_EXEC_MASK and bit 6 of the exit qualification of
EPT violation VM exits.
Note that while mmu_has_mbec()/cr4_smep affect the interpretation of
ACC_USER_EXEC_MASK and add bit 10 as a "present bit" in guest EPT page
table entries, they do not affect how KVM operates on SPTEs. That's
because the MMU uses explicit ACC_USER_EXEC_MASK/shadow_xu_mask even for
the non-nested EPT; the only difference is that ACC_USER_EXEC_MASK and
ACC_EXEC_MASK will always be set in tandem outside the nested scenario.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:07 +0000 (11:42 -0400)]
KVM: nVMX: pass PFERR_USER_MASK to MMU on EPT violations
For EPT, PFERR_USER_MASK refers not to the CPL of the guest,
but to the AND of the U bits encountered while walking guest
page tables; this is consistent with how MBEC differentiates
between XS and XU. This is available through the
"advanced vmexit information for EPT violations" feature.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:06 +0000 (11:42 -0400)]
KVM: nVMX: pass advanced EPT violation vmexit info to guest
KVM will use advanced vmexit information for EPT violations to
virtualize MBEC. Pass it to the guest since it is easy and allows
testing nested nested.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:05 +0000 (11:42 -0400)]
KVM: VMX: enable use of MBEC
If available, set SECONDARY_EXEC_MODE_BASED_EPT_EXEC in the secondary
execution controls.
The changes are limited because the MMU is designed to create the same
sPTEs independent of the MBEC setting. On hosts lacking support for
MBEC, and in nested guests which cannot enable it as of this commit,
the XU bit is ignored by the processor.
Note that, as of this patch, MBEC is not available to L1 hypervisors
for their guests.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:04 +0000 (11:42 -0400)]
KVM: x86/mmu: move cr4_smep to base role
Guest page tables can be reused independent of the value of CR4.SMEP
(at least if WP=1). However, this is not true of EPT MBEC pages,
because presence of EPT entries is signaled by bits 0-2 when MBEC
is off, and bits 0-2 + bit 10 when MBEC is on.
In preparation for enabling MBEC, move cr4_smep to the base role.
This makes the smep_andnot_wp bit redundant, so remove it.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:03 +0000 (11:42 -0400)]
KVM: x86/mmu: split XS/XU bits for EPT
When EPT is in use, replace ACC_USER_MASK with ACC_USER_EXEC_MASK,
so that supervisor and user-mode execution can be controlled
independently (ACC_USER_MASK would not allow a setting similar to
XU=0 XS=1 W=1 R=1).
Replace shadow_x_mask with shadow_xs_mask/shadow_xu_mask, to allow setting
XS and XU bits separately in EPT entries.
In fact, ACC_USER_EXEC_MASK is already set through ACC_ALL in the
kvm_mmu_page roles and propagates to the XU bit of sPTEs even if
MBEC is not (yet) enabled in the execution controls. This is fine,
because the XU bit is ignored by the processor, and even once KVM
supports MBEC this mode will remain for processors that lack the
feature.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:02 +0000 (11:42 -0400)]
KVM: x86: make translate_nested_gpa vendor-specific
EPT and NPT have different rules for passing PFERR_USER_MASK to the
nested page table walk. In particular, for final addresses EPT
uses the U bit of the guest (nGVA->nGPA) walk.
While at it, remove PFERR_USER_MASK from the VMX version of the
function, since it is actually ignored by the tables that
update_permission_bitmask() generates for EPT.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:01 +0000 (11:42 -0400)]
KVM: x86/mmu: pass pte_access for final nGPA->GPA walk
The XS/XU bit for EPT are only applied to final accesses, and use the
U bit from the page walk itself. This is available in the page walker
as pte_access & ACC_USER_MASK but not available to translate_nested_gpa,
so pass it down.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:42:00 +0000 (11:42 -0400)]
KVM: x86/mmu: pass PFERR_GUEST_PAGE/FINAL_MASK to kvm_translate_gpa
The XS/XU bit for EPT are only applied to final accesses, and use the
U bit from the page walk itself. While strictly speaking not necessary
(any value of PFERR_USER_MASK would be the same for page table accesses,
because they're reads and writes only), it is clearer and less hackish
to only apply MBEC to PFERR_GUEST_FINAL_MASK. Allow kvm-intel.ko to
distinguish the two cases.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 15:41:58 +0000 (11:41 -0400)]
KVM: x86/mmu: introduce ACC_READ_MASK
Read permissions so far were only needed for EPT, which does not need
ACC_USER_MASK. Therefore, for EPT page tables ACC_USER_MASK was repurposed
as a read permission bit.
In order to implement nested MBEC, EPT will genuinely have four kinds of
accesses, and there will be no room for such hacks; bite the bullet at
last, enlarging ACC_ALL to four bits and permissions[] to 2^4 bits (u16).
The new code does not enforce that the XWR bits on non-execonly processors
have their R bit set, even when running nested: none of the shadow_*_mask
values have bit 0 set, and make_spte() genuinely relies on ACC_READ_MASK
being requested! This works because, if execonly is not supported by the
processor, shadow EPT will generate an EPT misconfig vmexit if the XWR
bits represent a non-readable page, and therefore the pte_access argument
to make_spte() will also always have ACC_READ_MASK set.
Tested-by: David Riley <d.riley@proxmox.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Alexander Stein [Wed, 11 Feb 2026 14:49:48 +0000 (15:49 +0100)]
phy: freescale: imx8qm-hsio: provide regmap names
This driver uses multiple regmaps, which will causes name conflicts
in debugfs like:
debugfs: '5f1a0000.phy' already exists in 'regmap'
Fix this by using a dedicated regmap config for each resource, each
having a dedicated regmap name.
Théo Lebrun [Mon, 9 Mar 2026 14:37:34 +0000 (15:37 +0100)]
phy: Add driver for EyeQ5 Ethernet PHY wrapper
EyeQ5 embeds a system-controller called OLB. It features many unrelated
registers, and some of those are registers used to configure the
integration of the RGMII/SGMII Cadence PHY used by MACB/GEM instances.
Wrap in a neat generic PHY provider, exposing two PHYs with standard
phy_init() / phy_set_mode() / phy_power_on() operations.
Fix a malformed MODULE_AUTHOR macro in the RZ/G3E USB3.0 PHY driver where
the author's name and opening angle bracket were missing, leaving only the
email address with a stray closing >. Correct it to the standard Name
<email> format.
Reported-by: Pavel Machek <pavel@nabladev.com> Closes: https://lore.kernel.org/all/abp4KprlYyU+jMPu@duo.ucw.cz/ Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20260319063211.5056-1-biju.das.jz@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Vladimir Oltean [Sat, 21 Mar 2026 01:14:51 +0000 (03:14 +0200)]
phy: lynx-28g: implement phy_exit() operation
On Layerscape, some Lynx SerDes consumers go through the PHY framework
(we call these 'managed' for the sake of this discussion; they are some
Ethernet lanes), and some consumers don't go through the PHY framework
(we call these 'unmanaged'; they are some unconverted Ethernet lanes,
plus all SATA and PCIe controllers).
A lane is initially unmanaged, and becomes managed when phy_init() is
called on it. Similarly, it becomes unmanaged again when phy_exit() is
called.
Managed lanes are supposed to have power management through
phy_power_on() and phy_power_off().
The lynx-28g SerDes driver, when it probes, probes on all lanes, but
needs to be careful to keep the unmanaged lanes powered on, because
those might be in use by consumers unaware that they need to call
phy_init() and phy_power_on(). This also applies after phy_exit() is
called - no guarantee is made about how the port may be used
afterwards - may be DPDK, may be something else which is unaware of
the PHY framework.
Given this state table:
State | Consumer calls phy_exit()? | Provider implements phy_exit()?
-------+----------------------------+--------------------------------
(a) | no | no
(b) | no | yes
(c) | yes | no
(d) | yes | yes
we are currently in state (a). This has the problem that when the
consumer fails to probe with -EPROBE_DEFER or is otherwise unbound,
the phy->init_count remains elevated and the lane never returns to the
unmanaged state (temporarily or not) as it should. Furthermore, the
second and subsequent phy_init() consumer calls are never passed on to
the provider driver.
We solve the above problem by implementing phy_exit() in the consumer,
and that moves us to state (c). But this creates the problem that a
balanced set of phy_init() and phy_exit() calls from the consumer will
effectively result in multiple lynx_28g_init() calls as seen by the
SerDes and nothing else - as the optional phy_ops :: exit() is not
implemented. But that actually doesn't work - the 28G Lynx SerDes can't
power down a lane which is already powered down; that call sequence
would time out and fail.
So actually we want to be in state (d), where both the provider and the
consumer implement phy_exit(). But we can only do that safely through
intermediary state (b), where the provider implements it first. This
effectively behaves just like (a), except it offers a safe migration
path for the consumer to call phy_exit() as mandated by the Generic PHY
API.
Extra development notes: ignoring the lynx_28g_power_on() error in
lynx_28g_exit() is a deliberate decision. The consumer can't deal with a
teardown path that is not error-free. Ignoring the error is not silent:
lynx_28g_power_on() -> lynx_28g_lane_reset() will print on failure.
Vladimir Oltean [Sat, 21 Mar 2026 01:14:50 +0000 (03:14 +0200)]
phy: lynx-28g: truly power the lanes up or down
The current procedure for power_off() and power_on() is the same as the
one used for major lane reconfiguration, aka halting. But this is
incorrect.
One would expect that a powered off lane causes the CDR (clock and data
recovery) loop of the link partner to lose lock onto its RX stream
(which suggests there are no longer any bit transitions => the channel
is inactive). However, it can be observed that this does not take place
(the CDR lock is still there), which means that a halted lane is not
powered off.
Implement the procedure mentioned in the block guide for powering down
a lane, and then back on. This means:
- lynx_28g_power_off() currently emits a HLT_REQ and waits for it to
clear. Rename it to lynx_28g_lane_halt() and keep using it for
lynx_28g_set_mode().
- lynx_28g_power_on() currently emits a RST_REQ and waits for it to
clear. This is the reset procedure - rename it to
lynx_28g_lane_reset(), and keep using it for lynx_28g_set_mode().
The "real" lynx_28g_power_off() should emit a STP_REQ and wait for it to
clear. And the "real" lynx_28g_power_on() should clear the DIS bit and
then perform a lane reset. Hook these methods to the phy_ops ::
power_off() and power_on() instead.
As opposed to lynx_28g_power_off() which is also directly hooked to the
PHY API, lynx_28g_lane_halt() isn't; just to lynx_28g_set_mode(), and
the call is being made in a state where we haven't yet made any change
to the lane. So it does make some limited amount of sense to code this
up such that if it fails, we make an attempt to reset the lane anyway
and let the consumer know that phy_set_mode_ext() failed.
Sort the field definitions in LNaTRSTCTL and LNaRRSTCTL in descending
order, and add new definitions for STP_REQ and DIS, previously unused.
Vladimir Oltean [Sat, 21 Mar 2026 01:14:49 +0000 (03:14 +0200)]
phy: lynx-28g: use timeouts when waiting for lane halt and reset
There are various circumstances in which a lane halt, or a lane reset,
will fail to complete. If this happens, it will hang the kernel, which
only implements a busy loop with no timeout.
The circumstances in which this will happen are all bugs in nature:
- if we try to power off a powered off lane
- if we try to power off a lane that uses a PLL locked onto the wrong
refclk frequency (wrong RCW, but SoC boots anyway)
Actually, unbounded loops in the kernel are a bad practice, so let's use
read_poll_timeout() with a custom function that reads both LNaTRSTCTL
(lane transmit control register) and LNaRRSTCTL (lane receive control
register) and returns true when the request is done in both directions.
The HLT_REQ bit has to clear, whereas the RST_DONE bit has to get set.
Any time such an error happens, it is catastrophic and there is no point
in trying to propagate it to our callers:
- if lynx_28g_set_mode() -> lynx_28g_power_on() times out, we have
already reconfigured the lane, but returning an error would tell the
caller that we didn't
- if lynx_28g_power_off() times out, again not much for the consumer to
do to help get out of this situation - the phy_power_off() call is
probably made from a context that the consumer can't cancel, or it is
making it to return to a known state from a previous failure.
So just print an error if timeouts happen and let the driver control
flow continue. The entire point is just to not let the kernel freeze.
Wesley Cheng [Mon, 2 Mar 2026 08:34:46 +0000 (10:34 +0200)]
phy: qcom: m31-eusb2: Make USB repeater optional
A repeater is not required for the PHY to function. On systems with
multiple PHY instances connected to a multi-port controller, some PHYs
may be unconnected. All PHYs must still probe successfully even without
attached repeaters, otherwise the controller probe fails.
So make it optional.
Signed-off-by: Wesley Cheng <wesley.cheng@oss.qualcomm.com>
[abel.vesa@oss.qualcomm.com: commit re-worded to reflect actual reason] Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260302-phy-qcom-m31-eusb2-make-repeater-optional-v2-1-dbf714c72056@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
Commit 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
moved QPHY_V6_PCS_UFS_PLL_CNTL register configuration from the shared
sm8650_ufsphy_g5_pcs table to the SM8650-specific sm8650_ufsphy_pcs base
table to fix Gear 4 operation on SM8650.
However, this change inadvertently broke kaanapali and SM8750 SoCs
which also rely on the shared sm8650_ufsphy_g5_pcs table for Gear 5
configuration but use their own sm8750_ufsphy_pcs base table. After the
change, kaanapali PHYs are left without the required PLL_CNTL = 0x33
setting, causing the PHY PLL to remain at its hardware reset default
value, preventing PLL lock and resulting in DME_LINKSTARTUP timeouts.
Fix this by adding the missing QPHY_V6_PCS_UFS_PLL_CNTL = 0x33 entry
to the sm8750_ufsphy_pcs table, mirroring what the original commit
already did for sm8650_ufsphy_pcs.
Cc: stable@vger.kernel.org # v6.19.12 Fixes: 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4") Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260415104851.2763238-1-nitin.rawat@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy: exynos5-usbdrd: fix USB 2.0 HS PHY tuning values for Exynos7870
The existing PHYPARAM0 tuning values for Exynos7870 are incorrect,
causing the USB 2.0 PHY to fail high-speed negotiation and fall back
to full-speed (12Mbps) operation.
Fix TXVREFTUNE (transmitter voltage reference) from 14 to 3,
TXRESTUNE (transmitter impedance) from 3 to 2, and SQRXTUNE
(squelch threshold) from 6 to 5. Also explicitly set
TXPREEMPPULSETUNE to 0, which was previously missing from the
tuning table despite being included in the register mask.
All values are derived from the vendor kernel for the Samsung
Galaxy A6 (SM-A600FN), as no public hardware documentation is
available for the Exynos7870 USB DRD PHY. With these corrections,
the PHY successfully negotiates high-speed (480Mbps) operation.
The existing code reads a single hs_term_range_adj value from bit field
[10:7] of FUSE_SKU_CALIB_0 and applies it to all USB2 pads uniformly.
However, on SoCs that support per-pad termination, each pad has its own
hs_term_range_adj field: pad 0 in FUSE_SKU_CALIB_0[10:7], and pads 1-3
in FUSE_USB_CALIB_EXT_0 at bit offsets [8:5], [12:9], and [16:13]
respectively.
Fix the calibration by reading per-pad values from the appropriate fuse
registers. For SoCs that do not support per-pad termination, replicate
pad 0's value to all pads to maintain existing behavior.
Add a has_per_pad_term flag to the SoC data to indicate whether per-pad
termination values are available in FUSE_USB_CALIB_EXT_0.
Ritesh Kumar [Wed, 28 Jan 2026 11:48:49 +0000 (17:18 +0530)]
dt-bindings: phy: qcom-edp: Add reference clock for sa8775p eDP PHY
The initial sa8775p eDP PHY binding contribution missed adding support for
voting on the eDP reference clock. This went unnoticed because the UFS PHY
driver happened to enable the same clock.
After commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls"), the eDP reference clock is no longer kept enabled, which results
in the following PHY power-on failure:
To fix this, explicit voting for the eDP reference clock is required.
This patch adds the eDP reference clock for sa8775p eDP PHY and updates
the corresponding example node.
Shawn Guo [Sat, 14 Mar 2026 05:13:23 +0000 (13:13 +0800)]
phy: qcom-qmp-usbc: Rename QCS615 DP PHY variables and functions
Commit 81791c45c8e0 ("phy: qcom: qmp-usbc: Add QCS615 USB/DP PHY config
and DP mode support") chose to name QCS615 DP PHY variables/functions
with qmp_v2 prefix, by assuming that QMP PHY registers are versioned
as a whole. However, the reality is that the registers are versioned
in sub-modules like QSERDES COM and QSERDES TXRX respectively, e.g.
QCS615 DP PHY has registers of QSERDES COM v2 and QSERDES TXRX v3.
Thus it may cause confusion that qmp_v2_xxx table and functions access
QSERDES TXRX v3 registers.
Rename QCS615 DP PHY variables and functions to be prefixed by qcs615
instead of qmp_v2. This better aligns with how the driver names USB3 PHY
variables for QCM2290 etc.
Shawn Guo [Sat, 14 Mar 2026 05:13:22 +0000 (13:13 +0800)]
phy: qcom-qmp-usbc: Use register definitions in qserdes-txrx-v3
The register definitions in header qserdes-txrx-v2 and qserdes-txrx-v3
are actually identical. Considering that QSERDES TX/RX v2 is already
defined by header qserdes-txrx, qserdes-txrx-v2 is really just
a duplication of qserdes-txrx-v3 for QSERDES TX/RX v3. Switch
qcom-qmp-usbc driver to use v3 registers.
Shawn Guo [Sat, 14 Mar 2026 05:13:21 +0000 (13:13 +0800)]
phy: qcom-qmp: Use explicit QSERDES COM v2 register definitions
As the code comments in the headers say, both qserdes-com and
qserdes-com-v2 define QSERDES COM registers for QMP V2 PHY. Switch
phy-qcom-qmp drivers to use register definitions in qserdes-com-v2
to make the QSERDES COM version explicit.
The mvebu_a3700_utmi_phy_power_off() function tries to modify the
USB2_PHY_CTRL register by using the IO address of the PHY IP block along
with the readl/writel IO accessors. However, the register exist in the
USB miscellaneous register space, and as such it must be accessed via
regmap like it is done in the mvebu_a3700_utmi_phy_power_on() function.
Change the code to use regmap_update_bits() for modífying the register
to fix this.
phy: tegra: xusb: Make USB_CONN_GPIO select conditional on GPIOLIB
kconfiglint reports:
K006: config PHY_TEGRA_XUSB selects USB_CONN_GPIO which depends on
GPIOLIB, but PHY_TEGRA_XUSB does not depend on GPIOLIB
K002: config PHY_TEGRA_XUSB selects visible symbol USB_CONN_GPIO
which has dependencies
USB_CONN_GPIO was introduced in commit 4602f3bff266 ("usb: common: add USB
GPIO based connection detection driver") with a hard dependency on GPIOLIB,
since it needs GPIO pins to detect USB cable connection state.
Commit f67213cee2b3 ("phy: tegra: xusb: Add usb-role-switch support") added
`select USB_CONN_GPIO` to PHY_TEGRA_XUSB to support USB role switching via
GPIO-based detection. At that time, PHY_TEGRA_XUSB depended only on
`ARCH_TEGRA`, and both the ARM32 and ARM64 ARCH_TEGRA Kconfig definitions
select GPIOLIB, so the missing explicit GPIOLIB guard was not a functional
problem — GPIOLIB is always available when ARCH_TEGRA is enabled.
Later, commit 0d5c9bc7c680 ("phy: tegra: Select USB_COMMON for
usb_get_maximum_speed()") added `depends on USB_SUPPORT` but still did not
address the GPIOLIB gap.
The select can force USB_CONN_GPIO on without its GPIOLIB dependency being
satisfied if the Kconfig dependencies were ever restructured. Make the
select conditional with `select USB_CONN_GPIO if GPIOLIB` to make the
dependency explicit. This mirrors how other drivers handle optional
GPIO-dependent selects throughout the kernel.
RDMA/addr: Change addr_wq back to unordered workqueue
Commit 5fff41e1f89d ("IB/core: Fix race condition in resolving IP to MAC")
changed the workqueue "addr_wq" to a single-threaded wq.
Commit e19c0d237873 ("RDMA/rdma_cm: Remove process_req and timer sorting")
eliminated global work and started using per-req work.
Now we no longer have the race, change "addr_wq" back to multi-threaded
workqueue to speed up multiple addr resolutions.
interconnect: qcom: Restrict drivers per ARM/ARM64
There is no point to allow selecting core SoC drivers like interconnects
for Qualcomm ARMv7 SoCs when building ARM64 kernel, and vice versa.
This makes kernel configuration more difficult as many do not remember
the Qualcomm SoCs model names/numbers and their properties like
architecture. No features should be lost because:
1. There won't be a single image for ARMv7 and ARMv8/9 SoCs.
2. Newer ARMv8/9 SoCs won't be running in arm32 emulation mode.
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:12 +0000 (02:33 +0200)]
media: qcom: iris: extract firmware description data
In preparation to adding support for several firmware revisions to be
used for a platform, extract the firmware description data. It
incorporates firmware name, HFI ops and buffer requirements of the
particular firmware build.
Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
[bod: Made struct iris_firmware_desc into static consts to pass media CI] Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:11 +0000 (02:33 +0200)]
media: qcom: iris: use new firmware name for SM8250
The linux-firmware is providing the vpuNN_pM.mbn firmware for SM8250
since August of 2024. Stop using the legacy firmware name
(vpu-1.0/venus.mbn) and switch to the standard firmware name schema
(vpu/vpu20_p4.mbn).
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:10 +0000 (02:33 +0200)]
media: qcom: iris: split platform data from firmware data
Finalize the logical separation of the software and hardware interface
descriptions by moving hardware properties to the files specific to the
particular VPU version.
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:09 +0000 (02:33 +0200)]
media: qcom: iris: split firmware_data from raw platform data
Having firmware-related fields in platform data results in the tying
platform data to the HFI firmware data rather than the actual hardware.
For example, SM8450 uses Gen2 firmware, so currently its platform data
should be placed next to the other gen2 platforms, although it has the
VPU2.0 core, similar to the one found on SM8250 and SC7280 and so the
hardware-specific platform data is also close to those devices.
Split firmware data to a separate struct, separating hardware-related
data from the firmware interfaces.
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:07 +0000 (02:33 +0200)]
media: qcom: iris: move get_instance to iris_hfi_sys_ops
The get_instance() is a callback tightly connected to the HFI
implementation. Move it into the new iris_hfi_sys_ops structure, merging
all core callbacks into a single vtable.
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:05 +0000 (02:33 +0200)]
media: qcom: iris: split HFI session ops from core ops
Calling HFI instance-specific ops should not require double indirection
through the core ops. Split instance-specific ops to a separate struct,
keep a pointer to it in struct iris_inst and set it directly in the
get_instance function.
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:04 +0000 (02:33 +0200)]
media: qcom: iris: don't use function indirection in gen2-specific code
To note that iris_set_num_comv() is gen2-internal, rename it to
iris_hfi_gen2_set_num_comv() and then stop using hfi_ops indirection to
set session property (like other functions in this file do).
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:03 +0000 (02:33 +0200)]
media: qcom: iris: use common set_preset_registers function
The set_preset_registers is (currently) common to all supported devices.
Extract it to a iris_vpu_common.c and call it directly from
iris_vpu_power_on(). Later, if any of the devices requires special
handling, it can be sorted out separately.
Dmitry Baryshkov [Sun, 29 Mar 2026 00:33:02 +0000 (02:33 +0200)]
media: qcom: iris: drop pas_id from the iris_platform_data struct
The PAS ID, the authentication service ID, used by the Iris is a
constant and it is not expected to change anytime. Drop it from the
platform data and use the constant instead.
Dmitry Baryshkov [Fri, 27 Mar 2026 20:19:56 +0000 (22:19 +0200)]
media: qcom: venus: flip the venus/iris switch
With the Iris and Venus driver having more or less feature parity for
"HFI 6xx" platforms and with Iris gaining support for SC7280, flip the
switch. Use Iris by default for SM8250 and SC7280, the platforms which
are supported by both drivers, and use Venus only if Iris is not
compiled at all. Use IS_ENABLED to strip out the code and data
structures which are used by the disabled platforms.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
[bod: Moved two conditional compats inside of one ifdef for ci]
[bod: Changed IS_V6(core) (0) to ((void)(core), 0) for ci] Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Dmitry Baryshkov [Fri, 27 Mar 2026 20:19:54 +0000 (22:19 +0200)]
media: dt-bindings: qcom-sc7180-venus: move video-firmware here
As SC7180 is the only remaining user of the non-TZ / non-PAS setup which
uses the video-firmware subnode, move its definition from the common
schema to the SC7180-specific one.
These properties do not accurately describe the hardware. Future
platforms that are going to support non-TZ setup will use different
semantics and different DT ABI (using the iommu-map property).
Dmitry Baryshkov [Fri, 27 Mar 2026 20:19:53 +0000 (22:19 +0200)]
media: dt-bindings: qcom,sc7280-venus: drop non-PAS support
The only users of the non-PAS setup on SC7280 platform are the ChromeOS
devices, which were cancelled before reaching end users. Iris, the
alternative driver for the same hardware, does not support non-PAS
setup. It is expected that in future both Venus and Iris devices will
use different ABI for non-PAS (EL2) setup.
In order to declare only the future-proof hardware description drop
support for non-PAS setup from the SC7280 Venus schema (breaking almost
non-existing SC7280 ChromeOS devices).
The dropped iommus entry reflects the extra stream, which should not be
treated in the same way as the main one (which doesn't match the usage
described by the iommus definition).
On SM8250 most of the video clocks are powered by the MMCX domain, while
the PLL is powered on by the MX domain. Extend the driver to support
scaling both power domains, while keeping compatibility with the
existing DTs, which define only the MX domain.
On SM8250 most of the video clocks are powered by the MMCX domain, while
the PLL is powered on by the MX domain. Extend the driver to support
scaling both power domains, while keeping compatibility with the
existing DTs, which define only the MX domain.
media: dt-bindings: qcom,sm8250-venus: sort out power domains
First of all, on SM8250 Iris (ex-Venus) core needs to scale clocks which
are powered by the MMCX domain. Add MMCX domain to the list of the power
domain to be used on this platform.
Dmitry Baryshkov [Sun, 25 Jan 2026 11:30:11 +0000 (13:30 +0200)]
media: iris: drop remnants of UBWC configuration
Now as all UBWC configuration bits were migrated to be used or derived
from the global UBWC platform-specific data, drop the unused struct and
field definitions.
Dmitry Baryshkov [Sun, 25 Jan 2026 11:30:10 +0000 (13:30 +0200)]
media: iris: don't specify max_channels in the source code
The UBWC max_channels spreading is specified in the Iris driver, but it
also can be calculated from the platform UBWC config. Use the platform
UBWC configuration instead of specifying it directly in the source.
Dmitry Baryshkov [Sun, 25 Jan 2026 11:30:09 +0000 (13:30 +0200)]
media: iris: don't specify bank_spreading in the source code
The UBWC bank spreading is specified both in the Iris driver and in the
platform UBWC config. Use the platform UBWC configuration instead of
specifying it directly in the source.
projects / thirdparty / kernel / linux.git / log
