From: Conor Dooley <conor@kernel.org>
To: Frank Li <Frank.li@oss.nxp.com>
Cc: Shubham Patil <shubhamsanjay.patil@amd.com>,
alexandre.belloni@bootlin.com, Frank.Li@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
linux-i3c@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, git@amd.com
Subject: Re: [PATCH v3 1/3] dt-bindings: i3c: xlnx: Add IBI and hot-join capability properties
Date: Thu, 10 Sep 2026 12:36:45 +0100 [thread overview]
Message-ID: <aqKWTT47S_zPzvbN@squawk> (raw)
In-Reply-To: <aqGHlWpQjpHEft3j@SMW015318>
[-- Attachment #1: Type: text/plain, Size: 6280 bytes --]
On Wed, Sep 09, 2026 at 11:21:41AM -0500, Frank Li wrote:
> On Tue, Sep 08, 2026 at 06:54:31PM +0100, Conor Dooley wrote:
> > On Tue, Sep 08, 2026 at 03:12:55PM +0530, Shubham Patil wrote:
> > > In-Band Interrupt and Hot-Join are synthesis-time options of the AXI I3C
> > > IP. Describe them with two boolean properties.
> > >
> > > A Hot-Join request is acknowledged by the IBI machinery, so a hot-join
> > > capable design is always IBI capable as well. Both events are reported
> > > through the controller interrupt, which is therefore required whenever
> > > the capability is present.
> > >
> > > Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com>
> > > ---
> > > Changes in V3:
> > > - Move in-band-interrupt-capable and hot-join-capable into the common
> > > i3c.yaml schema and drop the xlnx, prefix.
> > > - Keep dependencies in the AMD binding.
> > > - Update the commit description accordingly.
> > > - Conor Dooley acked v2 with the xlnx,-prefixed properties in the AMD
> > > binding [1].
> > > That Acked-by is not carried here: the names lost the vendor prefix
> > > and the definitions moved to i3c.yaml after Frank Li's comment.
> > > [1]:https://lore.kernel.org/all/20260824-tightwad-impose-495476599087@spud/
> >
> > I disagree with Frank. These properties make sense for Xilinx because it
> > is an FPGA IP and synthesis options impact this. For other devices, this
> > should be determined from the compatible.
> > Please revert to how things were done in v2, especially as no rationale
> > was provided for why these should be common.
>
> It is common problems, when IP intergrate by SOC, which may defeature some
> part, It is not appeared now just because IBI and HJ have not enabled
> widely.
>
> IBI and HJ is optional features of I3C. Ideally it should be indicated by
> some registers. But not all vendor implement provide this CAP registers.
>
> IBI and HJ depend on some slow clocks, which monitor SDA line change.
> Some instances of IP may not have such slow clocks. Some IP's IBI and HJ
> use seperate IRQ line, but these irq line may not connect of difference
> instances.
All of this should be able to be dealt with by appropriate use of
specific compatibles.
> like previous SPI vendor customized property, we takes efforts to convert
> to common one and also meet back compatiblity problem at convert. I don't
> want to do it again. This kind property is most likely as below.
What SPI controller specific properties are you talking about here?
There are relatively few properties in spi-controller.yaml, and none of
them deal with these kinds of capabilities.
>
> default: decide by comaptible string or hardware cap
> force-disabled: force disable for some reason, like, miss connect irq line
> or missed some clock, or IP bugs, or board desgin's some level shift chip
> broken IBI/HJ timing requirements.
Of these, only the last would be a valid reason for having a property
for it. Missing interrupts, clocks or IP bugs should all be dealt with
using device specific compatibles.
If board wiring causes the breakage, the property may be more
appropriate at the i3c device level rather than the controller given
that wiring to some devices on the bus may not have the problems?
That said, I think that problem should be dealt with when it arises,
rather than starting a trend of adding capabilities properties at the
controller level when I am not convinced that there's going to be other
users in the same vein.
Thanks,
Conor.
>
> Frank
>
> >
> > pw-bot: changes-requested
> >
> > Thanks,
> > Conor.
> >
> > >
> > > Changes in V2:
> > > - Rename the properties to "xlnx,in-band-interrupt-capable" and
> > > "xlnx,hot-join-capable", and expand their descriptions.
> > > - Express the interrupt requirement with dependencies: instead of an
> > > allOf/if-then clause.
> > > ---
> > > Documentation/devicetree/bindings/i3c/i3c.yaml | 15 +++++++++++++++
> > > .../devicetree/bindings/i3c/xlnx,axi-i3c-1.0.yaml | 6 ++++++
> > > 2 files changed, 21 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > index e25fa72fd7857..7430394cc6b9b 100644
> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> > > @@ -61,6 +61,21 @@ properties:
> > > Indicates that the system is accessible via this bus as an endpoint for
> > > MCTP over I3C transport.
> > >
> > > + in-band-interrupt-capable:
> > > + type: boolean
> > > + description:
> > > + The controller supports In-Band Interrupts. A target can request
> > > + attention on SDA/SCL by driving its dynamic address during bus
> > > + arbitration, instead of using a dedicated side-band interrupt line.
> > > +
> > > + hot-join-capable:
> > > + type: boolean
> > > + description:
> > > + The controller supports Hot-Join. A target attached or powered up
> > > + after the bus is already running can announce itself using the
> > > + reserved Hot-Join address so the controller can assign it a dynamic
> > > + address.
> > > +
> > > required:
> > > - "#address-cells"
> > > - "#size-cells"
> > > diff --git a/Documentation/devicetree/bindings/i3c/xlnx,axi-i3c-1.0.yaml b/Documentation/devicetree/bindings/i3c/xlnx,axi-i3c-1.0.yaml
> > > index 2caa245a86568..9480de3fe8e1d 100644
> > > --- a/Documentation/devicetree/bindings/i3c/xlnx,axi-i3c-1.0.yaml
> > > +++ b/Documentation/devicetree/bindings/i3c/xlnx,axi-i3c-1.0.yaml
> > > @@ -37,6 +37,10 @@ required:
> > > - reg
> > > - clocks
> > >
> > > +dependentRequired:
> > > + hot-join-capable: [ in-band-interrupt-capable ]
> > > + in-band-interrupt-capable: [ interrupts ]
> > > +
> > > allOf:
> > > - $ref: i3c.yaml#
> > >
> > > @@ -54,5 +58,7 @@ examples:
> > > interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
> > > #address-cells = <3>;
> > > #size-cells = <0>;
> > > + hot-join-capable;
> > > + in-band-interrupt-capable;
> > > };
> > > ...
> > > --
> > > 2.34.1
> > >
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-09-10 11:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 9:42 [PATCH v3 0/3] i3c: master: amd: Add IBI and hot-join support Shubham Patil
2026-09-08 9:42 ` [PATCH v3 1/3] dt-bindings: i3c: xlnx: Add IBI and hot-join capability properties Shubham Patil
2026-09-08 17:54 ` Conor Dooley
2026-09-09 16:21 ` Frank Li
2026-09-10 11:36 ` Conor Dooley [this message]
2026-09-10 15:44 ` Frank Li
2026-09-08 9:42 ` [PATCH v3 2/3] i3c: master: amd: Add support for in-band interrupts Shubham Patil
2026-09-08 9:42 ` [PATCH v3 3/3] i3c: master: amd: Add hot-join support Shubham Patil
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=aqKWTT47S_zPzvbN@squawk \
--to=conor@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=Frank.li@oss.nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=git@amd.com \
--cc=krzk+dt@kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=shubhamsanjay.patil@amd.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®