Re: [PATCH] arm64: dts: qcom: ipq9574: Enable eMMC variant

Sumit Garg
2026-01-05T04:39:05Z

On Fri, Jan 02, 2026 at 02:09:04PM -0600, Bjorn Andersson wrote:
> On Fri, Jan 02, 2026 at 12:08:03PM +0100, Krzysztof Kozlowski wrote:
> > On 02/01/2026 11:46, Varadarajan Narayanan wrote:
> > > RDP433 can have NAND or eMMC based on a board level rework. Since the
> > > same GPIOS are used for both the interfaces, only one of them can be
> > > used. Add a new DTS file to disable NAND and enable eMMC.
> > >
> > > Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/Makefile | 2 +-
> > > .../boot/dts/qcom/ipq9574-rdp-common.dtsi | 32 +++++++++++++++++++
> > > .../boot/dts/qcom/ipq9574-rdp433-emmc.dts | 26 +++++++++++++++
> > > 3 files changed, 59 insertions(+), 1 deletion(-)
> > > create mode 100644 arch/arm64/boot/dts/qcom/ipq9574-rdp433-emmc.dts
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > index 6f34d5ed331c..d5fe12ef4300 100644
> > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > @@ -26,7 +26,7 @@ dtb-$(CONFIG_ARCH_QCOM) += ipq8074-hk01.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq8074-hk10-c1.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq8074-hk10-c2.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp418.dtb
> > > -dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp433.dtb
> > > +dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp433.dtb ipq9574-rdp433-emmc.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp449.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp453.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += ipq9574-rdp454.dtb
> > > diff --git a/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi b/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi
> > > index bdb396afb992..e4ae79b2fcd9 100644
> > > --- a/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi
> > > @@ -169,6 +169,38 @@ data-pins {
> > > bias-disable;
> > > };
> > > };
> > > +
> > > + sdc_default_state: sdc-default-state {
> > > + clk-pins {
> > > + pins = "gpio5";
> > > + function = "sdc_clk";
> > > + drive-strength = <8>;
> > > + bias-disable;
> > > + };
> > > +
> > > + cmd-pins {
> > > + pins = "gpio4";
> > > + function = "sdc_cmd";
> > > + drive-strength = <8>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + data-pins {
> > > + pins = "gpio0", "gpio1", "gpio2",
> > > + "gpio3", "gpio6", "gpio7",
> > > + "gpio8", "gpio9";
> > > + function = "sdc_data";
> > > + drive-strength = <8>;
> > > + bias-pull-up;
> > > + };
> > > +
> > > + rclk-pins {
> > > + pins = "gpio10";
> > > + function = "sdc_rclk";
> > > + drive-strength = <8>;
> > > + bias-pull-down;
> > > + };
> > > + };
> > > };
> > >
> > > &qpic_bam {
> > > diff --git a/arch/arm64/boot/dts/qcom/ipq9574-rdp433-emmc.dts b/arch/arm64/boot/dts/qcom/ipq9574-rdp433-emmc.dts
> > > new file mode 100644
> > > index 000000000000..ffd96b1b1c65
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/ipq9574-rdp433-emmc.dts
> > > @@ -0,0 +1,26 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> >
> > Odd license. We don't take GPL v3.
> >
> > > +/*
> > > + * IPQ9574 RDP433 eMMC board variant device tree source
> > > + *
> > > + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "ipq9574-rdp433.dts"
> >
> > I find it discouraged practice. Although if Bjorn is fine with it, you
> > still need proper compatibles.
> >
>
> Nah, I don't fancy including .dts files. But I do see that I've let a
> few of those slip by over the years.
>
> The general approach for these cases has been to rename dts->dtsi and
> create the two dts files.

That sounds better to me.

>
> I wonder though if this would be better served by an overlay, as it's
> the same board, but with modifications applied?

I am not sure how overlay is a better fit here. AFAIK, the DT overlay is
generally used for plug and play hardware mezzanines. But here we are
dealing with the default boot medium which can either be eMMC or NAND.
Can a developer easily reverse the board modifications to boot from a
different medium?

And this DT is not only going to be consumed by the kernel but rather
the bootloader (U-Boot) in this case where there isn't a concept of DT
overlays which the prior stage can apply.

-Sumit