[PATCH v2] i3c: dw-i3c-master: Fix IBI count register selection for versalnet

Datta, Shubhrajyoti shubhrajyoti.datta at amd.com
Tue Apr 14 23:54:35 PDT 2026


[Public]

> -----Original Message-----
> From: Jeremy Kerr <jk at codeconstruct.com.au>
> Sent: Wednesday, April 8, 2026 3:36 PM
> To: Datta, Shubhrajyoti <shubhrajyoti.datta at amd.com>; Alexandre Belloni
> <alexandre.belloni at bootlin.com>
> Cc: Datta, Shubhrajyoti <shubhrajyoti.datta at amd.com>; linux-
> kernel at vger.kernel.org; git (AMD-Xilinx) <git at amd.com>; Frank Li
> <Frank.Li at nxp.com>; Joel Stanley <joel at jms.id.au>; linux-
> i3c at lists.infradead.org
> Subject: Re: [PATCH v2] i3c: dw-i3c-master: Fix IBI count register selection for
> versalnet
>
>
>
> Hi Shubhrajyoti,
>
> > I see three possible approaches here:
> >
> >  1. SoC‑specific |compatible|(e.g. VersalNet detection)
> >     Use a dedicated compatible string to identify VersalNet and adjust
> >     the behavior accordingly.
> >  2. Dynamic runtime detection (current approach)
> >     The current patch attempts to infer the absence of IBI payload data
> >     dynamically, without relying on DT information.
> >  3. Explicit DT property (|has-no-ibi-data|)
> >     Introduce a boolean device‑tree property to explicitly describe the
> >     hardware capability that no IBI payload data is provided, and use
> >     that to drive the behavior.
> >
> > Could you please advise which approach would be preferred?
>
> Regardless of choice here, you will still need to introduce a device-specific
> compatible string.
I agree,
I will plan to take it up in a separate patch.
>
> From there, your three options apply. My thinking is:
>
>  - if you can *guarantee* that the probing method (2) is accurate (and
>    there are no other synthesis settings that might invalidate it), then
>    use that.
Yes that is so.


>
>  - otherwise, if you're unsure of the reliability of probing, use a new
>    explicit DT property as per your (3). This is more appropriate than
>    using the compatible string, as it's an actual configurable property
>    of the hardware, rather than a workaround-style thing.
>
> Note that Alexandre has the final say in this though. He's okay with the probe
> approach, so it's up to your call on whether that will be solid enough for all dw-
> i3c hardware.

Sure
>
> Cheers,
>
>
> Jeremy


More information about the linux-i3c mailing list