* Re: [PATCH 3/4] arm64: dts: allwinner: add Allwinner A733 SoC
From: Jerome Brunet @ 2026-06-23 15:35 UTC (permalink / raw)
To: Enzo Adriano via B4 Relay
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Maxime Ripard, Ulf Hansson,
enzo.adriano.code, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-mmc
In-Reply-To: <20260613-a733-dts-v1-public-ready-v1-3-7787c94681db@gmail.com>
On sam. 13 juin 2026 at 05:42, Enzo Adriano via B4 Relay <devnull+enzo.adriano.code.gmail.com@kernel.org> wrote:
> From: Enzo Adriano <enzo.adriano.code@gmail.com>
>
> Add the initial A733 SoC description with CPUs, timers, interrupt
> controller, clocks, pinctrl, UART0, and MMC0.
>
> Keep peripherals disabled by default. Board DTS files can enable only the
> devices that are proven on their hardware.
>
> Signed-off-by: Enzo Adriano <enzo.adriano.code@gmail.com>
> ---
> arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi | 198 +++++++++++++++++++++++++
> 1 file changed, 198 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi b/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi
> new file mode 100644
> index 000000000000..3721aa9e8573
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun60i-a733.dtsi
> @@ -0,0 +1,198 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/sun60i-a733-ccu.h>
> +#include <dt-bindings/reset/sun60i-a733-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x000>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu1: cpu@100 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x100>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu2: cpu@200 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x200>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu3: cpu@300 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x300>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu4: cpu@400 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x400>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu5: cpu@500 {
> + compatible = "arm,cortex-a55";
> + device_type = "cpu";
> + reg = <0x500>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <530>;
> + };
> +
> + cpu6: cpu@600 {
> + compatible = "arm,cortex-a76";
> + device_type = "cpu";
> + reg = <0x600>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> + };
> +
> + cpu7: cpu@700 {
> + compatible = "arm,cortex-a76";
> + device_type = "cpu";
> + reg = <0x700>;
> + enable-method = "psci";
> + capacity-dmips-mhz = <1024>;
> + };
> + };
> +
> + osc24M: osc24M-clk {
Note A733 supports 19.2MHz, 24MHz and 26MHz xtals apparently.
The A7S and A7A do have a 26MHz xtal according to the schematics.
While this might be fine in the SoC dtsi, your are missing something in
your board dts to change the xtal rate, at least.
Also the node and clock name are a bit misleading now.
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: osc32k-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
I think this is the ext32k supposed to feed the rtc ccu ...
> + };
> +
> + iosc: internal-osc-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <16000000>;
> + clock-output-names = "iosc";
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0", "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x0 0x40000000>;
> +
> + pio: pinctrl@2000000 {
> + compatible = "allwinner,sun60i-a733-pinctrl";
> + reg = <0x02000000 0x600>;
> + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_APB1>, <&osc24M>, <&osc32k>;
> + clock-names = "apb", "hosc", "losc";
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> +
> + mmc0_pins: mmc0-pins {
> + pins = "PF0", "PF1", "PF2",
> + "PF3", "PF4", "PF5";
> + function = "mmc0";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> + };
> +
> + ccu: clock-controller@2002000 {
> + compatible = "allwinner,sun60i-a733-ccu";
> + reg = <0x02002000 0x2000>;
> + clocks = <&osc24M>, <&osc32k>, <&iosc>;
^
... not directly the main CCU.
> + clock-names = "hosc", "losc", "iosc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + uart0: serial@2500000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x02500000 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + gic: interrupt-controller@3400000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x03400000 0x10000>,
> + <0x03460000 0x100000>;
> + };
> +
> + mmc0: mmc@4020000 {
> + compatible = "allwinner,sun60i-a733-mmc",
> + "allwinner,sun20i-d1-mmc";
> + reg = <0x04020000 0x1000>;
> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_MMC0>, <&ccu CLK_MMC0>;
> + clock-names = "ahb", "mmc";
> + resets = <&ccu RST_BUS_MMC0>;
> + reset-names = "ahb";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> + max-frequency = <200000000>;
> + cap-sd-highspeed;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +};
--
Jerome
^ permalink raw reply
* [PATCH] spi: imx: reconfigure for PIO when DMA cannot be started
From: Javier Fernandez Pastrana @ 2026-06-23 15:32 UTC (permalink / raw)
To: Mark Brown, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Carlos Song, linux-spi, imx, linux-arm-kernel,
linux-kernel
Cc: javier.pastrana, stable
When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA:
spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and
spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the
SDMA watermarks.
If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single()
returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and
falls back to PIO. The dynamic-burst DMA path uses its own bounce
buffers instead of the SPI core's mapping, so xfer->{tx,rx}_sg_mapped
are not set and the core's DMA->PIO retry is skipped; the driver falls
back to PIO internally. But none of the DMA-mode configuration is
undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst
length and dynamic_burst cleared, and the transferred data is corrupted.
This is easily hit on i.MX8MP boards that describe ECSPI DMA in the
device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin):
every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then
returns shifted TPM2_GetCapability data, is flagged "field failure
mode", /dev/tpmrm0 is never created.
Mark the controller PIO-only (controller->fallback) and re-run
spi_imx_setupxfer() before falling back, so the ECSPI is reconfigured
exactly like a normal PIO transfer.
Fixes: faa8e404ad8e ("spi: imx: support dynamic burst length for ECSPI DMA mode")
Cc: stable@vger.kernel.org
Signed-off-by: Javier Fernandez Pastrana <javier.pastrana@linutronix.de>
---
drivers/spi/spi-imx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 480d1e8b281f..64c78bd79d7d 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -2153,6 +2153,8 @@ static int spi_imx_transfer_one(struct spi_controller *controller,
ret = spi_imx_dma_transfer(spi_imx, transfer);
if (transfer->error & SPI_TRANS_FAIL_NO_START) {
spi_imx->usedma = false;
+ controller->fallback = true;
+ spi_imx_setupxfer(spi, transfer);
if (spi_imx->target_mode)
return spi_imx_pio_transfer_target(spi, transfer);
else
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Add tracepoint for EVTQ events
From: Robin Murphy @ 2026-06-23 15:31 UTC (permalink / raw)
To: Chen Jun, will, joro, linux-kernel, linux-arm-kernel; +Cc: zhangyuwei20
In-Reply-To: <20260613130007.18563-1-chenjun102@huawei.com>
On 13/06/2026 2:00 pm, Chen Jun wrote:
> Events reported by the SMMU can severely impact accelerator
> performance. Currently, only events that the SMMU fails to handle are
> printed to the kernel log, leaving most events invisible to users.
> To analyze and optimize accelerator performance, complete visibility
> into all SMMU-reported events is required.
What events, exactly? AFAICS the only events we should expect to handle
"invisibly", without being some unexpected error condition worth
screaming about, would be stalls for SVA page faults, and if SVA isn't
generically accounting page faults itself then I would imagine it
probably should.
Thanks,
Robin.
> Add a tracepoint in the EVTQ interrupt handler to capture every
> event record reported by the SMMU. This allows users to collect all
> event information via ftrace/perf for further analysis, complementing
> the existing event decoder and error dump which only cover a subset
> of events.
>
> Signed-off-by: Chen Jun <chenjun102@huawei.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/Makefile | 2 +-
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 3 ++
> drivers/iommu/arm/arm-smmu-v3/trace.c | 9 ++++
> drivers/iommu/arm/arm-smmu-v3/trace.h | 53 +++++++++++++++++++++
> 4 files changed, 66 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iommu/arm/arm-smmu-v3/trace.c
> create mode 100644 drivers/iommu/arm/arm-smmu-v3/trace.h
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/Makefile b/drivers/iommu/arm/arm-smmu-v3/Makefile
> index 493a659cc66b..63a8d71bfc93 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/Makefile
> +++ b/drivers/iommu/arm/arm-smmu-v3/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_ARM_SMMU_V3) += arm_smmu_v3.o
> -arm_smmu_v3-y := arm-smmu-v3.o
> +arm_smmu_v3-y := arm-smmu-v3.o trace.o
> arm_smmu_v3-$(CONFIG_ARM_SMMU_V3_IOMMUFD) += arm-smmu-v3-iommufd.o
> arm_smmu_v3-$(CONFIG_ARM_SMMU_V3_SVA) += arm-smmu-v3-sva.o
> arm_smmu_v3-$(CONFIG_TEGRA241_CMDQV) += tegra241-cmdqv.o
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f0..85e6c25b73ed 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -34,6 +34,8 @@
> #include "arm-smmu-v3.h"
> #include "../../dma-iommu.h"
>
> +#include "trace.h"
> +
> static bool disable_msipolling;
> module_param(disable_msipolling, bool, 0444);
> MODULE_PARM_DESC(disable_msipolling,
> @@ -2271,6 +2273,7 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev)
>
> do {
> while (!queue_remove_raw(q, evt)) {
> + trace_smmu_evtq_event(smmu, evt);
> arm_smmu_decode_event(smmu, evt, &event);
> if (arm_smmu_handle_event(smmu, evt, &event))
> arm_smmu_dump_event(smmu, evt, &event, &rs);
> diff --git a/drivers/iommu/arm/arm-smmu-v3/trace.c b/drivers/iommu/arm/arm-smmu-v3/trace.c
> new file mode 100644
> index 000000000000..77378698b1a3
> --- /dev/null
> +++ b/drivers/iommu/arm/arm-smmu-v3/trace.c
> @@ -0,0 +1,9 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ARM SMMUv3 trace support
> + *
> + * Copyright (c) 2026 OpenCloudOS / openEuler
> + */
> +
> +#define CREATE_TRACE_POINTS
> +#include "trace.h"
> diff --git a/drivers/iommu/arm/arm-smmu-v3/trace.h b/drivers/iommu/arm/arm-smmu-v3/trace.h
> new file mode 100644
> index 000000000000..7cec8d41745e
> --- /dev/null
> +++ b/drivers/iommu/arm/arm-smmu-v3/trace.h
> @@ -0,0 +1,53 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * ARM SMMUv3 trace support
> + *
> + * Copyright (c) 2026 OpenCloudOS / openEuler
> + */
> +
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM arm_smmu_v3
> +
> +#if !defined(_TRACE_ARM_SMMU_V3_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_ARM_SMMU_V3_H
> +
> +#include <linux/tracepoint.h>
> +
> +#include "arm-smmu-v3.h"
> +
> +TRACE_EVENT(smmu_evtq_event,
> +
> + TP_PROTO(struct arm_smmu_device *smmu, u64 *evt),
> +
> + TP_ARGS(smmu, evt),
> +
> + TP_STRUCT__entry(
> + __string(iommu, dev_name(smmu->dev))
> + __field(u64, evt0)
> + __field(u64, evt1)
> + __field(u64, evt2)
> + __field(u64, evt3)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(iommu);
> + __entry->evt0 = evt[0];
> + __entry->evt1 = evt[1];
> + __entry->evt2 = evt[2];
> + __entry->evt3 = evt[3];
> + ),
> +
> + TP_printk("%s evt: 0x%016llx 0x%016llx 0x%016llx 0x%016llx",
> + __get_str(iommu),
> + __entry->evt0, __entry->evt1,
> + __entry->evt2, __entry->evt3)
> +);
> +
> +#endif /* _TRACE_ARM_SMMU_V3_H */
> +
> +/* This part must be outside protection */
> +#undef TRACE_INCLUDE_PATH
> +#undef TRACE_INCLUDE_FILE
> +#define TRACE_INCLUDE_PATH ../../drivers/iommu/arm/arm-smmu-v3/
> +#define TRACE_INCLUDE_FILE trace
> +#include <trace/define_trace.h>
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Chen-Yu Tsai @ 2026-06-23 15:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, André Przywara
In-Reply-To: <1jv7bjd6wi.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:56 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 22:41, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> Add support for the internal CCU found in the RTC module of the Allwinner
> >> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
> >> with older SoCs like the sun6i, the A733 introduces several new features.
> >>
> >> The A733 RTC CCU supports choosing one of three external crystal
> >> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
> >> logic to automatically identify the frequency used on the board and
> >> exports this DCXO signal as the "hosc" clock.
> >>
> >> Furthermore, the driver implements logic to derive a 32kHz reference
> >> from the HOSC. This is achieved through a muxed clock path using fixed
> >> pre-dividers to normalize the different crystal frequencies to ~32kHz.
> >
> > Have you tested whether the actually normalizes the frequency, i.e.
> > selects a different divider based on the DCXO frequency? Otherwise
> > we're just lying about the frequency.
> >
> >> This path reuses the same hardware mux registers as the HOSC clock.
> >>
> >> Additionally, this CCU provides several gate clocks for specific
> >> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
> >> as an auxiliary driver to be bound to the sun6i-rtc driver.
> >>
> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> >> ---
>
> [...]
>
> >> +};
> >> +
> >> +static const struct clk_parent_data hosc_parents[] = {
> >> + { .fw_name = "osc24M" },
> >> + { .fw_name = "osc19M" },
> >> + { .fw_name = "osc26M" },
> >> + { .fw_name = "osc24M" },
> >> +};
> >
> > As mentioned in my reply to the binding, this is wrong. There is only
> > one input.
> >
> > The most you can do is check the rate of the parent clock against the
> > detected one, and _scream_ that the DT is wrong. And maybe override
> > the reported frequency.
> >
> > If you want to do the latter, you could add a new fixed rate gated
> > clock type to our library. You would fill in the rate before the
> > clocks get registered. I probably wouldn't go that far. We want people
> > to have correct hardware descriptions.
> >
> > Funnily enough Allwinner's BSP actually implements a fixed rate gate
> > for the next 24M-to-32k divider clock.
>
> What about implementing the register bellow as a read-only (and
> non-cached) divider using the factors provided by Junhui ? That would be
> an accurate description of the HW I think.
>
> The oscillator gets set in DT and if the output reported past the
> divider is not 32728Hz, you know you've got a problem (bad DT or HW gone
> bad)
>
> With a fixed-rate gate, you may actually end up lying about what
> actually happen, if the HW does not behave as expected.
>
> Do you prefer a fixed-rate gate still or should I try the RO divider
> approach ?
I think either one would work. The RO divider is probably more accurate.
Sorry for the late reply.
ChenYu
^ permalink raw reply
* Re: [PATCH 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Robin Murphy @ 2026-06-23 15:16 UTC (permalink / raw)
To: Marek Szyprowski, Viacheslav Bocharov, Linus Walleij,
Bartosz Golaszewski
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Diederik de Haas, linux-gpio, linux-arm-kernel, linux-amlogic,
linux-kernel, linux-rockchip, Heiko Stuebner
In-Reply-To: <184d315b-a0a1-4792-8a40-1b4967025916@samsung.com>
On 11/06/2026 9:26 am, Marek Szyprowski wrote:
> Hi Viachesla,
>
> On 10.06.2026 17:32, Viacheslav Bocharov wrote:
>> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
>> the underlying chip's can_sleep, but under that lock it calls config and
>> direction ops that reach sleeping pinctrl paths. On a controller with
>> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
>> runs from atomic context:
>>
>> BUG: sleeping function called from invalid context
>> ... pinctrl_gpio_set_config <- gpiochip_generic_config
>> <- gpio_shared_proxy_set_config (voting spinlock held)
>> <- ... <- mmc_pwrseq_simple_probe
>>
>> This was reported on Khadas VIM3 and worked around for Amlogic by
>> commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
>> sleeping"), which marked the whole meson controller sleeping. That
>> workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
>> no longer detects devices, because its IRQ-disabled read slot calls the
>> non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
>>
>> Patch 1 fixes the proxy locking generically (always a sleeping mutex).
>> Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
>>
>> Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
>> gating on gpiod_cansleep() change behaviour. No current device needs
>> atomic (non-cansleep) value access on a shared GPIO -- every report
>> (Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
>> (eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
>> which is what the proxy exists to vote on. An alternative that keeps
>> atomic value access (split locking) is possible but adds a second lock
>> and new race windows. I went with the simpler, verified approach and
>> would appreciate guidance on whether the atomic value path must be
>> preserved.
>>
>> The two are a unit: patch 2 must not be applied without patch 1,
>> otherwise the original VIM3 splat returns on boards that share a meson
>> GPIO -- please keep the order. I have not Cc'd stable; I will request
>> stable backports separately once both patches have landed.
>>
>> Viacheslav Bocharov (2):
>> gpio: shared-proxy: always serialize with a sleeping mutex
>> pinctrl: meson: restore non-sleeping GPIO access
>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> This probably also affects the similar changes in Rockchip GPIO driver done
> by the following commits:
> 20cf2aed89ac ("gpio: rockchip: mark the GPIO controller as sleeping")
> 7ca497be0016 ("gpio: rockchip: Stop calling pinctrl for set_direction")
>
> I've checked this patchset with these two reverted and no warning was reported.
If it hadn't already been fixed, then indeed I guess this might make
20cf2aed89ac redundant. However, 7ca497be0016 is still an objective
improvement either way, since that driver never needed to call pinctrl
at all (it was seemingly just an artefact of how the GPIO code was
originally implemented within the pinctrl driver itself).
Thanks,
Robin.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Bradley Morgan @ 2026-06-23 15:11 UTC (permalink / raw)
To: Fuad Tabba
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <CA+EHjTz+oNerTD3Ygj3EzOA4zm4BKfQYM45ydwVO=2amErkBAQ@mail.gmail.com>
On June 23, 2026 4:03:30 PM GMT+01:00, Fuad Tabba <fuad.tabba@linux.dev>
wrote:
>On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
>>
>> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org>
>wrote:
>> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
>> >> Protected guest faults charge long term pins to the VM's mm. Teardown
>> >> can run later from file release, where current->mm may be unrelated.
>> >>
>> >> Drop the charge from kvm->mm instead.
>> >>
>> >>
>> >
>> >Applied to fixes, thanks!
>> >
>> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
>> > commit: d098bb75d14fde2f12155f1a95ec0168160867ce
>> >
>> >Cheers,
>> >
>> > M.
>> >
>>
>>
>> Hey, which tree did you apply it to?
>
>https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
>
>/fuad
>
>>
>>
>> Thanks!
>
Thanks fuad.
May I ask if this would be put onto ACK?
Since this affects pixel devices.
(E.g, my pixel 7....)
Thanks!
^ permalink raw reply
* Re: [PATCH v1 1/1] i2c: nomadik: Use generic definitions for bus frequencies
From: Andi Shyti @ 2026-06-23 15:10 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: linux-arm-kernel, linux-i2c, linux-kernel, Linus Walleij
In-Reply-To: <20260618141730.3243303-1-andriy.shevchenko@linux.intel.com>
Hi Andy,
On Thu, Jun 18, 2026 at 04:17:30PM +0200, Andy Shevchenko wrote:
> Since we have generic definitions for bus frequencies, let's use them.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
I merged all this seriesin i2c/i2c.
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH] iio: stm32-dfsdm: Treat flags as booleans
From: Jonathan Cameron @ 2026-06-23 15:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Olivier MOYSAN, Rob Herring (Arm), David Lechner, Nuno Sá,
Andy Shevchenko, Maxime Coquelin, Alexandre Torgue, linux-iio,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <ajpX3E2zHYh2e8FG@ashevche-desk.local>
On Tue, 23 Jun 2026 12:54:36 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Tue, Jun 23, 2026 at 11:43:49AM +0200, Olivier MOYSAN wrote:
> > On 6/21/26 16:10, Jonathan Cameron wrote:
> > > On Sat, 13 Jun 2026 16:39:16 +0300
> > > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > > > On Fri, Jun 12, 2026 at 04:51:50PM -0500, Rob Herring (Arm) wrote:
>
> ...
>
> > > > > - ret = of_property_read_u32_index(indio_dev->dev.of_node,
> > > > > - "st,adc-alt-channel", chan_idx,
> > > > > - &df_ch->alt_si);
> > > >
> > > > > + df_ch->alt_si = of_property_present(indio_dev->dev.of_node,
> > > >
> > > > I believe it still has another (serious?) issue. We usually don't use indio_dev
> > > > for device properties. It's not a device that is described in DT.
> > > > It seems the only driver in IIO that does that. Note, I haven't conducted any
> > > > deeper research, it might be (however I'm quite in doubt) that this is correct
> > > > use and one device registers a few indio_dev:s.
> > >
> > > It is curious. The registration sequence in this driver is complex, but I'm not
> > > seeing anything that sets the fwnode for the struct iio_dev->dev before calling
> > > the init() callbacks that end up in this code. It is set later by iio_device_register()
> > > (iirc that has something to do with consumers turning up later).
> > >
> > > St folk could you take a look at this and see what we are missing
> > > if it does currently work?
> > >
> > > For now I'll apply this patch but might need to drop it if a fix clashes
> > > with it.
> >
> > I confirm that the current legacy path is functional
> > (With the st,adc-alt-channel property fix applied)
>
> Yeah, it's here
> https://elixir.bootlin.com/linux/v7.1.1/source/drivers/iio/adc/stm32-dfsdm-adc.c#L1772
> and should gone. Basically one wants to replace all these to use device and
> fwnode propery APIs and proper device node, without that hack.
If we 'were' going to keep this it should have been using the helper
to set that. I thought all those had been cleaned up so didn't check
for it being directly written :( Obviously this comment is irrelevant
given the code is going away!
Jonathan
>
> > It currently works because the driver initializes np from dev->of_node in
> > probe, and that value is then used in init callbacks.
> >
> > I agree that this approach is not robust, as it depends on initialization
> > sequencing and on using an IIO object that is not the DT owner object. I
> > will prepare a patch to use the DT device directly as the single source for
> > DT properties.
> >
> > I also suggest keeping a fallback path for st,adc-alt-channel so we do not
> > break legacy DTs that have not yet migrated to the new binding.
> > I prepare this also.
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Fuad Tabba @ 2026-06-23 15:03 UTC (permalink / raw)
To: Bradley Morgan
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <CE64C9AC-32D5-495E-B713-552921468FB9@grrlz.net>
On Tue, 23 Jun 2026 at 16:01, Bradley Morgan <include@grrlz.net> wrote:
>
> On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
> >On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> >> Protected guest faults charge long term pins to the VM's mm. Teardown
> >> can run later from file release, where current->mm may be unrelated.
> >>
> >> Drop the charge from kvm->mm instead.
> >>
> >>
> >
> >Applied to fixes, thanks!
> >
> >[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> > commit: d098bb75d14fde2f12155f1a95ec0168160867ce
> >
> >Cheers,
> >
> > M.
> >
>
>
> Hey, which tree did you apply it to?
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git/log/?h=fixes
/fuad
>
>
> Thanks!
^ permalink raw reply
* Re: [PATCH] ARM: imx: Drop obsolte stuff from common.h
From: Frank Li @ 2026-06-23 14:42 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel, imx
In-Reply-To: <ajqZIBDVccYSGoIY@monoceros>
On Tue, Jun 23, 2026 at 04:33:50PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On Tue, Jun 23, 2026 at 08:07:37AM -0500, Frank Li wrote:
> > On Tue, Jun 23, 2026 at 12:45:57PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > i.MX21 (and thus imx21_init_early()) is gone since v5.10-rc1 (commit
> > > 4b563a066611 ("ARM: imx: Remove imx21 support")).
> > >
> > > The init_irq() functions are gone since v5.12-rc5 (commit e2c1b0ff38c9
> > > ("ARM: imx: avic: Convert to using IRQCHIP_DECLARE")).
> > >
> > > And mxc_device_init() was removed for v5.10-rc1 (in commit 8485adf17a15
> > > ("ARM: imx: Remove imx device directory")).
> > >
> > > The last user of imx1_reset_init() is gone since v4.9-rc1 (commit
> > > e1291cffcc50 ("ARM: i.MX: Remove i.MX1 non-DT support")).
> > >
> > > Drop declaration of enum mxc_cpu_pwr_mode, the actual definition follows
> > > later in common.h without a usage in-between.
> > >
> > > All users of of_device_id also include <linux/of.h>,
> > > <linux/of_address.h> or <linux/of_platform.h> which is enough to not
> > > need the forward declaration.
> > >
> > > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> > > ---
> > > [...]
> > > void mx31_map_io(void);
> > > void mx35_map_io(void);
> > > -void imx21_init_early(void);
> > > void imx31_init_early(void);
> > > void imx35_init_early(void);
> > > -void mx31_init_irq(void);
> > > -void mx35_init_irq(void);
> >
> > which commit remove above two functions?
>
> These are covered by:
>
> > > The init_irq() functions are gone since v5.12-rc5 (commit e2c1b0ff38c9
> > > ("ARM: imx: avic: Convert to using IRQCHIP_DECLARE")).
Thanks
Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Bradley Morgan @ 2026-06-23 15:01 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <178222278590.523236.18181071715501850418.b4-ty@kernel.org>
On June 23, 2026 2:53:11 PM GMT+01:00, Marc Zyngier <maz@kernel.org> wrote:
>On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
>> Protected guest faults charge long term pins to the VM's mm. Teardown
>> can run later from file release, where current->mm may be unrelated.
>>
>> Drop the charge from kvm->mm instead.
>>
>>
>
>Applied to fixes, thanks!
>
>[1/1] KVM: arm64: account pKVM reclaim against the VM mm
> commit: d098bb75d14fde2f12155f1a95ec0168160867ce
>
>Cheers,
>
> M.
>
Hey, which tree did you apply it to?
Thanks!
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frank Li @ 2026-06-23 14:36 UTC (permalink / raw)
To: Peng Fan
Cc: Frieder Schrempf, Krzysztof Kozlowski, Frieder Schrempf,
Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <ajoJFt6c1cKELlH6@shlinux89>
On Tue, Jun 23, 2026 at 12:18:30PM +0800, Peng Fan wrote:
> On Mon, Jun 22, 2026 at 09:14:43AM -0500, Frank Li wrote:
> >On Wed, Jun 17, 2026 at 01:36:30PM +0200, Frieder Schrempf wrote:
> >> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
> >> > On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
> >> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> >>
> >> >> Some SoCs like the i.MX9 family allow full access to the fuses only
> >> >> through the secure enclave firmware API. Add a property to reference
> >> >> the secure enclave node and let the driver use the API.
> >> >>
> >> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> >> ---
> >> >> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
> >> >> 1 file changed, 4 insertions(+)
> >> >>
> >> >> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> >> index a8076d0e2737..14a6429f4a4c 100644
> >> >> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> >> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> >> >> @@ -53,6 +53,10 @@ properties:
> >> >> reg:
> >> >> maxItems: 1
> >> >>
> >> >> + secure-enclave:
> >> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> >> + description: A phandle to the secure enclave node
> >> >
> >> > Two things here:
> >> > 1. Here you describe what for is that phandle, how it is used by the
> >> > hardware. Currently the description repeats the property name and type,
> >> > so not much useful.
> >>
> >> Ok, agree.
> >>
> >> >
> >> > 2. If you access OTP via firmware, then this is completely different
> >> > interface than MMIO, thus:
> >> > A. reg is not appropriate
> >> > B. Device is very different thus it has different compatible and I even
> >> > claim should be in different binding. Devices having completely
> >> > different SW interface should not be in the same binding, at least
> >> > usually.
> >> >
> >> > If any of above is not accurate, then your commit msg should answer why
> >> > and give some background.
> >>
> >> Thanks for the feedback!
> >>
> >> The driver currently uses the limited MMIO (FSB) interface to access the
> >> OTPs. The intention is to support the firmware interface alongside the
> >> MMIO interface so the driver can pick the interface that is available
> >> (firmware might not be loaded) and fallback to MMIO.
> >
> >Does ELE and MMIO access the same bank of fuse? If access the same bank,
>
> Some fuse banks are only accessible through ELE firmware. Some fuse banks
> are accessible using MMIO. In theory, ELE firmware are able to access all
> fuse banks.
So use two driver for it, one use current MMIO ot access part of fuse box.
use ELE access the left part, which MMIO can't access.
MMIO should be simple and quick than go through ELE.
Frank
>
> Regards
> Peng
>
> >why not always use MMIO. Any beneafit from ELE firmware?
>
> >
> >Frank
> >>
> >> Following your argument would mean a driver deciding by itself which
> >> interface to use at runtime is not something we want to have in general,
> >> right?
> >>
> >> In turn this would mean we need two drivers, or at least two
> >> compatibles/bindings for something that is effectively the same hardware.
> >>
> >> Actually, my first RFC approach [1] was to create a separate driver. But
> >> in the end it seemed very weird to have two drivers and two DT nodes for
> >> the same hardware block. Also I have no idea what happens if both
> >> interfaces are used at the same time.
> >>
> >> The other idea from back then was to replace the MMIO (FSB) interface
> >> with ELE, but this would mean that we rely on the proprietary ELE
> >> firmware to be available for simple things like reading a MAC address,
> >> which is not desirable either, I guess.
> >>
> >> In which direction should I move on with this?
> >>
> >> [1]
> >> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250416142715.1042363-1-frieder@fris.de/
> >>
^ permalink raw reply
* Re: [PATCH] clk: mediatek: mt6735: Unregister PLLs on probe failure
From: Brian Masney @ 2026-06-23 14:35 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Yassine Oudjana, Michael Turquette, Stephen Boyd,
Matthias Brugger, AngeloGioacchino Del Regno, linux-clk,
linux-mediatek, linux-kernel, linux-arm-kernel, Ijae Kim
In-Reply-To: <20260623094125.95791-1-mhun512@gmail.com>
Hi Myeonghun,
On Tue, Jun 23, 2026 at 06:41:11PM +0900, Myeonghun Pak wrote:
> mtk_clk_register_plls() registers the apmixedsys PLL clocks manually, while
> clk_mt6735_apmixed_remove() unregisters them on driver removal.
>
> If devm_of_clk_add_hw_provider() fails after the PLL registration succeeds,
> probe returns the error directly and the remove callback is not run. This
> leaves the registered PLL clocks behind on the probe failure path.
>
> Add an unregister_plls error path so provider registration failures unwind the
> PLLs before returning the error.
Please run your patches through checkpatch.pl before sending.
>
> Fixes: 43c04ed79189 ("clk: mediatek: Add drivers for MediaTek MT6735 main clock and reset drivers")
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
>
> ---
> drivers/clk/mediatek/clk-mt6735-apmixedsys.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
> index 9e30c089a2..04cf9665ec 100644
> --- a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
> +++ b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
> @@ -102,10 +102,17 @@ static int clk_mt6735_apmixed_probe(struct platform_device *pdev)
>
> ret = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_onecell_get,
> clk_data);
> - if (ret)
> + if (ret) {
> dev_err(&pdev->dev,
> "Failed to register clock provider: %d\n", ret);
> + goto unregister_plls;
> + }
> +
> + return 0;
>
> +unregister_plls:
> + mtk_clk_unregister_plls(apmixedsys_plls, ARRAY_SIZE(apmixedsys_plls),
> + clk_data);
> return ret;
> }
This fix is correct. Since only one path will encounter this, personally
I would just put the call to mtk_clk_unregister_plls() inside the if
statement above to simplify this further.
Brian
^ permalink raw reply
* Re: [PATCH] ARM: imx: Drop obsolte stuff from common.h
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-23 14:33 UTC (permalink / raw)
To: Frank Li
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel, imx
In-Reply-To: <ajqFGWp3XKqDhPpE@SMW015318>
[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]
On Tue, Jun 23, 2026 at 08:07:37AM -0500, Frank Li wrote:
> On Tue, Jun 23, 2026 at 12:45:57PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > i.MX21 (and thus imx21_init_early()) is gone since v5.10-rc1 (commit
> > 4b563a066611 ("ARM: imx: Remove imx21 support")).
> >
> > The init_irq() functions are gone since v5.12-rc5 (commit e2c1b0ff38c9
> > ("ARM: imx: avic: Convert to using IRQCHIP_DECLARE")).
> >
> > And mxc_device_init() was removed for v5.10-rc1 (in commit 8485adf17a15
> > ("ARM: imx: Remove imx device directory")).
> >
> > The last user of imx1_reset_init() is gone since v4.9-rc1 (commit
> > e1291cffcc50 ("ARM: i.MX: Remove i.MX1 non-DT support")).
> >
> > Drop declaration of enum mxc_cpu_pwr_mode, the actual definition follows
> > later in common.h without a usage in-between.
> >
> > All users of of_device_id also include <linux/of.h>,
> > <linux/of_address.h> or <linux/of_platform.h> which is enough to not
> > need the forward declaration.
> >
> > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> > ---
> > [...]
> > void mx31_map_io(void);
> > void mx35_map_io(void);
> > -void imx21_init_early(void);
> > void imx31_init_early(void);
> > void imx35_init_early(void);
> > -void mx31_init_irq(void);
> > -void mx35_init_irq(void);
>
> which commit remove above two functions?
These are covered by:
> > The init_irq() functions are gone since v5.12-rc5 (commit e2c1b0ff38c9
> > ("ARM: imx: avic: Convert to using IRQCHIP_DECLARE")).
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 3/3] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Will Deacon @ 2026-06-23 14:33 UTC (permalink / raw)
To: Jinjie Ruan
Cc: Michael Kelley, catalin.marinas@arm.com,
tsbogend@alpha.franken.de, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, peterz@infradead.org, kees@kernel.org,
nathan@kernel.org, linusw@kernel.org, ojeda@kernel.org,
david.kaplan@amd.com, lukas.bulwahn@redhat.com,
ryan.roberts@arm.com, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, thuth@redhat.com, oupton@kernel.org,
yeoreum.yun@arm.com, miko.lenczewski@arm.com, broonie@kernel.org,
kevin.brodsky@arm.com, james.clark@linaro.org, tabba@google.com,
mrigendra.chaubey@gmail.com, arnd@arndb.de,
anshuman.khandual@arm.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <b828dd7a-0363-46cf-aad0-e4962e299338@huawei.com>
On Mon, Jun 22, 2026 at 05:16:30PM +0800, Jinjie Ruan wrote:
>
>
> On 6/18/2026 8:21 PM, Will Deacon wrote:
> > Hi Jinjie,
> >
> > On Mon, Jun 15, 2026 at 04:51:48PM +0800, Jinjie Ruan wrote:
> >> On 6/12/2026 11:45 PM, Michael Kelley wrote:
> >>> From: Jinjie Ruan <ruanjinjie@huawei.com> Sent: Thursday, June 11, 2026 6:38 AM
> >>>>
> >>>> Support for parallel secondary CPU bringup is already utilized by x86,
> >>>> MIPS, and RISC-V. This patch brings this capability to the arm64
> >>>> architecture.
> >>>>
> >>>> Rework the global `secondary_data` accessed during early boot into
> >>>> a per-CPU array. This array maps logical CPU IDs to MPIDR_EL1 values,
> >>>> enabling the early boot code in head.S to resolve each secondary CPU's
> >>>> logical ID concurrently.
> >>>>
> >>>> To fully enable HOTPLUG_PARALLEL, this patch implements:
> >>>> 1) An arm64-specific arch_cpuhp_kick_ap_alive() handler.
> >>>> 2) Callbacks to cpuhp_ap_sync_alive() inside secondary_start_kernel().
> >>>>
> >>>> Successfully tested on QEMU ARM64 virt machine (KVM on, 128 vCPUs).
> >>>>
> >>>> | test kernel | secondary CPUs boot time |
> >>>> | --------------------- | -------------------- |
> >>>> | Without this patch | 155.672 |
> >>>> | cpuhp.parallel=0 | 62.897 |
> >>>> | cpuhp.parallel=1 | 166.703 |
> >>>
> >>> The last two rows seem mixed up. I would expect parallel=0 to
> >>> result in a longer boot time.
> >>
> >> Hi, Michael,
> >>
> >> The results are correct and not mixed up.
> >>
> >> Compared to the original non‑HOTPLUG_PARALLEL approach, the advantage of
> >> cpuhp.parallel=0 lies in its use of cpu_relax(`yield` on arm64) instead
> >> of the wait_for_completion_timeout() mechanism (which may cause sleep
> >> and context switching). This significantly reduces the overhead of VM
> >> exits and context switches in a KVM guest, thereby cutting the secondary
> >> CPU boot time by more than half.
> >
> > I don't think that's a particularly compelling reason to enable this for
> > arm64, in all honesty. The yield instruction typically doesn't do
> > anything on actual arm64 silicon, so this probably means that you're
> > introducing busy-loops which tend to be bad for power and scalability.
> >
> > I implemented this a while ago [1] but didn't manage to see much in terms
> > of performance improvement and so I didn't bother to send the patches out
> > after talking about it at KVM forum [2]. However, as mentioned at the end
> > of that talk, it _is_ still useful for confidential VMs using PSCI so
> > let me dust off my old series and send it out to see what you think.
>
> Hi Will,
>
> Thanks for the insights! Your point about using PSCI v0.2's Context ID
> to avoid the NR_CPUS array for input parameters (like
> secondary_data.task) is incredibly elegant.
>
> However, if I understand your series correctly, it seems your approach
> primarily targets preventing the concurrent use of secondary_data.task,
> but it doesn't seem to account for the potential data trampling on
> secondary_data.status when multiple secondary CPUs are brought up
> simultaneously.
>
> update_cpu_boot_status()
> -> WRITE_ONCE(secondary_data.status.flags[val], 1)
>
> arch_cpuhp_cleanup_kick_cpu()
> -> status = READ_ONCE(secondary_data.status)
I need to dust it back off but IIRC I made that thing a byte array, with
a separate byte for each failure reason.
Will
^ permalink raw reply
* Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-23 14:32 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260623030736.1421537-2-sherry.sun@oss.nxp.com>
On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> suspend to preserve wakeup capability of the devices and also not to power
> on the devices in the init path.
> This allows controller power-off to be skipped when some devices(e.g. M.2
> cards key E without auxiliary power) required to support PCIe L2 link state
> and wake-up mechanisms.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 36 +++++++++++++++++----------
> 1 file changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 0fa716d1ed75..ff5a9565dbbf 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> }
> }
>
> - ret = pci_pwrctrl_create_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to create pwrctrl devices\n");
> - goto err_reg_disable;
> + if (!pci->suspended) {
> + ret = pci_pwrctrl_create_devices(dev);
Is possible move pci_pwrctrl_create_devices() of pci_pwrctrl_create_devices
and call it direct at probe() function, like other regulator_get function.
Frank
> + if (ret) {
> + dev_err(dev, "failed to create pwrctrl devices\n");
> + goto err_reg_disable;
> + }
> }
>
> - ret = pci_pwrctrl_power_on_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to power on pwrctrl devices\n");
> - goto err_pwrctrl_destroy;
> + if (!pp->skip_pwrctrl_off) {
> + ret = pci_pwrctrl_power_on_devices(dev);
> + if (ret) {
> + dev_err(dev, "failed to power on pwrctrl devices\n");
> + goto err_pwrctrl_destroy;
> + }
> }
>
> ret = imx_pcie_clk_enable(imx_pcie);
> @@ -1460,9 +1464,10 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> err_clk_disable:
> imx_pcie_clk_disable(imx_pcie);
> err_pwrctrl_power_off:
> - pci_pwrctrl_power_off_devices(dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(dev);
> err_pwrctrl_destroy:
> - if (ret != -EPROBE_DEFER)
> + if (ret != -EPROBE_DEFER && !pci->suspended)
> pci_pwrctrl_destroy_devices(dev);
> err_reg_disable:
> if (imx_pcie->vpcie)
> @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
> }
> imx_pcie_clk_disable(imx_pcie);
>
> - pci_pwrctrl_power_off_devices(pci->dev);
> + if (!pci->pp.skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(pci->dev);
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> }
> @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct platform_device *pdev)
> static void imx_pcie_shutdown(struct platform_device *pdev)
> {
> struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> + struct dw_pcie *pci = imx_pcie->pci;
> + struct dw_pcie_rp *pp = &pci->pp;
>
> /* bring down link, so bootloader gets clean state in case of reboot */
> imx_pcie_assert_core_reset(imx_pcie);
> imx_pcie_assert_perst(imx_pcie, true);
> - pci_pwrctrl_power_off_devices(&pdev->dev);
> - pci_pwrctrl_destroy_devices(&pdev->dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(&pdev->dev);
> + if (!pci->suspended)
> + pci_pwrctrl_destroy_devices(&pdev->dev);
> }
>
> static const struct imx_pcie_drvdata drvdata[] = {
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Will Deacon @ 2026-06-23 14:30 UTC (permalink / raw)
To: Marc Zyngier
Cc: Bradley Morgan, Oliver Upton, Fuad Tabba, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <86se6dqsav.wl-maz@kernel.org>
On Tue, Jun 23, 2026 at 02:50:48PM +0100, Marc Zyngier wrote:
> On Tue, 23 Jun 2026 14:41:20 +0100,
> Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Jun 22, 2026 at 09:32:29AM +0100, Marc Zyngier wrote:
> > > On Sun, 21 Jun 2026 22:31:55 +0100,
> > > Bradley Morgan <include@grrlz.net> wrote:
> > > >
> > > > Protected guest faults charge long term pins to the VM's mm. Teardown
> > > > can run later from file release, where current->mm may be unrelated.
> > > >
> > > > Drop the charge from kvm->mm instead.
> > > >
> > > > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> > > > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > > > ---
> > > > arch/arm64/kvm/pkvm.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > > > index 053e4f733e4b..428723b1b0f5 100644
> > > > --- a/arch/arm64/kvm/pkvm.c
> > > > +++ b/arch/arm64/kvm/pkvm.c
> > > > @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
> > > > page = pfn_to_page(mapping->pfn);
> > > > WARN_ON_ONCE(mapping->nr_pages != 1);
> > > > unpin_user_pages_dirty_lock(&page, 1, true);
> > > > - account_locked_vm(current->mm, 1, false);
> > > > + account_locked_vm(kvm->mm, 1, false);
> > > > pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> > > > kfree(mapping);
> > > > }
> > >
> > > Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2
> > > teardown.
> > >
> > > Will, what do you think?
> >
> > Thanks, this looks correct to me.
> >
> > While I was thinking about it, I also started looking at the use of
> > 'current->mm' in kvm_arch_prepare_memory_region() in case that should
> > also be 'kvm->mm'. However, I then realised that I don't really grok
> > that code at all because it does a bunch of checking on the VMAs with
> > mmap_read_lock(current->mm) held, but then that lock is dropped
> > immediately after doing the checks so I'm not really sure what they
> > are protected against. Presumably, the address space could be modified
> > as soon as the lock is dropped?
> >
> > But it's hot, so I'm probably missing something here.
>
> I think this is just trying to catch a few obvious issues, such as
> dirty logging on device memory, but that only works for well behaved
> userspace that is making "a honest mistake".
>
> For the more trying ones, we end-up doing the same checks again at
> fault time anyway.
Got it, so it's a best-effort check. Although it does mean that memslot
changes have to be done by the same mm as kvm->mm, otherwise you could
get a spurious error back from the kernel.
Will
^ permalink raw reply
* [PATCH v3 4/7] serial: 8250_aspeed_vuart: add VUART over PCI
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
This patch enables the VUART over PCI possible for the AST2600. This is
only activated if the 'aspeed,vuart-over-pci' property flag is set on an
'ast2600-vuart' compatible node.
The AST2600 has 2 VUART that are usable over PCI. These are the VUART3
and VUART4 in the 'apseed-g6.dtsi'.
This code sets the BMC PCI device enables
bits, sets the PCI class code to MFD device and configures MSI interrupts.
There is no disable function. Removing this driver should not disable
the BMC PCI device, as other drivers could use it.
However, if all the drivers using it are removed, the
BMC PCI device will still be activated, which is not ideal. Realistically though, this is not a
use case for a BMC, the drivers will never be removed.
This is useful on PCIe BMC expansion cards that use the AST2600, such as the
ASUS Kommando IPMI Expansion Card.
Registers initialisation taken from ASPEED 6.18 Kernel SDK.
Return code checks were added to each register write.
The code has been simplified and macros have been added.
The ASPEED_SCUC24 regmap update is missing a macro for 'BIT(14)'. I was
unable to determine the purpose of this bit. In the AST2600 A3
datasheet it is marked as 'reserved'. It is only used on the other
revision. As I only have the AST2600A3, I was unable to try this code
path.
Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/tty/serial/8250/8250_aspeed_vuart.c | 86 +++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 6afa2f4057e1..e204e26fa173 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -32,6 +32,27 @@
#define ASPEED_VUART_DEFAULT_SIRQ 4
#define ASPEED_VUART_DEFAULT_SIRQ_POLARITY IRQ_TYPE_LEVEL_LOW
+#define ASPEED_SCU_SILICON_REVISION_ID 0x04
+#define AST2600A3_REVISION_ID 0x05030303
+
+#define ASPEED_SCUC24 0xC24
+#define ASPEED_SCUC24_MSI_ROUTING_MASK GENMASK(11, 10)
+#define ASPEED_SCUC24_MSI_ROUTING_PCIe2LPC_PCIDEV1 (0x2 << 10)
+#define ASPEED_SCUC24_PCIDEV1_INTX_MSI_HOST2BMC_EN BIT(18)
+#define ASPEED_SCUC24_PCIDEV1_INTX_MSI_SCU560_EN BIT(17)
+
+
+#define ASPEED_SCU_PCIE_CONF_CTRL 0xC20
+#define SCU_PCIE_CONF_BMC_DEV_EN BIT(8)
+#define SCU_PCIE_CONF_BMC_DEV_EN_MMIO BIT(9)
+#define SCU_PCIE_CONF_BMC_DEV_EN_MSI BIT(11)
+#define SCU_PCIE_CONF_BMC_DEV_EN_IRQ BIT(13)
+#define SCU_PCIE_CONF_BMC_DEV_EN_PCIE_BUS_MASTER BIT(14)
+#define SCU_PCIE_CONF_BMC_DEV_EN_E2L BIT(15)
+#define SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE BIT(21)
+
+#define ASPEED_SCU_BMC_DEV_CLASS 0xC68
+
struct aspeed_vuart {
struct device *dev;
int line;
@@ -412,6 +433,62 @@ static int aspeed_vuart_map_irq_polarity(u32 dt)
}
}
+static int aspeed_ast2600_vuart_over_pci_set_enabled(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ u32 silicon_revision_id;
+ struct regmap *scu;
+ int rc;
+
+ u32 pcie_config_ctl = SCU_PCIE_CONF_BMC_DEV_EN_IRQ |
+ SCU_PCIE_CONF_BMC_DEV_EN_MMIO |
+ SCU_PCIE_CONF_BMC_DEV_EN_MSI |
+ SCU_PCIE_CONF_BMC_DEV_EN_PCIE_BUS_MASTER |
+ SCU_PCIE_CONF_BMC_DEV_EN_E2L |
+ SCU_PCIE_CONF_BMC_DEV_EN_LPC_DECODE |
+ SCU_PCIE_CONF_BMC_DEV_EN;
+
+ scu = syscon_regmap_lookup_by_phandle(dev->of_node, "clocks");
+ if (IS_ERR(scu)) {
+ dev_err(&pdev->dev, "failed to find SCU regmap\n");
+ return PTR_ERR(scu);
+ }
+
+ /* update class code to be an MFD device */
+ if (regmap_write(scu, ASPEED_SCU_BMC_DEV_CLASS, 0xff000000)) {
+ dev_err(dev, "could not set PCI class code\n");
+ return -EIO;
+ }
+
+ if (regmap_update_bits(scu, ASPEED_SCU_PCIE_CONF_CTRL,
+ pcie_config_ctl, pcie_config_ctl)) {
+ dev_err(dev, "could not set PCIe configuration\n");
+ return -EIO;
+ }
+
+ if (regmap_read(scu, ASPEED_SCU_SILICON_REVISION_ID, &silicon_revision_id)) {
+ dev_err(dev, "could not read silicon revision\n");
+ return -EIO;
+ }
+
+ if (silicon_revision_id == AST2600A3_REVISION_ID)
+ rc = regmap_update_bits(scu, ASPEED_SCUC24,
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_HOST2BMC_EN | ASPEED_SCUC24_MSI_ROUTING_MASK,
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_HOST2BMC_EN | ASPEED_SCUC24_MSI_ROUTING_PCIe2LPC_PCIDEV1);
+ else
+ rc = regmap_update_bits(scu, ASPEED_SCUC24,
+ /* The bit 14 is reserved in the Datasheet, so we can't say what it does. This revision has not been tested */
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_SCU560_EN | BIT(14) | ASPEED_SCUC24_MSI_ROUTING_MASK,
+ ASPEED_SCUC24_PCIDEV1_INTX_MSI_SCU560_EN | BIT(14) | ASPEED_SCUC24_MSI_ROUTING_PCIe2LPC_PCIDEV1);
+ if (rc) {
+ dev_err(dev, "could not set PCI device 1 MSI interrupt routing\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+
static int aspeed_vuart_probe(struct platform_device *pdev)
{
struct of_phandle_args sirq_polarity_sense_args;
@@ -540,6 +617,15 @@ static int aspeed_vuart_probe(struct platform_device *pdev)
aspeed_vuart_set_host_tx_discard(vuart, true);
platform_set_drvdata(pdev, vuart);
+ if (of_device_is_compatible(dev->of_node, "aspeed,ast2600-vuart") &&
+ of_property_read_bool(dev->of_node, "aspeed,vuart-over-pci")) {
+ rc = aspeed_ast2600_vuart_over_pci_set_enabled(pdev);
+ if (rc) {
+ dev_err(dev, "could not enable VUART over PCI\n");
+ return rc;
+ }
+ }
+
return 0;
err_sysfs_remove:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC 3/3] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Will Deacon @ 2026-06-23 14:30 UTC (permalink / raw)
To: Jinjie Ruan
Cc: Michael Kelley, catalin.marinas@arm.com,
tsbogend@alpha.franken.de, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, peterz@infradead.org, kees@kernel.org,
nathan@kernel.org, linusw@kernel.org, ojeda@kernel.org,
david.kaplan@amd.com, lukas.bulwahn@redhat.com,
ryan.roberts@arm.com, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, thuth@redhat.com, oupton@kernel.org,
yeoreum.yun@arm.com, miko.lenczewski@arm.com, broonie@kernel.org,
kevin.brodsky@arm.com, james.clark@linaro.org, tabba@google.com,
mrigendra.chaubey@gmail.com, arnd@arndb.de,
anshuman.khandual@arm.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <2a34ff43-78a0-4d99-885a-0e7f560634ca@huawei.com>
On Mon, Jun 22, 2026 at 04:06:38PM +0800, Jinjie Ruan wrote:
> On 6/18/2026 8:21 PM, Will Deacon wrote:
> > On Mon, Jun 15, 2026 at 04:51:48PM +0800, Jinjie Ruan wrote:
> >> On 6/12/2026 11:45 PM, Michael Kelley wrote:
> >>> From: Jinjie Ruan <ruanjinjie@huawei.com> Sent: Thursday, June 11, 2026 6:38 AM
> >>>>
> >>>> Support for parallel secondary CPU bringup is already utilized by x86,
> >>>> MIPS, and RISC-V. This patch brings this capability to the arm64
> >>>> architecture.
> >>>>
> >>>> Rework the global `secondary_data` accessed during early boot into
> >>>> a per-CPU array. This array maps logical CPU IDs to MPIDR_EL1 values,
> >>>> enabling the early boot code in head.S to resolve each secondary CPU's
> >>>> logical ID concurrently.
> >>>>
> >>>> To fully enable HOTPLUG_PARALLEL, this patch implements:
> >>>> 1) An arm64-specific arch_cpuhp_kick_ap_alive() handler.
> >>>> 2) Callbacks to cpuhp_ap_sync_alive() inside secondary_start_kernel().
> >>>>
> >>>> Successfully tested on QEMU ARM64 virt machine (KVM on, 128 vCPUs).
> >>>>
> >>>> | test kernel | secondary CPUs boot time |
> >>>> | --------------------- | -------------------- |
> >>>> | Without this patch | 155.672 |
> >>>> | cpuhp.parallel=0 | 62.897 |
> >>>> | cpuhp.parallel=1 | 166.703 |
> >>>
> >>> The last two rows seem mixed up. I would expect parallel=0 to
> >>> result in a longer boot time.
> >>
> >> The results are correct and not mixed up.
> >>
> >> Compared to the original non‑HOTPLUG_PARALLEL approach, the advantage of
> >> cpuhp.parallel=0 lies in its use of cpu_relax(`yield` on arm64) instead
> >> of the wait_for_completion_timeout() mechanism (which may cause sleep
> >> and context switching). This significantly reduces the overhead of VM
> >> exits and context switches in a KVM guest, thereby cutting the secondary
> >> CPU boot time by more than half.
> >
> > I don't think that's a particularly compelling reason to enable this for
> > arm64, in all honesty. The yield instruction typically doesn't do
> > anything on actual arm64 silicon, so this probably means that you're
> > introducing busy-loops which tend to be bad for power and scalability.
>
> After updating the implementation in v2, the performance gains are
> primarily observed on actual hardware.
... but that's presumably because the secondary cores are busy-looping.
That's not something we should do during boot. It might be "fast" on
your machine but it will probably be "hot" as well.
> > I implemented this a while ago [1] but didn't manage to see much in terms
> > of performance improvement and so I didn't bother to send the patches out
>
> As shown in v2 below, on actual hardware, this results in a 40%–60%
> reduction in boot time.
>
> Bringup Time Comparison (ms, lower is better):
>
> | Platform | Baseline| P=0 | P=1 | Delta(%)|
> | --------------------- | ------- | ------- | ------ | ------- |
> | 64-core ATF QEMU | 2075.8 | 2080.7 | 1653.4 | 20.34% |
> | 192-core server(HIP12)| 14619.2 | 14619.1 | 8589.4 | 41.21% |
> | 32-core board | 2776.5 | 2881.0 | 1045.0 | 62.36% |
>
> Link:
> https://lore.kernel.org/all/20260618092444.1316336-5-ruanjinjie@huawei.com/
To be honest, I'm pretty confused with all these numbers. Your first
table above suggests that parallel boot is *slower* but then this table
suggests the opposite. However, it also has a QEMU entry despite being
"on actual hardware". Is that in a VM?
> > after talking about it at KVM forum [2]. However, as mentioned at the end
> > of that talk, it _is_ still useful for confidential VMs using PSCI so
> > let me dust off my old series and send it out to see what you think.
> >
> > It relies on PSCI v0.2, which means we don't need the NR_CPUS size array
> > for secondary_data and I also have some support for error handling (it
> > doesn't look like you handle __early_cpu_boot_status properly).
>
> I need some time to look closely at your patch. Alternatively, I will
> integrate your changes, re-test everything on actual hardware, and then
> send out a revised version.
Please just give me a week or so to rebase my changes and send them out
for discussion. It'll be interesting to see what numbers you get.
> It seems that the following patch removing
> `rcutree_report_cpu_starting()` will reintroduce the original issue as
> commit ce3d31ad3cac ("arm64/smp: Move
> rcu_cpu_starting() earlier") soloved.
>
> Link:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=cpu-hotplug&id=bba4b62f45f2614bf6085e6cd3f233528f85bf26
>
> Indeed, I also noticed that the invocation order of
> rcutree_report_cpu_starting() on arm64 is somewhat suboptimal. It
> hinders the implementation of parallel bringup on arm64 and could
> potentially lead to RCU stalls.
>
> Link:
> https://lore.kernel.org/all/20260618092444.1316336-4-ruanjinjie@huawei.com/
>
> [ 0.329017] smp: Bringing up secondary CPUs ...
> [ 0.343628] Detected VIPT I-cache on CPU1
> [ 0.343788]
> [ 0.343806] =============================
> [ 0.343816] WARNING: suspicious RCU usage
> [ 0.343966] 7.1.0-rc1-g27c1871848a2 #109 Not tainted
> [ 0.344087] -----------------------------
> [ 0.344098] kernel/locking/lockdep.c:3801 RCU-list traversed in
> non-reader section!!
Thanks, I'll look into this.
Will
^ permalink raw reply
* [PATCH v3 6/7] ARM: dts: aspeed: g6: Change vuart compatible string for ast2600
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
Use the ast2600 compatible string.
This makes it more precise and enables specific ast2600 properties.
Still use the ast2500 compatible string as a fallback.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 56bb3b0444f7..7c02633f2bd6 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -707,7 +707,7 @@ emmc: sdhci@1e750100 {
};
vuart1: serial@1e787000 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e787000 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
@@ -717,7 +717,7 @@ vuart1: serial@1e787000 {
};
vuart3: serial@1e787800 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e787800 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
@@ -727,7 +727,7 @@ vuart3: serial@1e787800 {
};
vuart2: serial@1e788000 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e788000 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
@@ -737,7 +737,7 @@ vuart2: serial@1e788000 {
};
vuart4: serial@1e788800 {
- compatible = "aspeed,ast2500-vuart";
+ compatible = "aspeed,ast2600-vuart", "aspeed,ast2500-vuart";
reg = <0x1e788800 0x40>;
reg-shift = <2>;
interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 7/7] ARM: dts: aspeed: g6: add aspeed,vuart-over-pci prop to vuart3 and 4
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
The VUART 3 and 4 are VUART over PCI.
This flag indicates this information.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 7c02633f2bd6..2a19463b4c21 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -723,6 +723,7 @@ vuart3: serial@1e787800 {
interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_APB2>;
no-loopback-test;
+ aspeed,vuart-over-pci;
status = "disabled";
};
@@ -743,6 +744,7 @@ vuart4: serial@1e788800 {
interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&syscon ASPEED_CLK_APB2>;
no-loopback-test;
+ aspeed,vuart-over-pci;
status = "disabled";
};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 5/7] soc: aspeed: add host-side PCIe BMC device driver
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
Add support for VUART over PCIe between BMC and host.
This add host side driver.
This only support the AST2600.
Taken from ASPEED 6.18 Kernel SDK and trimmed down.
The host can't detect the VUART adresses, they are forced
at 0x3f8 and 0x2f8, similar from the initial ASPEED driver.
The MSI vector index has been changed for the VUART2 from 15 to 17.
The index 15 used in the initial driver was not working.
Data path in both direction is tested on both VUART.
Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com>
Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
Tested-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/soc/aspeed/Kconfig | 8 +
drivers/soc/aspeed/Makefile | 1 +
drivers/soc/aspeed/aspeed-host-bmc-dev.c | 183 +++++++++++++++++++++++
3 files changed, 192 insertions(+)
create mode 100644 drivers/soc/aspeed/aspeed-host-bmc-dev.c
diff --git a/drivers/soc/aspeed/Kconfig b/drivers/soc/aspeed/Kconfig
index 63a656449a1a..ebd023b10701 100644
--- a/drivers/soc/aspeed/Kconfig
+++ b/drivers/soc/aspeed/Kconfig
@@ -4,6 +4,14 @@ if ARCH_ASPEED || COMPILE_TEST
menu "ASPEED SoC drivers"
+config ASPEED_HOST_BMC_DEV
+ tristate "ASPEED Host BMC Device"
+ depends on PCI
+ depends on SERIAL_8250
+ help
+ Enable support for the ASPEED AST2600 BMC Device on the Host.
+ This configure the PCIe and setup two 8250 compatible VUART ports.
+
config ASPEED_LPC_CTRL
tristate "ASPEED LPC firmware cycle control"
select REGMAP
diff --git a/drivers/soc/aspeed/Makefile b/drivers/soc/aspeed/Makefile
index b35d74592964..c515e163eab7 100644
--- a/drivers/soc/aspeed/Makefile
+++ b/drivers/soc/aspeed/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ASPEED_HOST_BMC_DEV) += aspeed-host-bmc-dev.o
obj-$(CONFIG_ASPEED_LPC_CTRL) += aspeed-lpc-ctrl.o
obj-$(CONFIG_ASPEED_LPC_SNOOP) += aspeed-lpc-snoop.o
obj-$(CONFIG_ASPEED_UART_ROUTING) += aspeed-uart-routing.o
diff --git a/drivers/soc/aspeed/aspeed-host-bmc-dev.c b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
new file mode 100644
index 000000000000..3160b6aedb5b
--- /dev/null
+++ b/drivers/soc/aspeed/aspeed-host-bmc-dev.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright (C) ASPEED Technology Inc.
+
+#include <linux/init.h>
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/pci.h>
+#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
+
+#define BMC_MULTI_MSI 32
+#define PCI_BMC_DEVICE_ID 0x2402
+
+#define DRIVER_NAME "aspeed-host-bmc-dev"
+
+enum aspeed_platform_id {
+ ASPEED,
+};
+
+static int vuart_msi_index[2] = { 16, 17 };
+static int vuart_port_addr[2] = {0x3f8, 0x2f8};
+
+struct aspeed_pci_bmc_dev {
+ struct device *dev;
+ kernel_ulong_t driver_data;
+ int id;
+
+ unsigned long message_bar_base;
+
+ struct uart_8250_port uart[2];
+ int uart_line[2];
+
+ int *msi_idx_table;
+};
+
+static void aspeed_pci_setup_irq_resource(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+
+ pci_bmc_dev->msi_idx_table = vuart_msi_index;
+
+ if (pci_alloc_irq_vectors(pdev, 1, BMC_MULTI_MSI, PCI_IRQ_INTX | PCI_IRQ_MSI) <= 1)
+ /* If pci_alloc fail, set all msi index to the first vector */
+ memset(pci_bmc_dev->msi_idx_table, 0, sizeof(vuart_msi_index));
+}
+
+static int aspeed_pci_bmc_device_setup_vuart(struct pci_dev *pdev, int idx)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+ struct uart_8250_port *uart = &pci_bmc_dev->uart[idx];
+ u16 vuart_ioport;
+ int ret;
+
+ /* Assign the line to non-exist device before everything is setup */
+ pci_bmc_dev->uart_line[idx] = -ENOENT;
+
+ vuart_ioport = vuart_port_addr[idx];
+ /* ASPEED BMC device shift adresses by 2 to the left */
+ vuart_ioport = vuart_ioport << 2;
+
+ uart->port.flags = UPF_SKIP_TEST | UPF_BOOT_AUTOCONF | UPF_SHARE_IRQ;
+ uart->port.uartclk = 115200 * 16;
+ uart->port.irq = pci_irq_vector(pdev, pci_bmc_dev->msi_idx_table[idx]);
+ uart->port.dev = dev;
+ uart->port.iotype = UPIO_MEM32;
+ uart->port.iobase = 0;
+ uart->port.mapbase = pci_bmc_dev->message_bar_base + vuart_ioport;
+ uart->port.membase = 0;
+ uart->port.type = PORT_16550A;
+ uart->port.flags |= (UPF_IOREMAP | UPF_FIXED_PORT | UPF_FIXED_TYPE);
+ uart->port.regshift = 2;
+
+ ret = serial8250_register_8250_port(&pci_bmc_dev->uart[idx]);
+ if (ret < 0) {
+ dev_err_probe(dev, ret, "Can't setup PCIe VUART%d\n", idx);
+ return ret;
+ }
+
+ pci_bmc_dev->uart_line[idx] = ret;
+
+ return 0;
+}
+
+static void aspeed_pci_host_bmc_device_release_vuart(struct pci_dev *pdev, int idx)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+
+ if (pci_bmc_dev->uart_line[idx] >= 0)
+ serial8250_unregister_port(pci_bmc_dev->uart_line[idx]);
+}
+
+static int aspeed_pci_host_setup(struct pci_dev *pdev)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev = pci_get_drvdata(pdev);
+ int rc = 0;
+
+ pci_bmc_dev->message_bar_base = pci_resource_start(pdev, 1);
+
+ if (pdev->revision == 0x27) {
+ pr_err("AST2700 detected but not supported");
+ return -ENODEV;
+ }
+
+ rc = aspeed_pci_bmc_device_setup_vuart(pdev, 0);
+ if (rc)
+ return rc;
+
+ rc = aspeed_pci_bmc_device_setup_vuart(pdev, 1);
+ if (rc)
+ goto out_freeVUART1;
+
+ return 0;
+
+out_freeVUART1:
+ aspeed_pci_host_bmc_device_release_vuart(pdev, 0);
+
+ return rc;
+}
+
+static int aspeed_pci_host_bmc_device_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+ struct aspeed_pci_bmc_dev *pci_bmc_dev;
+ int rc = 0;
+
+ pci_bmc_dev = devm_kzalloc(&pdev->dev, sizeof(*pci_bmc_dev), GFP_KERNEL);
+ if (!pci_bmc_dev)
+ return -ENOMEM;
+
+ rc = pci_enable_device(pdev);
+ if (rc) {
+ dev_err(&pdev->dev, "pci_enable_device() returned error %d\n", rc);
+ return rc;
+ }
+
+ pci_set_master(pdev);
+ pci_set_drvdata(pdev, pci_bmc_dev);
+
+ aspeed_pci_setup_irq_resource(pdev);
+
+ /* Setup BMC PCI device */
+ rc = aspeed_pci_host_setup(pdev);
+ if (rc) {
+ dev_err(&pdev->dev, "ASPEED PCIe Host device returned error %d\n", rc);
+ pci_free_irq_vectors(pdev);
+ pci_disable_device(pdev);
+ return rc;
+ }
+
+ return 0;
+}
+
+static void aspeed_pci_host_bmc_device_remove(struct pci_dev *pdev)
+{
+ aspeed_pci_host_bmc_device_release_vuart(pdev, 0);
+ aspeed_pci_host_bmc_device_release_vuart(pdev, 1);
+
+ pci_free_irq_vectors(pdev);
+ pci_disable_device(pdev);
+}
+
+static struct pci_device_id aspeed_host_bmc_dev_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_ASPEED, PCI_BMC_DEVICE_ID), .class = 0xFF0000, .class_mask = 0xFFFF00,
+ .driver_data = ASPEED },
+ { 0 }
+};
+
+MODULE_DEVICE_TABLE(pci, aspeed_host_bmc_dev_pci_ids);
+
+static struct pci_driver aspeed_host_bmc_dev_driver = {
+ .name = DRIVER_NAME,
+ .id_table = aspeed_host_bmc_dev_pci_ids,
+ .probe = aspeed_pci_host_bmc_device_probe,
+ .remove = aspeed_pci_host_bmc_device_remove,
+};
+
+module_driver(aspeed_host_bmc_dev_driver, pci_register_driver, pci_unregister_driver);
+
+MODULE_AUTHOR("Ryan Chen <ryan_chen@aspeedtech.com>");
+MODULE_DESCRIPTION("ASPEED Host BMC DEVICE Driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/7] serial: 8250_aspeed_vuart: add aspeed,ast2600-vuart compatible string
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
Makes the driver compatible with the ast2600-vuart.
This enables specific configuration for the AST2600.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
drivers/tty/serial/8250/8250_aspeed_vuart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/8250_aspeed_vuart.c b/drivers/tty/serial/8250/8250_aspeed_vuart.c
index 26fc0464f1cc..6afa2f4057e1 100644
--- a/drivers/tty/serial/8250/8250_aspeed_vuart.c
+++ b/drivers/tty/serial/8250/8250_aspeed_vuart.c
@@ -560,6 +560,7 @@ static void aspeed_vuart_remove(struct platform_device *pdev)
static const struct of_device_id aspeed_vuart_table[] = {
{ .compatible = "aspeed,ast2400-vuart" },
{ .compatible = "aspeed,ast2500-vuart" },
+ { .compatible = "aspeed,ast2600-vuart" },
{ },
};
MODULE_DEVICE_TABLE(of, aspeed_vuart_table);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
The ASPEED AST2600 has 2 VUART accessible over PCI.
This boolean can be set to specify if the VUART is used over PCI.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
.../devicetree/bindings/serial/8250.yaml | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 3cbd0f532e15..b03797f4674d 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -26,6 +26,14 @@ allOf:
anyOf:
- const: aspeed,ast2500-vuart
- const: aspeed,ast2600-vuart
+ - if:
+ anyOf:
+ - required:
+ - aspeed,vuart-over-pci
+ then:
+ properties:
+ compatible:
+ const: aspeed,ast2600-vuart
- if:
properties:
compatible:
@@ -312,6 +320,13 @@ properties:
polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
applicable to aspeed,ast2500-vuart and aspeed,ast2600-vuart.
+ aspeed,vuart-over-pci:
+ type: boolean
+ default: false
+ description: |
+ Enable the VUART over the BMC PCI device. Only applicable to
+ aspeed,ast2600-vuart.
+
required:
- reg
- interrupts
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/7] dt-bindings: serial: 8250: aspeed: add compatible string for ast2600
From: Grégoire Layet @ 2026-06-23 14:25 UTC (permalink / raw)
To: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt
Cc: andrew, jacky_chou, yh_chung, ninad, anirudhsriniv, linux-serial,
linux-aspeed, linux-arm-kernel, linux-kernel, Grégoire Layet
In-Reply-To: <cover.1782224059.git.gregoire.layet@9elements.com>
The ast2600 was using the ast2500 vuart compatible string.
This change makes it possible to have ast2600-specific properties.
Signed-off-by: Grégoire Layet <gregoire.layet@9elements.com>
---
.../devicetree/bindings/serial/8250.yaml | 20 +++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index bb7b9c87a807..3cbd0f532e15 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -23,7 +23,9 @@ allOf:
then:
properties:
compatible:
- const: aspeed,ast2500-vuart
+ anyOf:
+ - const: aspeed,ast2500-vuart
+ - const: aspeed,ast2600-vuart
- if:
properties:
compatible:
@@ -287,17 +289,19 @@ properties:
aspeed,sirq-polarity-sense:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
- Phandle to aspeed,ast2500-scu compatible syscon alongside register
- offset and bit number to identify how the SIRQ polarity should be
- configured. One possible data source is the LPC/eSPI mode bit. Only
- applicable to aspeed,ast2500-vuart.
+ Phandle to aspeed,ast2500-scu or aspeed,ast2600-scu compatible syscon
+ alongside register offset and bit number to identify how the SIRQ
+ polarity should be configured. One possible data source is the LPC/eSPI
+ mode bit. Only applicable to aspeed,ast2500-vuart and
+ aspeed,ast2600-vuart.
deprecated: true
aspeed,lpc-io-reg:
$ref: /schemas/types.yaml#/definitions/uint32-array
maxItems: 1
description: |
- The VUART LPC address. Only applicable to aspeed,ast2500-vuart.
+ The VUART LPC address. Only applicable to aspeed,ast2500-vuart and
+ aspeed,ast2600-vuart.
aspeed,lpc-interrupts:
$ref: /schemas/types.yaml#/definitions/uint32-array
@@ -305,8 +309,8 @@ properties:
maxItems: 2
description: |
A 2-cell property describing the VUART SIRQ number and SIRQ
- polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
- applicable to aspeed,ast2500-vuart.
+ polarity (IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). Only
+ applicable to aspeed,ast2500-vuart and aspeed,ast2600-vuart.
required:
- reg
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox