In [1], Christoph Hellwig has proposed to remove the wrappers in
include/linux/pci-dma-compat.h.

Some reasons why this API should be removed have been given by Julia
Lawall in [2].

A coccinelle script has been used to perform the needed transformation.
Only relevant parts are given below.

@@ @@
-    PCI_DMA_BIDIRECTIONAL
+    DMA_BIDIRECTIONAL

@@ @@
-    PCI_DMA_TODEVICE
+    DMA_TO_DEVICE

@@ @@
-    PCI_DMA_FROMDEVICE
+    DMA_FROM_DEVICE

@@ @@
-    PCI_DMA_NONE
+    DMA_NONE

@@
expression e1, e2, e3, e4;
@@
-    pci_map_single(e1, e2, e3, e4)
+    dma_map_single(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-    pci_unmap_single(e1, e2, e3, e4)
+    dma_unmap_single(&e1->dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-    pci_unmap_sg(e1, e2, e3, e4)
+    dma_unmap_sg(&e1->dev, e2, e3, e4)

[1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
[2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
 arch/alpha/include/asm/floppy.h |  7 ++++---
 arch/alpha/kernel/pci_iommu.c   | 12 ++++++------
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/arch/alpha/include/asm/floppy.h b/arch/alpha/include/asm/floppy.h
index 8dfdb3aa1d96..588758685439 100644
--- a/arch/alpha/include/asm/floppy.h
+++ b/arch/alpha/include/asm/floppy.h
@@ -43,17 +43,18 @@ alpha_fd_dma_setup(char *addr, unsigned long size, int mode, int io)
 	static int prev_dir;
 	int dir;
 
-	dir = (mode != DMA_MODE_READ) ? PCI_DMA_FROMDEVICE : PCI_DMA_TODEVICE;
+	dir = (mode != DMA_MODE_READ) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
 
 	if (bus_addr 
 	    && (addr != prev_addr || size != prev_size || dir != prev_dir)) {
 		/* different from last time -- unmap prev */
-		pci_unmap_single(isa_bridge, bus_addr, prev_size, prev_dir);
+		dma_unmap_single(&isa_bridge->dev, bus_addr, prev_size,
+				 prev_dir);
 		bus_addr = 0;
 	}
 
 	if (!bus_addr)	/* need to map it */
-		bus_addr = pci_map_single(isa_bridge, addr, size, dir);
+		bus_addr = dma_map_single(&isa_bridge->dev, addr, size, dir);
 
 	/* remember this one as prev */
 	prev_addr = addr;
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 21f9ac101324..e83a02ed5267 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -333,7 +333,7 @@ static dma_addr_t alpha_pci_map_page(struct device *dev, struct page *page,
 	struct pci_dev *pdev = alpha_gendev_to_pci(dev);
 	int dac_allowed;
 
-	BUG_ON(dir == PCI_DMA_NONE);
+	BUG_ON(dir == DMA_NONE);
 
 	dac_allowed = pdev ? pci_dac_dma_supported(pdev, pdev->dma_mask) : 0; 
 	return pci_map_single_1(pdev, (char *)page_address(page) + offset, 
@@ -356,7 +356,7 @@ static void alpha_pci_unmap_page(struct device *dev, dma_addr_t dma_addr,
 	struct pci_iommu_arena *arena;
 	long dma_ofs, npages;
 
-	BUG_ON(dir == PCI_DMA_NONE);
+	BUG_ON(dir == DMA_NONE);
 
 	if (dma_addr >= __direct_map_base
 	    && dma_addr < __direct_map_base + __direct_map_size) {
@@ -460,7 +460,7 @@ static void alpha_pci_free_coherent(struct device *dev, size_t size,
 				    unsigned long attrs)
 {
 	struct pci_dev *pdev = alpha_gendev_to_pci(dev);
-	pci_unmap_single(pdev, dma_addr, size, PCI_DMA_BIDIRECTIONAL);
+	dma_unmap_single(&pdev->dev, dma_addr, size, DMA_BIDIRECTIONAL);
 	free_pages((unsigned long)cpu_addr, get_order(size));
 
 	DBGA2("pci_free_consistent: [%llx,%zx] from %ps\n",
@@ -639,7 +639,7 @@ static int alpha_pci_map_sg(struct device *dev, struct scatterlist *sg,
 	dma_addr_t max_dma;
 	int dac_allowed;
 
-	BUG_ON(dir == PCI_DMA_NONE);
+	BUG_ON(dir == DMA_NONE);
 
 	dac_allowed = dev ? pci_dac_dma_supported(pdev, pdev->dma_mask) : 0;
 
@@ -702,7 +702,7 @@ static int alpha_pci_map_sg(struct device *dev, struct scatterlist *sg,
 	/* Some allocation failed while mapping the scatterlist
 	   entries.  Unmap them now.  */
 	if (out > start)
-		pci_unmap_sg(pdev, start, out - start, dir);
+		dma_unmap_sg(&pdev->dev, start, out - start, dir);
 	return -ENOMEM;
 }
 
@@ -722,7 +722,7 @@ static void alpha_pci_unmap_sg(struct device *dev, struct scatterlist *sg,
 	dma_addr_t max_dma;
 	dma_addr_t fbeg, fend;
 
-	BUG_ON(dir == PCI_DMA_NONE);
+	BUG_ON(dir == DMA_NONE);
 
 	if (! alpha_mv.mv_pci_tbi)
 		return;
-- 
2.32.0

On Sun, Jan 2, 2022 at 10:32 AM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
>
> In [1], Christoph Hellwig has proposed to remove the wrappers in
> include/linux/pci-dma-compat.h.
>
> Some reasons why this API should be removed have been given by Julia
> Lawall in [2].
>
> A coccinelle script has been used to perform the needed transformation.
> Only relevant parts are given below.
>
>
> [1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
> [2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

It looks like the number of remaining files that use the old
interfaces has gone down
a lot more since you last sent these patches. I would suggest you send them as a
series that includes the patch to remove the header as the last change, and
ask Andrew to pick up the ones that remain after this resend into the -mm tree,
possibly after the next -rc1. How many patches do you have left?

         Arnd

Le 03/01/2022 à 02:51, Arnd Bergmann a écrit :
> On Sun, Jan 2, 2022 at 10:32 AM Christophe JAILLET
> <christophe.jaillet@wanadoo.fr> wrote:
>>
>> In [1], Christoph Hellwig has proposed to remove the wrappers in
>> include/linux/pci-dma-compat.h.
>>
>> Some reasons why this API should be removed have been given by Julia
>> Lawall in [2].
>>
>> A coccinelle script has been used to perform the needed transformation.
>> Only relevant parts are given below.
>>
>>
>> [1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
>> [2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> It looks like the number of remaining files that use the old
> interfaces has gone down
> a lot more since you last sent these patches. I would suggest you send them as a
> series that includes the patch to remove the header as the last change, and
> ask Andrew to pick up the ones that remain after this resend into the -mm tree,
> possibly after the next -rc1. How many patches do you have left?
> 
>           Arnd
> 

Hi,

This would be ~ 10 patches.
I sent recently some missing ones because I was not aware of 
--include-headers. So .h files were missing in my previous patches.


The main remaining issue is linked to files in message/fusion.
The patches are big.
They have to be looked at carefully because it touches some GFP flags 
when s/pci_alloc_consistent/dma_alloc_coherent/.

My last try did not get any attention.
Even [1] which is purely mechanical

I'll try another approach without trying to turn some (hidden) 
GFP_ATOMIC into GFP_KERNEL.
1st patch: only mechanical changes done with coccinelle, leaving GFP_ATOMIC
2nd patch: add some FIXME comments explaining why some could be turned 
into GFP_KERNEL
3rd patch: remove the comments and update the GFP flags accordingly.

So, a maintainer could either apply 1 (no risk at all, should even 
generate the same .o file), or 1+2 (only FIXME comments for future 
analysis) or 1+2+3 for full clean-up (if he trusts me and/or has time to 
check my explanations).

This way, I hope that some could at least apply the first one.


Being able to axe this deprecated API and .h file would be my 
contribution to Ingo Molnar's "Fast Kernel Headers" tree :)

CJ

[1]: 
https://lore.kernel.org/kernel-janitors/db5aa78d7d44b809ab83ba6fb4880d698517bfec.1623580326.git.christophe.jaillet@wanadoo.fr/

On Wed, Jan 5, 2022 at 4:23 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Le 03/01/2022 à 02:51, Arnd Bergmann a écrit :
> > On Sun, Jan 2, 2022 at 10:32 AM Christophe JAILLET
> > It looks like the number of remaining files that use the old
> > interfaces has gone down
> > a lot more since you last sent these patches. I would suggest you send them as a
> > series that includes the patch to remove the header as the last change, and
> > ask Andrew to pick up the ones that remain after this resend into the -mm tree,
> > possibly after the next -rc1. How many patches do you have left?
> >
>
> This would be ~ 10 patches.
> I sent recently some missing ones because I was not aware of
> --include-headers. So .h files were missing in my previous patches.
>
>
> The main remaining issue is linked to files in message/fusion.
> The patches are big.
> They have to be looked at carefully because it touches some GFP flags
> when s/pci_alloc_consistent/dma_alloc_coherent/.
>
> My last try did not get any attention.
> Even [1] which is purely mechanical
>
> I'll try another approach without trying to turn some (hidden)
> GFP_ATOMIC into GFP_KERNEL.
> 1st patch: only mechanical changes done with coccinelle, leaving GFP_ATOMIC
> 2nd patch: add some FIXME comments explaining why some could be turned
> into GFP_KERNEL
> 3rd patch: remove the comments and update the GFP flags accordingly.
>
> So, a maintainer could either apply 1 (no risk at all, should even
> generate the same .o file), or 1+2 (only FIXME comments for future
> analysis) or 1+2+3 for full clean-up (if he trusts me and/or has time to
> check my explanations).
>
> This way, I hope that some could at least apply the first one.

If it's down to 10 patches, just send them as a series with Andrew Morton,
Christoph Hellwig and me as recipients, in addition to the respective
subsystem maintainers. Christoph and I can make sure that every
patch is reviewed and then it's either the subsystem maintainers that pick
them up, and one of us that applies all the remaining ones in the mm,
dma-mapping, or asm-generic trees.

What I've seen from your patches all looks good, and I just want
them to be done, no need to wait forever for maintainers to reply
when they have had their chance several times before.

          Arnd