[PATCH 1/2] block: remove unused dma_iova_state function parameter

[PATCH 1/2] block: remove unused dma_iova_state function parameter

[Nitesh Shetty]

DMA IOVA state is not used inside blk_rq_dma_map_iter_next

Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
---
 block/blk-mq-dma.c         | 3 +--
 include/linux/blk-mq-dma.h | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c
index 752060d7261cb..3c87779cdc19d 100644
--- a/block/blk-mq-dma.c
+++ b/block/blk-mq-dma.c
@@ -233,7 +233,6 @@ EXPORT_SYMBOL_GPL(blk_rq_dma_map_iter_start);
  * blk_rq_dma_map_iter_next - map the next DMA segment for a request
  * @req:	request to map
  * @dma_dev:	device to map to
- * @state:	DMA IOVA state
  * @iter:	block layer DMA iterator
  *
  * Iterate to the next mapping after a previous call to
@@ -248,7 +247,7 @@ EXPORT_SYMBOL_GPL(blk_rq_dma_map_iter_start);
  * returned in @iter.status.
  */
 bool blk_rq_dma_map_iter_next(struct request *req, struct device *dma_dev,
-		struct dma_iova_state *state, struct blk_dma_iter *iter)
+		struct blk_dma_iter *iter)
 {
 	struct phys_vec vec;
 
diff --git a/include/linux/blk-mq-dma.h b/include/linux/blk-mq-dma.h
index cb88fc791fbd1..214c181ff2c9c 100644
--- a/include/linux/blk-mq-dma.h
+++ b/include/linux/blk-mq-dma.h
@@ -28,7 +28,7 @@ struct blk_dma_iter {
 bool blk_rq_dma_map_iter_start(struct request *req, struct device *dma_dev,
 		struct dma_iova_state *state, struct blk_dma_iter *iter);
 bool blk_rq_dma_map_iter_next(struct request *req, struct device *dma_dev,
-		struct dma_iova_state *state, struct blk_dma_iter *iter);
+		struct blk_dma_iter *iter);
 
 /**
  * blk_rq_dma_map_coalesce - were all segments coalesced?
-- 
2.39.5

[PATCH 2/2] nvme: blk_rq_dma_map_iter_next is no longer using iova state

[Nitesh Shetty]

DMA IOVA state is not used inside blk_rq_dma_map_iter_next

Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
---
 drivers/nvme/host/pci.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 3b528369f5454..065555576d2f9 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -823,7 +823,7 @@ static bool nvme_pci_prp_iter_next(struct request *req, struct device *dma_dev,
 
 	if (iter->len)
 		return true;
-	if (!blk_rq_dma_map_iter_next(req, dma_dev, &iod->dma_state, iter))
+	if (!blk_rq_dma_map_iter_next(req, dma_dev, iter))
 		return false;
 	if (!dma_use_iova(&iod->dma_state) && dma_need_unmap(dma_dev)) {
 		iod->dma_vecs[iod->nr_dma_vecs].addr = iter->addr;
@@ -1010,8 +1010,7 @@ static blk_status_t nvme_pci_setup_data_sgl(struct request *req,
 		}
 		nvme_pci_sgl_set_data(&sg_list[mapped++], iter);
 		iod->total_len += iter->len;
-	} while (blk_rq_dma_map_iter_next(req, nvmeq->dev->dev, &iod->dma_state,
-				iter));
+	} while (blk_rq_dma_map_iter_next(req, nvmeq->dev->dev, iter));
 
 	nvme_pci_sgl_set_seg(&iod->cmd.common.dptr.sgl, sgl_dma, mapped);
 	if (unlikely(iter->status))
-- 
2.39.5

Re: [PATCH 2/2] nvme: blk_rq_dma_map_iter_next is no longer using iova state

[Damien Le Moal]

On 1/12/26 14:57, Nitesh Shetty wrote:
> DMA IOVA state is not used inside blk_rq_dma_map_iter_next
> 
> Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
> ---
>  drivers/nvme/host/pci.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> index 3b528369f5454..065555576d2f9 100644
> --- a/drivers/nvme/host/pci.c
> +++ b/drivers/nvme/host/pci.c
> @@ -823,7 +823,7 @@ static bool nvme_pci_prp_iter_next(struct request *req, struct device *dma_dev,
>  
>  	if (iter->len)
>  		return true;
> -	if (!blk_rq_dma_map_iter_next(req, dma_dev, &iod->dma_state, iter))
> +	if (!blk_rq_dma_map_iter_next(req, dma_dev, iter))

Hu... Why is this not squashed with the previous patch ? If only patch 1 is
applied, this will not compile, right ?

>  		return false;
>  	if (!dma_use_iova(&iod->dma_state) && dma_need_unmap(dma_dev)) {
>  		iod->dma_vecs[iod->nr_dma_vecs].addr = iter->addr;
> @@ -1010,8 +1010,7 @@ static blk_status_t nvme_pci_setup_data_sgl(struct request *req,
>  		}
>  		nvme_pci_sgl_set_data(&sg_list[mapped++], iter);
>  		iod->total_len += iter->len;
> -	} while (blk_rq_dma_map_iter_next(req, nvmeq->dev->dev, &iod->dma_state,
> -				iter));
> +	} while (blk_rq_dma_map_iter_next(req, nvmeq->dev->dev, iter));
>  
>  	nvme_pci_sgl_set_seg(&iod->cmd.common.dptr.sgl, sgl_dma, mapped);
>  	if (unlikely(iter->status))


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 2/2] nvme: blk_rq_dma_map_iter_next is no longer using iova state

[Nitesh Shetty]

[-- Attachment #1: Type: text/plain, Size: 1083 bytes --]

On 12/01/26 03:08PM, Damien Le Moal wrote:
>On 1/12/26 14:57, Nitesh Shetty wrote:
>> DMA IOVA state is not used inside blk_rq_dma_map_iter_next
>>
>> Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com>
>> ---
>>  drivers/nvme/host/pci.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
>> index 3b528369f5454..065555576d2f9 100644
>> --- a/drivers/nvme/host/pci.c
>> +++ b/drivers/nvme/host/pci.c
>> @@ -823,7 +823,7 @@ static bool nvme_pci_prp_iter_next(struct request *req, struct device *dma_dev,
>>
>>  	if (iter->len)
>>  		return true;
>> -	if (!blk_rq_dma_map_iter_next(req, dma_dev, &iod->dma_state, iter))
>> +	if (!blk_rq_dma_map_iter_next(req, dma_dev, iter))
>
>Hu... Why is this not squashed with the previous patch ? If only patch 1 is
>applied, this will not compile, right ?
>
I couldn’t decide whether to use the layering convention or a unified patch,
so I chose one patch per layer.
Agreed, independently this doesn't compile, merging make sense.
I will resend.

Thanks,
Nitesh

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [PATCH 2/2] nvme: blk_rq_dma_map_iter_next is no longer using iova state

[Christoph Hellwig]

On Mon, Jan 12, 2026 at 07:58:22PM +0530, Nitesh Shetty wrote:
>> Hu... Why is this not squashed with the previous patch ? If only patch 1 is
>> applied, this will not compile, right ?
>>
> I couldn’t decide whether to use the layering convention or a unified patch,
> so I chose one patch per layer.
> Agreed, independently this doesn't compile, merging make sense.
> I will resend.

Rule number one is: don't break compilation after each step.
Everything else is secondary.

Also I'm only seeing patch 2 anyway, and not patch 1.