Max McNamee [Mon, 23 Feb 2026 22:05:14 +0000 (22:05 +0000)]
arm64: dts: qcom: msm8916-samsung-coreprimeltevzw: add device tree
Samsung Galaxy Core Prime Verizon Wireless is a phone based on MSM8916.
They are similar to the other Samsung devices based on MSM8916 with only a
few minor differences.
The device trees contain initial support with:
- GPIO keys
- Regulator haptic
- SDHCI (internal and external storage)
- USB Device Mode
- UART (on USB connector via the SM5502 MUIC)
- WCNSS (WiFi/BT)
- Regulators
- QDSP6 audio
- Speaker/earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- WWAN Internet via BAM-DMUX
- PMIC and charger
- Touchscreen
There are different variants of Core Prime, with some differences in
NFC and MUIC.
The common parts are shared in
msm8916-samsung-fortuna-common.dtsi and msm8916-samsung-rossa-common.dtsi
to reduce duplication.
Signed-off-by: Max McNamee <maxmcnamee@proton.me>
[Raymond: Refactor touchscreen and MUIC. Add commit messages.] Signed-off-by: Raymond Hackley <raymondhackley@protonmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260223220514.2556033-4-wonderfulshrinemaidenofparadise@postmarketos.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Raymond Hackley [Mon, 23 Feb 2026 22:05:12 +0000 (22:05 +0000)]
arm64: dts: qcom: msm8916-samsung-fortuna: Move SM5504 from rossa and refactor MUIC
MUIC varies on fortuna/rossa devices, which could be either SM5502 or
SM5504. Move SM5504 from msm8916-samsung-rossa-common to
msm8916-samsung-fortuna-common and refactor MUIC.
Disable MUIC by default in msm8916-samsung-fortuna-common, and explicitly
specify them in each fortuna/rossa board.
John Crispin [Wed, 11 Mar 2026 18:39:40 +0000 (19:39 +0100)]
dt-bindings: clock: qcom: Add CMN PLL support for IPQ8074
The CMN PLL block in the IPQ8074 SoC takes 48 MHz as the reference
input clock. Its output clocks are the bias_pll_cc_clk (300 MHz) and
bias_pll_nss_noc_clk (416.5 MHz) clocks used by the networking
subsystem.
Add the related compatible for IPQ8074 to the ipq9574-cmn-pll
generic schema.
Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311183942.10134-4-ansuelsmth@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
John Crispin [Wed, 11 Mar 2026 18:39:38 +0000 (19:39 +0100)]
dt-bindings: clock: qcom: Add CMN PLL support for IPQ6018
The CMN PLL block in the IPQ6018 SoC takes 48 MHz as the reference
input clock. Its output clocks are the bias_pll_cc_clk (300 MHz) and
bias_pll_nss_noc_clk (416.5 MHz) clocks used by the networking
subsystem.
Add the related compatible for IPQ6018 to the ipq9574-cmn-pll
generic schema.
Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260311183942.10134-2-ansuelsmth@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Pengyu Luo [Sun, 8 Mar 2026 06:48:35 +0000 (14:48 +0800)]
arm64: dts: qcom: sc8280xp: Add dsi nodes on SC8280XP
The DT configuration follows other Samsung 5nm-based Qualcomm SOCs,
utilizing the same register layouts and clock structures.
However, DSI won't work properly for now until we submit dispcc fixes.
And some DSC enabled panels require DPU timing calculation fixes too.
(hdisplay / width timing round errors cause the fifo error)
Co-developed-by: Tianyu Gao <gty0622@gmail.com> Signed-off-by: Tianyu Gao <gty0622@gmail.com> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Tested-by: White Lewis <liu224806@gmail.com> # HUAWEI Gaokun3 Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260308064835.479356-5-mitltlatltl@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
selftests/livepatch: add test for module function patching
Add a target module and livepatch pair that verify module function
patching via a proc entry. Two test cases cover both the
klp_enable_patch path (target loaded before livepatch) and the
klp_module_coming path (livepatch loaded before target).
Signed-off-by: Pablo Alessandro Santos Hugen <phugen@redhat.com> Acked-by: Miroslav Benes <mbenes@suse.cz> Acked-by: Joe Lawrence <joe.lawrence@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Tested-by: Petr Mladek <pmladek@suse.com> Link: https://patch.msgid.link/20260320201135.1203992-1-phugen@redhat.com Signed-off-by: Petr Mladek <pmladek@suse.com>
The onboard Wi-Fi / BT device, WCN3990, has a simple on-chip PMU, which
further spreads generated voltage. Describe the PMU in the device tree
and rewire Bluetooth and WiFi supply properties to use the PMU LDO
outputs instead of referencing the SoC regulators directly.
The onboard Wi-Fi / BT device, WCN3990, has a simple on-chip PMU, which
further spreads generated voltage. Describe the PMU in the device tree
and rewire Bluetooth and Wi-Fi supply properties to use the PMU LDO
outputs instead of referencing the SoC regulators directly.
Most qcom DTs were converted to use the gpu_zap_shader label instead
of patching the gpu node in commit 2377626fd216 ("arm64: dts: qcom:
add gpu_zap_shader label"). This fixes the remaining ones.
clk: qcom: gdsc: Fix error path on registration of multiple pm subdomains
Some pm subdomains may be left in added to a parent domain state, if
gdsc_add_subdomain_list() function fails in the middle and bails from
a GDSC power domain controller registration out.
Fixes: b489235b4dc0 ("clk: qcom: Support attaching GDSCs to multiple parents") Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bod@kernel.org> Link: https://lore.kernel.org/r/20260328012619.832770-1-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Canfeng Zhuang [Fri, 27 Mar 2026 08:31:01 +0000 (16:31 +0800)]
arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
The monaco-evk mezzanine connector supports a robot expansion board that
requires UART6, which is currently disabled. This prevents the expansion
board from exchanging data and control commands.
Enable UART6 and assign the serial2 alias to provide stable device
enumeration for the expansion board.
Canfeng Zhuang [Fri, 27 Mar 2026 08:31:00 +0000 (16:31 +0800)]
arm64: dts: qcom: lemans-evk: enable UART0 for robot expansion board
The lemans-evk mezzanine connector supports a robot expansion board that
requires UART0, which is currently disabled. This prevents the expansion
board from exchanging data and control commands.
Enable UART0 and assign the serial2 alias to provide stable device
enumeration for the expansion board.
Abel Vesa [Fri, 27 Mar 2026 12:13:41 +0000 (14:13 +0200)]
arm64: dts: qcom: milos: Add missing CX power domain to GCC
Unless CX is declared as the power-domain of GCC, votes (power and
performance) on the GDSCs it provides will not propagate to the CX,
which might result in under-voltage conditions.
Add the missing power-domains property to associate GCC with RPMHPD_CX.
Erikas Bitovtas [Sun, 29 Mar 2026 23:37:57 +0000 (02:37 +0300)]
arm64: dts: qcom: msm8939-asus-z00t: add regulators for ambient light and proximity sensor
VCNL4000 includes support for regulators. Add regulators listed in the
downstream device tree so they can be powered in during initialization.
VLED supply is missing downstream, so it will be powered on by a dummy.
Alok Tiwari [Sun, 29 Mar 2026 19:53:23 +0000 (12:53 -0700)]
soc: qcom: aoss: compare against normalized cooling state
qmp_cdev_set_cur_state() normalizes the requested state to a boolean
(cdev_state = !!state). The existing early-return check compares
qmp_cdev->state == state, which can be wrong if state is non-boolean
(any non-zero value). Compare qmp_cdev->state against cdev_state instead,
so the check matches the effective state and avoids redundant updates.
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260329195333.1478090-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The llcc_v1_edac_reg_offset table uses 0x2304c for trp_ecc_sb_err_syn0,
which is inconsistent with the surrounding TRP ECC registers (0x2034x)
and with llcc_v2_1_edac_reg_offset, where trp_ecc_sb_err_syn0 is 0x2034c
adjacent to trp_ecc_error_status0/1 at 0x20344/0x20348.
Use 0x2034c for llcc v1 so the SB syndrome register follows the expected
+0x4 progression from trp_ecc_error_status1. This fixes EDAC reading the
wrong register for SB syndrome reporting.
Fixes: c13d7d261e36 ("soc: qcom: llcc: Pass LLCC version based register offsets to EDAC driver") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260330095118.2657362-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
For some reason we ended up adding only 4 out of 11 compute cb's for
CDSP, add the missing compute cb. This will also improve the end
user-experience by enabling running multiple AI usecases in parallel.
John Groves [Fri, 27 Mar 2026 21:05:12 +0000 (21:05 +0000)]
dax: Add fs_dax_get() func to prepare dax for fs-dax usage
The fs_dax_get() function should be called by fs-dax file systems after
opening a fsdev dax device. This adds holder_operations, which provides
a memory failure callback path and effects exclusivity between callers
of fs_dax_get().
fs_dax_get() is specific to fsdev_dax, so it checks the driver type
(which required touching bus.[ch]). fs_dax_get() fails if fsdev_dax is
not bound to the memory.
This function serves the same role as fs_dax_get_by_bdev(), which dax
file systems call after opening the pmem block device.
This can't be located in fsdev.c because struct dax_device is opaque
there.
This will be called by fs/fuse/famfs.c in a subsequent commit.
John Groves [Fri, 27 Mar 2026 21:05:03 +0000 (21:05 +0000)]
dax: Add dax_set_ops() for setting dax_operations at bind time
Add a new dax_set_ops() function that allows drivers to set the
dax_operations after the dax_device has been allocated. This is needed
for fsdev_dax where the operations need to be set during probe and
cleared during unbind.
The fsdev driver uses devm_add_action_or_reset() for cleanup consistency,
avoiding the complexity of mixing devm-managed resources with manual
cleanup in a remove() callback. This ensures cleanup happens automatically
in the correct reverse order when the device is unbound.
John Groves [Fri, 27 Mar 2026 21:04:54 +0000 (21:04 +0000)]
dax: Add dax_operations for use by fs-dax on fsdev dax
fsdev: Add dax_operations for use by famfs.
This replicates the functionality from drivers/nvdimm/pmem.c that
conventional fs-dax file systems (e.g. xfs) use to support dax
read/write/mmap to a daxdev - without which famfs can't sit atop a
daxdev.
- These methods are based on pmem_dax_ops from drivers/nvdimm/pmem.c
- fsdev_dax_direct_access() returns the hpa, pfn and kva. The kva was
newly stored as dev_dax->virt_addr by dev_dax_probe().
- The hpa/pfn are used for mmap (dax_iomap_fault()), and the kva is used
for read/write (dax_iomap_rw())
- fsdev_dax_recovery_write() and dev_dax_zero_page_range() have not been
tested yet. I'm looking for suggestions as to how to test those.
- dax-private.h: add dev_dax->cached_size, which fsdev needs to
remember. The dev_dax size cannot change while a driver is bound
(dev_dax_resize returns -EBUSY if dev->driver is set). Caching the size
at probe time allows fsdev's direct_access path can use it without
acquiring dax_dev_rwsem (which isn't exported anyway).
John Groves [Fri, 27 Mar 2026 21:04:35 +0000 (21:04 +0000)]
dax: add fsdev.c driver for fs-dax on character dax
The new fsdev driver provides pages/folios initialized compatibly with
fsdax - normal rather than devdax-style refcounting, and starting out
with order-0 folios.
When fsdev binds to a daxdev, it is usually (always?) switching from the
devdax mode (device.c), which pre-initializes compound folios according
to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the
folios into a fsdax-compatible state.
A side effect of this is that raw mmap doesn't (can't?) work on an fsdev
dax instance. Accordingly, The fsdev driver does not provide raw mmap -
devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw
mmap capability.
In this commit is just the framework, which remaps pages/folios compatibly
with fsdax.
Enabling dax changes:
- bus.h: add DAXDRV_FSDEV_TYPE driver type
- bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs
- dax.h: prototype inode_dax(), which fsdev needs
John Groves [Fri, 27 Mar 2026 21:04:22 +0000 (21:04 +0000)]
dax: Factor out dax_folio_reset_order() helper
Both fs/dax.c:dax_folio_put() and drivers/dax/fsdev.c:
fsdev_clear_folio_state() (the latter coming in the next commit after this
one) contain nearly identical code to reset a compound DAX folio back to
order-0 pages. Factor this out into a shared helper function.
The new dax_folio_reset_order() function:
- Clears the folio's mapping and share count
- Resets compound folio state via folio_reset_order()
- Clears PageHead and compound_head for each sub-page
- Restores the pgmap pointer for each resulting order-0 folio
- Returns the original folio order (for callers that need to advance by
that many pages)
Two intentional differences from the original dax_folio_put() logic:
1. folio->share is cleared unconditionally. This is correct because the DAX
subsystem maintains the invariant that share != 0 only when
mapping == NULL (enforced by dax_folio_make_shared()). dax_folio_put()
ensures share has reached zero before calling this helper, so the
unconditional clear is safe.
2. folio->pgmap is now explicitly restored for order-0 folios. For the
dax_folio_put() caller this is a no-op (reads and writes back the same
field). It is intentional for the upcoming fsdev_clear_folio_state()
caller, which converts previously-compound folios and needs pgmap
re-established for all pages regardless of order.
This simplifies fsdev_clear_folio_state() from ~50 lines to ~15 lines.
John Groves [Fri, 27 Mar 2026 21:04:08 +0000 (21:04 +0000)]
dax: move dax_pgoff_to_phys from [drivers/dax/] device.c to bus.c
This function will be used by both device.c and fsdev.c, but both are
loadable modules. Moving to bus.c puts it in core and makes it available
to both.
Johan Hovold [Mon, 9 Mar 2026 08:12:59 +0000 (09:12 +0100)]
i2c: tegra: enable compile testing on all archs
Commit 4a2d5f663dab ("i2c: Enable compile testing for more drivers")
enabled compile testing of the Tegra i2c driver only for architectures
that explicitly provide readsX() and writesX().
This limitation appears to have been too restrictive since the generic
implementation of these primitives added by commit 9ab3a7a0d2b4
("asm-generic/io.h: Implement generic {read,write}s*()") predates the
commit in question.
Allow compile testing of the driver on all architectures.
Cc: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Bjorn Andersson [Tue, 24 Mar 2026 02:32:39 +0000 (21:32 -0500)]
arm64: dts: qcom: qcs6490-rb3gen2: Enable uPD720201 and GL3590
The QCS6490 Rb3Gen2 has a Renesas μPD720201 XHCI controller hanging off
the TC9563 PCIe switch, on this a Genesys Logic GL3590 USB hub provides
two USB Type-A ports and an ASIX AX88179 USB 3.0 Gigabit Ethernet
interface.
The Renesas chip is powered by two regulators controlled through PM7250B
GPIOs 1 and 4, and the power/reset pin is pulled down by PM8350C GPIO 4.
The Genesys chip power is always-on, but the reset pin is controlled
through TLMM GPIO 162.
Describe the Renesas chip on the PCIe bus, with supplies and reset, to
allow it to be brought out of reset and discovered. Then describe the
two peers of the USB hub, with its reset GPIO, to allow this to be
brought out of reset.
The USB Type-A connectors are not described, as they are in no regard
controlled by the operating system.
Ziyue Zhang [Mon, 30 Mar 2026 02:09:34 +0000 (10:09 +0800)]
arm64: dts: qcom: hamoa: Fix incomplete Root Port property migration
Historically, the Qualcomm PCIe controller node (Host bridge) described
all Root Port properties, such as PHY, PERST#, and WAKE#. But to provide
a more accurate hardware description and to support future multi-Root Port
controllers, these properties were moved to the Root Port node in the
devicetree bindings.
Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
initiated this transition for the Hamoa platform by moving the PHY
property to the Root Port node in hamoa.dtsi. However, it only updated
some platform specific DTS files for PERST# and WAKE#, leaving others in
a "mixed" binding state.
While the PCIe controller driver supports both legacy and Root Port
bindings, It cannot correctly handle a mix of both. In these cases, the
driver parses the PHY from the Root Port node, but fails to find the
PERST# property (which it then assumes is not present, as it is optional).
Consequently, the controller probe succeeds, but PERST# remains
uncontrolled, preventing PCIe endpoints from functioning.
So, fix the incomplete migration by moving the PERST# and WAKE# properties
from the controller node to the Root Port node in all remaining Hamoa
platform DTS files.
Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260330020934.3501247-1-ziyue.zhang@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Matthew Brost [Thu, 26 Mar 2026 21:01:15 +0000 (14:01 -0700)]
drm/xe: Avoid memory allocations in xe_device_declare_wedged()
xe_device_declare_wedged() runs in the DMA-fence signaling path, where
GFP_KERNEL memory allocations are not allowed. However, registering
xe_device_wedged_fini via drmm_add_action_or_reset() triggers a
GFP_KERNEL allocation.
Fix this by deferring the registration of xe_device_wedged_fini until
late in the driver load sequence. Additionally, drop the wedged PM
reference only if the device is actually wedged in
xe_device_wedged_fini.
Matthew Brost [Fri, 27 Feb 2026 01:52:25 +0000 (17:52 -0800)]
drm/xe: Disable garbage collector work item on SVM close
When an SVM is closed, the garbage collector work item must be stopped
synchronously and any future queuing must be prevented. Replace
flush_work() with disable_work_sync() to ensure both conditions are
met.
On PTL, older GSC FWs have a bug that can cause them to crash during
PXP invalidation events, which leads to a complete loss of power
management on the media GT. Therefore, we can't use PXP on FWs that
have this bug, which was fixed in PTL GSC build 1396.
Fixes: b1dcec9bd8a1 ("drm/xe/ptl: Enable PXP for PTL") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260324153718.3155504-10-daniele.ceraolospurio@intel.com
(cherry picked from commit 6eb04caaa972934c9b6cea0e0c29e466bf9a346f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/pxp: Remove incorrect handling of impossible state during suspend
The default case of the PXP suspend switch is incorrectly exiting
without releasing the lock. However, this case is impossible to hit
because we're switching on an enum and all the valid enum values have
their own cases. Therefore, we can just get rid of the default case
and rely on the compiler to warn us if a new enum value is added and
we forget to add it to the switch.
Fixes: 51462211f4a9 ("drm/xe/pxp: add PXP PM support") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com> Cc: Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patch.msgid.link/20260324153718.3155504-8-daniele.ceraolospurio@intel.com
(cherry picked from commit f1b5a77fc9b6a90cd9a5e3db9d4c73ae1edfcfac) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/pxp: Clean up termination status on failure
If the PXP HW termination fails during PXP start, the normal completion
code won't be called, so the termination will remain uncomplete. To avoid
unnecessary waits, mark the termination as completed from the error path.
Note that we already do this if the termination fails when handling a
termination irq from the HW.
Fixes: f8caa80154c4 ("drm/xe/pxp: Add PXP queue tracking and session start") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com> Cc: Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by: Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patch.msgid.link/20260324153718.3155504-7-daniele.ceraolospurio@intel.com
(cherry picked from commit 5d9e708d2a69ab1f64a17aec810cd7c70c5b9fab) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Arvind Yadav [Thu, 26 Mar 2026 13:08:38 +0000 (18:38 +0530)]
drm/xe/madvise: Accept canonical GPU addresses in xe_vm_madvise_ioctl
Userspace passes canonical (sign-extended) GPU addresses where bits 63:48
mirror bit 47. The internal GPUVM uses non-canonical form (upper bits
zeroed), so passing raw canonical addresses into GPUVM lookups causes
mismatches for addresses above 128TiB.
Strip the sign extension with xe_device_uncanonicalize_addr() at the
top of xe_vm_madvise_ioctl(). Non-canonical addresses are unaffected.
Fixes: ada7486c5668 ("drm/xe: Implement madvise ioctl for xe") Suggested-by: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Arvind Yadav <arvind.yadav@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260326130843.3545241-13-arvind.yadav@intel.com
(cherry picked from commit 05c8b1cdc54036465ea457a0501a8c2f9409fce7) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Felix Gu [Sat, 28 Mar 2026 16:07:06 +0000 (00:07 +0800)]
spi: stm32-ospi: Fix reset control leak on probe error
When spi_register_controller() fails after reset_control_acquire()
succeeds, the reset control is never released. This causes a resource
leak in the error path.
Add the missing reset_control_release() call in the error path.
Fixes: cf2c3eceb757 ("spi: stm32-ospi: Make usage of reset_control_acquire/release() API") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://patch.msgid.link/20260329-stm32-ospi-v1-1-142122466412@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, __device_set_driver_override() handles clearing the override
via empty string ("") and newline ("\n") in two separate paths. The "\n"
case also performs an unnecessary memory allocation and immediate free.
Simplify the logic by initializing 'new' to NULL and only allocating
memory if the string length remains non-zero after stripping the
trailing newline.
Reduce code size, improve readability, and avoid unnecessary memory
operations.
Aleksandr Nogikh [Wed, 25 Mar 2026 15:48:24 +0000 (16:48 +0100)]
x86/kexec: Disable KCOV instrumentation after load_segments()
The load_segments() function changes segment registers, invalidating GS base
(which KCOV relies on for per-cpu data). When CONFIG_KCOV is enabled, any
subsequent instrumented C code call (e.g. native_gdt_invalidate()) begins
crashing the kernel in an endless loop.
To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented
kernel:
$ kexec -l /boot/otherKernel
$ kexec -e
The real-world context for this problem is enabling crash dump collection in
syzkaller. For this, the tool loads a panic kernel before fuzzing and then
calls makedumpfile after the panic. This workflow requires both CONFIG_KEXEC
and CONFIG_KCOV to be enabled simultaneously.
Adding safeguards directly to the KCOV fast-path (__sanitizer_cov_trace_pc())
is also undesirable as it would introduce an extra performance overhead.
Disabling instrumentation for the individual functions would be too fragile,
so disable KCOV instrumentation for the entire machine_kexec_64.c and
physaddr.c. If coverage-guided fuzzing ever needs these components in the
future, other approaches should be considered.
The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported
there.
Randy Dunlap [Thu, 12 Mar 2026 05:14:44 +0000 (22:14 -0700)]
powercap: correct kernel-doc function parameter names
Use the correct function parameter names in kernel-doc comments to
avoid these warnings:
Warning: include/linux/powercap.h:254 function parameter 'name' not
described in 'powercap_register_control_type'
Warning: include/linux/powercap.h:298 function parameter 'nr_constraints'
not described in 'powercap_register_zone'
m68k: defconfig: hp300: Enable monochrome and 16-color linux logos
According to "HP 9000 Series 300 Computers: Video Signals and
Monitors"[1], HP Topcat and Catseye graphics hardware varieties support
monochrome, 16-color, 64-color, and 256-color displays. Hence enable the
standard black-and-white and 16-color Linux logos, too.
This occurs when allocating MSI-X vectors for an NVMe device. During
allocation the XIVE code creates a struct xive_irq_data and stores it
in irq_data->chip_data.
When the MSI-X irqdomain is later freed, xive_irq_free_data() is
responsible for retrieving this structure and freeing it. However,
after commit cc0cc23babc9 ("powerpc/xive: Untangle xive from child
interrupt controller drivers"), xive_irq_free_data() retrieves the
chip_data using irq_get_chip_data(), which looks up the data through
the child domain.
This is incorrect because the XIVE-specific irq data is associated with
the XIVE (parent) domain. As a result the lookup fails and the allocated
struct xive_irq_data is never freed, leading to the kmemleak report
shown above.
Fix this by retrieving the irq_data from the correct domain using
irq_domain_get_irq_data() and then accessing the chip_data via
irq_data_get_irq_chip_data().
This uses _RPAGE_SW2 bit for the PMD and PUDs similar to PTEs.
This also adds support for {pte,pmd,pud}_pgprot helpers needed for
follow_pfnmap APIs.
This allows us to extend the PFN mappings, e.g. PCI MMIO bars where
it can grow as large as 8GB or even bigger, to map at PMD / PUD level.
VFIO PCI core driver already supports fault handling at PMD / PUD level
for more efficient BAR mappings.
drivers/vfio_pci_core: Change PXD_ORDER check from switch case to if/else block
Architectures like PowerPC uses runtime defined values for
PMD_ORDER/PUD_ORDER. This is because it can use either RADIX or HASH MMU
at runtime using kernel cmdline. So the pXd_index_size is not known at
compile time. Without this fix, when we add huge pfn support on powerpc
in the next patch, vfio_pci_core driver compilation can fail with the
following errors.
CC [M] drivers/vfio/vfio_main.o
CC [M] drivers/vfio/group.o
CC [M] drivers/vfio/container.o
CC [M] drivers/vfio/virqfd.o
CC [M] drivers/vfio/vfio_iommu_spapr_tce.o
CC [M] drivers/vfio/pci/vfio_pci_core.o
CC [M] drivers/vfio/pci/vfio_pci_intrs.o
CC [M] drivers/vfio/pci/vfio_pci_rdwr.o
CC [M] drivers/vfio/pci/vfio_pci_config.o
CC [M] drivers/vfio/pci/vfio_pci.o
AR kernel/built-in.a
../drivers/vfio/pci/vfio_pci_core.c: In function ‘vfio_pci_vmf_insert_pfn’:
../drivers/vfio/pci/vfio_pci_core.c:1678:9: error: case label does not reduce to an integer constant
1678 | case PMD_ORDER:
| ^~~~
../drivers/vfio/pci/vfio_pci_core.c:1682:9: error: case label does not reduce to an integer constant
1682 | case PUD_ORDER:
| ^~~~
make[6]: *** [../scripts/Makefile.build:289: drivers/vfio/pci/vfio_pci_core.o] Error 1
make[6]: *** Waiting for unfinished jobs....
make[5]: *** [../scripts/Makefile.build:546: drivers/vfio/pci] Error 2
make[5]: *** Waiting for unfinished jobs....
make[4]: *** [../scripts/Makefile.build:546: drivers/vfio] Error 2
make[3]: *** [../scripts/Makefile.build:546: drivers] Error 2
Tom Lendacky [Tue, 24 Mar 2026 16:13:01 +0000 (10:13 -0600)]
crypto/ccp: Update HV_FIXED page states to allow freeing of memory
After SNP is disabled, any pages allocated as HV_FIXED can now be freed.
Update the page state of these pages and the snp_leak_hv_fixed_pages()
function to free pages on SNP_SHUTDOWN.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Link: https://patch.msgid.link/20260324161301.1353976-8-tycho@kernel.org
The SEV firmware has support to disable SNP during an SNP_SHUTDOWN_EX command.
Verify that this support is available and set the flag so that SNP is disabled
when it is not being used.
In cases where SNP is disabled, skip the call to amd_iommu_snp_disable(), as
all of the IOMMU pages have already been made shared. Also skip the panic
case, since snp_shutdown() does IPIs.
Signed-off-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Link: https://patch.msgid.link/20260324161301.1353976-7-tycho@kernel.org
The locking in gfs2_trans_add_data() and gfs2_trans_add_meta() doesn't
follow the usual coding pattern of checking bh->b_private under lock,
allocating a new bufdata object with the locks dropped, and re-checking
once the lock has been reacquired. Both functions set bh->b_private
without holding the buffer lock. Fix that.
Also, in gfs2_trans_add_meta(), taking the folio lock during the
allocation doesn't actually do anything useful.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Ingo Molnar [Sun, 14 Dec 2025 08:46:49 +0000 (09:46 +0100)]
x86/cpu: Remove M486/M486SX/ELAN support
In the x86 architecture we have various complicated hardware emulation
facilities on x86-32 to support ancient 32-bit CPUs that very very few
people are using with modern kernels. This compatibility glue is sometimes
even causing problems that people spend time to resolve, which time could
be spent on other things.
As Linus recently remarked:
> I really get the feeling that it's time to leave i486 support behind.
> There's zero real reason for anybody to waste one second of
> development effort on this kind of issue.
Implement the first step and remove M486/M486SX/ELAN support:
CONFIG_M486SX
CONFIG_M486
CONFIG_MELAN
[ There's no recent M486=y kernel package for any mainstream x86
32-bit distribution available that I've been able to find, so
actual users should not be impacted, and any legacy users can
keep using older kernels. ]
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ahmed S. Darwish <darwi@linutronix.de> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Arnd Bergmann <arnd@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20251214084710.3606385-2-mingo@kernel.org
Ast's DP501 initialization reads the register SCU2C at offset 0x1202c
and tries to set it to source data from VGA. But writes the update to
offset 0x0, with unknown results. Write the result to SCU instead.
The bug only happens in ast_init_analog(). There's similar code in
ast_init_dvo(), which works correctly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 83c6620bae3f ("drm/ast: initial DP501 support (v0.2)") Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jocelyn Falempe <jfalempe@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.16+ Link: https://patch.msgid.link/20260327133532.79696-2-tzimmermann@suse.de
Wang Yechao [Mon, 30 Mar 2026 08:12:58 +0000 (16:12 +0800)]
RISC-V: KVM: Split huge pages during fault handling for dirty logging
During dirty logging, all huge pages are write-protected. When the guest
writes to a write-protected huge page, a page fault is triggered. Before
recovering the write permission, the huge page must be split into smaller
pages (e.g., 4K). After splitting, the normal mapping process proceeds,
allowing write permission to be restored at the smaller page granularity.
If dirty logging is disabled because migration failed or was cancelled,
only recover the write permission at the 4K level, and skip recovering the
huge page mapping at this time to avoid the overhead of freeing page tables.
The huge page mapping can be recovered in the ioctl context, similar to x86,
in a later patch.
Wang Yechao [Mon, 30 Mar 2026 08:10:52 +0000 (16:10 +0800)]
RISC-V: KVM: Fix lost write protection on huge pages during dirty logging
When enabling dirty log in small chunks (e.g., QEMU default chunk
size of 256K), the chunk size is always smaller than the page size
of huge pages (1G or 2M) used in the gstage page tables. This caused
the write protection to be incorrectly skipped for huge PTEs because
the condition `(end - addr) >= page_size` was not satisfied.
Remove the size check in `kvm_riscv_gstage_wp_range()` to ensure huge
PTEs are always write-protected regardless of the chunk size. Additionally,
explicitly align the address down to the page size before invoking
`kvm_riscv_gstage_op_pte()` to guarantee that the address passed to the
operation function is page-aligned.
This fixes the issue where dirty pages might not be tracked correctly
when using huge pages.
Mukesh Ojha [Fri, 27 Mar 2026 17:12:40 +0000 (22:42 +0530)]
pinctrl: qcom: Drop redundant intr_target_reg on modern SoCs
On all Qualcomm TLMM generations from APQ8084 onwards, the interrupt
target routing bits are located in the same register as the interrupt
configuration bits (intr_cfg_reg). Only five older SoCs — APQ8064,
IPQ8064, MDM9615, MSM8660 and MSM8960 — have a genuinely separate
interrupt target routing register at a different offset (0x400 + 0x4 * id).
Replace MSM_ACCESSOR(intr_target) with a custom accessor that falls back
to intr_cfg_reg when intr_target_reg is zero. Apply the same fallback in
the SCM path. Drop the now-redundant .intr_target_reg initializer from
all SoC drivers where it duplicated intr_cfg_reg, keeping it only in
the five drivers where it genuinely differs.
Mukesh Ojha [Fri, 27 Mar 2026 17:12:39 +0000 (22:42 +0530)]
pinctrl: qcom: eliza: Fix interrupt target bit
The intr_target_bit for Eliza was incorrectly set to 5, which is the
value used by older Qualcomm SoCs (e.g. SM8250, MSM8996, X1E80100).
Newer SoCs such as SM8650, SM8750, Milos, and Kaanapali all use
bit 8 for the interrupt target field in the TLMM interrupt configuration
register.
Eliza belongs to the newer generation and should use bit 8 to correctly
route interrupts to the KPSS (Applications Processor). Using the wrong
bit position means the interrupt target routing is silently misconfigured,
which can result in GPIO interrupts not being delivered to the expected
processor.
Fix this by aligning Eliza with the correct value used by its peer SoCs.
Fixes: 6f26989e15fb ("pinctrl: qcom: Add Eliza pinctrl driver") Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
gpio: shared: shorten the critical section in gpiochip_setup_shared()
Commit 710abda58055 ("gpio: shared: call gpio_chip::of_xlate() if set")
introduced a critical section around the adjustmenet of entry->offset.
However this may cause a deadlock if we create the auxiliary shared
proxy devices with this lock taken. We only need to protect
entry->offset while it's read/written so shorten the critical section
and release the lock before creating the proxy device as the field in
question is no longer accessed at this point.
Jiakai Xu [Thu, 19 Mar 2026 03:59:02 +0000 (03:59 +0000)]
RISC-V: KVM: Fix integer overflow in kvm_pmu_validate_counter_mask()
When a guest initiates an SBI_EXT_PMU_COUNTER_CFG_MATCH call with
ctr_base=0xfffffffffffffffe, ctr_mask=0xeb5f and flags=0x1
(SBI_PMU_CFG_FLAG_SKIP_MATCH), kvm_riscv_vcpu_pmu_ctr_cfg_match()
first invokes kvm_pmu_validate_counter_mask() to verify whether
ctr_base and ctr_mask are valid, by evaluating:
!ctr_mask || (ctr_base + __fls(ctr_mask) >= kvm_pmu_num_counters(kvpmu))
With the above inputs, __fls(0xeb5f) equals 15, and adding 15 to
0xfffffffffffffffe causes an integer overflow, wrapping around to 13.
Since 13 is less than kvm_pmu_num_counters(), the validation wrongly
succeeds.
Thereafter, since flags & SBI_PMU_CFG_FLAG_SKIP_MATCH is satisfied,
the code evaluates:
!test_bit(ctr_base + __ffs(ctr_mask), kvpmu->pmc_in_use)
Here __ffs(0xeb5f) equals 0, so test_bit() receives 0xfffffffffffffffe
as the bit index and attempts to access the corresponding element of
the kvpmu->pmc_in_use, which results in an invalid memory access. This
triggers the following Oops:
Unable to handle kernel paging request at virtual address e3ebffff12abba89
generic_test_bit include/asm-generic/bitops/generic-non-atomic.h:128
kvm_riscv_vcpu_pmu_ctr_cfg_match arch/riscv/kvm/vcpu_pmu.c:758
kvm_sbi_ext_pmu_handler arch/riscv/kvm/vcpu_sbi_pmu.c:49
kvm_riscv_vcpu_sbi_ecall arch/riscv/kvm/vcpu_sbi.c:608
kvm_riscv_vcpu_exit arch/riscv/kvm/vcpu_exit.c:240
The root cause is that kvm_pmu_validate_counter_mask() does not account
for the case where ctr_base itself is out of range, allowing the
subsequent addition to silently overflow and bypass the check.
Fix this by explicitly validating ctr_base against kvm_pmu_num_counters()
before performing the addition.
This bug was found by fuzzing the KVM RISC-V PMU interface.
Mikhail Gavrilov [Fri, 27 Mar 2026 12:41:56 +0000 (17:41 +0500)]
dma-debug: suppress cacheline overlap warning when arch has no DMA alignment requirement
When CONFIG_DMA_API_DEBUG is enabled, the DMA debug infrastructure
tracks active mappings per cacheline and warns if two different DMA
mappings share the same cacheline ("cacheline tracking EEXIST,
overlapping mappings aren't supported").
On x86_64, ARCH_KMALLOC_MINALIGN defaults to 8, so small kmalloc
allocations (e.g. the 8-byte hub->buffer and hub->status in the USB
hub driver) frequently land in the same 64-byte cacheline. When both
are DMA-mapped, this triggers a false positive warning.
This has been reported repeatedly since v5.14 (when the EEXIST check
was added) across various USB host controllers and devices including
xhci_hcd with USB hubs, USB audio devices, and USB ethernet adapters.
The cacheline overlap is only a real concern on architectures that
require DMA buffer alignment to cacheline boundaries (i.e. where
ARCH_DMA_MINALIGN >= L1_CACHE_BYTES). On architectures like x86_64
where dma_get_cache_alignment() returns 1, the hardware is
cache-coherent and overlapping cacheline mappings are harmless.
Suppress the EEXIST warning when dma_get_cache_alignment() is less
than L1_CACHE_BYTES, indicating the architecture does not require
cacheline-aligned DMA buffers.
Verified with a kernel module reproducer that performs two kmalloc(8)
allocations back-to-back and DMA-maps both:
Before: allocations share a cacheline, EEXIST fires within ~50 pairs
After: same cacheline pair found, but no warning emitted
Cássio Gabriel [Mon, 30 Mar 2026 04:00:34 +0000 (01:00 -0300)]
ALSA: aoa: i2sbus: fix OF node lifetime handling
i2sbus_add_dev() keeps the matched "sound" child pointer after
for_each_child_of_node() has dropped the iterator reference. Take an
extra reference before saving that node and drop it after the
layout-id/device-id lookup is complete.
The function also stores np in dev->sound.ofdev.dev.of_node without
taking a reference for the embedded soundbus device. Since i2sbus
overrides the embedded platform device release callback, balance that
reference explicitly in the local error path and in i2sbus_release_dev().
wangdicheng [Mon, 30 Mar 2026 05:41:31 +0000 (13:41 +0800)]
ALSA: hda/cs8409: Fix error message in cs8409_i2c_bulk_read()
The error message in cs8409_i2c_bulk_read() incorrectly says "I2C Bulk
Write Failed" when it should say "I2C Bulk Read Failed". This is a
copy-paste error from cs8409_i2c_bulk_write().
Berk Cem Goksel [Sun, 29 Mar 2026 13:38:25 +0000 (16:38 +0300)]
ALSA: caiaq: fix stack out-of-bounds read in init_card
The loop creates a whitespace-stripped copy of the card shortname
where `len < sizeof(card->id)` is used for the bounds check. Since
sizeof(card->id) is 16 and the local id buffer is also 16 bytes,
writing 16 non-space characters fills the entire buffer,
overwriting the terminating nullbyte.
When this non-null-terminated string is later passed to
snd_card_set_id() -> copy_valid_id_string(), the function scans
forward with `while (*nid && ...)` and reads past the end of the
stack buffer, reading the contents of the stack.
A USB device with a product name containing many non-ASCII, non-space
characters (e.g. multibyte UTF-8) will reliably trigger this as follows:
BUG: KASAN: stack-out-of-bounds in copy_valid_id_string
sound/core/init.c:696 [inline]
BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c
sound/core/init.c:718
The off-by-one has been present since commit bafeee5b1f8d ("ALSA:
snd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1),
which first introduced this whitespace-stripping loop. The original
code never accounted for the null terminator when bounding the copy.
Fix this by changing the loop bound to `sizeof(card->id) - 1`,
ensuring at least one byte remains as the null terminator.
Fixes: bafeee5b1f8d ("ALSA: snd_usb_caiaq: give better shortname") Cc: stable@vger.kernel.org Cc: Andrey Konovalov <andreyknvl@gmail.com> Reported-by: Berk Cem Goksel <berkcgoksel@gmail.com> Signed-off-by: Berk Cem Goksel <berkcgoksel@gmail.com> Link: https://patch.msgid.link/20260329133825.581585-1-berkcgoksel@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
Uros Bizjak [Mon, 30 Mar 2026 05:57:45 +0000 (07:57 +0200)]
x86/asm/segment: Implement loadsegment()/savesegment() macros with static inline helpers
Convert the __loadsegment_simple() and savesegment() macro
implementations into static inline helper functions generated
via small helper macros.
Historically loadsegment() and savesegment() relied on macros that
embedded inline assembly. This approach obscures types, complicates
debugging, and makes the call sites harder for the compiler and static
analysis tools to reason about.
This change is purely mechanical and does not alter the generated code,
but improves readability, type safety, and compiler visibility of the
helpers.
Suggested-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://patch.msgid.link/20260330055823.5793-4-ubizjak@gmail.com
Uros Bizjak [Mon, 30 Mar 2026 05:57:44 +0000 (07:57 +0200)]
x86/asm/segment: Use ASM_INPUT_RM in __loadsegment_fs()
Use the ASM_INPUT_RM macro in __loadsegment_fs() to work around Clang
problems with the "rm" asm constraint. Clang seems to always chose the
memory input, while it is almost always the worst choice.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Nathan Chancellor <nathan@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Link: https://patch.msgid.link/20260330055823.5793-3-ubizjak@gmail.com
Uros Bizjak [Mon, 30 Mar 2026 05:57:43 +0000 (07:57 +0200)]
x86/asm/segment: Remove unnecessary "memory" clobber from savesegment()
The savesegment() macro uses inline assembly to copy a segment register
into a general-purpose register:
movl %seg, reg
This instruction does not access memory, yet the inline asm currently
declares a "memory" clobber, which unnecessarily acts as a compiler
barrier and may inhibit optimization.
Remove the "memory" clobber and mark the asm as `asm volatile` instead.
Segment register loads in the kernel are implemented using `asm volatile`,
so the compiler will not schedule segment register reads before those
loads. Using `asm volatile` preserves the intended ordering with other
segment register operations without imposing an unnecessary global memory
barrier.
No functional change intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Link: https://patch.msgid.link/20260330055823.5793-2-ubizjak@gmail.com
Uros Bizjak [Mon, 30 Mar 2026 05:57:42 +0000 (07:57 +0200)]
x86/asm/fsgsbase: Remove unnecessary "memory" clobbers from FS/GS base (read-) accessors
The rdfsbase() and rdgsbase() helpers currently include a "memory"
clobber in their inline assembly definitions. However, the RDFSBASE
and RDGSBASE instructions only read the FS/GS base MSRs into a
general-purpose register and do not access memory. The "memory" clobber,
which acts as a compiler barrier and may inhibit optimization,
is therefore unnecessary.
The "memory" clobber was historically used as a scheduling constraint
to prevent the compiler from moving the instructions before preceding
segment register loads. This is not required because both the segment
register loads and the RDFSBASE/RDGSBASE accessors are implemented
with `asm volatile`, which already prevents reordering between them.
No functional change intended.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Link: https://patch.msgid.link/20260330055823.5793-1-ubizjak@gmail.com
projects / thirdparty / linux.git / log
