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
