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

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

[Abdurrahman Hussain]

Platform-device i2c muxes (i2c-mux-reg, i2c-mux-gpio, ...) reference
the bus they multiplex with an i2c-parent phandle and hold a reference
on that adapter from probe until remove. Unlike muxes that are clients
on the parent bus, they live outside the adapter's device hierarchy,
so nothing orders their teardown against it: if the adapter's device
is unbound first — e.g. while reverting a device-tree overlay whose
changeset attached the mux nodes before the controller nodes —
i2c_del_adapter() blocks forever in
wait_for_completion(&adap->dev_released), waiting for a reference that
is only dropped later in the same teardown sequence.

Teach fw_devlink about i2c-parent so the core creates the
corresponding device links: consumers are unbound before the parent
adapter's device, and probe ordering no longer needs -EPROBE_DEFER.

A plain DEFINE_SIMPLE_PROP() cannot be used because the property has
two incompatible layouts: the i2c mux bindings hold a list of bare
phandles (i2c-demux-pinctrl takes several), while toshiba,tc9563 holds
a single phandle followed by an i2c slave-address cell. The two forms
are indistinguishable in the flattened tree, and a 0-cell parse of the
tc9563 form would read the slave address as a phandle, linking the
consumer to whatever node happens to carry that phandle value. Use a
custom parser that only takes entry 0 for toshiba,tc9563 nodes.

Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
---
Changes in v3:
- Fix the tc9563 compatible check: match "pci1179,0623" (the actual
  binding compatible) instead of "toshiba,tc9563", which never matched
  and let the bare-phandle parser misread the i2c slave-address cell as
  a phandle (Sashiko AI review)
- Link to v2: https://patch.msgid.link/20260815-b4-of-property-add-i2c-parent-v2-1-239c6da9e097@nexthop.ai

Changes in v2:
- Use a custom parser instead of DEFINE_SIMPLE_PROP: toshiba,tc9563 puts
  an i2c slave-address cell after the phandle, which a 0-cell parse
  would misread as a phandle (Sashiko AI review, Rob). Kept the full
  phandle-list parse for other users since i2c-demux-pinctrl takes
  several parents; only tc9563 is limited to entry 0
- Move the Signed-off-by into the commit message proper; v1 had it below
  the '---' cutter line where it would be dropped on apply
- Link to v1: https://patch.msgid.link/20260813-b4-of-property-add-i2c-parent-v1-1-a2487e920ce1@nexthop.ai

To: Rob Herring <robh@kernel.org>
To: Saravana Kannan <saravanak@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/of/property.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/drivers/of/property.c b/drivers/of/property.c
index 72cf12907de0..9bf3bc0a5f38 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1471,6 +1471,22 @@ static struct device_node *parse_gpio_compat(struct device_node *np,
 	return sup_args.np;
 }
 
+static struct device_node *parse_i2c_parent(struct device_node *np,
+					    const char *prop_name, int index)
+{
+	if (strcmp(prop_name, "i2c-parent"))
+		return NULL;
+
+	/* tc9563 (pci1179,0623) is <phandle addr>; every other user is bare phandles */
+	if (of_device_is_compatible(np, "pci1179,0623")) {
+		if (index)
+			return NULL;
+		return of_parse_phandle(np, prop_name, 0);
+	}
+
+	return of_parse_phandle(np, prop_name, index);
+}
+
 static struct device_node *parse_interrupts(struct device_node *np,
 					    const char *prop_name, int index)
 {
@@ -1562,6 +1578,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
 	{ .parse_prop = parse_resets, },
 	{ .parse_prop = parse_leds, },
 	{ .parse_prop = parse_backlight, },
+	{ .parse_prop = parse_i2c_parent, },
 	{ .parse_prop = parse_panel, },
 	{ .parse_prop = parse_msi_parent, },
 	{ .parse_prop = parse_pses, },

---
base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
change-id: 20260813-b4-of-property-add-i2c-parent-168c6d7f1934

Best regards,
--  
Abdurrahman Hussain <abdurrahman@nexthop.ai>

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

[Saravana Kannan]

On Sat, Aug 15, 2026 at 8:33 PM Abdurrahman Hussain
<abdurrahman@nexthop.ai> wrote:
>
> Platform-device i2c muxes (i2c-mux-reg, i2c-mux-gpio, ...) reference
> the bus they multiplex with an i2c-parent phandle and hold a reference
> on that adapter from probe until remove. Unlike muxes that are clients
> on the parent bus, they live outside the adapter's device hierarchy,
> so nothing orders their teardown against it: if the adapter's device
> is unbound first — e.g. while reverting a device-tree overlay whose
> changeset attached the mux nodes before the controller nodes —
> i2c_del_adapter() blocks forever in
> wait_for_completion(&adap->dev_released), waiting for a reference that
> is only dropped later in the same teardown sequence.
>
> Teach fw_devlink about i2c-parent so the core creates the
> corresponding device links: consumers are unbound before the parent
> adapter's device, and probe ordering no longer needs -EPROBE_DEFER.
>
> A plain DEFINE_SIMPLE_PROP() cannot be used because the property has
> two incompatible layouts: the i2c mux bindings hold a list of bare
> phandles (i2c-demux-pinctrl takes several), while toshiba,tc9563 holds
> a single phandle followed by an i2c slave-address cell. The two forms
> are indistinguishable in the flattened tree, and a 0-cell parse of the
> tc9563 form would read the slave address as a phandle, linking the
> consumer to whatever node happens to carry that phandle value. Use a
> custom parser that only takes entry 0 for toshiba,tc9563 nodes.
>
> Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> ---
> Changes in v3:
> - Fix the tc9563 compatible check: match "pci1179,0623" (the actual
>   binding compatible) instead of "toshiba,tc9563", which never matched
>   and let the bare-phandle parser misread the i2c slave-address cell as
>   a phandle (Sashiko AI review)
> - Link to v2: https://patch.msgid.link/20260815-b4-of-property-add-i2c-parent-v2-1-239c6da9e097@nexthop.ai
>
> Changes in v2:
> - Use a custom parser instead of DEFINE_SIMPLE_PROP: toshiba,tc9563 puts
>   an i2c slave-address cell after the phandle, which a 0-cell parse
>   would misread as a phandle (Sashiko AI review, Rob). Kept the full

A bit of a tangent, is this a bug in Sashiko bot?
It just dropped me from the reply in the v1 patch set. Any idea why?

-Saravana

>   phandle-list parse for other users since i2c-demux-pinctrl takes
>   several parents; only tc9563 is limited to entry 0
> - Move the Signed-off-by into the commit message proper; v1 had it below
>   the '---' cutter line where it would be dropped on apply
> - Link to v1: https://patch.msgid.link/20260813-b4-of-property-add-i2c-parent-v1-1-a2487e920ce1@nexthop.ai
>
> To: Rob Herring <robh@kernel.org>
> To: Saravana Kannan <saravanak@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/of/property.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 72cf12907de0..9bf3bc0a5f38 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1471,6 +1471,22 @@ static struct device_node *parse_gpio_compat(struct device_node *np,
>         return sup_args.np;
>  }
>
> +static struct device_node *parse_i2c_parent(struct device_node *np,
> +                                           const char *prop_name, int index)
> +{
> +       if (strcmp(prop_name, "i2c-parent"))
> +               return NULL;
> +
> +       /* tc9563 (pci1179,0623) is <phandle addr>; every other user is bare phandles */
> +       if (of_device_is_compatible(np, "pci1179,0623")) {
> +               if (index)
> +                       return NULL;
> +               return of_parse_phandle(np, prop_name, 0);
> +       }
> +
> +       return of_parse_phandle(np, prop_name, index);
> +}
> +
>  static struct device_node *parse_interrupts(struct device_node *np,
>                                             const char *prop_name, int index)
>  {
> @@ -1562,6 +1578,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
>         { .parse_prop = parse_resets, },
>         { .parse_prop = parse_leds, },
>         { .parse_prop = parse_backlight, },
> +       { .parse_prop = parse_i2c_parent, },
>         { .parse_prop = parse_panel, },
>         { .parse_prop = parse_msi_parent, },
>         { .parse_prop = parse_pses, },
>
> ---
> base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
> change-id: 20260813-b4-of-property-add-i2c-parent-168c6d7f1934
>
> Best regards,
> --
> Abdurrahman Hussain <abdurrahman@nexthop.ai>
>

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

[Rob Herring]

On Sun, Aug 16, 2026 at 10:17:08PM -0700, Saravana Kannan wrote:
> On Sat, Aug 15, 2026 at 8:33 PM Abdurrahman Hussain
> <abdurrahman@nexthop.ai> wrote:
> >
> > Platform-device i2c muxes (i2c-mux-reg, i2c-mux-gpio, ...) reference
> > the bus they multiplex with an i2c-parent phandle and hold a reference
> > on that adapter from probe until remove. Unlike muxes that are clients
> > on the parent bus, they live outside the adapter's device hierarchy,
> > so nothing orders their teardown against it: if the adapter's device
> > is unbound first — e.g. while reverting a device-tree overlay whose
> > changeset attached the mux nodes before the controller nodes —
> > i2c_del_adapter() blocks forever in
> > wait_for_completion(&adap->dev_released), waiting for a reference that
> > is only dropped later in the same teardown sequence.
> >
> > Teach fw_devlink about i2c-parent so the core creates the
> > corresponding device links: consumers are unbound before the parent
> > adapter's device, and probe ordering no longer needs -EPROBE_DEFER.
> >
> > A plain DEFINE_SIMPLE_PROP() cannot be used because the property has
> > two incompatible layouts: the i2c mux bindings hold a list of bare
> > phandles (i2c-demux-pinctrl takes several), while toshiba,tc9563 holds
> > a single phandle followed by an i2c slave-address cell. The two forms
> > are indistinguishable in the flattened tree, and a 0-cell parse of the
> > tc9563 form would read the slave address as a phandle, linking the
> > consumer to whatever node happens to carry that phandle value. Use a
> > custom parser that only takes entry 0 for toshiba,tc9563 nodes.
> >
> > Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> > ---
> > Changes in v3:
> > - Fix the tc9563 compatible check: match "pci1179,0623" (the actual
> >   binding compatible) instead of "toshiba,tc9563", which never matched
> >   and let the bare-phandle parser misread the i2c slave-address cell as
> >   a phandle (Sashiko AI review)
> > - Link to v2: https://patch.msgid.link/20260815-b4-of-property-add-i2c-parent-v2-1-239c6da9e097@nexthop.ai
> >
> > Changes in v2:
> > - Use a custom parser instead of DEFINE_SIMPLE_PROP: toshiba,tc9563 puts
> >   an i2c slave-address cell after the phandle, which a 0-cell parse
> >   would misread as a phandle (Sashiko AI review, Rob). Kept the full
> 
> A bit of a tangent, is this a bug in Sashiko bot?
> It just dropped me from the reply in the v1 patch set. Any idea why?

sashiko has configuration for who to reply to rather than reply-all. 
Probably something not right there. 

I think it should be reply-all, but the sashiko maintainers are 
reluctant to enable that and some folks don't want to get the reports.

Rob

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

[Roman Gushchin]

Rob Herring <robh@kernel.org> writes:

> On Sun, Aug 16, 2026 at 10:17:08PM -0700, Saravana Kannan wrote:
>> On Sat, Aug 15, 2026 at 8:33 PM Abdurrahman Hussain
>> <abdurrahman@nexthop.ai> wrote:
>> >
>> > Platform-device i2c muxes (i2c-mux-reg, i2c-mux-gpio, ...) reference
>> > the bus they multiplex with an i2c-parent phandle and hold a reference
>> > on that adapter from probe until remove. Unlike muxes that are clients
>> > on the parent bus, they live outside the adapter's device hierarchy,
>> > so nothing orders their teardown against it: if the adapter's device
>> > is unbound first — e.g. while reverting a device-tree overlay whose
>> > changeset attached the mux nodes before the controller nodes —
>> > i2c_del_adapter() blocks forever in
>> > wait_for_completion(&adap->dev_released), waiting for a reference that
>> > is only dropped later in the same teardown sequence.
>> >
>> > Teach fw_devlink about i2c-parent so the core creates the
>> > corresponding device links: consumers are unbound before the parent
>> > adapter's device, and probe ordering no longer needs -EPROBE_DEFER.
>> >
>> > A plain DEFINE_SIMPLE_PROP() cannot be used because the property has
>> > two incompatible layouts: the i2c mux bindings hold a list of bare
>> > phandles (i2c-demux-pinctrl takes several), while toshiba,tc9563 holds
>> > a single phandle followed by an i2c slave-address cell. The two forms
>> > are indistinguishable in the flattened tree, and a 0-cell parse of the
>> > tc9563 form would read the slave address as a phandle, linking the
>> > consumer to whatever node happens to carry that phandle value. Use a
>> > custom parser that only takes entry 0 for toshiba,tc9563 nodes.
>> >
>> > Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
>> > ---
>> > Changes in v3:
>> > - Fix the tc9563 compatible check: match "pci1179,0623" (the actual
>> >   binding compatible) instead of "toshiba,tc9563", which never matched
>> >   and let the bare-phandle parser misread the i2c slave-address cell as
>> >   a phandle (Sashiko AI review)
>> > - Link to v2: https://patch.msgid.link/20260815-b4-of-property-add-i2c-parent-v2-1-239c6da9e097@nexthop.ai
>> >
>> > Changes in v2:
>> > - Use a custom parser instead of DEFINE_SIMPLE_PROP: toshiba,tc9563 puts
>> >   an i2c slave-address cell after the phandle, which a 0-cell parse
>> >   would misread as a phandle (Sashiko AI review, Rob). Kept the full
>> 
>> A bit of a tangent, is this a bug in Sashiko bot?
>> It just dropped me from the reply in the v1 patch set. Any idea why?

Hm, can you, please, clarify, what do you mean?
https://sashiko.dev/#/patchset/20260813-b4-of-property-add-i2c-parent-v1-1-a2487e920ce1%40nexthop.ai
has your email in to according to the email policy.

Thanks!

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

[Rob Herring]

On Mon, Aug 17, 2026 at 07:36:46PM +0000, Roman Gushchin wrote:
> Rob Herring <robh@kernel.org> writes:
> 
> > On Sun, Aug 16, 2026 at 10:17:08PM -0700, Saravana Kannan wrote:
> >> On Sat, Aug 15, 2026 at 8:33 PM Abdurrahman Hussain
> >> <abdurrahman@nexthop.ai> wrote:
> >> >
> >> > Platform-device i2c muxes (i2c-mux-reg, i2c-mux-gpio, ...) reference
> >> > the bus they multiplex with an i2c-parent phandle and hold a reference
> >> > on that adapter from probe until remove. Unlike muxes that are clients
> >> > on the parent bus, they live outside the adapter's device hierarchy,
> >> > so nothing orders their teardown against it: if the adapter's device
> >> > is unbound first — e.g. while reverting a device-tree overlay whose
> >> > changeset attached the mux nodes before the controller nodes —
> >> > i2c_del_adapter() blocks forever in
> >> > wait_for_completion(&adap->dev_released), waiting for a reference that
> >> > is only dropped later in the same teardown sequence.
> >> >
> >> > Teach fw_devlink about i2c-parent so the core creates the
> >> > corresponding device links: consumers are unbound before the parent
> >> > adapter's device, and probe ordering no longer needs -EPROBE_DEFER.
> >> >
> >> > A plain DEFINE_SIMPLE_PROP() cannot be used because the property has
> >> > two incompatible layouts: the i2c mux bindings hold a list of bare
> >> > phandles (i2c-demux-pinctrl takes several), while toshiba,tc9563 holds
> >> > a single phandle followed by an i2c slave-address cell. The two forms
> >> > are indistinguishable in the flattened tree, and a 0-cell parse of the
> >> > tc9563 form would read the slave address as a phandle, linking the
> >> > consumer to whatever node happens to carry that phandle value. Use a
> >> > custom parser that only takes entry 0 for toshiba,tc9563 nodes.
> >> >
> >> > Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> >> > ---
> >> > Changes in v3:
> >> > - Fix the tc9563 compatible check: match "pci1179,0623" (the actual
> >> >   binding compatible) instead of "toshiba,tc9563", which never matched
> >> >   and let the bare-phandle parser misread the i2c slave-address cell as
> >> >   a phandle (Sashiko AI review)
> >> > - Link to v2: https://patch.msgid.link/20260815-b4-of-property-add-i2c-parent-v2-1-239c6da9e097@nexthop.ai
> >> >
> >> > Changes in v2:
> >> > - Use a custom parser instead of DEFINE_SIMPLE_PROP: toshiba,tc9563 puts
> >> >   an i2c slave-address cell after the phandle, which a 0-cell parse
> >> >   would misread as a phandle (Sashiko AI review, Rob). Kept the full
> >> 
> >> A bit of a tangent, is this a bug in Sashiko bot?
> >> It just dropped me from the reply in the v1 patch set. Any idea why?
> 
> Hm, can you, please, clarify, what do you mean?
> https://sashiko.dev/#/patchset/20260813-b4-of-property-add-i2c-parent-v1-1-a2487e920ce1%40nexthop.ai
> has your email in to according to the email policy.

It has mine, but not Saravana's. The problem is Saravana only gets 
drivers/of/ emails and not all the bindings.

Saravana, If I enable your email, then you will get all the 
sashiko binding replies. Is that okay?

Rob