Re: [PATCH] ASoC: core: add snd_BUG_ON() check in devm_snd_soc_register_card()

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 8/3/2026 1:58 PM, Bui Duc Phuc wrote:

>> Not sure whether we need such defenses. If we are to follow such
>> approach, many ASoC-driver APIs require BUG_ON/WARN_ON() update.
>>
>> register_card() is typically called as a last step, once 'card' is
>> already allocated. At the same time, the register_card() typically
>> occurs in probe() context of given device so we're always certain the
>> 'dev' is not NULL.
>>
>> TLDR: this is not a UAPI, (obvious) NULL-checks can be skipped.
> 
> I completely understand where you're coming from.
> My thinking was that this function is referenced quite widely
> (currently in 112 files).
> Given how frequently it is used, I felt that adding a simple defensive
> check here
> could make the API a little more robust and help avoid potential
> NULL pointer dereferences for both existing and future callers.
> 
> I wasn't suggesting that every ASoC API should be updated this way.
> I was only thinking of APIs that are used very frequently, especially
> those commonly called from probe paths.
> 
> Also, it's not always obvious to callers what assumptions a core API
> relies on or
> the context in which it is expected to be used.
> 
> That was simply the motivation behind this patch.
snd_BUG_ON() translates to WARN_ON() in debug conditions.  After reading 
the macro documentation, pr_xxx() or equivalents are recommended when 
dealing with invalid arguments.  Same results after grepping for WARNs 
in sound/soc or in general references such as driver/base/core.c - it's 
clear to me the macro is not used as plain null-arg-check.

Updating just one function with the check raises the question when 
reading the file - Why just one devm_snd_xxx() has the check and the 
rest do not?


Kind regards,
Czarek