Re: [PATCH] of: property: add i2c-parent to fw_devlink supplier bindings

Rob Herring <[email protected]>
Newsgroups dev.linux.lists.sashiko-reviews,org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
On Fri, Aug 14, 2026 at 01:09:49AM +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] fw_devlink incorrectly parses I2C slave addresses as phandles due to 0-cell supplier binding definition for `i2c-parent`.
> --
> 
> --- Patch [1]: [PATCH] of: property: add i2c-parent to fw_devlink supplier bindings ---
> commit 85f34a66eac871d9e36bccb6795b94b17ab065d4
> Author: Abdurrahman Hussain <[email protected]>
> 
> of: property: add i2c-parent to fw_devlink supplier bindings
> 
> This commit teaches fw_devlink about i2c-parent so the core creates the
> corresponding device links. This ensures consumers are unbound before the
> parent adapter's device, removing the need for -EPROBE_DEFER.
> 
> > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > --- a/drivers/of/property.c
> > +++ b/drivers/of/property.c
> > @@ -1409,6 +1409,7 @@ DEFINE_SIMPLE_PROP(resets, "resets", "#reset-cells")
> >  DEFINE_SIMPLE_PROP(leds, "leds", NULL)
> >  DEFINE_SIMPLE_PROP(backlight, "backlight", NULL)
> >  DEFINE_SIMPLE_PROP(panel, "panel", NULL)
> > +DEFINE_SIMPLE_PROP(i2c_parent, "i2c-parent", NULL)
> 
> [Severity: High]
> Will this correctly handle device tree bindings where the i2c-parent
> property includes a slave address argument?
> 
> For example, platforms using devices like the Toshiba TC9563 PCIe switch
> might use a property such as: i2c-parent = <&qup_i2c 0x77>;
> 
> By passing NULL as the cells argument to DEFINE_SIMPLE_PROP(), the parser
> assumes a 0-cell list. When fw_devlink iterates over the property, it finds
> the first phandle correctly, but won't it erroneously interpret the slave
> address argument (0x77 / 119) as a second, independent 0-cell phandle?
> 
> If another unrelated device tree node happens to match this phandle ID,
> could this cause fw_devlink to link the consumer to the wrong device,
> potentially leading to spurious probe deferrals or circular dependencies?

I think you need custom parsing for this one to read the first cell and 
ignore the 2nd cell if present.

Rob
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.