From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (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 DC8DC3BE627 for ; Mon, 4 May 2026 11:34:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777894448; cv=none; b=kPCtkDfXYGIZkCEHPaMf93d6Bg62Pfoio/+nb8udvRlqhjUFf43QZrQX1eA0Hd4g4MeWDxJqaV3BH3uqlFsEaNjPSBTtQm/9Cupp8FdZTnt7KoGX+gUrcGeeD7LRB0MoKkWWhLT3fkf0C9kmcNrnUmyDu+NMxNx6D0lT93/58ko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777894448; c=relaxed/simple; bh=tBQeJbD6frPT216scr5vXTjp7lJDChruCq8wEw3Bl4k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DrygG8szkbm8eSY3ilTZ+GhSxJUCR7m4iwd6yqjfhXqvLJEvHi5jsrBV32m17Y5WcvAonfvacFoH9djCU4awloLUsVyIKLhnaMPR8cZRasSchHlvLI/bB/DRi9EN9QFCkprXEE/lcnygTbjYuuOxADK0Xj4eba3zqMBP+VyOGWM= 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=VLfhIKGS; arc=none smtp.client-ip=192.198.163.13 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="VLfhIKGS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1777894447; x=1809430447; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=tBQeJbD6frPT216scr5vXTjp7lJDChruCq8wEw3Bl4k=; b=VLfhIKGScuyvBC2HLRq32XTgJKk7y4SpMBIgiyQwWVBvdDPYBPGowEpH i+9X9YBDnu4cBfIIjY+2Xj4pDU3+oHtv0dbn3U3RCGydIK+1TQrbgs7Oq 6g6+c66cR9U8a0ZKvkCqB2wXUr5HngXXNEnH7B1+eESeY9TEz7d7S/uMH 1JYjJOtXAvSVFMRQl1STKSU66jtAI5KIhStm8SS5B/99Bui62lVjt0tdS DRU2ZhzQeRTg7TJlGq/RNrXGhp8o7FKvyi/r6oNCb3DKiFkJeZSSOVTu3 MXvRTshGkcZQab62LLzkksAlwdlk08TYCr3e/9S1AZDSgaAl86THRRNmL g==; X-CSE-ConnectionGUID: 0XprgtEiRCem2j308WLvnw== X-CSE-MsgGUID: PKwSikXqRTyqzneI0h38ag== X-IronPort-AV: E=McAfee;i="6800,10657,11775"; a="81315145" X-IronPort-AV: E=Sophos;i="6.23,215,1770624000"; d="scan'208";a="81315145" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2026 04:34:07 -0700 X-CSE-ConnectionGUID: pkkDYiE6S7C6x9EkmxHqUg== X-CSE-MsgGUID: gSL30k/bTvmv+R55amxWbg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,215,1770624000"; d="scan'208";a="240478194" Received: from hrotuna-mobl2.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.245.92]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 May 2026 04:34:05 -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 02/16] i3c: mipi-i3c-hci: Preserve RUN bit when aborting DMA ring Date: Mon, 4 May 2026 14:33:38 +0300 Message-ID: <20260504113352.38490-3-adrian.hunter@intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260504113352.38490-1-adrian.hunter@intel.com> References: <20260504113352.38490-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 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 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