On 25/07/2022 19:13, Dmitry Baryshkov wrote:
> On Mon, 25 Jul 2022 at 19:18, Krzysztof Kozlowski
> <krzysztof.kozlowski@xxxxxxxxxx> wrote:
>>
>> On 24/07/2022 00:50, Dmitry Baryshkov wrote:
>>> 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.
>>
>> Schema is a tool, we create here bindings. The bindings document what
>> you wrote above, plus compatibles and any other pieces mentioned in DT spec.
>>
>>> 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.
>>
>> Although one of goals is to have schema compliance, that is not the
>> reason why we document compatibles. Compatibles were documented long
>> time ago before DT schema came, because the bindings require it.
>>
>> Bindings define the interface between the DTS and software which uses
>> it. SW is kernel, bootloaders, user-space and some more.
>
> I completely agree here.
>
> From the point of HW/SW interfaces maybe the following compat lists
> would make more sense:
> - "xiaomi,msm8996-phone", "qcom,msm8996"
> - "qcom,qrb5165-iot-platform", "qcom,sm8250"
> - "qcom,sda845-iot-platform", "qcom,sdm845"
> - "inforce,sda660-sbc", "qcom,sda660"
>
> etc. IOW, describing the kind of the device, not the exact name/model of it.
With a specific compatible (covered by pattern), this could work,
although not sure what would be the benefit. Other components, like some
user-space or bootloader might still need the specific compatible.
And if anyone needs a specific compatible, it means it should be documented.
>> To summarize, you propose to not document board compatibles. This is not
>> what we want, because then the next step is - let's don't document SoCs.
>> If you do not document it, means anyone can uniliteraly change it, e.g.
>> in kernel DTS, which will break all other users (e.g. user-space or
>> bootloaders) parsing the compatibles. And before you say - no one parses
>> the board compatibles - let me just say that several user-space
>> (embedded/closed) parse them, bootloaders parse them (U-Boot, Google's
>> Chromebooks and others)
>
> Yes, I know. And in the case of e.g. Google ChromeOS bootloader it
> might make sense to declare compatibles using patterns rather than
> enumeration.
Patterns would simplify here a lot but also would allow (thus not
validate) incorrect combinations. Consider Ssytem-on-Modules:
oneOf:
- items:
- {}
- foo,som-msm8996
- qcom,msm8996
- items:
- {}
- qcom,msm8996
what stops anyone to have a DTS:
"xiaomi,msm8996-phone", "foo,som-msm8996", "qcom,msm8996"
? even though it does not contain that SoM from company Foo?
For DT schema it would be a perfectly valid combination, even though it
would not make any sense. We document valid machines/compatibles as
documentation of the interface but the schema also allows us - with that
documentation - to actually check if DTS is correct.
One more use case are the the qcom,board-id and msm-id properties. They
might once be restricted to specific board compatibles, because maybe
only the closed-bootloader platforms need them. We don't want these
properties in general, thus we might decide to prohibit to use them in
open platforms (e.g. using open bootloader). Without board compatibles
we won't be able to do it.
> Anyway, thank you for your comments, let's continue with documenting
> all the devices until something changes.
>
Best regards,
Krzysztof
