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 81FB03C278C for ; Thu, 2 Apr 2026 08:32:33 +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=1775118755; cv=none; b=puI2a1QaavmO79guXMSiiYFCIcJb6fGaKaQfCzGRI5PJD1NcsCTUPUAflTmd0nsJ3HDZ9rVWrIeRAx5mhv6VkPYT2xIBtF+XH+0T1O1DKgrd6zCFnBBUWAv8n+UiKVFvodNqPsHt7D5zr40otJdlG7I7Xr6kqzCYTcYUr/8G93E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775118755; c=relaxed/simple; bh=eZcJ64gmgk3xVHXG1yPukJP/maK5TiEMdaQBHSRLdPg=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=cPx0e3QeEC9iz6r3UjMrVLGnqtblVSAYnKo2Fa4uGqwEsg3xlMr6V2E+maSWyCYseBtiRnJc2NiHn4Pe7aL+ocqb+HE5T2wDydogWTggHZNJ3q/knEOvHD78mPWJ0b72JRPYTvLeOHm21Nii2Lf8O31MrfjMevMdn/WHFzBBbKw= 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=ATSN0PDT; 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="ATSN0PDT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1775118751; bh=eZcJ64gmgk3xVHXG1yPukJP/maK5TiEMdaQBHSRLdPg=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ATSN0PDTv9ZBpdlAM3GrYne8MKAshSP2c0FBPaxXUN3qOaE6WwBi7yxDy533b6nfn DnBTW9PBBxc/k9GQTmCMgRq+DSbs/aHLv67oRGaNiW6PfPbXFDnAz3Uk2wg0vieXIn PC8nPnZYNaFfb3nLGte8cyxM7S6YKzri9ZzTKKiTsQjfI3Z4ctFfqckUQm68rdytIE bTOp7FHr5uEoZERJ0D/QhcHRmH5Q9gxQy8e/3v17oXmUDG7hm4TiTkHpGWFaK12cgA aXCmrpfj/k6oEBnUszTDdE/Ggvxi27bsOXzGGl1ZDp8mJ54G2drjP7TJFR1tqn6IMY rWMdq+FUaUyBA== Received: from [192.168.72.167] (210-10-213-150.per.static-ipl.aapt.com.au [210.10.213.150]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 8A53365082; Thu, 2 Apr 2026 16:32:30 +0800 (AWST) Message-ID: <5cb83afcd5340a108fd5a7346494ccf73752cc27.camel@codeconstruct.com.au> Subject: Re: [PATCH v2] i3c: dw-i3c-master: Fix IBI count register selection for versalnet From: Jeremy Kerr To: "Datta, Shubhrajyoti" , "linux-kernel@vger.kernel.org" Cc: "git (AMD-Xilinx)" , Alexandre Belloni , Frank Li , Joel Stanley , "linux-i3c@lists.infradead.org" Date: Thu, 02 Apr 2026 16:32:30 +0800 In-Reply-To: References: <20260401084430.436059-1-shubhrajyoti.datta@amd.com> 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, > > How are you binding the driver to this device? Are you using a unique O= F > > compatible string, or something ACPI-based? > >=20 > > ... and if that can be specific to this hardware instance, would that b= e an > > effective mechanism to select the IBI read method instead? > Hi Jeremy, >=20 > VersalNet currently uses the generic "snps,dw-i3c-master-1.00a" > compatible string =E2=80=94 there is no unique compatible string for this > hardware instance. The DTS =C2=A0=C2=A0 entry looks like: >=20 > =C2=A0 compatible =3D "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. > =C2=A0 We could introduce a VersalNet-specific compatible with a generic = fallback: >=20 > =C2=A0 compatible =3D "xlnx,versalnet-dw-i3c-master", "snps,dw-i3c-master= -1.00a"; Yes, you want that anyway. > =C2=A0 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 =E2=80=94 the IC_HAS_IBI_DATA=3D0 configuration is a synthesizab= le > option in the IP and may appear in other SoCs using the same core. >=20 > 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 compatib= le. Given it doesn't work at the moment, there shouldn't be any backwards compat concerns, I think? Cheers, Jeremy