From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A9B43358CA for ; Wed, 8 Apr 2026 10:06:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=203.29.241.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775642793; cv=none; b=DUTNtX8LTCWd/4kWQrKXHT9mauJY8daRbVD50qtkrXJVsWBRfjLmDIv7+uybv3/tyV7cWRyodsKpHxRNN46vOaoXnL03Ah+ohm9Xgbj1Ckj0ufpue41wl2k5+bcl8ZekiUottE27/SWfcQkCcnEKWRuXhqVmuEzJ+FLyD3MthFI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775642793; c=relaxed/simple; bh=O8NbuKKos3Afy5aWDcqiprT+HjWa1aee6BSXmNFYed4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=JkBo3f/c26gqpaG72FWVpeOUZfW2Bw23QZ3vfXjm6ifXTiy4cK94uwM3MdzMfNG3JKIXBRk8JO1zmIscefbB0VimNsG2aaZ5jg7o9ihpqk5JklqLd5f+pSE6lrWiluj43DNx/8Iz0k9ZCIc7U+sSHvRL0o2O6ynsrKQYXYII68c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au; spf=pass smtp.mailfrom=codeconstruct.com.au; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b=ZordAn9p; arc=none smtp.client-ip=203.29.241.158 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codeconstruct.com.au Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.b="ZordAn9p" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1775642778; bh=oiyeq3Ur4x2y2xjIPdSHCE2q70JzPYHlkX4NN/+e+dY=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ZordAn9pbn2uqRR3zM0Ss9pFhF02lmsS8/eHdjQu/s34io7VsuokT+7916xqjbCua 9CpD6u+y+GVLzjvzAo5tKi6xH7otNi81CjQFQTuv2VE5wRC7cmR6uYdOOn7UKCu97d i4MEtTNiR2jkSneGKBzjiR/jJCUs7dkpxI3ndIcHP0K5T8nFEj5e1nU1JtmZ1rafez rvNjhCEWsFcErSVVcVPTOuZBsWdgmZhuBqmd8EGisxyZvQ7hxDXXQOqJrzq+0swcq4 G4doWsWsZ2CsdXBR07R8TwjEahnPh7W8ebNtwwB1/eHi5IEyOZa1wBm5f6mj5eP7pE Hd3E4dbBTndlQ== Received: from sparky.lan (unknown [159.196.93.152]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 9620D651D5; Wed, 8 Apr 2026 18:06:17 +0800 (AWST) Message-ID: Subject: Re: [PATCH v2] i3c: dw-i3c-master: Fix IBI count register selection for versalnet From: Jeremy Kerr To: "Datta, Shubhrajyoti" , Alexandre Belloni Cc: "Datta, Shubhrajyoti" , "linux-kernel@vger.kernel.org" , "git (AMD-Xilinx)" , Frank Li , Joel Stanley , "linux-i3c@lists.infradead.org" Date: Wed, 08 Apr 2026 18:06:15 +0800 In-Reply-To: References: <20260401084430.436059-1-shubhrajyoti.datta@amd.com> <5cb83afcd5340a108fd5a7346494ccf73752cc27.camel@codeconstruct.com.au> <20260403162442668f12b7@mail.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2+deb12u1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Hi Shubhrajyoti, > I see three possible approaches here: >=20 > =C2=A01. SoC=E2=80=91specific |compatible|(e.g. VersalNet detection) > =C2=A0=C2=A0=C2=A0 Use a dedicated compatible string to identify VersalNe= t and adjust > =C2=A0=C2=A0=C2=A0 the behavior accordingly. > =C2=A02. Dynamic runtime detection (current approach) > =C2=A0=C2=A0=C2=A0 The current patch attempts to infer the absence of IBI= payload data > =C2=A0=C2=A0=C2=A0 dynamically, without relying on DT information. > =C2=A03. Explicit DT property (|has-no-ibi-data|) > =C2=A0=C2=A0=C2=A0 Introduce a boolean device=E2=80=91tree property to ex= plicitly describe the > =C2=A0=C2=A0=C2=A0 hardware capability that no IBI payload data is provid= ed, and use > =C2=A0=C2=A0=C2=A0 that to drive the behavior. >=20 > 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