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
