Re: [PATCH v5 01/14] media: iris: Add iris vpu bus support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Missing explicit inclusion of `<linux/slab.h>`.
- [Low] Unchecked return value of `dev_set_name()` obscures memory allocation failures.
--

commit 98f1237fb4e4382526cb267a03ee922744bc30d4
Author: Vikash Garodia <vikash.garodia@oss.qualcomm.com>

media: iris: Add iris vpu bus support

This commit introduces the iris-vpu-bus to create a dynamic child device
for firmware loading, setting up a dedicated IOMMU context with a separate
stream ID.

> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_bus.c b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
> new file mode 100644
> index 0000000000000..15ba4d9c563e9
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
> @@ -0,0 +1,69 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/iris_vpu_bus.h>
> +#include <linux/of_device.h>

This isn't a bug, but should linux/slab.h be explicitly included here?

The implementation uses slab allocator functions like kzalloc_obj() and
kfree(), and relying on implicit inclusion could lead to build breakages on
different architectures or in future kernel versions.

[ ... ]

> +struct device *create_iris_vpu_bus_device(struct device *parent_device, const char *name,
> +					  u64 dma_mask, const u32 *iommu_fid)
> +{
> +	struct device *dev;
> +	int ret;
> +
> +	dev = kzalloc_obj(*dev);
> +	if (!dev)
> +		return ERR_PTR(-ENOMEM);
> +
> +	dev->release = release_iris_vpu_bus_device;
> +	dev->bus = &iris_vpu_bus_type;
> +	dev->parent = parent_device;
> +	dev->coherent_dma_mask = dma_mask;
> +	dev->dma_mask = &dev->coherent_dma_mask;
> +
> +	dev_set_name(dev, "%s", name);

Is it safe to ignore the return value of dev_set_name() here?

If memory allocation fails, dev_set_name() returns -ENOMEM and leaves the
device name as NULL. The subsequent call to device_register() handles this
gracefully by returning -EINVAL rather than propagating the original -ENOMEM.

While this does not cause a crash, could dropping the accurate error code
obscure the root out-of-memory cause during debugging?

> +	dev_set_drvdata(dev, (void *)iommu_fid);
> +
> +	ret = device_register(dev);
> +	if (ret) {
> +		put_device(dev);
> +		return ERR_PTR(ret);
> +	}
> +
> +	return dev;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260509-glymur-v5-0-7fbb340c5dbd@oss.qualcomm.com?part=1