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

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:35:12 +0300	[thread overview]
Message-ID: <200e3faf-e377-9fab-7cb2-bbea07be00cf@linaro.org> (raw)
In-Reply-To: <560e80df-4819-1062-50ee-eb1d1d19bae1@microchip.com>

On 19/08/2022 17:32, Conor.Dooley@microchip.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