[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c3b8a28d-087f-f973-17db-da9c0fed10dd@linaro.org>
Date: Sun, 15 May 2022 11:54:38 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Jacky Huang <ychuang570808@...il.com>,
Jacky Huang <ychuang3@...oton.com>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc: robh+dt@...nel.org, sboyd@...nel.org, krzk+dt@...nel.org,
arnd@...db.de, olof@...om.net, catalin.marinas@....com,
will@...nel.org, soc@...nel.org, cfli0@...oton.com
Subject: Re: [PATCH V4 3/5] arm64: dts: nuvoton: Add initial support for
MA35D1
On 15/05/2022 07:53, Jacky Huang wrote:
>
> On 2022/5/13 下午 02:57, Krzysztof Kozlowski wrote:
>> On 13/05/2022 08:48, Jacky Huang wrote:
>>>>> +
>>>>> + hxt_24m: hxt_24mhz {
>>>> No underscores in node name. Generic node names, so "clock-X" or
>>>> "clock-some-suffix"
>>> OK, I will modify it as
>>> hxt-24m: hxt-24mhz
>> No, it is not a generic node name. Please read my reply again.
>
> I would modify it as
>
> clock-hxt: clock-hspd-ext-crystal
>
>
>>
>>>>> + compatible = "fixed-clock";
>>>>> + #clock-cells = <0>;
>>>>> + clock-frequency = <24000000>;
>>>> This does not look like property of SoC. Where is this clock defined? In
>>>> the SoC or on the board?
>>> It's an external crystal on the board.
>>> I add this node, because it's the clock source of clock controller.
>>> It always present on all ma35d1 boards.
>>>
Then such clock is not a property of a SoC, but a board. Feel free to
simplify DTS by storing most of the clock node in DTSI, but frequency
should be defined by each board.
Best regards,
Krzysztof
Powered by blists - more mailing lists