From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Conor.Dooley@microchip.com, mturquette@baylibre.com,
sboyd@kernel.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, palmer@dabbelt.com,
Daire.McNamara@microchip.com
Cc: paul.walmsley@sifive.com, aou@eecs.berkeley.edu,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 6/6] riscv: dts: microchip: add the mpfs' fabric clock control
Date: Fri, 19 Aug 2022 17:06:58 +0300 [thread overview]
Message-ID: <138af26e-8e36-63a0-d3a0-5af866318839@linaro.org> (raw)
In-Reply-To: <19ca2ca1-c678-c669-4214-e92416e37191@microchip.com>
On 19/08/2022 16:48, Conor.Dooley@microchip.com wrote:
> 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?
Uniqueness among entire DTS? I don't think you can, except of course
mentioning it in description. Your driver should handle such DTS -
minimally by gracefully failing but better behaving in some default way.
>
> FWIW I would then have:
> ccc_sw: clock-controller@38400000 {
> 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]$
Yes, although this won't enforce uniqueness.
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-08-19 14:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 12:22 [PATCH 0/6] Add PolarFire SoC Fabric Clock Conditioning Circuitry Support Conor Dooley
2022-08-19 12:22 ` [PATCH 1/6] dt-bindings: clk: rename mpfs-clkcfg binding Conor Dooley
2022-08-19 12:44 ` Krzysztof Kozlowski
2022-08-19 12:22 ` [PATCH 2/6] dt-bindings: clk: document PolarFire SoC fabric clocks Conor Dooley
2022-08-19 12:45 ` Krzysztof Kozlowski
2022-08-19 13:20 ` Conor.Dooley
2022-08-19 12:22 ` [PATCH 3/6] dt-bindings: clk: add PolarFire SoC fabric clock ids Conor Dooley
2022-08-19 12:45 ` Krzysztof Kozlowski
2022-08-19 12:22 ` [PATCH 4/6] clk: microchip: add PolarFire SoC fabric clock support Conor Dooley
2022-08-19 12:22 ` [PATCH 5/6] dt-bindings: riscv: microchip: document icicle reference design Conor Dooley
2022-08-19 12:46 ` Krzysztof Kozlowski
2022-08-19 12:23 ` [PATCH 6/6] riscv: dts: microchip: add the mpfs' fabric clock control Conor Dooley
2022-08-19 12:47 ` Krzysztof Kozlowski
2022-08-19 13:15 ` Conor.Dooley
2022-08-19 13:28 ` Krzysztof Kozlowski
2022-08-19 13:48 ` Conor.Dooley
2022-08-19 14:06 ` Krzysztof Kozlowski [this message]
2022-08-19 14:14 ` Conor.Dooley
2022-08-19 14:22 ` Krzysztof Kozlowski
2022-08-19 14:32 ` Conor.Dooley
2022-08-19 14:35 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=138af26e-8e36-63a0-d3a0-5af866318839@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=Conor.Dooley@microchip.com \
--cc=Daire.McNamara@microchip.com \
--cc=aou@eecs.berkeley.edu \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).