next-20240814: bcm2711-rpi-4-b boot failed

[Stefan Wahren]

Hi,

[add Raspberry Pi kernel list]

Am 14.08.24 um 21:48 schrieb Florian Fainelli:
> On 8/14/24 09:19, Stefan Wahren wrote:
>> Hi Naresh,
>>
>> Am 14.08.24 um 17:26 schrieb Naresh Kamboju:
>>> On Wed, 14 Aug 2024 at 20:54, Naresh Kamboju
>>> <naresh.kamboju at linaro.org> wrote:
>>>> The arm64 kernel booting on bcm2711-rpi-4-b boot failed with
>>>> today's Linux
>>>> next-20240814 tag. The boot failed with half boot log [1]
>>>>
>>>> Reported-by: Linux Kernel Functional Testing <lkft at linaro.org>
>>>>
>>>>   GOOD: next-20240813
>>>>   BAD:  next-20240814
>>>>
>>>> The first investigation show the following to changes and I have
>>>> reverted the
>>>> following two commits and the boot test is back to pass [2].
>>>>
>>>> $ git log --oneline  next-20240813..next-20240814
>>>> arch/arm64/boot/dts/broadcom/
>>>>    6e7b99d720da6 ARM: dts: bcm271x: add missing properties to
>>>> local_intc
>>>>    eb81f43c901ff ARM: dts: bcm2837/bcm2712: adjust local intc node
>>>> names
>>>>
>>> Anders bisected down to first bad commit as,
>>>     6e7b99d720da ("ARM: dts: bcm271x: add missing properties to
>>> local_intc")
>> thank you for the report and sorry about that mess. I don't why i was
>> under the impression they were harmless DT properties. I look into this,
>> so a revert is the proper solution for now.
>
> Without the 'interrupt-controller' of_irq_init() would not be picking
> up the interrupt-controller at 7cd00000 node and it would not attempt to
> register the driver. We can see that the GIC is still the primary
> interrupt controller for that system:
>
> [    0.000000] Root IRQ handler: gic_handle_irq
>
> my suspicion here is that irq-bcm2836.c still wants to own the inter
> processor operations and calls set_smp_ipi_range() which then replaces
> what the GIC has installed, thus diverting all interrupts towards
> itself, when it should not, and that won't work as there is no
> coordination with the ARM GIC driver. Stefan do you know how the VPU
> decides between one interrupt controller versus the other, assuming
> there is even a choice offered to users?
Unfortunately not, i hope someone from the Raspberry Pi guys can tell us.
> Is it via adding/removing the 'interrupt-controller' property, or is
> it via the more conventional 'status' property?
>
> FWIW, I did changes back in the days to support the 7211 sister chip
> of 2711:
>
> https://lore.kernel.org/lkml/20191015185919.GA26464@bogus/T/
Thanks for pointing out, now i better understand the complexity behind
it. So the missing properties were intended.
>
> Dropping the patch for now, thanks!