From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (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 7EFC73EEAC6 for ; Wed, 27 May 2026 11:28:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779881294; cv=none; b=idmg9C7fmB1RNywxOKSMdEz9x+TH40NgPNk+Oij7sVUHu0L4kU2P2uQxYuDNbGumCzQzsK8+ps+40u+et/VbSTwjtsjrVZC9D241qLgHnp1n0bJU+eGAFDcwzI+YcBWf/0cKm58Lbd+I0s9KFE4IacWiJ7EmpLGx/IiJInPqNrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779881294; c=relaxed/simple; bh=gDsxcfg85cTAJxGKjUadiwBxxzUTuggBnRV6qMS3N20=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qHSxitmC/n1zVdyTSMmYpLv7lfVlSnH1MrHDMlukidjFlbB4BHNJGU6XuNjbxCzI1YdFDZSfe/ELNl6CQlyjXDlw8EEuyHoxwq7rpYaRTTp7DuArS2DZTm0quJQtWSNyMtQ1a2dsy99zusEL6htHD4umTEd9mU5bp9U550cv7iw= 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=Uv7JQZ00; arc=none smtp.client-ip=198.175.65.9 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="Uv7JQZ00" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1779881293; x=1811417293; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=gDsxcfg85cTAJxGKjUadiwBxxzUTuggBnRV6qMS3N20=; b=Uv7JQZ00ReakZHEWjihrEjbDukNQaQwVcVAZqf+uDOnrxIwTjiEVkUAP HTBHctvSsLTaA5J4giXb3z2TU9Z3KommTS1RKnPq221DUUxsi1rqRuzf6 iiQ6jtHV7/Yk1kaexa78YtY05eRvTFnlr5Nq6+XOfDHLAcYONWEXT/muU h+swmdFZQMcX/cF6xggM09DitaXLXS2psH1HmVAQEG0RciH10oSoDlHB9 6PDpn4HsM19oXnjWwqcokiGMSr5yvWFHT5OFvTWVcW5L9cN1jdUrDeJI/ rCCYsslYjnJRAiAjd/IeVlLBac7ySifzm46X4sS81udhR/+aT+YecKtte Q==; X-CSE-ConnectionGUID: aHKEXs1IRBuqc4bLaQoi5g== X-CSE-MsgGUID: DilALJqiT0CqgRI67e2xVw== X-IronPort-AV: E=McAfee;i="6800,10657,11798"; a="103381710" X-IronPort-AV: E=Sophos;i="6.24,171,1774335600"; d="scan'208";a="103381710" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2026 04:28:13 -0700 X-CSE-ConnectionGUID: XuSdtqjdQEaqBZw6PGm7+g== X-CSE-MsgGUID: 0uU54AGTRYi9p0o4XiJOnw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,171,1774335600"; d="scan'208";a="246238602" Received: from smoticic-mobl1.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.244.228]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 May 2026 04:28:12 -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 2/7] i3c: mipi-i3c-hci: Ignore DISEC failures when disabling IBIs Date: Wed, 27 May 2026 14:27:53 +0300 Message-ID: <20260527112758.38530-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260527112758.38530-1-adrian.hunter@intel.com> References: <20260527112758.38530-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 --- 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 b19bdff5c5e2..3ef7faed9957 100644 --- a/drivers/i3c/master/mipi-i3c-hci/core.c +++ b/drivers/i3c/master/mipi-i3c-hci/core.c @@ -689,7 +689,13 @@ static int i3c_hci_disable_ibi(struct i3c_dev_desc *dev) mipi_i3c_hci_dat_v1.set_flags(hci, dev_data->dat_idx, DAT_0_SIR_REJECT, 0); scoped_guard(spinlock_irqsave, &hci->lock) hci->ibi_devs[dev_data->dat_idx] = NULL; - 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