ACPI/IORT: Handle memory address size limits as limits

Return the Root Complex/Named Component memory address size limit as an
inclusive limit value, rather than an exclusive size. This saves having

ACPI/IORT: Handle memory address size limits as limits

Return the Root Complex/Named Component memory address size limit as an
inclusive limit value, rather than an exclusive size. This saves having
to fudge an off-by-one for the 64-bit case, and simplifies our caller.

Acked-by: Hanjun Guo <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Tested-by: Hanjun Guo <[email protected]>
Signed-off-by: Robin Murphy <[email protected]>
Link: https://lore.kernel.org/r/284ae9fbadb12f2e3b5a30cd4d037d0e6843a8f4.1713523152.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

perf/smmuv3: Enable HiSilicon Erratum 162001900 quirk for HIP08/09

Some HiSilicon SMMU PMCG suffers the erratum 162001900 that the PMU
disable control sometimes fail to disable the counters. This wi

perf/smmuv3: Enable HiSilicon Erratum 162001900 quirk for HIP08/09

Some HiSilicon SMMU PMCG suffers the erratum 162001900 that the PMU
disable control sometimes fail to disable the counters. This will lead
to error or inaccurate data since before we enable the counters the
counter's still counting for the event used in last perf session.

This patch tries to fix this by hardening the global disable process.
Before disable the PMU, writing an invalid event type (0xffff) to
focibly stop the counters. Correspondingly restore each events on
pmu::pmu_enable().

Signed-off-by: Yicong Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>

show more ...

irqchip/gicv3: Add a iort_pmsi_get_dev_id() prototype

iort_pmsi_get_dev_id() has a __weak definition in the driver, and
an override in arm64 specific code, but the declaration is conditional
and not

irqchip/gicv3: Add a iort_pmsi_get_dev_id() prototype

iort_pmsi_get_dev_id() has a __weak definition in the driver, and
an override in arm64 specific code, but the declaration is conditional
and not always seen when the copy in the driver gets built:

drivers/irqchip/irq-gic-v3-its-platform-msi.c:41:12: error: no previous prototype for 'iort_pmsi_get_dev_id' [-Werror=missing-prototypes]

Move the existing declaration out of the #ifdef block to ensure
it can be seen in all configurations.

Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

ACPI: bus: Consolidate all arm specific initialisation into acpi_arm_init()

Move all of the ARM-specific initialization into one function namely
acpi_arm_init(), so it is not necessary to modify/upd

ACPI: bus: Consolidate all arm specific initialisation into acpi_arm_init()

Move all of the ARM-specific initialization into one function namely
acpi_arm_init(), so it is not necessary to modify/update bus.c every
time a new piece of it is added.

Cc: Lorenzo Pieralisi <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Suggested-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Link: https://lore.kernel.org/r/CAJZ5v0iBZRZmV_oU+VurqxnVMbFN_ttqrL=cLh0sUH+=u0PYsw@mail.gmail.com
Signed-off-by: Sudeep Holla <[email protected]>
Reviewed-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Shaoqin Huang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI/IORT: Add a helper to retrieve RMR info directly

This will provide a way for SMMU drivers to retrieve StreamIDs
associated with IORT RMR nodes and use that to set bypass settings
for those IDs.

ACPI/IORT: Add a helper to retrieve RMR info directly

This will provide a way for SMMU drivers to retrieve StreamIDs
associated with IORT RMR nodes and use that to set bypass settings
for those IDs.

Tested-by: Steven Price <[email protected]>
Tested-by: Laurentiu Tudor <[email protected]>
Tested-by: Hanjun Guo <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Signed-off-by: Shameer Kolothum <[email protected]>
Acked-by: Robin Murphy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI/IORT: Provide a generic helper to retrieve reserve regions

Currently IORT provides a helper to retrieve HW MSI reserve regions.
Change this to a generic helper to retrieve any IORT related rese

ACPI/IORT: Provide a generic helper to retrieve reserve regions

Currently IORT provides a helper to retrieve HW MSI reserve regions.
Change this to a generic helper to retrieve any IORT related reserve
regions. This will be useful when we add support for RMR nodes in
subsequent patches.

[Lorenzo: For ACPI IORT]

Reviewed-by: Lorenzo Pieralisi <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Tested-by: Steven Price <[email protected]>
Tested-by: Laurentiu Tudor <[email protected]>
Tested-by: Hanjun Guo <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Signed-off-by: Shameer Kolothum <[email protected]>
Acked-by: Robin Murphy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI/IORT: Make iort_iommu_msi_get_resv_regions() return void

At present iort_iommu_msi_get_resv_regions() returns the number of
MSI reserved regions on success and there are no users for this.
The

ACPI/IORT: Make iort_iommu_msi_get_resv_regions() return void

At present iort_iommu_msi_get_resv_regions() returns the number of
MSI reserved regions on success and there are no users for this.
The reserved region list will get populated anyway for platforms
that require the HW MSI region reservation. Hence, change the
function to return void instead.

Reviewed-by: Christoph Hellwig <[email protected]>
Tested-by: Steven Price <[email protected]>
Tested-by: Laurentiu Tudor <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Signed-off-by: Shameer Kolothum <[email protected]>
Acked-by: Robin Murphy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI: Move IOMMU setup code out of IORT

Extract the code that sets up the IOMMU infrastructure from IORT, since
it can be reused by VIOT. Move it one level up into a new
acpi_iommu_configure_id() fu

ACPI: Move IOMMU setup code out of IORT

Extract the code that sets up the IOMMU infrastructure from IORT, since
it can be reused by VIOT. Move it one level up into a new
acpi_iommu_configure_id() function, which calls the IORT parsing
function which in turn calls the acpi_iommu_fwspec_init() helper.

Signed-off-by: Jean-Philippe Brucker <[email protected]>
Reviewed-by: Eric Auger <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI: arm64: Move DMA setup operations out of IORT

Extract generic DMA setup code out of IORT, so it can be reused by VIOT.
Keep it in drivers/acpi/arm64 for now, since it could break x86
platforms

ACPI: arm64: Move DMA setup operations out of IORT

Extract generic DMA setup code out of IORT, so it can be reused by VIOT.
Keep it in drivers/acpi/arm64 for now, since it could break x86
platforms that haven't run this code so far, if they have invalid
tables.

Reviewed-by: Eric Auger <[email protected]>
Signed-off-by: Jean-Philippe Brucker <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

arm64: mm: Set ZONE_DMA size based on early IORT scan

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particul

arm64: mm: Set ZONE_DMA size based on early IORT scan

We recently introduced a 1 GB sized ZONE_DMA to cater for platforms
incorporating masters that can address less than 32 bits of DMA, in
particular the Raspberry Pi 4, which has 4 or 8 GB of DRAM, but has
peripherals that can only address up to 1 GB (and its PCIe host
bridge can only access the bottom 3 GB)

Instructing the DMA layer about these limitations is straight-forward,
even though we had to fix some issues regarding memory limits set in
the IORT for named components, and regarding the handling of ACPI _DMA
methods. However, the DMA layer also needs to be able to allocate
memory that is guaranteed to meet those DMA constraints, for bounce
buffering as well as allocating the backing for consistent mappings.

This is why the 1 GB ZONE_DMA was introduced recently. Unfortunately,
it turns out the having a 1 GB ZONE_DMA as well as a ZONE_DMA32 causes
problems with kdump, and potentially in other places where allocations
cannot cross zone boundaries. Therefore, we should avoid having two
separate DMA zones when possible.

So let's do an early scan of the IORT, and only create the ZONE_DMA
if we encounter any devices that need it. This puts the burden on
the firmware to describe such limitations in the IORT, which may be
redundant (and less precise) if _DMA methods are also being provided.
However, it should be noted that this situation is highly unusual for
arm64 ACPI machines. Also, the DMA subsystem still gives precedence to
the _DMA method if implemented, and so we will not lose the ability to
perform streaming DMA outside the ZONE_DMA if the _DMA method permits
it.

[nsaenz: unified implementation with DT's counterpart]

Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Tested-by: Jeremy Linton <[email protected]>
Acked-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Hanjun Guo <[email protected]>
Cc: Jeremy Linton <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Nicolas Saenz Julienne <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Robin Murphy <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Anshuman Khandual <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI/IORT: Add an input ID to acpi_dma_configure()

Some HW devices are created as child devices of proprietary busses,
that have a bus specific policy defining how the child devices
wires representi

ACPI/IORT: Add an input ID to acpi_dma_configure()

Some HW devices are created as child devices of proprietary busses,
that have a bus specific policy defining how the child devices
wires representing the devices ID are translated into IOMMU and
IRQ controllers device IDs.

Current IORT code provides translations for:

- PCI devices, where the device ID is well identified at bus level
as the requester ID (RID)
- Platform devices that are endpoint devices where the device ID is
retrieved from the ACPI object IORT mappings (Named components single
mappings). A platform device is represented in IORT as a named
component node

For devices that are child devices of proprietary busses the IORT
firmware represents the bus node as a named component node in IORT
and it is up to that named component node to define in/out bus
specific ID translations for the bus child devices that are
allocated and created in a bus specific manner.

In order to make IORT ID translations available for proprietary
bus child devices, the current ACPI (and IORT) code must be
augmented to provide an additional ID parameter to acpi_dma_configure()
representing the child devices input ID. This ID is bus specific
and it is retrieved in bus specific code.

By adding an ID parameter to acpi_dma_configure(), the IORT
code can map the child device ID to an IOMMU stream ID through
the IORT named component representing the bus in/out ID mappings.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Robin Murphy <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI/IORT: Make iort_msi_map_rid() PCI agnostic

There is nothing PCI specific in iort_msi_map_rid().

Rename the function using a bus protocol agnostic name,
iort_msi_map_id(), and convert current c

ACPI/IORT: Make iort_msi_map_rid() PCI agnostic

There is nothing PCI specific in iort_msi_map_rid().

Rename the function using a bus protocol agnostic name,
iort_msi_map_id(), and convert current callers to it.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Robin Murphy <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic

iort_get_device_domain() is PCI specific but it need not be,
since it can be used to retrieve IRQ domain nexus of any kind
by adding an irq

ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic

iort_get_device_domain() is PCI specific but it need not be,
since it can be used to retrieve IRQ domain nexus of any kind
by adding an irq_domain_bus_token input to it.

Make it PCI agnostic by also renaming the requestor ID input
to a more generic ID name.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]> # pci/msi.c
Cc: Will Deacon <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Sudeep Holla <[email protected]>
Cc: Robin Murphy <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 320

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms and c

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 320

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms and conditions of the gnu general public license
version 2 as published by the free software foundation this program
is distributed in the hope it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details you should have received a copy of the gnu general
public license along with this program if not write to the free
software foundation inc 59 temple place suite 330 boston ma 02111
1307 usa

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 33 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Alexios Zavras <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

perf/smmuv3: Enable HiSilicon Erratum 162001800 quirk

HiSilicon erratum 162001800 describes the limitation of
SMMUv3 PMCG implementation on HiSilicon Hip08 platforms.

On these platforms, the PMCG e

perf/smmuv3: Enable HiSilicon Erratum 162001800 quirk

HiSilicon erratum 162001800 describes the limitation of
SMMUv3 PMCG implementation on HiSilicon Hip08 platforms.

On these platforms, the PMCG event counter registers
(SMMU_PMCG_EVCNTRn) are read only and as a result it
is not possible to set the initial counter period value
on event monitor start.

To work around this, the current value of the counter
is read and used for delta calculations. OEM information
from ACPI header is used to identify the affected hardware
platforms.

Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Acked-by: Lorenzo Pieralisi <[email protected]>
[will: update silicon-errata.txt and add reason string to acpi match]
Signed-off-by: Will Deacon <[email protected]>

show more ...

ACPI/IORT: Add support for PMCG

Add support for the SMMU Performance Monitor Counter Group
information from ACPI. This is in preparation for its use
in the SMMUv3 PMU driver.

Signed-off-by: Neil Le

ACPI/IORT: Add support for PMCG

Add support for the SMMU Performance Monitor Counter Group
information from ACPI. This is in preparation for its use
in the SMMUv3 PMU driver.

Signed-off-by: Neil Leeder <[email protected]>
Signed-off-by: Hanjun Guo <[email protected]>
Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Acked-by: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>

show more ...

ACPI/IORT: Add msi address regions reservation helper

On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
speci

ACPI/IORT: Add msi address regions reservation helper

On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.

Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations. The function checks for the smmu model number and
only applies the msi reservation if the platform requires it.

Signed-off-by: Shameer Kolothum <[email protected]>
Reviewed-by: Lorenzo Pieralisi <[email protected]>
[For the ITS part]
Reviewed-by: Marc Zyngier <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI/IORT: Improve functions return type/storage class specifier indentation

Some functions definition indentations are using a style that is frowned
upon with return value type/storage class specif

ACPI/IORT: Improve functions return type/storage class specifier indentation

Some functions definition indentations are using a style that is frowned
upon with return value type/storage class specifier in a separate line.

Reindent the function definitions to fix them.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Hanjun Guo <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Sudeep Holla <[email protected]>

show more ...

ACPI: Make acpi_dma_configure() DMA regions aware

Current ACPI DMA configuration set-up device DMA capabilities through
kernel defaults that do not take into account platform specific DMA
configurat

ACPI: Make acpi_dma_configure() DMA regions aware

Current ACPI DMA configuration set-up device DMA capabilities through
kernel defaults that do not take into account platform specific DMA
configurations reported by firmware.

By leveraging the ACPI acpi_dev_get_dma_resources() API, add code
in acpi_dma_configure() to retrieve the DMA regions to correctly
set-up PCI devices DMA parameters.

Rework the ACPI IORT kernel API to make sure they can accommodate
the DMA set-up required by firmware. By making PCI devices DMA set-up
ACPI IORT specific, the kernel is shielded from unwanted regressions
that could be triggered by parsing DMA resources on arches that were
previously ignoring them (ie x86/ia64), leaving kernel behaviour
unchanged on those arches.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Will Deacon <[email protected]>
Tested-by: Nate Watterson <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

ACPI/IORT: Remove iort_node_match()

Commit 316ca8804ea8 ("ACPI/IORT: Remove linker section for IORT entries
probing") removed the linker section for IORT entries probing.

Since those IORT entries w

ACPI/IORT: Remove iort_node_match()

Commit 316ca8804ea8 ("ACPI/IORT: Remove linker section for IORT entries
probing") removed the linker section for IORT entries probing.

Since those IORT entries were the only iort_node_match() interface
users, the iort_node_match() became obsolete and can then be removed.

Remove the ACPI IORT iort_node_match() interface from the kernel.

Acked-by: Marc Zyngier <[email protected]>
Acked-by: Hanjun Guo <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Cc: Hanjun Guo <[email protected]>
Signed-off-by: Will Deacon <[email protected]>

show more ...

ACPI/IORT: Remove linker section for IORT entries probing

The IORT linker section introduced by commit 34ceea275f62
("ACPI/IORT: Introduce linker section for IORT entries probing")
was needed to mak

ACPI/IORT: Remove linker section for IORT entries probing

The IORT linker section introduced by commit 34ceea275f62
("ACPI/IORT: Introduce linker section for IORT entries probing")
was needed to make sure SMMU drivers are registered (and therefore
probed) in the kernel before devices using the SMMU have a chance
to probe in turn.

Through the introduction of deferred IOMMU configuration the linker
section based IORT probing infrastructure is not needed any longer, in
that device/SMMU probe dependencies are managed through the probe
deferral mechanism, making the IORT linker section infrastructure
unused, so that it can be removed.

Remove the unused IORT linker section probing infrastructure
from the kernel to complete the ACPI IORT IOMMU configure probe
deferral mechanism implementation.

Tested-by: Hanjun Guo <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Cc: Sricharan R <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI: platform: setup MSI domain for ACPI based platform device

By allowing platform MSI domain to be created on ACPI platforms,
a platform device MSI domain can be set-up when it is probed.

In ord

ACPI: platform: setup MSI domain for ACPI based platform device

By allowing platform MSI domain to be created on ACPI platforms,
a platform device MSI domain can be set-up when it is probed.

In order to do that, the MSI domain the platform device connects
to should be retrieved, so the iort_get_platform_device_domain() is
introduced to retrieve the domain from the IORT kernel layer.

With the domain retrieved, we need a proper way to set the
domain to platform device.

Given that some platform devices (irqchips) require the MSI irqdomain
to be their interrupt parent domain, the MSI irqdomain should be
determined before platform device is probed but after the platform
device is allocated which means that the code setting up the MSI
irqdomain, ie acpi_configure_pmsi_domain() should be called in
acpi_platform_notify() (that is triggered after adding a device but
before the respective driver is probed) for the platform MSI domain
code set-up path to work properly.

Acked-by: Rafael J. Wysocki <[email protected]> [for glue.c]
Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>

show more ...

ACPI: platform-msi: retrieve devid from IORT

For devices connecting to an ITS, the devices need to identify themself
through a devid; this devid is represented in the IORT table in named
component n

ACPI: platform-msi: retrieve devid from IORT

For devices connecting to an ITS, the devices need to identify themself
through a devid; this devid is represented in the IORT table in named
component node [1] for platform devices, so this patch adds code that
scans the IORT table to retrieve the devices devid.

Add an IORT interface to collect ITS devices devid to carry out platform
devices MSI mappings with IORT tables.

[1]: https://static.docs.arm.com/den0049/b/DEN0049B_IO_Remapping_Table.pdf

Signed-off-by: Hanjun Guo <[email protected]>
[[email protected]: rewrote commit log/dropped ITS changes]
Signed-off-by: Lorenzo Pieralisi <[email protected]>
Tested-by: Ming Lei <[email protected]>
Tested-by: Wei Xu <[email protected]>
Tested-by: Sinan Kaya <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
Cc: Thomas Gleixner <[email protected]>

show more ...

ACPI/IORT: Make dma masks set-up IORT specific

The introduction of acpi_dma_configure() allows to configure DMA
and related IOMMU for any device that is DMA capable. To achieve
that goal it ensures

ACPI/IORT: Make dma masks set-up IORT specific

The introduction of acpi_dma_configure() allows to configure DMA
and related IOMMU for any device that is DMA capable. To achieve
that goal it ensures DMA masks are set-up to sane default values
before proceeding with IOMMU and DMA ops configuration.

On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
called for every device that has an ACPI companion, in that every device
is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
which has the side effect of initializing dma masks also for
pseudo-devices (eg CPUs and memory nodes) and potentially for devices
whose dma masks were not set-up before the acpi_dma_configure() API was
introduced, which may have noxious side effects.

Therefore, in preparation for IORT firmware specific DMA masks set-up,
wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
default expected behaviour on x86/ia64 systems and keeping DMA default
masks set-up on IORT based (ie ARM) arch configurations.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Will Deacon <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Hanjun Guo <[email protected]>
Tested-by: Hanjun Guo <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Robin Murphy <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
Cc: Joerg Roedel <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Sricharan R <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

ACPI/IORT: Introduce iort_iommu_configure

DT based systems have a generic kernel API to configure IOMMUs
for devices (ie of_iommu_configure()).

On ARM based ACPI systems, the of_iommu_configure() e

ACPI/IORT: Introduce iort_iommu_configure

DT based systems have a generic kernel API to configure IOMMUs
for devices (ie of_iommu_configure()).

On ARM based ACPI systems, the of_iommu_configure() equivalent can
be implemented atop ACPI IORT kernel API, with the corresponding
functions to map device identifiers to IOMMUs and retrieve the
corresponding IOMMU operations necessary for DMA operations set-up.

By relying on the iommu_fwspec generic kernel infrastructure,
implement the IORT based IOMMU configuration for ARM ACPI systems
and hook it up in the ACPI kernel layer that implements DMA
configuration for a device.

Signed-off-by: Lorenzo Pieralisi <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]> [ACPI core]
Reviewed-by: Tomasz Nowicki <[email protected]>
Tested-by: Hanjun Guo <[email protected]>
Tested-by: Tomasz Nowicki <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Tomasz Nowicki <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Signed-off-by: Will Deacon <[email protected]>

show more ...