Re: [PATCH v5 3/7] ASoC: SDCA: expose class SoundWire probe/remove as library

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] sdca: API contract violation causes type confusion risk in class_function_probe()
--

commit d168d671e23f5aecfdc67da7d941b185751c5190
Author: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>

ASoC: SDCA: expose class SoundWire probe/remove as library

This commit splits the internal class_sdw_probe and class_sdw_remove
functions into exported library helpers. Codec-specific SoundWire drivers
can now embed the class state in their own private structure and manage
dev_set_drvdata() themselves to keep per-slave state.

> diff --git a/sound/soc/sdca/sdca_class.c b/sound/soc/sdca/sdca_class.c
> index a092ebaa620aa..0e6dead414959 100644
> --- a/sound/soc/sdca/sdca_class.c
> +++ b/sound/soc/sdca/sdca_class.c
> @@ -136,18 +136,31 @@ static void class_boot_work(struct work_struct *work)
>  	pm_runtime_put_sync(drv->dev);
>  }
>  
> -static int class_sdw_probe(struct sdw_slave *sdw, const struct sdw_device_id *id)
> +/**
> + * sdca_class_probe - SDCA class SoundWire slave probe helper
> + * @sdw: SoundWire slave
> + * @drv: caller-allocated sdca_class_drv storage.  The caller (a codec
> + *       driver, or the built-in class_sdw_driver in this file) owns the
> + *       allocation and sets its own dev_set_drvdata() -- the framework
> + *       does not touch drvdata.  Typically embedded in the codec's own
> + *       priv struct so codec drivers can keep per-slave state.
> + *
> + * Codec-specific SoundWire drivers call this from their .probe after
> + * allocating a struct sdca_class_drv (usually embedded in their own
> + * priv) and setting drvdata to their priv.  The framework fills in the
> + * sdca_class_drv fields, sets up the class regmap, and queues the
> + * deferred boot work.
> + */
> +int sdca_class_probe(struct sdw_slave *sdw, struct sdca_class_drv *drv)

[Severity: Medium]
Does this documentation accurately reflect how struct sdca_class_drv is
fetched by the framework?

If a codec driver embeds struct sdca_class_drv at a non-zero offset within
its private struct and sets drvdata to the private struct, won't this cause
type confusion in class_function_probe()?

sound/soc/sdca/sdca_class_function.c:class_function_probe() {
    ...
    struct sdca_class_drv *core = dev_get_drvdata(dev->parent);
    ...
}

Here, class_function_probe() fetches the parent's drvdata (the SoundWire
device) and blindly casts it to struct sdca_class_drv *.  If the codec
driver's private struct has sdca_class_drv at a non-zero offset, this will
lead to a corrupted pointer.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925161049.758913-1-srinivas.kandagatla@oss.qualcomm.com?part=3