[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1307524659.4771.12.camel@i7.infradead.org>
Date: Wed, 08 Jun 2011 10:17:38 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Ohad Ben-Cohen <ohad@...ery.com>
Cc: Joerg Roedel <Joerg.Roedel@....com>, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Arnd Bergmann <arnd@...db.de>,
David Brown <davidb@...eaurora.org>,
iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH 4/4] x86: intel-iommu: move to drivers/iommu/
On Wed, 2011-06-08 at 11:34 +0300, Ohad Ben-Cohen wrote:
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -30,7 +30,7 @@ obj-$(CONFIG_PCI_MSI) += msi.o
> obj-$(CONFIG_HT_IRQ) += htirq.o
>
> # Build Intel IOMMU support
> -obj-$(CONFIG_DMAR) += dmar.o iova.o intel-iommu.o
> +obj-$(CONFIG_DMAR) += dmar.o iova.o
>
> obj-$(CONFIG_INTR_REMAP) += dmar.o intr_remapping.o
>
At least iova.o wants to go with it. That's one of the parts that is a
candidate for harmonisation across IOMMU implementations, either by
removing it or by having others use it too. It's how we allocate virtual
I/O address space.
I suspect the interrupt remapping support may well want to move with it
too. It's no more out-of-place in drivers/iommu than it is in
drivers/pci. And then you can certainly move dmar.o too.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@...el.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists