Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

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

On 25/07/2022 18:41, Krzysztof Kozlowski wrote:
> On 25/07/2022 18:25, Doug Anderson wrote:
>> Let's look specifically at the device tree file for the LTE board. One
>> way to look at it is that the dts for the LTE board should have
>> compatibles:
>>   compatible = "lte", "wifi-only"
>>
>> The above matches the normal device tree mentality. It says: "hey, if
>> you've got a lte driver for this board then use it; otherwise use the
>> wifi-only driver".
>>
>> However, the above is actually broken for the bootloader use case. The
>> bootloader is trying to pick a device tree and, to the bootloader, the
>> above says "you can use this dts for either an lte board or a
>> wifi-only board". That's bad. If the bootloader picks this device tree
>> for a wifi-only board then the OS will try to initialize lte and
>> things will crash. To go further, if you think about it things
>> actually work fine if the wifi-only device tree says it's compatible
>> with the LTE board. This is why I say it's opposite... ;-)
> 
> This is not specific to "bootloaders" but your specific implementation
> of entire chain. How you described it, you have dependent pieces -
> user-space must use the same DTB as bootloader chosen, but bootloader
> makes different choices than user-space. It's perfectly fine to make
> these choices different, but then user-space should not depend on
> something which was/was not initialized in bootloader.
> 
> IOW, if bootloader picked up generic WiFi compatible and user-space will
> crash if picking up specific comaptible, you have a dependency and
> user-space should probably bind to modified DTB, where LTE comaptible is
> removed.
> 
> Other systems - I would say most of them - are independent, IOW, we try
> to make kernel and user-space independent of what bootloader did,
> because we are never sure what bootloader actually did and what DTS it
> received.

You can BTW compare it nicely to Linux device driver binding. If a
driver binds to more generic (WiFi) compatible, it is not allowed to use
any features/code related to more specific compatible (LTE).

Your case breaks this rule. Bootloader bound to generic (WiFi)
compatible, but it passed entire DTB/FDT to kernel/user-space which can
then run code for more specific compatible.

Although I understand the point the board compatibles by themself
provide little help for such use case.

Best regards,
Krzysztof