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 > > > --- > > > 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 = ; > > > #address-cells = <3>; > > > #size-cells = <0>; > > > + hot-join-capable; > > > + in-band-interrupt-capable; > > > }; > > > ... > > > -- > > > 2.34.1 > > > > >