>Well, now, this is a quandry isn't it... Actually, I'm inclined to >agree with you. > >Tony, et al., care to restate your reasoning for moving it under >drivers/pci? Historically swiotlb.c was written with just PCI in mind (hence all the comments ("... implement the PCI DMA API", "The PCI address to use is returned", "teardown the PCI dma mapping") and a few error messages ("PCI-DMA: Out of SW-IOMMU space ...", "PCI-DMA: Memory would be corrupted", "PCI-DMA: Random memory would be DMAed"). Perhaps back then the only options were PCI and ISA???? Matthew is probably technically right in that this is a more generic interface ... but is it actually being used for anything other than PCI? Will it ever be so used? Ignoring the comments and error messages, the attached patch removed the <linux/pci.h> and <asm/pci.h> includes (and adds a couple of others that are then needed, and converts a few PCI_DMA_* defines to DMA_* ones that sound like they mean the same thing). Compiles, but not tested. -Tony
Attachment:
sw.patch
Description: sw.patch
- Follow-Ups:
- Prev by Date: Re: [2.6.13] pktcdvd: IO-errors
- Next by Date: Re: questions on discontgmem.
- Previous by thread: [PATCH] When L3 is present show its size in /proc/cpuinfo
- Next by thread: Re: [patch 2.6.14-rc2 0/5] swiotlb maintenance and x86_64 dma_sync_single_range_for_{cpu,device}
- Index(es):