From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.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 E8E4B3F58CD for ; Fri, 15 May 2026 16:26:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778862401; cv=none; b=GkukEpz6Vse8FwNlRvIM2DaULyb6u6yPyHwrDN1CA3ui33aSDX6lWudBEeL/thxsp3XogtTRchHyIv76tY3cCfXgUhnqffGXWUtlSYfbVTmCq55iLWc9RUsM6n+w6cqivjSvM44smywkQcwf1aecdVYGW9h4GnJm4WyLx75C9fg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778862401; c=relaxed/simple; bh=ObbOkCE44+r/FKwgeTpdAODaGKkmUlmyYBoR8+AOZxc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Rutrg/1T8QyrHpe6Jej8ra3zmILa93OVz6+odR7M6FVNLyRN2ABBit+5RKM4qrqsS/xU8tBQwT0bYFOIRXUFKPTkrHTm/t6mVaq0g3kbAn5DtVaJ6q/SWpPK/s0aBMEIvTVAO1kSBEPz1pzq/wIJ9LrwmCKaB5gjDJStK7CPB00= 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=JvXU+LvF; arc=none smtp.client-ip=198.175.65.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="JvXU+LvF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778862400; x=1810398400; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ObbOkCE44+r/FKwgeTpdAODaGKkmUlmyYBoR8+AOZxc=; b=JvXU+LvFEVzUl02rlbrK6dRf8ymGkTP/NmVzFPi4N5CYIhTkHNBrGavx Wdd1k4QhWqwft0yorqCFMvRtydJktO/KofpyNq8VsXltflTwwI8IlyHLa 9cZIm3slV4nYnSalgZ6D7pv9cf+n/Hew236tZVOq4l9hJyfLtv018mr5p R1D5toQdMktsRtuUrlm0Ys0Vt/uQ612oeiBdrgANcrdkGFPghhp2gxJUE ue/Yh47g8OXpXB9MIcTyw1mgPwJ5Yp7QhJjEgknvEwqMtk1bxUYe1dYuY 8KOJttFxl75ux8oHImpADPjZFNYxhxoYLuRk9qIzkvMQSRS4DU7sj+0WU A==; X-CSE-ConnectionGUID: ADgzPdWvRw25fD3GZtMoIA== X-CSE-MsgGUID: wZDDy8cYSBStvvihynnmgg== X-IronPort-AV: E=McAfee;i="6800,10657,11787"; a="79785227" X-IronPort-AV: E=Sophos;i="6.23,236,1770624000"; d="scan'208";a="79785227" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2026 09:26:38 -0700 X-CSE-ConnectionGUID: SdgyzqifTAuRnXcUrmaF3A== X-CSE-MsgGUID: O/1n+4/zSsq1QcCfWUlxmw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,236,1770624000"; d="scan'208";a="238857133" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.245.28]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 May 2026 09:26:36 -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 02/17] i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring Date: Fri, 15 May 2026 19:26:06 +0300 Message-ID: <20260515162621.57719-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260515162621.57719-1-adrian.hunter@intel.com> References: <20260515162621.57719-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: 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