Re: [PATCH v1 0/7] Add rtc refclk support for PolarFire SoC

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Conor Dooley <mail@conchuod.ie>,
	Conor Dooley <conor.dooley@microchip.com>,
	mturquette@baylibre.com, sboyd@kernel.org, aou@eecs.berkeley.edu,
	paul.walmsley@sifive.com, palmer@rivosinc.com,
	a.zummo@towertech.it, alexandre.belloni@bootlin.com,
	robh+dt@kernel.org, krzk+dt@kernel.org
Cc: daire.mcnamara@microchip.com, linux-rtc@vger.kernel.org,
	devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH v1 0/7] Add rtc refclk support for PolarFire SoC
Date: Sat, 9 Apr 2022 12:45:11 +0200	[thread overview]
Message-ID: <ed73017f-54d0-b303-1557-b6086ce2d155@linaro.org> (raw)
In-Reply-To: <cc11d576-3670-ff0a-e0a1-e92780a04c2a@conchuod.ie>

On 08/04/2022 17:29, Conor Dooley wrote:
> 
> 
> On 08/04/2022 15:57, Krzysztof Kozlowski wrote:
>> On 08/04/2022 16:36, Conor Dooley wrote:
>>> Hey,
>>> As I mentioned in my fixes for 5.18 [0], found out that the reference
>>> clock for the rtc is actually missing from the clock driver (and the
>>> dt binding).
>>>
>>> Currently the mpfs clock driver uses a reference clock called the
>>> "msspll", set in the device tree, as the parent for the cpu/axi/ahb
>>> (config) clocks. The frequency of the msspll is determined by the FPGA
>>> bitstream & the bootloader configures the clock to match the bitstream.
>>> The real reference is provided by a 100 or 125 MHz off chip oscillator.
>>>
>>> However, the msspll clock is not actually the parent of all clocks on
>>> the system - the reference clock for the rtc/mtimer actually has the
>>> off chip oscillator as its parent.
>>>
>>> This series enables reading the rate of the msspll clock, converts
>>> the refclock in the device tree to the external reference & adds
>>> the missing rtc reference clock.
>>>
>>> I assume it is okay not to add fixes tags for the rtc dt binding?
>>> Since the clock was previously missing, the binding is wrong, but
>>> idk if that qualifies as a fix?
>>
>> Usually ABI breakage, even if accepted, should be be tagged as fix
>> because it is clearly then a break of other peoples' trees...
>>
> 
> That means either a) do something messy in the clock driver or b) mark
> the whole series as fixes (and roll it into [0]).
> 
> The second option seems far more sensible to me, do you agree?

I think ate part of my sentence... it should be:
"Usually ABI breakage, even if accepted, should NOT be tagged as fix..."

So usually it should not be a fix.

The binding actually could be backported, because the driver changes
bring the real ABI breakage.

Best regards,
Krzysztof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv