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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, Jul 25, 2022 at 10:29 AM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
>
> On 25/07/2022 19:22, Doug Anderson wrote:
> >>>> You cannot do that...
> >>>
> >>> The bootloader never falls back to just the SoC name.
> >>
> >> There is no "SoC" part of compatible list. Only by convenience we put it
> >> that way, but DT spec does not define first compatible to be for
> >> platform because they all are[1], therefore following your earlier
> >> description - bootloader should load BAR DTS on FOO device just because
> >> qcom,sdm845 matches.
> >
> > As documented in "Documentation/arm/google/chromebook-boot-flow.rst",
> > the bootloader creates a match list to pick a device tree file. It
> > never creates a match list that has just the SoC. It always picks
> > based on the board name and never falls back to just the SoC name.
>
> So this means you embedded some custom-interpretation of board
> compatibles in bootloader. What stops you to customize it even more,
> that the bootloader must always pick the most specific compatible? IOW,
> it cannot load DTB from more generic compatible (just like it should not
> load qcom,sdm845 DTS)?
>
> I understand the limitation of board compatibles for your case, but I
> still believe it is wrong usage of it.
> If the usage - by principle - was correct, then you would not need to
> add the restriction you mentioned above ("never creates a match list
> that has just the SoC").
>
> Because when Linux drivers match, they do not have such restriction...

I think we're essentially re-hashing a previous discussion that led me
writing the documentation of how depthcharge boots. It's probably not
worth rehashing. Depthcharge isn't going to change unless we find a
compelling way to solve all the use cases we described last time we
talked about this. I honestly think the "backwardness" stems from the
fact that in the normal case we start with a dts and pick a driver and
in the FIT image / bootloader case we are picking a dts. Those are
fundamentally different needs.

-Doug



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux