[Question] Dead code in ALSA drivers - functions always returning 0?

[Question] Dead code in ALSA drivers - functions always returning 0?

[Ingyu Jang]

Hi,

I noticed several ALSA driver functions that always return 0, but their
return values are still checked by callers. I wanted to ask whether
these are intentional defensive coding or could be cleaned up.

1. sound/isa/cs423x/cs4236.c - snd_cs423x_pnp_init_mpu()
   This function handles pnp_activate_dev() failure internally by
   setting mpu_port[dev] = SNDRV_AUTO_PORT, then always returns 0.
   The caller checks "< 0" which can never be true.

2. sound/pci/ice1712/ice1712.c - snd_ice1712_chip_init()
   Always returns 0. Callers check "< 0" in snd_ice1712_create()
   and the PM resume path.

3. sound/pci/ice1712/ice1724.c - snd_vt1724_chip_init()
   Always returns 0. Similar pattern to ice1712.

4. sound/pci/vx222/vx222_ops.c - put_xilinx_data()
   Always returns 0. Caller vx2_load_xilinx_binary() checks "< 0".

Are these intentional for potential future error handling, or could
the return value checks be removed?

Thanks,
Ingyu Jang

Re: [Question] Dead code in ALSA drivers - functions always returning 0?

[Takashi Iwai]

On Sat, 31 Jan 2026 09:14:31 +0100,
Ingyu Jang wrote:
> 
> Hi,
> 
> I noticed several ALSA driver functions that always return 0, but their
> return values are still checked by callers. I wanted to ask whether
> these are intentional defensive coding or could be cleaned up.
> 
> 1. sound/isa/cs423x/cs4236.c - snd_cs423x_pnp_init_mpu()
>    This function handles pnp_activate_dev() failure internally by
>    setting mpu_port[dev] = SNDRV_AUTO_PORT, then always returns 0.
>    The caller checks "< 0" which can never be true.
> 
> 2. sound/pci/ice1712/ice1712.c - snd_ice1712_chip_init()
>    Always returns 0. Callers check "< 0" in snd_ice1712_create()
>    and the PM resume path.
> 
> 3. sound/pci/ice1712/ice1724.c - snd_vt1724_chip_init()
>    Always returns 0. Similar pattern to ice1712.
> 
> 4. sound/pci/vx222/vx222_ops.c - put_xilinx_data()
>    Always returns 0. Caller vx2_load_xilinx_binary() checks "< 0".
> 
> Are these intentional for potential future error handling, or could
> the return value checks be removed?

Those are for potential error handling that may be added in future.
But, given that those are all pretty old code, the chance of
extensions should be very low.  OTOH, all those are static local
functions and the compiler should reduce things appropriately.

So, if any, we may clean them up, but the gain would be very small,
likely negligible.


thanks,

Takashi