Re: [RFC patch] init default dma_ops to prepare intel_iommu_initfailure

From: FUJITA Tomonori
Date: Wed Aug 12 2009 - 22:11:53 EST


On Wed, 12 Aug 2009 17:20:11 +0800
Luming Yu <luming.yu@xxxxxxxxx> wrote:

> Hi there,
>
> On ia64 platform with dmar table and new upstream
> kernel(config_dmar_default_on enabled),
> if intel_iommu_init ends up without dma_ops initialized or other iommu
> failures.
> We got nothing to fall back. The following patch fixes it.

Hmm, I think that the current code should work.

If intel_iommu_init ends up without dma_ops initialized or other iommu
failures, then 'iommu_detected' should be zero.


Note that IA64_DIG_VTD doesn't enable SWIOTLB so there is fall
back. That's kinda the IA64 policy about non IA64_GENERIC kernel.


> Please review. If make sense, please apply.
>
> **The patch is enclosed in text attachment*
> **Using web client to send the patch* *
> **below is for review, please apply attached patch*/
>
> Thanks,
> Luming
>
> Signed-off-by: Yu Luming <luming.yu@xxxxxxxxx>
>
> arch/ia64/kernel/pci-swiotlb.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/arch/ia64/kernel/pci-swiotlb.c b/arch/ia64/kernel/pci-swiotlb.c
> index 223abb1..d5dcaf5 100644
> --- a/arch/ia64/kernel/pci-swiotlb.c
> +++ b/arch/ia64/kernel/pci-swiotlb.c
> @@ -46,15 +46,13 @@ void __init swiotlb_dma_init(void)
>
> void __init pci_swiotlb_init(void)
> {
> - if (!iommu_detected || iommu_pass_through) {
> #ifdef CONFIG_IA64_GENERIC
> - swiotlb = 1;
> - printk(KERN_INFO "PCI-DMA: Re-initialize machine vector.\n");
> - machvec_init("dig");
> - swiotlb_init();
> - dma_ops = &swiotlb_dma_ops;
> + swiotlb = 1;
> + printk(KERN_INFO "PCI-DMA: Re-initialize machine vector.\n");
> + machvec_init("dig");
> + swiotlb_init();
> + dma_ops = &swiotlb_dma_ops;
> #else
> - panic("Unable to find Intel IOMMU");
> + panic("Unable to find Intel IOMMU");
> #endif
> - }
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/