[PATCH RESEND v8 04/10] spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
sashiko-bot at kernel.org
sashiko-bot at kernel.org
Mon May 11 18:57:59 PDT 2026
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Commit message claims to add spmi_subdevice_put_and_remove() but it is missing
- [Medium] Missing reference count on SPMI controller causes potential Use-After-Free (UAF)
- [Low] Format string type mismatch for controller number in device name
--
commit 481d7c4794f3b580a0e0d422d1a5cc8b6a3b1466
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
This commit introduces spmi_subdevice_alloc_and_add() and a devres variant
to manage complex sub-devices on the SPMI bus. It allows PMIC components
sharing a single SID to be represented as sub-devices. The new exports
are placed in the "SPMI" namespace.
> Add new functions aimed at managing sub-devices of a SPMI device
> spmi_subdevice_alloc_and_add() and a spmi_subdevice_put_and_remove()
This isn't a bug, but the commit message mentions
spmi_subdevice_put_and_remove(), while the implemented function is
actually named spmi_subdevice_remove(). Should the commit message be
updated to match the code?
> diff --git a/drivers/spmi/spmi.c b/drivers/spmi/spmi.c
> index 91a40ea8031ad..cdf3e99194c4c 100644
> --- a/drivers/spmi/spmi.c
> +++ b/drivers/spmi/spmi.c
[ ... ]
> +struct spmi_subdevice *spmi_subdevice_alloc_and_add(struct spmi_device *sparent)
> +{
> + struct spmi_subdevice *sub_sdev;
> + struct spmi_device *sdev;
> + int ret;
> +
> + sub_sdev = kzalloc(sizeof(*sub_sdev), GFP_KERNEL);
> + if (!sub_sdev)
> + return ERR_PTR(-ENOMEM);
> +
> + sdev = &sub_sdev->sdev;
> + sdev->ctrl = sparent->ctrl;
Does this missing reference count on the controller introduce a potential
use-after-free regression?
If the parent PMIC device is removed and drops its reference to the controller,
could the subdevice outlive it and still hold a dangling pointer to
sdev->ctrl? Should this initialization take a reference via
get_device(&sdev->ctrl->dev)?
> + sdev->usid = sparent->usid;
> +
> + ret = ida_alloc(&spmi_subdevice_ida, GFP_KERNEL);
> + if (ret < 0) {
> + kfree(sub_sdev);
> + return ERR_PTR(ret);
> + }
> + sub_sdev->devid = ret;
> +
> + device_initialize(&sdev->dev);
> + sdev->dev.parent = &sparent->dev;
> + sdev->dev.bus = &spmi_bus_type;
> + sdev->dev.type = &spmi_subdev_type;
> +
> + ret = dev_set_name(&sdev->dev, "%d-%02x.%d.auto",
> + sdev->ctrl->nr, sdev->usid, sub_sdev->devid);
This isn't a bug, but could the format specifier for sdev->ctrl->nr
cause a type mismatch warning? Looking at struct spmi_controller, nr is
an unsigned int, so should this use %u instead of %d?
> + if (ret)
> + goto err_put_dev;
> +
> + ret = device_add(&sdev->dev);
> + if (ret) {
> + dev_err(&sdev->dev, "Can't add device, status %pe\n", ERR_PTR(ret));
> + goto err_put_dev;
> + }
> +
> + return sub_sdev;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260511100805.121432-1-angelogioacchino.delregno@collabora.com?part=4
More information about the linux-phy
mailing list