Hi Krzysztof, > Subject: Re: [PATCH 0/6] i2c-imx-lpi2c: add IPG clock > > On 15/08/2022 03:52, Peng Fan wrote: > > Hi Krzysztof, > > > >> Subject: Re: [PATCH 0/6] i2c-imx-lpi2c: add IPG clock > >> > >> On 12/08/2022 07:34, Peng Fan (OSS) wrote: > >>> From: Peng Fan <peng.fan@xxxxxxx> > >>> > >>> The i.MX LPI2C needs PER and IPG clock, not just PER or IPG clock. > >>> This patch is to enable both PER and IPG clock for imx-i2c-lpi2c. > >> > >> This patchset breaks the ABI and is not bisectable. The justification > >> is very limited (one sentence), so not really enough. > > > > ARM32 i.MX7ULP and ARM64 i.MX8QXP/i.MX8ULP all need to use two > clocks, > > PER and IPG. But current dt-bindings and dts, use one clock. > > > > This patchset includes dts changes patch 4 and patch 5. > > Patch 6 is to update driver use two clocks. > > > > I think the patch order in this patchset would not break git bisect, > > it just break ABI. But I not find good way how could not break ABI, > > because only use one clock is wrong whether in dt-bindings or dtbs. > > Driver changes always go via separate branch than DTS, so your patch > breaks git bisect. I already pointed it out in other patch. This is not really > acceptable. Breaking ABI is another problem which could be justified with > your explanation in other cases... but not in this one, since it is easy to make > it backwards compatible, > > > Should I use a fixes tag to dt-bindings, then break ABI is allowed? > > No. For such patch ABI break is also not allowed in that case. Just make the > driver backwards compatible and both problems - non bisectability and ABI > break - go away. One more point that I am not very clear about "non bisectability and ABI break " ABI, I suppose you mean dt-binding, right? The I2C bindings and dts update will go through different tree, I think. So dtbs_check may fail considering the PR merge order. Thanks, Peng. > > Best regards, > Krzysztof