linux-kernel - Re: [RFC PATCH v3 4/6] dt-bindings: clock: meson: document A1 SoC audio clock controller driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 21 Apr 2024 20:17:16 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Jan Dakinevich <jan.dakinevich@...utedevices.com>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 Jerome Brunet <jbrunet@...libre.com>,
 Michael Turquette <mturquette@...libre.com>, Stephen Boyd
 <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Kevin Hilman <khilman@...libre.com>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
 Philipp Zabel <p.zabel@...gutronix.de>, Jiucheng Xu
 <jiucheng.xu@...ogic.com>, linux-amlogic@...ts.infradead.org,
 linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v3 4/6] dt-bindings: clock: meson: document A1 SoC
 audio clock controller driver

On 21/04/2024 17:35, Jan Dakinevich wrote:
>>>>
>>>>> +        };
>>>>> +
>>>>> +        clkc_audio_vad: clock-controller@...54800 {
>>>>
>>>> Just keep one example. It's basically almost the same.
>>>>
>>>
>>> The worth of this duplication is to show how a clock from second
>>> controller (<&clkc_audio_vad AUD_CLKID_VAD_AUDIOTOP>) is used by first
>>> one. May be it would be better to keep it... What do you think?
>>
>> I don't understand what is worth here. Using clocks is kind of obvious?
>> What's special?
>>
> 
> The special is that the clock "pclk" for "clkc_audio" must be
> <&clkc_audio_vad AUD_CLKID_VAD_AUDIOTOP>. This thing is not obvious. I

So you want to document non-obvious SoC architecture via example, not
via actual documentation. Plus you want to document it for purpose of
..? Isn't this SoC component, so once you write DTSI it is done?

I fail to see any logic in this, but maybe the binding is kind of
special, misrepresented or hardware is different? But the subject
clearly states it is part of SoC, so dunno...

> can keep only "clkc_audio" node here, but reference to "clkc_audio_vad"
> will be undefined in example. Is it okay?

Just like all phandles.

Best regards,
Krzysztof