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

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

[Martin Wetterwald]

Hi,

After moving from 6.18.52 to 6.19 (still present in 7.2.6), the bcm2835
Headphones sound card no longer appears on my Raspberry Pi 3 Model B Rev 1.2
(arm64). 6.18.52 works with the exact same userspace.

dmesg shows:

  Driver 'bcm2835-audio' was unable to register with bus_type 'vchiq-bus'
  because the bus was not initialized.

and /proc/asound/cards reports "--- no soundcards ---".

My kernel is monolithic (no module support), with:

  CONFIG_BCM2835_VCHIQ=y
  CONFIG_SND_BCM2835=y
  CONFIG_BCM2835_VCHIQ_MMAL is not set
  CONFIG_VCHIQ_CDEV is not set

Analysis: both drivers are built in and use module_init(), i.e. the same
initcall level (6), so they run in link order.
vchiq_driver_init() registers vchiq_bus_type, and bcm2835_alsa_driver_init()
registers a driver on that bus, so VCHIQ must run first. In 6.18 it does, but
in 6.19 the order is reversed.
System.map (same initcall level, lower address runs first):

  6.18: vchiq_driver_init            ffff800080646704
        bcm2835_alsa_driver_init     ffff800080646708

  6.19: bcm2835_alsa_driver_init     ffff800080646698
        vchiq_driver_init            ffff80008064669c

In 6.18 both drivers lived under drivers/staging/vc04_services/. In 6.19 the
VCHIQ interface lives in drivers/platform/raspberrypi/, while bcm2835-audio
stayed in drivers/staging/. drivers/Makefile links staging/ before platform/
(line 154/155 in v6.19), which matches the flipped order.

After boot the bus does exist (/sys/bus/vchiq-bus is present); it is only
registered after the audio driver has already failed. Without module support
there is no way to retry.

My suspect is this commit:

  aa125180c673881f88b528600b57865dc158b3a7
  ("platform/raspberrypi: Destage VCHIQ interface")

I could not bisect to a single commit, but what I know for sure is: v6.18.52
works, v6.19 and v7.2.6 fail, and the initcall ordering above explains the
failure.

#regzbot introduced: v6.18..v6.19

Possible fixes I can think of, none tested yet: register the bus earlier (e.g.
postcore_initcall or subsys_initcall for the bus registration in the VCHIQ
interface), or defer the bcm2835-audio registration to a later initcall level.

I'm happy to test patches and I can do it on 1B rev 2, 1B+, 2B, 3B and 4B if
necessary.

Thanks!
Martin

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

[Thorsten Leemhuis]

On 9/21/26 12:07, Martin Wetterwald wrote:

> After moving from 6.18.52 to 6.19 (still present in 7.2.6), the bcm2835
> Headphones sound card no longer appears on my Raspberry Pi 3 Model B Rev 1.2
> (arm64). 6.18.52 works with the exact same userspace.
> [...]
> My suspect is this commit:
> 
>   aa125180c673881f88b528600b57865dc158b3a7
>   ("platform/raspberrypi: Destage VCHIQ interface")
> 
> I could not bisect to a single commit,

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

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

[Jai Luthra]

Hi Martin, Thorsten,

Quoting Thorsten Leemhuis (2026-10-12 18:53:13)
> On 9/21/26 12:07, Martin Wetterwald wrote:
> 
> > After moving from 6.18.52 to 6.19 (still present in 7.2.6), the bcm2835
> > Headphones sound card no longer appears on my Raspberry Pi 3 Model B Rev 1.2
> > (arm64). 6.18.52 works with the exact same userspace.
> > [...]
> > My suspect is this commit:
> > 
> >   aa125180c673881f88b528600b57865dc158b3a7
> >   ("platform/raspberrypi: Destage VCHIQ interface")
> > 
> > I could not bisect to a single commit,
> 
> 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?
> 

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 :-)

> Ciao, Thorsten

Thanks,
Jai

Re: [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@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@ideasonboard.com>
>     Link: https://patch.msgid.link/20251029-vchiq-destage-v3-6-da8d6c83c2c5@ideasonboard.com
>     Signed-off-by: Greg Kroah-Hartman <gregkh@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

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

[Martin Wetterwald]

I also tested current mainline (7.3-rc7), and I confirm the issue is
still there.
Martin

On Tue, Oct 13, 2026 at 9:28 AM Martin Wetterwald <martin@wetterwald.eu> wrote:
>
> 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@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@ideasonboard.com>
> >     Link: https://patch.msgid.link/20251029-vchiq-destage-v3-6-da8d6c83c2c5@ideasonboard.com
> >     Signed-off-by: Greg Kroah-Hartman <gregkh@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

[PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Martin Wetterwald]

Since the VCHIQ interface was moved out of staging, its bus is no longer
guaranteed to be registered before its client drivers. bcm2835-audio,
still in drivers/staging, registers at device_initcall level and now
runs first:

  Driver 'bcm2835-audio' was unable to register with bus_type
  'vchiq-bus' because the bus was not initialized.

Register the bus and the platform driver at subsys_initcall so the bus
exists before any client driver, independently of link order. The
platform driver probe already returns -EPROBE_DEFER while the firmware
is not ready, so probing earlier is safe. When built as modules, this is
equivalent to module_init() and nothing changes.

Tested on Raspberry Pi 1B rev2, 1B+, 2B, 3B and 4B with VCHIQ and
bcm2835-audio both builtin and both as modules.

Fixes: aa125180c673 ("platform/raspberrypi: Destage VCHIQ interface")
Reported-by: Martin Wetterwald <martin@wetterwald.eu>
Link: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
Closes: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
Signed-off-by: Martin Wetterwald <martin@wetterwald.eu>
---
 drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
index e78641703252..d35f5ac5c2e2 100644
--- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
+++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
@@ -1462,7 +1462,7 @@ static int __init vchiq_driver_init(void)
 
 	return ret;
 }
-module_init(vchiq_driver_init);
+subsys_initcall(vchiq_driver_init);
 
 static void __exit vchiq_driver_exit(void)
 {
-- 
2.55.0

Re: [PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Jai Luthra]

Hi Martin,

Thanks for the quick fix.

Quoting Martin Wetterwald (2026-10-13 18:44:35)
> Since the VCHIQ interface was moved out of staging, its bus is no longer
> guaranteed to be registered before its client drivers. bcm2835-audio,
> still in drivers/staging, registers at device_initcall level and now
> runs first:
> 
>   Driver 'bcm2835-audio' was unable to register with bus_type
>   'vchiq-bus' because the bus was not initialized.
> 
> Register the bus and the platform driver at subsys_initcall so the bus
> exists before any client driver, independently of link order. The
> platform driver probe already returns -EPROBE_DEFER while the firmware
> is not ready, so probing earlier is safe. When built as modules, this is
> equivalent to module_init() and nothing changes.
> 
> Tested on Raspberry Pi 1B rev2, 1B+, 2B, 3B and 4B with VCHIQ and
> bcm2835-audio both builtin and both as modules.
> 
> Fixes: aa125180c673 ("platform/raspberrypi: Destage VCHIQ interface")
> Reported-by: Martin Wetterwald <martin@wetterwald.eu>
> Link: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Closes: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Signed-off-by: Martin Wetterwald <martin@wetterwald.eu>

Reviewed-by: Jai Luthra <jai.luthra@ideasonboard.com>

Thanks,
  Jai

> ---
>  drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> index e78641703252..d35f5ac5c2e2 100644
> --- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> +++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> @@ -1462,7 +1462,7 @@ static int __init vchiq_driver_init(void)
>  
>  	return ret;
>  }
> -module_init(vchiq_driver_init);
> +subsys_initcall(vchiq_driver_init);
>  
>  static void __exit vchiq_driver_exit(void)
>  {
> -- 
> 2.55.0
>

Re: [PATCH] platform/raspberrypi: vchiq: register bus at subsys_initcall

[Gaston Gonzalez]

On Tue Oct 13, 2026 at 10:14 AM -03, Martin Wetterwald wrote:
> Since the VCHIQ interface was moved out of staging, its bus is no longer
> guaranteed to be registered before its client drivers. bcm2835-audio,
> still in drivers/staging, registers at device_initcall level and now
> runs first:
>
>   Driver 'bcm2835-audio' was unable to register with bus_type
>   'vchiq-bus' because the bus was not initialized.
>
> Register the bus and the platform driver at subsys_initcall so the bus
> exists before any client driver, independently of link order. The
> platform driver probe already returns -EPROBE_DEFER while the firmware
> is not ready, so probing earlier is safe. When built as modules, this is
> equivalent to module_init() and nothing changes.
>
> Tested on Raspberry Pi 1B rev2, 1B+, 2B, 3B and 4B with VCHIQ and
> bcm2835-audio both builtin and both as modules.
>
> Fixes: aa125180c673 ("platform/raspberrypi: Destage VCHIQ interface")
> Reported-by: Martin Wetterwald <martin@wetterwald.eu>
> Link: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Closes: https://lore.kernel.org/r/CAFERDQ0FpdVvA5VJxOyRAE_pgxnPVmFx1tkZio5R272j6Bs4tg@mail.gmail.com/
> Signed-off-by: Martin Wetterwald <martin@wetterwald.eu>
> ---
>  drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> index e78641703252..d35f5ac5c2e2 100644
> --- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> +++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_arm.c
> @@ -1462,7 +1462,7 @@ static int __init vchiq_driver_init(void)
>  
>  	return ret;
>  }
> -module_init(vchiq_driver_init);
> +subsys_initcall(vchiq_driver_init);
>  
>  static void __exit vchiq_driver_exit(void)
>  {

Hi,

For Raspberry Pi Zero v1.3:

Tested-by: Gaston Gonzalez <gascoar@gmail.com>

Test setup:

- Branch: patch manually applied in staging-next over commit ec1ecf4f23c5
- Setup: RPi Zero v1.3 connected to a HDMI monitor
- OS: standard raspbian with the desktop environment enabled
- Driver built both as a module and built-in.
- The following command was run to test the sound: 'speaker-test -t wav -c 2'
- Result: Both HDMI audio channels worked correctly

I’d be happy to run any additional tests if needed.

Regards,

Gaston