* Re: [PATCH v5 5/8] ARM: dts: Add an armv7 timer for zx297520v3
From: Krzysztof Kozlowski @ 2026-04-22 7:10 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260421-send-v5-5-ace038e63515@gmail.com>
On Tue, Apr 21, 2026 at 11:23:13PM +0300, Stefan Dösinger wrote:
> The stock kernel does not use this timer, but it seems to work fine. The
> board has other board-specific timers that would need a driver and I see
> no reason to bother with them since the arm standard timer works.
>
> The caveat is the non-standard GIC setup needed to handle the timer's
> level-low PPI. This is the responsibility of the boot loader and
> documented in Documentation/arch/arm/zte/zx297520v3.rst.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> arch/arm/boot/dts/zte/zx297520v3.dtsi | 24 ++++++++++++++++++++++++
This must be squashed. You add new SoC - that's one commit. One logical
change. Adding "not working SoC" and then "let's fix it" are not two
separate tasks.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 7/8] ARM: dts: Declare UARTs on zx297520v3 boards
From: Krzysztof Kozlowski @ 2026-04-22 7:10 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260421-send-v5-7-ace038e63515@gmail.com>
On Tue, Apr 21, 2026 at 11:23:15PM +0300, Stefan Dösinger wrote:
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>
> ---
>
Same comments about subject and squashing. This cannot be a separate
commit.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 7/8] ARM: dts: Declare UARTs on zx297520v3 boards
From: Krzysztof Kozlowski @ 2026-04-22 7:11 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Alexandre Belloni, Linus Walleij, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260422-vigorous-beautiful-peacock-4ac41b@quoll>
On 22/04/2026 09:10, Krzysztof Kozlowski wrote:
> On Tue, Apr 21, 2026 at 11:23:15PM +0300, Stefan Dösinger wrote:
>> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
>>
>> ---
>>
>
> Same comments about subject and squashing. This cannot be a separate
> commit.
>
Heh, and with empty commit msg!
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/9] ASoC: dt-bindings: mt2701-afe-pcm: add HDMI audio path clocks
From: Krzysztof Kozlowski @ 2026-04-22 7:19 UTC (permalink / raw)
To: Daniel Golle
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Cyril Chao,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <69f0b69e49068695db4ba6164c0757ccdf9786fd.1776646435.git.daniel@makrotopia.org>
On Mon, Apr 20, 2026 at 02:13:05AM +0100, Daniel Golle wrote:
> clock-names:
> + minItems: 34
> items:
> - const: infra_sys_audio_clk
> - const: top_audio_mux1_sel
> @@ -104,6 +110,10 @@ properties:
> - const: audio_a1sys_pd
> - const: audio_a2sys_pd
> - const: audio_mrgif_pd
> + - const: hadds2pll_294m
> + - const: audio_hdmi_pd
> + - const: audio_spdf_pd
> + - const: audio_apll_pd
>
> required:
> - compatible
> @@ -114,3 +124,16 @@ required:
> - clock-names
>
> additionalProperties: false
> +
> +allOf:
allOf goes before additionalProperties
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/9] ASoC: dt-bindings: mediatek,mt2701-hdmi-audio: add MT2701 HDMI audio
From: Krzysztof Kozlowski @ 2026-04-22 7:23 UTC (permalink / raw)
To: Daniel Golle
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Cyril Chao,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <072c4db4a01ac125e9ee5e34f992cd169c78e117.1776646435.git.daniel@makrotopia.org>
On Mon, Apr 20, 2026 at 02:13:13AM +0100, Daniel Golle wrote:
> Describe the sound card node that routes the MT2701/MT7623N AFE
> HDMI playback path to the on-chip HDMI transmitter. This is
> separate from the AFE platform binding (mediatek,mt2701-audio)
> because it represents board-level audio routing between the AFE
> and the HDMI codec, not an additional IP block. MT7623N boards
> carry the same IP and use the mt7623n- compatible as a fallback
> to mt2701-.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> v2:
> * Fix subject prefix to use schema filename (Krzysztof Kozlowski)
> * Rewrite title and description to describe hardware, not driver
> (Krzysztof Kozlowski)
> * Clarify in commit message why this is a separate binding from
> mediatek,mt2701-audio (Krzysztof Kozlowski)
>
> .../sound/mediatek,mt2701-hdmi-audio.yaml | 48 +++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 1/1] arm64: dts: add tqma9596la-mba95xxca
From: Alexander Stein @ 2026-04-22 7:24 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Markus Niebel, imx, linux-arm-kernel, devicetree, linux-kernel,
linux, linux-renesas-soc, Alexander Stein
From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
This adds support for TQMa95xxLA modules, designed to be soldered
on a carrier board. MBa95xxCA is a carrier reference board / starter kit
design.
There is a common device tree for all variants with e.g. reduced
CPU core / feature count.
Enable the external accessible PCIe controllers as host,
add clocking and reset GPIO. While at it, add hogs for GPIO
lines from the M.2 slots until M.2 connector driver is available.
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v3:
* Moved reserved-memory to board-lebel
* Remove VPU reserved memory (unused for now)
* Fix typo in connector comment
Changes in v2:
* removed useless regulator
* added USB PD source configuration
* Removed unused uart-has-rtscts properties (unused by LPUART)
* Fixed RTS/CTS pullups in pinctrl
* Added thermalzone on module
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../freescale/imx95-tqma9596la-mba95xxca.dts | 961 ++++++++++++++++++
.../boot/dts/freescale/imx95-tqma9596la.dtsi | 278 +++++
3 files changed, 1240 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c990..b47db26224bb9 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -507,6 +507,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596la-mba95xxca.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-dahlia.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
new file mode 100644
index 0000000000000..82d1d2f150124
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la-mba95xxca.dts
@@ -0,0 +1,961 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ * Author: Markus Niebel
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95-tqma9596la.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX95 TQMa95xxLA on MBa95xxCA";
+ compatible = "tq,imx95-tqma9596la-mba95xxca", "tq,imx95-tqma9596la", "fsl,imx95";
+ chassis-type = "embedded";
+
+ aliases {
+ ethernet0 = &enetc_port0;
+ ethernet1 = &enetc_port1;
+ ethernet2 = &enetc_port2;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ gpio3 = &gpio4;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ i2c4 = &lpi2c5;
+ i2c5 = &lpi2c6;
+ i2c6 = &lpi2c7;
+ i2c7 = &lpi2c8;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ rtc0 = &pcf85063;
+ rtc1 = &scmi_bbm;
+ serial0 = &lpuart1;
+ serial1 = &lpuart2;
+ serial2 = &lpuart3;
+ serial3 = &lpuart4;
+ serial4 = &lpuart5;
+ serial5 = &lpuart6;
+ serial6 = &lpuart7;
+ serial7 = &lpuart8;
+ spi0 = &flexspi1;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ backlight_lvds: backlight-lvds {
+ compatible = "pwm-backlight";
+ pwms = <&tpm5 2 100000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&expander2 6 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_12v0>;
+ status = "disabled";
+ };
+
+ clk_eth: clk-eth {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <156250000>;
+ };
+
+ /*
+ * TODO: gate is disabled for now and GPIO are hogged
+ * ENETC driver switches the clock far too late for ENETC2 + SFP
+ */
+ clk_eth_gate: clk-eth-gate {
+ compatible = "gpio-gate-clock";
+ enable-gpios = <&expander2 0 GPIO_ACTIVE_HIGH>;
+ clocks = <&clk_eth>;
+ #clock-cells = <0>;
+ status = "disabled";
+ };
+
+ clk_xtal25: clk-xtal25 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+
+ button-b {
+ label = "BUTTON_B#";
+ linux,code = <BTN_1>;
+ gpios = <&expander1 0 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&expander2 13 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ led-2 {
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_HEARTBEAT;
+ gpios = <&expander2 14 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc1 0>, <&adc1 1>, <&adc1 2>, <&adc1 3>,
+ <&adc1 4>, <&adc1 5>, <&adc1 6>, <&adc1 7>;
+ };
+
+ reg_v1v8_mb: regulator-v1v8-mb {
+ compatible = "regulator-fixed";
+ regulator-name = "V_1V8_MB";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_v3v3_mb: regulator-v3v3-mb {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3_MB";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_3v3a_10g: regulator-3v3a-10g {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3A_10G";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander2 15 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <2000>;
+ enable-active-high;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12V0";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&expander1 15 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_pwm_fan: regulator-pwm-fan {
+ compatible = "regulator-fixed";
+ regulator-name = "FAN_PWR";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&expander3 15 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <®_12v0>;
+ };
+
+ reg_lvds: regulator-lvds {
+ compatible = "regulator-fixed";
+ regulator-name = "LCD_PWR_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander2 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ /* USB NC limitations, RM 162.1.2 VBUS limitations */
+ reg_vbus_usb3: regulator-vbus-usb3 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-name = "USB3_VBUS";
+ gpio = <&gpio4 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux_cma: linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x28000000>;
+ alloc-ranges = <0 0x80000000 0 0x80000000>;
+ linux,cma-default;
+ };
+ };
+
+ sfp_xfi: sfp-xfi {
+ compatible = "sff,sfp";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sfp>;
+ i2c-bus = <&lpi2c7>;
+ maximum-power-milliwatt = <2000>;
+ mod-def0-gpios = <&expander1 3 GPIO_ACTIVE_LOW>;
+ tx-fault-gpios = <&gpio2 30 GPIO_ACTIVE_HIGH>;
+ los-gpios = <&gpio2 31 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpios = <&expander2 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-tlv320aic32x4";
+ model = "tqm-tlv320aic32";
+ audio-codec = <&tlv320aic3x04>;
+ audio-cpu = <&sai3>;
+ audio-routing =
+ "IN3_L", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "IN1_L", "Line In Jack",
+ "IN1_R", "Line In Jack",
+ "Line Out Jack", "LOL",
+ "Line Out Jack", "LOR";
+ };
+};
+
+&adc1 {
+ status = "okay";
+};
+
+&enetc_port0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enetc0>;
+ phy-handle = <ðphy0>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
+
+&enetc_port1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enetc1>;
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
+
+/* No support for XFI yet */
+&enetc_port2 {
+ sfp = <&sfp_xfi>;
+ phy-mode = "10gbase-r";
+ clocks = <&clk_eth>;
+ clock-names = "enet_ref_clk";
+ managed = "in-band-status";
+ status = "disabled";
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ tlv320aic3x04: audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ clocks = <&scmi_clk IMX95_CLK_SAI3>;
+ clock-names = "mclk";
+ reset-gpios = <&expander1 14 GPIO_ACTIVE_LOW>;
+ iov-supply = <®_v3v3_mb>;
+ ldoin-supply = <®_v3v3_mb>;
+ };
+
+ fan_controller: fan-controller@2f {
+ compatible = "microchip,emc2301", "microchip,emc2305";
+ reg = <0x2f>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #pwm-cells = <3>;
+ status = "okay";
+
+ fan: fan@0 {
+ reg = <0x0>;
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED 1>;
+ #cooling-cells = <2>;
+ fan-supply = <®_pwm_fan>;
+ };
+ };
+
+ ptn5110: usb-typec@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+
+ typec_con: connector {
+ compatible = "usb-c-connector";
+ label = "X9";
+ power-role = "source";
+ data-role = "dual";
+ source-pdos = <PDO_FIXED(5000, 500, PDO_FIXED_USB_COMM)>;
+ self-powered;
+
+ port {
+ typec_con_hs: endpoint {
+ remote-endpoint = <&typec_hs>;
+ };
+ };
+ };
+ };
+
+ sensor_mb: temperature-sensor@1e {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x1e>;
+ };
+
+ eeprom_mb: eeprom@56 {
+ compatible = "nxp,se97b", "atmel,24c02";
+ reg = <0x56>;
+ pagesize = <16>;
+ vcc-supply = <®_v3v3_mb>;
+ };
+
+ pcieclk: clock-generator@68 {
+ compatible = "renesas,9fgv0441";
+ reg = <0x68>;
+ clocks = <&clk_xtal25>;
+ #clock-cells = <1>;
+ };
+
+ /* D39 IN/OUT 3V3 */
+ expander1: gpio@74 {
+ compatible = "ti,tca9539";
+ reg = <0x74>;
+ vcc-supply = <®_v3v3_mb>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_expander1>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
+
+ gpio-line-names =
+ /* 00 */ "BUTTON_B#", "CAM0_SYNC_3V3",
+ /* 02 */ "CAM1_SYNC_3V3", "SFP_MOD_ABS",
+ /* 04 */ "DIG_IN1", "DIG_IN2",
+ /* 06 */ "DIG_IN3", "DIG_IN4",
+ /* 08 */ "DIG_OUT_1_2_STATE", "DIG_OUT_3_4_STATE",
+ /* 10 */ "DIG_OUT_1_EN", "DIG_OUT_2_EN",
+ /* 12 */ "DIG_OUT_3_EN", "DIG_OUT_4_EN",
+ /* 14 */ "AUDIO_RST#", "12V_EN";
+ };
+
+ /* D40 OUT 3V3 */
+ expander2: gpio@75 {
+ compatible = "ti,tca9539";
+ reg = <0x75>;
+ vcc-supply = <®_3v3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ /* 00 */ "ETH10G_REFCLK_EN", "ETH10G_REFCLK_RST#",
+ /* 02 */ "SFP_TX_DIS", "USB3_RESET#",
+ /* 04 */ "USB2_RESET#", "LCD_RESET#",
+ /* 06 */ "LCD_BLT_EN", "LCD_PWR_EN",
+ /* 08 */ "M2_KEYE_PERST#", "M2_KEYE_WDISABLE1#",
+ /* 10 */ "M2_KEYE_WDISABLE2#", "M2_KEYB_PERST#",
+ /* 12 */ "M2_KEYB_WDISABLE1#", "USER_LED1",
+ /* 14 */ "USER_LED2", "3V3A_10G_EN";
+
+ eth10g-refclk-en-hog {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "ETH10G_REFCLK_EN";
+ };
+
+ eth10g-refclk-rst-hog {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "ETH10G_REFCLK_RST#";
+ };
+
+ m2_keye_wdisable1_hog: m2-keye-wdisable1-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "M2_KEYE_WDISABLE1#";
+ };
+
+ m2_keye_wdisable2_hog: m2-keye-wdisable2-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "M2_KEYE_WDISABLE2#";
+ };
+
+ m2-keyb-wdisable1-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "M2_KEYB_WDISABLE1#";
+ };
+ };
+
+ /* D41 OUT 1V8 */
+ expander3: gpio@76 {
+ compatible = "ti,tca9539";
+ reg = <0x76>;
+ vcc-supply = <®_v1v8_mb>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ /* 00 */ "ENET1_RESET#", "ENET2_RESET#",
+ /* 02 */ "M2_KEYE_SDIO_RST#", "M2_KEYE_DEV_WLAN_WAKE#",
+ /* 04 */ "M2_KEYE_DEV_BT_WAKE", "M2_KEYB_W_DISABLE2#",
+ /* 06 */ "M2_KEYB_RST#", "M2_KEYB_FULL_CARD_PWR_OFF#",
+ /* 08 */ "M2_KEYB_DPR", "CAM0_PWR#",
+ /* 10 */ "CAM1_PWR#", "CAM0_RST#",
+ /* 12 */ "CAM1_RST#", "CAM0_TRIGGER",
+ /* 14 */ "CAM1_TRIGGER", "FAN_PWR_EN";
+
+ m2-keye-sdio-rst-hog {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "M2_KEYE_SDIO_RST#";
+ };
+
+ m2-keye-dev_wlan-wake-hog {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "M2_KEYE_DEV_WLAN_WAKE#";
+ };
+
+ m2-keye-dev_bt-wake-hog {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "M2_KEYE_DEV_BT_WAKE#";
+ };
+
+ m2-keyb-wdisable2-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "M2_KEYB_WDISABLE1#";
+ };
+
+ m2-keyb-rst-hog {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "M2_KEYB_RST#";
+ };
+
+ m2-keyb-full-card-pwr-off-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "M2_KEYB_FULL_CARD_PWR_OFF#";
+ };
+ };
+};
+
+/* X4 + SFP */
+&lpi2c7 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c7>;
+ pinctrl-1 = <&pinctrl_lpi2c7_recovery>;
+ scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ /* TODO: 0x19: retimer */
+
+ /* 0x50 / 0x51: SFP EEPROM */
+};
+
+/* X4 */
+&lpspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi4>;
+ cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>, <&gpio5 14 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&lpuart1 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart1>;
+ status = "okay";
+};
+
+&lpuart2 {
+ /* SM */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart2>;
+ status = "reserved";
+};
+
+&lpuart5 {
+ /* X16 M.2 KEY E */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart5>;
+ status = "okay";
+};
+
+&lpuart7 {
+ /* X5 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart7>;
+ status = "okay";
+};
+
+&lpuart8 {
+ /* X15 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart8>;
+ linux,rs485-enabled-at-boot-time;
+ status = "okay";
+};
+
+&netc_blk_ctrl {
+ status = "okay";
+};
+
+&netc_emdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emdio>;
+ status = "okay";
+
+ /* IRQ pin is AON GPIO, not usable */
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&expander3 0 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ };
+
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ethphy1>;
+ reset-gpios = <&expander3 1 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_50_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ };
+};
+
+&netc_timer {
+ status = "okay";
+};
+
+&netcmix_blk_ctrl {
+ status = "okay";
+};
+
+/* X16 M2 / E-Key mPCIe */
+&pcie0 {
+ pinctrl-0 = <&pinctrl_pcie0>;
+ pinctrl-names = "default";
+ clocks = <&scmi_clk IMX95_CLK_HSIO>,
+ <&scmi_clk IMX95_CLK_HSIOPLL>,
+ <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
+ <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
+ <&pcieclk 1>;
+ clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
+ reset-gpios = <&expander2 8 GPIO_ACTIVE_LOW>;
+ /* Not supported on REV.0100 */
+ /* supports-clkreq; */
+ status = "okay";
+};
+
+/* X17 M2 / B-Key PCIe */
+&pcie1 {
+ pinctrl-0 = <&pinctrl_pcie1>;
+ pinctrl-names = "default";
+ clocks = <&scmi_clk IMX95_CLK_HSIO>,
+ <&scmi_clk IMX95_CLK_HSIOPLL>,
+ <&scmi_clk IMX95_CLK_HSIOPLL_VCO>,
+ <&scmi_clk IMX95_CLK_HSIOPCIEAUX>,
+ <&pcieclk 0>;
+ clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux", "ref";
+ reset-gpios = <&expander2 11 GPIO_ACTIVE_LOW>;
+ /* Not supported on REV.0100 */
+ /* supports-clkreq; */
+ status = "okay";
+};
+
+®_sdvmmc {
+ status = "okay";
+};
+
+&sai3 {
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI3>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <12288000>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+&scmi_bbm {
+ linux,code = <KEY_POWER>;
+};
+
+&thermal_zones {
+ a55-thermal {
+ trips {
+ cpu_active0: trip-active0 {
+ temperature = <40000>;
+ hysteresis = <5000>;
+ type = "active";
+ };
+
+ cpu_active1: trip-active1 {
+ temperature = <48000>;
+ hysteresis = <3000>;
+ type = "active";
+ };
+
+ cpu_active2: trip-active2 {
+ temperature = <60000>;
+ hysteresis = <10000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&cpu_active0>;
+ cooling-device = <&fan 0 2>;
+ };
+
+ map2 {
+ trip = <&cpu_active1>;
+ cooling-device = <&fan 3 5>;
+ };
+
+ map3 {
+ trip = <&cpu_active2>;
+ cooling-device = <&fan 6 10>;
+ };
+ };
+ };
+};
+
+&tpm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tpm3>;
+ status = "okay";
+};
+
+&tpm5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tpm5>;
+};
+
+&usb2 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ typec_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ hub_2_0: hub@1 {
+ compatible = "usb451,8142";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_v3v3_mb>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub_2_1: hub@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ reset-gpios = <&expander2 4 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_v3v3_mb>;
+ vdda-supply = <®_v3v3_mb>;
+ };
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb451,8140";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&expander2 3 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_v3v3_mb>;
+ };
+};
+
+&usb3_phy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb3>;
+ vbus-supply = <®_vbus_usb3>;
+ status = "okay";
+};
+
+/* X7 µSD */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+ vmmc-supply = <®_sdvmmc>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ no-mmc;
+ no-sdio;
+ disable-wp;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ pinctrl_enetc0: enetc0grp {
+ fsl,pins = <IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x1100>,
+ <IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x1100>,
+ <IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x1100>,
+ <IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x1100>,
+ <IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x1100>,
+ <IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x1100>,
+ <IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x11e>,
+ <IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x11e>,
+ <IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x11e>,
+ <IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x11e>,
+ <IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x11e>,
+ <IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x11e>;
+ };
+
+ pinctrl_enetc1: enetc1grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD0__NETCMIX_TOP_ETH1_RGMII_RD0 0x1100>,
+ <IMX95_PAD_ENET2_RD1__NETCMIX_TOP_ETH1_RGMII_RD1 0x1100>,
+ <IMX95_PAD_ENET2_RD2__NETCMIX_TOP_ETH1_RGMII_RD2 0x1100>,
+ <IMX95_PAD_ENET2_RD3__NETCMIX_TOP_ETH1_RGMII_RD3 0x1100>,
+ <IMX95_PAD_ENET2_RXC__NETCMIX_TOP_ETH1_RGMII_RX_CLK 0x1100>,
+ <IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_ETH1_RGMII_RX_CTL 0x1100>,
+ <IMX95_PAD_ENET2_TD0__NETCMIX_TOP_ETH1_RGMII_TD0 0x11e>,
+ <IMX95_PAD_ENET2_TD1__NETCMIX_TOP_ETH1_RGMII_TD1 0x11e>,
+ <IMX95_PAD_ENET2_TD2__NETCMIX_TOP_ETH1_RGMII_TD2 0x11e>,
+ <IMX95_PAD_ENET2_TD3__NETCMIX_TOP_ETH1_RGMII_TD3 0x11e>,
+ <IMX95_PAD_ENET2_TXC__NETCMIX_TOP_ETH1_RGMII_TX_CLK 0x11e>,
+ <IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_ETH1_RGMII_TX_CTL 0x11e>;
+ };
+
+ pinctrl_ethphy0: ethphy0grp {
+ fsl,pins = <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_GPIO1_IO_BIT9 0x1100>;
+ };
+
+ pinctrl_ethphy1: ethphy1grp {
+ fsl,pins = <IMX95_PAD_ENET1_MDC__GPIO4_IO_BIT0 0x1100>;
+ };
+
+ pinctrl_expander1: expander1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO14__GPIO2_IO_BIT14 0x1100>;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <IMX95_PAD_SAI1_TXC__AONMIX_TOP_CAN1_RX 0x1300>,
+ <IMX95_PAD_SAI1_TXD0__AONMIX_TOP_CAN1_TX 0x31e>;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO25__CAN2_TX 0x31e>,
+ <IMX95_PAD_GPIO_IO27__CAN2_RX 0x1300>;
+ };
+
+ pinctrl_lpi2c7: lpi2c7grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO07__LPI2C7_SCL 0x40001b1e>,
+ <IMX95_PAD_GPIO_IO06__LPI2C7_SDA 0x40001b1e>;
+ };
+
+ pinctrl_lpi2c7_recovery: lpi2c7recoverygrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO07__GPIO2_IO_BIT7 0x40001b1e>,
+ <IMX95_PAD_GPIO_IO06__GPIO2_IO_BIT6 0x40001b1e>;
+ };
+
+ pinctrl_lpspi4: lpspi4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO37__LPSPI4_SCK 0x91e>,
+ <IMX95_PAD_GPIO_IO19__LPSPI5_SIN 0x191e>,
+ <IMX95_PAD_GPIO_IO36__LPSPI4_SOUT 0x91e>,
+ <IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x91e>,
+ <IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13 0x91e>;
+ };
+
+ pinctrl_lpuart1: lpuart1grp {
+ fsl,pins = <IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e>,
+ <IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x1300>;
+ };
+
+ pinctrl_lpuart2: lpuart2grp {
+ fsl,pins = <IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX 0x31e>,
+ <IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX 0x1300>;
+ };
+
+ pinctrl_lpuart5: lpuart5grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO00__LPUART5_TX 0x31e>,
+ <IMX95_PAD_GPIO_IO01__LPUART5_RX 0x1300>,
+ <IMX95_PAD_GPIO_IO02__LPUART5_CTS_B 0x1300>,
+ <IMX95_PAD_GPIO_IO03__LPUART5_RTS_B 0x31e>;
+ };
+
+ pinctrl_lpuart7: lpuart7grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO08__LPUART7_TX 0x31e>,
+ <IMX95_PAD_GPIO_IO09__LPUART7_RX 0x1300>,
+ <IMX95_PAD_GPIO_IO10__LPUART7_CTS_B 0x1300>,
+ <IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>;
+ };
+
+ pinctrl_lpuart8: lpuart8grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO12__LPUART8_TX 0x31e>,
+ <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x1300>,
+ <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>;
+ };
+
+ pinctrl_emdio: emdiogrp {
+ fsl,pins = <IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x51e>,
+ <IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x51e>;
+ };
+
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x111e>;
+ };
+
+ pinctrl_pcie1: pcie1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x111e>;
+ };
+
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO16__SAI3_TX_BCLK 0x51e>,
+ <IMX95_PAD_GPIO_IO17__SAI3_MCLK 0x51e>,
+ <IMX95_PAD_GPIO_IO20__SAI3_RX_DATA_BIT0 0x1300>,
+ <IMX95_PAD_GPIO_IO21__SAI3_TX_DATA_BIT0 0x51e>,
+ <IMX95_PAD_GPIO_IO26__SAI3_TX_SYNC 0x51e>;
+ };
+
+ pinctrl_retimer: retirmergrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO29__GPIO2_IO_BIT29 0x1100>;
+ };
+
+ pinctrl_sfp: sfpgrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO30__GPIO2_IO_BIT30 0x1100>,
+ <IMX95_PAD_GPIO_IO31__GPIO2_IO_BIT31 0x1100>;
+ };
+
+ pinctrl_tpm3: tpm3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO24__TPM3_CH3 0x51e>;
+ };
+
+ pinctrl_tpm5: tpm5grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO18__TPM5_CH2 0x51e>;
+ };
+
+ pinctrl_typec: typcegrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO28__GPIO2_IO_BIT28 0x1100>;
+ };
+
+ pinctrl_usb3: usb3grp {
+ fsl,pins = <IMX95_PAD_ENET1_MDIO__GPIO4_IO_BIT1 0x31e>;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
+ <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x51e>,
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x31e>,
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x131e>,
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x131e>,
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x131e>,
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x131e>,
+ <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
+ <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x58e>,
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x38e>,
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e>,
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e>,
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e>,
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e>,
+ <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>,
+ <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x5fe>,
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x3fe>,
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe>,
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe>,
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe>,
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe>,
+ <IMX95_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e>;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
new file mode 100644
index 0000000000000..aa2756c14e461
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-tqma9596la.dtsi
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2024-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Alexander Stein
+ * Author: Markus Niebel
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "imx95.dtsi"
+
+/ {
+ memory@80000000 {
+ device_type = "memory";
+ /*
+ * DRAM base addr, size : 2048 MiB DRAM
+ * should be corrected by bootloader
+ */
+ reg = <0 0x80000000 0 0x80000000>;
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "V_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_sdvmmc: regulator-sdvmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sdvmmc>;
+ regulator-name = "SD_PWR_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ off-on-delay-us = <12000>;
+ enable-active-high;
+ /* can be enabled by mainboard with SD-Card support */
+ status = "disabled";
+ };
+};
+
+&adc1 {
+ vref-supply = <®_1v8>;
+};
+
+&flexspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi1>;
+ status = "okay";
+
+ flash0: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <66000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ vcc-supply = <®_1v8>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
+
+/* System Manager */
+&gpio1 {
+ status = "reserved";
+};
+
+/* System Manager */
+&lpi2c1 {
+ status = "reserved";
+};
+
+&lpi2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ status = "okay";
+
+ pcf85063: rtc@51 {
+ compatible = "nxp,pcf85063a";
+ reg = <0x51>;
+ quartz-load-femtofarads = <7000>;
+ };
+
+ m24c64: eeprom@54 {
+ compatible = "atmel,24c64";
+ reg = <0x54>;
+ pagesize = <32>;
+ vcc-supply = <®_3v3>;
+ };
+
+ /* protectable identification memory (part of M24C64-D @54) */
+ eeprom@5c {
+ compatible = "atmel,24c64d-wl";
+ reg = <0x5c>;
+ pagesize = <32>;
+ vcc-supply = <®_3v3>;
+ };
+
+ imu@6b {
+ compatible = "st,ism330dhcx";
+ reg = <0x6b>;
+ vdd-supply = <®_3v3>;
+ vddio-supply = <®_3v3>;
+ };
+};
+
+&thermal_zones {
+ pf09-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 2>;
+
+ trips {
+ pf09_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf09_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pf53arm-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 4>;
+
+ cooling-maps {
+ map0 {
+ trip = <&pf5301_alert>;
+ cooling-device =
+ <&A55_0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&A55_5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ pf5301_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf5301_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pf53soc-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 3>;
+
+ trips {
+ pf5302_alert: trip0 {
+ hysteresis = <2000>;
+ temperature = <140000>;
+ type = "passive";
+ };
+
+ pf5302_crit: trip1 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ no-sdio;
+ no-sd;
+ status = "okay";
+};
+
+&wdog3 {
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ pinctrl_flexspi1: flexspi1grp {
+ fsl,pins = <IMX95_PAD_XSPI1_SS0_B__FLEXSPI1_A_SS0_B 0x19e>,
+ <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x19e>,
+ <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x19e>,
+ <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x19e>,
+ <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x19e>,
+ /* SION to allow clock loopback from pad */
+ <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x4000019e>,
+ <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x4000019e>;
+ };
+
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x4000191e>,
+ <IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x4000191e>;
+ };
+
+ pinctrl_sdvmmc: sdvmmcgrp {
+ fsl,pins = <IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x11e>;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>,
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>,
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>,
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>,
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>,
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>,
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>,
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>,
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>,
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>,
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe>,
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe>,
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe>,
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe>,
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe>,
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe>,
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe>,
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe>,
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe>,
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe>,
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* Re: New warning in linus/master
From: Christophe Leroy (CS GROUP) @ 2026-04-22 7:26 UTC (permalink / raw)
To: Thomas Weißschuh, Ricardo Ribalda
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422071541-9a295128-d913-418f-a21c-1386fca30290@linutronix.de>
Le 22/04/2026 à 07:56, Thomas Weißschuh a écrit :
> Hi Ricardo,
>
> On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
>> Media-CI has found a couple of new warnings in the latest kernel
>> version for aarch64 and powerpc. They get fixed with this patch and
>> before moving I wanted to know if this was under your radar.
>
> Thanks for the report. I was not aware of these so far.
>
>> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
>> index 7dec05dd33b7..65914842fae0 100644
>> --- a/arch/arm64/kernel/vdso/Makefile
>> +++ b/arch/arm64/kernel/vdso/Makefile
>> @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
>> CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
>>
>> ifneq ($(c-gettimeofday-y),)
>> - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
>> + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
>> -Wno-maybe-uninitialized
>> endif
>
> (...)
>
> I'd like to know exactly what is going on before suppressing the warning.
> It is a non-standard warning, only enabled by *some* of the vDSO builds
> for some reason.
>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fusers%2Fribalda%2F-%2Fpipelines%2F1649144%2Ftest_report%3Fjob_name%3Dcross-gcc&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C5c0f15ee20a44072f47108dea0340304%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124342424606113%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9Tvp2aYfB02ijxVGLzCOYcMwZlPvqVDufxEporLl1mc%3D&reserved=0
>
> While I was able to download a configuration from this job and also use the
> same container image, I can not reproduce the issue. Is the configuration the
> full one or only the template?
>
> Could you provide full reproduction steps?
>
>> CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Debian 15.2.0-16) 15.2.0"
>
> The linked test log shows GCC 14.2, not 15.2.
> Not that I could reproduce it with either one...
>
>> SYNC include/config/auto.conf
>> CC arch/arm64/kernel/vdso/vgettimeofday.o
>> In file included from <command-line>:
>> In function ‘vdso_set_timespec’,
>> inlined from ‘do_aux’ at /workdir/lib/vdso/gettimeofday.c:266:2,
>> inlined from ‘__cvdso_clock_gettime_common’ at
>> /workdir/lib/vdso/gettimeofday.c:293:10,
>> inlined from ‘__cvdso_clock_gettime_data.constprop’ at
>> /workdir/lib/vdso/gettimeofday.c:306:7:
>> /workdir/lib/vdso/gettimeofday.c:104:26: warning: ‘sec’ may be used
>> uninitialized [-Wmaybe-uninitialized]
>> 104 | ts->tv_sec = sec + __iter_div_u64_rem(ns, NSEC_PER_SEC, &ns);
>> | ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> /workdir/lib/vdso/gettimeofday.c: In function
>> ‘__cvdso_clock_gettime_data.constprop’:
>> /workdir/lib/vdso/gettimeofday.c:242:13: note: ‘sec’ was declared here
>> 242 | u64 sec, ns;
>> | ^~~
>
> The same pattern is used in some other do_ handlers, which do not generate this
> warning. I also can't immediately see what is wrong.
You are likely in a special case where vdso_get_timestamp() returns
false without setting &sec, and some versions of GCC and/or CLANG fail
to see that vdso_set_timespec() is not called when vdso_get_timestamp()
returns false.
Christophe
^ permalink raw reply
* Re: New warning in linus/master
From: Thomas Weißschuh @ 2026-04-22 7:32 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CANiDSCviww1L1p2+MvF59Biqb6hc7WdL1J37kBjFd1NXz-Yt8A@mail.gmail.com>
On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> <thomas.weissschuh@linutronix.de> wrote:
> > On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> > > Media-CI has found a couple of new warnings in the latest kernel
> > > version for aarch64 and powerpc. They get fixed with this patch and
> > > before moving I wanted to know if this was under your radar.
> >
> > Thanks for the report. I was not aware of these so far.
> >
> > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > index 7dec05dd33b7..65914842fae0 100644
> > > --- a/arch/arm64/kernel/vdso/Makefile
> > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> > > CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
> > >
> > > ifneq ($(c-gettimeofday-y),)
> > > - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > -Wno-maybe-uninitialized
> > > endif
> >
> > (...)
> >
> > I'd like to know exactly what is going on before suppressing the warning.
> > It is a non-standard warning, only enabled by *some* of the vDSO builds
> > for some reason.
> >
> > > https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
> >
> > While I was able to download a configuration from this job and also use the
> > same container image, I can not reproduce the issue. Is the configuration the
> > full one or only the template?
> >
> > Could you provide full reproduction steps?
>
> You can try repro with:
>
> work/linux $ podman run -v .:/workdir/ --rm -it
> registry.freedesktop.org/linux-media/media-ci/build:latest
> $ cd /workdir
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> arch/arm64/kernel/vdso/vgettimeofday.o
>
> The gcc version discrepancy is because I the error was due to old gcc
> version and I was playing around with that... but it fails in both
> gcc14 and gcc15
Ack.
> You can try with debian testing with
> work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
> $ apt-get update
> $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
> $ cd /workdir
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> arch/arm64/kernel/vdso/vgettimeofday.o
Both reproducers do *not* reproduce the issue for me.
(It is more or less exactly what I tried before)
Please note that this line does not work in general:
$ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make arch/arm64/kernel/vdso/vgettimeofday.o
The vDSO object files can not be built in this way like regular kernel object
files and will produce a compiler error, but not the one under discussion.
Instead the vDSO on arm64 is built during the 'make prepare' phase.
(Other architectures work differently, of course...)
(...)
Thomas
^ permalink raw reply
* Re: [PATCH v2] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: David Hildenbrand (Arm) @ 2026-04-22 7:32 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, Ryan Roberts, Mark Brown,
Dev Jain, linux-kernel, linux-mm, stable
In-Reply-To: <20260421-zerotags-v2-1-05cb1035482e@kernel.org>
> }
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 6c75df30a281..d79049291b1a 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -273,11 +273,11 @@ enum {
> *
> * %__GFP_ZERO returns a zeroed page on success.
> *
> - * %__GFP_ZEROTAGS zeroes memory tags at allocation time if the memory itself
> - * is being zeroed (either via __GFP_ZERO or via init_on_alloc, provided that
> - * __GFP_SKIP_ZERO is not set). This flag is intended for optimization: setting
> - * memory tags at the same time as zeroing memory has minimal additional
> - * performance impact.
> + * %__GFP_ZEROTAGS zeroes memory tags at allocation time. Setting memory tags at
> + * the same time as zeroing memory (e.g., with __GPF_ZERO) has minimal
As pointed out by AI review s/__GPF_ZERO/__GFP_ZERO/.
I assume this can be fixed up when applying.
--
Cheers,
David
^ permalink raw reply
* Re: New warning in linus/master
From: Ricardo Ribalda @ 2026-04-22 8:06 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422092713-4021a1a5-3a54-4260-878a-aec1bef3f8c7@linutronix.de>
Hi Thomas
On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
<thomas.weissschuh@linutronix.de> wrote:
>
> On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> > On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> > <thomas.weissschuh@linutronix.de> wrote:
> > > On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> > > > Media-CI has found a couple of new warnings in the latest kernel
> > > > version for aarch64 and powerpc. They get fixed with this patch and
> > > > before moving I wanted to know if this was under your radar.
> > >
> > > Thanks for the report. I was not aware of these so far.
> > >
> > > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > > index 7dec05dd33b7..65914842fae0 100644
> > > > --- a/arch/arm64/kernel/vdso/Makefile
> > > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > > @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> > > > CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
> > > >
> > > > ifneq ($(c-gettimeofday-y),)
> > > > - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > -Wno-maybe-uninitialized
> > > > endif
> > >
> > > (...)
> > >
> > > I'd like to know exactly what is going on before suppressing the warning.
> > > It is a non-standard warning, only enabled by *some* of the vDSO builds
> > > for some reason.
> > >
> > > > https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
> > >
> > > While I was able to download a configuration from this job and also use the
> > > same container image, I can not reproduce the issue. Is the configuration the
> > > full one or only the template?
> > >
> > > Could you provide full reproduction steps?
> >
> > You can try repro with:
> >
> > work/linux $ podman run -v .:/workdir/ --rm -it
> > registry.freedesktop.org/linux-media/media-ci/build:latest
> > $ cd /workdir
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > arch/arm64/kernel/vdso/vgettimeofday.o
> >
> > The gcc version discrepancy is because I the error was due to old gcc
> > version and I was playing around with that... but it fails in both
> > gcc14 and gcc15
>
> Ack.
>
> > You can try with debian testing with
> > work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
> > $ apt-get update
> > $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
> > $ cd /workdir
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > arch/arm64/kernel/vdso/vgettimeofday.o
>
> Both reproducers do *not* reproduce the issue for me.
> (It is more or less exactly what I tried before)
Ok, I think I found what is going on. media-ci was forcing
KCFLAGS=-Wmaybe-uninitialized
https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-build.sh?ref_type=heads#L29
And something has changed in the kernel in the last version that
triggers a (hopefully) false positive.
can you try with:
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized allyesconfig
CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
KCFLAGS=-Wmaybe-uninitialized prepare
?
>
> Please note that this line does not work in general:
> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make arch/arm64/kernel/vdso/vgettimeofday.o
>
> The vDSO object files can not be built in this way like regular kernel object
> files and will produce a compiler error, but not the one under discussion.
> Instead the vDSO on arm64 is built during the 'make prepare' phase.
> (Other architectures work differently, of course...)
>
> (...)
>
>
> Thomas
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Alexey Charkov @ 2026-04-22 8:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Brian Masney, Sebastian Reichel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Pavel Zhovner, Andy Yan, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, linux-clk, Cristian Ciocaltea
In-Reply-To: <20260421-quirky-tough-robin-817a1c@houat>
Hi Sebastian, Brian, Maxime,
Thanks a lot for your inputs!
On Tue, Apr 21, 2026 at 8:10 PM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi Brian, Alexey,
>
> On Mon, Apr 20, 2026 at 12:02:58PM -0400, Brian Masney wrote:
> > On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> > > On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > > > Dear all,
> > > >
> > > > Need the help of the collective wisdom of the community.
> > > >
> > > > The problem I'm trying to solve is reliably obtaining the exact pixel
> > > > clock for arbitrary display modes supported by the RK3576 SoC.
> > > >
> > > > Rockchip RK3576 has three display output processors VP0~VP2, each
> > > > supporting different ranges of display modes, roughly as follows:
> > > > - VP0: 4K 120Hz
> > > > - VP1: 2.5k 60Hz
> > > > - VP2: 1080p 60Hz
>
> Do any of those have an additional multiplier or divider after the PLL?
>
> I'm asking because 4k@120Hz is 1188MHz, and 1080p@60Hz is 148.5 (so 1188
> / 8). 2.5k @ 60 might be a bit more problematic, but my point is that
> for HDMI/DP, most resolutions all have a pixel clock that are multiples
> of 148.5MHz.
>
> If you manage to get the PLL to the highest you need (1188MHz), and then
> apply dividers, you don't need to change the PLL frequency anymore.
Yes, each of them has an (integer-only) divider between the PLL and
the respective mux. The problem though is that displays' EDIDs want
modes that are all over the place and don't seem to converge to any
common numbers generally (it looks like display manufacturers haven't
heard of VESA modes these days).
Following Heiko's nudge from the other sub-thread (thanks for the
pointers Heiko!), I derived the fractional PLL parameters for the
modes which couldn't be obtained cleanly from existing PLL values. It
ended up being 35(!) different rates for just the 7 displays my
colleagues and I could get our hands on, majority of which only
representable with the fractional delta-sigma component. That's after
consolidating the clocks which can be driven from the same
higher-frequency PLL configuration with small integer dividers. Seeing
all of that I couldn't help but think, "Surely those should be
possible to consolidate further by allowing for some error margin!" -
but had to guess again. Even a deviation as small as 0.2% of the
effective clock from the requested rate causes blank screens in my
sample - sometimes less than that.
This further leads me to believe that Brian's rate negotiation series
won't save me here, as the chances of two different displays at two
different weird modes magically agreeing on a PLL rate that is a
common multiple of their respective pixel clocks seem infinitesimal.
And their modes will most likely differ, as VP outputs are asymmetric.
Unless of course everything is 1920x1080@60 with a standard 148.5 MHz
pixel clock or its integer multiple - then the problem doesn't exist,
as this particular mode works even in the current configuration on all
VPs.
> > > > Each one obviously needs a pixel clock. The required frequencies for the
> > > > pixel clocks vary greatly depending on the display mode, and need to be
> > > > matched within a tight tolerance, or else many displays will refuse to
> > > > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > > > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > > > be obtained using integer dividers from its default clock source (GPLL
> > > > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > > > outside the tolerance of e.g. DP specification, resulting in a blank
> > > > screen on most displays by default.
> > > >
> > > > The clock sources are of course configurable, in particular there are muxes
> > > > connected to each VP for selecting the source of the pixel clock:
> > > > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > > > its dedicated dclk_vpX_src mux
> > > > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > > > (GPLL, CPLL, VPLL, BPLL, LPLL)
> > > >
> > > > While the system PLLs can be configured to output a wide range of
> > > > frequencies, they are shared between many system components. E.g. on the
> > > > current mainline kernel on one of my RK3576 boards I've got the following:
> > > > GPLL: 1188 MHz, enable count 20
> > > > CPLL: 1000 MHz, enable count 17
> > > > VPLL: 594 MHz, enable count 0 (yaay!)
> > > > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > > > predividers, so are less flexible)
> > > >
> > > > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > > > used to generate arbitrary pixel clocks, but we have up to three consumers
> > > > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > > > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > > > frequency on the fly to satisfy the requirements of the selected display
> > > > mode.
> > > >
> > > > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > > > three consumers while changing the PLL frequency on the fly sounds like
> > > > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > > > HDMI output out of the equation, because it can be driven from the HDMI
> > > > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > > > makes the decision of which dclk source to use for a VP block dependent on
> > > > which downstream consumer is connected to it (HDMI vs. something else).
> > >
> > > It becomes more messy: The HDMI PHY cannot be used as clock source
> > > for modes exceeding 4K@60Hz.
Thanks for the pointer! I've checked, and indeed it automatically
switches to the PHY clock for anything below 600 MHz.
This is in fact a notable improvement, because then only a handful of
higher-rate modes out of my modest sample need a dedicated PLL for the
VP0+HDMI setup: specifically, 3840x2160@160 (1478740 kHz),
3840x2160@144 (1275830 kHz), 3840x2160@119.88 (1186813 kHz - this one
might work with 1188000 if CCF allows returning higher-than-requested
effective rates) and 2560x1440@165.08 (645000 kHz).
3840x2160@120 can be driven from the current GPLL, as it's exactly 1188 MHz.
The configuration / policy to enable that transparently for the user
seems non-trivial though:
- If the output is HDMI and the display clock is <=600 MHz, always
source it from HDMI PHY (easy)
- Otherwise, if the display clock is 1188 MHz or its integer quotient,
always source it from GPLL, and disallow parent rate changes
- Otherwise, reparent to any active PLL whose current rate is an
integer multiple of the required display clock, and disallow parent
rate changes
- Otherwise, see if VPLL is free. If it is, reparent to it and request
its rate change to the required display clock (or its integer
multiple)
- Otherwise, tell the user the mode set failed (and let them retry
with a different mode, or own the pieces)
I'd love to learn if the above (or anything close) is representable in
the kernel, although I suspect it's not:
- Allowing or disallowing parent rate changes depends on the selected
parent here, while in the current clock implementation it's an
attribute of the child
- All PLLs are equal, but one (VPLL) is more equal than the others by
the virtue of being free more often, and also having the required
delta-sigma component
- Reparenting to an already running PLL if its rate permits should be
preferred to monopolizing the VPLL
> > > > Even then we somehow need two devices to cooperate in picking a PLL
> > > > frequency that satisfies the requirements of both of them, and change to it
> > > > without display corruption. I'm not even sure if the CCF has mechanisms
> > > > for that?..
>
> It's not *just* the CCF though. You will disrupt the other, already
> active display, which might affect the user because the screen will
> blank, throw off the vblank timings and thus userspace, etc.
Indeed. Changing the rate of a PLL while it's in use sounds scary,
even if a solution for the rate exists and can be found in reasonable
time.
> Brian's solution is great progress on that front already, but if you can
> just save yourself the trouble, I'd advise you to do that instead :)
I'd love to, but it seems that displays won't let me :-D
It might be helpful to pre-filter the allowed display modes to only
offer those which can be derived from the currently available PLL
frequencies. The problem is that it makes an extremely limited subset
on real-world displays.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-22 8:36 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <aeeMp1XBDxSZ1qrl@monoceros>
Hi Uwe,
On 16:50 Tue 21 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
> On Mon, Apr 20, 2026 at 06:27:45PM +0200, Andrea della Porta wrote:
> > On 12:50 Fri 17 Apr , Uwe Kleine-König wrote:
> > > What happens if sync is asserted while a disabled channel didn't
> > > complete the last period yet?
> >
> > The output stops immediately without waiting for the current period to finish.
>
> This is a good info for the Limitations block.
Yup, already added, plus a couple other edge cases.
>
> > > Maybe it's worth to test the following procedure for updating duty and
> > > period:
> > >
> > > disable channel
> > > configure duty
> > > configure period
> > > enable
> > > set update flag
> > >
> > > Assumint disable is delayed until the end of the currently running
> > > period, the effect of this procedure might be that no glitch happens if
> > > the update flag is asserted before the currently running period ends and
> > > the anormality is reduced to a longer inactive state if the updates are
> > > not that lucky (in contrast to more severe glitches).
> >
> > The disable isn't delayed as explained above. Setting just the new period/duty
> > (which do not depend on the sync bit) correctly waits for the end of the current
> > period without noticeable glitches (tested with a scope).
>
> So if you happen to change both and one is done before the end of the
> current period and the other shortly afterwards (which might happen as
> those are configured in two different registers and the update trigger
> isn't used), you get a mixed output for one cycle, right? If yes, please
> also mention that in the Limitations paragraph.
Confirmed, tested with the scope and a very long period time.
>
> > > > Let's say that teh user want 10 tick period, we have to use
> > > > 9 instead to account for the extra tick at the end, so that the complete period
> > > > contains that extra tick?
> > >
> > > I would describe that a bit differently, but in general: yes.
> > >
> > > The more straight forward description is that setting
> > >
> > > RP1_PWM_RANGE(pwm->hwpwm) := x
> > >
> > > results in a period of x + 1 ticks.
> >
> > Exactly. So whatever the user request I have to subtract one from the value
> > to be written to the RANGE register.
>
> Unless the calculation is already rounded to 0, in that case don't
> subtract 1 and let the tohw callback return 1.
Sure.
>
> > > > This also means that if we ask for 100% duty cycle, the output waveform will
> > > > have the high part of the signal lasting one tick less than expected.a I guess
> > > > this is the accepted compromise.
> > >
> > > I assume you considered something like:
> > >
> > > RP1_PWM_RANGE(pwm->hwpwm) := 17
> > > RP1_PWM_DUTY(pwm->hwpwm) := 18
> > >
> > > to get a 100% relative duty?
> >
> > Ah right! It's working fine and I've got 100% duty. So at hw register level
> > the duty can be greater that the period.
>
> In that case please make sure to not use the maximal value for
> RP1_PWM_RANGE(pwm->hwpwm) to ensure that for each (possible) period
> length a 100% relative duty cycle can be configured.
Ack.
>
> > > My (not so well articulated) point is: Please be stringent about clock
> > > handling to not bank up technical dept more than necessary and such that
> > > the driver can be made unbindable if and when syscons grow
> > > that feature. Optionally wail at the syscon guys :-)
> >
> > Hmmm not sure I've understood your point: is it a requirement that the driver
> > must be unbindable? In this case I should avoid registering the syscon. Or
> > should I just provide a .remove callback in case there will be a way to
> > unregister the syscon (even if this callback will not be called as of now)?
>
> It's a requirement to properly manage the resources you allocate. If a
> driver isn't unbindable due to restrictions of other subsystems that's
> unfortunate and I don't like it, but I wouldn't block a patch because of
> that.
I totally agree, of course. From a practical perspective I take it as "even
if it's not ideal, you don't need to do further coding action on that side".
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: qcom:: Fix Hawi compatible placement
From: Mukesh Ojha @ 2026-04-22 8:33 UTC (permalink / raw)
To: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy, Mukesh Ojha
Cc: Robin Murphy, Krzysztof Kozlowski, linux-arm-kernel, iommu,
devicetree, linux-kernel
qcom,hawi-smmu-500 was placed in the wrong enum block of GPU. Move it to
the correct location alongside other Qualcomm SMMU-500 compatibles for
CPU.
Fixes: 5e8323c3d528 ("dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC")
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..ba9ad1f5a8ff 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -37,6 +37,7 @@ properties:
- enum:
- qcom,eliza-smmu-500
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
@@ -93,7 +94,6 @@ properties:
items:
- enum:
- qcom,glymur-smmu-500
- - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: i.MX8M Plus PCIe link regression
From: Thorsten Leemhuis @ 2026-04-22 8:39 UTC (permalink / raw)
To: Alexander Stein, Hongxing Zhu, Manivannan Sadhasivam
Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, Linux kernel regressions list
In-Reply-To: <6102060.LvFx2qVVIh@steina-w>
Lo! What happened to this regression? It looks like it was never
resolved. Is that something everybody can live with in some way? Or
something we have to live with, as reverting the culprit at this point
would create a regression and thus creates even more trouble then it solves?
Ciao, Thorsten
On 3/4/26 09:47, Alexander Stein wrote:
>
> Am Mittwoch, 4. März 2026, 07:32:48 CET schrieb Manivannan Sadhasivam:
>> On Wed, Mar 04, 2026 at 02:55:51AM +0000, Hongxing Zhu wrote:
>>>> -----Original Message-----
>>>> From: Manivannan Sadhasivam <mani@kernel.org>
>>>> Sent: 2026年3月4日 0:42
>>>> To: Hongxing Zhu <hongxing.zhu@nxp.com>; Alexander Stein
>>>> <alexander.stein@ew.tq-group.com>
>>>> Cc: linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
>>>> imx@lists.linux.dev
>>>> Subject: Re: i.MX8M Plus PCIe link regression
>>>>
>>>> On Tue, Mar 03, 2026 at 01:38:13PM +0100, Alexander Stein wrote:
>>>>> Hi,
>>>>>
>>>>> these days I noticed that there is a PCIe link regression on my
>>>>> i.MX8MP platform (TQMa8MPxL) running next-20260227.
>>>>> I could bisect it back to commit 9c03e30e3ade3 ("PCI: imx6: Skip link
>>>>> up workaround for newer platforms"). I always get the following errors:
>>>>>
>>>>> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM:
>>>>> CFG_LINKWD_START imx6q-pcie 33800000.pcie: probe with driver
>>>>> imx6q-pcie failed with error -110
>>>>>
>>>>> Connected is a Gen1 PCIe -> Ethernet adapter. Interestingly a Gen2
>>>>> device is detected without issues.
>>>>>
>>>>> Reverting 3c96a61dd2e098dda8dcac3dce3d38a3c87afbfc and
>>>>> b9a8d28ebbf118bb3eac953f4a37abbd341257ab "fixes" my platform, both
>>>> Gen
>>>>> 1 and Gen 2 devices are detect. Commit
>>>>> 3c96a61dd2e098dda8dcac3dce3d38a3c87afbfc is only required for conflict
>>>> free revert.
>>>>>
>>>>> Here is a summary with outputs:
>>>>> Gen 1 device
>>>>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>>>> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>>>>>> RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev
>>>>>> 01)
>>>>>
>>>>> Gen 2 device
>>>>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>>>> 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9128 PCIe
>>>>>> SATA 6 Gb/s RAID controller (rev 20)
>>>>>
>>>>> output of "dmesg | grep imx6q-pcie". Common part for all tests:
>>>>>> imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
>>>>>> imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff ->
>>>>>> 0x0000000000
>>>>>> imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff ->
>>>>>> 0x0018000000
>>>>>> imx6q-pcie 33800000.pcie: config reg[1] 0x1ff00000 == cpu 0x1ff00000
>>>>>> imx6q-pcie 33800000.pcie: iATU: unroll T, 4 ob, 4 ib, align 64K,
>>>>>> limit 16G
>>>>>
>>>>> next-20260227
>>>>> Gen 1
>>>>>> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM:
>>>>>> CFG_LINKWD_START imx6q-pcie 33800000.pcie: probe with driver
>>>>>> imx6q-pcie failed with error -110
>>>>>
>>>>> Gen 2
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCI host bridge to bus 0000:00
>>>>>
>>>>> next-20260227 + reverts
>>>>> Gen 1
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie 33800000.pcie: PCI
>>>>>> host bridge to bus 0000:00
>>>>>
>>>>> Gen 2
>>>>>> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up imx6q-pcie
>>>>>> 33800000.pcie: PCIe Gen.2 x1 link up imx6q-pcie 33800000.pcie: PCI
>>>>>> host bridge to bus 0000:00
>>>>>
>>>>> What can we do here? I'm wondering why Gen 2 trains correctly, while
>>>>> Gen 1 doesn't.
>>>>>
>>>>
>>>> Thanks for the report and sorry for the breakage. Commit 9c03e30e3ade3,
>>>> mentions that the workaround is only needed for the i.MX6 platforms. So
>>>> I'm not sure why the patch breaks i.MX8M and that too only for Gen 1
>>>> speed.
>>>>
>>>> Also, before 9c03e30e3ade3, LTSSM was always started in Gen 1, but as per
>>>> your finding, only Gen 1 devices fail to work. So the code till
>>>> imx_pcie_wait_for_speed_change() shouldn't have an impact. Maybe the
>>>> issue is due to skipping imx_pcie_wait_for_speed_change()?
>>>>
>>>> Richard, thoughts?
>>> Hi Maini:
>>> Prior to calling imx_pcie_wait_for_speed_change(), the PCIe link must
>>> already be established. Before commit 9c03e30e3ade3, the speed change
>>> procedure was only initiated after the initial Gen1 link was successfully
>>> brought up.
>>>
>>> Hi Alexander:
>>> Sorry for the breakage.
>>> Before commit 9c03e30e3ade3, i.MX8MP PCIe forced Gen1 link training
>>> initially, then switched to Gen3 after link-up by triggering a speed
>>> change. After commit 9c03e30e3ade3, link training starts directly at
>>> the Gen3 capability level.
>>>
>>> The two link training methods differ only in the i.MX8MP Root Complex (RC)
>>> link capability configuration prior to link training: one method forces
>>> Gen1 speed, while the other retains the default Gen3 setting in your tests.
>>>
>>
>> I still don't understand why the link fails to train at Gen 1.
>
> Independently from the configured maximum link speed, shouldn't the initial
> link be Gen1 anyway and upgraded to Gen 2 later on?
>
> I added some debug output to dw_pcie_link_up()
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 3
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f704
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f722
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM: CFG_LINKWD_START
> imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
>
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 2
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x28000000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x2800f702
> imx6q-pcie 33800000.pcie: Link failed to come up. LTSSM: CFG_LINKWD_START
> imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
>
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 1
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08000010
> imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up
> imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
>
> So for any maximum speed above Gen1 it seems that LTSSM is stuck at link
> training.
> Unfortunately only link training and link up bits are defined and RM doesn't
> show anything, so I don't know what the other bits are indicating.
>
> For a Gen2 device the link training succeeds right away.
>
> imx6q-pcie 33800000.pcie: dw_pcie_link_set_max_speed: current pci->max_link_speed: 2
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08200000
> imx6q-pcie 33800000.pcie: dw_pcie_link_up: PCIE_PORT_DEBUG1: 0x08000010
> imx6q-pcie 33800000.pcie: PCIe Gen.2 x1 link up
> imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
>
> Best regards,
> Alexander
^ permalink raw reply
* Re: [PATCH] net/stmmac: Fix typos: 'tx_undeflow_irq' -> 'tx_underflow_irq'
From: Jakub Raczynski @ 2026-04-22 8:42 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kuba, davem, andrew+netdev, kernel-janitors,
linux-arm-kernel, linux-stm32
In-Reply-To: <7eb9e4d4-909c-4203-833d-bd8b664fdfbc@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 963 bytes --]
On Tue, Apr 21, 2026 at 02:39:15PM +0200, Andrew Lunn wrote:
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> > @@ -78,7 +78,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
> > STMMAC_STAT(rx_vlan),
> > STMMAC_STAT(rx_split_hdr_pkt_n),
> > /* Tx/Rx IRQ error info */
> > - STMMAC_STAT(tx_undeflow_irq),
> > + STMMAC_STAT(tx_underflow_irq),
>
> Please take another look at this one and think about it.
>
> Andrew
>
> ---
> pw-bot: cr
>
I don't see anything wrong with it?
- naming is correct, same as stmmac_extra_stats from common.h, as it
wouldn't compile otherwise
- string length is ok, as max name length is ETH_GSTRING_LEN=32 and it is
not close
- ethtool just polls data from driver and in my tests it is ok
- all instances of 'undeflow' are changed
- 'underflow' semantic is ok, 'undeflow' is just not correct
Please correct me if I am wrong, but imo no issues with this patch.
Regards
Jakub Raczynski
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: New warning in linus/master
From: Thomas Weißschuh @ 2026-04-22 8:45 UTC (permalink / raw)
To: Ricardo Ribalda; +Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <CANiDSCtfiPDiqzhjZGoCJbLC0fRoH1HLKrvYUt7jLDYEBQHqgg@mail.gmail.com>
On Wed, Apr 22, 2026 at 04:06:45PM +0800, Ricardo Ribalda wrote:
> On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
> <thomas.weissschuh@linutronix.de> wrote:
> >
> > On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
> > > On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
> > > <thomas.weissschuh@linutronix.de> wrote:
> > > > On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
> > > > > Media-CI has found a couple of new warnings in the latest kernel
> > > > > version for aarch64 and powerpc. They get fixed with this patch and
> > > > > before moving I wanted to know if this was under your radar.
> > > >
> > > > Thanks for the report. I was not aware of these so far.
> > > >
> > > > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > > > index 7dec05dd33b7..65914842fae0 100644
> > > > > --- a/arch/arm64/kernel/vdso/Makefile
> > > > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > > > @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
> > > > > CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
> > > > >
> > > > > ifneq ($(c-gettimeofday-y),)
> > > > > - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > > + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
> > > > > -Wno-maybe-uninitialized
> > > > > endif
> > > >
> > > > (...)
> > > >
> > > > I'd like to know exactly what is going on before suppressing the warning.
> > > > It is a non-standard warning, only enabled by *some* of the vDSO builds
> > > > for some reason.
> > > >
> > > > > https://gitlab.freedesktop.org/linux-media/users/ribalda/-/pipelines/1649144/test_report?job_name=cross-gcc
> > > >
> > > > While I was able to download a configuration from this job and also use the
> > > > same container image, I can not reproduce the issue. Is the configuration the
> > > > full one or only the template?
> > > >
> > > > Could you provide full reproduction steps?
> > >
> > > You can try repro with:
> > >
> > > work/linux $ podman run -v .:/workdir/ --rm -it
> > > registry.freedesktop.org/linux-media/media-ci/build:latest
> > > $ cd /workdir
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > > arch/arm64/kernel/vdso/vgettimeofday.o
> > >
> > > The gcc version discrepancy is because I the error was due to old gcc
> > > version and I was playing around with that... but it fails in both
> > > gcc14 and gcc15
> >
> > Ack.
> >
> > > You can try with debian testing with
> > > work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
> > > $ apt-get update
> > > $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
> > > $ cd /workdir
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
> > > $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> > > arch/arm64/kernel/vdso/vgettimeofday.o
> >
> > Both reproducers do *not* reproduce the issue for me.
> > (It is more or less exactly what I tried before)
>
>
> Ok, I think I found what is going on. media-ci was forcing
> KCFLAGS=-Wmaybe-uninitialized
>
> https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-build.sh?ref_type=heads#L29
>
> And something has changed in the kernel in the last version that
> triggers a (hopefully) false positive.
>
> can you try with:
>
> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> KCFLAGS=-Wmaybe-uninitialized allyesconfig
> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
> KCFLAGS=-Wmaybe-uninitialized prepare
That works!
The warning was introduced in ed78b7b2c5ae ("vdso/gettimeofday: Add a helper to
read the sequence lock of a time namespace aware clock").
It is *not* a false-positive, specifically:
do {
if (vdso_read_begin_timens(vc, &seq)) {
vd = __arch_get_vdso_u_timens_data(vd);
vc = &vd->aux_clock_data[idx];
/* Re-read from the real time data page */
continue;
This 'continue' jumps to the end of the loop body and if the real vDSO datapage
by chance has a sequence counter of '1' will exit the loop, leaving 'sec' and
'nsec' uninitialized. My believe was that the 'continue' would jump to the
*beginning* of the loop body, which is cleary wrong. Previously there was an
inner while loop() which would make the 'continue' effectively start at the
beginning of the outer do-while loop.
}
/* Auxclock disabled? */
if (vc->clock_mode == VDSO_CLOCKMODE_NONE)
return false;
if (!vdso_get_timestamp(vd, vc, VDSO_BASE_AUX, &sec, &ns))
return false;
} while (vdso_read_retry(vc, seq));
vdso_set_timespec(ts, sec, ns);
I'm working on a fix.
Thomas
^ permalink raw reply
* Re: [PATCH 0/3] arm64/virt: Add Arm CCA measurement register support
From: Sami Mujawar @ 2026-04-22 8:57 UTC (permalink / raw)
To: Jason Gunthorpe, Suzuki Poulose
Cc: Dan Williams, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Catalin Marinas, will@kernel.org,
thuth@redhat.com, Steven Price, gshan@redhat.com, Yeoreum Yun,
cedric.xing@intel.com, Dan Williams, Dionna Glaze,
Aneesh Kumar K . V, Alexey Kardashevskiy,
linux-coco@lists.linux.dev
In-Reply-To: <20260414133525.GA2577880@ziepe.ca>
Hi Jason,
> On Tue, Apr 14, 2026 at 02:26:58PM +0100, Suzuki K Poulose wrote:
> > On 14/04/2026 13:29, Jason Gunthorpe wrote:
> > > On Tue, Apr 14, 2026 at 11:10:51AM +0100, Suzuki K Poulose wrote:
> > >
> > > > > Isn't this also sort of incomplete? Doesn't anything serious need
> > > > > signed measurements? Isnt't there alot more data that comes out of RMM
> > > > > than just a few measurement registers?
> > > > As mentioned above, this series adds the support for Runtime Extendible
> > > > Measurements (REM in CCA, RTMR on TDX). The RIM+Platform Attestation is
> > > > already provided via the TSM_REPORT
> > >
> > > Okay, but what actual use is this?
> > >
> >
> > Good point. This REMs are planned to be used for EFI_CC_MEASUREMENT_PROTOCOL
> > as described below:
> >
> > https://github.com/tianocore/edk2/issues/11383
>
> So this is tying it to the same FW event log that TPM uses.
>
> I think that strengthens my point this should all be uninform. TPM
> drivers are directly exposing the event log today, but I guess that
> needs generalization if non-TPM drivers are going to present it as
> well.
>
> How do you imagine getting and manipulating the EFI event log to use
> with this?
The event logs from UEFI will be handed off to the OS using CCEL ACPI table. The CCEL table spec update can be seen at https://github.com/tianocore/edk2/issues/11384
Regards,
Sami Mujawar
> Jason
>
^ permalink raw reply
* Re: New warning in linus/master
From: Christophe Leroy (CS GROUP) @ 2026-04-22 9:09 UTC (permalink / raw)
To: Thomas Weißschuh, Ricardo Ribalda
Cc: linux-arm-kernel, Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <20260422103218-1efdbb73-51fa-48c9-ae92-75306147d61f@linutronix.de>
Le 22/04/2026 à 10:45, Thomas Weißschuh a écrit :
> On Wed, Apr 22, 2026 at 04:06:45PM +0800, Ricardo Ribalda wrote:
>> On Wed, 22 Apr 2026 at 15:32, Thomas Weißschuh
>> <thomas.weissschuh@linutronix.de> wrote:
>>>
>>> On Wed, Apr 22, 2026 at 03:00:11PM +0800, Ricardo Ribalda wrote:
>>>> On Wed, 22 Apr 2026 at 13:57, Thomas Weißschuh
>>>> <thomas.weissschuh@linutronix.de> wrote:
>>>>> On Wed, Apr 22, 2026 at 11:51:45AM +0800, Ricardo Ribalda wrote:
>>>>>> Media-CI has found a couple of new warnings in the latest kernel
>>>>>> version for aarch64 and powerpc. They get fixed with this patch and
>>>>>> before moving I wanted to know if this was under your radar.
>>>>>
>>>>> Thanks for the report. I was not aware of these so far.
>>>>>
>>>>>> diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
>>>>>> index 7dec05dd33b7..65914842fae0 100644
>>>>>> --- a/arch/arm64/kernel/vdso/Makefile
>>>>>> +++ b/arch/arm64/kernel/vdso/Makefile
>>>>>> @@ -50,7 +50,7 @@ CFLAGS_vgettimeofday.o = $(CC_FLAGS_ADD_VDSO)
>>>>>> CFLAGS_vgetrandom.o = $(CC_FLAGS_ADD_VDSO)
>>>>>>
>>>>>> ifneq ($(c-gettimeofday-y),)
>>>>>> - CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
>>>>>> + CFLAGS_vgettimeofday.o += -include $(c-gettimeofday-y)
>>>>>> -Wno-maybe-uninitialized
>>>>>> endif
>>>>>
>>>>> (...)
>>>>>
>>>>> I'd like to know exactly what is going on before suppressing the warning.
>>>>> It is a non-standard warning, only enabled by *some* of the vDSO builds
>>>>> for some reason.
>>>>>
>>>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fusers%2Fribalda%2F-%2Fpipelines%2F1649144%2Ftest_report%3Fjob_name%3Dcross-gcc&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7cbf9009269d4ddc16d208dea04b86f1%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124443421115079%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O4r8HjaUn7KEgW8tDE9GEC9e8CWyJBpCfhVTJZZ%2BFHs%3D&reserved=0
>>>>>
>>>>> While I was able to download a configuration from this job and also use the
>>>>> same container image, I can not reproduce the issue. Is the configuration the
>>>>> full one or only the template?
>>>>>
>>>>> Could you provide full reproduction steps?
>>>>
>>>> You can try repro with:
>>>>
>>>> work/linux $ podman run -v .:/workdir/ --rm -it
>>>> registry.freedesktop.org/linux-media/media-ci/build:latest
>>>> $ cd /workdir
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>>>> arch/arm64/kernel/vdso/vgettimeofday.o
>>>>
>>>> The gcc version discrepancy is because I the error was due to old gcc
>>>> version and I was playing around with that... but it fails in both
>>>> gcc14 and gcc15
>>>
>>> Ack.
>>>
>>>> You can try with debian testing with
>>>> work/linux$ podman run -v .:/workdir/ --rm -it debian:testing
>>>> $ apt-get update
>>>> $ apt-get install gcc-aarch64-linux-gnu build-essential flex bison libssl-dev bc
>>>> $ cd /workdir
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make allyesconfig
>>>> $ CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>>>> arch/arm64/kernel/vdso/vgettimeofday.o
>>>
>>> Both reproducers do *not* reproduce the issue for me.
>>> (It is more or less exactly what I tried before)
>>
>>
>> Ok, I think I found what is going on. media-ci was forcing
>> KCFLAGS=-Wmaybe-uninitialized
>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Flinux-media%2Fmedia-ci%2F-%2Fblob%2Fmain%2Ftest-build.sh%3Fref_type%3Dheads%23L29&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7cbf9009269d4ddc16d208dea04b86f1%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639124443421146576%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FpTHYfCn5ob42%2Fm6FVOZ32PVzuXBNBT3rlMVWslCfhw%3D&reserved=0
>>
>> And something has changed in the kernel in the last version that
>> triggers a (hopefully) false positive.
>>
>> can you try with:
>>
>> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>> KCFLAGS=-Wmaybe-uninitialized allyesconfig
>> CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 make
>> KCFLAGS=-Wmaybe-uninitialized prepare
>
> That works!
>
> The warning was introduced in ed78b7b2c5ae ("vdso/gettimeofday: Add a helper to
> read the sequence lock of a time namespace aware clock").
>
> It is *not* a false-positive, specifically:
>
> do {
> if (vdso_read_begin_timens(vc, &seq)) {
> vd = __arch_get_vdso_u_timens_data(vd);
> vc = &vd->aux_clock_data[idx];
> /* Re-read from the real time data page */
> continue;
>
> This 'continue' jumps to the end of the loop body and if the real vDSO datapage
> by chance has a sequence counter of '1' will exit the loop, leaving 'sec' and
> 'nsec' uninitialized. My believe was that the 'continue' would jump to the
> *beginning* of the loop body, which is cleary wrong. Previously there was an
> inner while loop() which would make the 'continue' effectively start at the
> beginning of the outer do-while loop.
Well spotted. I missed it too while reviewing.
A 'retry:' label at the begining of the loop with a 'goto retry' instead
of the 'continue' should make it.
Christophe
>
> }
>
> /* Auxclock disabled? */
> if (vc->clock_mode == VDSO_CLOCKMODE_NONE)
> return false;
>
> if (!vdso_get_timestamp(vd, vc, VDSO_BASE_AUX, &sec, &ns))
> return false;
>
> } while (vdso_read_retry(vc, seq));
>
> vdso_set_timespec(ts, sec, ns);
>
>
> I'm working on a fix.
>
>
> Thomas
>
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Leo Jiang @ 2026-04-22 9:13 UTC (permalink / raw)
To: Will Deacon, Robin Murphy; +Cc: joro, iommu, linux-arm-kernel
In-Reply-To: <aeeoEHHNKPo32H9R@willie-the-truck>
On Tue, Apr 21, 2026 at 05:38:40PM +0100, Will Deacon wrote:
> On Tue, Apr 21, 2026 at 04:56:47PM +0100, Robin Murphy wrote:
> > On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> > > From: LoserJL <leo.jiang1224@foxmail.com>
> > >
> > > In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> > > dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> > > allocates at least PAGE_SIZE, retrying with a smaller size after
> > > a PAGE_SIZE failure is logically redundant.
> >
> > Says who? It's certainly not a guarantee offered by the DMA API itself, and
> > indeed some allocation paths can definitely still allocate less than a page
> > - e.g. anything which hits a per-device or global coherent pool.
> >
> > > Moreover, if a sub-page retry were to succeed due to concurrent memory
> > > release, the hardware would be configured with a smaller queue depth
> > > despite a full page being allocated. This leads to inefficient memory
> > > usage and unnecessary hardware performance limitation.
> > >
> > > Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> > > consistency and optimal hardware configuration.
> >
> > That's really not an argument - even if an allocator does happen to
> > over-allocate for the requested size, that is hardly the caller's concern;
> > and as far as "optimal" queue sizes go in this case, those very much depend
> > on the number of CPUs issuing commands and volume of expected stall/PRI
> > events - in many cases PAGE_SIZE would already be far too small to really
> > work well.
> >
> > Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller
> > queue, there would be very little chance of the subsequent allocation(s) for
> > the stream table succeeding, so realistically the driver is probably going
> > to end up failing to probe in such circumstances anyway.
>
> That's all true, but tbf I think I just fscked up the comparison in
> d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") so
> I'm not against fixing that up even though the "rationale" given by
> Loser doesn't make a whole lot of sense.
Hi Will, Robin,
Thank you both for the detailed feedback.
Robin, you are absolutely correct. After a deeper look into the source code,
I see that allocations smaller than a page are indeed possible in certain
cases. My previous assumption about the DMA API's granularity was wrong,
and I appreciate the correction.
However, as Will noted that the current logic deviates from the original
intent, I have prepared a v2 to limit the queue allocation retry boundary
to PAGE_SIZE.
In v2, I have:
- Updated my identity to Leo Jiang.
- Removed the code comments as suggested.
I will send the v2 as a follow-up shortly.
Best regards,
Leo Jiang
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: qcom:: Fix Hawi compatible placement
From: Krzysztof Kozlowski @ 2026-04-22 9:04 UTC (permalink / raw)
To: Mukesh Ojha, Will Deacon, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robin Murphy
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel
In-Reply-To: <20260422083329.885979-1-mukesh.ojha@oss.qualcomm.com>
On 22/04/2026 10:33, Mukesh Ojha wrote:
> qcom,hawi-smmu-500 was placed in the wrong enum block of GPU. Move it to
> the correct location alongside other Qualcomm SMMU-500 compatibles for
> CPU.
How could it pass dtbs_check?
>
> Fixes: 5e8323c3d528 ("dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC")
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 06fb5c8e7547..ba9ad1f5a8ff 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -37,6 +37,7 @@ properties:
> - enum:
> - qcom,eliza-smmu-500
> - qcom,glymur-smmu-500
> + - qcom,hawi-smmu-500
> - qcom,kaanapali-smmu-500
> - qcom,milos-smmu-500
> - qcom,qcm2290-smmu-500
> @@ -93,7 +94,6 @@ properties:
> items:
> - enum:
> - qcom,glymur-smmu-500
> - - qcom,hawi-smmu-500
No, why? That's for GPU. Why are you moving GPU compatible to non-GPU place?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] iommu/arm-smmu-v3: Limit queue allocation retry boundary to PAGE_SIZE
From: Leo Jiang @ 2026-04-22 9:28 UTC (permalink / raw)
To: Will Deacon
Cc: Robin Murphy, Joerg Roedel, iommu, linux-arm-kernel, Leo Jiang
In-Reply-To: <tencent_DA99B62735469A0CD219E9FC73E234A47309@qq.com>
In arm_smmu_init_one_queue(), the driver attempts to allocate the largest
supported queue and retries by halving the size on failure. Currently,
the retry logic allows the allocation to fall below PAGE_SIZE if the
PAGE_SIZE attempt fails.
While dmam_alloc_coherent() can theoretically return allocations smaller
than a page in certain configurations, it is preferable to limit the
retry boundary to PAGE_SIZE for SMMUv3 queues to align with the
original design intent.
This patch ensures the retry loop terminates when qsz reaches PAGE_SIZE,
per the feedback from the maintainer.
Signed-off-by: Leo Jiang <leo.jiang1224@foxmail.com>
---
v2:
- Use real name "Leo Jiang".
- Remove code comments as suggested by Will.
- Limit the queue allocation retry boundary to PAGE_SIZE
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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..4a0b15b1d4d2 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4418,7 +4418,7 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
GFP_KERNEL);
- if (q->base || qsz < PAGE_SIZE)
+ if (q->base || qsz <= PAGE_SIZE)
break;
q->llq.max_n_shift--;
--
2.34.1
^ permalink raw reply related
* [PATCH V14 00/12] pci-imx6: Add support for parsing the reset property in new Root Port binding
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
This patch set adds support for parsing the reset property in new Root Port
binding in pci-imx6 driver, similar to the implementation in the qcom pcie
driver[1].
Also introduce generic helper functions to parse Root Port device tree
nodes and extract common properties like reset GPIOs. This allows multiple
PCI host controller drivers to share the same parsing logic.
Define struct pci_host_port to hold common Root Port properties
(currently only reset GPIO descriptor) and add
pci_host_common_parse_ports() to parse Root Port nodes from device tree.
Also add the 'ports' list to struct pci_host_bridge for better maintain
parsed Root Port information.
The plan is to add the wake-gpio property to the root port in subsequent
patches. Also, the vpcie-supply property will be moved to the root port
node later based on the refactoring patch set for the PCI pwrctrl
framework[2].
The initial idea is to adopt the Manivannan’s recent PCIe M.2 KeyE
connector support patch set[3] and PCI power control framework patches[2],
and extend them to the pcie-imx6 driver. Since the new M.2/pwrctrl model is
implemented based on Root Ports and requires the pwrctrl driver to bind to
a Root Port device, we need to introduce a Root Port child node on i.MX
boards that provide an M.2 connector.
To follow a more standardized DT structure, it also makes sense to move
the reset-gpios and wake-gpios properties into the Root Port node. These
signals logically belong to the Root Port rather than the host bridge,
and placing them there aligns with the new M.2/pwrctrl model.
Regarding backward compatibility, as Frank suggested, I will not remove
the old reset-gpio property from existing DTS files to avoid function
break.
For new i.MX platforms — such as the upcoming i.MX952-evk will add
vpcie-supply, reset-gpios, and wake-gpios directly under the Root Port
node.
Therefore, driver updates are needed to support both the legacy
properties and the new standardized Root Port based layout.
[1] https://lore.kernel.org/linux-pci/20250702-perst-v5-0-920b3d1f6ee1@qti.qualcomm.com/
[2] https://lore.kernel.org/linux-pci/20260115-pci-pwrctrl-rework-v5-0-9d26da3ce903@oss.qualcomm.com/
[3] https://lore.kernel.org/linux-pci/20260112-pci-m2-e-v4-0-eff84d2c6d26@oss.qualcomm.com/
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
Changes in V14:
1. Add pci_host_common_parse_perst() helper to parse PERST# from all PCIe bridge
nodes starting from the Root Port node.
2. Corresponding changes in patch#2 and patch#4 for the parsing PERST# logic.
Changes in V13:
1. Use of_property_present() instead of of_property_read_bool() in patch#2 as
reviewed by sashiko.
2. Add reset Null check in imx_pcie_parse_legacy_binding() to avoid
unconditional deassert delays on boards without reset GPIO as reviewed by
sashiko.
3. Delete the pcie@0,0 port defined in imx6q-utilite-pro.dts and use the new
pcie_port0 label in imx6qdl.dtsi to avoid to defining the conflicting node as
reviewed by sashiko.
Changes in V12:
1. Improve the pci_host_common_parse_port() to correctly handle three scenarios:
PERST# found in Root Port node & PERST# not in Root Port but found in RC node
& PERST# not found in either node.
2. Add documentation noting for pci_host_common_parse_port().
3. Add err_cleanup handle path for pci_host_common_parse_ports() to clean up any
partially parsed Root Port resources.
4. Optimize imx_pcie_assert_perst() to avoid the linearly increasing deassertion
delay if controller has multiple Root Ports.
5. Use mdelay instead of msleep in imx_pcie_assert_perst() for noirq context
safety.
6. Remove early return in imx_pcie_parse_legacy_binding() when reset is NULL to
align with pci_host_common_parse_port(), allowing port creation even without
PERST# GPIO.
Changes in V11:
1. Call pci_host_common_parse_ports() API from pci-imx6 driver instead of dwc
common layer as Mani suggested.
2. Improve the commit message of patch#3 to avoid confusion as Mani suggested.
Changes in V10:
1. Use gpiod_direction_output() instead of gpiod_set_value_cansleep() to
ensure the reset GPIO is properly configured as output before setting
its value in patch#5 as now the reset GPIO is obtained with
GPIOD_ASIS flag.
Changes in V9:
1. Improve the error handling in pci_host_common_parse_ports() as Mani suggested.
2. Move the list_empty check and the comment to imx_pcie_host_init() to make it
clear that imx_pcie_parse_legacy_binding() is a fallback as Mani suggested.
3. Export pci_host_common_delete_ports() so that it can be called by
imx_pcie_parse_legacy_binding().
Changes in V8:
1. Add back the cleanup function pci_host_common_delete_ports() to properly
handles the ports list instead of simply using pci_free_resource_list().
2. Improve the patch#4 commit message.
3. Remove the irrelevant code change in patch#4.
Changes in V7:
1. Change to use GPIOD_ASIS when requesting perst gpio as Mani suggested.
using bridge->dev.
2. Add a seperate patch to move vpcie3v3aux regulator enable from probe to
imx_pcie_host_init() and move imx_pcie_assert_perst() before regulator and
clock enable for pci-imx6.
3. Add device pointer parameter for pci_host_common_parse_port() instead of
Changes in V6:
1. Drop the pre-allocate pci_host_bridge struct changes in dw_pcie_host_init()
and imx_pcie_probe().
2. Parse Root Port nodes in dw_pcie_host_init() as Frank and Mani suggested.
3. Move the imx_pcie_parse_legacy_binding() from imx_pcie_probe() to
imx_pcie_host_init(), so that dw_pcie_host_init() parse Root Port first, if
no Root Port nodes were parsed(indicated by empty ports list), then parse
legacy binding.
4. Add device pointer parameter for pci_host_common_parse_ports().
5. Add NULL pointer check for reset gpio in imx_pcie_parse_legacy_binding().
Changes in V5:
1. Add the Root Port list(pci_host_port) to struct pci_host_bridge for better
maintain parsed Root Port information.
2. Delete the pci_host_common_delete_ports() as now the Root Port list in
pci_host_bridge can be cleared by pci_release_host_bridge_dev().
3. Change the common API pci_host_common_parse_ports() pass down struct
pci_host_bridge *.
4. Modify dw_pcie_host_init() to allow drivers to pre-allocate pci_host_bridge
struct when needed.
5. Allocate bridge early in imx_pcie_probe() to parse Root Ports.
Changes in V4:
1. Add common helpers for parsing Root Port properties in pci-host-common.c in
patch#2.
2. Call common pci_host_common_parse_ports() and pci_host_common_delete_ports()
in pci-imx6 driver.
3. Use PCIE_T_PVPERL_MS and PCIE_RESET_CONFIG_WAIT_MS instead of magic number
100 in patch#3 as Manivannan suggested.
4. Use "PERST#" instead of "PCIe reset" for the reset gpio lable in patch#3.
Changes in V3:
1. Improve the patch#2 commit message as Frank suggested.
2. Add Reviewed-by tag for patch#1.
Changes in V2:
1. Improve the patch#1 commit message as Frank suggested.
2. Also mark the reset-gpio-active-high property as deprecated in
imx6q-pcie DT binding as Rob suggested.
3. The imx_pcie_delete_ports() has been moved up so that the
imx_pcie_parse_ports() can call this helper function in error handling.
4. Keep the old reset-gpio property in the host bridge node for the
existing dts files and add comments to avoid confusion.
---
Sherry Sun (12):
dt-bindings: PCI: fsl,imx6q-pcie: Add reset GPIO in Root Port node
PCI: host-generic: Add common helpers for parsing Root Port properties
PCI: imx6: Assert PERST# before enabling regulators
PCI: imx6: Add support for parsing the reset property in new Root Port
binding
arm: dts: imx6qdl: Add Root Port node and PERST property
arm: dts: imx6sx: Add Root Port node and PERST property
arm: dts: imx7d: Add Root Port node and PERST property
arm64: dts: imx8mm: Add Root Port node and PERST property
arm64: dts: imx8mp: Add Root Port node and PERST property
arm64: dts: imx8mq: Add Root Port node and PERST property
arm64: dts: imx8dxl/qm/qxp: Add Root Port node and PERST property
arm64: dts: imx95: Add Root Port node and PERST property
.../bindings/pci/fsl,imx6q-pcie.yaml | 32 ++++
.../boot/dts/nxp/imx/imx6q-utilite-pro.dts | 17 +-
.../arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi | 11 ++
.../arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 11 ++
arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx7d.dtsi | 11 ++
.../boot/dts/freescale/imx8-ss-hsio.dtsi | 11 ++
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 5 +
arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 5 +
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 11 ++
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 5 +
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 ++
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 10 ++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 22 +++
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 10 ++
.../boot/dts/freescale/imx8qm-ss-hsio.dtsi | 22 +++
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 5 +
.../boot/dts/freescale/imx95-15x15-evk.dts | 5 +
.../boot/dts/freescale/imx95-19x19-evk.dts | 10 ++
arch/arm64/boot/dts/freescale/imx95.dtsi | 22 +++
drivers/pci/controller/dwc/pci-imx6.c | 132 +++++++++++---
drivers/pci/controller/pci-host-common.c | 164 ++++++++++++++++++
drivers/pci/controller/pci-host-common.h | 28 +++
drivers/pci/probe.c | 1 +
include/linux/pci.h | 1 +
28 files changed, 546 insertions(+), 36 deletions(-)
--
2.37.1
^ permalink raw reply
* [PATCH V14 01/12] dt-bindings: PCI: fsl,imx6q-pcie: Add reset GPIO in Root Port node
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Update fsl,imx6q-pcie.yaml to include the standard reset-gpios property
for the Root Port node.
The reset-gpios property is already defined in pci-bus-common.yaml for
PERST#, so use it instead of the local reset-gpio property. Keep the
existing reset-gpio property in the bridge node for backward
compatibility, but mark it as deprecated.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/pci/fsl,imx6q-pcie.yaml | 32 +++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 9d1349855b42..e8b8131f5f23 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -66,16 +66,34 @@ properties:
- const: dma
reset-gpio:
+ deprecated: true
description: Should specify the GPIO for controlling the PCI bus device
reset signal. It's not polarity aware and defaults to active-low reset
sequence (L=reset state, H=operation state) (optional required).
+ This property is deprecated, instead of referencing this property from the
+ host bridge node, use the reset-gpios property from the root port node.
reset-gpio-active-high:
+ deprecated: true
description: If present then the reset sequence using the GPIO
specified in the "reset-gpio" property is reversed (H=reset state,
L=operation state) (optional required).
+ This property is deprecated along with the reset-gpio property above, use
+ the reset-gpios property from the root port node.
type: boolean
+ pcie@0:
+ description:
+ Describe the i.MX6 PCIe Root Port.
+ type: object
+ $ref: /schemas/pci/pci-pci-bridge.yaml#
+
+ properties:
+ reg:
+ maxItems: 1
+
+ unevaluatedProperties: false
+
required:
- compatible
- reg
@@ -236,6 +254,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/clock/imx6qdl-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pcie: pcie@1ffc000 {
@@ -262,5 +281,18 @@ examples:
<&clks IMX6QDL_CLK_LVDS1_GATE>,
<&clks IMX6QDL_CLK_PCIE_REF_125M>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
+
+ pcie_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ };
};
...
--
2.37.1
^ permalink raw reply related
* [PATCH V14 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
Introduce generic helper functions to parse Root Port device tree nodes
and extract common properties like reset GPIOs. This allows multiple
PCI host controller drivers to share the same parsing logic.
Define struct pci_host_port to hold common Root Port properties
(currently only list of PERST# GPIO descriptors) and add
pci_host_common_parse_ports() to parse Root Port nodes from device tree.
Also add the 'ports' list to struct pci_host_bridge for better maintain
parsed Root Port information.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
drivers/pci/controller/pci-host-common.c | 164 +++++++++++++++++++++++
drivers/pci/controller/pci-host-common.h | 28 ++++
drivers/pci/probe.c | 1 +
include/linux/pci.h | 1 +
4 files changed, 194 insertions(+)
diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c
index d6258c1cffe5..77905c728d0d 100644
--- a/drivers/pci/controller/pci-host-common.c
+++ b/drivers/pci/controller/pci-host-common.c
@@ -9,6 +9,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
+#include <linux/gpio/consumer.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
@@ -17,6 +18,169 @@
#include "pci-host-common.h"
+/**
+ * pci_host_common_delete_ports - Cleanup function for port list
+ * @data: Pointer to the port list head
+ */
+void pci_host_common_delete_ports(void *data)
+{
+ struct list_head *ports = data;
+ struct pci_host_perst *perst, *tmp_perst;
+ struct pci_host_port *port, *tmp_port;
+
+ list_for_each_entry_safe(port, tmp_port, ports, list) {
+ list_for_each_entry_safe(perst, tmp_perst, &port->perst, list)
+ list_del(&perst->list);
+ list_del(&port->list);
+ }
+}
+EXPORT_SYMBOL_GPL(pci_host_common_delete_ports);
+
+/**
+ * pci_host_common_parse_perst - Parse PERST# from all nodes in depth first manner
+ * @dev: Device pointer
+ * @port: PCI host port
+ * @np: Device tree node to start parsing from
+ *
+ * This function recursively parses PERST# GPIO from all PCIe bridge nodes
+ * starting from @np in a depth-first manner.
+ *
+ * Returns: 0 on success, negative error code on failure.
+ */
+static int pci_host_common_parse_perst(struct device *dev,
+ struct pci_host_port *port,
+ struct device_node *np)
+{
+ struct pci_host_perst *perst;
+ struct gpio_desc *reset;
+ int ret;
+
+ if (!of_property_present(np, "reset-gpios"))
+ goto parse_child_node;
+
+ reset = devm_fwnode_gpiod_get(dev, of_fwnode_handle(np), "reset",
+ GPIOD_ASIS, "PERST#");
+ if (IS_ERR(reset)) {
+ /*
+ * FIXME: GPIOLIB currently supports exclusive GPIO access only.
+ * Non exclusive access is broken. But shared PERST# requires
+ * non-exclusive access. So once GPIOLIB properly supports it,
+ * implement it here.
+ */
+ if (PTR_ERR(reset) == -EBUSY)
+ dev_err(dev, "Shared PERST# is not supported\n");
+
+ return PTR_ERR(reset);
+ }
+
+ perst = devm_kzalloc(dev, sizeof(*perst), GFP_KERNEL);
+ if (!perst)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&perst->list);
+ perst->desc = reset;
+ list_add_tail(&perst->list, &port->perst);
+
+parse_child_node:
+ for_each_available_child_of_node_scoped(np, child) {
+ ret = pci_host_common_parse_perst(dev, port, child);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * pci_host_common_parse_port - Parse a single Root Port node
+ * @dev: Device pointer
+ * @bridge: PCI host bridge
+ * @node: Device tree node of the Root Port
+ *
+ * This function parses Root Port properties from the device tree.
+ * Currently it only handles the PERST# GPIO (including PERST# GPIOs from
+ * all PCIe bridge nodes under this Root Port) which is optional.
+ *
+ * NOTE: This helper fetches resources (like PERST# GPIO) optionally.
+ * If a controller driver has a hard dependency on certain resources(PHY,
+ * clocks, regulators, etc.), those resources MUST be modeled correctly
+ * in the DT binding and validated in DTS. This helper cannot enforce such
+ * dependencies and the driver may fail to operate if required resources
+ * are missing.
+ *
+ * Returns: 0 on success, -ENODEV if PERST# found in RC node (legacy binding
+ * should be used), Other negative error codes on failure.
+ */
+static int pci_host_common_parse_port(struct device *dev,
+ struct pci_host_bridge *bridge,
+ struct device_node *node)
+{
+ struct pci_host_port *port;
+ int ret;
+
+ port = devm_kzalloc(dev, sizeof(*port), GFP_KERNEL);
+ if (!port)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&port->perst);
+
+ ret = pci_host_common_parse_perst(dev, port, node);
+ if (ret)
+ return ret;
+
+ /*
+ * 1. PERST# found in RP or its child nodes - list is not empty, continue
+ * 2. PERST# not found in RP/children, but found in RC node - return -ENODEV
+ * to fallback legacy binding
+ * 3. PERST# not found anywhere - list is empty, continue (optional PERST#)
+ */
+ if (list_empty(&port->perst)) {
+ if (of_property_present(dev->of_node, "reset-gpios") ||
+ of_property_present(dev->of_node, "reset-gpio"))
+ return -ENODEV;
+ }
+
+ INIT_LIST_HEAD(&port->list);
+ list_add_tail(&port->list, &bridge->ports);
+
+ return 0;
+}
+
+/**
+ * pci_host_common_parse_ports - Parse Root Port nodes from device tree
+ * @dev: Device pointer
+ * @bridge: PCI host bridge
+ *
+ * This function iterates through child nodes of the host bridge and parses
+ * Root Port properties (currently only reset GPIOs).
+ *
+ * Returns: 0 on success, -ENODEV if no ports found or PERST# found in RC node
+ * (legacy binding should be used), Other negative error codes on failure.
+ */
+int pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge *bridge)
+{
+ int ret = -ENODEV;
+
+ for_each_available_child_of_node_scoped(dev->of_node, of_port) {
+ if (!of_node_is_type(of_port, "pci"))
+ continue;
+ ret = pci_host_common_parse_port(dev, bridge, of_port);
+ if (ret)
+ goto err_cleanup;
+ }
+
+ if (ret)
+ return ret;
+
+ return devm_add_action_or_reset(dev, pci_host_common_delete_ports,
+ &bridge->ports);
+
+err_cleanup:
+ pci_host_common_delete_ports(&bridge->ports);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_host_common_parse_ports);
+
static void gen_pci_unmap_cfg(void *ptr)
{
pci_ecam_free((struct pci_config_window *)ptr);
diff --git a/drivers/pci/controller/pci-host-common.h b/drivers/pci/controller/pci-host-common.h
index b5075d4bd7eb..6b4e43e6ff22 100644
--- a/drivers/pci/controller/pci-host-common.h
+++ b/drivers/pci/controller/pci-host-common.h
@@ -12,6 +12,34 @@
struct pci_ecam_ops;
+/**
+ * struct pci_host_perst - PERST# GPIO descriptor
+ * @list: List node for linking multiple PERST# GPIOs
+ * @desc: GPIO descriptor for PERST# signal
+ *
+ * This structure holds a single PERST# GPIO descriptor.
+ */
+struct pci_host_perst {
+ struct list_head list;
+ struct gpio_desc *desc;
+};
+
+/**
+ * struct pci_host_port - Generic Root Port properties
+ * @list: List node for linking multiple ports
+ * @perst: List of PERST# GPIO descriptors for this port and its children
+ *
+ * This structure contains common properties that can be parsed from
+ * Root Port device tree nodes.
+ */
+struct pci_host_port {
+ struct list_head list;
+ struct list_head perst;
+};
+
+void pci_host_common_delete_ports(void *data);
+int pci_host_common_parse_ports(struct device *dev, struct pci_host_bridge *bridge);
+
int pci_host_common_probe(struct platform_device *pdev);
int pci_host_common_init(struct platform_device *pdev,
struct pci_host_bridge *bridge,
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b63cd0c310bc..6094b6c1fc90 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -660,6 +660,7 @@ static void pci_init_host_bridge(struct pci_host_bridge *bridge)
{
INIT_LIST_HEAD(&bridge->windows);
INIT_LIST_HEAD(&bridge->dma_ranges);
+ INIT_LIST_HEAD(&bridge->ports);
/*
* We assume we can manage these PCIe features. Some systems may
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..cb5f3e7e8e48 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -636,6 +636,7 @@ struct pci_host_bridge {
int domain_nr;
struct list_head windows; /* resource_entry */
struct list_head dma_ranges; /* dma ranges resource list */
+ struct list_head ports; /* Root Port list (pci_host_port) */
#ifdef CONFIG_PCI_IDE
u16 nr_ide_streams; /* Max streams possibly active in @ide_stream_ida */
struct ida ide_stream_ida;
--
2.37.1
^ permalink raw reply related
* [PATCH V14 03/12] PCI: imx6: Assert PERST# before enabling regulators
From: Sherry Sun @ 2026-04-22 9:35 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, mani, bhelgaas, hongxing.zhu, l.stach
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260422093549.407022-1-sherry.sun@nxp.com>
The PCIe endpoint may start responding or driving signals as soon as
its supply is enabled, even before the reference clock is stable.
Asserting PERST# before enabling the regulator ensures that the
endpoint remains in reset throughout the entire power-up sequence,
until both power and refclk are known to be stable and link
initialization can safely begin.
Currently, the driver enables the vpcie3v3aux regulator in
imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(),
which may cause PCIe endpoint undefined behavior during early
power-up. However, there is no issue so far because PERST# is
requested as GPIOD_OUT_HIGH in imx_pcie_probe(), which guarantees
that PERST# is asserted before enabling the vpcie3v3aux regulator.
This is prepare for the upcoming changes that will parse the reset
property using the new Root Port binding, which will use GPIOD_ASIS
when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not
guaranteed, so explicit sequencing is required.
Fix the power sequencing by:
1. Moving vpcie3v3aux regulator enable from probe to
imx_pcie_host_init(), where it can be properly sequenced with PERST#.
2. Moving imx_pcie_assert_perst() before regulator and clock enable to
ensure correct ordering.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 49 +++++++++++++++++++++------
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index e35044cc5218..735127ed1455 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -168,6 +168,8 @@ struct imx_pcie {
u32 tx_swing_full;
u32 tx_swing_low;
struct regulator *vpcie;
+ struct regulator *vpcie_aux;
+ bool vpcie_aux_enabled;
struct regulator *vph;
void __iomem *phy_base;
@@ -1222,6 +1224,13 @@ static void imx_pcie_disable_device(struct pci_host_bridge *bridge,
imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev));
}
+static void imx_pcie_vpcie_aux_disable(void *data)
+{
+ struct regulator *vpcie_aux = data;
+
+ regulator_disable(vpcie_aux);
+}
+
static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool assert)
{
if (assert) {
@@ -1242,6 +1251,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
struct imx_pcie *imx_pcie = to_imx_pcie(pci);
int ret;
+ imx_pcie_assert_perst(imx_pcie, true);
+
+ /* Keep 3.3Vaux supply enabled for the entire PCIe controller lifecycle */
+ if (imx_pcie->vpcie_aux && !imx_pcie->vpcie_aux_enabled) {
+ ret = regulator_enable(imx_pcie->vpcie_aux);
+ if (ret) {
+ dev_err(dev, "failed to enable vpcie_aux regulator: %d\n",
+ ret);
+ return ret;
+ }
+ imx_pcie->vpcie_aux_enabled = true;
+
+ ret = devm_add_action_or_reset(dev, imx_pcie_vpcie_aux_disable,
+ imx_pcie->vpcie_aux);
+ if (ret)
+ return ret;
+ }
+
if (imx_pcie->vpcie) {
ret = regulator_enable(imx_pcie->vpcie);
if (ret) {
@@ -1251,25 +1278,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
}
}
+ ret = imx_pcie_clk_enable(imx_pcie);
+ if (ret) {
+ dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
+ goto err_reg_disable;
+ }
+
if (pp->bridge && imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT)) {
pp->bridge->enable_device = imx_pcie_enable_device;
pp->bridge->disable_device = imx_pcie_disable_device;
}
imx_pcie_assert_core_reset(imx_pcie);
- imx_pcie_assert_perst(imx_pcie, true);
if (imx_pcie->drvdata->init_phy)
imx_pcie->drvdata->init_phy(imx_pcie);
imx_pcie_configure_type(imx_pcie);
- ret = imx_pcie_clk_enable(imx_pcie);
- if (ret) {
- dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
- goto err_reg_disable;
- }
-
if (imx_pcie->phy) {
ret = phy_init(imx_pcie->phy);
if (ret) {
@@ -1782,9 +1808,12 @@ static int imx_pcie_probe(struct platform_device *pdev)
of_property_read_u32(node, "fsl,max-link-speed", &pci->max_link_speed);
imx_pcie->supports_clkreq = of_property_read_bool(node, "supports-clkreq");
- ret = devm_regulator_get_enable_optional(&pdev->dev, "vpcie3v3aux");
- if (ret < 0 && ret != -ENODEV)
- return dev_err_probe(dev, ret, "failed to enable Vaux supply\n");
+ imx_pcie->vpcie_aux = devm_regulator_get_optional(&pdev->dev, "vpcie3v3aux");
+ if (IS_ERR(imx_pcie->vpcie_aux)) {
+ if (PTR_ERR(imx_pcie->vpcie_aux) != -ENODEV)
+ return PTR_ERR(imx_pcie->vpcie_aux);
+ imx_pcie->vpcie_aux = NULL;
+ }
imx_pcie->vpcie = devm_regulator_get_optional(&pdev->dev, "vpcie");
if (IS_ERR(imx_pcie->vpcie)) {
--
2.37.1
^ 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