* Re: [PATCH v4 6/9] arm64: dts: amlogic: t7: khadas-vim4: Add power regulators
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-6-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add voltage regulator nodes describing the VIM4 power tree,
> required by peripheral nodes such as the SD card controller.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 90 ++++++++++++++++++++++
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> index fffdab96b12eb..2450084d37642 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
> @@ -6,6 +6,8 @@
> /dts-v1/;
>
> #include "amlogic-t7.dtsi"
> +#include <dt-bindings/gpio/amlogic,t7-periphs-pinctrl.h>
> +#include <dt-bindings/gpio/gpio.h>
>
> / {
> model = "Khadas vim4";
> @@ -45,6 +47,94 @@ xtal: xtal-clk {
> #clock-cells = <0>;
> };
>
> + dc_in: regulator-dc-in {
> + compatible = "regulator-fixed";
> + regulator-name = "DC_IN";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + };
> +
> + sd_3v3: regulator-sdcard-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "SD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + gpio = <&gpio GPIOD_11 GPIO_ACTIVE_LOW>;
> + regulator-boot-on;
> + enable-active-low;
> + regulator-always-on;
> + };
> +
> + vcc5v: regulator-vcc-5v {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_in>;
> +
> + gpio = <&gpio GPIOH_4 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vcc5v0_usb: regulator-vcc-usb {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC5V0_USB";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v>;
> +
> + gpio = <&gpio GPIOY_5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + vddao_1v8: regulator-vddao-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddao_3v3: regulator-vddao-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&dc_in>;
> + regulator-always-on;
> + };
> +
> + vddio_1v8: regulator-vddio-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vddio_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_3v3: regulator-vddio-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddao_3v3>;
> + regulator-always-on;
> + };
> +
> + vddio_c: regulator-gpio-c {
> + compatible = "regulator-gpio";
> + regulator-name = "VDDIO_C";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vddio_3v3>;
> + gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
> + states = <1800000 1
> + 3300000 0>;
> + };
> };
>
> &uart_a {
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 5/9] arm64: dts: amlogic: t7: Add PWM controller nodes
From: Neil Armstrong @ 2026-03-26 8:53 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless, Nick Xie
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-5-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add device tree nodes for the seven PWM controllers available
> on the Amlogic T7 SoC, using amlogic,meson-s4-pwm as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Co-developed-by: Nick Xie <nick@khadas.com>
> Signed-off-by: Nick Xie <nick@khadas.com>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 63 +++++++++++++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index eb09a26bcd0e0..581cdaebfe637 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -511,6 +511,69 @@ sec_ao: ao-secure@10220 {
> amlogic,has-chip-id;
> };
>
> + pwm_ao_ef: pwm@30000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x30000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_E>,
> + <&clkc_periphs CLKID_PWM_AO_F>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_gh: pwm@32000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x32000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_G>,
> + <&clkc_periphs CLKID_PWM_AO_H>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ab: pwm@58000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x58000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_A>,
> + <&clkc_periphs CLKID_PWM_B>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_cd: pwm@5a000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5a000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_C>,
> + <&clkc_periphs CLKID_PWM_D>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ef: pwm@5c000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5c000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_E>,
> + <&clkc_periphs CLKID_PWM_F>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_ab: pwm@5e000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x5e000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_A>,
> + <&clkc_periphs CLKID_PWM_AO_B>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> + pwm_ao_cd: pwm@60000 {
> + compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
> + reg = <0x0 0x60000 0x0 0x24>;
> + clocks = <&clkc_periphs CLKID_PWM_AO_C>,
> + <&clkc_periphs CLKID_PWM_AO_D>;
> + #pwm-cells = <3>;
> + status = "disabled";
> + };
> +
> sd_emmc_a: mmc@88000 {
> compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> reg = <0x0 0x88000 0x0 0x800>;
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 4/9] arm64: dts: amlogic: t7: Add PWM pinctrl nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-4-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> These pinctrl nodes are required by the PWM drivers to configure
> pin muxing at runtime.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 136 ++++++++++++++++++++++++++++
> 1 file changed, 136 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 62c87d0ef7065..eb09a26bcd0e0 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -307,6 +307,142 @@ mux {
> };
> };
>
> + pwm_a_pins: pwm-a {
> + mux {
> + groups = "pwm_a";
> + function = "pwm_a";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_a_pins: pwm-ao-a {
> + mux {
> + groups = "pwm_ao_a";
> + function = "pwm_ao_a";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_b_pins: pwm-ao-b {
> + mux {
> + groups = "pwm_ao_b";
> + function = "pwm_ao_b";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_c_pins: pwm-ao-c {
> + mux {
> + groups = "pwm_ao_c";
> + function = "pwm_ao_c";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_c_hiz_pins: pwm-ao-c-hiz {
> + mux {
> + groups = "pwm_ao_c_hiz";
> + function = "pwm_ao_c_hiz";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_d_pins: pwm-ao-d {
> + mux {
> + groups = "pwm_ao_d";
> + function = "pwm_ao_d";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_e_pins: pwm-ao-e {
> + mux {
> + groups = "pwm_ao_e";
> + function = "pwm_ao_e";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_f_pins: pwm-ao-f {
> + mux {
> + groups = "pwm_ao_f";
> + function = "pwm_ao_f";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_g_pins: pwm-ao-g {
> + mux {
> + groups = "pwm_ao_g";
> + function = "pwm_ao_g";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_g_hiz_pins: pwm-ao-g-hiz {
> + mux {
> + groups = "pwm_ao_g_hiz";
> + function = "pwm_ao_g_hiz";
> + bias-disable;
> + };
> + };
> +
> + pwm_ao_h_pins: pwm-ao-h {
> + mux {
> + groups = "pwm_ao_h";
> + function = "pwm_ao_h";
> + bias-disable;
> + };
> + };
> +
> + pwm_b_pins: pwm-b {
> + mux {
> + groups = "pwm_b";
> + function = "pwm_b";
> + bias-disable;
> + };
> + };
> +
> + pwm_c_pins: pwm-c {
> + mux {
> + groups = "pwm_c";
> + function = "pwm_c";
> + bias-disable;
> + };
> + };
> +
> + pwm_d_pins: pwm-d {
> + mux {
> + groups = "pwm_d";
> + function = "pwm_d";
> + bias-disable;
> + };
> + };
> +
> + pwm_e_pins: pwm-e {
> + mux {
> + groups = "pwm_e";
> + function = "pwm_e";
> + bias-disable;
> + };
> + };
> +
> + pwm_f_pins: pwm-f {
> + mux {
> + groups = "pwm_f";
> + function = "pwm_f";
> + bias-disable;
> + };
> + };
> +
> + pwm_vs_pins: pwm-vs {
> + mux {
> + groups = "pwm_vs";
> + function = "pwm_vs";
> + bias-disable;
> + };
> + };
> +
> sdcard_pins: sdcard {
> mux {
> groups = "sdcard_d0",
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v4 3/9] arm64: dts: amlogic: t7: Add MMC controller nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-3-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> Add device tree nodes for the three MMC controllers available
> on the Amlogic T7 SoC, using amlogic,meson-axg-mmc as fallback compatible.
> All nodes are disabled by default and should be
> enabled in the board-specific DTS file.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 39 +++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 016b5429c8d1b..62c87d0ef7065 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -374,6 +374,45 @@ sec_ao: ao-secure@10220 {
> reg = <0x0 0x10220 0x0 0x140>;
> amlogic,has-chip-id;
> };
> +
> + sd_emmc_a: mmc@88000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x88000 0x0 0x800>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
move disabled at the end of the properties
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_A>,
> + <&clkc_periphs CLKID_SD_EMMC_A>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> +
> + sd_emmc_b: mmc@8a000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8a000 0x0 0x800>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
Ditto
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_B>,
> + <&clkc_periphs CLKID_SD_EMMC_B>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> +
> + sd_emmc_c: mmc@8c000 {
> + compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> + reg = <0x0 0x8c000 0x0 0x800>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
Ditto
> + clocks = <&clkc_periphs CLKID_SYS_SD_EMMC_C>,
> + <&clkc_periphs CLKID_SD_EMMC_C>,
> + <&scmi_clk CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
> + assigned-clock-parents = <&xtal>;
> + };
> };
>
> };
>
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Jinjie Ruan @ 2026-03-26 8:52 UTC (permalink / raw)
To: Mark Rutland, Thomas Gleixner
Cc: vladimir.murzin, peterz, catalin.marinas, linux-kernel, luto,
will, linux-arm-kernel
In-Reply-To: <acPAzdtjK5w-rNqC@J2N7QTR9R3>
On 2026/3/25 19:03, Mark Rutland wrote:
> On Sun, Mar 22, 2026 at 12:25:06AM +0100, Thomas Gleixner wrote:
>> On Fri, Mar 20 2026 at 17:31, Mark Rutland wrote:
>>> On Fri, Mar 20, 2026 at 05:26:47PM +0100, Thomas Gleixner wrote:
>>> I *think* you're saying that because the arch code would manage DAIF
>>> early during entry and late during exit, that would all be in one place.
>>
>> That was my thought, see below.
>>
>>> However, that doubles the number of times we have to write to DAIF: at
>>> entry we'd have to poke it once to unmask everything except IRQs, then
>>> again to unmask IRQs, and exit would need the inverse. We'd also have to
>>> split the inheritance logic into inherit-everything-but-interrupt and
>>> inherit-only-interrupt, which is doable but not ideal. With pseudo-NMI
>>> it's even worse, but that's largely because pseudo-NMI is
>>> over-complicated today.
>>
>> Interrupts are not unmasked on interrupt/exception entry ever and I
>> don't understand your concerns at all, but as always I might be missing
>> something.
>
> I think one problem is that we're using the same words to describe
> distinct things, because the terminology is overloaded; I've tried to
> clarify some of that below.
>
> I think another is that there are a large number of interacting
> constraints, and it's easily possible to find something that for most
> but not all of those. I *think* there's an approach that satisfies all
> of our requirements; see below where I say "I *think* what would work
> for us ...".
>
> For context, when I said "at entry" and "at exit" I was including
> *everything* we have to do before/after the "real" logic to handle an
> exception, including parts that surround the generic entry code. I'm
> happy to use a different term for those periods, but I can't immediately
> think of something better.
>
> For example, for faults handled by arm64's el1_abort(), I was
> characterising this as:
>
> /* -------- "entry" begins here -------- */
>
> [[ entry asm ]]
> [[ early triage, branch to el1_abort() ]]
>
> static void noinstr el1_abort(struct pt_regs *regs, unsigned long esr)
> {
> unsigned long far = read_sysreg(far_el1);
> irqentry_state_t state;
>
> state = enter_from_kernel_mode(regs) {
> ...
> irqentry_enter(regs);
> ...
> }
> local_daif_inherit(regs); // <----------- might unmask interrupts
> /* -------- "entry" ends here ---------- */
>
>
> /* -------- "real logic" begins here --- */
> do_mem_abort(far, esr, regs);
> /* -------- "real logic" ends here ----- */
>
>
> /* -------- "exit" begins here --------- */
> local_daif_mask(); // <------------------------- masks interrupts
> exit_to_kernel_mode(regs, state) {
> ...
> irqentry_exit(regs);
> ...
> }
> }
>
> [[ return from el1_abort() ]]
> [[ exit asm ]]
>
> /* -------- "exit" ends here ----------- */
>
> Please note, el1_abort() is indicative of what arm64 does for
> (most) synchronous exceptions, but there are slight differences for
> other exceptions. For anything maskable (including interupts) we DO NOT
> use local_daif_inherit() and instead unmask specific higher-priority
> maskable exceptions via other functions that write to DAIF, etc.
>
> Interrupts are an odd middle ground where we use irqentry_{enter,exit}()
> but do not use local_daif_inherit().
>
>> The current sequence on entry is:
>>
>> // interrupts are disabled by interrupt/exception entry
>> enter_from_kernel_mode()
>> irqentry_enter(regs);
>> mte_check_tfsr_entry();
>> mte_disable_tco_entry();
>> daif_inherit(regs);
>> // interrupts are still disabled
>
> That last comment isn't quite right: we CAN and WILL enable interrupts
> in local_daif_inherit(), if and only if they were enabled in the context
> the exception was taken from.
>
> As mentioned above, when handling an interrupt (rather than a
> synchronous exception), we don't use local_daif_inherit(), and instead
> use a different DAIF function to unmask everything except interrupts.
>
>> which then becomes:
>>
>> // interrupts are disabled by interrupt/exception entry
>> irqentry_enter(regs)
>> establish_state();
>> // RCU is watching
>> arch_irqentry_enter_rcu()
>> mte_check_tfsr_entry();
>> mte_disable_tco_entry();
>> daif_inherit(regs);
>> // interrupts are still disabled
>>
>> Which is equivalent versus the MTE/DAIF requirements, no?
>
> As above, we can't use local_daif_inherit() here because we want
> different DAIF masking behavior for entry to interrupts and entry to
> synchronous exceptions. While we could pass some token around to
> determine the behaviour dynamically, that's less clear, more
> complicated, and results in worse code being generated for something we
> know at compile time.
>
> If we can leave DAIF masked early on during irqentry_enter(), I don't
> see why we can't leave all DAIF exceptions masked until the end of
> irqentry_enter().
>
> I *think* what would work for us is we could split some of the exit
> handling (including involuntary preemption) into a "prepare" step, as we
> have for return to userspace. That way, arm64 could handle exiting
> something like:
>
> local_irq_disable();
> irqentry_exit_prepare(); // new, all generic logic
> local_daif_mask();
> arm64_exit_to_kernel_mode() {
> ...
> irqentry_exit(); // ideally irqentry_exit_to_kernel_mode().
> ...
> }
I agree. Having a symmetric 'prepare' step for kernel-mode exit as we do
for userspace would be much cleaner. It effectively addresses the DAIF
masking constraints on arm64.
arm64_exit_to_user_mode(struct pt_regs *regs)
-> local_irq_disable(); // only mask irqs
^^^^^^^^^^^^^^^^^^^^^^
-> exit_to_user_mode_prepare_legacy(regs);
-> schedule() // schedule if need resched
-> local_daif_mask(); // set daif to mask all exceptions
^^^^^^^^^^^^^^^^^^^^^
-> mte_check_tfsr_exit();
-> exit_to_user_mode();
This approach can also align with generic implementations like RISC-V.
We can split irqentry_exit() into two sub-functions:
irqentry_exit_prepare() to handle scheduling-related tasks, and the
remaining logic in a simplified irqentry_exit() (or a specific helper).
This way, arm64 can call these two helpers with the DAIF masking
operation inserted in between, while architectures like RISC-V can
continue to use the full irqentry_exit() functionality as they do now.
void do_page_fault(struct pt_regs *regs)
-> irqentry_state_t state = irqentry_enter(regs);
-> handle_page_fault(regs);
-> local_irq_disable();
-> irqentry_exit(regs, state);
>
> ... and other architectures can use a combined exit_to_kernel_mode() (or
> whatever we call that), which does both, e.g.
>
> // either noinstr, __always_inline, or a macro
> void irqentry_prepare_and_exit(void)
> {
> irqentry_exit_prepare();
> irqentry_exit();
> }
>
> That way:
>
> * There's a clear separation between the "prepare" and subsequent exit
> steps, which minimizes the risk that a change subtly breaks arm64's
> exception masking.
>
> * This would mirror the userspace return path, and so would be more
> consistent over all.
>
> * All of arm64's arch-specific exception masking can live in
> arch/arm64/kernel/entry-common.c, explicit in the straight line code
> rather than partially hidden behind arch_*() callbacks.
>
> * There's no unnecessary cost to other architectures.
>
> * There's no/minimal maintenance cost for the generic code. There are no
> arch_*() callbacks, and we'd have to enforce ordering between the
> prepare/exit steps anyhow...
>
> If you don't see an obvious problem with that, I will go and try that
> now.
>
>> The current broken sequence vs. preemption on exit is:
>>
>> // interrupts are disabled
>> exit_to_kernel_mode
>> daif_mask();
>> mte_check_tfsr_exit();
>> irqentry_exit(regs, state);
>>
>> which then becomes:
>>
>> // interrupts are disabled
>> irqentry_exit(regs, state)
>> // includes preemption
>> prepare_for_exit();
>>
>> // RCU is still watching
>> arch_irqentry_ecit_rcu()
>> daif_mask();
>> mte_check_tfsr_exit();
>>
>> if (state.exit_rcu)
>> ct_irq_exit();
>
> As above, I'd strongly prefer if we could pull the "prepare" step out of
> irqentry_exit(). Especially since for the entry path we can't push the
> DAIF masking into irqentry_enter(), and I'd very strongly prefer that
> the masking and unmasking occur in the same logical place, rather than
> having one of those hidden behind an arch_() callback.
>
>> Which is equivalent versus the MTE/DAIF requirements and fixes the
>> preempt on exit issue too, no?
>>
>> That change would be trivial enough for backporting, right?
>>
>> It also prevents you from staring at the bug reports which are going to
>> end up in your mailbox after I merged the patch which moves the
>> misplaced rcu_irq_exit_check_preempt() check _before_ the
>> preempt_count() check where it belongs.
>
> I intend to fix that issue, so hopefully I'm not staring at those for
> long.
>
> Just to check, do you mean that you've already queued that (I didn't
> spot it in tip), or that you intend to? I'll happily test/review/ack a
> patch adding that, but hopefully we can fix arm64 first.
>
>> I fully agree that ARM64 is special vs. CPU state handling, but it's not
>> special enough to justify it's own semantically broken preemption logic.
>
> Sure. To be clear, I'm not arguing for broken preemption logic. I'd
> asked those initial two questions because I suspected this approach
> wasn't quite right.
>
> As above, I think we can solve this in an actually generic way by
> splitting out a "prepare to exit" step, and still keep the bulk of the
> logic generic.
>
>> Looking at those details made me also look at this magic
>> arch_irqentry_exit_need_resched() inline function.
>
> I see per your other reply that you figured out this part was ok:
>
> https://lore.kernel.org/linux-arm-kernel/87se9ph129.ffs@tglx/
>
> ... though I agree we can clean that up further.
>
> Mark.
>
^ permalink raw reply
* Re: [PATCH v4 1/9] arm64: dts: amlogic: t7: Add eMMC, SD card and SDIO pinctrl nodes
From: Neil Armstrong @ 2026-03-26 8:52 UTC (permalink / raw)
To: Ronald Claveau, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ulf Hansson,
Johannes Berg, van Spriel
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
linux-mmc, linux-wireless
In-Reply-To: <20260325-add-emmc-t7-vim4-v4-1-44c7b4a5e459@aliel.fr>
On 3/25/26 10:15, Ronald Claveau wrote:
> These pinctrl nodes are required by the eMMC, SD card and SDIO drivers
> to configure pin muxing at runtime.
>
> - eMMC: control, 4-bit/8-bit data, data strobe and clock gate pins
> - SD card: data, clock, command and clock gate pins
> - SDIO: data, clock, command and clock gate pins
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 98 +++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 6510068bcff92..016b5429c8d1b 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -250,6 +250,104 @@ gpio: bank@4000 {
> #gpio-cells = <2>;
> gpio-ranges = <&periphs_pinctrl 0 0 157>;
> };
> +
> + emmc_ctrl_pins: emmc-ctrl {
> + mux-0 {
> + groups = "emmc_cmd";
> + function = "emmc";
> + bias-pull-up;
> + };
> +
> + mux-1 {
> + groups = "emmc_clk";
> + function = "emmc";
> + bias-disable;
> + };
> + };
> +
> + emmc_data_4b_pins: emmc-data-4b {
> + mux-0 {
No need for "-0"
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_data_8b_pins: emmc-data-8b {
> + mux-0 {
No need for "-0"
> + groups = "emmc_nand_d0",
> + "emmc_nand_d1",
> + "emmc_nand_d2",
> + "emmc_nand_d3",
> + "emmc_nand_d4",
> + "emmc_nand_d5",
> + "emmc_nand_d6",
> + "emmc_nand_d7";
> + function = "emmc";
> + bias-pull-up;
> + };
> + };
> +
> + emmc_ds_pins: emmc-ds {
> + mux {
> + groups = "emmc_nand_ds";
> + function = "emmc";
> + bias-pull-down;
> + };
> + };
> +
> + emmc_clk_gate_pins: emmc-clk-gate {
> + mux {
> + groups = "GPIOB_8";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdcard_pins: sdcard {
> + mux {
> + groups = "sdcard_d0",
> + "sdcard_d1",
> + "sdcard_d2",
> + "sdcard_d3",
> + "sdcard_clk",
> + "sdcard_cmd";
> + function = "sdcard";
> + bias-pull-up;
> + };
> + };
> +
> + sdcard_clk_gate_pins: sdcard-clk-gate {
> + mux {
> + groups = "GPIOC_4";
> + function = "gpio_periphs";
> + bias-pull-down;
> + };
> + };
> +
> + sdio_pins: sdio {
> + mux-0 {
No need for "-0"
> + groups = "sdio_d0",
> + "sdio_d1",
> + "sdio_d2",
> + "sdio_d3",
> + "sdio_clk",
> + "sdio_cmd";
> + function = "sdio";
> + bias-pull-up;
> + };
> + };
> +
> + sdio_clk_gate_pins: sdio-clk-gate {
> + mux {
> + groups = "GPIOX_4";
> + function = "gpio_periphs";
> + bias-pull-up;
> + };
> + };
> };
>
> gpio_intc: interrupt-controller@4080 {
>
^ permalink raw reply
* Re: [PATCH v3] gpio: mxc: map Both Edge pad wakeup to Rising Edge
From: Bartosz Golaszewski @ 2026-03-26 8:41 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Frank Li, Sascha Hauer,
Shenwei Wang
Cc: Bartosz Golaszewski, Pengutronix Kernel Team, Fabio Estevam,
Peng Fan, linux-gpio, imx, linux-arm-kernel, linux-kernel,
linux-imx, stable
In-Reply-To: <20260324192129.2797237-1-shenwei.wang@nxp.com>
On Tue, 24 Mar 2026 14:21:29 -0500, Shenwei Wang wrote:
> Suspend may fail on i.MX8QM when Falling Edge is used as a pad wakeup
> trigger due to a hardware bug in the detection logic. Since the hardware
> does not support Both Edge wakeup, remap requests for Both Edge to Rising
> Edge by default to avoid hitting this issue.
>
> A warning is emitted when Falling Edge is selected on i.MX8QM.
>
> [...]
Applied, thanks!
[1/1] gpio: mxc: map Both Edge pad wakeup to Rising Edge
https://git.kernel.org/brgl/c/c720fb57d56274213d027b3c5ab99080cf62a306
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] gpio: fix up CONFIG_OF dependencies
From: Bartosz Golaszewski @ 2026-03-26 8:41 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann
Cc: Bartosz Golaszewski, Arnd Bergmann, Yixun Lan, Matthias Brugger,
AngeloGioacchino Del Regno, linux-gpio, linux-kernel, linux-riscv,
spacemit, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260325100144.1696731-1-arnd@kernel.org>
On Wed, 25 Mar 2026 11:01:14 +0100, Arnd Bergmann wrote:
> A number of GPIO drivers that used to have a CONFIG_OF_GPIO dependency now fail
> to build on targets without CONFIG_OF:
>
> WARNING: unmet direct dependencies detected for GPIO_SYSCON
> Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
> Selected by [y]:
> - GPIO_SAMA5D2_PIOBU [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
>
> [...]
Applied, thanks!
[1/1] gpio: fix up CONFIG_OF dependencies
https://git.kernel.org/brgl/c/af475c16bc02a08ed6af6ca0c920f98a45611fe6
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] gpio: fix up CONFIG_OF dependencies
From: Bartosz Golaszewski @ 2026-03-26 8:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnd Bergmann, Yixun Lan, Matthias Brugger,
AngeloGioacchino Del Regno, open list:GPIO SUBSYSTEM,
linux-kernel, linux-riscv, spacemit, linux-arm-kernel,
linux-mediatek, Linus Walleij
In-Reply-To: <1789ce66-5a18-4b54-bbad-3b2049f2c26d@app.fastmail.com>
On Wed, Mar 25, 2026 at 11:41 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Mar 25, 2026, at 11:32, Bartosz Golaszewski wrote:
> > On Wed, 25 Mar 2026 11:01:14 +0100, Arnd Bergmann <arnd@kernel.org> said:
> >>
> >> WARNING: unmet direct dependencies detected for GPIO_SYSCON
> >> Depends on [n]: GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && OF [=n]
> >> Selected by [y]:
> >> - GPIO_SAMA5D2_PIOBU [=y] && GPIOLIB [=y] && HAS_IOMEM [=y] && MFD_SYSCON [=y] && (ARCH_AT91 || COMPILE_TEST [=y])
> >>
> >
> > Thanks and sorry for the breakage. However, I'm wondering if it wouldn't make
> > sense to do the following:
> >
> >
> > -#if defined(CONFIG_OF_GPIO)
> > /*
> > * If CONFIG_OF_GPIO is enabled, then all GPIO controllers described in
> > * the device tree automatically may have an OF translation
> ...
> > Symbols from linux/of.h are stubbed out and these drivers can build just fine
> > with !CONFIG_OF. This would naturally increase the build coverage.
>
> I don't think we need to worry about the build coverage here, CONFIG_OF
> is still included in x86 allmodconfig and half the randconfig builds,
> so the drivers get enough exposure either way.
>
> On the other hand, dropping the build time check may help avoid
> future Kconfig dependency issues, so that still sounds like a
> reasonable suggestion. At least CONFIG_GPIO_SAMA5D2_PIOBU
> is going to need the 'depends on OF' regardless though to work
> around the other build error I cited above.
>
> Arnd
Fair enough, I'll queue this patch.
Bart
^ permalink raw reply
* Re: [PATCH] i2c: s3c24xx: check the size of the SMBUS message before using it
From: Greg Kroah-Hartman @ 2026-03-26 8:39 UTC (permalink / raw)
To: Andi Shyti
Cc: linux-arm-kernel, linux-samsung-soc, linux-i2c, linux-kernel,
Krzysztof Kozlowski, Alim Akhtar, stable
In-Reply-To: <acQYnURilS0_fTvS@zenone.zhora.eu>
On Wed, Mar 25, 2026 at 06:17:58PM +0100, Andi Shyti wrote:
> Hi Greg,
>
> On Mon, Feb 23, 2026 at 06:05:15PM +0100, Greg Kroah-Hartman wrote:
> > The first byte of an i2c SMBUS message is the size, and it should be
> > verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX
> > before processing it.
> >
> > This is the same logic that was added in commit a6e04f05ce0b ("i2c:
> > tegra: check msg length in SMBUS block read") to the i2c tegra driver.
> >
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > Cc: Alim Akhtar <alim.akhtar@samsung.com>
> > Cc: Andi Shyti <andi.shyti@kernel.org>
> > Cc: stable <stable@kernel.org>
> > Assisted-by: gkh_clanker_2000
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> merged to i2c/i2c-host.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/4] drm/panel: simple: add JuTouch JT070TM041
From: Neil Armstrong @ 2026-03-26 8:38 UTC (permalink / raw)
To: Steffen Trumtrar, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-2-10255d236439@pengutronix.de>
On 3/25/26 12:32, Steffen Trumtrar wrote:
> Add JuTouch Technology JT070TM041 7" 1024x600 LVDS panel support.
>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> ---
> drivers/gpu/drm/panel/panel-simple.c | 32 ++++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
> index 91ab280869bac..6ac263f83793b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2940,6 +2940,35 @@ static const struct panel_desc innolux_zj070na_01p = {
> },
> };
>
> +static const struct display_timing jutouch_jt070tm041_timing = {
> + .pixelclock = { 40800000, 51200000, 67200000 },
> + .hactive = { 1024, 1024, 1024 },
> + .hfront_porch = { 16, 160, 216 },
> + .hback_porch = { 160, 160, 160 },
> + .hsync_len = { 1, 1, 140 },
> + .vactive = { 600, 600, 600 },
> + .vfront_porch = { 1, 12, 127 },
> + .vback_porch = { 23, 23, 23 },
> + .vsync_len = { 1, 1, 20 },
> +};
> +
> +static const struct panel_desc jutouch_jt070tm041 = {
> + .timings = &jutouch_jt070tm041_timing,
> + .num_timings = 1,
> + .bpc = 8,
> + .size = {
> + .width = 154,
> + .height = 86,
> + },
> + .delay = {
> + .enable = 50,
> + .disable = 50,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH,
> + .connector_type = DRM_MODE_CONNECTOR_LVDS,
> +};
> +
> static const struct display_timing jutouch_jt101tm023_timing = {
> .pixelclock = { 66300000, 72400000, 78900000 },
> .hactive = { 1280, 1280, 1280 },
> @@ -5352,6 +5381,9 @@ static const struct of_device_id platform_of_match[] = {
> }, {
> .compatible = "innolux,zj070na-01p",
> .data = &innolux_zj070na_01p,
> + }, {
> + .compatible = "jutouch,jt070tm041",
> + .data = &jutouch_jt070tm041,
> }, {
> .compatible = "jutouch,jt101tm023",
> .data = &jutouch_jt101tm023,
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: iio: adc: amlogic,meson-saradc: add S4 compatible
From: Krzysztof Kozlowski @ 2026-03-26 8:19 UTC (permalink / raw)
To: Nick Xie
Cc: neil.armstrong, khilman, martin.blumenstingl, jbrunet, jic23,
dlechner, andy, krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325070618.81955-2-nick@khadas.com>
On Wed, Mar 25, 2026 at 03:06:15PM +0800, Nick Xie wrote:
> Add the compatible string for the SARADC (Successive Approximation
> Register ADC) IP block found in the Amlogic Meson S4 SoC.
>
> There are no known differences between the SARADC on S4 and the one
> on G12A. Therefore, it uses "amlogic,meson-g12a-saradc" as a proper
> specific fallback.
>
> Also add a comment indicating that "amlogic,meson-saradc" must not be
> used for new devices. It's a made up compatible string that does not
> correspond to a specific hardware generation and is not used to match
> any driver. For old devices we keep it as it's part of the ABI.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* RE: Clear CLKREQ# override breaks functionality
From: Hongxing Zhu @ 2026-03-26 8:17 UTC (permalink / raw)
To: Franz Schnyder
Cc: Franz Schnyder, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org, Francesco Dolcini,
Manivannan Sadhasivam, Frank Li
In-Reply-To: <jfefktil6ywvugvbxdplbvry6g5efka5g4bpr2dwhha2mtrkm5@6gkcmj2glvwo>
> -----Original Message-----
> From: Franz Schnyder <fra.schnyder@gmail.com>
> Sent: 2026年3月26日 16:00
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: Franz Schnyder <franz.schnyder@toradex.com>;
> linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; Francesco Dolcini
> <francesco@dolcini.it>; Manivannan Sadhasivam <mani@kernel.org>; Frank
> Li <frank.li@nxp.com>
> Subject: Clear CLKREQ# override breaks functionality
>
> Hi Richard,
>
> While integrating the `supports-clkreq` DT property on our iMX95-based
> SoM, we had failures in our CI on one of the two M.2 PCIe slots on our
> development board.
> The failing slot uses a card that does not advertise L1 PM substates.
> This issue comes from commit a152a90f5390 ("PCI: imx6: Clear CLKREQ#
> override if 'supports-clkreq' DT property is available"), which clears the
> CLKREQ# override based only on the DT property.
>
> It seems that clearing the CLKREQ# override should happen only when the
> driver knows that the downstream device advertises L1 PM Substates.
> Otherwise CLKREQ# should remain asserted to keep compatibility with cards
> that do not support L1 PM Substates.
>
> Thoughts?
Hi Franz:
No, CLKREQ# is not dependent on L1 PM Substates capabilities.
According to the PCI Express Card Electromechanical Specification r6.0,
Section 2 (Auxiliary Signals):
"CLKREQ# (optional) signal is an open drain, active low signal that is driven
low by the card to request that the PCI Express reference clock be available
(active clock state) to allow the PCI Express interface to send/receive data."
When the 'supports-clkreq' property is present, it indicates that the endpoint
device supports CLKREQ# signaling and will actively drive the signal low when
it needs the reference clock.
Therefore, the RC (Root Complex) controller can safely clear any CLKREQ#
active-low override settings, allowing the endpoint to control the clock
request through proper CLKREQ# signaling.
If the endpoint devices on your platform can't drive the CLKREQ# signal to
low, remove 'supports-clkreq' property from your board's device tree file.
Best Regards
Richard Zhu
>
> Kind Regards
>
> Franz
^ permalink raw reply
* [PATCH v2 2/2] regulator: mt6315: Add regulator supplies
From: Chen-Yu Tsai @ 2026-03-26 8:10 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-kernel, Chen-Yu Tsai, linux-arm-kernel, linux-mediatek,
devicetree
In-Reply-To: <20260326081050.1115201-1-wenst@chromium.org>
The MT6315 family of PMICs has 4 buck regulators. Each regulator has a
separate supply.
Add these supplies to the driver.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/regulator/mt6315-regulator.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/mt6315-regulator.c b/drivers/regulator/mt6315-regulator.c
index d3f93aae0fc5..231e64fb0596 100644
--- a/drivers/regulator/mt6315-regulator.c
+++ b/drivers/regulator/mt6315-regulator.c
@@ -31,10 +31,11 @@ struct mt6315_chip {
struct regmap *regmap;
};
-#define MT_BUCK(_name, _bid, _vsel) \
+#define MT_BUCK(_name, _bid, _supply, _vsel) \
[_bid] = { \
.desc = { \
.name = _name, \
+ .supply_name = _supply, \
.of_match = of_match_ptr(_name), \
.regulators_node = "regulators", \
.ops = &mt6315_volt_range_ops, \
@@ -190,10 +191,10 @@ static const struct regulator_ops mt6315_volt_range_ops = {
};
static const struct mt6315_regulator_info mt6315_regulators[MT6315_VBUCK_MAX] = {
- MT_BUCK("vbuck1", MT6315_VBUCK1, MT6315_BUCK_TOP_ELR0),
- MT_BUCK("vbuck2", MT6315_VBUCK2, MT6315_BUCK_TOP_ELR2),
- MT_BUCK("vbuck3", MT6315_VBUCK3, MT6315_BUCK_TOP_ELR4),
- MT_BUCK("vbuck4", MT6315_VBUCK4, MT6315_BUCK_TOP_ELR6),
+ MT_BUCK("vbuck1", MT6315_VBUCK1, "pvdd1", MT6315_BUCK_TOP_ELR0),
+ MT_BUCK("vbuck2", MT6315_VBUCK2, "pvdd2", MT6315_BUCK_TOP_ELR2),
+ MT_BUCK("vbuck3", MT6315_VBUCK3, "pvdd3", MT6315_BUCK_TOP_ELR4),
+ MT_BUCK("vbuck4", MT6315_VBUCK4, "pvdd4", MT6315_BUCK_TOP_ELR6),
};
static const struct regmap_config mt6315_regmap_config = {
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v2 1/2] regulator: dt-bindings: mt6315: Add regulator supplies
From: Chen-Yu Tsai @ 2026-03-26 8:10 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-kernel, Chen-Yu Tsai, linux-arm-kernel, linux-mediatek,
devicetree
In-Reply-To: <20260326081050.1115201-1-wenst@chromium.org>
The MT6315 family of PMICs has 4 buck regulators. Each regulator has a
separate supply.
Add these supplies to the device tree binding.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Moved *-supply to top level, same level as compatible
---
.../bindings/regulator/mt6315-regulator.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
index fa6743bb269d..1c63265907f1 100644
--- a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml
@@ -25,6 +25,15 @@ properties:
reg:
maxItems: 1
+ pvdd1-supply:
+ description: Supply for regulator vbuck1
+ pvdd2-supply:
+ description: Supply for regulator vbuck2
+ pvdd3-supply:
+ description: Supply for regulator vbuck3
+ pvdd4-supply:
+ description: Supply for regulator vbuck4
+
regulators:
type: object
description: List of regulators and its properties
@@ -49,8 +58,11 @@ examples:
pmic@6 {
compatible = "mediatek,mt6315-regulator";
reg = <0x6 0>;
+ pvdd1-supply = <&pp4200_z2>;
+ pvdd3-supply = <&pp4200_z2>;
regulators {
+
vbuck1 {
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1193750>;
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v2 0/2] regulator: mt6315: add regulator supplies
From: Chen-Yu Tsai @ 2026-03-26 8:10 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-kernel, Chen-Yu Tsai, linux-arm-kernel, linux-mediatek,
devicetree
Hi,
This is v2 of the "Add MT6315 regulator supplies" series.
Changes since v1:
- Link to v1: https://lore.kernel.org/all/20260324053030.4077453-1-wenst@chromium.org/
- Move supplies to top level node, at the same level as the compatible
This series is part of a broader collection of regulator related
cleanups for MediaTek Chromebooks. This one covers the MT6315 PMIC.
Patch 1 adds the names of the power supply inputs to the binding.
Patch 2 adds the supply names from the DT binding change in patch 1
to the regulator descriptions in the driver. This patch has a
checkpatch.pl warnings, but I wonder if it's because the context size
for checking complex macros is not large enough.
Device tree changes will be sent separately. The goal is to get the
regulator tree as complete as possible. This includes adding supply
names to other regulator DT bindings, and adding all the supply links
to the existing DTs.
Please have a look.
Thanks
ChenYu
Chen-Yu Tsai (2):
regulator: dt-bindings: mt6315: Add regulator supplies
regulator: mt6315: Add regulator supplies
.../bindings/regulator/mt6315-regulator.yaml | 12 ++++++++++++
drivers/regulator/mt6315-regulator.c | 11 ++++++-----
2 files changed, 18 insertions(+), 5 deletions(-)
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply
* RE: [PATCH v2] net: stmmac: skip VLAN restore when VLAN hash ops are missing
From: Ovidiu Panait @ 2026-03-26 8:07 UTC (permalink / raw)
To: Maxime Chevallier, Michal Piekos, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Alexandre Torgue
Cc: netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <abb1c779-b306-42f8-b2b1-aa56bfcebe1b@bootlin.com>
Hi,
>
> Hi,
>
> On 21/03/2026 06:38, Michal Piekos wrote:
> > stmmac_vlan_restore() unconditionally calls stmmac_vlan_update() when
> > NETIF_F_VLAN_FEATURES is set. On platforms where priv->hw->vlan (or
> > ->update_vlan_hash) is not provided, stmmac_update_vlan_hash() returns
> > -EINVAL via stmmac_do_void_callback(), resulting in a spurious
> > "Failed to restore VLANs" error even when no VLAN filtering is in use.
> >
> > Check presence of VLAN HW FILTER flags before stmmac_vlan_update().
> >
> > Tested on Orange Pi Zero 3.
> >
> > Fixes: bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore")
> > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > ---
> > This patch fixes a noisy "Failed to restore VLANs" message on platforms
> > where stmmac VLAN hash ops are not implemented.
> > stmmac_vlan_restore() calls stmmac_vlan_update() without checking for
> > VLAN hash ops presence which results in -EINVAL.
>
> I've been seeing the same message on socfpga. My two cents on that is
> that this error messages doesn't bring anything to the table anyways.
>
> As Russell explains, it's either triggered when the vlan op isn't
> implemented (the stmmac callback macro stuff turns that into a -EINVAL),
> or when some capabilities arent present. All in all, it's always stuff
> that users can't really do anything about, as it's HW limitations, I
> think we can simply discard this message.
>
> Also, nothing actually checks what stmmac_vlan_restore() returns, so we
> might as well return void ?
>
I think this is the best solution until the VLAN capabilities handling is
cleaned up.
Michal, please let me know if you will be handling this in v3 or I should
send a fix for it.
Thanks,
Ovidiu
> Maxime
>
> > ---
> > Changes in v2:
> > - Replace check for hash ops with check for HW FILTER flags
> > - Link to v1: https://lore.kernel.org/r/20260314-vlan-restore-error-v1-
> 1-4fc6c3e2115f@mmpsystems.pl
> > ---
> > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > index 6827c99bde8c..cfc0ce9cec9c 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > @@ -6863,7 +6863,8 @@ static int stmmac_vlan_restore(struct stmmac_priv
> *priv)
> > {
> > int ret;
> >
> > - if (!(priv->dev->features & NETIF_F_VLAN_FEATURES))
> > + if (!(priv->dev->features &
> > + (NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)))
> > return 0;
> >
> > if (priv->hw->num_vlan)
> >
> > ---
> > base-commit: 42bddab0563fe67882b2722620a66dd98c8dbf33
> > change-id: 20260314-vlan-restore-error-f8b3a1c7f50a
> >
> > Best regards,
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Vladimir Oltean @ 2026-03-26 8:04 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <20260325115731.genmq2yew2p4dvbs@skbuf>
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
On Wed, Mar 25, 2026 at 01:57:31PM +0200, Vladimir Oltean wrote:
> On Wed, Mar 25, 2026 at 05:21:14PM +0530, Manivannan Sadhasivam wrote:
> > I believe I added the power_count check for phy_exit(). But since that got
> > moved, the check becomes no longer necessary.
>
> FYI, the power_count keeps track of the balance of phy_power_on() and
> phy_power_off() calls, whereas it is the init_count keeps track of
> phy_init() and phy_exit() calls. They are only related to the extent
> that you must respect the phy_init() -> phy_power_on() -> phy_power_off()
> -> phy_exit() sequence. But in any case, both should be considered
> PHY-internal fields. The "Order of API calls" section from
> Documentation/driver-api/phy/phy.rst mentions the order that I just
> described above, and consumers should just ensure they follow that.
Ok, so we can close this topic of "checking the power_count not needed"
by linking to the conversation which spun off here:
https://lore.kernel.org/lkml/20260325120122.265973-1-manivannan.sadhasivam@oss.qualcomm.com/
Mani, I spent some more time to figure out what's really going on with
this unexpected phy_power_off() call. Do you think you could
regression-test the patch attached?
Thanks!
[-- Attachment #2: 0001-scsi-ufs-qcom-don-t-call-phy_power_on-before-phy_ini.patch --]
[-- Type: text/x-diff, Size: 7996 bytes --]
From 50dfff3541566eb094e931bd56c80011f29b9817 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Thu, 26 Mar 2026 10:01:55 +0200
Subject: [PATCH] scsi: ufs: qcom: don't call phy_power_on() before phy_init()
The Qualcomm UFS host controller driver violates the Generic PHY API
expectation, documented in section "Order of API calls" from
Documentation/driver-api/phy/phy.rst, and then tries to hide it.
The expectation is that calls must be made in the phy_init() ->
phy_power_on() -> phy_power_off() -> phy_exit() sequence.
What we actually have is:
ufshcd_init()
-> ufshcd_hba_init()
-> ufshcd_setup_clocks(hba, true)
-> ufshcd_vops_setup_clocks(hba, true, POST_CHANGE)
-> ufs_qcom_setup_clocks(hba, true, POST_CHANGE)
-> phy_power_on(phy)
-> ufshcd_variant_hba_init()
-> ufs_qcom_init()
-> ufs_qcom_setup_clocks(hba, true, POST_CHANGE)
-> phy_power_on(phy)
-> ufshcd_hba_enable()
-> ufshcd_vops_hce_enable_notify()
-> ufs_qcom_hce_enable_notify()
-> ufs_qcom_power_up_sequence()
-> if (phy->power_count) phy_power_off(phy)
-> phy_init(phy)
This "works" because the way that the "phy_power_on was called before
phy_init\n" condition is detected in phy-core.c is if the power_count is
positive at the phy_init() call time.
By having that "if (phy->power_count) phy_power_off(phy)" logic, the
ufs-qcom.c technically sidesteps the test, but actually violates the
Generic PHY API even more (calls phy_power_on() *and* phy_power_off()
before phy_init()).
The reason why I stumbled upon this was that I was trying to remove
dereferences of phy->power_count from drivers. This is a PHY-internal
field, and using it from drivers is highly likely to be incorrect, as
this case showcases rather well.
As commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls") shows, this driver tries to couple the PHY power state with the
HBA clocks, for power saving reasons. I won't try to change that, I will
just move the phy_init() call earlier, to ufs_qcom_init().
After the phy_init() movement, ufs_qcom_power_up_sequence() should no
longer need to do either phy_init() nor the conditional phy_power_down().
Because the UFS variant operations are not balanced, but the PHY API
calls need to be, create wrappers for all Generic PHY API calls, and
keep a "phy_initialized" and a "phy_powered_on" boolean, so that we call
these only once, and they properly get paired with their phy_exit()/
phy_power_off() counterparts rather than leave the phy->init_count and
phy->power_count elevated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Nitin Rawat <quic_nitirawa@quicinc.com>
v5->v6: rewrite after actually understanding the core issue
v4->v5: patch is new
---
drivers/ufs/host/ufs-qcom.c | 104 ++++++++++++++++++++++++++----------
drivers/ufs/host/ufs-qcom.h | 2 +
2 files changed, 79 insertions(+), 27 deletions(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 375fd24ba458..ed067247d72a 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -485,11 +485,70 @@ static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba)
return UFS_HS_G3;
}
+static int ufs_qcom_phy_init(struct ufs_qcom_host *host)
+{
+ struct phy *phy = host->generic_phy;
+ int err;
+
+ if (host->phy_initialized)
+ return 0;
+
+ err = phy_init(phy);
+ if (err)
+ return err;
+
+ host->phy_initialized = true;
+
+ return 0;
+}
+
+static void ufs_qcom_phy_exit(struct ufs_qcom_host *host)
+{
+ if (host->phy_initialized) {
+ phy_exit(host->generic_phy);
+ host->phy_initialized = false;
+ }
+}
+
+static int ufs_qcom_phy_power_on(struct ufs_qcom_host *host)
+{
+ int err;
+
+ if (host->phy_powered_on)
+ return 0;
+
+ err = phy_power_on(host->generic_phy);
+ if (err)
+ return err;
+
+ host->phy_powered_on = true;
+
+ return 0;
+}
+
+static int ufs_qcom_phy_set_gear(struct ufs_qcom_host *host,
+ enum phy_mode mode)
+{
+ return phy_set_mode_ext(host->generic_phy, mode, host->phy_gear);
+}
+
+static int ufs_qcom_phy_calibrate(struct ufs_qcom_host *host)
+{
+ return phy_calibrate(host->generic_phy);
+}
+
+static void ufs_qcom_phy_power_off(struct ufs_qcom_host *host)
+{
+ if (host->phy_powered_on) {
+ phy_power_off(host->generic_phy);
+ host->phy_powered_on = false;
+ }
+}
+
static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
struct ufs_host_params *host_params = &host->host_params;
- struct phy *phy = host->generic_phy;
enum phy_mode mode;
int ret;
@@ -508,31 +567,22 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
if (ret)
return ret;
- if (phy->power_count)
- phy_power_off(phy);
-
-
- /* phy initialization - calibrate the phy */
- ret = phy_init(phy);
+ ret = ufs_qcom_phy_set_gear(host, mode);
if (ret) {
- dev_err(hba->dev, "%s: phy init failed, ret = %d\n",
+ dev_err(hba->dev, "%s: phy_set_mode_ext() failed, ret = %d\n",
__func__, ret);
- return ret;
- }
-
- ret = phy_set_mode_ext(phy, mode, host->phy_gear);
- if (ret)
goto out_disable_phy;
+ }
/* power on phy - start serdes and phy's power and clocks */
- ret = phy_power_on(phy);
+ ret = ufs_qcom_phy_power_on(host);
if (ret) {
dev_err(hba->dev, "%s: phy power on failed, ret = %d\n",
__func__, ret);
goto out_disable_phy;
}
- ret = phy_calibrate(phy);
+ ret = ufs_qcom_phy_calibrate(host);
if (ret) {
dev_err(hba->dev, "Failed to calibrate PHY: %d\n", ret);
goto out_disable_phy;
@@ -543,7 +593,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
return 0;
out_disable_phy:
- phy_exit(phy);
+ ufs_qcom_phy_power_off(host);
return ret;
}
@@ -1233,7 +1283,6 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
enum ufs_notify_change_status status)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
- struct phy *phy;
int err;
/*
@@ -1244,8 +1293,6 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
if (!host)
return 0;
- phy = host->generic_phy;
-
switch (status) {
case PRE_CHANGE:
if (on) {
@@ -1263,16 +1310,12 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
ufs_qcom_dev_ref_clk_ctrl(host, false);
}
- err = phy_power_off(phy);
- if (err) {
- dev_err(hba->dev, "phy power off failed, ret=%d\n", err);
- return err;
- }
+ ufs_qcom_phy_power_off(host);
}
break;
case POST_CHANGE:
if (on) {
- err = phy_power_on(phy);
+ err = ufs_qcom_phy_power_on(host);
if (err) {
dev_err(hba->dev, "phy power on failed, ret = %d\n", err);
return err;
@@ -1441,6 +1484,13 @@ static int ufs_qcom_init(struct ufs_hba *hba)
if (err)
goto out_variant_clear;
+ err = ufs_qcom_phy_init(host);
+ if (err) {
+ dev_err(hba->dev, "%s: phy_init failed, ret = %d\n",
+ __func__, err);
+ goto out_variant_clear;
+ }
+
ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
ufs_qcom_get_default_testbus_cfg(host);
@@ -1466,8 +1516,8 @@ static void ufs_qcom_exit(struct ufs_hba *hba)
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
ufs_qcom_disable_lane_clks(host);
- phy_power_off(host->generic_phy);
- phy_exit(host->generic_phy);
+ ufs_qcom_phy_power_off(host);
+ ufs_qcom_phy_exit(host);
}
static int ufs_qcom_fw_managed_init(struct ufs_hba *hba)
diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
index 1111ab34da01..33b1b1521916 100644
--- a/drivers/ufs/host/ufs-qcom.h
+++ b/drivers/ufs/host/ufs-qcom.h
@@ -282,6 +282,8 @@ struct ufs_qcom_host {
struct clk_bulk_data *clks;
u32 num_clks;
bool is_lane_clks_enabled;
+ bool phy_initialized;
+ bool phy_powered_on;
struct icc_path *icc_ddr;
struct icc_path *icc_cpu;
--
2.34.1
^ permalink raw reply related
* Clear CLKREQ# override breaks functionality
From: Franz Schnyder @ 2026-03-26 8:00 UTC (permalink / raw)
To: Hongxing Zhu
Cc: Franz Schnyder, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org, Francesco Dolcini,
Manivannan Sadhasivam, Frank Li
Hi Richard,
While integrating the `supports-clkreq` DT property on our iMX95-based
SoM, we had failures in our CI on one of the two M.2 PCIe slots on our
development board.
The failing slot uses a card that does not advertise L1 PM substates.
This issue comes from commit a152a90f5390 ("PCI: imx6: Clear CLKREQ#
override if 'supports-clkreq' DT property is available"), which clears
the CLKREQ# override based only on the DT property.
It seems that clearing the CLKREQ# override should happen only
when the driver knows that the downstream device advertises L1 PM
Substates. Otherwise CLKREQ# should remain asserted to keep compatibility
with cards that do not support L1 PM Substates.
Thoughts?
Kind Regards
Franz
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: mediatek: Add mt8173-mfgtop driver
From: Dan Carpenter @ 2026-03-26 7:58 UTC (permalink / raw)
To: oe-kbuild, Chen-Yu Tsai, Stephen Boyd, Matthias Brugger,
AngeloGioacchino Del Regno, Frank Binns, Matt Coster,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Cc: lkp, oe-kbuild-all, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260325071951.544031-3-wenst@chromium.org>
Hi Chen-Yu,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Chen-Yu-Tsai/dt-bindings-clock-mediatek-Add-mt8173-mfgtop/20260325-202618
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
patch link: https://lore.kernel.org/r/20260325071951.544031-3-wenst%40chromium.org
patch subject: [PATCH v2 2/5] clk: mediatek: Add mt8173-mfgtop driver
config: csky-randconfig-r073-20260326 (https://download.01.org/0day-ci/archive/20260326/202603261444.jANdMbNC-lkp@intel.com/config)
compiler: csky-linux-gcc (GCC) 11.5.0
smatch: v0.5.0-9004-gb810ac53
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202603261444.jANdMbNC-lkp@intel.com/
smatch warnings:
drivers/clk/mediatek/clk-mt8173-mfgtop.c:163 clk_mt8173_mfgtop_probe() warn: missing error code 'ret'
vim +/ret +163 drivers/clk/mediatek/clk-mt8173-mfgtop.c
edc2074329e271 Chen-Yu Tsai 2026-03-25 153 ret = mtk_clk_register_gates(dev, node, mfg_clks, ARRAY_SIZE(mfg_clks),
edc2074329e271 Chen-Yu Tsai 2026-03-25 154 data->clk_data);
edc2074329e271 Chen-Yu Tsai 2026-03-25 155 if (ret) {
edc2074329e271 Chen-Yu Tsai 2026-03-25 156 dev_err_probe(dev, ret, "Failed to register clock gates\n");
edc2074329e271 Chen-Yu Tsai 2026-03-25 157 goto put_pm_runtime;
edc2074329e271 Chen-Yu Tsai 2026-03-25 158 }
edc2074329e271 Chen-Yu Tsai 2026-03-25 159
edc2074329e271 Chen-Yu Tsai 2026-03-25 160 data->clk_26m = clk_hw_get_clk(data->clk_data->hws[CLK_MFG_26M], "26m");
edc2074329e271 Chen-Yu Tsai 2026-03-25 161 if (IS_ERR(data->clk_26m)) {
edc2074329e271 Chen-Yu Tsai 2026-03-25 162 dev_err_probe(dev, PTR_ERR(data->clk_26m), "Failed to get 26 MHz clock\n");
edc2074329e271 Chen-Yu Tsai 2026-03-25 @163 goto unregister_clks;
ret = dev_err_probe() or ret = PTR_ERR(data->clk_26m)?
edc2074329e271 Chen-Yu Tsai 2026-03-25 164 }
edc2074329e271 Chen-Yu Tsai 2026-03-25 165
edc2074329e271 Chen-Yu Tsai 2026-03-25 166 ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, data->clk_data);
edc2074329e271 Chen-Yu Tsai 2026-03-25 167 if (ret) {
edc2074329e271 Chen-Yu Tsai 2026-03-25 168 dev_err_probe(dev, ret, "Failed to add clk OF provider\n");
edc2074329e271 Chen-Yu Tsai 2026-03-25 169 goto put_26m_clk;
edc2074329e271 Chen-Yu Tsai 2026-03-25 170 }
edc2074329e271 Chen-Yu Tsai 2026-03-25 171
edc2074329e271 Chen-Yu Tsai 2026-03-25 172 data->genpd.name = "mfg-top";
edc2074329e271 Chen-Yu Tsai 2026-03-25 173 data->genpd.power_on = clk_mt8173_mfgtop_power_on;
edc2074329e271 Chen-Yu Tsai 2026-03-25 174 data->genpd.power_off = clk_mt8173_mfgtop_power_off;
edc2074329e271 Chen-Yu Tsai 2026-03-25 175 ret = pm_genpd_init(&data->genpd, NULL, true);
edc2074329e271 Chen-Yu Tsai 2026-03-25 176 if (ret) {
edc2074329e271 Chen-Yu Tsai 2026-03-25 177 dev_err_probe(dev, ret, "Failed to add power domain\n");
edc2074329e271 Chen-Yu Tsai 2026-03-25 178 goto del_clk_provider;
edc2074329e271 Chen-Yu Tsai 2026-03-25 179 }
edc2074329e271 Chen-Yu Tsai 2026-03-25 180
edc2074329e271 Chen-Yu Tsai 2026-03-25 181 ret = of_genpd_add_provider_simple(node, &data->genpd);
edc2074329e271 Chen-Yu Tsai 2026-03-25 182 if (ret) {
edc2074329e271 Chen-Yu Tsai 2026-03-25 183 dev_err_probe(dev, ret, "Failed to add power domain OF provider\n");
edc2074329e271 Chen-Yu Tsai 2026-03-25 184 goto remove_pd;
edc2074329e271 Chen-Yu Tsai 2026-03-25 185 }
edc2074329e271 Chen-Yu Tsai 2026-03-25 186
edc2074329e271 Chen-Yu Tsai 2026-03-25 187 ret = of_genpd_add_subdomain(&data->parent_pd, &data->child_pd);
edc2074329e271 Chen-Yu Tsai 2026-03-25 188 if (ret) {
edc2074329e271 Chen-Yu Tsai 2026-03-25 189 dev_err_probe(dev, ret, "Failed to link PM domains\n");
edc2074329e271 Chen-Yu Tsai 2026-03-25 190 goto del_pd_provider;
edc2074329e271 Chen-Yu Tsai 2026-03-25 191 }
edc2074329e271 Chen-Yu Tsai 2026-03-25 192
edc2074329e271 Chen-Yu Tsai 2026-03-25 193 pm_runtime_put(dev);
edc2074329e271 Chen-Yu Tsai 2026-03-25 194 return 0;
edc2074329e271 Chen-Yu Tsai 2026-03-25 195
edc2074329e271 Chen-Yu Tsai 2026-03-25 196 del_pd_provider:
edc2074329e271 Chen-Yu Tsai 2026-03-25 197 of_genpd_del_provider(node);
edc2074329e271 Chen-Yu Tsai 2026-03-25 198 remove_pd:
edc2074329e271 Chen-Yu Tsai 2026-03-25 199 pm_genpd_remove(&data->genpd);
edc2074329e271 Chen-Yu Tsai 2026-03-25 200 del_clk_provider:
edc2074329e271 Chen-Yu Tsai 2026-03-25 201 of_clk_del_provider(node);
edc2074329e271 Chen-Yu Tsai 2026-03-25 202 put_26m_clk:
edc2074329e271 Chen-Yu Tsai 2026-03-25 203 clk_put(data->clk_26m);
edc2074329e271 Chen-Yu Tsai 2026-03-25 204 unregister_clks:
edc2074329e271 Chen-Yu Tsai 2026-03-25 205 mtk_clk_unregister_gates(mfg_clks, ARRAY_SIZE(mfg_clks), data->clk_data);
edc2074329e271 Chen-Yu Tsai 2026-03-25 206 put_pm_runtime:
edc2074329e271 Chen-Yu Tsai 2026-03-25 207 pm_runtime_put(dev);
edc2074329e271 Chen-Yu Tsai 2026-03-25 208 put_of_node:
edc2074329e271 Chen-Yu Tsai 2026-03-25 209 of_node_put(data->parent_pd.np);
edc2074329e271 Chen-Yu Tsai 2026-03-25 210 return ret;
edc2074329e271 Chen-Yu Tsai 2026-03-25 211 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: freescale: add i.MX91 9x9 QSB basic support
From: Joy Zou @ 2026-03-26 7:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Joy Zou,
Daniel Baluta
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-0-b991b81639e6@nxp.com>
Add i.MX91 9x9 Quick Start Board support.
- Enable ADC1.
- Enable lpuart1.
- Enable network eqos.
- Enable I2C bus and children nodes under I2C bus.
- Enable USB and related nodes.
- Enable uSDHC1 and uSDHC2.
- Enable Watchdog3.
The board description can refer to the following link:
https://www.nxp.com/design/design-center/development-boards-and-designs/IMX91QSB
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
---
Changes in v2:
1. Correct GPIO pin number typo: <&gpio3 00 GPIO_ACTIVE_LOW> to <&gpio3 0 GPIO_ACTIVE_LOW>.
2. Add whitespace before brace in BUCK4 node.
3. Remove one level of indentation for rtc node.
4. Remove clock-frequency property from mdio node.
5. add Reviewed-by tag.
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts | 425 ++++++++++++++++++++++++
2 files changed, 426 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index bae24b53bce6d33a6929d7c6b3f8c1a70911c5d0..382094fa220ab6c388d182be179a82eefed74b45 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -412,6 +412,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8qxp-tqma8xqp-mba8xx.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8qxp-tqma8xqps-mb-smarc-2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8ulp-9x9-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8ulp-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx91-9x9-qsb.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-frdm-s.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
new file mode 100644
index 0000000000000000000000000000000000000000..1239bbf579da44ab3f4be2dc566c53a1e5db6c05
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-9x9-qsb.dts
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx91.dtsi"
+
+/ {
+ compatible = "fsl,imx91-9x9-qsb", "fsl,imx91";
+ model = "NXP i.MX91 9x9 Quick Start Board";
+
+ aliases {
+ ethernet0 = &fec;
+ ethernet1 = &eqos;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ rtc0 = &bbnsm_rtc;
+ serial0 = &lpuart1;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ reg_vref_1v8: regulator-adc-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref_1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VSD_3V3";
+ off-on-delay-us = <12000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x10000000>;
+ linux,cma-default;
+ };
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+&eqos {
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+ pinctrl-0 = <&pinctrl_eqos>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <5000000>;
+
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ realtek,clkout-disable;
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX91_PAD_ENET1_MDC__ENET1_MDC 0x57e
+ MX91_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
+ MX91_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
+ MX91_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
+ MX91_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
+ MX91_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
+ MX91_PAD_ENET1_RXC__ENET_QOS_RGMII_RXC 0x5fe
+ MX91_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
+ MX91_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
+ MX91_PAD_ENET1_TD1__ENET1_RGMII_TD1 0x57e
+ MX91_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
+ MX91_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
+ MX91_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x5fe
+ MX91_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
+ >;
+ };
+
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <
+ MX91_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
+ MX91_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <
+ MX91_PAD_I2C2_SCL__LPI2C2_SCL 0x40000b9e
+ MX91_PAD_I2C2_SDA__LPI2C2_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_pcal6524: pcal6524grp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO1__GPIO3_IO26 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX91_PAD_SD2_RESET_B__GPIO3_IO7 0x31e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX91_PAD_UART1_RXD__LPUART1_RX 0x31e
+ MX91_PAD_UART1_TXD__LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX91_PAD_SD1_CLK__USDHC1_CLK 0x1582
+ MX91_PAD_SD1_CMD__USDHC1_CMD 0x1382
+ MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x1382
+ MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x1382
+ MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x1382
+ MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x1382
+ MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x1382
+ MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x1382
+ MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x1382
+ MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x1382
+ MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ MX91_PAD_SD1_CMD__USDHC1_CMD 0x138e
+ MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x138e
+ MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x138e
+ MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x138e
+ MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x138e
+ MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x138e
+ MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x138e
+ MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x138e
+ MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x138e
+ MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ MX91_PAD_SD1_CMD__USDHC1_CMD 0x13fe
+ MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe
+ MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe
+ MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe
+ MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe
+ MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe
+ MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe
+ MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe
+ MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe
+ MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX91_PAD_SD2_CD_B__GPIO3_IO0 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX91_PAD_SD2_CLK__USDHC2_CLK 0x1582
+ MX91_PAD_SD2_CMD__USDHC2_CMD 0x1382
+ MX91_PAD_SD2_DATA0__USDHC2_DATA0 0x1382
+ MX91_PAD_SD2_DATA1__USDHC2_DATA1 0x1382
+ MX91_PAD_SD2_DATA2__USDHC2_DATA2 0x1382
+ MX91_PAD_SD2_DATA3__USDHC2_DATA3 0x1382
+ MX91_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ MX91_PAD_SD2_CMD__USDHC2_CMD 0x138e
+ MX91_PAD_SD2_DATA0__USDHC2_DATA0 0x138e
+ MX91_PAD_SD2_DATA1__USDHC2_DATA1 0x138e
+ MX91_PAD_SD2_DATA2__USDHC2_DATA2 0x138e
+ MX91_PAD_SD2_DATA3__USDHC2_DATA3 0x138e
+ MX91_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX91_PAD_SD2_CLK__USDHC2_CLK 0x15fe
+ MX91_PAD_SD2_CMD__USDHC2_CMD 0x13fe
+ MX91_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe
+ MX91_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe
+ MX91_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe
+ MX91_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe
+ MX91_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+};
+
+&lpi2c1 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ p3t1085: temperature-sensor@48 {
+ compatible = "nxp,p3t1085";
+ reg = <0x48>;
+ };
+
+ ptn5110: tcpc@50 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x50>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+
+ typec1_con: connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ label = "USB-C";
+ op-sink-microwatt = <15000000>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+ PDO_VAR(5000, 20000, 3000)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+ };
+ };
+
+ pcf2131: rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&lpi2c2 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ pcal6524: gpio@22 {
+ compatible = "nxp,pcal6524";
+ reg = <0x22>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio3>;
+ interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ pinctrl-0 = <&pinctrl_pcal6524>;
+ pinctrl-names = "default";
+ };
+
+ pmic@32 {
+ compatible = "nxp,pf9453";
+ reg = <0x32>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1140000>;
+ regulator-min-microvolt = <1060000>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <900000>;
+ regulator-min-microvolt = <610000>;
+ regulator-ramp-delay = <12500>;
+ };
+
+ buck3: BUCK3 {
+ regulator-name = "BUCK3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3450000>;
+ regulator-min-microvolt = <1650000>;
+ };
+
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3450000>;
+ regulator-min-microvolt = <1650000>;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <1650000>;
+ };
+
+ ldo2: LDO2 {
+ regulator-name = "LDO2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1890000>;
+ regulator-min-microvolt = <760000>;
+ };
+
+ ldo_snvs: LDO-SNVS {
+ regulator-name = "LDO-SNVS";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <1950000>;
+ regulator-min-microvolt = <1650000>;
+ };
+ };
+ };
+};
+
+&lpuart1 {
+ pinctrl-0 = <&pinctrl_uart1>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usbotg1 {
+ adp-disable;
+ disable-over-current;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ usb-role-switch;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usdhc1 {
+ bus-width = <8>;
+ non-removable;
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ fsl,tuning-step = <1>;
+ status = "okay";
+};
+
+&usdhc2 {
+ bus-width = <4>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ no-mmc;
+ no-sdio;
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ vmmc-supply = <®_usdhc2_vmmc>;
+ fsl,tuning-step = <1>;
+ status = "okay";
+};
+
+&wdog3 {
+ fsl,ext-reset-output;
+ status = "okay";
+};
--
2.37.1
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: imx93-9x9-qsb: remove unused property clock-frequency from mdio node
From: Joy Zou @ 2026-03-26 7:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Joy Zou
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-0-b991b81639e6@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
index 7bcebd702106343bde0f084dec6c38d53a985357..01c11c517986a0642d0fedf79a11889c2bf23ae5 100644
--- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
@@ -228,7 +228,6 @@ mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
#size-cells = <0>;
- clock-frequency = <5000000>;
ethphy1: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.37.1
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: imx93-11x11-evk: remove unused property clock-frequency from mdio node
From: Joy Zou @ 2026-03-26 7:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Joy Zou
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-0-b991b81639e6@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx93-11x11-evk-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-common.dtsi b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-common.dtsi
index 7d3fc4ad7b8b7cf213e8ec977589509a7419a04b..f48e7947cf647355c57c82a42a5c0807f53f3a55 100644
--- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-common.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-common.dtsi
@@ -187,7 +187,6 @@ mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
#size-cells = <0>;
- clock-frequency = <5000000>;
ethphy1: ethernet-phy@1 {
reg = <1>;
--
2.37.1
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: imx91-11x11-evk: remove unused property clock-frequency from mdio node
From: Joy Zou @ 2026-03-26 7:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Joy Zou
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-0-b991b81639e6@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
---
arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
index c083b97476a5155b45ead382da22f8bcfd5a4c79..de524f1921de808ee29895852fcbea37565a7e07 100644
--- a/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-11x11-evk.dts
@@ -195,7 +195,6 @@ mdio {
compatible = "snps,dwmac-mdio";
#address-cells = <1>;
#size-cells = <0>;
- clock-frequency = <5000000>;
ethphy1: ethernet-phy@1 {
reg = <1>;
--
2.37.1
^ permalink raw reply related
* [PATCH v2 1/5] dt-bindings: arm: fsl: add i.MX91 9x9 QSB board
From: Joy Zou @ 2026-03-26 7:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Ye Li, Jacky Bai, Peng Fan
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Joy Zou,
Daniel Baluta, Conor Dooley
In-Reply-To: <20260326-b4-imx91-qsb-dts-v2-0-b991b81639e6@nxp.com>
Add compatible string for i.MX91 9x9 Quick Start Board.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v2:
1. add Reviewed-by and Acked-by tag.
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index da2be7114f6417317b3bc904cc5c1953e64e21ea..6a94e0201f704f87df8b5bae0fcae9b2d9133f91 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1458,6 +1458,7 @@ properties:
- description: i.MX91 based Boards
items:
- enum:
+ - fsl,imx91-9x9-qsb # i.MX91 9x9 QSB Board
- fsl,imx91-11x11-evk # i.MX91 11x11 EVK Board
- fsl,imx91-11x11-frdm # FRDM i.MX91 Development Board
- fsl,imx91-11x11-frdm-s # FRDM i.MX91S Development Board
--
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