On 7/6/2023 2:44 AM, Dmitry Baryshkov wrote:
On 05/07/2023 22:30, Rob Herring wrote:
On Wed, Jul 05, 2023 at 11:34:35AM +0200, Krzysztof Kozlowski wrote:
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@xxxxxxxxxxxxxxxx/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.
My main concern here is not so much having this info in DT, but whether
it's just the start of various properties. Either because there's already
more data and these are just the 2 things you care about now, or because
once we enable this it's an invitation to add more properties.
Boot timing information seems like something multiple platforms might
want and only having 2 stages isn't extensible.
I preferred the previous implementation idea, where the Linux driver
will parse firmware data, instead of bootloader doing something for us.
Not to mention that that approach would allow us to get boot time stats
on older platforms, without waiting (indefinitely) for the platform
vendor to update the bootloader.
Rob
Hi Rob/Krzysztof/Arnd,
We will work on describing the bindings better but can you first give us
clarity on whether this is something that should be represented on the
devicetree and what should be the final approach we need to take for
boot_stats?
Thanks,
Souradeep
