mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeremy Kerr <jk@codeconstruct.com.au>
To: "Datta, Shubhrajyoti" <shubhraj@amd.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: "Datta, Shubhrajyoti" <shubhrajyoti.datta@amd.com>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"git (AMD-Xilinx)" <git@amd.com>, Frank Li <Frank.Li@nxp.com>,
	Joel Stanley <joel@jms.id.au>,
	 "linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: Re: [PATCH v2] i3c: dw-i3c-master: Fix IBI count register selection for versalnet
Date: Wed, 08 Apr 2026 18:06:15 +0800	[thread overview]
Message-ID: <f202840ba1053f9d14655c9f6310298ba3e9c5a1.camel@codeconstruct.com.au> (raw)
In-Reply-To: <f6253217-4b40-4d0e-b2cb-085c3d090b71@amd.com>

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.

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.

 - 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.

Cheers,


Jeremy

  reply	other threads:[~2026-04-08 10:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-01  8:44 Shubhrajyoti Datta
2026-04-01  9:14 ` Jeremy Kerr
2026-04-02  7:39   ` Datta, Shubhrajyoti
2026-04-02  8:32     ` Jeremy Kerr
2026-04-03 16:24       ` Alexandre Belloni
2026-04-08  9:06         ` Datta, Shubhrajyoti
2026-04-08 10:06           ` Jeremy Kerr [this message]
2026-04-15  6:54             ` Datta, Shubhrajyoti
2026-04-30 10:13 ` Alexandre Belloni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f202840ba1053f9d14655c9f6310298ba3e9c5a1.camel@codeconstruct.com.au \
    --to=jk@codeconstruct.com.au \
    --cc=Frank.Li@nxp.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=git@amd.com \
    --cc=joel@jms.id.au \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shubhraj@amd.com \
    --cc=shubhrajyoti.datta@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®