[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <26988bcd-4d58-4100-b89c-00e8ef879329@kernel.org>
Date: Tue, 13 Aug 2024 07:55:11 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Ryan Chen <ryan_chen@...eedtech.com>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...econstruct.com.au>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: Re: [PATCH 3/4] dt-bindings: clock: Add AST2700 clock bindings
On 13/08/2024 03:53, Ryan Chen wrote:
>> Drop the define for number of clocks from the header, because it is not a
*NUMBER OF CLOCKS*
>> binding. You can put it in the driver or not, I don't care and do not provide
>> guidance on this because I don't know if it makes sense at all.
>> What I know is that number of clocks is not related to binding. It is not needed
*NUMBER OF CLOCKS*
>> in the binding, either.
>
> Sorry, I am confused.
> if you think that number of clocks is not related to binding.
*NUMBER OF CLOCKS*
> How dtsi claim for clk?
> For example in dtsi.
> include <dt-bindings/clock/aspeed,ast2700-clk.h>
> usb3bhp: usb3bhp {
> ....
> clocks = <&syscon0 SCU0_CLK_GATE_PORTAUSB>;
And where is *NUMBER OF CLOCKS* here? I don't see any problem. No
useless SCU0_CLK_GATE_NUM define here.
> ...
> }
>
> It need for dtsi binding include for clock enable.
>
> If there is no binding clock include file, how device know the clock index?
Just look how ALL other bindings for new platforms are doing it. Why are
we discussing obvious kernel aspects? Spend time to read other drivers
before posting yours.
Best regards,
Krzysztof
Powered by blists - more mailing lists