linux-kernel - Re: [PATCH v2 03/16] dmaengine: qcom: bam

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <knhqbj2pyluwrvr2f4h6zgpfosa6o2qgnhtl4qltadpuyfexgu@kk5knurc4v7h>
Date: Fri, 16 Aug 2024 11:22:29 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Md Sadre Alam <quic_mdalam@...cinc.com>
Cc: vkoul@...nel.org, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, konradybcio@...nel.org, thara.gopinath@...il.com, 
	herbert@...dor.apana.org.au, davem@...emloft.net, gustavoars@...nel.org, 
	u.kleine-koenig@...gutronix.de, kees@...nel.org, agross@...nel.org, 
	linux-arm-msm@...r.kernel.org, dmaengine@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org, quic_srichara@...cinc.com, 
	quic_varada@...cinc.com, quic_utiwari@...cinc.com
Subject: Re: [PATCH v2 03/16] dmaengine: qcom: bam_dma: add LOCK & UNLOCK
 flag support

On Thu, Aug 15, 2024 at 02:27:12PM GMT, Md Sadre Alam wrote:
> Add lock and unlock flag support on command descriptor.
> Once lock set in requester pipe, then the bam controller
> will lock all others pipe and process the request only
> from requester pipe. Unlocking only can be performed from
> the same pipe.
> 

Is the lock per channel, or for the whole BAM instance?

> If DMA_PREP_LOCK flag passed in command descriptor then requester
> of this transaction wanted to lock the BAM controller for this
> transaction so BAM driver should set LOCK bit for the HW descriptor.

You use the expression "this transaction" here, but if I understand the
calling code the lock is going to be held over multiple DMA operations
and even across asynchronous operations in the crypto driver.

DMA_PREP_LOCK indicates that this is the beginning of a transaction,
consisting of multiple operations that needs to happen while other EEs
are being locked out, and DMA_PREP_UNLOCK marks the end of the
transaction.

That said, I'm not entirely fond of the fact that these flags are not
just used on first and last operation in one sequence, but spread out.

Locking is hard, when you spread the responsibility of locking and
unlocking across different entities it's made harder...

> 
> If DMA_PREP_UNLOCK flag passed in command descriptor then requester
> of this transaction wanted to unlock the BAM controller.so BAM driver
> should set UNLOCK bit for the HW descriptor.
> 
> Signed-off-by: Md Sadre Alam <quic_mdalam@...cinc.com>
> ---
> 
> Change in [v2]
> 
> * Added LOCK and UNLOCK flag in bam driver
> 
> Change in [v1]
> 
> * This patch was not included in [v1]

v1 can be found here:
https://lore.kernel.org/all/20231214114239.2635325-7-quic_mdalam@quicinc.com/

And it was also posted once before that:
https://lore.kernel.org/all/1608215842-15381-1-git-send-email-mdalam@codeaurora.org/

In particular during the latter (i.e. first post) we had a rather long
discussion about this feature, so that's certainly worth linking to.

Looks like this series provides some answers to the questions we had
back then.

Regards,
Bjorn

> 
>  drivers/dma/qcom/bam_dma.c | 10 +++++++++-
>  include/linux/dmaengine.h  |  6 ++++++
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 1ac7e250bdaa..ab3b5319aa68 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -58,6 +58,8 @@ struct bam_desc_hw {
>  #define DESC_FLAG_EOB BIT(13)
>  #define DESC_FLAG_NWD BIT(12)
>  #define DESC_FLAG_CMD BIT(11)
> +#define DESC_FLAG_LOCK BIT(10)
> +#define DESC_FLAG_UNLOCK BIT(9)
>  
>  struct bam_async_desc {
>  	struct virt_dma_desc vd;
> @@ -692,9 +694,15 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
>  		unsigned int curr_offset = 0;
>  
>  		do {
> -			if (flags & DMA_PREP_CMD)
> +			if (flags & DMA_PREP_CMD) {
>  				desc->flags |= cpu_to_le16(DESC_FLAG_CMD);
>  
> +				if (bdev->bam_pipe_lock && flags & DMA_PREP_LOCK)
> +					desc->flags |= cpu_to_le16(DESC_FLAG_LOCK);
> +				else if (bdev->bam_pipe_lock && flags & DMA_PREP_UNLOCK)
> +					desc->flags |= cpu_to_le16(DESC_FLAG_UNLOCK);
> +			}
> +
>  			desc->addr = cpu_to_le32(sg_dma_address(sg) +
>  						 curr_offset);
>  
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index b137fdb56093..70f23068bfdc 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -200,6 +200,10 @@ struct dma_vec {
>   *  transaction is marked with DMA_PREP_REPEAT will cause the new transaction
>   *  to never be processed and stay in the issued queue forever. The flag is
>   *  ignored if the previous transaction is not a repeated transaction.
> + *  @DMA_PREP_LOCK: tell the driver that there is a lock bit set on command
> + *  descriptor.
> + *  @DMA_PREP_UNLOCK: tell the driver that there is a un-lock bit set on command
> + *  descriptor.
>   */
>  enum dma_ctrl_flags {
>  	DMA_PREP_INTERRUPT = (1 << 0),
> @@ -212,6 +216,8 @@ enum dma_ctrl_flags {
>  	DMA_PREP_CMD = (1 << 7),
>  	DMA_PREP_REPEAT = (1 << 8),
>  	DMA_PREP_LOAD_EOT = (1 << 9),
> +	DMA_PREP_LOCK = (1 << 10),
> +	DMA_PREP_UNLOCK = (1 << 11),
>  };
>  
>  /**
> -- 
> 2.34.1
>