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.
Dmitry Baryshkov [Sun, 25 Jan 2026 11:30:08 +0000 (13:30 +0200)]
media: iris: don't specify ubwc_swizzle in the source code
The UBWC swizzle 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.
Dmitry Baryshkov [Sun, 25 Jan 2026 11:30:07 +0000 (13:30 +0200)]
media: iris: don't specify highest_bank_bit in the source code
The highest_bank_bit param 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.
Dmitry Baryshkov [Sun, 25 Jan 2026 11:30:06 +0000 (13:30 +0200)]
media: iris: don't specify min_acc_length in the source code
The min_acc length can be calculated from the platform UBWC
configuration. Use the freshly introduced helper and calculate min_acc
length based on the platform UBWC configuration instead of specifying it
directly in the source.
Dmitry Baryshkov [Sun, 25 Jan 2026 11:30:05 +0000 (13:30 +0200)]
media: iris: retrieve UBWC platform configuration
Specifying UBWC data in each driver doesn't scale and is prone to
errors. Request UBWC data from the central database in preparation to
using it through the rest of the driver.
Yixun Lan [Thu, 5 Mar 2026 01:00:51 +0000 (01:00 +0000)]
dt-bindings: phy: spacemit: k3: add USB2 PHY support
Introduce a compatible string for the USB2 PHY in SpacemiT K3 SoC. The IP
of USB2 PHY mostly shares the same functionalities with K1 SoC, while has
some register layout changes.
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
dt-bindings: interconnect: qcom,sm6115: Restrict children and clocks
Some interconnect devices described in the binding have children and
some have clocks. The devices which do not have them, should have this
restricted (disallowed).
qcom,sm6115-cnoc has a clock, thus also extend the example to be
complete for this device.
dt-bindings: interconnect: qcom,sm6115: Drop incorrect children if:then: block
This binding has children, so any if:then: block restricting them,
cannot be defined in top-level allOf:if:then:properties:, because it
simply does not match these children. The block, if it was useful,
should be defined within patternProperties for the children, however
since child nodes do not have clocks at all, there is little point in
disallowing them in the first place.
Remove completely redundant and ineffective piece of code.
dt-bindings: interconnect: qcom,sdm660: Disallow clocks when appropriate
Only qcom,sdm660-mnoc and qcom,sdm660-a2noc devices from what is covered
by this binding have clocks. Others do not, so restrict the schema to
be more accurate.
interconnect: Move MODULE_DEVICE_TABLE next to the table itself
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
exports, because this is easier to read and verify. It also makes more
sense since #ifdef for ACPI or OF could hide both of them.
Most of the privers already have this correctly placed, so adjust
the missing ones. No functional impact.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260505102854.186925-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
interconnect: Do not create empty devres on missing interconnects
of_icc_get() returns NULL on valid case - no interconnects - but no
need to create devres for that, because it just wastes memory without
any use/benefits.
Add the Qualcomm Hawi SoC compatible string for the CPU bandwidth
monitor and there is single instance present globally to monitor
the traffic from CPU to LLCC.
Odelu Kukatla [Sun, 10 May 2026 02:06:07 +0000 (10:06 +0800)]
interconnect: qcom: Add interconnect provider driver for Nord SoC
Add driver for the Qualcomm interconnect buses found on Nord SoC.
The topology consists of several NoCs that are controlled by
a remote processor that collects the aggregated bandwidth for each
master-slave pair.
Add driver for the Qualcomm interconnect buses found in Shikra
based platforms. The topology consists of several NoCs that are
controlled by a remote processor that collects the aggregated
bandwidth for each master-slave pairs.
DaeMyung Kang [Sun, 10 May 2026 02:13:11 +0000 (11:13 +0900)]
ntfs: fix empty_buf and ra lifetime bugs in ntfs_empty_logfile()
ntfs_empty_logfile() has three related allocator bugs around the
@empty_buf and @ra buffers it uses inside the per-cluster loop.
When the loop encounters a runlist entry with LCN_RL_NOT_MAPPED, the
function kvfrees @empty_buf and goes to map_vcn to remap. @empty_buf
is not cleared. If ntfs_map_runlist_nolock() fails on re-entry,
control jumps to the err label which kvfrees @empty_buf a second time.
In the same branch, @ra is left allocated. When the remap succeeds
the function falls through the @empty_buf re-allocation and the @ra
re-allocation, overwriting the previous @ra pointer and leaking it.
The success path frees @empty_buf with kfree() instead of kvfree().
kvzalloc() may fall back to vmalloc(), in which case kfree() does not
correctly release the memory.
A KASAN-enabled QEMU harness mirroring this control flow reports
"BUG: KASAN: double-free" when the second ntfs_map_runlist_nolock()
fails.
Clear both @empty_buf and @ra after the in-loop releases so the err
path is a no-op when the buffers have already been freed and so the
remap-success path does not leak the previous @ra. Switch the success
path to kvfree() to match the @empty_buf allocator.
Raj Aryan [Thu, 7 May 2026 13:57:15 +0000 (19:27 +0530)]
soc: qcom: spmi-pmic: add SUBTYPEs for Glymur/Kaanapali/SM8750 PMICs
On Glymur, Kaanapali, and SM8750, PMIC info is not being properly populated
in qcom_socinfo. Its shows `unknown` as PMIC subtypes are
not updated in the socinfo.
clk: qcom: Constify qcom_cc_driver_data and list of critical CBCR registers
The static 'struct qcom_cc_driver_data' and array 'xxx_critical_cbcrs'
are already treated by common.c code as pointers to const, so constify
few remaining pieces.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260429170859.247165-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Reading few registers at the end of the block (e.g. 0x10000, 0x10004)
might result in synchronous external abort, so limit the regmap to the
last readable register which allows dumping the regs for debugging.
Reported-by: Daniel J Blueman <daniel@quora.org> Closes: https://lore.kernel.org/r/CAMVG2su+V5fcZ9LOC0Qm3bpfnhpbmQdJackc7-RvfztDL_dajw@mail.gmail.com/ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Daniel J Blueman <daniel@quora.org> Link: https://lore.kernel.org/r/20260505152908.302097-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Xin Liu [Fri, 17 Apr 2026 05:42:00 +0000 (22:42 -0700)]
arm64: dts: qcom: purwa: Add EL2 overlay for purwa-iot-evk
Add support for building an EL2 combined DTB for the purwa-iot-evk
in the Qualcomm DTS Makefile.
The new purwa-iot-evk-el2.dtb is generated by combining the base
purwa-iot-evk.dtb with the x1-el2.dtbo overlay, enabling EL2-specific
configurations required by the platform.
Hans de Goede [Sat, 25 Apr 2026 12:33:51 +0000 (14:33 +0200)]
clk: qcom: x1e80100-dispcc: Stop disp_cc_mdss_mdp_clk_src from getting parked
Parking disp_cc_mdss_mdp_clk_src at 19.2MHz causing the EFI GOP framebuffer
to stop functioning. The EFI GOP framebuffer should keep working until
the msm display driver loads, to help with boot debugging and to ensure
display output when the msm module is not in the initramfs.
Switch disp_cc_mdss_mdp_clk_src over to clk_rcg2_shared_no_init_park_ops
to keep the EFI GOP working after binding the x1e80100-dispcc driver.
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Link: https://lore.kernel.org/r/20260425123351.6292-1-johannes.goede@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
projects / thirdparty / linux.git / log
