Re: mainline build failure due to e1d7dc52c3e6 ("ARM: dts: suniv: f1c100s: add CIR DT node")

[Krzysztof Kozlowski]

On 13/12/2022 18:10, Andre Przywara wrote:
> On Tue, 13 Dec 2022 10:52:34 +0000
> "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@xxxxxxxxx> wrote:
> 
> Hi Sudip,
> 
> thanks for the heads up.
> 
>> The latest mainline kernel branch fails to build arm allmodconfig and
>> multi_v5_defconfig with the error:
>>
>> Error: arch/arm/boot/dts/suniv-f1c100s.dtsi:250.30-31 syntax error
>> FATAL ERROR: Unable to parse input tree
> 
> This is because the clock patch hasn't reached Linus' tree yet, as it's
> coming from a different branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/clk-for-6.2
> 
> In the original series I had it in the right order, but I guess the single
> line to add the "CLK_IR" symbol should have been in a separate patch and
> gone along with the DT patches.

No, the patchset was broken in few ways:
1.
https://lore.kernel.org/all/20221107005433.11079-5-andre.przywara@xxxxxxx/
You cannot mix driver changes and the bindings in the same patch.

2. Driver changes cannot go with DTS, thus you created non-bisectable
patchset breaking now Linus and in future - breaking all bisects.

Its applying was also wrong - the sunxi tree had bisectability problem
in its own for-next branch.

In future, please do it the same way as we do with regular updates with
dependencies between drivers+bindings+DTS, so:
1. Binding patch is *always* separate.

2. You have now choice of:
2a. Maintainer puts the binding patch with DTS on the DTS branch and
shares it via stable tag to the driver branch. The driver changes go to
driver branch. The order of pull request is important as changes from
driver branch cannot go to DTS branch.
2b. Submitter: Binding patch goes with drivers, but DTS uses hard-coded
numbers for defines and does not rely on the bindings patch.

> Anyway it should magically solve itself in the next hours/days, I guess.

No, it will not fix itself. Bisectability is broken.

Jernej,
Please be sure that your tree is covered by kernel build robot - all
branches, not only for-next. If it were there, you would receive build
error from the robot that bisectability is broken.

Best regards,
Krzysztof