| Age | Commit message (Collapse) | Author |
|---|
|
The current approach initializes hybrid PMU structures immediately before
registering them. This is risky as it can lead to key fields, such as
'capabilities', being inadvertently overwritten.
Although no issues have arisen so far, this method is not ideal. It makes
the PMU structure fields susceptible to being overwritten, especially with
future changes that might initialize fields like 'capabilities' within
init_hybrid_pmu() called by x86_pmu_starting_cpu().
To mitigate this potential problem, move the default hybrid structure
initialization before calling x86_pmu_starting_cpu().
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260824082731.1013973-2-dapeng1.mi@linux.intel.com
|
|
|
|
|
|
RK3588 Jaguar has a proprietary Mezzanine connector which exposes among
other things CAN1 and CAN2 controllers as well as UART4.
Add support for the CAN1-CAN2-UART4 Mezzanine adapter for RK3588 Jaguar
which exposes two CAN busses (CAN1 and CAN2) and an RS-232 UART, limited
to 250Kbps.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260811-jaguar-can-v2-2-7e78415b5a08@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
RK3588 Jaguar exposes the CAN0 interface on the P5 connector on the SBC.
Enable it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260811-jaguar-can-v2-1-7e78415b5a08@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The EmbedFire LubanCat 5 is an RK3588-based BTB core board. The LubanCat
5IO is its carrier board. The combination has the following features:
- Rockchip RK3588 SoC
- eMMC and microSD storage
- 2x RTL8211F Gigabit Ethernet
- 2x HDMI output and 1x HDMI input
- 1x M.2 M-Key slot
- 1x M.2 E-Key slot
- 1x Mini PCIe slot
- 1x PCIe x4 slot
- 1x SATA port
- 2x CAN-FD
- 2x UART
- 4x USB Type-A ports
- 1x USB 3.0 Type-C port with DisplayPort Alt Mode
- ES8388 analog audio codec
- HYM8563 RTC
- PWM-controlled fan
The carrier routes CAN1 and CAN2 to SIT1042AQT/3 transceivers. Set both
controller clocks to 300 MHz to provide exact CAN bit timing for a wider
range of bit rates.
Signed-off-by: Cunhao Lu <1579567540@qq.com>
Link: https://patch.msgid.link/tencent_AC68050423A2FB5D3571D158CB7C25048C0A@qq.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
CAN0 is piped through the Q7 connector to the CAN header on the Haikou
baseboard, so enable support for it there.
At least on RK3588 Tiger, the CAN clocks default to 99 MHz, limiting
usable CAN bitrates without skew. The RK3568 errata documentation
mentions 300 MHz as the default frequency, so request the same rate to
allow more bitrates.
The CAN clock setup is common to the Tiger SoM regardless of which
carrier board exposes CAN0, so place it in rk3588-tiger.dtsi. Keep CAN0
disabled by default and enable it in rk3588-tiger-haikou.dts, where the
carrier board routes it to a transceiver.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Cunhao Lu <1579567540@qq.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/tencent_A982C9885A401DE2AB5F405336CDA14C7C06@qq.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Describe the three CAN-FD controllers integrated in RK3588 in the base
SoC .dtsi.
Add CAN0, CAN1 and CAN2 nodes with their register ranges, interrupts,
clocks and resets, and keep them disabled by default so board DTS files
can enable them as needed.
Co-developed-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Jaguar
Signed-off-by: Cunhao Lu <1579567540@qq.com>
Link: https://patch.msgid.link/tencent_95532630016C2421000111DBAFADA99A8605@qq.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
paravirt_steal_rq_enabled and paravirt_steal_enabled use raw static_key
APIs which are now deprecated. Use the new API instead.
No functional change.
Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Juergen Gross <jgross@suse.com>
Link: https://patch.msgid.link/20260819081207.12150-1-hongyan.xia@transsion.com
|
|
PREEMPT_DYNAMIC is now limited to the FULL and LAZY preemption models.
Switching model only changes the behaviour of dynamic_preempt_lazy(),
which uses a static key. There are no other static calls or static keys,
and so there's no need for HAVE_PREEMPT_DYNAMIC_CALL or
HAVE_PREEMPT_DYNAMIC_KEY.
The static key used by dynamic_preempt_lazy() is entirely local to
kernel/sched/core.c, and any architecture which selects
ARCH_HAS_PREEMPT_LAZY implements the necessary support. Remove
PREEMPT_DYNAMIC's dependencies on HAVE_PREEMPT_DYNAMIC_CALL and
HAVE_PREEMPT_DYNAMIC_KEY entirely, leaving the dependency on
ARCH_HAS_PREEMPT_LAZY.
For architectures which previously selected HAVE_PREEMPT_DYNAMIC_KEY,
PREEMPT_DYNAMIC will now be selected by default, matching x86. As the
runtime impact is limited to dynamic_preempt_lazy(), this shouldn't be
as concerning as previously (e.g. where calls to {cond,might}_resched()
stubs could introduce a measurable penalty).
As all of this can work without jump labels, JUMP_LABEL is not selected
explicitly. It is obviously preferable to have JUMP_LABEL enabled, but
this is not functionally necessary.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Mete Durlu <meted@linux.ibm.com>
Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://patch.msgid.link/20260803191731.3244294-6-mark.rutland@arm.com
|
|
PREEMPT_DYNAMIC is now limited to the FULL and LAZY preemption models.
In either model, both preempt_schedule() and preempt_schedule_notrace()
are always called and never disabled.
Remove the unnecessary code for these when PREEMPT_DYNAMIC is selected.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Reviewed-by: Jinjie Ruan <ruanjinjie@huawei.com>
Tested-by: Mete Durlu <meted@linux.ibm.com>
Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://patch.msgid.link/20260803191731.3244294-4-mark.rutland@arm.com
|
|
sched_set_itmt_support() treats debugfs file creation failures as fatal.
When CONFIG_DEBUG_FS is disabled, debugfs stubs return ERR_PTR(-ENODEV),
causing ITMT to be silently disabled.
debugfs is a debug-only facility; its return values should be ignored.
Drop the fatal error handling and enable ITMT unconditionally.
Fixes: d04013a4b21b ("x86/itmt: Move the "sched_itmt_enabled" sysctl to debugfs")
Reported-by: Klaus Kusche <klaus.kusche@computerix.info>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://patch.msgid.link/20260831053836.1881864-1-mario.limonciello@amd.com
|
|
Mukesh Pilaniya <mpilaniy@redhat.com> says:
kexec: fix probe error codes and error propagation
While debugging a misleading error on s390x where kexec -s reported
"syscall kexec_file_load not available" instead of the actual EINVAL
from a kernel command line that exceeded the architecture limit, it was
found that some kexec image probe functions return -EINVAL instead of
-ENOEXEC for format mismatches, and kexec_image_probe_default() has a
bug where it returns whatever the last loader returned rather than
always returning -ENOEXEC when no loader matches.
* Fix all probe functions to return -ENOEXEC when they do not recognize
the image format.
* Fix kexec_image_probe_default() to distinguish format mismatches
(-ENOEXEC) from real errors (e.g. -ENOMEM), propagating real errors
immediately and only continuing to the next loader on -ENOEXEC.
kexec-tools patch:
https://lore.kernel.org/all/20260814075329.30203-1-mpilaniy@redhat.com/
Link: https://patch.msgid.link/20260821-mpilaniy-v3-0-76b355399d2e@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
Several kexec_file_load() image probe functions return -EINVAL when
they do not recognize the image format. A probe function that rejects
an image should return -ENOEXEC to indicate that the image is not a
recognized executable format. -EINVAL implies a problem with the
syscall parameters, not with image recognition.
kexec_image_probe_default() iterates through registered loaders and
returns the last probe's error code to the caller. That error
propagates as the kexec_file_load() return value to userspace.
Returning -EINVAL from a probe when no loader matches is semantically
incorrect and misleads userspace about the nature of the failure.
Return -ENOEXEC from all probe functions and their helpers when the
image format is not recognized.
Signed-off-by: Mukesh Pilaniya <mpilaniy@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Pratyush Yadav <pratyush@kernel.org>
Reviewed-by: Bradley Morgan <include@grrlz.net>
Link: https://patch.msgid.link/20260821-mpilaniy-v3-1-76b355399d2e@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
|
|
Zen6 has BTB protection which isolates the different contexts
(user/kernel, guest/host) from one another. This makes the SafeRET
mitigation there unnecessary leaving the user/user and guest/guest
attack vectors open, whose protection is handled by the Spectre v2
mitigation setting to do IBPB on a context switch.
Detect that setting and report it with a new mitigation string.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20260822013231.1109255-1-bp@kernel.org
|
|
The kernel never supports D without F, since D depends on F. The
D-extension flag is cleared during devicetree/ACPI parsing whenever
F is not present, so has_fpu() checking either extension with '||'
never actually produces a different result than checking D alone -
F without D cannot occur in practice, and there is no observable
impact on RISCV_HWPROBE_IMA_FD or userspace.
Simplify has_fpu() to check D only, matching the expectations set
elsewhere in the kernel for this dependency, rather than relying on
a redundant OR condition.
sys_hwprobe.c already calls has_fpu() and needs no changes.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221874
Suggested-by: Conor Dooley <conor.dooley@microchip.com>
Suggested-by: Andreas Schwab <schwab@suse.de>
Signed-off-by: Ivy Lopez <skunkolee@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260901013746.19386-1-skunkolee@gmail.com
[pjw@kernel.org: updated to apply]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
The RISC-V ISA manual specifies that Zfh implies Zfhmin, a normative
rule clarified in
https://github.com/riscv/riscv-isa-manual/pull/3070. Zvfh likewise
implies Zvfhmin, as stated by the vector extension specification.
The kernel currently reports ZFH and ZFHMIN (and ZVFH and ZVFHMIN) as
independent hwprobe bits derived only from what the device tree
declares. Platforms that declare just "zfh" (Zfh being a superset that
already contains all Zfhmin instructions) therefore report
RISCV_HWPROBE_EXT_ZFHMIN=0, which breaks userspace RVA23 conformance
checks (e.g. snapd installing core26 on riscv64).
Use the existing superset mechanism to set the implied subset bits:
- zfh implies zfhmin
- zvfh implies zvfhmin
Add a hwprobe selftest asserting the implication holds and update the
hwprobe documentation accordingly.
This is complementary to the rva23u64 base behavior discussion: the
RVA23 conformance query proposed there is derived from the
per-extension bits fixed here, so correct EXT_0 reporting is a
prerequisite for it to work on harts whose device tree declares only
"zfh".
Tested on a RISC-V QEMU VM whose device tree only declares "zfh" and
"zvfh": with this change both /proc/cpuinfo and the hwprobe
RISCV_HWPROBE_KEY_IMA_EXT_0 bitmap report ZFHMIN and ZVFHMIN, and the
hwprobe selftest (including the new implication check) passes.
Link: https://lore.kernel.org/kvm-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/
Signed-off-by: JinRui <jinrui@haiwei.tech>
Link: https://patch.msgid.link/7190E4DB338251C3+20260811081513.2849980-1-jinrui@haiwei.tech
[pjw@kernel.org: trimmed superfluous blank line in tags]
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
|
|
Apple Silicon Macs use a shared GPIO line for all speaker codec
shutdown pins.
Select HAVE_SHARED_GPIOS for ARCH_APPLE so that we can use the
shared GPIO proxy infrastructure for this.
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Link: https://patch.msgid.link/20260831-apple-shared-gpio-v1-1-e855b12e18ce@gmail.com
Signed-off-by: Sven Peter <sven@kernel.org>
|
|
The hym8563 on i2c2 does not ack:
rtc-hym8563 2-0051: could not init device, -6
It is also the ext_clock for sdio-pwrseq, so wifi does not come up
either.
i2c2 runs at 400 kHz with no scl edge times. The core defaults both to
300 ns and rk3x-i2c calculates a 900 ns high period, which is short for
this bus - it acks at 100 kHz. Set the edges to the values i2c3 already
uses, giving 1050 ns at 400 kHz.
Tested on a Radxa ROCK Pi N10: rtc0 registers and keeps time across a
reboot, and wifi activates.
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Link: https://patch.msgid.link/aou1Q5-hdF7kRVpe@0d3a7a881997
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Several USB nodes were enabled/configured on the NanoPC-T6 LTS first. Then
those same nodes were enabled/configured in the NanoPC-T6 dtsi file, but
the ones in the LTS dts file were not removed, so do that now.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260828114530.1315798-8-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The kernel can manage the I2S MCLK output gates since commit
02b9b0bb6269 ("clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO")
So switch to I2S0_8CH_MCLKOUT_TO_IO to do exactly that.
The audio ports are used in audio-graph-card, but simple-audio-card uses
sound-dai phandles to establish the DAI links. So drop the pointless ports.
Add a label to the soundcard to be used by tools like alsamixer.
Sort the various properties according to the DTS coding standard.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260828114530.1315798-7-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Nodes shall be ordered alpha-numerically by the node name.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260828114530.1315798-6-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
All NanoPC-T6 boards have a pull up resistor for the RTC pin, so there's
no need for the SoC to pull it up.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260828114530.1315798-5-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Use the pinctrl names as used in the schematics and use natural sort order
by property names for the hym8563 RTC node.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260828114530.1315798-4-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Use the pinctrl names as used in the schematics and use natural sort order
by property names for the PCIe 2 nodes.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260828114530.1315798-3-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The ``vcc_3v3_pcie20`` regulator, identified in the schematic with
``VDD3V3_25GLAN[_B]`` is only separated from ``VCC_3V3_S3`` with a ferrite
bead. So there's no need to define a separate regulator for that.
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260828114530.1315798-2-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The display, touchscreen, and IMU are currently not oriented
consistently. The touchscreen is 90 degrees offset and the IMU is using
the default mount matrix which is 180 degrees offset.
Fix the touchscreen alignment and add a mount matrix for the IMU. When
the device is held vertically relative to the display hardware, the
touchscreen 0,0 position is in the top left corner of the display
(next to the home button), and the IMU reads the correct orientation.
Fixes: 4e946c447a04 ("arm64: dts: rockchip: Add GameForce Ace")
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260828205331.78185-1-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Replace excessive spaces for aligning indentation into tabs. This will
be reported by dt-style-check ("[mixed-indent-chars] too many space
characters in indent (more than 7)").
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260829194012.107758-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add USB controller and PHY nodes to stm32mp251 DT. This includes two
USB 2.0 FEMTO PHYs, USB 2.0 host controller and DWC3 DRD controller
nodes.
Signed-off-by: Pankaj Dev <pankaj.dev@st.com>
Co-developed-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260831231814.137120-5-marex@nabladev.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add USB controller and PHY nodes to stm32mp231 DT. This includes two
USB 2.0 FEMTO PHYs, USB 2.0 host controller and DWC3 DRD controller
nodes.
Co-developed-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Co-developed-by: Francois Choleau <francois.choleau@st.com>
Signed-off-by: Francois Choleau <francois.choleau@st.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260831231814.137120-4-marex@nabladev.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use accurate STM32MP15xx compatible string for OHCI USB controller in
addition to "generic-ohci" fallback compatible string. This is future
proof, and drivers can match on the accurate compatible string in case
they need to discern this controller from the generic-ohci one.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260828150202.173109-3-marex@nabladev.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use accurate STM32MP13xx compatible string for OHCI USB controller in
addition to "generic-ohci" fallback compatible string. This is future
proof, and drivers can match on the accurate compatible string in case
they need to discern this controller from the generic-ohci one.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260828150202.173109-2-marex@nabladev.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use accurate STM32MP15xx compatible string for EHCI USB controller in
addition to "generic-ehci" fallback compatible string. This is future
proof, and drivers can match on the accurate compatible string in case
they need to discern this controller from the generic-ehci one.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260828152130.176171-3-marex@nabladev.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use accurate STM32MP13xx compatible string for EHCI USB controller in
addition to "generic-ehci" fallback compatible string. This is future
proof, and drivers can match on the accurate compatible string in case
they need to discern this controller from the generic-ehci one.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260828152130.176171-2-marex@nabladev.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Use READ_ONCE() in _destroy_pages_crste() to read the crste, avoid
dereferencing the pointer multiple times.
Fixes: a2c17f9270cc ("KVM: s390: New gmap code")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-9-imbrenda@linux.ibm.com>
|
|
When dat_cond_set_storage_key() finds a large page, it will
conditionally set the storage key in absolute memory using
large_crste_to_phys() to get the absolute address.
There is a race window between dat_entry_walk() and
large_crste_to_phys(): the large page could have been split
concurrently, and large_crste_to_phys() might be called with a crste
that does not designate a large page, leading to crashes.
Similar issues were also present in dat_set_storage_key().
dat_get_storage_key() and dat_reset_reference_bit() did instead check
for a potential concurrent splitting of the large page, but then
handled it incorrectly.
Fix by performing a READ_ONCE on the crste pointer, checking and using
the result, instead of dereferencing the pointer again. In case a race
is detacted, try dat_entry_walk() again.
Fixes: 8e03e8316eb2 ("KVM: s390: KVM page table management functions: storage keys")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-8-imbrenda@linux.ibm.com>
|
|
Like kvm_s390_inject_vcpu(), kvm_s390_set_irq_state() also needs the
kvm->srcu or the slots lock when performing the Store status operation.
Fix by taking kvm->srcu in kvm_s390_set_irq_state().
Fixes: ba5c1e9b6cee ("KVM: s390: interrupt subsystem, cpu timer, waitpsw")
Fixes: 062e44a9319f ("KVM: s390: Use srcu in kvm_arch_vcpu_unlocked_ioctl()")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-7-imbrenda@linux.ibm.com>
|
|
Move all code from s390_kvm_mmu_commit_memory_region() into
s390_kvm_mmu_prepare_memory_region(). This allows the function to fail
gracefully if needed. The previous behaviour was to print a warning and
continue execution with page tables inconsistent with the memslots.
Fixes: e38c884df921 ("KVM: s390: Switch to new gmap")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-6-imbrenda@linux.ibm.com>
|
|
Refactor dat_set_slot(), _dat_slot_pte(), _dat_slot_crste(). Now they
only take a struct kvm_s390_mmu_cache as priv. For dat_delete_slot(),
mc is NULL, as no allocations should take place.
This is needed as a prerequisite to move gmap DAT table setup from
kvm_arch_commit_memory_region() to kvm_arch_prepare_memory_region().
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-5-imbrenda@linux.ibm.com>
|
|
In some circumstances, it is possible that the page of nested guest
memory that is being shadowed is not present at all in the parent guest
gmap. dat_entry_walk() will not find any leaf entry and return with
-ENOENT, which will erroneously be propagated all the way to userspace.
Fix by manually calling gmap_link() on the memory of the nested guest
that is being shadowed if the mapping was not already present.
Fixes: e38c884df921 ("KVM: s390: Switch to new gmap")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-4-imbrenda@linux.ibm.com>
|
|
The parameter "old" should be marked as const, to prevent compile-time
warnings.
Fixes: d487a24041c2 ("KVM: s390: Prepare gmap for a second KVM implementation")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-3-imbrenda@linux.ibm.com>
|
|
When the indicator and/or summary bits are set in the guest, the
accessed page was only marked dirty in KVM if the access was performed
using the slow path; accesses through the new kvm_arch_set_irq_inatomic
fast inject path would not mark the page as dirty.
Fix by adding/moving the missing calls to mark_page_dirty(). Note that
for the inatomic path set_page_dirty{,_lock}() is not needed as the
page stays pinned; the unpin path correctly marks it as dirty.
Opportunistically reorder the local variables to be in reverse
Christmas tree order and refactor to use guard().
Fixes: 1e95e3bc6b05 ("KVM: s390: Enable adapter_indicators_set to use mapped pages")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-ID: <20260828115439.145885-2-imbrenda@linux.ibm.com>
|
|
arch_ptrace() accepts PTRACE_POKEUSR for every aligned offset below
PT_SIZE. This includes the saved machine status register and pt_mode,
which are kernel-owned execution state rather than general registers.
On return from an exception, rtbd copies MSR_UMS to the live MSR_UM bit.
An unprivileged same-UID tracer can therefore clear MSR_UMS in its
tracee's saved register frame and make the tracee resume in supervisor
mode. pt_mode also controls whether later entry paths classify the frame
as kernel or user state.
Reject PTRACE_POKEUSR writes to both fields while retaining read access.
Fixes: 2b4384542691 ("microblaze_v8: ptrace support")
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Link: https://patch.msgid.link/20260821103026.3627292-2-Jeremy.Jean@oss.cyber.gouv.fr
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
Every value returned from of_clk_get() is supposed to be cleaned up
via clk_put() once not needed anymore.
Fixes: c1120542b99a ("microblaze: Add support for CCF")
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Link: https://patch.msgid.link/20260526184105.18962-4-grandmaster@al2klimov.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
setup_sigcontext() and restore_sigcontext() copy r0-r31, pc, ear, esr and
fsr to and from the signal frame but never touch MSR. The interrupted
MSR is therefore dropped from the signal context entirely: the handler's
ucontext does not expose it, a handler cannot adjust the resumed
arithmetic flags through uc_mcontext.regs.msr, and -- because
restore_sigcontext() leaves regs->msr as whatever the rt_sigreturn trap
left in it -- the interrupted context resumes with the carry produced by
the syscall entry path (_user_exception does "addi r14, r14, 4", which
writes carry), not with its own.
Other architectures round-trip the user-visible flags through the signal
frame (arm's cpsr, csky's carry, x86's eflags), so a handler can both read
and adjust the resumed flags; purely privileged status registers such as
riscv's sstatus are left out. MicroBlaze should do the same for the
user-writable bits.
Concretely, MSR[C] (carry) is lost across signal delivery. Code that
keeps a live carry across a point where a signal can be delivered -- for
example an lwx/swx compare-and-swap retry loop, between the swx and the
carry test -- resumes with the handler's carry and mis-evaluates the
result; the same failure class as the rt_sigreturn r3/r4 clobber, reached
through a different register. Demonstrated under qemu-system-microblazeel
(machine petalogix-s3adsp1800): a handler that sets MSR_C in
uc_mcontext.regs.msr has no effect before this change (0 of 132 in-window
signals propagated) and takes effect after (130 of 132).
Save MSR in setup_sigcontext() so the handler's ucontext exposes it. The
signal frame is user-writable, so restore_sigcontext() must not restore it
verbatim: MicroBlaze packs the user-writable carry (MSR_C, MSR_CC) and the
privileged control bits (MSR_UM, MSR_VM, MSR_IE, MSR_EE, ...) into the one
register, and a verbatim restore would let userspace alter privileged
return state -- rtbd derives the resumed mode from MSR_UMS/MSR_VMS.
Restore only MSR_C | MSR_CC from the frame and keep the rest from the
current regs->msr. This mirrors x86's
restore_sigcontext(), which masks the restored EFLAGS to FIX_EFLAGS for
the same reason; arches whose status register is purely privileged (e.g.
riscv sstatus) simply do not restore it at all.
Comment on the exposed MSR reworded: it is not read-only,
restore_sigcontext() applies MSR_C|MSR_CC from the frame. Author's
Signed-off-by kept; he agreed to comment and changelog cleanups.
Fixes: 2148daa9c45f ("microblaze_v8: Signal support")
Cc: stable@vger.kernel.org
Signed-off-by: Sam Price <thesamprice@gmail.com>
Signed-off-by: Ramin Moussavi <ramin.moussavi@yacoub.de>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Link: https://patch.msgid.link/20260821151809.1233057-6-ramin.moussavi@yacoub.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
The MicroBlaze ABI has the caller reserve stack space for the arguments
it passes in registers: REG_PARM_STACK_SPACE is 24 and
OUTGOING_REG_PARM_STACK_SPACE is 1 in the gcc backend, so a callee may
write to [caller_sp + 4, caller_sp + 28). The kernel calls C functions
from entry.S with r1 pointing at pt_regs, handing the callee license to
spill its incoming arguments over the saved registers -- the syscall
dispatch is the worst case, where the first argument slot is PT_R1, the
saved user stack pointer.
This was latent until GCC 15: since 3b9b8d6cfdf5 ("ira: Scale
save/restore costs of callee save registers with block frequency") the
allocator prefers spilling incoming arguments over copying them into
callee-saved registers, and a kernel built with gcc >= 15 (without the
TARGET_CALLEE_SAVE_COST workaround some distributions carry) corrupts
PT_R1 on the first syscall: init takes SIGSEGV and the kernel panics.
The kernel had exactly this reservation until 2011:
commit 6e83557c38b4 ("microblaze: Remove r0_ram pointer and PTO alignment")
removed STATE_SAVE_ARG_SPACE and with it the PTO offset, as part of
cleaning up what was thought to be copied-from-v850 leftovers. Restore
it: the frame is STATE_SAVE_SIZE = PT_SIZE + PTO, r1 stays at the frame
base through every asm-to-C call, and the saved registers are reached
at r1 + PTO + PT_*. PTO is 28 rather than the historic 24, which was
one word short: FIRST_PARM_OFFSET is 4 and REG_PARM_STACK_SPACE is 24,
so the area spans [sp+4, sp+28) and needs 28 bytes. With 24 the last
argument slot overlapped pt_regs' r0 -- harmless only because r0 is the
constant-zero register. STACK_BOUNDARY is 32 bits, so 28 needs no
further rounding.
Two places deliberately keep their mainline addressing.
hw_exception_handler.S needs no offset change: its real-mode handler
saves into the standalone pt_pool_space buffer rather than a stack
frame, and _unaligned_data_exception works through a pointer to pt_regs
in r7, where plain PT_* offsets are already right. And the user-SP
reload after popping the frame keeps PT_R1 - PT_SIZE because PTO
cancels there: (PTO + PT_R1) - (PT_SIZE + PTO) = PT_R1 - PT_SIZE. Both
are exactly as the pre-2011 code had them.
The instruction count is unchanged -- the same instructions with
different immediates, no per-call reservation and no trampolines. The
cost is 28 bytes more kernel stack per saved frame.
Fixes: 6e83557c38b4 ("microblaze: Remove r0_ram pointer and PTO alignment")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ramin Moussavi <ramin.moussavi@yacoub.de>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Link: https://patch.msgid.link/20260821151809.1233057-5-ramin.moussavi@yacoub.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
ret_from_trap begins by storing the system call return values r3 and r4
back into the saved user pt_regs. That is right for an ordinary system
call, but sys_rt_sigreturn() returns through the same path and has to be
transparent: restore_sigcontext() has just filled pt_regs from the signal
frame, and every register must reach userspace exactly as saved. The two
stores overwrite the restored r3/r4 with whatever the C function left in
those registers.
Only r4 is actually lost, and that follows from how sigreturn is written
everywhere rather than from chance. Architectures have sys_rt_sigreturn()
return the restored return-value register precisely so that this writeback
stores the restored value -- arm returns regs->ARM_r0, riscv and csky
regs->a0, arc regs->r0 -- and microblaze does the same through
*rval_p = regs->r3 in restore_sigcontext(). But the entry macros treat r3
and r4 as a pair, so ret_from_trap writes back two registers while a C
function has only one return value; nothing carries the restored r4.
Commit 791d0a169b91 ("microblaze: Fix sys_rt_sigreturn_wrapper") introduced
this in v2.6.37. The old wrapper saved r3/r4 before the call and reloaded
them from pt_regs afterwards; switching brlid to brid removed the only
point where they were reloaded, and the stores have been overwriting them
ever since.
Fix it the way the sibling paths already behave: ret_from_irq and
ret_from_exc restore the full register set and do not perform these stores
at all. Label the instruction after the stores ret_from_trap_no_rval and
enter there, biasing r15 by -8 so that the ABI return "rtsd r15, 8" lands
on it; naming the entry rather than computing ret_from_trap + 8 keeps it
correct if the number of stores ever changes. Restoring the old
save/reload would work too, but costs four memory accesses and a branch to
undo damage that is better not done.
Any value the compiler keeps in r4 across a signal is lost. The tightest
windows are the lwx/swx compare-and-swap retry loops gcc emits for atomics:
in uClibc-ng's libc.so alone, 50 of 364 such loops hold the address in r4.
This is not specific to one libc -- musl passes the address as "r"(p), and
glibc has no microblaze atomic-machine.h and so uses gcc's __atomic
builtins, which expand the same way. Triggering it needs threads plus a
signal storm, which is why it survived 15 years.
Reproduced on qemu-system-microblazeel (petalogix-s3adsp1800) by running
the uClibc-ng NPTL test tst-eintr1 40 times against an unchanged userspace:
on v7.2 built with gcc 16.2.0, 23 of 40 iterations died with SIGSEGV
without this patch and 0 of 40 with it; on v7.0 built with gcc 12.5.0 the
same comparison gave 6 of 40 against 0 of 40. The register dump of a
failing iteration shows the signature: a zero r4 and a fault at address 0,
while r3 came back intact.
Fixes: 791d0a169b91 ("microblaze: Fix sys_rt_sigreturn_wrapper")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ramin Moussavi <ramin.moussavi@yacoub.de>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Link: https://patch.msgid.link/20260821151809.1233057-4-ramin.moussavi@yacoub.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
The MicroBlaze procedure call standard reserves [r1+0] for the return
address and lets a callee store its incoming register arguments r5..r10
into the caller-provided home slots at [r1+4]..[r1+24]. When the kernel
enters a signal handler it sets r1 to point at struct rt_sigframe, whose
leading member is the siginfo prepared for the handler. A handler that
homes its arguments - which an unoptimised (-O0) build always does -
therefore overwrites the first 24 bytes of that siginfo, so an
SA_SIGINFO handler reads corrupted values. The stores stay within
siginfo (128 bytes) and do not reach the ucontext behind it.
Reserve the home area by making a seven-word gap -- the return-address
slot plus the six argument slots, 28 bytes -- the first member of struct
rt_sigframe, so the handler's argument stores land in scratch space
instead of clobbering siginfo.
Tested on qemu-system-microblazeel (petalogix-s3adsp1800) with the
uClibc-ng NPTL test suite: tst-timer4, tst-timer5, tst-mqueue5 and
tst-signal6 pass; before this change they failed because the handler
clobbered the signal frame.
Fixes: 2148daa9c45f ("microblaze_v8: Signal support")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ramin Moussavi <ramin.moussavi@yacoub.de>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Link: https://patch.msgid.link/20260821151809.1233057-3-ramin.moussavi@yacoub.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
|
sigaltstack is wired to sys_ni_syscall - microblaze is the only
architecture without it - although the microblaze signal delivery code
fully supports the alternate signal stack: get_sigframe() picks the
stack via sigsp(), setup_rt_frame() saves it with __save_altstack() and
sys_rt_sigreturn() calls restore_altstack().
Wire it up to sys_sigaltstack.
Tested on qemu petalogix-s3adsp1800 (microblazeel) with the uClibc-ng
test suite: the five sigaltstack-dependent NPTL tests (tst-cancel20/21,
tst-cancelx20/21, tst-signal6) pass; before this change sigaltstack()
returned ENOSYS.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Ramin Moussavi <ramin.moussavi@yacoub.de>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Link: https://patch.msgid.link/20260821151809.1233057-2-ramin.moussavi@yacoub.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
|
