Hi, On Wed, May 11, 2022 at 10:49 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Wed, May 11, 2022 at 10:36 AM Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > > > > * 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. > > Looks plausible to me to make it. > > > > > 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. :) > > I will try to take a quick look to see what this would look like. I looked a bit and decided that unless maintainers agreed that we should do this that it would just be a waste of time. I guess I'll save it for the next time I see Rob... > > > 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. > > I'm still not seeing the help here. Is it somehow going to be easier > for someone to sneak in a dts file to the kernel tree that is just > "sc7180" than it will be to sneak an entry into the bindings that is > just "sc7180"? The people reviewing the dts and the list of allowed > boards in the bindings are the same people, right? Every entry in the > bindings gets used to match exactly one board, so, as I said, it's > pretty much just a question of whether you copy-pasted properly... After a bit of time of copy pasting, we now have a 3-patch series that starts with: https://lore.kernel.org/r/20220512090429.1.I9804fcd5d6c8552ab25f598dd7a3ea71b15b55f0@changeid -Doug
