Re: [PATCH v3 1/3] dt-bindings: i3c: xlnx: Add IBI and hot-join capability properties
From: Michal Simek
Date: Thu Sep 17 2026 - 07:31:14 EST
On 9/10/26 17:44, Frank Li wrote:
On Thu, Sep 10, 2026 at 12:36:45PM +0100, Conor Dooley wrote:Conor: Any update on this one? I think this thread is stuck at this stage.
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@xxxxxxx>
---
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.
I understand compatible can cover most cases. Need variance for property.
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.
num-cs vs fsl,espi-num-chipselects. Total number CS of IP is fixed, but
some instances have not route all CS to pad.
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?
I3C.yaml is for both master controller and devices now. I3C is bus, which
connect many devices, if wiring issue, whole bus can't support IBI. And
if any broken devices happen at address arbitation, whole bus can't support
IBI.
at beging, I suggest 3 state,
[default, enable, disable], but now I think IBI_broken, HJ_broken is more
reasonable to disable it, default value should be set by compatible
string or DCR of I3C regiser.
And some I3C device may be failure to work with IBI even DCR of I3C register
show it support IBI.
I don't want to appear two similar property between vendor and common, like
num-cs vs fsl,espi-num-chipselects.
such as IBI-broken can be used for controller and devices case.
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.
Understand, I3C is realtive new protocal. 'IBI-broken' is more easy
understand, logically equial to in-band-interrupt-capable.
Thanks,
Michal