Re: Removal of qcom,board-id and qcom,msm-id

[Dmitry Baryshkov]

On 19/05/2022 14:53, Krzysztof Kozlowski wrote:
> On 19/05/2022 13:39, Dmitry Baryshkov wrote:
> > On 19/05/2022 13:44, Krzysztof Kozlowski wrote:
> > > Hi,
> > >
> > > There was an old effort of removal of qcom,board-id and qcom,msm-id
> > > properties from Qualcomm SoC-based boards like [1].
> > >
> > > First approach was to document them, which (obviously) was not well
> > > received [2] [3] [4].
> > >
> > > The solution from Stephen was to encode these in the board compatible,
> > > so bootloader can extract that information. That seemed to receive
> > > positive comments, at least from Rob. [5]
> > >
> > > It was 2015... ~7 years later we are still things doing the same way,
> > > still with undocumented properties: qcom,board-id and qcom,msm-id.
> > >
> > >
> > > I would like to revive that topic, but before I start doing something
> > > pointless - any guidance on last patch from Stephen [5]? Was it ok? Some
> > > early NAKs?
> >
> > I do not quite fancy the idea of using extra tools to process dtb files.
> > At this moment it is possible to concatenate several kernel-generated
> > dtb files together. AOSP developers use this to have an image that boots
> > on both RB3 and RB5 boards.
> >
> > I think that changing compat strings only makes sense if Qualcomm would
> > use such compat strings in future. Otherwise we end up in a position
> > where we have custom bootloaders for the RB3/RB5/etc, but the majority
> > of the board requires extra processing steps.
>
> This was discussed in [2] [3] and [4] (previous links) and did not pass.
>
> Do you have any new arguments for above objections from Arnd, Olof and
> Rob? I don't think patch will get accepted if previous concerns during
> review are not addressed...

I'm not sure if the patches to the dtbTool have landed or not.
Anyway, as I said, I don't think post-processing the dtb is good way to 
go. It makes extremely hard to check that the dtb, used by the kernel or 
being a part of the boot.img, corresponds to this or that compiled dtb.

> > So, I think, we should drop the unspecified usid aliases, document the
> > board-id/msm-id/pmic-id properties and stick with them.
>
> The existing properties need anyway documenting, probably as deprecated
> so the schema can pass, because we cannot fix the bootloaders easly.
>
> > They might be
> > ugly, but they are expected/processed by the majority of devices present
> > in the wild.
>
> Any change in DTS affects only future devices, so not in the wild...

It affects existing devices that have deployed bootloaders. So far we 
could workaround thus by enforcing a single dtb attached to the kernel 
image. However this doesn't play well for the distro (or AOSP) kernels, 
where we'd like to have multiple dtb image attached.

> > > [1]
> > > https://elixir.bootlin.com/linux/v5.18-rc7/source/arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dts#L14
> > >
> > > [2] https://lore.kernel.org/all/7229476.C4So9noUlf@wuerfel/
> > > [3]
> > > https://lore.kernel.org/all/1450371534-10923-20-git-send-email-mtitinger+renesas@xxxxxxxxxxxx/
> > > [4] https://lore.kernel.org/all/20151119153640.GC893@xxxxxxxxxx/
> > > [5]
> > > https://lore.kernel.org/all/1448062280-15406-1-git-send-email-sboyd@xxxxxxxxxxxxxx/


--
With best wishes
Dmitry