On 25/01/2019 11:58, Andy Shevchenko wrote:
On Fri, Jan 25, 2019 at 3:50 AM Szabolcs Fruhwald <sfruhwald@xxxxxxxxxx> wrote:
First of all, please do not top post!
I took a quick look at arch_setup_pdev_archdata(), overridden it in
dcdbas.c and it works well (despite it's being called twice, since
it's called from platform_device_alloc and platform_device_register).
However, as I am not super familiar with ELF weak method references,
especially with its scope resolution / versioning part, so as I see
this weak method was introduced mainly for arch/** specific hooks.
Is it safe to override this method from driver code, when let's say
there's another implementation in the x86 arch code (currently there
isn't)?
No, it should be done somewhere in arch/x86.
OTOH, Intel iommu driver can do it based on the check dev_is_pci().
For now I think it's better to solve this inside Intel iommu driver.
Indeed - hacking code into individual device drivers which is entirely
specific to the current implementation of the intel-iommu driver sounds
like a recipe for a maintenance disaster (not to mention the extra fun
if any of those devices also end up in AMD-based systems).
AFAICS, the VT-d spec accommodates non-PCI devices via DRHD and
corresponding ANDD entries, and the driver already has at least some
degree of support for those - see dmar_acpi_insert_dev_scope() - so it
may not need much more than just hooking up to the platform bus. If
these platform devices do actually master through the IOMMU but don't
have an appropriate device scope described, then frankly that's broken
firmware, but the place to work around that would still be in the DMAR code.
Robin.
