Re: [PATCH] dcdbas: Fix Intel-IOMMU domain allocation failure

[Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Thu, Jan 24, 2019 at 10:31 PM Szabolcs Fruhwald <sfruhwald-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>
> (+iommu list for visibility and confirmation of the intended constant
> externalization, see 2nd point below)

> Absolutely, I thought so too. But, since the actual need to force
> id-mapping comes from the lack of support for non-pci buses
> particularly by the intel iommu implementation, it seemed a bit odd to
> move this constant into iommu.h. Other platforms' implementations are
> usually handling and hooking into other buses, eg platform bus.
>
> However, even these other hw platform iommu implementations are using
> ACPI or other (bios related) tables to generate source ids, which
> might still be an issue with drivers like dcdbas, with no real device
> info in these tables. Not to mention that forcing id-mapping might be
> a useful tool in driver developers' hands by other reasons too.
> Therefore, I just came to the conclusion that it is indeed useful to
> have this constant present in the common iommu header file (but with a
> more expressing name).
>
> Especially, as I just found that dcdbas is *not* the first one to
> implement this workaround:
> https://github.com/torvalds/linux/blob/71f3a82fab1b631ae9cb1feb677f498d4ca5007d/drivers/gpu/drm/i915/selftests/mock_gem_device.c#L154

> Let me come up with a v2 patch-set, containing a separate patch
> externalizing this constant from intel_iommu.c to iommu.h and making
> the above code using it too first, followed by this change in dcdbas.

Wait... It sounds to me like a part of arch code where we define
arch_setup_pdev_archdata() and use this dummy domain.
Though dummy domain definition should come from IOMMU framework.

-- 
With Best Regards,
Andy Shevchenko