| Age | Commit message (Collapse) | Author |
|---|
|
OF_GPIO is automatically enabled on all OF systems. There's no need to
select it explicitly.
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Link: https://patch.msgid.link/20260304-gpio-of-kconfig-v1-3-d597916e79e7@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
OF_GPIO is automatically enabled on all OF systems. There's no need to
select it explicitly.
Acked-by: Vineet Gupta <vgupta@kernel.org>
Link: https://patch.msgid.link/20260304-gpio-of-kconfig-v1-2-d597916e79e7@oss.qualcomm.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
|
|
Previously the UART rely on external bootloader to initialize clock,
pinctrl and reset, to solve this, explicitly adding those resource in
Device Tree, so UART driver will handle them properly.
Link: https://lore.kernel.org/r/20260304-01-dts-uart-full-v1-4-50a0aa53a245@kernel.org
Signed-off-by: Yixun Lan <dlan@kernel.org>
|
|
Add GPIO node in the Device Tree, so devices are able to request GPIO
resource properly.
Link: https://lore.kernel.org/r/20260304-01-dts-uart-full-v1-3-50a0aa53a245@kernel.org
Signed-off-by: Yixun Lan <dlan@kernel.org>
|
|
Populate pinctrl node in Device Tree for SpacemiT K3 SoC, So devices
can request pinctrl resource properly.
Link: https://lore.kernel.org/r/20260304-01-dts-uart-full-v1-2-50a0aa53a245@kernel.org
Signed-off-by: Yixun Lan <dlan@kernel.org>
|
|
Add clock support to SpacemiT K3 SoC, the clock tree consist of several
blocks which are APBC, APMU, DCIU, MPUM.
Link: https://lore.kernel.org/r/20260304-01-dts-uart-full-v1-1-50a0aa53a245@kernel.org
Signed-off-by: Yixun Lan <dlan@kernel.org>
|
|
Add the wakeup-source property to the ST1232 touchscreen node in the
device tree so that the touchscreen interrupt can wake the system from
suspend when the panel is touched.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260309000319.74880-3-phucduc.bui@gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
The Armadillo-800EVA board provides an SD card slot and an AWL13 SDIO
interface connected to the SDHI1 controller. Routing between these two
interfaces is controlled by a mechanical DIP switch and a set of
multiplexers.
To support this, add:
- A fixed 3.3V regulator for SDHI1 power, controlled by PORT16 (G2),
- SDHI1 pinmux groups for data, control, and card detection,
- A gpio-hog for PORT6 (J5) to control the SDHI1/AWLAN multiplexer.
PORT176 (N21) is already configured as output-high in this DTS (via
lcd0-mux-hog), routing the SDSLOT2_ENABLE signal to PORT6. Since the
hardware includes an external 10k pull-up resistor (R94) on this line,
PORT6 is configured as an input to allow the physical DIP switch to
determine the routing without SoC interference.
Both configurations have been verified:
- SD card (CON8): detected as mmcblk1, high-speed SDHC,
- SDIO (CON14): detected as mmc1, high-speed SDIO.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260224074532.60046-1-phucduc.bui@gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable the configurations needed for Aquila AM69 SoM and compatible
carrier boards.
- CONFIG_SENSORS_AMC6821, needed for the fan controller on the clover
and dev carrier board (as module).
- CONFIG_POWER_RESET_GPIO and CONFIG_POWER_RESET_GPIO_RESTART needed
for poweroff and restart functionalities (as built-in, it's not
possible to set them as 'm').
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://patch.msgid.link/20260306153130.102972-1-francesco@dolcini.it
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Remove the SENSORS_SA67MCU from the defconfig because the driver was
removed.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://patch.msgid.link/20260302122540.1377444-3-mwalle@kernel.org
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
The pin for GPMC0_CLK.GPIO0_31 at address 0x000F407C is N22 and not M19.
Hence, fix the pin name in the comment to avoid confusion.
Fixes: 8f023012eb4a ("arm64: dts: ti: k3-am62a: Enable UHS mode support for SD cards")
Cc: stable@vger.kernel.org
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Andrew Davis <afd@ti.com>
Reviewed-by: Bryan Brattlof <bb@ti.com>
Link: https://patch.msgid.link/20260309045539.2070793-1-s-vadapalli@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Commit a75b2be249d6 ("iommu: Add iommu_driver_get_domain_for_dev()
helper") introduced iommu_driver_get_domain_for_dev() for driver
code paths that hold iommu_group->mutex while attaching a device
to an IOMMU domain.
The same commit also added a lockdep assertion in
iommu_get_domain_for_dev() to ensure that callers do not hold
iommu_group->mutex when invoking it.
On powerpc platforms, when PCI device ownership is switched from
BLOCKED to the PLATFORM domain, the attach callback
spapr_tce_platform_iommu_attach_dev() still calls
iommu_get_domain_for_dev(). This happens while iommu_group->mutex
is held during domain switching, which triggers the lockdep warning
below during PCI enumeration:
WARNING: drivers/iommu/iommu.c:2252 at iommu_get_domain_for_dev+0x38/0x80, CPU#2: swapper/0/1
Modules linked in:
CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc2+ #35 PREEMPT
Hardware name: IBM,9105-22A Power11 (architected) 0x820200 0xf000007 of:IBM,FW1120.00 (RB1120_115) hv:phyp pSeries
NIP: c000000000c244c4 LR: c00000000005b5a4 CTR: c00000000005b578
REGS: c00000000a7bf280 TRAP: 0700 Not tainted (7.0.0-rc2+)
MSR: 8000000002029033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 22004422 XER: 0000000a
CFAR: c000000000c24508 IRQMASK: 0
GPR00: c00000000005b5a4 c00000000a7bf520 c000000001dc8100 0000000000000001
GPR04: c00000000f972f10 0000000000000000 0000000000000000 0000000000000001
GPR08: 0000001ffbc60000 0000000000000001 0000000000000000 0000000000000000
GPR12: c00000000005b578 c000001fffffe480 c000000000011618 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: ffffffffffffefff 0000000000000000 c000000002d30eb0 0000000000000001
GPR24: c0000000017881f8 0000000000000000 0000000000000001 c00000000f972e00
GPR28: c00000000bbba0d0 0000000000000000 c00000000bbba0d0 c00000000f972e00
NIP [c000000000c244c4] iommu_get_domain_for_dev+0x38/0x80
LR [c00000000005b5a4] spapr_tce_platform_iommu_attach_dev+0x2c/0x98
Call Trace:
iommu_get_domain_for_dev+0x68/0x80 (unreliable)
spapr_tce_platform_iommu_attach_dev+0x2c/0x98
__iommu_attach_device+0x44/0x220
__iommu_device_set_domain+0xf4/0x194
__iommu_group_set_domain_internal+0xec/0x228
iommu_setup_default_domain+0x5f4/0x6a4
__iommu_probe_device+0x674/0x724
iommu_probe_device+0x50/0xb4
iommu_add_device+0x48/0x198
pci_dma_dev_setup_pSeriesLP+0x198/0x4f0
pcibios_bus_add_device+0x80/0x464
pci_bus_add_device+0x40/0x100
pci_bus_add_devices+0x54/0xb0
pcibios_init+0xd8/0x140
do_one_initcall+0x8c/0x598
kernel_init_freeable+0x3ec/0x850
kernel_init+0x34/0x270
ret_from_kernel_user_thread+0x14/0x1c
Fix this by using iommu_driver_get_domain_for_dev() instead of
iommu_get_domain_for_dev() in spapr_tce_platform_iommu_attach_dev(),
which is the appropriate helper for callers holding the group mutex.
Cc: stable@vger.kernel.org
Fixes: a75b2be249d6 ("iommu: Add iommu_driver_get_domain_for_dev() helper")
Closes: https://patchwork.ozlabs.org/project/linuxppc-dev/patch/d5c834ff-4c95-44dd-8bef-57242d63aeee@linux.ibm.com/
Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
[Maddy: Added Closes, tested and reviewed by tags]
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260310082129.3630996-1-nilay@linux.ibm.com
|
|
The declaration in the pinmux device for the pinctrl registers is not
correct. These registers are actually 32 bits wide, not 16. Also the
mask for functional bits is also wrong. Functional bits are 0-4, not
0-3. So the mask needs to changed to 0x1f.
This information is taken from the TMS320DM816x DaVinci
Digital Media Processors Technical Reference Manual.
SPRUGX8C March 2015
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org>
Link: https://patch.msgid.link/20260312-dm816x_dt-v1-1-ed3370b20799@linaro.org
[khilman: fix minor typo: s/delcaration/declaration/]
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux into features
Add s390 support for CONFIG_PAGE_TABLE_CHECK.
* 'page-table-check-support' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: Enable page table check for debug_defconfig
s390/pgtable: Add s390 support for page table check
s390/pgtable: Use set_pmd_bit() to invalidate PMD entry
mm/page_table_check: Pass mm_struct to pxx_user_accessible_page()
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Link: https://lore.kernel.org/r/975007c27f8563e46d66a1fbb4b14ae6a4147edd.1772812343.git.agordeev@linux.ibm.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Add page table check hooks into routines that modify user page
tables.
Unlike other architectures s390 does not have means to distinguish
between kernel and user page table entries. Rely on the fact the
page table check infrastructure itself operates on non-init_mm
memory spaces only.
Use the provided mm_struct to verify that the memory space is not
init_mm (aka not the kernel memory space) indeed. That check is
supposed to be succeeded already (on some code paths even twice).
If the passed memory space by contrast is init_mm that would be an
unexpected semantical change in generic code, so do VM_BUG_ON() in
such case.
Unset _SEGMENT_ENTRY_READ bit to indicate that pmdp_invalidate()
was applied against a huge PMD and is going to be updated by
set_pmd_at() shortly. The hook pmd_user_accessible_page() should
skip such entries until that, otherwise the page table accounting
falls apart and BUG_ON() gets hit as result.
The invalidated huge PMD entry should not be confused with a PROT_NONE
entry as reported by pmd_protnone(), though the entry characteristics
exactly match: _SEGMENT_ENTRY_LARGE is set while _SEGMENT_ENTRY_READ is
unset. Since pmd_protnone() implementation depends on NUMA_BALANCING
configuration option, it should not be used in pmd_user_accessible_page()
check, which is expected to be CONFIG_NUMA_BALANCING-agnostic.
Nevertheless, an invalidated huge PMD is technically still pmd_protnone()
entry and it should not break other code paths once _SEGMENT_ENTRY_READ
is unset. As of now, all pmd_protnone() checks are done under page table
locks or exercise GUP-fast and HMM code paths, which are expected to be
safe against concurrent page table updates.
Alternative approach would be using the last remaining unused PMD entry
bit 0x800 to indicate that pmdp_invalidate() was called on a PMD. That
would allow avoiding collisions with pmd_protnone() handling code paths,
but saving the bit is more preferable way to go.
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Co-developed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Link: https://lore.kernel.org/r/4db8a681205bd555298d62441cdcfca43317a35a.1772812343.git.agordeev@linux.ibm.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Commit 3a5a8d343e1c ("mm: fix race between __split_huge_pmd_locked()
and GUP-fast") failed to follow the convention and used direct PMD
entry modification instead of set_pmd_bit().
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Link: https://lore.kernel.org/r/a9248694a38cc898d3f0628f59b8abb57d56a416.1772812343.git.agordeev@linux.ibm.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
Unlike other architectures, s390 does not have means to
distinguish kernel vs user page table entries - neither
an entry itself, nor the address could be used for that.
It is only the mm_struct that indicates whether an entry
in question is mapped to a user space. So pass mm_struct
to pxx_user_accessible_page() callbacks.
[agordeev@linux.ibm.com: rephrased commit message, removed braces]
Acked-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> #powerpc
Signed-off-by: Tobias Huschle <huschle@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Link: https://lore.kernel.org/r/ca77f3489453c2fe01b25e50e53b778929e0dfc5.1772812343.git.agordeev@linux.ibm.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
|
|
These allow selective muting/unmuting of inputs and outputs, as well as
setting mutually-exclusive rules in ALSA UCM.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Link: https://patch.msgid.link/20260311-evb1-audio-switches-v1-1-0e0199e56c80@flipper.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Advertise AVX512 Bit Matrix Multiply (BMM) and Bit Reversal instructions to
userspace via CPUID leaf 0x80000021_EAX[23]. This feature enables bit
matrix multiply operations and bit reversal. Like most AVX instructions,
there are no intercept controls for individual instructions, and no extra
work is needed in KVM to enable correct execution of the instructions in
the guest.
The instructions and CPUID feature are first described in:
AMD64 Bit Matrix Multiply and Bit Reversal Instructions
Publication #69192 Revision: 1.00
Issue Date: January 2026
While at it, reorder PREFETCHI in KVM's initialization sequence to match
the CPUID bit position order for better organization.
Signed-off-by: Nikunj A Dadhania <nikunj@amd.com>
Link: https://patch.msgid.link/20260210053511.1612505-1-nikunj@amd.com
[sean: massage changelog]
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
missing
Guard usage of the must-be-defined macros in KVM's multi-include headers
with the existing #ifdefs that attempt to alert the developer to a missing
macro, and spit out an explicit #error message if a macro is missing, as
referencing the missing macro completely defeats the purpose of the #ifdef
(the compiler spews a ton of error messages and buries the targeted error
message).
Suggested-by: Alexey Dobriyan <adobriyan@gmail.com>
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Link: https://patch.msgid.link/20260302212619.710873-1-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Commit 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with
flexible-array members") broke the userspace API for C++.
These structures ending in VLAs are typically a *header*, which can be
followed by an arbitrary number of entries. Userspace typically creates
a larger structure with some non-zero number of entries, for example in
QEMU's kvm_arch_get_supported_msr_feature():
struct {
struct kvm_msrs info;
struct kvm_msr_entry entries[1];
} msr_data = {};
While that works in C, it fails in C++ with an error like:
flexible array member 'kvm_msrs::entries' not at end of 'struct msr_data'
Fix this by using __DECLARE_FLEX_ARRAY() for the VLA, which uses [0]
for C++ compilation.
Fixes: 94dfc73e7cf4 ("treewide: uapi: Replace zero-length arrays with flexible-array members")
Cc: stable@vger.kernel.org
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Link: https://patch.msgid.link/3abaf6aefd6e5efeff3b860ac38421d9dec908db.camel@infradead.org
[sean: tag for stable@]
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Use the large-page metadata to avoid pointless attempts to search SP.
If the target GFN falls within a range where a large page is allowed,
then there cannot be a shadow page for that GFN; a shadow page in the
range would itself disallow using a large page. In that case, there
is nothing to unsync and mmu_try_to_unsync_pages() can return
immediately.
This is always true for TDP MMU without nested TDP, and holds for a
significant fraction of cases with shadow paging even all SPs are 4K.
For shadow paging, this optimization theoretically avoids work for about
1/e ~= 37% of GFNs, assuming one guest page table per 2M of memory and
that each GPT falls randomly into the 2M memory buckets. In a simple
test setup, it skipped unsync in a much higher percentage of cases,
mainly because the guest buddy allocator clusters GPTs into fewer
buckets.
Signed-off-by: Lai Jiangshan <jiangshan.ljs@antgroup.com>
Link: https://patch.msgid.link/20260123090304.32286-2-jiangshanlai@gmail.com
[sean: check for hugepage after write-tracking, update comment]
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
The __pv_send_ipi() function iterates over up to BITS_PER_LONG vCPUs
starting from the APIC ID specified in its 'min' argument, which is
provided by the guest.
Commit c87bd4dd43a6 used array_index_nospec() to clamp the value of 'min'
but then the for_each_set_bit() loop dereferences higher indices without
further protection. Theoretically, a guest can trigger speculative access
to up to BITS_PER_LONG elements off the end of the phys_map[] array.
(In practice it would probably need aggressive loop unrolling by the
compiler to go more than one element off the end, and even that seems
unlikely, but the theoretical possibility exists.)
Move the array_index_nospec() inside the loop to protect the [map + i]
index which is actually being used each time.
Fixes: c87bd4dd43a6 ("KVM: x86: use array_index_nospec with indices that come from guest")
Fixes: bdf7ffc89922 ("KVM: LAPIC: Fix pv ipis out-of-bounds access")
Fixes: 4180bf1b655a ("KVM: X86: Implement "send IPI" hypercall")
Signed-off-by: Anel Orazgaliyeva <anelkz@amazon.de>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Jim Mattson <jmattson@google.com>
Link: https://patch.msgid.link/9d50fc3ca9e8e58f551d015f95d51a3c29ce6ccc.camel@infradead.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
kvm_apic_write_nodecode() dereferences vcpu->arch.apic without first
checking whether the in-kernel LAPIC has been initialized. If it has
not (e.g. the vCPU was created without an in-kernel LAPIC), the
dereference results in a NULL pointer access.
While APIC-write VM-Exits are not expected to occur on a vCPU without
an in-kernel LAPIC, kvm_apic_write_nodecode() should be robust against
such a scenario as a defense-in-depth measure, e.g. to guard against
KVM bugs or CPU errata that could generate a spurious APIC-write
VM-Exit.
Use KVM_BUG_ON() with lapic_in_kernel() instead of a simple
WARN_ON_ONCE(), as suggested by Sean Christopherson, so that KVM
kills the VM outright rather than letting it continue in a broken
state.
Found by a VMCS-targeted fuzzer based on syzkaller.
Signed-off-by: xuanqingshi <1356292400@qq.com>
Link: https://patch.msgid.link/tencent_7A9F1B4D75468C0CF5DE1B6902038C948B07@qq.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Drop redundant parentheses; the & operator has higher precedence than the
return statement's implicit evaluation, making the grouping redundant.
Signed-off-by: Xin Li <xin@zytor.com>
Link: https://patch.msgid.link/20260306231253.2177246-1-xin@zytor.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Instead of checking that the hardware supports underlying features for
EFER bits, check if KVM supports them. It is practically the same, but
this removes a subtle dependency on kvm_set_cpu_caps() enabling the
relevant CPUID features.
No functional change intended.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
Link: https://patch.msgid.link/20260307011619.2324234-3-yosry@kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Move EFER bits enablement that only depend on CPU support to common
code, as there is no reason to do it in vendor code. Leave EFER.SVME and
EFER.LMSLE enablement in SVM code as they depend on vendor module
parameters.
Having the enablement in common code ensures that if a vendor starts
supporting an existing feature, KVM doesn't end up advertising to
userspace but not allowing the EFER bit to be set.
No functional change intended.
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Yosry Ahmed <yosry@kernel.org>
Link: https://patch.msgid.link/20260307011619.2324234-2-yosry@kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Selecting CONFIG_TRACE_REMOTE causes a build time warning when FTRACE
is disabled:
WARNING: unmet direct dependencies detected for TRACE_REMOTE
Depends on [n]: FTRACE [=n]
Selected by [y]:
- NVHE_EL2_TRACING [=y] && VIRTUALIZATION [=y] && KVM [=y] && NVHE_EL2_DEBUG [=y] && TRACING [=y]
Add this as another dependency to ensure a clean build.
Fixes: 3aed038aac8d ("KVM: arm64: Add trace remote for the nVHE/pKVM hyp")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Link: https://patch.msgid.link/20260312123601.625063-3-arnd@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
|
|
Move the SRAM node into the SoC node. Move the memory node out of
the include to make it customizable for each platform variant.
Signed-off-by: Debbie Horsfall <debbie.horsfall@arm.com>
Message-Id: <20260311173948.3478931-1-debbie.horsfall@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
|
|
The gpio-ranges in the MT7986A pinctrl node were incorrectly defined,
therefore, pin 100 cannot be used.
Correct the range count to match the driver.
Fixes: c3a064a32ed9 ("arm64: dts: mediatek: add pinctrl support for mt7986a")
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The gpio-ranges in the MT7981B pinctrl node were incorrectly defined,
therefore, pin 56 cannot be used.
Correct the range count to match the driver.
Fixes: 62b24c7fdf0a ("arm64: dts: mediatek: mt7981: add pinctrl")
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
The gpio-ranges in the MT6795 pinctrl node were incorrectly defined,
therefore, GPIO196 cannot be used.
Correct the range count to match the driver.
Fixes: b888886a4536 ("arm64: dts: mediatek: mt6795: Add pinctrl controller node")
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Introduce CC_FLAGS_DIALECT to make it easier to update the various
places in the tree that rely on the GNU C standard and Microsoft
extensions flags atomically. All remaining uses of '-std=gnu11' and
'-fms-extensions' are in the tools directory (which has its own build
system) and other standalone Makefiles. This will allow the kernel to
use a narrower option to enable the Microsoft anonymous tagged structure
extension in a simpler manner. Place the CC_FLAGS_DIALECT block after
the configuration include (so that a future change can move the
selection of the flag to Kconfig) but before the
arch/$(SRCARCH)/Makefile include (so that CC_FLAGS_DIALECT is available
for use in those Makefiles).
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Link: https://patch.msgid.link/20260223-fms-anonymous-structs-v1-1-8ee406d3c36c@kernel.org
Signed-off-by: Nicolas Schier <nsc@kernel.org>
|
|
__aligned() is a kernel macro, which is not available in UAPI headers.
Use the compiler-provided alignment attribute directly.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
Tested-by: Nicolas Schier <nsc@kernel.org>
Link: https://patch.msgid.link/20260227-kbuild-uapi-libc-v1-1-c17de0d19776@weissschuh.net
Signed-off-by: Nicolas Schier <nsc@kernel.org>
|
|
Unconditionally setting the CLOCK_SOURCE_VALID_FOR_HRES for the real TSC
clocksource is wrong as there is no guarantee that the early TSC was
validated for high resolution mode.
Set the flag only when the early TSC was validated as otherwise the
clocksource selection might enable high resolution mode with a TSC of
unknown quality and possibly no way to back out once it is discovered to be
unsuitable.
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260123231521.790598171@kernel.org
|
|
MIPS selects CLOCKSOURCE_WATCHDOG, but none of the clocksources actually
sets the MUST_VERIFY flag. So compiling the watchdog in is a pointless
exercise. Remove the selects.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Link: https://patch.msgid.link/20260123231521.723433371@kernel.org
|
|
PARISC does not enable the clocksource watchdog, so the VERIFY flags are
pointless as they are not evaluated. Remove them from the clocksource.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patch.msgid.link/20260123231521.655892451@kernel.org
|
|
Make use of the interrupts wired to the Micrel PHYs via the GPIO IRQ
mux.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260311200307.16034-2-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Node names should not contain underscores; replace them by hyphens.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patch.msgid.link/1c1fc11f1f183a8e72f168bf6eb35a40e01ecacb.1773240961.git.geert+renesas@glider.be
|
|
Enable the QSPI controller to access the connected SPI NOR flash. The
NOR datasheet may suggest faster tuning parameters but those did not
work on my board.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260305220023.28257-2-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable DMA support for RSPI channels.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260303233314.2928711-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable DMA support for RSPI channels.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260303233314.2928711-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add a node describing the QSPI controller.
There are 2 clocks feeding this controller:
- one for the reference clock
- one that feeds both the ahb and the apb interfaces
As the binding expect either the ref clock, or all three (ref, ahb and
apb) clocks, it makes sense to provide the same clock twice.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260205-schneider-6-19-rc1-qspi-v5-4-843632b3c674@bootlin.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
It's good enough to only check GP counters for PEBS constraints
validation since constraints overlap can only happen on GP counters.
Besides opportunistically refine the code style and use pr_warn() to
replace pr_info() as the message itself is a warning message.
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260228053320.140406-1-dapeng1.mi@linux.intel.com
|
|
When omr_source is 0x2, the omr_snoop (bit[6]) and omr_promoted (bit[7])
fields are combined to represent the snoop information. However, the
omr_promoted field was not left-shifted by 1 bit, resulting in incorrect
snoop information.
Besides, the snoop information parsing is not accurate for some OMR
sources, like the snoop information should be SNOOP_NONE for these memory
access (omr_source >= 7) instead of SNOOP_HIT.
Fix these issues.
Closes: https://lore.kernel.org/all/CAP-5=fW4zLWFw1v38zCzB9-cseNSTTCtup=p2SDxZq7dPayVww@mail.gmail.com/
Fixes: d2bdcde9626c ("perf/x86/intel: Add support for PEBS memory auxiliary info field in DMR")
Reported-by: Ian Rogers <irogers@google.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ian Rogers <irogers@google.com>
Link: https://patch.msgid.link/20260311075201.2951073-1-dapeng1.mi@linux.intel.com
|
|
When running the command:
'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1',
a "shift-out-of-bounds" warning is reported on CWF.
UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15
shift exponent 64 is too large for 64-bit type 'long long unsigned int'
......
intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7
intel_pmu_lbr_save_brstack+0xc0/0x4c0
setup_arch_pebs_sample_data+0x114b/0x2400
The warning occurs because the second "instructions:p" event, which
involves branch counters sampling, is incorrectly programmed to fixed
counter 0 instead of the general-purpose (GP) counters 0-3 that support
branch counters sampling. Currently only GP counters 0-3 support branch
counters sampling on CWF, any event involving branch counters sampling
should be programed on GP counters 0-3. Since the counter index of fixed
counter 0 is 32, it leads to the "src" value in below code is right
shifted 64 bits and trigger the "shift-out-of-bounds" warning.
cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK;
The root cause is the loss of the branch counters constraint for the
new event in the branch counters sampling event group. Since it isn't
yet part of the sibling list. This results in the second
"instructions:p" event being programmed on fixed counter 0 incorrectly
instead of the appropriate GP counters 0-3.
To address this, we apply the missing branch counters constraint for
the last event in the group. Additionally, we introduce a new function,
`intel_set_branch_counter_constr()`, to apply the branch counters
constraint and avoid code duplication.
Fixes: 33744916196b ("perf/x86/intel: Support branch counters logging")
Reported-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260228053320.140406-2-dapeng1.mi@linux.intel.com
Cc: stable@vger.kernel.org
|
|
Both Mi Dapeng and Ian Rogers noted that not everything that sets HES_STOPPED
is required to EF_UPDATE. Specifically the 'step 1' loop of rescheduling
explicitly does EF_UPDATE to ensure the counter value is read.
However, then 'step 2' simply leaves the new counter uninitialized when
HES_STOPPED, even though, as noted above, the thing that stopped them might not
be aware it needs to EF_RELOAD -- since it didn't EF_UPDATE on stop.
One such location that is affected is throttling, throttle does pmu->stop(, 0);
and unthrottle does pmu->start(, 0); possibly restarting an uninitialized counter.
Fixes: a4eaf7f14675 ("perf: Rework the PMU methods")
Reported-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Reported-by: Ian Rogers <irogers@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Link: https://patch.msgid.link/20260311204035.GX606826@noisy.programming.kicks-ass.net
|
|
A production AMD EPYC system crashed with a NULL pointer dereference
in the PMU NMI handler:
BUG: kernel NULL pointer dereference, address: 0000000000000198
RIP: x86_perf_event_update+0xc/0xa0
Call Trace:
<NMI>
amd_pmu_v2_handle_irq+0x1a6/0x390
perf_event_nmi_handler+0x24/0x40
The faulting instruction is `cmpq $0x0, 0x198(%rdi)` with RDI=0,
corresponding to the `if (unlikely(!hwc->event_base))` check in
x86_perf_event_update() where hwc = &event->hw and event is NULL.
drgn inspection of the vmcore on CPU 106 showed a mismatch between
cpuc->active_mask and cpuc->events[]:
active_mask: 0x1e (bits 1, 2, 3, 4)
events[1]: 0xff1100136cbd4f38 (valid)
events[2]: 0x0 (NULL, but active_mask bit 2 set)
events[3]: 0xff1100076fd2cf38 (valid)
events[4]: 0xff1100079e990a90 (valid)
The event that should occupy events[2] was found in event_list[2]
with hw.idx=2 and hw.state=0x0, confirming x86_pmu_start() had run
(which clears hw.state and sets active_mask) but events[2] was
never populated.
Another event (event_list[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH),
showing it was stopped when the PMU rescheduled events, confirming the
throttle-then-reschedule sequence occurred.
The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access
and potential PEBS record loss") which moved the cpuc->events[idx]
assignment out of x86_pmu_start() and into step 2 of x86_pmu_enable(),
after the PERF_HES_ARCH check. This broke any path that calls
pmu->start() without going through x86_pmu_enable() -- specifically
the unthrottle path:
perf_adjust_freq_unthr_events()
-> perf_event_unthrottle_group()
-> perf_event_unthrottle()
-> event->pmu->start(event, 0)
-> x86_pmu_start() // sets active_mask but not events[]
The race sequence is:
1. A group of perf events overflows, triggering group throttle via
perf_event_throttle_group(). All events are stopped: active_mask
bits cleared, events[] preserved (x86_pmu_stop no longer clears
events[] after commit 7e772a93eb61).
2. While still throttled (PERF_HES_STOPPED), x86_pmu_enable() runs
due to other scheduling activity. Stopped events that need to
move counters get PERF_HES_ARCH set and events[old_idx] cleared.
In step 2 of x86_pmu_enable(), PERF_HES_ARCH causes these events
to be skipped -- events[new_idx] is never set.
3. The timer tick unthrottles the group via pmu->start(). Since
commit 7e772a93eb61 removed the events[] assignment from
x86_pmu_start(), active_mask[new_idx] is set but events[new_idx]
remains NULL.
4. A PMC overflow NMI fires. The handler iterates active counters,
finds active_mask[2] set, reads events[2] which is NULL, and
crashes dereferencing it.
Move the cpuc->events[hwc->idx] assignment in x86_pmu_enable() to
before the PERF_HES_ARCH check, so that events[] is populated even
for events that are not immediately started. This ensures the
unthrottle path via pmu->start() always finds a valid event pointer.
Fixes: 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss")
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260310-perf-v2-1-4a3156fce43c@debian.org
|
|
On powerpc with PREEMPT_FULL or PREEMPT_LAZY and function tracing enabled,
KUAP warnings can be triggered from the VMX usercopy path under memory
stress workloads.
KUAP requires that no subfunctions are called once userspace access has
been enabled. The existing VMX copy implementation violates this
requirement by invoking enter_vmx_usercopy() from the assembly path after
userspace access has already been enabled. If preemption occurs
in this window, the AMR state may not be preserved correctly,
leading to unexpected userspace access state and resulting in
KUAP warnings.
Fix this by restructuring the VMX usercopy flow so that VMX selection
and VMX state management are centralized in raw_copy_tofrom_user(),
which is invoked by the raw_copy_{to,from,in}_user() wrappers.
The new flow is:
- raw_copy_{to,from,in}_user() calls raw_copy_tofrom_user()
- raw_copy_tofrom_user() decides whether to use the VMX path
based on size and CPU capability
- Call enter_vmx_usercopy() before enabling userspace access
- Enable userspace access as per the copy direction
and perform the VMX copy
- Disable userspace access as per the copy direction
- Call exit_vmx_usercopy()
- Fall back to the base copy routine if the VMX copy faults
With this change, the VMX assembly routines no longer perform VMX state
management or call helper functions; they only implement the
copy operations.
The previous feature-section based VMX selection inside
__copy_tofrom_user_power7() is removed, and a dedicated
__copy_tofrom_user_power7_vmx() entry point is introduced.
This ensures correct KUAP ordering, avoids subfunction calls
while KUAP is unlocked, and eliminates the warnings while preserving
the VMX fast path.
Fixes: de78a9c42a79 ("powerpc: Add a framework for Kernel Userspace Access Protection")
Reported-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Closes: https://lore.kernel.org/all/20260109064917.777587-2-sshegde@linux.ibm.com/
Suggested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Co-developed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Signed-off-by: Sayali Patil <sayalip@linux.ibm.com>
Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260304122201.153049-1-sayalip@linux.ibm.com
|
