From: Roman Gushchin <roman.gushchin@linux.dev>
To: Rob Herring <robh@kernel.org>
Cc: Saravana Kannan <saravanak@kernel.org>,
Abdurrahman Hussain <abdurrahman@nexthop.ai>,
sashiko@lists.linux.dev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] of: property: add i2c-parent to fw_devlink supplier bindings
Date: Mon, 17 Aug 2026 19:36:46 +0000 [thread overview]
Message-ID: <7ia4tsosfsj5.fsf@castle.c.googlers.com> (raw)
In-Reply-To: <20260817145906.GB579285-robh@kernel.org> (Rob Herring's message of "Mon, 17 Aug 2026 09:59:06 -0500")
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!
next prev parent reply other threads:[~2026-08-17 19:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 3:33 [PATCH v3] of: property: add i2c-parent to fw_devlink supplier bindings Abdurrahman Hussain
2026-08-17 5:17 ` Saravana Kannan
2026-08-17 14:59 ` Rob Herring
2026-08-17 19:36 ` Roman Gushchin [this message]
2026-08-17 21:00 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7ia4tsosfsj5.fsf@castle.c.googlers.com \
--to=roman.gushchin@linux.dev \
--cc=abdurrahman@nexthop.ai \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=saravanak@kernel.org \
--cc=sashiko@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.