From: Mostafa Saleh <smostafa@google.com>
To: linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org, vkoul@kernel.org,
Frank.Li@kernel.org, bartosz.golaszewski@oss.qualcomm.com,
Mostafa Saleh <smostafa@google.com>, Frank Li <Frank.Li@nxp.com>
Subject: [PATCH v2 2/2] dmaengine: qcom: bam_dma: Do not touch remote BAM in remove()
Date: Fri, 23 Oct 2026 10:15:36 +0000 [thread overview]
Message-ID: <20261023101536.3965344-3-smostafa@google.com> (raw)
In-Reply-To: <20261023101536.3965344-1-smostafa@google.com>
Unbinding the crypto BAM through sysfs on X1P42100 resets the board.
bam_dma_remove() clears BAM_IRQ_SRCS_MSK_EE unconditionally. For a BAM
that is controlled or powered remotely the register may not be
accessible: the clock and power of the block belong to the remote side
or to the consumer of the BAM, which is why bam_init() already avoids
every register access for such a BAM when the DT provides num-channels
and qcom,num-ees.
The write is also unnecessary. On a remotely controlled BAM the driver
only ever sets per channel bits in the EE mask, in bam_chan_init_hw(),
and bam_free_chan() clears them again. Both run on behalf of a
consumer, which keeps the block clocked while they do.
Skip the write for both kinds of remotely managed BAM, using the same
condition as bam_init().
Fixes: 5172c9eb89d4 ("dmaengine: qcom: bam_dma: add controlled-remotely dt property")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
drivers/dma/qcom/bam_dma.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 8a1f4e5d24d1..e01f0fec1599 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -1407,8 +1407,15 @@ static void bam_dma_remove(struct platform_device *pdev)
dma_async_device_unregister(&bdev->common);
pm_runtime_get_sync(&pdev->dev);
- /* mask all interrupts for this execution environment */
- writel_relaxed(0, bam_addr(bdev, 0, BAM_IRQ_SRCS_MSK_EE));
+
+ /*
+ * Mask all interrupts for this execution environment. A remotely
+ * controlled or powered BAM is left alone: it may be unclocked, and
+ * the only bits this driver sets in its mask are the per channel
+ * ones that bam_free_chan() cleared.
+ */
+ if (!bdev->controlled_remotely && !bdev->powered_remotely)
+ writel_relaxed(0, bam_addr(bdev, 0, BAM_IRQ_SRCS_MSK_EE));
free_irq(bdev->irq, bdev);
--
2.56.0.307.g5fe7bd680c-goog
prev parent reply other threads:[~2026-10-23 10:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 10:15 [PATCH v2 0/2] dmaengine: qcom: bam_dma: Fixes for unbind Mostafa Saleh
2026-10-23 10:15 ` [PATCH v2 1/2] dmaengine: qcom: bam_dma: Take a PM ref at remove() Mostafa Saleh
2026-10-23 19:38 ` Frank Li
2026-10-23 10:15 ` Mostafa Saleh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261023101536.3965344-3-smostafa@google.com \
--to=smostafa@google.com \
--cc=Frank.Li@kernel.org \
--cc=Frank.Li@nxp.com \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.