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 CE2941E230E for ; Wed, 1 Apr 2026 06:12:31 +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=1775023953; cv=none; b=iFNOJgfTORJBV4j+L6C7zKK5tfEPQrwAwUcM8DpyYEtYTak4LON6RZWnu1vwMOUgSYTgxszr3k8Z+hkC0mgJba1BHsP2t4M4heVz/9h7+dXGIsz/9uqbOu+0h9+6xDBVpkxzhYuk0x3tBqbiEDm14/HWtEFYk8u3yfip8tBHI0M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775023953; c=relaxed/simple; bh=PP8ht5mK1RSgutrNVTFAjzZOS3ocw0FInOljxxhLecs=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=MXKsnuPbwWrBqRNHtprlekkQZaigq0lQLRlj99V8n97B1ueJWMAO3qOGbyiRiiMemgz03Ic+TSl1rLPfB3uOfsdmNW3Uz2qZxeb/Tcak3LwZ6tmPdu3WwOvrdiliIZbGxSuheVWGhvL255Eek5rwVulrmY/UwtQg+YxvfIL4zig= 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=SKtrweD6; 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="SKtrweD6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1775023949; bh=PP8ht5mK1RSgutrNVTFAjzZOS3ocw0FInOljxxhLecs=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=SKtrweD6tT6auKN82Lv08WOc+guVPWvuDr8LvmxeBPuL4WQkZ5s+5GEwEM5d+JvIS qL6MARuF7YtQALRKZC/bQ5oIgu4pO+bQUQlLvlohkw1nu6wDTOMAOrs5s1tGpx/Dr2 Dr0YD+izJQArnwpRqmW01rgDLgOfvEyE8iODH3SLVbE7AyDzmtur3HooF2HJ3w0hGO bKznzBbKC+bmOHE4sUlTOjQifyGJ7Rk1do8n1j2zxupx+uQeLA7J5E91MlCTISyIyX 607GJyRnzg0KXCLxzMdVqL9H4WXXnM+VHbAxISfeGx6GUts3JD1QfbLZ2F4qt1Fm1o jGnSUReL1rl+A== Received: from pecola.lan (unknown [159.196.93.152]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 723F264FEF; Wed, 1 Apr 2026 14:12:28 +0800 (AWST) Message-ID: <139edc8cdd621451ca9993ea94b617f76340539d.camel@codeconstruct.com.au> Subject: Re: [PATCH] i3c: dw-i3c-master: Fix IBI count register selection for versalnet From: Jeremy Kerr To: Shubhrajyoti Datta , linux-kernel@vger.kernel.org Cc: git@amd.com, Alexandre Belloni , Frank Li , Joel Stanley , linux-i3c@lists.infradead.org Date: Wed, 01 Apr 2026 14:12:28 +0800 In-Reply-To: <20260401041937.279621-1-shubhrajyoti.datta@amd.com> References: <20260401041937.279621-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, > On DesignWare I3C controllers where IC_HAS_IBI_DATA=3D0 (such as versalne= t), > the IBI_STS_CNT field (bits [28:24] of QUEUE_STATUS_LEVEL) is hardwired > to 0. The IBI status entry count is instead reported via IBI_BUF_BLR > (bits [23:16] of the same register). OK. You seem to have some odd context in your patch though: > irq_handle_ibis() was unconditionally reading IBI_STS_CNT, causing it to > always see 0 pending IBIs on versalnet and return early without draining > the IBI buffer. Since INTR_IBI_THLD_STAT is level-triggered against the > buffer fill level, this left the interrupt permanently asserted. >=20 > Detect IBI data capability at probe time by writing the IBI data threshol= d > field in QUEUE_THLD_CTRL and reading it back. Use the result to select th= e > correct register field in irq_handle_ibis(). >=20 > Fixes: e389b1d72a62 ("i3c: dw: Add support for in-band interrupts") > Signed-off-by: Shubhrajyoti Datta > --- >=20 > =C2=A0drivers/i3c/master/dw-i3c-master.c | 21 ++++++++++++++++++++- > =C2=A0drivers/i3c/master/dw-i3c-master.h |=C2=A0 1 + > =C2=A02 files changed, 21 insertions(+), 1 deletion(-) >=20 > diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i= 3c-master.c > index f2a7f8122d9e..7a1782a69081 100644 > --- a/drivers/i3c/master/dw-i3c-master.c > +++ b/drivers/i3c/master/dw-i3c-master.c > @@ -1455,7 +1455,11 @@ static void dw_i3c_master_irq_handle_ibis(struct d= w_i3c_master *master) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u32 reg; > =C2=A0 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0reg =3D readl(master->reg= s + QUEUE_STATUS_LEVEL); > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0n_ibis =3D QUEUE_STATUS_IBI_ST= ATUS_CNT(reg); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (master->has_ibi_data) > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0n_ibis =3D QUEUE_STATUS_IBI_STATUS_CNT(reg); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0else > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0n_ibis =3D QUEUE_STATUS_IBI_BUF_BLR(reg); > + > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!n_ibis) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0n_ibis =3D QUEUE_STATUS_IBI_BUF_BLR(reg); ... where this last conditional is not present upstream? It would seem to duplicate the purpose of this patch. While that two-line addition could be a simpler workaround, I think your intended change looks a bit more solid. > Fixes: e389b1d72a62 ("i3c: dw: Add support for in-band interrupts") I don't think this is qualifies as a fix if it enables support for new hardware configurations. Cheers, Jeremy