linux-kernel - Re: [PATCH 6/6] riscv: dts: microchip: add the mpfs' fabric clock control

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: <19ca2ca1-c678-c669-4214-e92416e37191@microchip.com>
Date:   Fri, 19 Aug 2022 13:48:47 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <krzysztof.kozlowski@...aro.org>, <mturquette@...libre.com>,
        <sboyd@...nel.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <palmer@...belt.com>,
        <Daire.McNamara@...rochip.com>
CC:     <paul.walmsley@...ive.com>, <aou@...s.berkeley.edu>,
        <linux-clk@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH 6/6] riscv: dts: microchip: add the mpfs' fabric clock
 control

On 19/08/2022 14:28, Krzysztof Kozlowski wrote:
>> Maybe that is me exploiting the "should", but I was not sure how to
>> include the location in the devicetree.
> 
> Neither node names nor clock names are considered an ABI, but some
> pieces like to rely on them. Now you created such dependency so imagine
> someone prepares a DTSI/DTS with "clock-controller" names for all four
> blocks. How you driver would behave?

-EEXIST, registration fails in the core.

> The DTS would be perfectly valid but driver would not accept it
> (conflicting names) or behave incorrect.
> 
> I think what you need is the clock-output-names property. The core
> schema dtschema/schemas/clock/clock.yaml recommends unified
> interpretation of it - list of names for all the clocks - but accepts
> other uses, e.g. as a prefix.

So could I do `clock-output-names = "ccc_nw";`. That would work for me,
with one question:
How would I enforce the unique-ness of this property, since it would be
a per CCC/clock-controller property? Maybe I missed something, but I
gave it a shot with two different CCC nodes having "ccc_nw" & dtbs_check
did not complain. Up to me to explain the restriction in the dt-bindings
description?

FWIW I would then have:
ccc_sw: clock-controller@...00000 {
	compatible = "microchip,mpfs-ccc";
	reg = <0x0 0x38400000 0x0 0x1000>, <0x0 0x38800000 0x0 0x1000>,
	      <0x0 0x39400000 0x0 0x1000>, <0x0 0x39800000 0x0 0x1000>;
	#clock-cells = <1>;
	clock-output-names = "ccc_sw";
	status = "disabled";
};

& in the binding:
   clock-output-names:
     pattern: ^ccc_[ns][ew]$

As always, thanks for your help. I did look at output names earlier in
the process, but didn't realise I could use it as a prefix.
Conor.