Message ID | cover.1641500561.git.christophe.jaillet@wanadoo.fr (mailing list archive) |
---|---|
Headers | show |
Series | Remove usage of the deprecated "pci-dma-compat.h" API | expand |
Christophe, > This serie axes all the remaining usages of the deprecated > "pci-dma-compat.h" API. Applied patches 10-15 to 5.17/scsi-staging, thanks!
On Thu, 6 Jan 2022 22:45:13 +0100, Christophe JAILLET wrote: > This serie axes all the remaining usages of the deprecated "pci-dma-compat.h" > API. > > All these patches have already been posted. > > They have been generated with a coccinelle script. > The tricky parts are patches that use dma_alloc_coherent() because the correct > GFP flag has to be used in place of the previous embedded GFP_ATOMIC. > > [...] Applied to 5.17/scsi-queue, thanks! [10/16] scsi: message: fusion: Remove usage of the deprecated "pci-dma-compat.h" API https://git.kernel.org/mkp/scsi/c/b114dda6f2f1 [11/16] scsi: mptbase: Use dma_alloc_coherent() in 'mpt_alloc_fw_memory()' https://git.kernel.org/mkp/scsi/c/2d50607260a6 [12/16] scsi: mptbase: Use dma_alloc_coherent() https://git.kernel.org/mkp/scsi/c/5c5e6b6f61e0 [13/16] scsi: mptsas: Use dma_alloc_coherent() in mptsas_exp_repmanufacture_info() https://git.kernel.org/mkp/scsi/c/7a960b3a5e37 [14/16] scsi: mptsas: Use dma_alloc_coherent() https://git.kernel.org/mkp/scsi/c/76a334d756c5 [15/16] scsi: mptctl: Use dma_alloc_coherent() https://git.kernel.org/mkp/scsi/c/706dc3b91989
On Thu, Jan 06, 2022 at 10:45:13PM +0100, Christophe JAILLET wrote: > This serie axes all the remaining usages of the deprecated "pci-dma-compat.h" > API. > > All these patches have already been posted. > > They have been generated with a coccinelle script. > The tricky parts are patches that use dma_alloc_coherent() because the correct > GFP flag has to be used in place of the previous embedded GFP_ATOMIC. > > Patches 1-3 are already Reviewed. References to the corresponding mail is > given below the --- > > Patch 1-2,4-10 are just generated from the coccinelle script. Only too long > lines have been hand modified. dma_alloc_coherent() modification are NOT part > of these patches. > > Patch 3 also includes some 'dma_set_mask_and_coherent()' instead of > 'pci_set_dma_mask()/pci_set_consistent_dma_mask()'. > I've left this additional modification because it was reviewed with it. > > Patch 10-15 are the tricky parts. Explanation of which GFP flag is the right one > is given in each patch. It has been divided in several patches to ease review. > > Patch 15 is the only one I'm slighly unsure with. The old code was using a > GFP_USER flag in the function. I'm not familiar with it. > I *guess* that GFP_KERNEL is fine, but maybe it should also be GFP_USER or left > as GFP_ATOMIC so that nothing is changed. > > Patch 16 is the last step that remove "pci-dma-compat.h" and its only usage. > > > All patches, exept 1-2,6 that are architecture specific, have been compile tested. > > > After all that, a few rst files, 1 or 2 strings in error messages and some > error branching labels should still need some attention. > This is some minor issues. > > > Only the cover letter is sent to every one. Each patch is sent to the > corresponding maintainer(s) + Andrew Morton, Christoph Hellwig and Arnd Bergmann. > > > Best regards. > > > Christophe JAILLET (16): > alpha: Remove usage of the deprecated "pci-dma-compat.h" API > floppy: Remove usage of the deprecated "pci-dma-compat.h" API > fpga: dfl: pci: Remove usage of the deprecated "pci-dma-compat.h" API > media: Remove usage of the deprecated "pci-dma-compat.h" API > agp/intel: Remove usage of the deprecated "pci-dma-compat.h" API > sparc: Remove usage of the deprecated "pci-dma-compat.h" API > dmaengine: pch_dma: Remove usage of the deprecated "pci-dma-compat.h" > API > rapidio/tsi721: Remove usage of the deprecated "pci-dma-compat.h" API > media: v4l2-pci-skeleton: Remove usage of the deprecated > "pci-dma-compat.h" API > scsi: message: fusion: Remove usage of the deprecated > "pci-dma-compat.h" API > scsi: mptbase: Use dma_alloc_coherent() in 'mpt_alloc_fw_memory()' > scsi: mptbase: Use dma_alloc_coherent() > scsi: mptsas: Use dma_alloc_coherent() in > mptsas_exp_repmanufacture_info() > scsi: mptsas: Use dma_alloc_coherent() > scsi: mptctl: Use dma_alloc_coherent() > PCI: Remove usage of the deprecated "pci-dma-compat.h" API > > arch/alpha/include/asm/floppy.h | 7 +- > arch/alpha/kernel/pci_iommu.c | 12 +-- > arch/powerpc/include/asm/floppy.h | 8 +- > arch/sparc/kernel/ioport.c | 2 +- > drivers/char/agp/intel-gtt.c | 26 ++--- > drivers/dma/pch_dma.c | 2 +- > drivers/fpga/dfl-pci.c | 14 +-- > drivers/media/pci/cx18/cx18-queue.h | 6 +- > drivers/media/pci/ivtv/ivtv-queue.h | 25 +++-- > drivers/media/pci/ivtv/ivtv-udma.h | 8 +- > drivers/message/fusion/mptbase.c | 149 ++++++++++++++++------------ > drivers/message/fusion/mptctl.c | 82 +++++++++------ > drivers/message/fusion/mptlan.c | 90 +++++++++-------- > drivers/message/fusion/mptsas.c | 94 +++++++++--------- > drivers/rapidio/devices/tsi721.c | 8 +- > include/linux/pci-dma-compat.h | 129 ------------------------ > include/linux/pci.h | 3 - > samples/v4l/v4l2-pci-skeleton.c | 2 +- > 18 files changed, 289 insertions(+), 378 deletions(-) > delete mode 100644 include/linux/pci-dma-compat.h > > -- > 2.32.0 > Applied [03/16] to linux-fpga for-next. Thanks, Moritz
Hi Christophe, do you know what the state is in current linux-next? I think we'll just want to queue up anything left at this point in the dma-mapping or PCI tree and get it done.
Le 23/02/2022 à 08:46, Christoph Hellwig a écrit : > Hi Christophe, > > do you know what the state is in current linux-next? > > I think we'll just want to queue up anything left at this point in the > dma-mapping or PCI tree and get it done. > Hi, Patch 01, 04, 05, 06, 08, 09 have not reached -next yet. They all still apply cleanly. 04 has been picked it up for inclusion in the media subsystem for 5.18. The other ones all have 1 or more Reviewed-by:/Acked-by: tags. Patch 16 must be resubmitted to add "#include <linux/dma-mapping.h>" in order not to break builds. All the other patches have landed in -next. CJ
On Wed, Feb 23, 2022 at 9:26 PM Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote: > > Le 23/02/2022 à 08:46, Christoph Hellwig a écrit : > > Hi Christophe, > > > > do you know what the state is in current linux-next? > > > > I think we'll just want to queue up anything left at this point in the > > dma-mapping or PCI tree and get it done. > > > > Hi, > > Patch 01, 04, 05, 06, 08, 09 have not reached -next yet. > They all still apply cleanly. > > 04 has been picked it up for inclusion in the media subsystem for 5.18. > The other ones all have 1 or more Reviewed-by:/Acked-by: tags. > > Patch 16 must be resubmitted to add "#include <linux/dma-mapping.h>" in > order not to break builds. > > > All the other patches have landed in -next. Ok, these all look trivial. I'd suggest you send the rebase version to Andrew Morton then, so he can pick them all up into linux-mm, on top of the linux-next contents. Arnd
On Wed, Feb 23, 2022 at 09:26:56PM +0100, Christophe JAILLET wrote: > Patch 01, 04, 05, 06, 08, 09 have not reached -next yet. > They all still apply cleanly. > > 04 has been picked it up for inclusion in the media subsystem for 5.18. > The other ones all have 1 or more Reviewed-by:/Acked-by: tags. > > Patch 16 must be resubmitted to add "#include <linux/dma-mapping.h>" in > order not to break builds. So how about this: I'll pick up 1, 5,6,8 and 9 for the dma-mapping tree. After -rc1 when presumably all other patches have reached mainline your resubmit one with the added include and we finish this off? Thanks a lot for all your work already!
On Thu, Feb 24, 2022 at 7:25 AM Christoph Hellwig <hch@infradead.org> wrote: > > On Wed, Feb 23, 2022 at 09:26:56PM +0100, Christophe JAILLET wrote: > > Patch 01, 04, 05, 06, 08, 09 have not reached -next yet. > > They all still apply cleanly. > > > > 04 has been picked it up for inclusion in the media subsystem for 5.18. > > The other ones all have 1 or more Reviewed-by:/Acked-by: tags. > > > > Patch 16 must be resubmitted to add "#include <linux/dma-mapping.h>" in > > order not to break builds. > > So how about this: I'll pick up 1, 5,6,8 and 9 for the dma-mapping > tree. After -rc1 when presumably all other patches have reached > mainline your resubmit one with the added include and we finish this > off? Sounds good to me as well. Arnd
Le 24/02/2022 à 08:07, Arnd Bergmann a écrit : > On Thu, Feb 24, 2022 at 7:25 AM Christoph Hellwig <hch@infradead.org> wrote: >> On Wed, Feb 23, 2022 at 09:26:56PM +0100, Christophe JAILLET wrote: >>> Patch 01, 04, 05, 06, 08, 09 have not reached -next yet. >>> They all still apply cleanly. >>> >>> 04 has been picked it up for inclusion in the media subsystem for 5.18. >>> The other ones all have 1 or more Reviewed-by:/Acked-by: tags. >>> >>> Patch 16 must be resubmitted to add "#include <linux/dma-mapping.h>" in >>> order not to break builds. >> So how about this: I'll pick up 1, 5,6,8 and 9 for the dma-mapping >> tree. After -rc1 when presumably all other patches have reached >> mainline your resubmit one with the added include and we finish this >> off? > Sounds good to me as well. > > Arnd This is fine for me. When all patches have reached -next, I'll re-submit the fixed 16th patch. Thanks for your assistance for ending this long story :) CJ
I've applied patches 1,5,6,8 and 9 to the dma-mapping tree.