Hi Krzysztof and Dmitry
Sorry for the late response.
On 12/5/2024 3:32 AM, Dmitry Baryshkov wrote:
On Thu, 5 Dec 2024 at 09:33, Krzysztof Kozlowski <k...@kernel.org> wrote:
On 04/12/2024 11:09, Dmitry Baryshkov wrote:
On Wed, Dec 04, 2024 at 09:02:18AM +0100, Krzysztof Kozlowski wrote:
On Tue, Dec 03, 2024 at 03:41:48PM +0200, Dmitry Baryshkov wrote:
On Tue, Dec 03, 2024 at 09:01:31AM +0100, Krzysztof Kozlowski wrote:
On 03/12/2024 04:31, Abhinav Kumar wrote:
Document the assigned-clock-parents better for the DP controller node
to indicate its functionality better.
You change the clocks entirely, not "document". I would say that's an
ABI break if it really is a Linux requirement. You could avoid any
problems by just dropping the property from binding.
But if you take a look at the existing usage, the proposed change
matches the behaviour. So, I'd say, it's really a change that makes
documentation follow the actual hardware.
Yes, I was trying to document it better and that way adding/extending
more streams becomes easier for the next patches in the series.
First, this should be in the commit msg, instead of "document better to
indicate functionality better".
Second, what is the point of documenting it in the first place if you
can change it and changing has no impact? So maybe just drop?
So, do you suggest setting both of the property descriptions to true? Or
dropping them completely and using unevaluatedProperties instead of
additionalProperties?
Dropping them entirely, without any changes of additionalProperties.
Unless this property was added due to limitation of dtschema?
I don't remember at this point. I think it's worth trying to drop them.
I tried dropping assigned-clock-parents altogether and it seems fine, No
schema/errors of warnings if I also fixup the examples in
qcom,sc7180-mdss.yaml and qcom,sa8775p-mdss.yaml to drop the usage.
So I can go ahead with dropping it.
Thanks
Abhinav
