linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Doug Anderson <dianders@chromium.org>
Cc: "Krzysztof Kozłowski" <k.kozlowski.k@gmail.com>,
	"Mars Chen" <chenxiangrui@huaqin.corp-partner.google.com>,
	"Andy Gross" <agross@kernel.org>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	"Julius Werner" <jwerner@chromium.org>
Subject: Re: [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie
Date: Sat, 7 May 2022 19:11:33 +0200	[thread overview]
Message-ID: <63b76cc7-4a86-fb78-282e-acb16d09bb36@linaro.org> (raw)
In-Reply-To: <ce2ea308-b63d-ad27-4cea-7353268f8ebb@linaro.org>

On 07/05/2022 19:04, Krzysztof Kozlowski wrote:
> On 06/05/2022 23:33, Doug Anderson wrote:
>> Hi,
>>
>> On Wed, May 4, 2022 at 12:04 AM Krzysztof Kozlowski
>> <krzysztof.kozlowski@linaro.org> wrote:
>>>
>>>>>>> The most specific compatible identifies or, like recently Rob confirmed
>>>>>>> in case of Renesas, the list of compatibles:
>>>>>>> https://lore.kernel.org/linux-devicetree/Yk2%2F0Jf151gLuCGz@robh.at.kernel.org/
>>>>>>
>>>>>> I'm confused. If the device tree contains the compatibles:
>>>>>>
>>>>>> "google,lazor-rev4", "google,lazor-rev3", "google,lazor", "qualcomm,sc7180"
>>>>>>
>>>>>> You want to know what board you're on and you look at the compatible,
>>>>>> right? You'll decide that you're on a "google,lazor-rev4" which is the
>>>>>> most specific compatible. ...but you could have booted a
>>>>>> "google,lazor-rev3". How do you know?
>>>>>
>>>>> Applying the wrong DTB on the wrong device will always give you the
>>>>> wrong answer. You can try too boot google,lazor-rev3 on x86 PC and it
>>>>> does not make it a google,lazor-rev3...
>>>>
>>>> I don't understand what you're saying here. If a device tree has the compatible:
>>>>
>>>> "google,lazor-rev4", "google,lazor-rev3", "google,lazor", "qualcomm,sc7180"
>>>>
>>>> You wouldn't expect to boot it on an x86 PC, but you would expect to
>>>> boot it on either a "google,lazor-rev4" _or_ a "google,lazor-rev3".
>>>
>>> Yes, but booting it does not mean that the hardware is rev3 or rev4.
>>> Booting it means only that we are running DTB on a compatible hardware.
>>> The DTB determines what is accessible to user-space, not what *really*
>>> the hardware is. The user-space (since we are going now to original
>>> question) reads it and can understand that it is running on hardware
>>> compatible with rev3 - either rev3 or rev4 - and act accordingly.
>>>
>>>> Correct? Now, after we've booted software wants to look at the
>>>> compatible of the device tree that was booted. The most specific entry
>>>> in that device tree is "google,lazor-rev4". ...but we could have
>>>> booted it on a "google,lazor-rev3". How can you know?
>>>
>>> No, providing and loading a rev4 DTB on a rev3 board is not correct and
>>> does not make any sense. rev3 boards are not compatible with rev4, it's
>>> the other way. Not every fruit is an apple, but every apple is a fruit.
>>> This is why I used that example - if you load rev4 DTB on rev3 hardware
>>> then you have totally wrong booting process.
>>
>> I think this is the crux of the difference in opinion and there's no
>> reasonable way I'm aware of to do what you're asking. If -rev3 and
>> -rev4 are identical from a software point of view it would be silly
>> not to share a device tree for the two of them. The number of device
>> trees we'd have to land in the kernel tree would be multiplied by
>> several times and we'd have many that are identical except for this
>> compatible string. I see no benefit here and lots of downside.
> 
> Wait, we agreed that you don't consider them identical, didn't we? If
> they are identical, you do not need rev4 at all. So they are not
> identical...
> 
> If they are identical, just use rev3 and problem is gone.
> If they are not identical or you need to assume there will be difference
> (for future), then just go with rev3 without fallback to rev3 and also
> problem is gone.

This should be:
If they are not identical or you need to assume there will be difference
(for future), then just go with rev4 without fallback to rev3 and also
problem is gone.

> 
> Right now it's not possible to validate QCOM DTSes against DT bindings
> because they throw big fat warnings about undocumented top compatibles.
> This is a downside for us.
> 
> Remember, you do not have to use Devicetree or Linux at all if it causes
> you some downsides... No one is forced. :) If you choose to use it,
> sorry, it comes with some requirements like being following Devicetree
> specification or the binding guidelines.
> 
> Best regards,
> Krzysztof


Best regards,
Krzysztof

  reply	other threads:[~2022-05-07 17:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30  9:09 [PATCH] CHROMIUM: arm64: dts: qcom: Add sc7180-gelarshie Mars Chen
2022-03-30 14:21 ` kernel test robot
2022-03-30 17:16 ` Matthias Kaehlcke
2022-03-30 17:23   ` Krzysztof Kozlowski
2022-03-30 22:57   ` Rob Clark
2022-03-30 17:25 ` Krzysztof Kozlowski
2022-04-13 21:48   ` Doug Anderson
2022-04-14  7:10     ` Krzysztof Kozlowski
2022-04-14 17:36       ` Doug Anderson
2022-04-19 15:47         ` Krzysztof Kozlowski
2022-04-19 16:55           ` Doug Anderson
2022-05-03 15:53             ` Krzysztof Kozłowski
2022-05-03 16:13               ` Doug Anderson
2022-05-04  7:04                 ` Krzysztof Kozlowski
2022-05-04 23:56                   ` Julius Werner
2022-05-06 21:33                   ` Doug Anderson
2022-05-07 17:04                     ` Krzysztof Kozlowski
2022-05-07 17:11                       ` Krzysztof Kozlowski [this message]
2022-05-11  2:39                       ` Julius Werner
2022-05-11  7:20                         ` Krzysztof Kozlowski
2022-05-11 16:09                           ` Doug Anderson
2022-05-11 16:57                             ` Bjorn Andersson
2022-05-11 17:36                             ` Krzysztof Kozlowski
2022-05-11 17:49                               ` Doug Anderson
2022-05-12 16:08                                 ` Doug Anderson
2022-03-30 19:17 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=63b76cc7-4a86-fb78-282e-acb16d09bb36@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=chenxiangrui@huaqin.corp-partner.google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=jwerner@chromium.org \
    --cc=k.kozlowski.k@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).