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 A884B39E176 for ; Tue, 21 Apr 2026 17:54:51 +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=1776794093; cv=none; b=YH98+FZ1OtHAX1zGUmIXnSbOUzVsOR+t2CJpDYafg/FWgTjjhjsXyLkN1DwHmlHccWVqH2hFVmjIVavS0NmP9rPgzFUwtCE6yzbIV0R3uGLraew3QeDFWAMdIL2VjfbgHKSj/ecsDli5FCNr9rZpsjd1biojxL8SclA+S/SDwbk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776794093; c=relaxed/simple; bh=SjOF/6kJJSGB4kLdvP4pLaiiXGH1FK07/910HTlSe/4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l4pfMzrrY9MjxLIw7K3deW9eEwIwyNTrJ9YoPLMoyGqip28Zn1WQ6b9CLsROW4qjVcYygx3gWAUezSyS6i51QInu4Xy9FC69i0XrUzGbGifv/52k+cfCka10rXw7cxqG5szrxa2Z3YH/9w1GU6oK5MRo5UzhbJqQlm5Tl1txLVo= 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=mdYhvw88; 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="mdYhvw88" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776794091; x=1808330091; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SjOF/6kJJSGB4kLdvP4pLaiiXGH1FK07/910HTlSe/4=; b=mdYhvw88wh/o//LLev4nbbCB66fPZfVnPtColt5J9pgfU0SX5Z1R0LKc s2JmFv6kKSKOf5QSKVfcm1XszJ0h5amh6PK1UM59MwqmAoqjBAyMQ2OWg IOp6Pdyiv/2TNApa7ePBqKMYp7tGX9yaJM49VQgc5+z313j6k+ac56GXb BQAbmnr675UuvFw8e1NXMRwO9azlcNDcZvcm6MDHHkRd/ky6Gb+MMIGND rd8k1BjrZ/2k24HytZ9EJ3XG04KPSjWmK6dRVbeRsvqjpByKAErutHEZ5 Ms/m3aOtTS/LhnfU91XSozoc1tXq52FYCxxsEkbuAJQWxxJdUG5FqgkjT A==; X-CSE-ConnectionGUID: 9J53SMvmQ1SH8BSd0nyvEw== X-CSE-MsgGUID: 9cwNBzhDSdGYvUF1ZDf09g== X-IronPort-AV: E=McAfee;i="6800,10657,11763"; a="77651352" X-IronPort-AV: E=Sophos;i="6.23,192,1770624000"; d="scan'208";a="77651352" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2026 10:54:51 -0700 X-CSE-ConnectionGUID: gFrRyNQxQd6myaYR/Lmn1Q== X-CSE-MsgGUID: 651dHA4iSlSrfeHmQZV8og== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,192,1770624000"; d="scan'208";a="227494859" Received: from hrotuna-mobl2.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.244.242]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2026 10:54:50 -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 V2 02/16] i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring Date: Tue, 21 Apr 2026 20:54:21 +0300 Message-ID: <20260421175435.122094-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260421175435.122094-1-adrian.hunter@intel.com> References: <20260421175435.122094-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 --- 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 e487ef52f6b4..4cd32e3afa7b 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