From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (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 A8CBD3955C6 for ; Mon, 8 Jun 2026 07:58:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780905509; cv=none; b=Bhek9E1WglY03OumUS67nov/KvZWn1uSCExX3exjKjW2jmpTQcGG9qd9/sQ2iYuxbbI6xcM60nwkzHBNA43Ve2zxwQhzkMEeXnzrdp1SIPs+vXmGnhR93yRhxcNKRvwexvy3sFjImPgnJyBx5UsggzLkIWXQkOJASpmq4IKOuDM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780905509; c=relaxed/simple; bh=KvsnUxNlENe/8t68Aly3yDXUNfe5o9kjNbO4x0qNTAs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GpHXyaWx2P2V1QDww0WXhubRW3b6ds3uPp21Abnhr1DwKUjyev6oKacoLJPlKA9l+yu3JKTqEB8S/CQLgIgOkKKhNrM60JmCTNFg5Ybewq8smezdHsQ/sbnmTrg8Swj2Awj0Fa2I4vgFDF1V05VANj9DLzhD4l+llaVapMcuk+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=XpBWBIkQ; arc=none smtp.client-ip=198.175.65.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="XpBWBIkQ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780905508; x=1812441508; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KvsnUxNlENe/8t68Aly3yDXUNfe5o9kjNbO4x0qNTAs=; b=XpBWBIkQy+J4BnyTIf8nGe3Z9ZlkKp6aT2haNo2v2eCzqe6b+K87u6IC qoPvmPwbxs4OsljLwm4qZ8axyYletnnQPD9o08yy7auhW4xKSEcl552aR Ey2aNU4xtXWvbDj+gAjTFUWZZENfV7FBOEneXpvKUbOui5UXeENQE9Saf 9DeTkQCzpBOFLGKCS5xUcFkDoYzLAABGuL85ZiWAknqHlryQstv+Z7a76 Gc9+42y4H9SRtbqTOrM8NQRWdzwCNXENhPqcjNAjnggvVYooYQa1pssvj nKe8yeuyGPoPFQGzzoAO/t5C5JjIQswTCkYwSOYPUb7q2EtXZWoTHLcqJ Q==; X-CSE-ConnectionGUID: 2mirFFDjR7+YIHCHHIJnJQ== X-CSE-MsgGUID: qlOPyzOHRnqPqVWkHHkBow== X-IronPort-AV: E=McAfee;i="6800,10657,11810"; a="85520155" X-IronPort-AV: E=Sophos;i="6.24,194,1774335600"; d="scan'208";a="85520155" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2026 00:58:28 -0700 X-CSE-ConnectionGUID: pYxwM8Z7TcqmVdiqPrZEWw== X-CSE-MsgGUID: Bq3gfeTAQsaP7kKFmac7Ug== X-ExtLoop1: 1 Received: from conormcd-mobl2.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.244.114]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jun 2026 00:58:26 -0700 From: Adrian Hunter To: alexandre.belloni@bootlin.com Cc: Frank.Li@nxp.com, linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH V2 2/7] i3c: mipi-i3c-hci: Ignore DISEC failures when disabling IBIs Date: Mon, 8 Jun 2026 10:57:55 +0300 Message-ID: <20260608075801.16111-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260608075801.16111-1-adrian.hunter@intel.com> References: <20260608075801.16111-1-adrian.hunter@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Organization: Intel Finland Oy, Registered Address: c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Content-Transfer-Encoding: 8bit Disabling IBIs currently returns the result of the DISEC CCC, causing i3c_hci_disable_ibi() to fail if the transfer errors out. However, the controller has already been programmed to reject IBIs by setting DAT_0_SIR_REJECT, so the target’s IBIs are effectively disabled from the host side regardless of the outcome of the DISEC command. At this point, teardown of the IBI infrastructure can safely proceed even if DISEC fails. Note, from then on, the MIPI I3C HCI not only NACKs the target's IBI but automatically sends another DISEC command. Make i3c_hci_disable_ibi() resilient by ignoring the return value of i3c_master_disec_locked() and always returning success. Signed-off-by: Adrian Hunter --- Changes in V2: Re-base due to changes in previous patch. drivers/i3c/master/mipi-i3c-hci/core.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/i3c/master/mipi-i3c-hci/core.c b/drivers/i3c/master/mipi-i3c-hci/core.c index 1e1f05aff092..fffbc1775ef9 100644 --- a/drivers/i3c/master/mipi-i3c-hci/core.c +++ b/drivers/i3c/master/mipi-i3c-hci/core.c @@ -697,7 +697,13 @@ static int i3c_hci_disable_ibi(struct i3c_dev_desc *dev) struct i3c_hci *hci = to_i3c_hci(m); __i3c_hci_disable_ibi(hci, dev); - return i3c_master_disec_locked(m, dev->info.dyn_addr, I3C_CCC_EVENT_SIR); + /* + * The DAT entry is now set to NACK and DISEC this target's IBIs, so + * the IBI teardown can proceed even if DISEC below fails, so ignore + * errors. + */ + i3c_master_disec_locked(m, dev->info.dyn_addr, I3C_CCC_EVENT_SIR); + return 0; } static void i3c_hci_recycle_ibi_slot(struct i3c_dev_desc *dev, -- 2.51.0