Re: [PATCH v2 6/8] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API

Damien Le Moal <[email protected]>
Newsgroups dev.linux.lists.mhi,dev.linux.lists.imx,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-nvme,org.kernel.vger.dmaengine,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci
Organization Western Digital Research
Message-ID <[email protected]>
On 12/19/25 00:56, Frank Li wrote:
> Use the new dmaengine_prep_config_single_safe() API to combine the
> configuration and descriptor preparation into a single call.
> 
> Since dmaengine_prep_config_single_safe() performs the configuration and
> preparation atomically and dw edma driver implement prep_config_sg() call
> back, so dmaengine_prep_config_single() is reentriable, the mutex can be
> removed.

What about for platforms other than DesignWare EDMA ?
This is a generic endpoint driver that can work on any platform that is endpoint
capable and that has a DMA channel for the PCI endpoint.

The dmaengine_prep_config_single_safe() API should be handling everything
transparently for any platform, regardless of the DMA channel driver
implementing or not the prep_config_sg() callback.

For platforms that do not implement it, I suspect that the mutex will still be
needed here. So how to we resolve this ? Ideally, all of that should be hidden
by the DMA API. The endpoint driver should not need to deal with these differences.

> 
> Tested-by: Niklas Cassel <[email protected]>
> Signed-off-by: Frank Li <[email protected]>
> ---
>  drivers/nvme/target/pci-epf.c | 18 ++++--------------
>  1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index 56b1c6a7706a9e2dd9d8aaf17b440129b948486c..8b5ea5d4c79dfd461b767cfd4033a9e4604c94b1 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -388,22 +388,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  		return -EINVAL;
>  	}
>  
> -	mutex_lock(lock);
> -
>  	dma_dev = dmaengine_get_dma_device(chan);
>  	dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
>  	ret = dma_mapping_error(dma_dev, dma_addr);
>  	if (ret)
> -		goto unlock;
> -
> -	ret = dmaengine_slave_config(chan, &sconf);
> -	if (ret) {
> -		dev_err(dev, "Failed to configure DMA channel\n");
> -		goto unmap;
> -	}
> +		return ret;
>  
> -	desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
> -					   sconf.direction, DMA_CTRL_ACK);
> +	desc = dmaengine_prep_config_single_safe(chan, dma_addr, seg->length,
> +						 sconf.direction,
> +						 DMA_CTRL_ACK, &sconf);
>  	if (!desc) {
>  		dev_err(dev, "Failed to prepare DMA\n");
>  		ret = -EIO;
> @@ -426,9 +419,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  unmap:
>  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
>  
> -unlock:
> -	mutex_unlock(lock);
> -
>  	return ret;
>  }
>  
> 


-- 
Damien Le Moal
Western Digital Research
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.