From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (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 905F637883D for ; Wed, 3 Jun 2026 09:08:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780477695; cv=none; b=rTwCTyI6eECrFwg9RK7gZVJE3k78fY0xVsM+EuCkvZNLddkQ2yE04NNOdZ+ksmvEbdFzsVE1FxMc3Ff0jAbTXKdZyBPVaok3YPw7AGMi8wRAybvfpIbQmwNnrX7Nj4rO7MGclvIPCerKF0oHYJNe8g2P3BVhQHuM0ojkg7PCYjY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780477695; c=relaxed/simple; bh=KP3kMxkM4Qaxsw8Trwrd+QR1CMRx14o7NA48dVHMewg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WCMhqqrG63OKTmwSaHpEEADs12aDYUuMgnrWTyHa1Usentxr+gvv0OqaH8dbpeCaA8wJ49O7hMTLNqmcOE7+x+Hx0M/ot+2dRs5Ks7+sOt18kFYDmWVPibiW1pmxDnYEL7PgndE02nY8PwlMMrA2yoqwHrYi5AuV8p7AVCCpWQE= 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=Y3CzseFY; arc=none smtp.client-ip=192.198.163.11 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="Y3CzseFY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1780477694; x=1812013694; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KP3kMxkM4Qaxsw8Trwrd+QR1CMRx14o7NA48dVHMewg=; b=Y3CzseFYYjxM0etb8j7e5xeJQSIvevRUvDGDbLpCJwAXosEBGXBBOgWG YXQpZMaeBAvetovULyyGGTQEhJHceiEqrQpz/J2fYwb2CwRLoUr9RUoaz nQFWYVM/np2euS5TzfdjOKXW2Z3uh7bczdqvisMHz50xbxRznI1CAVOad nlN12sKtpFoIThZ2JCvHDoJHw3DYfPq05UtOIv1WaBPvO3dPVkCp2UYJT dciUCpTgwWc2/F/GTJFuIhMSzHt5cFSmhFPcV/dJT110gkFFIV0odb+yE T6Dy8+3vjqqHAoSW5QnAZeh6vNV3ba/IMOsLuwZ11YzJtpShWmFVa90bl Q==; X-CSE-ConnectionGUID: GUNmqkofRqWl8gWc43DJ9w== X-CSE-MsgGUID: WP+a0JR3Q3y53QL+xMruEw== X-IronPort-AV: E=McAfee;i="6800,10657,11805"; a="91852596" X-IronPort-AV: E=Sophos;i="6.24,184,1774335600"; d="scan'208";a="91852596" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2026 02:08:14 -0700 X-CSE-ConnectionGUID: B2lNsuIjSq6jtIDv6QcHGg== X-CSE-MsgGUID: O95FU69RSf+Qw4BpFVm/MA== X-ExtLoop1: 1 Received: from ijarvine-mobl1.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.244.137]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Jun 2026 02:08: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 V5 02/17] i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring Date: Wed, 3 Jun 2026 12:07:39 +0300 Message-ID: <20260603090754.16252-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260603090754.16252-1-adrian.hunter@intel.com> References: <20260603090754.16252-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 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 The MIPI I3C HCI specification does not require the DMA ring RUN bit (RUN_STOP) to be cleared when issuing an ABORT. That allows the DMA ring to continue to receive IBIs, although an IBI is anyway not lost because it can be received once the ring restarts if the I3C device has not given up. Note, currently ABORT is only used on a timeout error path so the change has very little effect in practice. In the more common case of a transfer error, the ring (bundle) operation is halted by the controller anyway. Adjust the RING_CONTROL handling to set ABORT without clearing RUN_STOP, bringing the driver into alignment with the specification. Fixes: b795e68bf3073 ("i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeue") Signed-off-by: Adrian Hunter Reviewed-by: Frank Li --- Changes in V4 and V5: None Changes in V3: Add Frank's rev'd-by Changes in V2: Improve commit message drivers/i3c/master/mipi-i3c-hci/dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i3c/master/mipi-i3c-hci/dma.c b/drivers/i3c/master/mipi-i3c-hci/dma.c index e4daaa612055..bdffdd8b8923 100644 --- a/drivers/i3c/master/mipi-i3c-hci/dma.c +++ b/drivers/i3c/master/mipi-i3c-hci/dma.c @@ -554,7 +554,7 @@ static bool hci_dma_dequeue_xfer(struct i3c_hci *hci, if (ring_status & RING_STATUS_RUNNING) { /* stop the ring */ reinit_completion(&rh->op_done); - rh_reg_write(RING_CONTROL, RING_CTRL_ENABLE | RING_CTRL_ABORT); + rh_reg_write(RING_CONTROL, rh_reg_read(RING_CONTROL) | RING_CTRL_ABORT); wait_for_completion_timeout(&rh->op_done, HZ); ring_status = rh_reg_read(RING_STATUS); if (ring_status & RING_STATUS_RUNNING) { -- 2.51.0