On 2023-06-27 11:07:22, Krzysztof Kozlowski wrote:

On 27/06/2023 11:02, Marijn Suijten wrote:

quoted

quoted

quoted

quoted

quoted

So deleting a new item at the end does not matter.  But what if I respin
this patch to add the new clock _at the end_, which will then be at the
same index as the previous GCC_DISP_AHB_CLK?

I think you know the answer, right? What do you want to prove? That two
independent changes can have together negative effect? We know this.

The question is whether this is allowed?

That would be an ABI break and I already explained if it is or is not
allowed.

How should we solve it then, if we cannot remove GCC_DISP_AHB_CLK in one
patch and add GCC_DISP_GPLL0_DIV_CLK_SRC **at the end** in the next
patch?  Keep an empty spot at the original index of GCC_DISP_AHB_CLK?

I don't know if you are trolling me or really asking question, so just
in case it is the latter:

Apologies if it comes across that way, but I am genuinely
misunderstanding what is and is not allowed as part of this ABI...

"No one is locked into the ABI. SoC maintainer decides on this. "

Especially if it is up to the SoC mantainer.

Also:
https://lore.kernel.org/linux-arm-msm/20230608152759.GA2721945-robh@kernel.org/ (local)

https://lore.kernel.org/linux-arm-msm/CAL_JsqKOq+PdjUPVYqdC7QcjGxp-KbAG_O9e+zrfY7k-wRr1QQ@mail.gmail.com/ (local)

https://lore.kernel.org/linux-arm-msm/20220602143245.GA2256965-robh@kernel.org/ (local)

https://lore.kernel.org/linux-arm-msm/20220601202452.GA365963-robh@kernel.org/ (local)

Any many more.

In that sense the question above is not for you, but for the SoC
maintainer?  Whom, I hope, will say that we can be lenient in changing
the ABI for a platform that is only slowly being brought up by a bunch
of community developers and unlikely to be touched by anyone else.

Thanks for helping out so far!

- Marijn