linux-kernel - Re: [PATCH 01/11] dt-bindings: firmware: arm,scmi: Document assigned-clocks and assigned-clock-rates

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAL_JsqL_EogoKOQ1xwU75=rJSC4o7yV3Jej4vadtacX2Pt3-hw@mail.gmail.com>
Date:   Fri, 17 Mar 2023 09:27:44 -0500
From:   Rob Herring <robh@...nel.org>
To:     Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
Cc:     Sudeep Holla <sudeep.holla@....com>,
        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 Fri, Mar 17, 2023 at 4:59 AM Cristian Ciocaltea
<cristian.ciocaltea@...labora.com> wrote:
>
> 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".

True, but in this case it's really a single consumer because it's all
CPU nodes which are managed together.

> That would avoid duplicating assigned-clock-rates in the CPU nodes.

Wouldn't one node be sufficient?

Thinking more about this, why aren't you using OPP tables to define
CPU frequencies. Assigned-clocks looks like a temporary hack because
you haven't done proper OPP tables.

Rob