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

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

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...

> 
> 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...

> 
>> [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@baylibre.com/
>> [4] https://lore.kernel.org/all/20151119153640.GC893@linaro.org/
>> [5]
>> https://lore.kernel.org/all/1448062280-15406-1-git-send-email-sboyd@codeaurora.org/
>>
>> Best regards,
>> Krzysztof
> 
> 


Best regards,
Krzysztof