* [PATCH v2 2/2] arm64: dts: rockchip: Add HINLINK H28K
From: Chukun Pan @ 2026-06-10 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Chukun Pan, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260610100006.366963-1-amadeus@jmu.edu.cn>
The HINLINK H28K (LinkStar H28K) is a SBC with the
Rockchip RK3528 SoC. It has the following features:
- 1x USB 2.0
- 8/32GB eMMC
- 1/2/4GB LPDDR4
- MicroSD card slot
- 1x 1GbE RTL8111H Ethernet
- 1x 1GbE RTL8211F Ethernet
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3528-hinlink-h28k.dts | 318 ++++++++++++++++++
2 files changed, 319 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 761d82b4f4f2..a68d07296c9f 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-armsom-sige1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-hinlink-h28k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-nanopi-zero2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
new file mode 100644
index 000000000000..0ec50e9156eb
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3528.dtsi"
+
+/ {
+ model = "HINLINK H28K";
+ compatible = "hinlink,h28k", "rockchip,rk3528";
+
+ aliases {
+ ethernet0 = &gmac1;
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:1500000n8";
+ };
+
+ keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-boot {
+ label = "BOOT";
+ linux,code = <KEY_SETUP>;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan_led>, <&wan_led>, <&work_led>;
+
+ led-0 {
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ gpios = <&gpio4 RK_PC1 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "netdev";
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_WAN;
+ gpios = <&gpio4 RK_PC0 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "netdev";
+ };
+
+ led-2 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio4 RK_PB7 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ vdd_0v9: regulator-0v9-vdd {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc_ddr: regulator-1v1-vcc-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc_1v8: regulator-1v8-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ };
+
+ vcc_3v3: regulator-3v3-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc3v3_sd: regulator-3v3-vcc-sd {
+ compatible = "regulator-fixed";
+ gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_pwren_l>;
+ regulator-name = "vcc3v3_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3>;
+ };
+
+ vcc5v0_sys: regulator-5v0-vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vccio_sd: regulator-vccio-sd {
+ compatible = "regulator-gpio";
+ gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_vol_ctrl_h>;
+ regulator-name = "vccio_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ states = <1800000 0x0>, <3300000 0x1>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vdd_arm: regulator-vdd-arm {
+ compatible = "pwm-regulator";
+ pwms = <&pwm1 0 5000 PWM_POLARITY_INVERTED>;
+ pwm-supply = <&vcc5v0_sys>;
+ regulator-name = "vdd_arm";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <746000>;
+ regulator-max-microvolt = <1201000>;
+ regulator-settling-time-up-us = <250>;
+ };
+
+ vdd_logic: regulator-vdd-logic {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 5000 PWM_POLARITY_INVERTED>;
+ pwm-supply = <&vcc5v0_sys>;
+ regulator-name = "vdd_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <705000>;
+ regulator-max-microvolt = <1006000>;
+ regulator-settling-time-up-us = <250>;
+ };
+};
+
+&combphy {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy>;
+ phy-mode = "rgmii-id";
+ phy-supply = <&vcc_3v3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_miim>,
+ <&rgmii_tx_bus2>,
+ <&rgmii_rx_bus2>,
+ <&rgmii_rgmii_clk>,
+ <&rgmii_rgmii_bus>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_logic>;
+ status = "okay";
+};
+
+&mdio1 {
+ rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1_rstn_l>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rtl8111hs_isolateb_l>;
+ reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc_3v3>;
+ status = "okay";
+};
+
+&pinctrl {
+ gmac {
+ gmac1_rstn_l: gmac1-rstn-l {
+ rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ leds {
+ lan_led: lan-led {
+ rockchip,pins = <4 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wan_led: wan-led {
+ rockchip,pins = <4 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ work_led: work-led {
+ rockchip,pins = <4 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ rtl8111hs_isolateb_l: rtl8111hs-isolateb-l {
+ rockchip,pins = <4 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ sdmmc {
+ sdmmc_pwren_l: sdmmc-pwren-l {
+ rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm1m0_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m0_pins>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ non-removable;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ disable-wp;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0m0_xfer>;
+ status = "okay";
+};
+
+&usb2phy {
+ status = "okay";
+};
+
+&usb2phy_host {
+ phy-supply = <&vcc5v0_sys>;
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: rockchip: Add HINLINK H28K
From: Chukun Pan @ 2026-06-10 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Chukun Pan, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
The HINLINK H28K is a dual-gigabit SBC based on the RK3528 SoC.
There is a version that SeeedStudio distributes called LinkStar-H28K.
It's no different from the HINLINK H28K. The schematic can be found here:
https://www.hinlink.cn/wp-content/uploads/2024/03/20240428015024130824.pdf
https://files.seeedstudio.com/wiki/H28K/Open_source/H28K-SCH.zip
The U-Boot patch will be sent after the kernel device tree is merged.
Changes in v2:
- Add USB 2.0 support
- Remove MangoPi patches
- Improve commit messages
Chukun Pan (2):
dt-bindings: arm: rockchip: Add HINLINK H28K
arm64: dts: rockchip: Add HINLINK H28K
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3528-hinlink-h28k.dts | 318 ++++++++++++++++++
3 files changed, 324 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
--
2.34.1
^ permalink raw reply
* Re: [PATCH v1] arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU
From: Mark Rutland @ 2026-06-10 10:00 UTC (permalink / raw)
To: Shanker Donthineni
Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, linux-kernel,
linux-doc, Vikram Sethi, Jason Sequeira, Alok Mooley, Rich Wiley
In-Reply-To: <20260609234044.3945938-1-sdonthineni@nvidia.com>
On Tue, Jun 09, 2026 at 06:40:44PM -0500, Shanker Donthineni wrote:
> NVIDIA Olympus cores are affected by the TLBI completion issue tracked as
> CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses
> ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB
> sequence and ensure affected memory write effects are globally observed.
>
> Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same
> mitigation is enabled on affected Olympus systems. Also document the
> NVIDIA Olympus erratum in the arm64 silicon errata table and list it in
> the Kconfig help text.
>
> Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> ---
> Note: This patch depends on the following series as a prerequisite:
> https://lore.kernel.org/all/20260609101203.1512409-1-mark.rutland@arm.com/
FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
I'll keep note of this when backporting the other patches; as a
prerequisite we'll also need to pick commit
e185c8a0d842 ("arm64: cputype: Add NVIDIA Olympus definitions")
I have one minor comment below, but that's more for Catalin/Will, and
doesn't require a respin.
> Documentation/arch/arm64/silicon-errata.rst | 2 ++
> arch/arm64/Kconfig | 3 ++-
> arch/arm64/kernel/cpu_errata.c | 1 +
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index a01e916ede17..ad09bbb10da8 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -298,6 +298,8 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM |
> +----------------+-----------------+-----------------+-----------------------------+
> +| NVIDIA | Olympus core | T410-OLY-1029 | ARM64_ERRATUM_4118414 |
> ++----------------+-----------------+-----------------+-----------------------------+
> | NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A |
> +----------------+-----------------+-----------------+-----------------------------+
> | NVIDIA | T241 MPAM | T241-MPAM-1 | N/A |
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 48233b54c482..c65cef81be86 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1155,7 +1155,7 @@ config ARM64_ERRATUM_4193714
> If unsure, say Y.
>
> config ARM64_ERRATUM_4118414
> - bool "Cortex-*/Neoverse-*/C1-*: Completion of affected memory accesses might not be guaranteed by completion of a TLBI"
> + bool "Cortex-*/Neoverse-*/C1-*/Olympus: Completion of affected memory accesses might not be guaranteed by completion of a TLBI"
As this is getting increasingly long, maybe it's worth reducing this to
"Various" in the title, i.e.
bool "Cortex-*/Neoverse: Completion of affected memory accesses might not be guaranteed by completion of a TLBI"
... but as above, no need to respin for that.
Mark.
> default y
> select ARM64_WORKAROUND_REPEAT_TLBI
> help
> @@ -1182,6 +1182,7 @@ config ARM64_ERRATUM_4118414
> * ARM Neoverse-V2 erratum 4193787
> * ARM Neoverse-V3 erratum 4193784
> * ARM Neoverse-V3AE erratum 4193784
> + * NVIDIA Olympus erratum T410-OLY-1029
>
> On affected cores, some memory accesses might not be completed by
> broadcast TLB invalidation.
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index fe6fe5de495b..d597896b0f7f 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -364,6 +364,7 @@ static const struct arm64_cpu_capabilities arm64_repeat_tlbi_list[] = {
> MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V2),
> MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3),
> MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V3AE),
> + MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
> {}
> })),
> },
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 1/3] soc: samsung: exynos-pmu: use target cpu ID in hotplug callbacks
From: Peter Griffin @ 2026-06-10 9:55 UTC (permalink / raw)
To: Alexey Klimov
Cc: Krzysztof Kozlowski, Alim Akhtar, Sam Protsenko,
linux-samsung-soc, linux-arm-kernel, linux-kernel, stable,
Sashiko
In-Reply-To: <20260605-exynos-pmu-cpuhp-idle-fixes-v1-1-0cd05c81a82d@linaro.org>
Hi Alexey,
Thanks for your patch.
On Fri, 5 Jun 2026 at 21:19, Alexey Klimov <alexey.klimov@linaro.org> wrote:
>
> The CPU hotplug state callbacks __gs101_cpu_pmu_online() and
> __gs101_cpu_pmu_offline() currently partially use smp_processor_id() to
> determine the target register offset for the CPU inform hints. This may
> be fine for cpuidle flow but broken for cpu hotplug where the target
> cpu is passed as an argument and could be different from cpu where
> that is executing (e.g. CPU 0 offlining CPU 1), meaning that
> smp_processor_id() returns the id of local CPU but hotplug flow
> deals with another CPU core undergoing the transition.
This was intentional. The powermode hint is always programmed based on
the currently executing CPU core in the gs101 downstream code (for
both CPU Idle and CPU hotplug paths). See
https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/drivers/soc/google/cal-if/pmucal_powermode.c#15
and the pmu_intr_gen is done based on the actual CPU being
enabled/disabled.
It's possible Exynos850 requires something different. I suggest
checking the equivalent function in the e850 downstream kernel.
>
> This causes the pmu driver to write power down and power on configuration
> hints to the wrong hardware registers, messing up the power state of active
> cores and failing to configure the target core. Fix this by removing the
> cpuhint variable entirely and utilizing the target 'cpu' argument passed
> to the callbacks by the hotplug core infrastructure.
Unfortunately I think you're introducing the bug you describe with this patch.
regards,
Peter
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3
> Fixes: 598995027b91 ("soc: samsung: exynos-pmu: enable CPU hotplug support for gs101")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> drivers/soc/samsung/exynos-pmu.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c
> index d58376c38179..6e635872247a 100644
> --- a/drivers/soc/samsung/exynos-pmu.c
> +++ b/drivers/soc/samsung/exynos-pmu.c
> @@ -235,11 +235,10 @@ EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle);
> static int __gs101_cpu_pmu_online(unsigned int cpu)
> __must_hold(&pmu_context->cpupm_lock)
> {
> - unsigned int cpuhint = smp_processor_id();
> u32 reg, mask;
>
> /* clear cpu inform hint */
> - regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpuhint),
> + regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu),
> CPU_INFORM_CLEAR);
>
> mask = BIT(cpu);
> @@ -296,12 +295,10 @@ static int gs101_cpuhp_pmu_online(unsigned int cpu)
> static int __gs101_cpu_pmu_offline(unsigned int cpu)
> __must_hold(&pmu_context->cpupm_lock)
> {
> - unsigned int cpuhint = smp_processor_id();
> u32 reg, mask;
>
> /* set cpu inform hint */
> - regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpuhint),
> - CPU_INFORM_C2);
> + regmap_write(pmu_context->pmureg, GS101_CPU_INFORM(cpu), CPU_INFORM_C2);
>
> mask = BIT(cpu);
> regmap_update_bits(pmu_context->pmuintrgen, GS101_GRP2_INTR_BID_ENABLE,
>
> --
> 2.51.0
>
^ permalink raw reply
* [soc:for-next] BUILD SUCCESS de02cc4e855af652e4b5382e5d604169ca086dfa
From: kernel test robot @ 2026-06-10 9:53 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
branch HEAD: de02cc4e855af652e4b5382e5d604169ca086dfa soc: document merges
elapsed time: 795m
configs tested: 229
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260610 gcc-8.5.0
arc randconfig-002-20260610 gcc-8.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260610 gcc-8.5.0
arm randconfig-002-20260610 gcc-8.5.0
arm randconfig-003-20260610 gcc-8.5.0
arm randconfig-004-20260610 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260610 clang-23
arm64 randconfig-001-20260610 gcc-11.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260610 clang-23
arm64 randconfig-002-20260610 gcc-11.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260610 clang-23
arm64 randconfig-003-20260610 gcc-11.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260610 clang-23
arm64 randconfig-004-20260610 gcc-11.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260610 clang-23
csky randconfig-001-20260610 gcc-11.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260610 clang-23
csky randconfig-002-20260610 gcc-11.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260610 clang-22
hexagon randconfig-001-20260610 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260610 clang-22
hexagon randconfig-002-20260610 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260610 gcc-14
i386 buildonly-randconfig-002-20260610 gcc-14
i386 buildonly-randconfig-003-20260610 gcc-14
i386 buildonly-randconfig-004-20260610 gcc-14
i386 buildonly-randconfig-005-20260610 gcc-14
i386 buildonly-randconfig-006-20260610 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260610 gcc-14
i386 randconfig-002-20260610 gcc-14
i386 randconfig-003-20260610 gcc-14
i386 randconfig-004-20260610 gcc-14
i386 randconfig-005-20260610 gcc-14
i386 randconfig-006-20260610 gcc-14
i386 randconfig-007-20260610 gcc-14
i386 randconfig-011 gcc-14
i386 randconfig-011-20260610 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260610 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260610 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260610 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260610 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260610 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260610 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260610 clang-22
loongarch randconfig-001-20260610 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260610 clang-22
loongarch randconfig-002-20260610 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k apollo_defconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips lemote2f_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260610 clang-22
nios2 randconfig-001-20260610 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260610 clang-22
nios2 randconfig-002-20260610 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-23
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260610 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260610 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc microwatt_defconfig gcc-16.1.0
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260610 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260610 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260610 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260610 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260610 gcc-16.1.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260610 gcc-16.1.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260610 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260610 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-23
sh defconfig gcc-14
sh polaris_defconfig gcc-16.1.0
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260610 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260610 gcc-16.1.0
sh se7724_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260610 gcc-14.3.0
sparc randconfig-002-20260610 gcc-14.3.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260610 gcc-14.3.0
sparc64 randconfig-002-20260610 gcc-14.3.0
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260610 gcc-14.3.0
um randconfig-002-20260610 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260610 gcc-14
x86_64 buildonly-randconfig-002-20260610 gcc-14
x86_64 buildonly-randconfig-003-20260610 gcc-14
x86_64 buildonly-randconfig-004-20260610 gcc-14
x86_64 buildonly-randconfig-005-20260610 gcc-14
x86_64 buildonly-randconfig-006-20260610 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260610 gcc-13
x86_64 randconfig-002-20260610 gcc-13
x86_64 randconfig-003-20260610 gcc-13
x86_64 randconfig-004-20260610 gcc-13
x86_64 randconfig-005-20260610 gcc-13
x86_64 randconfig-006-20260610 gcc-13
x86_64 randconfig-011-20260610 gcc-14
x86_64 randconfig-012-20260610 gcc-14
x86_64 randconfig-013-20260610 gcc-14
x86_64 randconfig-014-20260610 gcc-14
x86_64 randconfig-015-20260610 gcc-14
x86_64 randconfig-016-20260610 gcc-14
x86_64 randconfig-071-20260610 gcc-14
x86_64 randconfig-072-20260610 gcc-14
x86_64 randconfig-073-20260610 gcc-14
x86_64 randconfig-074-20260610 gcc-14
x86_64 randconfig-075-20260610 gcc-14
x86_64 randconfig-076-20260610 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260610 gcc-14.3.0
xtensa randconfig-002-20260610 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [soc:soc/arm] BUILD SUCCESS c28364c9831c1996db6df5cd7e315865bd439a73
From: kernel test robot @ 2026-06-10 9:22 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/arm
branch HEAD: c28364c9831c1996db6df5cd7e315865bd439a73 Merge tag 'mvebu-arm-7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/arm
elapsed time: 765m
configs tested: 231
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260610 gcc-8.5.0
arc randconfig-002-20260610 gcc-8.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260610 gcc-8.5.0
arm randconfig-002-20260610 gcc-8.5.0
arm randconfig-003-20260610 gcc-8.5.0
arm randconfig-004-20260610 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260610 clang-23
arm64 randconfig-001-20260610 gcc-11.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260610 clang-23
arm64 randconfig-002-20260610 gcc-11.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260610 clang-23
arm64 randconfig-003-20260610 gcc-11.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260610 clang-23
arm64 randconfig-004-20260610 gcc-11.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260610 clang-23
csky randconfig-001-20260610 gcc-11.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260610 clang-23
csky randconfig-002-20260610 gcc-11.5.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260610 clang-22
hexagon randconfig-001-20260610 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260610 clang-22
hexagon randconfig-002-20260610 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260610 gcc-14
i386 buildonly-randconfig-002-20260610 gcc-14
i386 buildonly-randconfig-003-20260610 gcc-14
i386 buildonly-randconfig-004-20260610 gcc-14
i386 buildonly-randconfig-005-20260610 gcc-14
i386 buildonly-randconfig-006-20260610 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260610 gcc-14
i386 randconfig-002-20260610 gcc-14
i386 randconfig-003-20260610 gcc-14
i386 randconfig-004-20260610 gcc-14
i386 randconfig-005-20260610 gcc-14
i386 randconfig-006-20260610 gcc-14
i386 randconfig-007-20260610 gcc-14
i386 randconfig-011 gcc-14
i386 randconfig-011-20260610 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260610 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260610 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260610 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260610 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260610 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260610 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260610 clang-22
loongarch randconfig-001-20260610 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260610 clang-22
loongarch randconfig-002-20260610 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k apollo_defconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips lemote2f_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260610 clang-22
nios2 randconfig-001-20260610 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260610 clang-22
nios2 randconfig-002-20260610 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-23
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260610 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260610 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc microwatt_defconfig gcc-16.1.0
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260610 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260610 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260610 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260610 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260610 gcc-16.1.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260610 gcc-16.1.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260610 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260610 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-23
sh defconfig gcc-14
sh polaris_defconfig gcc-16.1.0
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260610 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260610 gcc-16.1.0
sh se7724_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260610 gcc-14.3.0
sparc randconfig-002-20260610 gcc-14.3.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260610 gcc-14.3.0
sparc64 randconfig-002-20260610 gcc-14.3.0
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260610 gcc-14.3.0
um randconfig-002-20260610 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260610 gcc-14
x86_64 buildonly-randconfig-002-20260610 gcc-14
x86_64 buildonly-randconfig-003-20260610 gcc-14
x86_64 buildonly-randconfig-004-20260610 gcc-14
x86_64 buildonly-randconfig-005-20260610 gcc-14
x86_64 buildonly-randconfig-006-20260610 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260610 gcc-13
x86_64 randconfig-002-20260610 gcc-13
x86_64 randconfig-003-20260610 gcc-13
x86_64 randconfig-004-20260610 gcc-13
x86_64 randconfig-005-20260610 gcc-13
x86_64 randconfig-006-20260610 gcc-13
x86_64 randconfig-011-20260610 gcc-14
x86_64 randconfig-012-20260610 gcc-14
x86_64 randconfig-013-20260610 gcc-14
x86_64 randconfig-014-20260610 gcc-14
x86_64 randconfig-015-20260610 gcc-14
x86_64 randconfig-016-20260610 gcc-14
x86_64 randconfig-071-20260610 gcc-14
x86_64 randconfig-072-20260610 gcc-14
x86_64 randconfig-073-20260610 gcc-14
x86_64 randconfig-074-20260610 gcc-14
x86_64 randconfig-075-20260610 gcc-14
x86_64 randconfig-076-20260610 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260610 gcc-14.3.0
xtensa randconfig-002-20260610 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 0/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Liu Ying @ 2026-06-10 9:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
Hi,
This patch series aims to add DY1212W-4856 [1] LVDS panel to i.MX93 11x11
EVK board.
Patch 1 allows LVDS Display Bridge (LDB) child node in i.MX93 mediamix
blk-ctrl DT binding.
Patch 2 adds LDB child node to mediamix blk-ctrl node in imx93.dtsi.
Patch 3 adds a DT overlay to support the DY1212W-4856 LVDS panel on
i.MX93 11x11 EVK board.
[1] https://www.nxp.com/design/design-center/development-boards-and-designs/dy1212w-4856-tft-lcd-panel-with-lvds-interface:DY1212W-4856
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
Changes in v3:
- Explain in patch 1's commit message that mixing addressable and
non-addressable DT child nodes is allowed. (Krzysztof)
- Link to v2: https://patch.msgid.link/20260608-imx93-ldb-v2-0-1b1fe621bfda@nxp.com
Changes in v2:
- Rebase on next-20260605.
- Disallow bridge@20 for i.MX91 in patch 1. (Sashiko bot)
- Cc Marco.
- Link to v1: https://patch.msgid.link/20260513-imx93-ldb-v1-0-d11c5c3cc197@nxp.com
---
Liu Ying (3):
dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
arm64: dts: imx93: Add LVDS Display Bridge support
arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
.../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 39 +++++++++++
arch/arm64/boot/dts/freescale/Makefile | 4 ++
.../freescale/imx93-11x11-evk-dy1212w-4856.dtso | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx93.dtsi | 37 ++++++++++
4 files changed, 161 insertions(+)
---
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
change-id: 20260513-imx93-ldb-c5a4194e41ce
Best regards,
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Vincent Donnefort @ 2026-06-10 9:26 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <20260608165549.1479409-1-sebastianene@google.com>
On Mon, Jun 08, 2026 at 04:55:42PM +0000, Sebastian Ene wrote:
> Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM
> FF-A proxy. This restriction was preventing the use of asynchronous
> signaling mechanisms defined by the Arm FF-A specification to
> communicate with the secure services.
> While these calls are markes as optional, there is no reason why the
> hypervisor proxy would block them because:
>
> 1. Host is the Sole Non-Secure Endpoint: The Host operates as the
> only Non-Secure VM ID (VM ID 0) recognized by the Secure World.
> Because all forwarded notifications are inherently attributed to
> the Host by the SPMC, there is no risk of VM ID spoofing
> originating from the Normal World.
>
> 2. No Memory Pointers or Addresses: The FFA_NOTIFICATION_* ABIs
> operate strictly via register-based parameters, passing only
> VM IDs, VCPU IDs, flags, and bitmaps. Because these calls do
> not contain memory addresses, offsets, or pointers, forwarding
> them doesn't pose a risk of memory-based confused deputy attack
> (e.g., tricking the SPMC into overwriting protected memory).
>
> While the pKVM proxy behaves as a relayer, it doesn't currently have its
> own FF-A ID(only the host has the ID 0). The behavior of the setup
> flow is covered by the spec in the: '10.9 Notification support without
> a Hypervisor'.
As it is only a relayer. Is it really important to check SBZ arguments and
fields on behalf of Trustzone? It doesn't feel it brings any security. If the
host passes broken arguments, I don't believe this puts pKVM at risk. Does it?
>
> ---
> Changes in v2:
> - enforce the MBZ/SBZ fields
> - split the calls into separate patches
> - rebase on 7.1-rc7
>
> Link to v1:
> https://lore.kernel.org/all/20260501114447.2389222-2-sebastianene@google.com/
>
> Sebastian Ene (7):
> KVM: arm64: Support FFA_NOTIFICATION_BITMAP_CREATE in host handler
> KVM: arm64: Support FFA_NOTIFICATION_BITMAP_DESTROY in host handler
> KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
> KVM: arm64: Support FFA_NOTIFICATION_UNBIND in host handler
> KVM: arm64: Support FFA_NOTIFICATION_SET in host handler
> KVM: arm64: Support FFA_NOTIFICATION_GET in host handler
> KVM: arm64: Support FFA_NOTIFICATION_INFO_GET in host handler
>
> arch/arm64/kvm/hyp/nvhe/ffa.c | 190 ++++++++++++++++++++++++++++++++--
> 1 file changed, 182 insertions(+), 8 deletions(-)
>
> --
> 2.54.0.1064.gd145956f57-goog
>
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Liu Ying @ 2026-06-10 9:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
In-Reply-To: <20260610-imx93-ldb-v3-0-c9b65d742753@nxp.com>
DY1212W-4856 [1] is a 12.1" (WXGA) TFT LCD panel with LVDS interface.
The panel's 40-pin connector allows it to be directly connected to
i.MX93 11x11 EVK board.
Link: https://www.nxp.com/design/design-center/development-boards-and-designs/dy1212w-4856-tft-lcd-panel-with-lvds-interface:DY1212W-4856 [1]
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 4 ++
.../freescale/imx93-11x11-evk-dy1212w-4856.dtso | 81 ++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8ddaab127ab9..dbe27d757c86 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -588,6 +588,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-tianma-tm050rdh03.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
+
+imx93-11x11-evk-dy1212w-4856-dtbs += imx93-11x11-evk.dtb imx93-11x11-evk-dy1212w-4856.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk-dy1212w-4856.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
imx93-11x11-frdm-pixpaper-dtbs += imx93-11x11-frdm.dtb imx93-11x11-frdm-pixpaper.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
new file mode 100644
index 000000000000..35f7c5699e3a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/imx93-clock.h>
+
+&{/} {
+ panel-lvds {
+ compatible = "boe,ev121wxm-n10-1850";
+ backlight = <&backlight_lvds>;
+ power-supply = <&buck4>;
+
+ panel-timing {
+ /*
+ * Set clock frequency to 71142858Hz to accommodate
+ * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate
+ * table.
+ */
+ clock-frequency = <71142858>;
+ hactive = <1280>;
+ vactive = <800>;
+ hfront-porch = <48>;
+ hback-porch = <80>;
+ hsync-len = <32>;
+ vfront-porch = <3>;
+ vback-porch = <14>;
+ vsync-len = <6>;
+ };
+
+ port {
+ panel_lvds_in: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+ };
+};
+
+&backlight_lvds {
+ status = "okay";
+};
+
+&lcdif {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&panel_lvds_in>;
+ };
+ };
+ };
+};
+
+&media_blk_ctrl {
+ assigned-clocks = <&clk IMX93_CLK_MEDIA_AXI>,
+ <&clk IMX93_CLK_MEDIA_APB>,
+ <&clk IMX93_CLK_MEDIA_DISP_PIX>,
+ <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1>,
+ <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>,
+ <&clk IMX93_CLK_VIDEO_PLL>;
+ /*
+ * Set IMX93_CLK_MEDIA_DISP_PIX rate to 71142858Hz to accommodate
+ * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate table.
+ */
+ assigned-clock-rates = <400000000>, <133333333>, <71142858>, <498000000>;
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] KVM: arm64: Replace memslot_is_logging() with kvm_slot_dirty_track_enabled()
From: Alexandru Elisei @ 2026-06-10 9:48 UTC (permalink / raw)
To: Leonardo Bras
Cc: Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Gavin Shan
In-Reply-To: <aig_xcTZKzux0OaS@devkitleo>
Hi Leo,
Just FYI, write faults on read-only memslots are handled as MMIO accesses in
kvm_handle_guest_abort() (gfn_to_hva_memslot_prot() sets @writable to false).
Thanks,
Alex
On Tue, Jun 09, 2026 at 05:31:01PM +0100, Leonardo Bras wrote:
> On Mon, Jun 08, 2026 at 04:55:45PM +0100, Leonardo Bras wrote:
> > Hi Wei Lin,
> >
> > On Fri, Jun 05, 2026 at 04:32:47PM +0100, Wei-Lin Chang wrote:
> > > When checking whether a memslot has dirty logging enabled, the
> > > KVM_MEM_LOG_DIRTY_PAGES flag is the source of truth. Previously we were
> > > using memslot_is_logging() which only tests dirty bitmap and did not
> > > consider dirty ring. This was not detected because
> > > KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP was introduced together with KVM
> > > arm64 dirty ring, and users need to enable it to ensure dirty
> > > information is not lost for the case of VGIC LPI/ITS table changes.
> > >
> > > Fix this by using kvm_slot_dirty_track_enabled() instead which checks
> > > KVM_MEM_LOG_DIRTY_PAGES.
> > >
> > > Note that memslot_is_logging() also treats a memslot as not logging if
> > > KVM_MEM_READONLY is set, hence a memslot with both dirty logging and
> > > read only would be seen as not logging for memslot_is_logging(), but
> > > logging for kvm_slot_dirty_track_enabled(). This allows a read only
> > > mapping of size > PAGE_SIZE to be built when memslot_is_logging() is
> > > used, leading to a better read performance compared to
> > > kvm_slot_dirty_track_enabled(). However memslots that have both
> > > KVM_MEM_LOG_DIRTY_PAGES and KVM_MEM_READONLY set do not really make
> > > sense as dirty logging is essentially nop for a read only memslot, so
> > > this shouldn't affect real workloads much.
> >
> >
> > It worries me a bit that we are ignoring the KVM_MEM_READONLY flag...
> > I have not yet gone through the whole s2_mmu code but IIUC we can have
> > scenarios on which a memslot can be read-only and have dirty-logging
> > enabled.
>
>
> > If a memslot is not faulted yet, IIUC it is marked as read-only
> > (so it can be mapped on write fault), and we can have dirty-logging
> > enabled for it as well (as the VMM has no idea).
> >
>
> Ignore above bit, I confused memslot with block/page entry.
>
> Looking a bit more, my viewpoint is that:
> - Due to dirty_ring, checking memslot.dirty_bitmap should be done only to
> detect the existence of a dirty_bitmap, not the migration process.
> - This changes how detection works, in regardas to read-only blocks:
> memslot_is_logging() -> Checks dirty-bitmap + read-only memslot
> kvm_slot_dirty_track_enabled() -> Checks only memslot flag
> - As a simpler change, we could have:
>
> ~~~
> - return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
> + return kvm_slot_dirty_track_enabled(memslot) && !(memslot->flags & KVM_MEM_READONLY);
> ~~~
>
> Both are cheking memslot->flags, so it will be probably optimized by the
> compiler as:
>
> ~~~
> return memslot->flags & 3 == 1
> ~~~
>
> My main worry was that in the curent patch we are changing the behavior
> on skipping read-only memslots. So going through the users, we can see:
>
> > >
> > > Fixes: 9cb1096f8590 ("KVM: arm64: Enable ring-based dirty memory tracking")
> > > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > > ---
> > > It took me a long investigation to acquire the context needed to
> > > understand this change, however the reason for this problem not being
> > > detected is an educated guess. Please let me know if this is wrong or
> > > if there are other issues, thanks!
> > >
> > > arch/arm64/kvm/mmu.c | 11 +++--------
> > > 1 file changed, 3 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index 4da9281312eb..06c46124d3e7 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > > @@ -161,11 +161,6 @@ static int kvm_mmu_split_huge_pages(struct kvm *kvm, phys_addr_t addr,
> > > return ret;
> > > }
> > >
> > > -static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> > > -{
> > > - return memslot->dirty_bitmap && !(memslot->flags & KVM_MEM_READONLY);
> > > -}
> > > -
> > > /**
> > > * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8
> > > * @kvm: pointer to kvm structure.
> > > @@ -1748,7 +1743,7 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
> > > {
> > > short vma_shift;
> > >
> > > - if (memslot_is_logging(s2fd->memslot)) {
> > > + if (kvm_slot_dirty_track_enabled(s2fd->memslot)) {
> > > s2vi->max_map_size = PAGE_SIZE;
> > > vma_shift = PAGE_SHIFT;
> > > } else {
>
> On the case dirty_track is enabled in a read-only slot, it will resolve to
> a smaller vma_size. The fault granule will be smaller here. This could be
> bad for performance, so maybe we could add a check for read-only block
> here:
>
> ~~~
> - if (memslot_is_logging(s2fd->memslot)) {
> + if (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
> + !memslot_is_readonly(s2fd->memslot) {
> ~~~
>
>
> > > @@ -1953,7 +1948,7 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
> > > *prot = KVM_PGTABLE_PROT_R;
> > >
> > > if (s2vi->map_writable && (s2vi->device ||
> > > - !memslot_is_logging(s2fd->memslot) ||
> > > + !kvm_slot_dirty_track_enabled(s2fd->memslot) ||
> > > kvm_is_write_fault(s2fd->vcpu)))
> > > *prot |= KVM_PGTABLE_PROT_W;
> > >
>
>
> On the same scenario (dirty_track enabled on readonly memslot):
> This one should be safe, as kvm_is_write_fault() will check if the memslot
> is readonly and return false in this case. But then, it will have to
> actually call kvm_is_write_fault(), as the previous version would not even
> call it in that scenario.
>
> Not sure how would that impact perforformance, though.
>
> > > @@ -2084,7 +2079,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
> > > * and a write fault needs to collapse a block entry into a table.
> > > */
> > > memcache = get_mmu_memcache(s2fd->vcpu);
> > > - if (!perm_fault || (memslot_is_logging(s2fd->memslot) &&
> > > + if (!perm_fault || (kvm_slot_dirty_track_enabled(s2fd->memslot) &&
> > > kvm_is_write_fault(s2fd->vcpu))) {
> > > ret = topup_mmu_memcache(s2fd->vcpu, memcache);
> > > if (ret)
>
> Same thing, if memslot is tracking and is readonly, topup_*() would be
> called with the new patch, but not with the old behavior.
>
> All of that depends on how the VMM uses dirty_tracking: does it enable for
> all memory, or only for memory that is writable?
>
> I could not find anything that would prevent user from enabling
> dirty_tracking on read-only memslots, so we can either ignore this
> scenario, apply those patches and let those users carry the extra overhead,
> or do an extra test to make sure it's doing the same thing as before.
>
> Thanks!
> Leo
>
^ permalink raw reply
* Re: [PATCH] ARM: imx: avic: fix device_node refcount leaks in mxc_init_irq()
From: Martin Kaiser @ 2026-06-10 9:42 UTC (permalink / raw)
To: Weigang He
Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260610053115.2263570-1-geoffreyhe2@gmail.com>
Hi,
Thus wrote Weigang He (geoffreyhe2@gmail.com):
> mxc_init_irq() obtains two device_node references via
> of_find_compatible_node() and never releases either one:
> - The "fsl,imx25-ccm" node (looked up to map the CCM low-power
> interrupt mask registers on i.MX25) is stored in np, used by
> of_iomap(), and then the same np variable is overwritten by the
> second of_find_compatible_node() call without an of_node_put().
> On i.MX25 this leaks the node reference on every boot.
> - The "fsl,avic" node is passed via of_fwnode_handle(np) to
> irq_domain_create_legacy(), which takes its own reference on the
> fwnode through fwnode_handle_get(), so the caller's reference is
> not transferred. np is then leaked at function return.
> Both lookups predate the switch to irq_domain_create_*(); the missing
> puts have been there since the code was introduced.
> Drop each reference once the value derived from it is no longer needed:
> after of_iomap() has mapped the CCM registers, and after
> irq_domain_create_legacy() has taken its own fwnode reference.
> of_node_put() is NULL-safe, so platforms without these nodes are
> unaffected.
> Found by static analysis tool CodeQL.
> Fixes: 544496ab5cbd ("ARM: imx: move irq_domain_add_legacy call into avic driver")
> Fixes: 9b454d16e57d ("ARM: imx: avic: set low-power interrupt mask for imx25")
> Signed-off-by: Weigang He <geoffreyhe2@gmail.com>
> ---
> arch/arm/mach-imx/avic.c | 2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/arch/arm/mach-imx/avic.c b/arch/arm/mach-imx/avic.c
> index 3067c06b4b8eb..6873a50bbe2c0 100644
> --- a/arch/arm/mach-imx/avic.c
> +++ b/arch/arm/mach-imx/avic.c
> @@ -173,6 +173,7 @@ static void __init mxc_init_irq(void __iomem *irqbase)
> np = of_find_compatible_node(NULL, NULL, "fsl,imx25-ccm");
> mx25_ccm_base = of_iomap(np, 0);
> + of_node_put(np);
> if (mx25_ccm_base) {
> /*
> @@ -203,6 +204,7 @@ static void __init mxc_init_irq(void __iomem *irqbase)
> np = of_find_compatible_node(NULL, NULL, "fsl,avic");
> domain = irq_domain_create_legacy(of_fwnode_handle(np), AVIC_NUM_IRQS, irq_base, 0,
> &irq_domain_simple_ops, NULL);
> + of_node_put(np);
> WARN_ON(!domain);
> for (i = 0; i < AVIC_NUM_IRQS / 32; i++, irq_base += 32)
> base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
> --
> 2.43.0
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Thanks,
Martin
^ permalink raw reply
* [soc:soc/dt] BUILD SUCCESS 2a185da3ed581e2f6e7a7417106eb32d063a12b5
From: kernel test robot @ 2026-06-10 9:39 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/dt
branch HEAD: 2a185da3ed581e2f6e7a7417106eb32d063a12b5 Merge tag 'microchip-dt64-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt
elapsed time: 781m
configs tested: 240
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allmodconfig gcc-16.1.0
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260610 gcc-8.5.0
arc randconfig-002-20260610 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm randconfig-001-20260610 gcc-8.5.0
arm randconfig-002-20260610 gcc-8.5.0
arm randconfig-003-20260610 gcc-8.5.0
arm randconfig-004-20260610 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260610 clang-23
arm64 randconfig-001-20260610 gcc-11.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260610 clang-23
arm64 randconfig-002-20260610 gcc-11.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260610 clang-23
arm64 randconfig-003-20260610 gcc-11.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260610 clang-23
arm64 randconfig-004-20260610 gcc-11.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260610 clang-23
csky randconfig-001-20260610 gcc-11.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260610 clang-23
csky randconfig-002-20260610 gcc-11.5.0
hexagon allmodconfig clang-23
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260610 clang-22
hexagon randconfig-001-20260610 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260610 clang-22
hexagon randconfig-002-20260610 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-14
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260610 gcc-14
i386 buildonly-randconfig-002-20260610 gcc-14
i386 buildonly-randconfig-003-20260610 gcc-14
i386 buildonly-randconfig-004-20260610 gcc-14
i386 buildonly-randconfig-005-20260610 gcc-14
i386 buildonly-randconfig-006-20260610 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260610 gcc-14
i386 randconfig-002-20260610 gcc-14
i386 randconfig-003-20260610 gcc-14
i386 randconfig-004-20260610 gcc-14
i386 randconfig-005-20260610 gcc-14
i386 randconfig-006-20260610 gcc-14
i386 randconfig-007-20260610 gcc-14
i386 randconfig-011 gcc-14
i386 randconfig-011-20260610 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260610 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260610 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260610 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260610 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260610 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260610 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-20
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260610 clang-22
loongarch randconfig-001-20260610 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260610 clang-22
loongarch randconfig-002-20260610 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k allyesconfig gcc-16.1.0
m68k apollo_defconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips lemote2f_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260610 clang-22
nios2 randconfig-001-20260610 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260610 clang-22
nios2 randconfig-002-20260610 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allmodconfig gcc-16.1.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-16.1.0
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-16.1.0
parisc allyesconfig clang-23
parisc allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260610 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260610 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-16.1.0
powerpc microwatt_defconfig gcc-16.1.0
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260610 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260610 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260610 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260610 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-16.1.0
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260610 gcc-16.1.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260610 gcc-16.1.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260610 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260610 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allnoconfig gcc-16.1.0
sh allyesconfig clang-23
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh polaris_defconfig gcc-16.1.0
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260610 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260610 gcc-16.1.0
sh se7724_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-16.1.0
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260610 gcc-14.3.0
sparc randconfig-002-20260610 gcc-14.3.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260610 gcc-14.3.0
sparc64 randconfig-002-20260610 gcc-14.3.0
um allmodconfig clang-23
um allnoconfig clang-16
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260610 gcc-14.3.0
um randconfig-002-20260610 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260610 gcc-14
x86_64 buildonly-randconfig-002-20260610 gcc-14
x86_64 buildonly-randconfig-003-20260610 gcc-14
x86_64 buildonly-randconfig-004-20260610 gcc-14
x86_64 buildonly-randconfig-005-20260610 gcc-14
x86_64 buildonly-randconfig-006-20260610 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260610 gcc-13
x86_64 randconfig-002-20260610 gcc-13
x86_64 randconfig-003-20260610 gcc-13
x86_64 randconfig-004-20260610 gcc-13
x86_64 randconfig-005-20260610 gcc-13
x86_64 randconfig-006-20260610 gcc-13
x86_64 randconfig-011-20260610 gcc-14
x86_64 randconfig-012-20260610 gcc-14
x86_64 randconfig-013-20260610 gcc-14
x86_64 randconfig-014-20260610 gcc-14
x86_64 randconfig-015-20260610 gcc-14
x86_64 randconfig-016-20260610 gcc-14
x86_64 randconfig-071-20260610 gcc-14
x86_64 randconfig-072-20260610 gcc-14
x86_64 randconfig-073-20260610 gcc-14
x86_64 randconfig-074-20260610 gcc-14
x86_64 randconfig-075-20260610 gcc-14
x86_64 randconfig-076-20260610 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-16.1.0
xtensa allyesconfig clang-20
xtensa randconfig-001-20260610 gcc-14.3.0
xtensa randconfig-002-20260610 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 2/3] arm64: dts: imx93: Add LVDS Display Bridge support
From: Liu Ying @ 2026-06-10 9:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
In-Reply-To: <20260610-imx93-ldb-v3-0-c9b65d742753@nxp.com>
Add LVDS Display Bridge(LDB) child node to mediamix blk-ctrl node
so that video could be output through a LVDS interface.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx93.dtsi | 37 ++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index b9abe143cb56..79fb4a15b733 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -178,6 +178,7 @@ &lcdif {
port {
lcdif_to_ldb: endpoint@1 {
reg = <1>;
+ remote-endpoint = <&ldb_from_lcdif>;
};
lcdif_to_dsi: endpoint@2 {
@@ -186,6 +187,42 @@ lcdif_to_dsi: endpoint@2 {
};
};
+&media_blk_ctrl {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ lvds_bridge: bridge@20 {
+ compatible = "fsl,imx93-ldb";
+ reg = <0x20 0x4>, <0x24 0x4>;
+ reg-names = "ldb", "lvds";
+ clocks = <&clk IMX93_CLK_LVDS_GATE>;
+ clock-names = "ldb";
+ assigned-clocks = <&clk IMX93_CLK_MEDIA_LDB>;
+ assigned-clock-parents = <&clk IMX93_CLK_VIDEO_PLL>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ ldb_from_lcdif: endpoint {
+ remote-endpoint = <&lcdif_to_ldb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ };
+ };
+ };
+ };
+};
+
&src {
mlmix: power-domain@44461800 {
compatible = "fsl,imx93-src-slice";
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
From: Liu Ying @ 2026-06-10 9:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
In-Reply-To: <20260610-imx93-ldb-v3-0-c9b65d742753@nxp.com>
i.MX93 SoC mediamix blk-ctrl contains one LDB_CTRL register and one LVDS
register which control video output through a LVDS interface. Allow the
LVDS Display Bridge(LDB) child node and add the child node to example.
i.MX93 LDB child node(bridge@20) is an addressable node, while i.MX93
Parallel Display Format Configuration(PDFC) child node(dpi-bridge) is a
non-addressable node. Mixing the addressable and non-addressable child
nodes is allowed according to discussion [1].
Link: https://lore.kernel.org/all/n6akxiayi3g6gxcqhreb4iaohmeokoalnqup6h5r2fwdt4zijt@u2wyps55ayqm/ [1]
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
.../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
index d828c2e82965..124f5c206ee3 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
@@ -26,6 +26,12 @@ properties:
reg:
maxItems: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
'#power-domain-cells':
const: 1
@@ -92,6 +98,11 @@ properties:
- compatible
- ports
+ bridge@20:
+ type: object
+ $ref: /schemas/display/bridge/fsl,ldb.yaml#
+ unevaluatedProperties: false
+
allOf:
- if:
properties:
@@ -112,6 +123,7 @@ allOf:
- const: lcdif
- const: isi
- const: csi
+ bridge@20: false
- if:
properties:
compatible:
@@ -163,6 +175,8 @@ examples:
<&clk IMX93_CLK_MIPI_DSI_GATE>;
clock-names = "apb", "axi", "nic", "disp", "cam",
"pxp", "lcdif", "isi", "csi", "dsi";
+ #address-cells = <1>;
+ #size-cells = <1>;
#power-domain-cells = <1>;
dpi-bridge {
@@ -190,4 +204,29 @@ examples:
};
};
};
+
+ bridge@20 {
+ compatible = "fsl,imx93-ldb";
+ reg = <0x20 0x4>, <0x24 0x4>;
+ reg-names = "ldb", "lvds";
+ clocks = <&clk IMX93_CLK_LVDS_GATE>;
+ clock-names = "ldb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&lcdif_to_ldb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+ };
+ };
};
--
2.43.0
^ permalink raw reply related
* [soc:soc/defconfig] BUILD SUCCESS 512cef2af615cf0a4c9b0529a2aa36390240ecb7
From: kernel test robot @ 2026-06-10 9:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git soc/defconfig
branch HEAD: 512cef2af615cf0a4c9b0529a2aa36390240ecb7 arm64: configs: Update defconfig for AST2700 platform support
elapsed time: 762m
configs tested: 216
configs skipped: 144
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260610 gcc-8.5.0
arc randconfig-002-20260610 gcc-8.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm allyesconfig gcc-16.1.0
arm defconfig gcc-16.1.0
arm randconfig-001-20260610 gcc-8.5.0
arm randconfig-002-20260610 gcc-8.5.0
arm randconfig-003-20260610 gcc-8.5.0
arm randconfig-004-20260610 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001 clang-23
arm64 randconfig-001-20260610 clang-23
arm64 randconfig-001-20260610 gcc-11.5.0
arm64 randconfig-002 clang-23
arm64 randconfig-002-20260610 clang-23
arm64 randconfig-002-20260610 gcc-11.5.0
arm64 randconfig-003 clang-23
arm64 randconfig-003-20260610 clang-23
arm64 randconfig-003-20260610 gcc-11.5.0
arm64 randconfig-004 clang-23
arm64 randconfig-004-20260610 clang-23
arm64 randconfig-004-20260610 gcc-11.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001 clang-23
csky randconfig-001-20260610 clang-23
csky randconfig-001-20260610 gcc-11.5.0
csky randconfig-002 clang-23
csky randconfig-002-20260610 clang-23
csky randconfig-002-20260610 gcc-11.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260610 clang-22
hexagon randconfig-001-20260610 gcc-11.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260610 clang-22
hexagon randconfig-002-20260610 gcc-11.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260610 gcc-14
i386 buildonly-randconfig-002-20260610 gcc-14
i386 buildonly-randconfig-003-20260610 gcc-14
i386 buildonly-randconfig-004-20260610 gcc-14
i386 buildonly-randconfig-005-20260610 gcc-14
i386 buildonly-randconfig-006-20260610 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260610 gcc-14
i386 randconfig-002-20260610 gcc-14
i386 randconfig-003-20260610 gcc-14
i386 randconfig-004-20260610 gcc-14
i386 randconfig-005-20260610 gcc-14
i386 randconfig-006-20260610 gcc-14
i386 randconfig-007-20260610 gcc-14
i386 randconfig-011 gcc-14
i386 randconfig-011-20260610 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260610 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260610 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260610 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260610 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260610 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260610 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260610 clang-22
loongarch randconfig-001-20260610 gcc-11.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260610 clang-22
loongarch randconfig-002-20260610 gcc-11.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k apollo_defconfig gcc-16.1.0
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
mips lemote2f_defconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001 gcc-11.5.0
nios2 randconfig-001-20260610 clang-22
nios2 randconfig-001-20260610 gcc-11.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260610 clang-22
nios2 randconfig-002-20260610 gcc-11.5.0
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-23
parisc defconfig gcc-16.1.0
parisc randconfig-001 gcc-8.5.0
parisc randconfig-001-20260610 gcc-8.5.0
parisc randconfig-002 gcc-8.5.0
parisc randconfig-002-20260610 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc microwatt_defconfig gcc-16.1.0
powerpc randconfig-001 gcc-8.5.0
powerpc randconfig-001-20260610 gcc-8.5.0
powerpc randconfig-002 gcc-8.5.0
powerpc randconfig-002-20260610 gcc-8.5.0
powerpc64 randconfig-001 gcc-8.5.0
powerpc64 randconfig-001-20260610 gcc-8.5.0
powerpc64 randconfig-002 gcc-8.5.0
powerpc64 randconfig-002-20260610 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260610 gcc-16.1.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260610 gcc-16.1.0
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260610 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260610 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-23
sh defconfig gcc-14
sh polaris_defconfig gcc-16.1.0
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260610 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260610 gcc-16.1.0
sh se7724_defconfig gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260610 gcc-14.3.0
sparc randconfig-002-20260610 gcc-14.3.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260610 gcc-14.3.0
sparc64 randconfig-002-20260610 gcc-14.3.0
um allmodconfig clang-23
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260610 gcc-14.3.0
um randconfig-002-20260610 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260610 gcc-14
x86_64 buildonly-randconfig-002-20260610 gcc-14
x86_64 buildonly-randconfig-003-20260610 gcc-14
x86_64 buildonly-randconfig-004-20260610 gcc-14
x86_64 buildonly-randconfig-005-20260610 gcc-14
x86_64 buildonly-randconfig-006-20260610 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260610 gcc-13
x86_64 randconfig-002-20260610 gcc-13
x86_64 randconfig-003-20260610 gcc-13
x86_64 randconfig-004-20260610 gcc-13
x86_64 randconfig-005-20260610 gcc-13
x86_64 randconfig-006-20260610 gcc-13
x86_64 randconfig-011-20260610 gcc-14
x86_64 randconfig-012-20260610 gcc-14
x86_64 randconfig-013-20260610 gcc-14
x86_64 randconfig-014-20260610 gcc-14
x86_64 randconfig-015-20260610 gcc-14
x86_64 randconfig-016-20260610 gcc-14
x86_64 randconfig-071-20260610 gcc-14
x86_64 randconfig-072-20260610 gcc-14
x86_64 randconfig-073-20260610 gcc-14
x86_64 randconfig-074-20260610 gcc-14
x86_64 randconfig-075-20260610 gcc-14
x86_64 randconfig-076-20260610 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001-20260610 gcc-14.3.0
xtensa randconfig-002-20260610 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 0/2] Cleanup and fix for NanoPC-T6 Plus
From: Diederik de Haas @ 2026-06-10 9:18 UTC (permalink / raw)
To: Diederik de Haas, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Jonas Karlman, Marcin Juszkiewicz
In-Reply-To: <20260610081400.758687-1-diederik@cknow-tech.com>
On Wed Jun 10, 2026 at 10:14 AM CEST, Diederik de Haas wrote:
> Several nodes were enabled/configured when support for the NanoPC-T6 Plus was
s/Plus/LTS/ in Subject and here ...
Still working on a submission for the NanoPC-T6 Plus ;-)
Cheers,
Diederik
> added, but later those same nodes got enabled/configured in the dtsi file,
> making those in the dts file superfluous, so remove them.
>
> The MTT USB 2.0 Hub is connected to USB20 HOST1, so the phy-supply belongs to
> u2phy3_host, not u2phy2_host as that is for USB20 HOST0.
>
> Diederik de Haas (2):
> arm64: dts: rockchip: Drop duplicate USB nodes on NanoPC-T6 LTS
> arm64: dts: rockchip: Fix USB hub phy-supply config for NanoPC-T6 LTS
>
> .../dts/rockchip/rk3588-nanopc-t6-lts.dts | 19 +------------------
> 1 file changed, 1 insertion(+), 18 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Krzysztof Kozlowski @ 2026-06-10 9:14 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <2fc48536-5af9-419e-b4df-746b678cb6ab@gmail.com>
On 10/06/2026 11:10, Laurentiu Mihalcea wrote:
>
>
> On 6/10/2026 12:37 AM, Krzysztof Kozlowski wrote:
>> On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
>>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>>
>>> The names of the carveout regions are derived using the names of the
>>> reserved memory devicetree nodes, which are referenced using the
>>> "memory-region" property. This adds a restriction on the names of said
>>> devicetree nodes, often bearing specific names such as: "vdevbuffer",
>>> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
>>> specification's recommendation, which states that the devicetree node
>>> names should be generic.
>>
>> No, it does not. Names like rsc-table feels exactly like DT spec is
>> asking - for a name matching purpose. Are you sure you read the spec?
>
> Quoting from the spec:
>
> "The name of a node should be somewhat generic, reflecting the function of the
> device and not its precise programming model"
And read the rest of the spec, please.
>
> and looking at the examples provided in "2.2.2 Generic Names Recommendation",
> wouldn't "memory" be a more appropriate choice for the DT node name instead of
> "rsc-table" since it's more generic, while still matching the purpose
> of the device? Or perhaps I'm interpreting this the wrong way?
You just took one piece skipping the rest. Also binding in the dtschema
repeats that.
>
>>
>>>
>>> Fix this by documenting an additional, optional property:
>>> "memory-region-names". This way, the carveout names can use the values
>>> passed via "memory-region-names", while keeping the devicetree node
>>> names of the reserved memory regions generic.
>>
>> I don't see how anything here is fixed. memory-region-names has nothing
>> to do with node names.
>
> The idea here is that the names of the carveout regions can now be passed
> via the "memory-region-names" property. Previously, we were using the DT
> node names for that.
memory-region phandles give you that, not names. You need to state why
this is not sufficient.
>
> Thus, we can now use the more generic "memory" name for the DT nodes since we
> no longer use them for the carveout names.
That's wrong reason for doing this change. Also random names here change
nothing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Laurentiu Mihalcea @ 2026-06-10 9:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer, Peng Fan,
Fabio Estevam, Daniel Baluta, Francesco Dolcini, linux-remoteproc,
devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260610-adventurous-granite-marmoset-e0eaa8@quoll>
On 6/10/2026 12:37 AM, Krzysztof Kozlowski wrote:
> On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
>> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>>
>> The names of the carveout regions are derived using the names of the
>> reserved memory devicetree nodes, which are referenced using the
>> "memory-region" property. This adds a restriction on the names of said
>> devicetree nodes, often bearing specific names such as: "vdevbuffer",
>> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
>> specification's recommendation, which states that the devicetree node
>> names should be generic.
>
> No, it does not. Names like rsc-table feels exactly like DT spec is
> asking - for a name matching purpose. Are you sure you read the spec?
Quoting from the spec:
"The name of a node should be somewhat generic, reflecting the function of the
device and not its precise programming model"
and looking at the examples provided in "2.2.2 Generic Names Recommendation",
wouldn't "memory" be a more appropriate choice for the DT node name instead of
"rsc-table" since it's more generic, while still matching the purpose
of the device? Or perhaps I'm interpreting this the wrong way?
>
>>
>> Fix this by documenting an additional, optional property:
>> "memory-region-names". This way, the carveout names can use the values
>> passed via "memory-region-names", while keeping the devicetree node
>> names of the reserved memory regions generic.
>
> I don't see how anything here is fixed. memory-region-names has nothing
> to do with node names.
The idea here is that the names of the carveout regions can now be passed
via the "memory-region-names" property. Previously, we were using the DT
node names for that.
Thus, we can now use the more generic "memory" name for the DT nodes since we
no longer use them for the carveout names.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: defconfig: Switch Qualcomm SDM845, SM8150 and SM8250 drivers to modules
From: Konrad Dybcio @ 2026-06-10 9:07 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel
In-Reply-To: <20260609-clk-qcom-defaults-v2-7-0c67c06dca11@oss.qualcomm.com>
On 6/9/26 5:32 PM, Krzysztof Kozlowski wrote:
> Display, GPU and video clock controllers on Qualcomm SDM845, SM8150 and
> SM8250 SoCs should not be built-in because they are not necessary for
> platform bring-up to shell or even mounting rootfs. Drop their explicit
> selection in defconfig, relying on defaults which makes them modules.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 5/7] clk: qcom: Add defaults for desired arm64 drivers
From: Konrad Dybcio @ 2026-06-10 9:07 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel
In-Reply-To: <20260609-clk-qcom-defaults-v2-5-0c67c06dca11@oss.qualcomm.com>
On 6/9/26 5:32 PM, Krzysztof Kozlowski wrote:
> Clock controller drivers are essential for booting up SoCs and are not
> really optional for a given platform. Kernel should not ask users
> choice of drivers when that choice is obvious and known to the
> developers that answer should be 'yes' or 'module'.
>
> Enable drivers for upstreamed or being upstreamed SoCs, which are not
> yed enabled in defconfig: Glymur, Hawi, Nord, MSM8976, MSM8998 (GPU CC),
> SC7180, SC8180X, SC8280XP, SC7280, SDM660, QDU1000, SM4450, SM7150,
> SM8150, SM8450, SM6125, SM6375. Note that main GCC clock controller
> drivers are usually already enabled for these.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v2:
> 1. Add defaults for: MSM_GCC_8976, MSM_GPUCC_8998, SDM_GCC_660,
> SDM_MMCC_660, SDM_GPUCC_660, HAWI
>
> 2. Drop the Konrad RB tag, considering above a significant change.
> ---
[...]
> tristate "SDM660 Global Clock Controller"
> depends on ARM64 || COMPILE_TEST
> select QCOM_GDSC
> + default m if ARCH_QCOM
Drop the 'm'
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/7] clk: qcom: Make important ARM64 drivers default
From: Konrad Dybcio @ 2026-06-10 9:04 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel
In-Reply-To: <20260609-clk-qcom-defaults-v2-3-0c67c06dca11@oss.qualcomm.com>
On 6/9/26 5:32 PM, Krzysztof Kozlowski wrote:
> Clock controller drivers are essential for booting up SoCs and are not
> really optional for a given platform. Kernel should not ask users
> choice of drivers when that choice is obvious and known to the
> developers that answer should be 'yes' or 'module'.
>
> Switch all Qualcomm clock controller drivers which are chosen in
> defconfig to respective default 'yes' or 'module'.
>
> This has no impact on ARM64 defconfig include/generated/autoconf.h,
> however changes few drivers for ARM 32-bit:
>
> 1. multi_v7_defconfig: Enable QCOM_CLK_RPMH as module, because SDX55
> (ARM 32-bit) uses it.
FWIW RPMHCC is a provider to GCC
I think TCSR_CC is also a good candidate for =y, as on platforms that
have it, it's necessary for USB/PCIe/UFS
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/7] KVM: arm64: Support FFA_NOTIFICATION_BIND in host handler
From: Vincent Donnefort @ 2026-06-10 9:03 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, will, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <20260608165549.1479409-4-sebastianene@google.com>
On Mon, Jun 08, 2026 at 04:55:45PM +0000, Sebastian Ene wrote:
> Verify the arguments of the FF-A notification bind call and forward the
> message to Trustzone.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 32 +++++++++++++++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 91e89d889c44..eedb01955a45 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -42,6 +42,8 @@
> */
> #define HOST_FFA_ID 0
>
> +#define FFA_NOTIF_SENDER_ENDP_MASK GENMASK(31, 16)
Could we move the MASK definitions form arm_ffa to include/linux/arm_ffa.h?
> +
> /*
> * A buffer to hold the maximum descriptor size we can see from the host,
> * which is required when the SPMD returns a fragmented FFA_MEM_RETRIEVE_RESP
> @@ -688,7 +690,6 @@ static bool ffa_call_supported(u64 func_id)
> case FFA_MEM_DONATE:
> case FFA_MEM_RETRIEVE_REQ:
> /* Optional notification interfaces added in FF-A 1.1 */
> - case FFA_NOTIFICATION_BIND:
> case FFA_NOTIFICATION_UNBIND:
> case FFA_NOTIFICATION_SET:
> case FFA_NOTIFICATION_GET:
> @@ -912,6 +913,32 @@ static void do_ffa_notif_bitmap_destroy(struct arm_smccc_1_2_regs *res,
> arm_smccc_1_2_smc(args, res);
> }
>
> +static void do_ffa_notif_bind(struct arm_smccc_1_2_regs *res,
> + struct kvm_cpu_context *ctxt)
> +{
> + DECLARE_REG(u32, endp_id, ctxt, 1);
> + DECLARE_REG(u32, flags, ctxt, 2);
> + struct arm_smccc_1_2_regs *args;
> +
> + if (ffa_check_unused_args_sbz(ctxt, 5)) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + if (FIELD_GET(FFA_NOTIF_SENDER_ENDP_MASK, endp_id) != HOST_FFA_ID) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
> +
> + if (flags & GENMASK(31, 1)) {
> + ffa_to_smccc_res(res, FFA_RET_INVALID_PARAMETERS);
> + return;
> + }
if (flags > 1) ?
> +
> + args = (void *)&ctxt->regs.regs[0];
> + arm_smccc_1_2_smc(args, res);
And of course just like all the other functions, it should use
the hyp_ prefix.
> +}
> +
> bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> {
> struct arm_smccc_1_2_regs res;
> @@ -976,6 +1003,9 @@ bool kvm_host_ffa_handler(struct kvm_cpu_context *host_ctxt, u32 func_id)
> case FFA_NOTIFICATION_BITMAP_DESTROY:
> do_ffa_notif_bitmap_destroy(&res, host_ctxt);
> goto out_handled;
> + case FFA_NOTIFICATION_BIND:
> + do_ffa_notif_bind(&res, host_ctxt);
> + goto out_handled;
> }
>
> if (ffa_call_supported(func_id))
> --
> 2.54.0.1064.gd145956f57-goog
>
^ permalink raw reply
* Re: [PATCH v2 03/16] power: sequencing: Change CONFIG_POWER_SEQUENCING to bool
From: Chen-Yu Tsai @ 2026-06-10 9:00 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, linux-acpi, driver-core, linux-pm, linux-usb,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-4-wenst@chromium.org>
On Wed, Jun 10, 2026 at 5:41 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> USB support, including the core and hub driver, is bool, no modules. To
> be able to use the power sequencing API in the USB core, the former must
> also be bool to avoid the latter being built as a module.
>
> Change CONFIG_POWER_SEQUENCING to bool.
As Sashiko pointed out, CONFIG_USB is tristate. I was looking at the
wrong symbol. Please ignore this patch.
ChenYu
^ permalink raw reply
* Re: [PATCH v2 2/7] clk: qcom: Restrict A7PLL and IPQ4019 GCC to ARM
From: Konrad Dybcio @ 2026-06-10 9:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel
In-Reply-To: <20260609-clk-qcom-defaults-v2-2-0c67c06dca11@oss.qualcomm.com>
On 6/9/26 5:32 PM, Krzysztof Kozlowski wrote:
> IPQ4019 is ARM 32-bit only SoC and QCOM_A7PLL is used only on SDX55 and
> SDX65, which are 32-bit as well.
>
> Do not allow building them for ARM64 to make built kernels smaller and
> user choices easier.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/7] clk: qcom: Restrict IPQ5424, IPQ6018,IPQ9574, QCM2290 and others to ARM64
From: Konrad Dybcio @ 2026-06-10 8:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Konrad Dybcio
Cc: linux-arm-msm, linux-clk, linux-kernel, linux-arm-kernel,
Dmitry Baryshkov
In-Reply-To: <20260609-clk-qcom-defaults-v2-1-0c67c06dca11@oss.qualcomm.com>
On 6/9/26 5:32 PM, Krzysztof Kozlowski wrote:
> Some clock drivers for IPQ5424, IPQ9574, QCM2290, QDU1000 and SA8775
> already depend on ARM64. IPQ6018 is ARM64 only SoC (at least upstream)
> so should not be a choice for ARM 32-bit builds, to make kernels smaller
> and user choices easier.
>
> IPQ_CMN_PLL is used only by the SoCs already having clock controllers
> restricted to ARM64
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
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