Re: [PATCH v3 1/3] dt-bindings: i3c: xlnx: Add IBI and hot-join capability properties

[Michal Simek <michal.simek@amd.com>]

On 9/10/26 17:44, Frank Li wrote:
> On Thu, Sep 10, 2026 at 12:36:45PM +0100, Conor Dooley wrote:
>> 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.
> 
> 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.
Conor: Any update on this one? I think this thread is stuck at this stage.

Thanks,
Michal