[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