Hi Marek, Thanks for pointing this out! On Tue, 2020-06-30 at 14:30 +0200, Marek Szyprowski wrote: > Hi > > On 24.06.2020 18:03, Takashi Iwai wrote: > > The module argument passed to snd_card_new() must be a valid non-NULL > > pointer when the module support is enabled. Since ASoC driver passes > > the argument from each snd_soc_card definition, one may forget to set > > the owner field and lead to a NULL module easily. > > > > For catching such an overlook, add a WARN_ON() in snd_card_new(). > > Also, put the card->module assignment in the ifdef block for a very > > minor optimization. > > > > Signed-off-by: Takashi Iwai > > I know that this is intended, but I would like to note that this patch > reveals the following issue on Raspberry Pi 3B with ARM 32bit kernel > compiled from multi_v7_defconfig: > > ------------[ cut here ]------------ > WARNING: CPU: 1 PID: 210 at sound/core/init.c:207 > snd_card_new+0x378/0x398 [snd] > Modules linked in: vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine > bluetooth snd_pcm snd_timer crc32_arm_ce raspberrypi_hwmon snd soundcore > ecdh_generic ecc bcm2835_thermal phy_generic > CPU: 1 PID: 210 Comm: systemd-udevd Not tainted > 5.8.0-rc1-00027-g81033c6b584b #1087 > Hardware name: BCM2835 > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0xd4/0xe8) > [] (dump_stack) from [] (__warn+0xdc/0xf4) > [] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8) > [] (warn_slowpath_fmt) from [] > (snd_card_new+0x378/0x398 [snd]) > [] (snd_card_new [snd]) from [] > (snd_soc_bind_card+0x280/0x99c [snd_soc_core]) > [] (snd_soc_bind_card [snd_soc_core]) from [] > (devm_snd_soc_register_card+0x34/0x6c [snd_soc_core]) > [] (devm_snd_soc_register_card [snd_soc_core]) from > [] (vc4_hdmi_bind+0x43c/0x5f4 [vc4]) > [] (vc4_hdmi_bind [vc4]) from [] > (component_bind_all+0xec/0x24c) > [] (component_bind_all) from [] > (vc4_drm_bind+0xd4/0x174 [vc4]) > [] (vc4_drm_bind [vc4]) from [] > (try_to_bring_up_master+0x160/0x1b0) > [] (try_to_bring_up_master) from [] > (component_master_add_with_match+0xd0/0x104) > [] (component_master_add_with_match) from [] > (vc4_platform_drm_probe+0x9c/0xbc [vc4]) > [] (vc4_platform_drm_probe [vc4]) from [] > (platform_drv_probe+0x6c/0xa4) > [] (platform_drv_probe) from [] > (really_probe+0x210/0x350) > [] (really_probe) from [] > (driver_probe_device+0x5c/0xb4) > [] (driver_probe_device) from [] > (device_driver_attach+0x58/0x60) > [] (device_driver_attach) from [] > (__driver_attach+0x80/0xbc) > [] (__driver_attach) from [] > (bus_for_each_dev+0x68/0xb4) > [] (bus_for_each_dev) from [] > (bus_add_driver+0x130/0x1e8) > [] (bus_add_driver) from [] (driver_register+0x78/0x110) > [] (driver_register) from [] > (do_one_initcall+0x50/0x220) > [] (do_one_initcall) from [] (do_init_module+0x60/0x210) > [] (do_init_module) from [] (load_module+0x1e34/0x2338) > [] (load_module) from [] (sys_finit_module+0xac/0xbc) > [] (sys_finit_module) from [] > (ret_fast_syscall+0x0/0x54) > Exception stack(0xeded9fa8 to 0xeded9ff0) > ... > ---[ end trace 6414689569c2bc08 ]--- > > This warning is not present when booting ARM 64bit kernel, but I suspect > that this is due to the differences in the kernel configuration. It's because vc4 is not yet supported on RPi4. Maxime Rippard is working on it: https://lkml.kernel.org/lkml/20200629142145.aa2vdfkgeugrze4c@gilmour.lan/T/. Regards, Nicolas