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

[Val Packett]

On 3/13/26 3:21 PM, Aaron Kling wrote:
> On Fri, Mar 13, 2026 at 12:48 PM Dmitry Baryshkov
> <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:
> > On Fri, Mar 13, 2026 at 12:34:21PM -0500, Aaron Kling wrote:
> > > 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.
> > > >
> > > > 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.
> > Well... It's a tough argument. Getting your DTs into mainline would help
> > occasional users that would like to run something else than Android
> > (PmOS or some other distro). Also it ensures that you can run Android
> > even when Google (Qualcomm) EOL the current SM8550 msm-something tree.
> Oh, I'm not working on the downstream kernel either way. The question
> is whether device support gets mainlined or if I keep all support out
> of tree and only update when Google forks the ack from a new lts.

IMO landing everything with proper upstream style and having minimal 
customization/patching during your Android build process to convert it 
into a base dtb + dtbos setup (or a blank base + everything as dtbos 
one?) during would already be really valuable.

> > Speaking about the boot process. I remember that historically it was
> > possible to pass several DTBs in the the Android boot image. Is it no
> > longer the case? Is there any way to identify the boards (I think
> > historical code was using qcom,board-id for that)? Then you would be
> > able to squash all your DTBs in a single boot image.
> That functionality is still there, the concatenated dtb slot in the
> vendor_boot image. Unfortunately for this context, the odm did not
> change those ids per hardware variant. I think they just left them at
> the hdk or qrd default that came with the bsp. I do have to jump some
> software hoops to slot in the correct dtbo to the dtbo partition
> during inline updates because of this, but it's not terrible. And
> that's not something I can reasonably do for the vendor_boot image. To
> my knowledge, there is no way for the bootloader to tell these devices
> apart and any attempt to do so would require a custom abl build,
> probably per variant, which would then desync the boot firmware from
> the official OS, plus make first install more difficult for users,
> both of which I'm trying not to do.

Leaving the default board ID is a classic… but on many old Android 
phones you (read: an intermediate bootloader) can use the cmdline 
injected by ABL to distinguish between models. Nothing like that here?

~val