On Tue, 27 Jan 2009 09:17:58 -0800
"Luck, Tony" <tony.luck@xxxxxxxxx> wrote:
> > > > ---
> > > > arch/ia64/kernel/dma-mapping.c | 3 +++
> > > > arch/ia64/kernel/pci-swiotlb.c | 3 ---
> > > > 2 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > Applied to tip/core/iommu, thanks!
> >
> > Tony, is this fix fine with you too?
>
> It works ... and dma-mapping.c is OK as a location for the
> definition. But there seemes to be some small scope for a
> related cleanup:
>
> There are "extern" declarations for "iommu_detected" in both
> <asm/iommu.h> (x86 and ia64) and also in <linux/dmar.h>
We can remove them in dmar.h. X86 exported iommu_detected and no_iommu
in several IOMMU code and we merged them into dmar.h. Seems that we
forgot to clean up dmar.h.
> Does having both of these avoid some #include hell?
I think we could. The root problem is that X86 sets up IOMMU in a very
hacky way. When we added VT-d support to IA64, we needed to add the
hacky code to IA64 even though IA64 doesn't need it.
We need to clean up the code to set up IOMMUs. I'll try later.
=
From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
Subject: [PATCH -tip] intel-iommu: no need to export iommu_detected and no_iommu in dmar.h
The users of intel-iommu (x86 and IA64) export iommu_detected and
no_iommu in their own iommu.h.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx>
---
include/linux/dmar.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index f284407..3e82a13 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -129,7 +129,6 @@ extern void dmar_msi_write(int irq, struct msi_msg *msg);
extern int dmar_set_interrupt(struct intel_iommu *iommu);
extern int arch_setup_dmar_msi(unsigned int irq);
-extern int iommu_detected, no_iommu;
extern struct list_head dmar_rmrr_units;
struct dmar_rmrr_unit {
struct list_head list; /* list of rmrr units */
--
1.6.0.6
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|