[REGRESSION] bcm2835-audio fails to register on vchiq-bus in monolithic kernels since 6.19 (VCHIQ destaging?)

[Martin Wetterwald]

Hi Jai, Thorsten,

> Hmm, no answer, so it seems nobody really cares. A bisection might help.
> Or at least validating your suspicion, hence: why can't you check the
> parent of aa125180c6738 and aa125180c6738 itself? Or at least the range
> with that commit in it? And is latest 7.3-rc still broken?
>
> Ciao, Thorsten

Thanks Thorsten for the follow up!
I didn't bisect because my image builder tool was not meant for kernel
development: it could only download stable release tarballs signed by Greg.

But now I've found a way around it and I've just bisected the issue! I've
bisected through the 6523 revisions between 6.18 and 6.19-rc1.

(The bisection was made on a Raspberry Pi 1B rev2 this time.)

> aa125180c673881f88b528600b57865dc158b3a7 is the first 'bad' commit
I confirm the issue was introduced by following commit:

> commit aa125180c673881f88b528600b57865dc158b3a7
> Author: Jai Luthra <jai.luthra at ideasonboard.com>
> Date:   Wed Oct 29 16:00:10 2025 +0530
>
>     platform/raspberrypi: Destage VCHIQ interface
>
>     Destage the VCHIQ interface driver to drivers/platform/raspberrypi.
>
>     There is still the remaining TODO item of improving the documentation,
>     which can be handled post destaging.
>
>     Secondly, multimedia drivers like codec and ISP that rely on this
>     interface need to be upstreamed. And lastly, the drivers that facilitate
>     the shared memory between VideoCore and Linux, like the vc-sm-cma driver
>     and vc_mem char driver also need to be upstreamed.
>
>     Signed-off-by: Jai Luthra <jai.luthra at ideasonboard.com>
>     Link: https://patch.msgid.link/20251029-vchiq-destage-v3-6-da8d6c83c2c5@ideasonboard.com
>     Signed-off-by: Greg Kroah-Hartman <gregkh at linuxfoundation.org>

#regzbot introduced: aa125180c673881f88b528600b57865dc158b3a7

> Sorry, this got lost in my inbox last month. It's likely my series that
> destaged VCHIQ broke the ordering as Martin suspects. I always tested with
> modules enabled so didn't encounter this issue.
>
> I'll look into how we can ensure the VCHIQ bus gets registered before
> peripheral drivers (like audio here) when CONFIG_MODULES=n. If someone
> already knows what to do, pointers are appreciated :-)

Thanks Jai!
I'm willing to make the patch, but I'm not familiar with initialization order
in the kernel boot sequence.
Would also love if someone has pointers on good ways to influence order of boot
sequence.

Martin