Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Aaron Kling]

On Fri, Mar 13, 2026 at 3:37 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On Fri, Mar 13, 2026 at 05:19:27AM +0200, Dmitry Baryshkov wrote:
> > On Wed, Mar 11, 2026 at 08:39:37PM -0500, Aaron Kling wrote:
> > > On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@xxxxxxxxxxxx> wrote:
> > > >
> > > > On 3/11/26 2:44 PM, Aaron Kling wrote:
> > > >
> > > > > From: Teguh Sobirin <teguh@xxxxxxxx>
> > > > >
> > > > > This adds a base dtb of everything common between the AYN QCS8550
> > > > > devices. It is intended to be extended by device specific overlays.
> > > > >
> > > > > Signed-off-by: Teguh Sobirin <teguh@xxxxxxxx>
> > > > > Co-developed-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > > > > Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
> > > > > ---
> > > > >   arch/arm64/boot/dts/qcom/Makefile                  |    1 +
> > > > >   arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
>
> Common is not a board, NAK. This could only be DTSI if you provide some
> sort of HARDWARE arguments explaining the common parts of schematics or
> hardware design.
>
> > > > >   2 files changed, 1778 insertions(+)
> > > > > […]
> > > > > +/ {
> > > > > +     model = "AYN QCS8550 Common";
> > > > > +     compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
> > > >
> > > > Huh?.. All existing -common files are .dtsi includes without their own
> > > > model/compatible, and the compile-time "dtbo" support is only used for
> > > > EL2 where we want to apply the same thing to many many devices without
> > > > polluting the tree with extra glue files. I don't see why this should be
> > > > a "common device" with its own compatible string, and not just a dtsi.
> > >
> > > My use case for these devices is Android, using a single base dtb and
> > > variant dtbo's in a single software build. Given the aosp boot image
> > > v4 setup, using individual dtb's would require different vendor_boot
> > > images, which would require multiple build targets. This setup allows
> > > for my use case, while also having individual dtb targets for a
> > > standard Linux use case. To my knowledge, the final device specific
> > > dtb from this is the same as a dtb using a common dtsi.
> >
> > This needs to be explained in the commit message. But do you need then a
> > model/compatible in the default dtb?

This was added because schema checks failed without model and compatible.

> Not enough. We do not add compatibles not representing actual hardware,
> just to streamline boot image handling.
>
> Plus this code is not even truly correct.
>
> We do not write DTS to fulfill broken Android boot process.

I have been trying rather hard to find a reasonable compromise between
mainline requirements and a normal Android use case, something I can
actually ship to normal users. This seemed fairly reasonable to me,
since it can generate standalone dtb's transparently. But if my use
case can never meet submission requirements, then why am I even here,
getting shamed for working on Android? If I have to fork the
device-tree anyways to fit my requirements, then there's no reason for
me to put the time and effort in to submitting something I can't use.
I'd be better off just keeping everything out of tree as googles
kernel-platform supports. And never look at mainline qcom again.

Frustratedly,
Aaron