From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 2C90E39150D for ; Wed, 10 Jun 2026 07:30:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781076624; cv=none; b=vGJT3XfmbmSFYpDZ2VLVTUu5HNsMzlb/gXf4b09pO7CevxzlYRKgx/c28aoGcGudjXfHD46EKp4GkjG+zleSIp5FNg3JDHhofY44YiCAvEmwkJURjaPgeYii0pMUTfa4pEb6cjZQTDOVa4WONFONfTxfSrRct2FZiu557+w44Wk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781076624; c=relaxed/simple; bh=Iil2ocVoAMeQzOA2FXTuLwD1NAdo6EBe1TOz5vHqZ68=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aJPpUUXQ3pjQlgpzV4jS94y989BhNTSGcXRyIH7FBfAtvsgMRdPV/CmZA0s6JpBIfYlLJONhJD5Vc8lDn45k2DfONmMb80k5EbAH0w+U8wJ0hEo86z6c1B7+UJAFINLFaHK3CVVxzV4krQ95vEALatIAEw2CUnr4DpR/WI7RdkM= 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=dd+LA3wB; arc=none smtp.client-ip=192.198.163.19 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="dd+LA3wB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1781076621; x=1812612621; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Iil2ocVoAMeQzOA2FXTuLwD1NAdo6EBe1TOz5vHqZ68=; b=dd+LA3wBo8SroeiirsK8DQgzKx8gqDnlyW/XyKjWu09DI+Arol5XtuKR eHeP5K6R4+CD0NiX01ooQAt3W3wJhckoNbdBupquKLJz7hsZ20nFLVRB4 BgPOaSGXwjQIUQrgeXpXW7yngJ+qEXRuWeLEsm2T2eirSMikU1KBmVO22 lz9QqozdM6Nx+XaFZOv4jJI/grLElloAiwRMsFBEAwVdWRPwnmV9ES/sv yLbGdbaoBvgGP1kgDifJiwDMuTEROH0Na+JjQLljhQXQ9J8mUcV8IKPpT 9ZOgT4SUpgv73SQp3NYAQ1VxPLF42wK687aOUItZ2PYXh3PgS7/Da6chF w==; X-CSE-ConnectionGUID: 4MX6dWXiQxikgTyWhj7xqg== X-CSE-MsgGUID: I+pvWD3TRfulbw0lKXmzAA== X-IronPort-AV: E=McAfee;i="6800,10657,11812"; a="80878411" X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="80878411" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2026 00:29:11 -0700 X-CSE-ConnectionGUID: j11I+wTGQe+lehkty0MWvQ== X-CSE-MsgGUID: cNkLaBDFS/m97YU5ZVSUpA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,197,1774335600"; d="scan'208";a="270103443" Received: from mkosciow-mobl1.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.245.210]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2026 00:29:09 -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 V3 2/7] i3c: mipi-i3c-hci: Ignore DISEC failures when disabling IBIs Date: Wed, 10 Jun 2026 10:28:47 +0300 Message-ID: <20260610072852.36934-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260610072852.36934-1-adrian.hunter@intel.com> References: <20260610072852.36934-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 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