[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <200e3faf-e377-9fab-7cb2-bbea07be00cf@linaro.org>
Date: Fri, 19 Aug 2022 17:35:12 +0300
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Conor.Dooley@...rochip.com, 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 17:32, Conor.Dooley@...rochip.com wrote:
>> The clock names should not really matter, so if you have conflict of
>> names among multiple controllers, I think driver should embed unit
>> address in the name (as fallback of clock-output-name) and the binding
>> should not enforce specific pattern.
>
> Not sure if you just passed over it, but I agree:
>>> Truncated base address I suppose would be a meaningful thing
>>> to fall back to afterwards.
Yeah, indeed, you mentioned it.
>
> But if the names aren't an ABI, then either there's not much point in
> having the regex at all for clock-output-names or failing the check for
> it does not matter. I'll have a think over the weekend about what
> exactly to do, but I think the driver side of this is clear to me now &
> what not to do in the binding is too.
Yes.
>
>> I can easily imagine a real hardware board design with
>> "sexy_duck_ccc_pll1_out3" clock names. :)
>
> If Alestorm made a board with our FPGA, I could see that..
> I'd buy the t-shirt too!
>
Best regards,
Krzysztof
Powered by blists - more mailing lists