Re: [PATCH v12 3/7] mfd: p3h2x4x: Add driver for NXP P3H2x4x i3c hub and on-die regulator
| Newsgroups | org.infradead.lists.linux-i3c,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The I3C driver incorrectly binds to any generic I3C Hub instead of specifically to NXP P3H2x4x devices. -- commit e3f8613aba897f64df36ad159bade0cf0e0c5cf1 Author: Aman Kumar Pandey <[email protected]> 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 registers the devices via I3C/I2C/SMBus and exposes multiple downstream target ports and an on-die regulator. > diff --git a/drivers/mfd/p3h2840.c b/drivers/mfd/p3h2840.c > new file mode 100644 > index 0000000000000..0a80992d6250a > --- /dev/null > +++ b/drivers/mfd/p3h2840.c [ ... ] > +static const struct i3c_device_id p3h2x4x_i3c_ids[] = { > + I3C_CLASS(I3C_DCR_HUB, NULL), [Severity: High] Does this match table inappropriately bind the driver to any generic I3C Hub instead of specifically NXP P3H2x4x devices? Since p3h2x4x_device_probe_i3c() does not perform manufacturer or part ID validation, could this claim non-NXP hubs and cause child drivers to send proprietary NXP register sequences to them? Should this use the I3C_DEVICE() macro with MIPI_VENDOR_ID_NXP instead? > + { /* sentinel */ }, > +}; > +MODULE_DEVICE_TABLE(i3c, p3h2x4x_i3c_ids); -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3 -- linux-i3c mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-i3c