On 06/05/2022 23:33, Doug Anderson wrote:
> Hi,
>
> On Wed, May 4, 2022 at 12:04 AM Krzysztof Kozlowski
> <[email protected]> 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%[email protected]/
>>>>>
>>>>> 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.
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
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
>> <[email protected]> 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%[email protected]/
>>>>>>
>>>>>> 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
> 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...
Well, they are identical until they're not. We intend them to be
identical. But for practical purposes it does sometimes happen that
two board revisions which were meant to be indistinguishable by
software end up needing to be distinguished at a later point, when
both the hardware and firmware can no longer be changed. We need to
allow an escape hatch for that case. It does not happen often, so just
treating them all as separate boards from the start is not a scalable
solution. DTBs are not free when they all need to be packaged in the
same kernel image.
> 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.
But that's a solvable problem, right? As I understand, what Doug was
initially just asking was whether it made _sense_ to document all of
these... not that we couldn't do it. Then this whole thread went down
a rabbit hole of whether our compatible assignments are allowed in the
first place. If we can compromise on this discussion by just doing
whatever needs to be done to make the tool happy, I think(?) we can
provide that.
> 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.
Woah... that is maybe a bit extreme, don't you think? My understanding
was that Linux tries to support a wide variety of platforms and
devices and can make the necessary compromises where needed to stay
practical. I'm sure you are aware of the numerous hacks, workarounds
and special cases throughout the kernel that enthusiasts put in there
to get their favorite platform working, even if the original
manufacturer never bothered to test with anything but Windows and
blatantly violates common standards. Or how the USB stack has a file
listing custom quirks for hundreds of individual device IDs just to
make hardware work that didn't put any effort into following the spec.
We're not even asking for any of that -- we're here, engaging with you
and trying to find the best way for our platforms to fit cleanly into
your model. All we're asking is to please offer some way that makes
accommodations for the necessary practical concerns that come up when
building devices at our scale. We're open for new suggestions, but
they need to stay within the realm of what we can practically do (e.g.
not ship a wholly separate DTB for each board revision, because that
would grow the kernel image beyond what can fit in the kernel
partitions on our platforms, and would create a notable extra cost in
boot time for our users).
Besides, I don't actually see how this violates the Device Tree
specification? All I see it say about the toplevel compatible property
is that it
> Specifies a list of platform architectures with which this platform is compatible. This property can be used by operating systems in selecting platform specific code.
It doesn't say anything about having to uniquely identify the platform
architecture even if a more generic identifier is good enough to make
all necessary platform-specific code choices for the operating system.
In fact, about compatible properties in general the specification says
> The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices.
Which implies that using a more generic string to cover multiple cases
at once is an intentionally allowed use case.
On 11/05/2022 04:39, Julius Werner wrote:
>> 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...
>
> Well, they are identical until they're not. We intend them to be
> identical. But for practical purposes it does sometimes happen that
> two board revisions which were meant to be indistinguishable by
> software end up needing to be distinguished at a later point, when
> both the hardware and firmware can no longer be changed. We need to
> allow an escape hatch for that case. It does not happen often, so just
> treating them all as separate boards from the start is not a scalable
> solution. DTBs are not free when they all need to be packaged in the
> same kernel image.
You split more important part of my message, ignoring the point.
So you choose they are not identical, fine. Why insisting on adding
fallback compatible while not keeping bindings updated? Just don't add
the compatible and work on rev3 or rev4. Doug even once wrote "_we don't
know_ if -rev7 and -rev8 are compatible", so don't make them compatible.
Don't add fallbacks or some generic unspecified front-compatibles and
just work on revision.
>
>> 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.
>
> But that's a solvable problem, right? As I understand, what Doug was
> initially just asking was whether it made _sense_ to document all of
> these... not that we couldn't do it. Then this whole thread went down
> a rabbit hole of whether our compatible assignments are allowed in the
> first place. If we can compromise on this discussion by just doing
> whatever needs to be done to make the tool happy, I think(?) we can
> provide that.
None of recent patches from Chromium were doing it, even after
complaining from my side, so why do you suddenly believe that it is
"doable"? If yes, please start doing it and fix the DTSes which you
already submitted without bindings.
To remind - entire discussion started with Doug saying it is pure
overhead for him.
>
>> 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.
>
> Woah... that is maybe a bit extreme, don't you think?
Yes, it was sarcasting. :) But yeah, using Linux and DTS comes now with
DT schema. Please document the bindings in DT schema. That's the
drawback of using mainline...
Best regards,
Krzysztof
Hi,
On Wed, May 11, 2022 at 12:20 AM Krzysztof Kozlowski
<[email protected]> wrote:
>
> On 11/05/2022 04:39, Julius Werner wrote:
> >> 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...
> >
> > Well, they are identical until they're not. We intend them to be
> > identical. But for practical purposes it does sometimes happen that
> > two board revisions which were meant to be indistinguishable by
> > software end up needing to be distinguished at a later point, when
> > both the hardware and firmware can no longer be changed. We need to
> > allow an escape hatch for that case. It does not happen often, so just
> > treating them all as separate boards from the start is not a scalable
> > solution. DTBs are not free when they all need to be packaged in the
> > same kernel image.
>
> You split more important part of my message, ignoring the point.
>
> So you choose they are not identical, fine. Why insisting on adding
> fallback compatible while not keeping bindings updated? Just don't add
> the compatible and work on rev3 or rev4. Doug even once wrote "_we don't
> know_ if -rev7 and -rev8 are compatible", so don't make them compatible.
> Don't add fallbacks or some generic unspecified front-compatibles and
> just work on revision.
Somehow, it seems like we keep talking past each other here and it
feels like folks are getting upset and we're not moving forward. Maybe
the right way to make progress is to find some face-to-face time at a
future conference and sit in front of a white board and hash it out.
That being said:
* Without changing our bootloader or having a big explosion in the
number of dts files, we really can't change our scheme. The best we
can do is document it.
* If we want to change our scheme, we'd need to sit down and come to
an agreement that satisfies everyone, if such a thing is possible.
That would only be able to affect future boards. We don't want to
change the bootloader dts loading scheme on old boards.
> >> 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.
> >
> > But that's a solvable problem, right? As I understand, what Doug was
> > initially just asking was whether it made _sense_ to document all of
> > these... not that we couldn't do it. Then this whole thread went down
> > a rabbit hole of whether our compatible assignments are allowed in the
> > first place. If we can compromise on this discussion by just doing
> > whatever needs to be done to make the tool happy, I think(?) we can
> > provide that.
>
> None of recent patches from Chromium were doing it, even after
> complaining from my side, so why do you suddenly believe that it is
> "doable"? If yes, please start doing it and fix the DTSes which you
> already submitted without bindings.
>
> To remind - entire discussion started with Doug saying it is pure
> overhead for him.
I mean, to be fair I said it _seems_ pure overhead and then said that
we could do it if it makes some tools happy. ...but before doing that,
I wanted to make sure it was actually valuable. I still have doubts
about the assertion that the most specific compatible is guaranteed to
uniquely identify hardware. So if the whole reason for doing this is
to make the validation tools happy and there's no other value, then at
least it's plausible to argue that the tools could simply be fixed to
allow this and not shout about it. Now, certainly I'm not arguing that
yaml validation in general is useless. I'm in agreement that we want
dts files to be able to be formally validated because it catches
typos, missing properties, and bugs. I am _only_ saying that I still
haven't seen a good argument for why we need to validate the top-level
compatible string. Since there no properties associated with the
top-level compatible string, it's mostly just checking did some one
copy-paste the compatible string from one file (the dts file) to the
other file (the yaml file) correctly. To me, that does not feel like a
useful check.
The other thing I wanted to make sure was that we weren't just going
to get NAKed later if/when we had to adjust compatible strings on
existing dts files.
In any case, I guess I'll make an attempt to document the compatibles
for existing Chromebooks and we'll see what happens. I'm still not
convinced of the value, but as long as we're not going to get NAKed
for documenting reality it's fine.
-Doug
-Doug
On Wed 11 May 09:09 PDT 2022, Doug Anderson wrote:
> Hi,
>
> On Wed, May 11, 2022 at 12:20 AM Krzysztof Kozlowski
> <[email protected]> wrote:
> >
> > On 11/05/2022 04:39, Julius Werner wrote:
> > >> 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...
> > >
> > > Well, they are identical until they're not. We intend them to be
> > > identical. But for practical purposes it does sometimes happen that
> > > two board revisions which were meant to be indistinguishable by
> > > software end up needing to be distinguished at a later point, when
> > > both the hardware and firmware can no longer be changed. We need to
> > > allow an escape hatch for that case. It does not happen often, so just
> > > treating them all as separate boards from the start is not a scalable
> > > solution. DTBs are not free when they all need to be packaged in the
> > > same kernel image.
> >
> > You split more important part of my message, ignoring the point.
> >
> > So you choose they are not identical, fine. Why insisting on adding
> > fallback compatible while not keeping bindings updated? Just don't add
> > the compatible and work on rev3 or rev4. Doug even once wrote "_we don't
> > know_ if -rev7 and -rev8 are compatible", so don't make them compatible.
> > Don't add fallbacks or some generic unspecified front-compatibles and
> > just work on revision.
>
> Somehow, it seems like we keep talking past each other here and it
> feels like folks are getting upset and we're not moving forward. Maybe
> the right way to make progress is to find some face-to-face time at a
> future conference and sit in front of a white board and hash it out.
> That being said:
>
> * Without changing our bootloader or having a big explosion in the
> number of dts files, we really can't change our scheme. The best we
> can do is document it.
>
> * If we want to change our scheme, we'd need to sit down and come to
> an agreement that satisfies everyone, if such a thing is possible.
> That would only be able to affect future boards. We don't want to
> change the bootloader dts loading scheme on old boards.
>
In particular we don't want to end up with a scheme that requires you to
spin new software for hardware that you think is compatible with the
existing description provided to the software, that would just cause
logistical overhead.
>
> > >> 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.
> > >
> > > But that's a solvable problem, right? As I understand, what Doug was
> > > initially just asking was whether it made _sense_ to document all of
> > > these... not that we couldn't do it. Then this whole thread went down
> > > a rabbit hole of whether our compatible assignments are allowed in the
> > > first place. If we can compromise on this discussion by just doing
> > > whatever needs to be done to make the tool happy, I think(?) we can
> > > provide that.
> >
> > None of recent patches from Chromium were doing it, even after
> > complaining from my side, so why do you suddenly believe that it is
> > "doable"? If yes, please start doing it and fix the DTSes which you
> > already submitted without bindings.
> >
> > To remind - entire discussion started with Doug saying it is pure
> > overhead for him.
>
> I mean, to be fair I said it _seems_ pure overhead and then said that
> we could do it if it makes some tools happy. ...but before doing that,
> I wanted to make sure it was actually valuable. I still have doubts
> about the assertion that the most specific compatible is guaranteed to
> uniquely identify hardware. So if the whole reason for doing this is
> to make the validation tools happy and there's no other value, then at
> least it's plausible to argue that the tools could simply be fixed to
> allow this and not shout about it. Now, certainly I'm not arguing that
> yaml validation in general is useless. I'm in agreement that we want
> dts files to be able to be formally validated because it catches
> typos, missing properties, and bugs. I am _only_ saying that I still
> haven't seen a good argument for why we need to validate the top-level
> compatible string. Since there no properties associated with the
> top-level compatible string, it's mostly just checking did some one
> copy-paste the compatible string from one file (the dts file) to the
> other file (the yaml file) correctly. To me, that does not feel like a
> useful check.
>
> The other thing I wanted to make sure was that we weren't just going
> to get NAKed later if/when we had to adjust compatible strings on
> existing dts files.
>
I don't have a reason for rejecting such changes, as long as it doesn't
affect your ability to run off existing DTBs - but in the end you'd be
the ones suffering most from that...
Regards,
Bjorn
> In any case, I guess I'll make an attempt to document the compatibles
> for existing Chromebooks and we'll see what happens. I'm still not
> convinced of the value, but as long as we're not going to get NAKed
> for documenting reality it's fine.
>
> -Doug
>
> -Doug
On 11/05/2022 18:09, Doug Anderson wrote:
>>
>> So you choose they are not identical, fine. Why insisting on adding
>> fallback compatible while not keeping bindings updated? Just don't add
>> the compatible and work on rev3 or rev4. Doug even once wrote "_we don't
>> know_ if -rev7 and -rev8 are compatible", so don't make them compatible.
>> Don't add fallbacks or some generic unspecified front-compatibles and
>> just work on revision.
>
> Somehow, it seems like we keep talking past each other here and it
> feels like folks are getting upset and we're not moving forward. Maybe
> the right way to make progress is to find some face-to-face time at a
> future conference and sit in front of a white board and hash it out.
> That being said:
>
> * Without changing our bootloader or having a big explosion in the
> number of dts files, we really can't change our scheme. The best we
> can do is document it.
That's reasonable.
>
> * If we want to change our scheme, we'd need to sit down and come to
> an agreement that satisfies everyone, if such a thing is possible.
There is open CFP for ELCE 2022 (in Ireland). Maybe we could organize
some session there? But we for sure would need Rob, so the arrangements
should rather focus on him, not on my availability.
> That would only be able to affect future boards.
I would like to say that if you had bindings, then obviously we would
not break them, but since there are no bindings... :)
> We don't want to
> change the bootloader dts loading scheme on old boards.
Understood.
>>>> 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.
>>>
>>> But that's a solvable problem, right? As I understand, what Doug was
>>> initially just asking was whether it made _sense_ to document all of
>>> these... not that we couldn't do it. Then this whole thread went down
>>> a rabbit hole of whether our compatible assignments are allowed in the
>>> first place. If we can compromise on this discussion by just doing
>>> whatever needs to be done to make the tool happy, I think(?) we can
>>> provide that.
>>
>> None of recent patches from Chromium were doing it, even after
>> complaining from my side, so why do you suddenly believe that it is
>> "doable"? If yes, please start doing it and fix the DTSes which you
>> already submitted without bindings.
>>
>> To remind - entire discussion started with Doug saying it is pure
>> overhead for him.
>
> I mean, to be fair I said it _seems_ pure overhead and then said that
> we could do it if it makes some tools happy. ...but before doing that,
> I wanted to make sure it was actually valuable. I still have doubts
> about the assertion that the most specific compatible is guaranteed to
> uniquely identify hardware. So if the whole reason for doing this is
> to make the validation tools happy and there's no other value, then at
> least it's plausible to argue that the tools could simply be fixed to
> allow this and not shout about it.
Instead of adding bindings, you can indeed change/fix the tools. Go
ahead. :)
> Now, certainly I'm not arguing that
> yaml validation in general is useless. I'm in agreement that we want
> dts files to be able to be formally validated because it catches
> typos, missing properties, and bugs. I am _only_ saying that I still
> haven't seen a good argument for why we need to validate the top-level
> compatible string.
I don't feel expert enough on this topic to give you good answer. Which
does not prove that there isn't or there is such good answer.
> Since there no properties associated with the
> top-level compatible string, it's mostly just checking did some one
> copy-paste the compatible string from one file (the dts file) to the
> other file (the yaml file) correctly. To me, that does not feel like a
> useful check.
Still it can detect messing of SoC compatibles or not defining any
board-level compatible thus pretending that someone's board is just
SC7180. Imagine now user-space or bootloader trying to parse it...
BTW, the bindings validation of top-level compatible might actually help
you - to be sure that DTSes have proper compatibles matching what
bootloader expects.
> The other thing I wanted to make sure was that we weren't just going
> to get NAKed later if/when we had to adjust compatible strings on
> existing dts files.
Stable ABI is more of SoC maintainer decision and I see Bjorn responded
here.
> In any case, I guess I'll make an attempt to document the compatibles
> for existing Chromebooks and we'll see what happens. I'm still not
> convinced of the value, but as long as we're not going to get NAKed
> for documenting reality it's fine.
Best regards,
Krzysztof