From: <Conor.Dooley@microchip.com>
To: <krzysztof.kozlowski@linaro.org>, <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 14:14:36 +0000 [thread overview]
Message-ID: <f8496006-7487-7b7e-1a53-ec38492dfe70@microchip.com> (raw)
In-Reply-To: <138af26e-8e36-63a0-d3a0-5af866318839@linaro.org>
On 19/08/2022 15:06, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> 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.
It fails not-too-gracefully at the moment, but that could easily be
changed. Truncated base address I suppose would be a meaningful thing
to fall back to afterwards.
>
>>
>> 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.
I know :( I'll respin next week I guess, thanks again.
Conor.
next prev parent reply other threads:[~2022-08-19 14:14 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
2022-08-19 14:14 ` Conor.Dooley [this message]
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=f8496006-7487-7b7e-1a53-ec38492dfe70@microchip.com \
--to=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=krzysztof.kozlowski@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).