[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5881d9f-90cc-f7a2-72a3-0701348a03fe@collabora.com>
Date: Fri, 17 Mar 2023 11:59:27 +0200
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: Sudeep Holla <sudeep.holla@....com>, Rob Herring <robh@...nel.org>
Cc: Stephen Boyd <sboyd@...nel.org>,
Cristian Marussi <cristian.marussi@....com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Nicolas Frattaroli <frattaroli.nicolas@...il.com>,
Heiko Stuebner <heiko@...ech.de>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Daniel Drake <drake@...lessm.com>,
Katsuhiro Suzuki <katsuhiro@...suster.net>,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
alsa-devel@...a-project.org, linux-rockchip@...ts.infradead.org,
linux-riscv@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH 01/11] dt-bindings: firmware: arm,scmi: Document
assigned-clocks and assigned-clock-rates
On 3/17/23 00:26, Sudeep Holla wrote:
> On Thu, Mar 16, 2023 at 03:34:17PM -0500, Rob Herring wrote:
>> +Stephen
>>
>> On Wed, Mar 15, 2023 at 01:47:56PM +0200, Cristian Ciocaltea wrote:
>>> Since commit df4fdd0db475 ("dt-bindings: firmware: arm,scmi: Restrict
>>> protocol child node properties") the following dtbs_check warning is
>>> shown:
>>>
>>> rk3588-rock-5b.dtb: scmi: protocol@14: Unevaluated properties are not allowed ('assigned-clock-rates', 'assigned-clocks' were unexpected)
>>
>> I think that's a somewhat questionable use of assigned-clock-rates. It
>> should be located with the consumer rather than the provider IMO. The
>> consumers of those 2 clocks are the CPU nodes.
>>
>
> Agreed. We definitely don't use those in the scmi clk provider driver.
> So NACK for the generic SCMI binding change.
According to [1], "configuration of common clocks, which affect multiple
consumer devices can be similarly specified in the clock provider node".
That would avoid duplicating assigned-clock-rates in the CPU nodes.
[1]
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/clock/clock.yaml
Thanks,
Cristian
Powered by blists - more mailing lists