lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 5 Jul 2023 11:34:35 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Souradeep Chowdhury <quic_schowdhu@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        Sibi Sankar <quic_sibis@...cinc.com>,
        Rajendra Nayak <quic_rjendra@...cinc.com>
Subject: Re: [PATCH V7 1/2] dt-bindings: firmware: bootstats: Add the dtschema

On 05/07/2023 10:33, Souradeep Chowdhury wrote:
>>> +    $ref: /schemas/types.yaml#/definitions/string-array
>>> +
>>> +  abl-time:
>>> +    description: The property to store the duration of abl in ms.
>>> +    $ref: /schemas/types.yaml#/definitions/string-array
>>
>> I have no clue what this entire binding is about. Nothing can bind to
>> it, no usage explained. Properties are not used to "store the duration".
>> This does not look like suitable for DT, drop entire binding.
> 
> This binding was created as per the suggestion on version 6 of the patch 
> by Arnd. The idea was that these 2 devicetree properties will be used to 
> populate the bootstat values from the bootloader and exposed to the user 
> via /sys/firmware/devicetree/ directly.
> 
> Details in the link below:-
> 
> https://lore.kernel.org/lkml/7d397e67-5d56-4975-98af-1ac9746c07f4@app.fastmail.com/T/#mbdc9ad95fcbb5ad7b56c6996a3933899b42d982c
> 
> Can you suggest any alternative way to represent this as a binding?

Then you should clearly state in the binding how this is going to be
used and who is going to populate it. Not only in the binding but also
in commit msg which currently has 0 rationale and answers to "why". Your
commit msg explained only "what", which is usually obvious and much less
important. Your commit should stand on its own and should clearly
explain why we need this feature at all, what problem it solves.

And before you claim that there is some discussion under link or some
cover letter - these do not matter. Commit and bindings matter.

What's more, I don't think that Arnd's advice is correct here - DT is
suppose to describe hardware or firmware. These properties are coming
from firmware but they are not describing any firmware or hardware
characteristics. Instead they are debugging of current boot status.

I will leave the decision on that for Rob, however anyway binding is
very vague and incorrect, so I would expect he will come with the same
concerns regardless whether it is suitable to DT or is not.



Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ