From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 2E7F2360EF2 for ; Fri, 12 Jun 2026 08:01:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781251296; cv=none; b=dBGjxrnfUyngfgycFB7QLY9RICk3atqLvoXJs655Uk2pzztSVUjQKZCU6at9winrjehIZ9GywEJA+81zjNTyOFzeQAVl2vLPqGu6rmEq7k0w1HGOrr0gjseaJA9pLez9T0Jh4+0+Qcj3UnEm2Uy5HV4Fu2wO5mIy2r2S7FyZd60= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781251296; c=relaxed/simple; bh=ClMlOgBM1Bn+TSJGqyqubQ/cA0h85s27faW8u//GBlc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jmCpE3NgqkF74TIl1YSq9FooCbXoiajXAzidZF3c1KUiJfs74RJbzR7q/O3LJYX8L/kQ3s2wIJmwrKRv6K3opEbwiO3T8iOxLQ/pBRSogcnvtU67EMAn9Sbmm+yfTFPxlFYQsSR63apt1hmSQ7quHrM/j0tGgPuELltihVLn4ak= 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=Qm3+DVN/; arc=none smtp.client-ip=192.198.163.15 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="Qm3+DVN/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1781251292; x=1812787292; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ClMlOgBM1Bn+TSJGqyqubQ/cA0h85s27faW8u//GBlc=; b=Qm3+DVN/3RDoj3GN4hyjuFZ0FPyTvzu7HsBXURWgA5JXrGHWh1XAC5rk z8/zhyASUY8Ra5buKDjqBU1crQAGLzWoJU+ER0fkFbQ8a810G89YXg4uc 3vBO3JmXMwuWUXqW6BzaEb612fcAaZr8D+wPnaRZExZ43PxPZM1npdjHA YU3FnVBn+BkTs5cTGW3eONBr/Dwv3DaMQyjJQmiWmvi6oCasVA1Lky4Ae tgWh+r9xBySiltKl+2hR+XhV5G11eTod67T1OdxN+urUePqbVZ2Y+18GH pgz8nytyzvNm+60VtW52nvHvXW5zVE4Uimuhgb8RS0co6dEeEMxrO8CK7 A==; X-CSE-ConnectionGUID: tjUDZixoS/WQqHb4pFV7Gg== X-CSE-MsgGUID: wAlvqg+WRsukVgivAjycMg== X-IronPort-AV: E=McAfee;i="6800,10657,11813"; a="82186738" X-IronPort-AV: E=Sophos;i="6.24,200,1774335600"; d="scan'208";a="82186738" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2026 01:01:22 -0700 X-CSE-ConnectionGUID: CP2rXTRZT/GYaj6PnkwxBg== X-CSE-MsgGUID: XjVGrQVrTdat+yPpSWfQ/g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,200,1774335600"; d="scan'208";a="246630340" Received: from vpanait-mobl.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.245.41]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jun 2026 01:01:20 -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 V4 2/7] i3c: mipi-i3c-hci: Ignore DISEC failures when disabling IBIs Date: Fri, 12 Jun 2026 11:01:02 +0300 Message-ID: <20260612080107.11606-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260612080107.11606-1-adrian.hunter@intel.com> References: <20260612080107.11606-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 Reviewed-by: Frank Li --- Changes in V4: None Changes in V3: Add Frank's Rev'd-by 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