Document support for the Expanded Serial Peripheral Interface (xSPI)
controller found on the Renesas RZ/V2H(P) (R9A09G057) and RZ/V2N
(R9A09G056) SoCs.
The xSPI hardware block on these SoCs is functionally identical to the
one on the RZ/G3E (R9A09G047) SoC. Therefore, the existing driver can be
reused without modification by using `renesas,r9a09g047-xspi` as a
fallback compatible.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250624171605.469724-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Commit 6cb3b1c2df changed how finish_xmote() clears the GLF_LOCK flag,
but it failed to adjust the equivalent code in do_xmote(). Fix that.
Fixes: 6cb3b1c2df ("gfs2: Fix additional unlikely request cancelation race")
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
There are redundant codes in IS_CUR{SEG,SEC}() macros, let's introduce
inline is_cur{seg,sec}() functions, and use a loop in it for cleanup.
Meanwhile, it enhances expansibility, as it doesn't need to change
is_cur{seg,sec}() when we add a new log header.
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
We should use "{usr,grp,prj}jquota=" to disable journaled quota,
rather than using off{usr,grp,prj}jquota.
Fixes: 4b2414d04e ("f2fs: support journalled quota")
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
In function kvm_guest_time_update(), __scale_tsc() is used to calculate
a TSC *frequency* rather than a TSC value. With low-enough ratios,
a TSC value that is less than 1 would underflow to 0 and to an infinite
while loop in kvm_get_time_scale():
kvm_guest_time_update(struct kvm_vcpu *v)
if (kvm_caps.has_tsc_control)
tgt_tsc_khz = kvm_scale_tsc(tgt_tsc_khz,
v->arch.l1_tsc_scaling_ratio);
__scale_tsc(u64 ratio, u64 tsc)
ratio=122380531, tsc=2299998, N=48
ratio*tsc >> N = 0.999... -> 0
Later in the function:
Call Trace:
<TASK>
kvm_get_time_scale arch/x86/kvm/x86.c:2458 [inline]
kvm_guest_time_update+0x926/0xb00 arch/x86/kvm/x86.c:3268
vcpu_enter_guest.constprop.0+0x1e70/0x3cf0 arch/x86/kvm/x86.c:10678
vcpu_run+0x129/0x8d0 arch/x86/kvm/x86.c:11126
kvm_arch_vcpu_ioctl_run+0x37a/0x13d0 arch/x86/kvm/x86.c:11352
kvm_vcpu_ioctl+0x56b/0xe60 virt/kvm/kvm_main.c:4188
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:871 [inline]
__se_sys_ioctl+0x12d/0x190 fs/ioctl.c:857
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x59/0x110 arch/x86/entry/common.c:81
entry_SYSCALL_64_after_hwframe+0x78/0xe2
This can really happen only when fuzzing, since the TSC frequency
would have to be nonsensically low.
Fixes: 35181e86df ("KVM: x86: Add a common TSC scaling function")
Reported-by: Yuntao Liu <liuyuntao12@huawei.com>
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Get rid of the GIF_ALLOC_FAILED flag; we can now be confident that the
additional consistency check isn't needed.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Use the SECTOR_SIZE and SECTOR_SHIFT constants where appropriate instead
of hardcoding their values.
Reported-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Jann Horn points out that epoll is decrementing the ep refcount and then
doing a
mutex_unlock(&ep->mtx);
afterwards. That's very wrong, because it can lead to a use-after-free.
That pattern is actually fine for the very last reference, because the
code in question will delay the actual call to "ep_free(ep)" until after
it has unlocked the mutex.
But it's wrong for the much subtler "next to last" case when somebody
*else* may also be dropping their reference and free the ep while we're
still using the mutex.
Note that this is true even if that other user is also using the same ep
mutex: mutexes, unlike spinlocks, can not be used for object ownership,
even if they guarantee mutual exclusion.
A mutex "unlock" operation is not atomic, and as one user is still
accessing the mutex as part of unlocking it, another user can come in
and get the now released mutex and free the data structure while the
first user is still cleaning up.
See our mutex documentation in Documentation/locking/mutex-design.rst,
in particular the section [1] about semantics:
"mutex_unlock() may access the mutex structure even after it has
internally released the lock already - so it's not safe for
another context to acquire the mutex and assume that the
mutex_unlock() context is not using the structure anymore"
So if we drop our ep ref before the mutex unlock, but we weren't the
last one, we may then unlock the mutex, another user comes in, drops
_their_ reference and releases the 'ep' as it now has no users - all
while the mutex_unlock() is still accessing it.
Fix this by simply moving the ep refcount dropping to outside the mutex:
the refcount itself is atomic, and doesn't need mutex protection (that's
the whole _point_ of refcounts: unlike mutexes, they are inherently
about object lifetimes).
Reported-by: Jann Horn <jannh@google.com>
Link: https://docs.kernel.org/locking/mutex-design.html#semantics [1]
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add said functions to Documentation/memory-barriers.txt.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
--
v1 -> v2:
* Changed the prosaic part to kernel-doc style and moved it to
include/linux/wait.h in another commit
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Ensure that vSErrors taken in the guest have an appropriate ESR_ELx
value for the expected exception. Additionally, switch the EASE test to
install the SEA handler at the SError offset, as the ESR is still
expected to match an SEA in that case.
Link: https://lore.kernel.org/r/20250708230632.1954240-3-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The hardware vSError injection mechanism populates ESR_ELx.EC as part of
ESR propagation and the contents of VSESR_EL2 populate the ISS field. Of
course, this means our emulated injection needs to set up the EC
correctly for an SError too.
Fixes: ce66109cec ("KVM: arm64: nv: Take "masked" aborts to EL2 when HCRX_EL2.TMEA is set")
Link: https://lore.kernel.org/r/20250708230632.1954240-2-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
For a VCPU thread pinned to a single LPU, verify that interleaved host
and guest reads of IA32_[AM]PERF return strictly increasing values when
APERFMPERF exiting is disabled.
Run the test in both L1 and L2 to verify that KVM passes through the
APERF and MPERF MSRs when L1 doesn't want to intercept them (or any MSRs).
Signed-off-by: Jim Mattson <jmattson@google.com>
Link: https://lore.kernel.org/r/20250530185239.2335185-4-jmattson@google.com
Co-developed-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/r/20250626001225.744268-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Expand kvm_pin_this_task_to_pcpu() into a set of APIs to allow pinning a
task (or self) to a CPU (any or specific). This will allow deduplicating
code throughout a variety of selftests.
Opportunistically use "self" instead of "this_task" as it is both more
concise and less ambiguous.
Link: https://lore.kernel.org/r/20250626001225.744268-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Allow a guest to read the physical IA32_APERF and IA32_MPERF MSRs
without interception.
The IA32_APERF and IA32_MPERF MSRs are not virtualized. Writes are not
handled at all. The MSR values are not zeroed on vCPU creation, saved
on suspend, or restored on resume. No accommodation is made for
processor migration or for sharing a logical processor with other
tasks. No adjustments are made for non-unit TSC multipliers. The MSRs
do not account for time the same way as the comparable PMU events,
whether the PMU is virtualized by the traditional emulation method or
the new mediated pass-through approach.
Nonetheless, in a properly constrained environment, this capability
can be combined with a guest CPUID table that advertises support for
CPUID.6:ECX.APERFMPERF[bit 0] to induce a Linux guest to report the
effective physical CPU frequency in /proc/cpuinfo. Moreover, there is
no performance cost for this capability.
Signed-off-by: Jim Mattson <jmattson@google.com>
Link: https://lore.kernel.org/r/20250530185239.2335185-3-jmattson@google.com
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://lore.kernel.org/r/20250626001225.744268-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Advertise support for LKGS (load into IA32_KERNEL_GS_BASE) to userspace
if the instruction is supported by the underlying CPU.
LKGS is introduced with FRED to completely eliminate the need to swapgs
explicilty. It behaves like the MOV to GS instruction except that it
loads the base address into the IA32_KERNEL_GS_BASE MSR instead of the
GS segment’s descriptor cache, which is exactly what Linux kernel does
to load a user level GS base. Thus there is no need to SWAPGS away
from the kernel GS base.
LKGS is an independent CPU feature that works correctly in a KVM guest
without requiring explicit enablement.
Signed-off-by: Xin Li (Intel) <xin@zytor.com>
Link: https://lore.kernel.org/r/20250626173521.2301088-1-xin@zytor.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Add VMX_HOST_OWNED_DEBUGCTL_BITS to track which bits are host-owned, i.e.
need to be preserved when running the guest, to dedup the logic without
having to incur a memory load to get at kvm_x86_ops.HOST_OWNED_DEBUGCTL.
No functional change intended.
Suggested-by: Maxim Levitsky <mlevitsk@redhat.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/all/aF1yni8U6XNkyfRf@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
The logic would not catch if the test process crashes and would
incorrectly report a "success" state. Fix this by looking for the final
"Total number of errors:" message and printing "failure" if it was not
seen.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://lore.kernel.org/r/20250709155512.971080-2-benjamin@sipsolutions.net
[Thomas: fix patch prefix]
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
According to the z16 and z17 Principle of Operation documents
SA22-7832-13 and SA22-7832-14 the event 4210 is named
PCC_COMPUTE_LAST_BLOCK_CMAC_USING_ENCRYPTED_AES_256
without a trailing 'A'. Adjust the json definition files
for this event and remove the trailing 'A' character.
PCC_COMPUTE_LAST_BLOCK_CMAC_USING_ENCRYPTED_AES_256A
Also remove a black ' ' between the dash '-' and the number:
xxx-AES- 192 ----> xxx-AES-192
Suggested-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Acked-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Link: https://lore.kernel.org/r/20250709072452.1595257-1-tmricht@linux.ibm.com
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
TSA are new aspeculative side channel attacks related to the execution
timing of instructions under specific microarchitectural conditions. In
some cases, an attacker may be able to use this timing information to
infer data from other contexts, resulting in information leakage.
Add the usual controls of the mitigation and integrate it into the
existing speculation bugs infrastructure in the kernel.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEzv7L6UO9uDPlPSfHEsHwGGHeVUoFAmhSsvQACgkQEsHwGGHe
VUrWNw//V+ZabYq3Nnvh4jEe6Altobnpn8bOIWmcBx6I3xuuArb9bLqcbKerDIcC
POVVW6zrdNigDe/U4aqaJXE7qCRX55uTYbhp8OLH0zzqX3Pjl/hUnEXWtMtlXj/G
CIM5mqjqEFp5JRGXetdjjuvjG1IPf+CbjKqj2WXbi//T6F3LiAFxkzdUhd+clBF/
ztWchjwUmqU0WJd6+Smb8ZnvWrLoZuOFldjhFad820B7fqkdJhzjHMmwBHJKUEZu
oABv8B0/4IALrx6LenCspWS4OuTOGG7DKyIgzitByXygXXb4L3ZUKpuqkxBU7hFx
bscwtOP7e5HIYAekx6ZSLZoZpYQXr1iH0aRGrjwapi3ASIpUwI0UA9ck2PdGo0IY
0GvmN0vbybskewBQyG819BM+DCau5pOLWuL7cYmaD2eTNoOHOknMDNlO8VzXqJxa
NnignSuEWFm2vNV1FXEav2YbVjlanV6JleiPDGBe5Xd9dnxZTvg9HuP2NkYio4dZ
mb/kEU/kTcN8nWh0Q96tX45kmj0vCbBgrSQkmUpyAugp38n69D1tp3ii9D/hyQFH
hKGcFC9m+rYVx1NLyAxhTGxaEqF801d5Qawwud8HsnQudTpCdSXD9fcBg9aCbWEa
FymtDpIeUQrFAjDpVEp6Syh3odKvLXsGEzL+DVvqKDuA8r6DxFo=
=2cLl
-----END PGP SIGNATURE-----
Merge tag 'tsa_x86_bugs_for_6.16' into tip-x86-bugs
Pick up TSA changes from mainline so that attack vectors work can
continue ontop.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Enable sdhci driver support for SpacemiT K1 SoC, so eMMC storage
will be probed and activated, Tested on the Banana Pi BPI-F3 board.
Signed-off-by: Yixun Lan <dlan@gentoo.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
The common style in all bindings for enumerating similar variants is to
use 'enum', not 'oneOf', so all boards of same variant or using same SoM
should be grouped under enum. It is more readable, more compact and
makes easier to find actual devices from the same family/type. Also
there is completely no point to repeat the compatible in the description
(incircuit,icnova-a20-adb4006 implies this is "ICnova A20 ADB4006" and
pine64,pinephone-1.2 implies "Pine64 PinePhone (1.2)").
Combine two easily visible cases: ICnova A20 and Pine64 PinePhone.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Link: https://patch.msgid.link/20250706095804.50475-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
It is not possible to enable SND_SOC_SDCA_HID when SND_SOC_SDCA is built-in
but HID is in a loadable module, as that results in a link failure:
x86_64-linux-ld: sound/soc/sdca/sdca_functions.o: in function `find_sdca_entity_hide':
sdca_functions.c:(.text+0x25b): undefined reference to `sdca_add_hid_device'
Change SND_SOC_SDCA_HID into a 'bool' option that can only be enabled
if this results in a working build, and change the Makefile so this driver
is a loadable module if possible.
Fixes: ac558015df ("ASoC: SDCA: add a HID device for HIDE entity")
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20250709152430.1498427-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
- Fix bogus KASAN splat on EFI runtime stack
- Select JUMP_LABEL unconditionally to avoid boot failure with pKVM
and the legacy implementation of static keys
- Avoid touching GCS registers when 'arm64.nogcs' has been passed on the
command-line
- Move a 'cpumask_t' off the stack in smp_send_stop()
- Don't advertise SME-related hwcaps to userspace when ID_AA64PFR1_EL1
indicates that SME is not implemented
- Always check the VMA when handling an Overlay fault
- Avoid corrupting TCR2_EL1 during boot
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAmhuU2IQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNLJcCAC+c06O04cqiY2z7ByUIe9G0PEhjDIGCDTe
kLOECPJ2bT0XKFkEnWX5qJ+t6etJomIIgAgk5ZVzBpFmkLeAayMFCjJpGAQ34gZR
vR57g/uWGlJJmdV5LsDD+chRLK76wZYNXI54Hzpu+mgN1wEoa1KTgtn7oul9bcdn
Mnuq183wiCnMYTjO26CVm9IHFVOygJVyaMxQty8zdiZwFDDIAngM1O8E0pXAkCPf
U7/nTbVkejnwDhC5eidPI9Bt3SednKyoSJ3/71fBXVP8E2tHhlwy1VpZiPk73VXz
ZwVBzw2q10uZJRFlybprqWdrVFmOhFP/nXhMP8X5/KT7MXWcfBPi
=GVwU
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
- Fix bogus KASAN splat on EFI runtime stack
- Select JUMP_LABEL unconditionally to avoid boot failure with pKVM and
the legacy implementation of static keys
- Avoid touching GCS registers when 'arm64.nogcs' has been passed on
the command-line
- Move a 'cpumask_t' off the stack in smp_send_stop()
- Don't advertise SME-related hwcaps to userspace when ID_AA64PFR1_EL1
indicates that SME is not implemented
- Always check the VMA when handling an Overlay fault
- Avoid corrupting TCR2_EL1 during boot
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64/mm: Drop wrong writes into TCR2_EL1
arm64: poe: Handle spurious Overlay faults
arm64: Filter out SME hwcaps when FEAT_SME isn't implemented
arm64: move smp_send_stop() cpu mask off stack
arm64/gcs: Don't try to access GCS registers if arm64.nogcs is enabled
arm64: Unconditionally select CONFIG_JUMP_LABEL
arm64: efi: Fix KASAN false positive for EFI runtime stack
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
We have many set_bias_level functions, thus dapm->bias_level should be
handled by owner function, not by its callback functions.
- Mark som pins as invalid for IRQ use in the Qualcomm
driver.
- Fix up the use of device properties on the MA35DX
Nuvoton, apparently something went sidewise.
- Clear the GPIO debounce settings when going down
for suspend in the AMD driver. Very good for some
AMD laptops that now wake up from suspend again!
- Add the compulsory .can_sleep bool flag in the
AW9523 driver, should have been there from the
beginning, now there are users finding the bug.
- Drop some bouncing email address from MAINTAINERS.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmhuQTwACgkQQRCzN7AZ
XXMzQQ/9HOYAkXpZ7vZa5VswSGVD6QX2w4SzJLpE94Oh4DL1z6Iu/UKjCFYmoPgc
nb2hn0Vx9PqbVuBd5nCb1SjzNHfqmDb/1RjO9k5tV/lH8WDYZrLVLk0cDEp2t7fB
/OSLzE1avznxxTB9+pZUD4ApA56l1FwI7iMXevlJM+ct9oeludX8waI3f+090SLX
roSPlSzok1C3BqMNHpjze72hbcLY9WoA4stZISxduMGCEJx1fVpygA296bZ7kQw6
axG9l/Vln5vKFCnPqfYJpVnUn4qNpBJxb9JJRjvxb99j06DLPL3UiP7thLatRPL9
9tdnzFQ3k8o/C93x1GhmFOdj7QVIfC4B16gHS8C6D64SGTvbxhBF8N3Qf7L0+lQk
gUpQqyOG3HupIDGpZBmNknyi2tcwPmdE/6NEkgmEkVLBYZM4MQ9o4N/IOUAHjnI1
6sjQRRYVPrTD453T0B4PgSacsM3SRU6Y4ngygrKT79wJsALrAleR6pPrc606wNEf
llhavu9EJLuGeDZsCAt6dXRbHmLZow0sQlS+c9dzuUqYg/4c9HdiQlM6I0T6x774
A1jAYuhLtaHDK6xnBCVlNy0cRp52spfxYTOh2PKf3Nb0/yVhjWL+Dj0By1vygeFp
9+j9WM86YVoJplO9xOL6tP7XGX19iVmijgTJgroV7uK+HRNDLKA=
=8Px+
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- Mark som pins as invalid for IRQ use in the Qualcomm driver
- Fix up the use of device properties on the MA35DX Nuvoton, apparently
something went sidewise
- Clear the GPIO debounce settings when going down for suspend in the
AMD driver. Very good for some AMD laptops that now wake up from
suspend again!
- Add the compulsory .can_sleep bool flag in the AW9523 driver, should
have been there from the beginning, now there are users finding the
bug
- Drop some bouncing email address from MAINTAINERS
* tag 'pinctrl-v6.16-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: aw9523: fix can_sleep flag for GPIO chip
pinctrl: amd: Clear GPIO debounce for suspend
pinctrl: nuvoton: Fix boot on ma35dx platforms
MAINTAINERS: drop bouncing Lakshmi Sowjanya D
pinctrl: qcom: msm: mark certain pins as invalid for interrupts
Add device-tree for ASUS VivoTab RT TF600T, which is NVIDIA Tegra30-based
tablet device with Windows RT.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Link: https://lore.kernel.org/r/20250617070320.9153-3-clamor95@gmail.com
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a new line-level, boolean property to the gpio-sim configfs
interface called 'valid'. It's set by default and the user can unset it
to make the line be included in the standard `gpio-reserved-ranges`
property when the chip is registered with GPIO core. This allows users
to specify which lines should not be available for requesting as GPIOs.
Link: https://lore.kernel.org/r/20250630130358.40352-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Only select ARCH_WANT_HUGE_PMD_SHARE on 64-bit x86.
Page table sharing requires at least three levels because it involves
shared references to PMD tables; 32-bit x86 has either two-level paging
(without PAE) or three-level paging (with PAE), but even with
three-level paging, having a dedicated PGD entry for hugetlb is only
barely possible (because the PGD only has four entries), and it seems
unlikely anyone's actually using PMD sharing on 32-bit.
Having ARCH_WANT_HUGE_PMD_SHARE enabled on non-PAE 32-bit X86 (which
has 2-level paging) became particularly problematic after commit
59d9094df3 ("mm: hugetlb: independent PMD page table shared count"),
since that changes `struct ptdesc` such that the `pt_mm` (for PGDs) and
the `pt_share_count` (for PMDs) share the same union storage - and with
2-level paging, PMDs are PGDs.
(For comparison, arm64 also gates ARCH_WANT_HUGE_PMD_SHARE on the
configuration of page tables such that it is never enabled with 2-level
paging.)
Closes: https://lore.kernel.org/r/srhpjxlqfna67blvma5frmy3aa@altlinux.org
Fixes: cfe28c5d63 ("x86: mm: Remove x86 version of huge_pmd_share.")
Reported-by: Vitaly Chikunov <vt@altlinux.org>
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Oscar Salvador <osalvador@suse.de>
Acked-by: David Hildenbrand <david@redhat.com>
Tested-by: Vitaly Chikunov <vt@altlinux.org>
Cc:stable@vger.kernel.org
Link: https://lore.kernel.org/all/20250702-x86-2level-hugetlb-v2-1-1a98096edf92%40google.com
of_flags is passed down to GPIO chip's xlate function, so ensure this one
is properly initialized as - if the xlate callback does nothing with it
- we may end up with various configuration errors like:
gpio-720 (enable): multiple pull-up, pull-down or pull-disable enabled, invalid configuration
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/20250708083829.658051-1-alexander.stein@ew.tq-group.com
[Bartosz: tweaked the commit message]
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The alloc implementation is a thin wrapper over slab/vmalloc, so to help
out on the mm side of things and to be cc'd on changes, add some mm people
as reviewers.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Acked-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Link: https://lore.kernel.org/r/20250708183747.104286-1-lorenzo.stoakes@oracle.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250704075434.3220506-1-sakari.ailus@linux.intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Object creation is a careful dance where we must guarantee that the
object is fully constructed before it is visible to other threads, and
GEM buffer objects are no difference.
Final publishing happens by calling drm_gem_handle_create(). After
that the only allowed thing to do is call drm_gem_object_put() because
a concurrent call to the GEM_CLOSE ioctl with a correctly guessed id
(which is trivial since we have a linear allocator) can already tear
down the object again.
Luckily most drivers get this right, the very few exceptions I've
pinged the relevant maintainers for. Unfortunately we also need
drm_gem_handle_create() when creating additional handles for an
already existing object (e.g. GETFB ioctl or the various bo import
ioctl), and hence we cannot have a drm_gem_handle_create_and_put() as
the only exported function to stop these issues from happening.
Now unfortunately the implementation of drm_gem_handle_create() isn't
living up to standards: It does correctly finishe object
initialization at the global level, and hence is safe against a
concurrent tear down. But it also sets up the file-private aspects of
the handle, and that part goes wrong: We fully register the object in
the drm_file.object_idr before calling drm_vma_node_allow() or
obj->funcs->open, which opens up races against concurrent removal of
that handle in drm_gem_handle_delete().
Fix this with the usual two-stage approach of first reserving the
handle id, and then only registering the object after we've completed
the file-private setup.
Jacek reported this with a testcase of concurrently calling GEM_CLOSE
on a freshly-created object (which also destroys the object), but it
should be possible to hit this with just additional handles created
through import or GETFB without completed destroying the underlying
object with the concurrent GEM_CLOSE ioctl calls.
Note that the close-side of this race was fixed in f6cd7daecf ("drm:
Release driver references to handle before making it available
again"), which means a cool 9 years have passed until someone noticed
that we need to make this symmetry or there's still gaps left :-/
Without the 2-stage close approach we'd still have a race, therefore
that's an integral part of this bugfix.
More importantly, this means we can have NULL pointers behind
allocated id in our drm_file.object_idr. We need to check for that
now:
- drm_gem_handle_delete() checks for ERR_OR_NULL already
- drm_gem.c:object_lookup() also chekcs for NULL
- drm_gem_release() should never be called if there's another thread
still existing that could call into an IOCTL that creates a new
handle, so cannot race. For paranoia I added a NULL check to
drm_gem_object_release_handle() though.
- most drivers (etnaviv, i915, msm) are find because they use
idr_find(), which maps both ENOENT and NULL to NULL.
- drivers using idr_for_each_entry() should also be fine, because
idr_get_next does filter out NULL entries and continues the
iteration.
- The same holds for drm_show_memory_stats().
v2: Use drm_WARN_ON (Thomas)
Reported-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Tested-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: stable@vger.kernel.org
Cc: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Signed-off-by: Simona Vetter <simona.vetter@intel.com>
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20250707151814.603897-1-simona.vetter@ffwll.ch
Make several autosuspend functions mark last busy stamp and update
the documentation accordingly (Sakari Ailus).
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmhjrvQSHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1aigIAKypscFSfd/WsAlP4orLtd4xiLi7KQHa
NrOYv7sZBVHgx4S9BGqHavYM3qhOBH5qCg+yBtqb8v6vp/TIlJjF2v3+C8uAXAnl
9GI5Gc6sZp/lMhf5Vb4Ibf58/P9lg4A7mIvM+LtfeEUMTlRrp47Q/RQ0ah7S4tDj
rFyC92QmBnkDLoyQp5IbCWkdjlqGgyTZzz/+XnfV9fWwX1aiXqaB4EZ2nXSAlyBx
awvA4/t662SWlHsdQqll9vS/+ZB39LEWwa1jJ7XGIK8t6GSH+TTys3S9/PHR/ua3
Dlcd+14plDGlSOy97hY+z6NdSgxH/qcpRgFduu5KwVqEwo2fqNkeV9Q=
=pFYw
-----END PGP SIGNATURE-----
mmc: Merge tag pm-runtime-6.17-rc1 into next
Merge the tag pm-runtime-6.17-rc1 from
git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into next
Runtime PM updates related to autosuspend for 6.17
Make several autosuspend functions mark last busy stamp and update
the documentation accordingly (Sakari Ailus).
This is needed to allow additional changes to the mmc subsystem to be
queued for v6.17 too.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
sprintf, snprintf, and scnprintf do not consider the PAGE_SIZE maximum
of the temporary buffer used for outputting sysfs content and they may
overrun the PAGE_SIZE buffer length.
To avoid output defects with the ATA transport class simple attributes,
use sysfs_emit instead of scnprintf().
This aligns with the sysfs guidance provided in
Documentation/filesystems/sysfs.rst.
Signed-off-by: Jonathan Velez <jonvelez12345@gmail.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Link: https://lore.kernel.org/r/20250709133330.3546-1-jonvelez12345@gmail.com
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Several speaker amp was missed when the compoennt_name was added, which
results missing " spk:" from the components string, confusing UCM.
Fixes: f792733e08 ("ASoC: sdw_utils: add component_name string to dai_info")
Cc: stable@vger.kernel.org
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20250709025745.1285788-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The variable was renamed to fbcon_registered_fb, but this comment was
not updated along with the change. Correct it to avoid confusion.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Fixes: efc3acbc10 ("fbcon: Maintain a private array of fb_info")
[sima: Add Fixes: line.]
Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20250709103438.572309-1-oushixiong1025@163.com
Fixes
- snapshot-order of tsc,mperf, clock in mperf_stop()
- printing of CORE, CPU fields in cpupower-monitor
Improves Python binding's Makefile
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPZKym/RZuOCGeA/kCwJExA0NQxwFAmhtce8ACgkQCwJExA0N
QxxIJQ/9H8lqQstep9XAtkSnwUoT0qAZvb7Z8VKm1+8czO/LIhnI9dIPV6GLwYBw
GRJMqrcVj9AAv9r5gv+7KLwLLQE8glcmOBu2GS7rH7WSYVnfGKB5K6neml8ow8FG
ipugEBivTWz1VsfApxqmamYZBhi+Q8SW0Nz8N0ggqGrzlF3YtEuPQD27g0IWBr34
qbuy4NhRpDKYwW23md4SjfV3GS19RwuEtDWiamYvNsErdTUuCUDKpQBCekzr7FaN
OUOE7h5K/Hnx3PM9tADYlXjV/G5eGJlrsEnLib7IeLhL2fsSKhcxmcNbCsa8KUZw
U+MAmh8oyauqwqM0WX1YL7299eVfyJkYm15JS59Jn6fOa03WVMMgO4Ik5+WgZHci
EL8CnGxTSkPvBtIbfwS6q1Ay2b1QNOQOfW6E9/62L9qzcflEUx7TgYja9fqmGY7U
sJ+lr5zIRLF5ZtoLvxx9aQwDkEGR/pLk/eM8axnurN5vhoyFBEAOdwIIdMC+gKFi
oJTpeqtnJzdF67Mu/S9FN93OsIY9LrpG/xgDU1x2HZadpQc4jDyoAD9PzI2uXtWf
RVXjZCbhaWyCdAwtQbRD+ma5MdMsGAm/GERE5kZIq0YjAUY6vmPBW9HlRHAFTtlJ
F752DGtwWcCgV1WP+IV8qwhcr4KXKHuuQrqqwLvZLqjhNyKuiJw=
=JBrS
-----END PGP SIGNATURE-----
Merge tag 'linux-cpupower-6.17-rc1-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux
Merge cpupower utility changes for 6.17-rc1 from Shuah Khan:
"Fixes
- snapshot-order of tsc,mperf, clock in mperf_stop()
- printing of CORE, CPU fields in cpupower-monitor
Improves Python binding's Makefile"
* tag 'linux-cpupower-6.17-rc1-fixed' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux:
cpupower: Improve Python binding's Makefile
pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor
pm: cpupower: Fix the snapshot-order of tsc,mperf, clock in mperf_stop()
The current BAR configuration for the PCI vNTB endpoint function allocates
BARs in order, which lacks flexibility and does not account for
platform-specific quirks. This is problematic on Renesas platforms, where
BAR_4 is a fixed 256B region that ends up being used for MW1, despite being
better suited for doorbells.
Add new configfs attributes to allow users to specify arbitrary BAR
assignments. If no configuration is provided, the driver retains its
original behavior of sequential BAR allocation, preserving compatibility
with existing userspace setups.
This enables use cases such as assigning BAR_2 for MW1 and using the
limited BAR_4 for doorbells on Renesas platforms.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
[mani: adjusted the indent of EPF_NTB_BAR_W, fixed kdoc & squashed bar fix]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20250603-pci-vntb-bar-mapping-v2-3-fc685a22ad28@baylibre.com
Change the default register settings for Gen7 to mach Gen4 and
later. Gen7 currently uses the settings for Gen1, which is most
likely incorrect.
Using Gen4+ settings enables E2M linear-access modes in VGACRA2.
It appears to be related to the chip's PCIE2MBOX feature, which
is unused.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-11-tzimmermann@suse.de
Set VGACRB6[5], which disables asynchronous sequencer resets via
VGASR0[1]. This was most likely an oversight when adding support
for Gen7. Aligns Gen7 with the earlier Gen4+.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-10-tzimmermann@suse.de
Duplicate ast_set_def_ext_reg() for individual chip generations
and move call it into per-chip source files. Remove the original
code. AST2100 and AST2500 reuse the function from earlier chips.
AST2600 appears to be incorrect as it uses an older function. Keep
this behavior for now.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-9-tzimmermann@suse.de
Most of struct ast_dramstruct stores hardware state. Some index
values have known or special meaning. The known values are
- 0xffff - Terminal entry in the array
- 0xff00 - Delays the programming for usecs
- 0x0004 - Sets the type of DRAM
Add constants and helper macros for these cases. Also add a helper
macro for testing. Update Gen1 and Gen2+ accordingly.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-8-tzimmermann@suse.de
Move POST code for Gen2+ and Gen1 to separate source files and
hide it in ast_2100_post() ans ast_2000_post(). With P2A
configuration, the POST logic for these chip generations has
been mingled in ast_init_dram_reg(). Hence, handle all generations
in a single change. The split simplifies both cases. Also move
the DRAM init tables for each Gen into the respective source
file. No changes to the overall logic.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250706162816.211552-6-tzimmermann@suse.de
