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

[Datta, Shubhrajyoti]

On 4/3/2026 9:54 PM, Alexandre Belloni wrote:
> Hello,
>
> On 02/04/2026 16:32:30+0800, Jeremy Kerr wrote:
> > Hi Shubhrajyoti,
> >
> > > > How are you binding the driver to this device? Are you using a unique OF
> > > > compatible string, or something ACPI-based?
> > > >
> > > > ... and if that can be specific to this hardware instance, would that be an
> > > > effective mechanism to select the IBI read method instead?
> > > Hi Jeremy,
> > >
> > > VersalNet currently uses the generic "snps,dw-i3c-master-1.00a"
> > > compatible string — there is no unique compatible string for this
> > > hardware instance. The DTS    entry looks like:
> > >
> > >    compatible = "snps,dw-i3c-master-1.00a";
> > You should *always* have a unique compatible string for each device
> > instance, if there can be any variation in behaviours from that generic
> > one (which you certainly do have here).
> >
> > You can still fall-back on a generic one, but using that as your only
> > compatible value means you can't do device-specific behaviours in your
> > driver, as you have just found.
> >
> > >    We could introduce a VersalNet-specific compatible with a generic fallback:
> > >
> > >    compatible = "xlnx,versalnet-dw-i3c-master", "snps,dw-i3c-master-1.00a";
> > Yes, you want that anyway.
> I agree you need a VersalNet-specific compatible string.
>
> > >    and pass a quirk flag via of_device_id.data to select the IBI read method.
> > Exactly, and there is already the struct dw_i3c_drvdata to help with
> > this.
> >
> > > However, the probe-time detection avoids having to enumerate all affected
> > > variants — the IC_HAS_IBI_DATA=0 configuration is a synthesizable
> > > option in the IP and may appear in other SoCs using the same core.
> > >
> > > Do you have a preference? If the DTS change is acceptable, I can go
> > > with the compatible + match-data approach
> > That would certainly be my recommendation.
> >
> > If it's a synthesisable option, it may even be worth adding as a flag to
> > the binding definition (along with the same for other options that might
> > be present). This would mean you don't need a-priori knowledge of the
> > mapping of compatible strings to their synthesis options.
> >
> > I don't have any access to documentation on those options though, so
> > can't be of much help with doing that.
> >
> > > However I thought that detecting it will be helpful for backward compatible.
> > Given it doesn't work at the moment, there shouldn't be any backwards
> > compat concerns, I think?
> I guess the proposed solution works as we can probe the HW to know how
> it was synthesised. It's good to be able to avoid having device tree
> properties for things we can discover.

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?
Also, if option (2) is considered acceptable and there are no further 
comments, can this patch be considered for merging?




> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com