Re: [PATCH v10 5/9] mfd: p3h2x4x: Add driver for NXP P3H2x4x i3c hub and on-die regulator

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver incorrectly uses a generic I3C class match (`I3C_CLASS(I3C_DCR_HUB, NULL)`) instead of a vendor-specific match, which will cause it to erroneously bind to any I3C hub from any manufacturer.
--

commit 6fe3cf08b12d16f6874bd262d173580fb662de0e
Author: Aman Kumar Pandey <aman.kumarpandey@nxp.com>
mfd: p3h2x4x: Add driver for NXP P3H2x4x i3c hub and on-die regulator

This commit adds core MFD support for the NXP P3H2x4x family of multiport I3C
hub devices. It allows the devices to connect via I3C/I2C/SMBus and exposes
multiple downstream target ports along with an on-die regulator.

> diff --git a/drivers/mfd/p3h2840.c b/drivers/mfd/p3h2840.c
> new file mode 100644
> index 0000000000000..9bd8cf6980f1e
> --- /dev/null
> +++ b/drivers/mfd/p3h2840.c
[ ... ]
> +static const struct i3c_device_id p3h2x4x_i3c_ids[] = {
> +	I3C_CLASS(I3C_DCR_HUB, NULL),

[Severity: High]
Will this generic class match cause the driver to incorrectly bind to any I3C
hub on the bus?

Because this driver instantiates vendor-specific child devices like
"p3h2x4x-regulator" and "p3h2x4x-i3c-hub", binding to third-party hubs
could prevent proper drivers from loading, or it could cause undefined
behavior if the child drivers attempt to write P3H2x4x-specific registers
to a non-NXP device.

Should this match table be restricted to NXP's Manufacturer ID and specific
Part IDs using I3C_DEVICE() instead?

> +	{ /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(i3c, p3h2x4x_i3c_ids);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525064209.2263045-1-lakshay.piplani@nxp.com?part=5