On Sat, 23 Jul 2022 at 20:48, Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
>
> On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> > Describing each compatible board in DT schema seems wrong to me. It
> > means that each new board is incompatible by default, until added to the DT
> > schema.
s/incompatible/non-valid/
>
> The bindings do not document something because it is or it is no
> compatible. They document the compatible. Your patch essentially removes
> the documentation, so there is no point in having compatibles in board
> at all...
I do not quite agree here. Please correct me if I'm wrong.
Schema defines which DT files are correct and which are not. Which
properties are required, which values are valid, etc. So far so good.
For the device nodes it declares (or is willing to declare) all
possible compatibility strings. There is a sensible number of on-chip
IP blocks, external chips, etc. Each and every new chip (or new IP
block) we are going to have a yaml file describing its usage. Perfect.
For the machine compatibility lists the arm,qcom schema declares which
machine compat strings are valid. And this looks like a problem. Now
for the DT to be fully valid against DT schema, we have to define its
machine compat string.
For each and every phone/sbc/evb we have to name it in schema. I think
this is an overkill. It feels like we are putting DT information
(mapping form machine compat to SoC) into the DT schema.
For qcs404 we already have a schema which uses three items: {},
qcom,qcs404-evb, qcom,qcs404. This sounds like a perfect idea to me.
We allow any board, created by Qualcomm, Google or any other random
vendor, named Foo, Bar or Baz, as long as it declares that it is
compatible with qcom,qcs404-evb.
To go even further. We now have the qrb5165-rb5.dts, declaring
compatible = "qcom,qrb5165-rb5", "qcom,sm8250".
If at some point I add a navigation/communication/whatever mezz on top
of it. It would make sense to use compatible =
"qcom,qrb5165-rb5-navi-comm", "qcom,qrb5165-rb5", "qcom,sm8250".
Adding this to the growing list inside arm,qcom.yaml sounds like a
nightmare. I can only hope that at some point JSON schema gains
postfixItems support (as proposed) to be able to change e.g.
arm,qcom.yaml to list just our qcom,something platforms as possible
postfixItems for the schema.
Regarding having compatibles in board files at all. I think that they
are somehow misused nowadays. Instead of declaring that the
Dragonboard 845c is compatible with "thundercomm,db845c",
"qcom,sdm845-sbc", "96boards,ce-board", "96boards,iot-board",
"qcom,sdm845", the DT file declares nearly useless
"thundercomm,db845c", "qcom,sdm845".
Thus, if we (mostly) use machine compatible array to just define
Vendor+device name and the underlying Qualcomm SoC, I propose to leave
just a sensible part (SoC) in DT schema, while allowing any string in
the first part.
> >Adding support for more and more devices would grow this file
> > indefinitely. Drop most of individual device-specific compatibility
> > strings leaving just list of platforms in place. All entries which
> > differ from two-item string array are left inplace.
--
With best wishes
Dmitry
