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

[Val Packett <val@packett.cool>]

On 3/13/26 3:21 PM, Aaron Kling wrote:
> On Fri, Mar 13, 2026 at 12:48 PM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> 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@kernel.org> 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@packett.cool> wrote:
>>>>>>> On 3/11/26 2:44 PM, Aaron Kling wrote:
>>>>>>>
>>>>>>>> From: Teguh Sobirin <teguh@sobir.in>
>>>>>>>>
>>>>>>>> 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@sobir.in>
>>>>>>>> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
>>>>>>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>>>>>>> ---
>>>>>>>>    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