RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta ; robh...@kernel.org;
> frowand.l...@gmail.com
> Cc: will.dea...@arm.com; mark.rutl...@arm.com; catalin.mari...@arm.com;
> h...@lst.de; gre...@linuxfoundation.org; j...@8bytes.org;
> m.szyprow...@samsung.com; shawn...@kernel.org; bhelg...@google.com;
> iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linuxppc-
> d...@lists.ozlabs.org; linux-...@vger.kernel.org; Bharat Bhushan
> ; stuyo...@gmail.com; Laurentiu Tudor
> ; Leo Li 
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.

Nipun, please clarify that only function name is changed and rest of body is 
same.

> >
> > Signed-off-by: Nipun Gupta 
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU?

Yes, this will be a problem with MSI 

> I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.
> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look 
> around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could 
> live?

drivers/of/address.c may be proper place to move until someone have better idea.

Thanks
-Bharat

> 
> >   drivers/of/irq.c |   6 +--
> >   drivers/pci/of.c | 101 
> > 
> >   include/linux/of_iommu.h |  11 +
> >   include/linux/of_pci.h   |  10 -
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index
> > 5c36a8b..4e7712f 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
> > return ops->of_xlate(dev, iommu_spec);
> >   }
> >
> > +/**
> > + * of_map_rid - Translate a requester ID through a downstream mapping.
> > + * @np: root complex device node.
> > + * @rid: device requester ID to map.
> > + * @map_name: property name of the map to use.
> > + * @map_mask_name: optional property name of the mask to use.
> > + * @target: optional pointer to a target device node.
> > + * @id_out: optional pointer to receive the translated ID.
> > + *
> > + * Given a device requester ID, look up the appropriate
> > +implementation-defined
> > + * platform ID and/or the target device which receives transactions
> > +on that
> > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > +@target or
> > + * @id_out may be NULL if only the other is required. If @target
> > +points to
> > + * a non-NULL device node pointer, only entries targeting that node
> > +will be
> > + * matched; if it points to a NULL value, it will receive the device
> > +node of
> > + * the first matching target phandle, with a reference held.
> > + *
> > + * Return: 0 on success or a standard error code on failure.
> > + */
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +  const char *map_name, const char *map_mask_name,
> > +  struct device_node **target, u32 *id_out) {
> > +   u32 map_mask, masked_rid;
> > +   int map_len;
> > +   const __be32 *map = NULL;
> > +
> > +   if (!np || !map_name || (!target && !id_out))
> > +   return -EINVAL;
> > +
> > +   map = of_get_property(np, map_name, _len);
> > +   if (!map) {
> > +   if (target)
> > +   return -ENODEV;
> > +   /* Otherwise, no map implies no translation */
> > +   *id_out = rid;
> > +   return 0;
> > +   }
> > +
> > +   if (!map_len || map_len % (4 * sizeof(*map))) {
> > +   pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > +   map_name, map_len);
> > +   return -EINVAL;
> > +   }
> > +
> > +   /* The default is to select all bits. */
> > +   map_mask = 0x;
> > +
> > +   /*
> > +* Can be overridden by "{iommu,msi}-map-mask" property.
> > +*/
> > +   if (map_mask_name)
> > +   of_property_read_u32(np, map_mask_name, _mask);
> > +
> > +   masked_rid = map_mask & rid;
> > +   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > +   struct device_node *phandle_node;
> > +   u32 rid_base = be32_to_cpup(map + 0);
> > +   u32 phandle = be32_to_cpup(map + 1);
> > +   u32 out_base = be32_to_cpup(map + 2);
> > +   

Re: [PATCH 01/12] iommu-common: move to arch/sparc

[Christoph Hellwig]

On Mon, Apr 16, 2018 at 09:58:33AM -0400, David Miller wrote:
> From: Anshuman Khandual 
> Date: Mon, 16 Apr 2018 14:26:07 +0530
> 
> > On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
> >> This code is only used by sparc, and all new iommu drivers should use the
> >> drivers/iommu/ framework.  Also remove the unused exports.
> >> 
> >> Signed-off-by: Christoph Hellwig 
> > 
> > Right, these functions are used only from SPARC architecture. Simple
> > git grep confirms it as well. Hence it makes sense to move them into
> > arch code instead.
> 
> Well, we put these into a common location and used type friendly for
> powerpc because we hoped powerpc would convert over to using this
> common piece of code as well.
> 
> But nobody did the powerpc work.
> 
> If you look at the powerpc iommu support, it's the same code basically
> for entry allocation.

I could also introduce a new config symbol and keep it in common code,
but it has been there for a while without any new user.

Right now it just means we built the code for everyone who selects
CONFIG_IOMMU_HELPER, which is just about anyone these days.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 18/20] spi: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Mark Brown 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/spi/Kconfig | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2d4146ce2f1be49d..5a8524a3bc13f92d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -71,7 +71,6 @@ config SPI_ARMADA_3700
 
 config SPI_ATMEL
tristate "Atmel SPI Controller"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
help
  This selects a driver for the Atmel SPI Controller, present on
@@ -233,7 +232,6 @@ config SPI_EFM32
 
 config SPI_EP93XX
tristate "Cirrus Logic EP93xx SPI controller"
-   depends on HAS_DMA
depends on ARCH_EP93XX || COMPILE_TEST
help
  This enables using the Cirrus EP93xx SPI controller in master
@@ -355,7 +353,6 @@ config SPI_FSL_SPI
 config SPI_FSL_DSPI
tristate "Freescale DSPI controller"
select REGMAP_MMIO
-   depends on HAS_DMA
depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || M5441x || 
COMPILE_TEST
help
  This enables support for the Freescale DSPI controller in master
@@ -431,7 +428,6 @@ config SPI_OMAP_UWIRE
 
 config SPI_OMAP24XX
tristate "McSPI driver for OMAP"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select SG_SPLIT
help
@@ -440,7 +436,6 @@ config SPI_OMAP24XX
 
 config SPI_TI_QSPI
tristate "DRA7xxx QSPI controller support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
help
  QSPI master controller for DRA7xxx used for flash devices.
@@ -469,7 +464,6 @@ config SPI_PIC32
 config SPI_PIC32_SQI
tristate "Microchip PIC32 Quad SPI driver"
depends on MACH_PIC32 || COMPILE_TEST
-   depends on HAS_DMA
help
  SPI driver for PIC32 Quad SPI controller.
 
@@ -572,7 +566,7 @@ config SPI_SC18IS602
 
 config SPI_SH_MSIOF
tristate "SuperH MSIOF SPI controller"
-   depends on HAVE_CLK && HAS_DMA
+   depends on HAVE_CLK
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  SPI driver for SuperH and SH Mobile MSIOF blocks.
@@ -650,7 +644,7 @@ config SPI_MXS
 config SPI_TEGRA114
tristate "NVIDIA Tegra114 SPI Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for NVIDIA Tegra114 SPI Controller interface. This 
controller
  is different than the older SoCs SPI controller and also register 
interface
@@ -668,7 +662,7 @@ config SPI_TEGRA20_SFLASH
 config SPI_TEGRA20_SLINK
tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
 
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 17/20] serial: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Greg Kroah-Hartman 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/tty/serial/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 0f058df0b0701fe2..25b8c0a8a50397d6 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -115,7 +115,6 @@ config SERIAL_SB1250_DUART_CONSOLE
 
 config SERIAL_ATMEL
bool "AT91 on-chip serial port support"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -500,7 +499,6 @@ config SERIAL_SA1100_CONSOLE
 
 config SERIAL_IMX
tristate "IMX serial port support"
-   depends on HAS_DMA
depends on ARCH_MXC || COMPILE_TEST
select SERIAL_CORE
select RATIONAL
@@ -1262,7 +1260,6 @@ config SERIAL_PCH_UART_CONSOLE
 
 config SERIAL_MXS_AUART
tristate "MXS AUART support"
-   depends on HAS_DMA
depends on ARCH_MXS || MACH_ASM9260 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -1473,7 +1470,6 @@ config SERIAL_SPRD_CONSOLE
 config SERIAL_STM32
tristate "STMicroelectronics STM32 serial port support"
select SERIAL_CORE
-   depends on HAS_DMA
depends on ARCH_STM32 || COMPILE_TEST
help
  This driver is for the on-chip Serial Controller on
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

[Alex Williamson]

On Mon, 16 Apr 2018 14:48:53 -0700
Jacob Pan  wrote:

> Add Intel VT-d ops to the generic iommu_bind_pasid_table API
> functions.
> 
> The primary use case is for direct assignment of SVM capable
> device. Originated from emulated IOMMU in the guest, the request goes
> through many layers (e.g. VFIO). Upon calling host IOMMU driver, caller
> passes guest PASID table pointer (GPA) and size.
> 
> Device context table entry is modified by Intel IOMMU specific
> bind_pasid_table function. This will turn on nesting mode and matching
> translation type.
> 
> The unbind operation restores default context mapping.
> 
> Signed-off-by: Jacob Pan 
> Signed-off-by: Liu, Yi L 
> Signed-off-by: Ashok Raj 
> ---
>  drivers/iommu/intel-iommu.c   | 119 
> ++
>  include/linux/dma_remapping.h |   1 +
>  2 files changed, 120 insertions(+)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index a0f81a4..d8058be 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -2409,6 +2409,7 @@ static struct dmar_domain 
> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
>   info->ats_supported = info->pasid_supported = info->pri_supported = 0;
>   info->ats_enabled = info->pasid_enabled = info->pri_enabled = 0;
>   info->ats_qdep = 0;
> + info->pasid_table_bound = 0;
>   info->dev = dev;
>   info->domain = domain;
>   info->iommu = iommu;
> @@ -5132,6 +5133,7 @@ static void intel_iommu_put_resv_regions(struct device 
> *dev,
>  
>  #ifdef CONFIG_INTEL_IOMMU_SVM
>  #define MAX_NR_PASID_BITS (20)
> +#define MIN_NR_PASID_BITS (5)
>  static inline unsigned long intel_iommu_get_pts(struct intel_iommu *iommu)
>  {
>   /*
> @@ -5258,6 +5260,119 @@ struct intel_iommu *intel_svm_device_to_iommu(struct 
> device *dev)
>  
>   return iommu;
>  }
> +
> +static int intel_iommu_bind_pasid_table(struct iommu_domain *domain,
> + struct device *dev, struct pasid_table_config *pasidt_binfo)
> +{

Never validates pasidt_binfo->{version,bytes}

> + struct intel_iommu *iommu;
> + struct context_entry *context;
> + struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> + struct device_domain_info *info;
> + struct pci_dev *pdev;
> + u8 bus, devfn, host_table_pasid_bits;
> + u16 did, sid;
> + int ret = 0;
> + unsigned long flags;
> + u64 ctx_lo;
> +
> + iommu = device_to_iommu(dev, , );
> + if (!iommu)
> + return -ENODEV;
> + /* VT-d spec section 9.4 says pasid table size is encoded as 2^(x+5) */
> + host_table_pasid_bits = intel_iommu_get_pts(iommu) + MIN_NR_PASID_BITS;
> + if (!pasidt_binfo || pasidt_binfo->pasid_bits > host_table_pasid_bits ||
> + pasidt_binfo->pasid_bits < MIN_NR_PASID_BITS) {
> + pr_err("Invalid gPASID bits %d, host range %d - %d\n",
> + pasidt_binfo->pasid_bits,
> + MIN_NR_PASID_BITS, host_table_pasid_bits);
> + return -ERANGE;
> + }
> + if (!ecap_nest(iommu->ecap)) {
> + dev_err(dev, "Cannot bind PASID table, no nested 
> translation\n");
> + ret = -EINVAL;
> + goto out;
> + }

Gratuitous use of pr_err, some of these look user reachable, for
instance can vfio know in advance the supported widths or can the user
trigger that pr_err at will?  Some of these errno values are also maybe
not as descriptive as they could be.  For instance if the iommu doesn't
support nesting, that's not a calling argument error, that's an
unsupported device error, right?

> + pdev = to_pci_dev(dev);
> + sid = PCI_DEVID(bus, devfn);
> + info = dev->archdata.iommu;
> +
> + if (!info) {
> + dev_err(dev, "Invalid device domain info\n");
> + ret = -EINVAL;
> + goto out;
> + }
> + if (info->pasid_table_bound) {
> + dev_err(dev, "Device PASID table already bound\n");
> + ret = -EBUSY;
> + goto out;
> + }
> + if (!info->pasid_enabled) {
> + ret = pci_enable_pasid(pdev, info->pasid_supported & ~1);
> + if (ret) {
> + dev_err(dev, "Failed to enable PASID\n");
> + goto out;
> + }
> + }
> + spin_lock_irqsave(>lock, flags);
> + context = iommu_context_addr(iommu, bus, devfn, 0);
> + if (!context_present(context)) {
> + dev_err(dev, "Context not present\n");
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + /* Anticipate guest to use SVM and owns the first level, so we turn
> +  * nested mode on
> +  */
> + ctx_lo = context[0].lo;
> + ctx_lo |= CONTEXT_NESTE | CONTEXT_PRS | CONTEXT_PASIDE;
> + ctx_lo &= ~CONTEXT_TT_MASK;
> + ctx_lo |= CONTEXT_TT_DEV_IOTLB << 

Re: [PATCH v4 09/22] iommu/vt-d: add svm/sva invalidate function

[Alex Williamson]

On Mon, 16 Apr 2018 14:48:58 -0700
Jacob Pan  wrote:

> When Shared Virtual Address (SVA) is enabled for a guest OS via
> vIOMMU, we need to provide invalidation support at IOMMU API and driver
> level. This patch adds Intel VT-d specific function to implement
> iommu passdown invalidate API for shared virtual address.
> 
> The use case is for supporting caching structure invalidation
> of assigned SVM capable devices. Emulated IOMMU exposes queue
> invalidation capability and passes down all descriptors from the guest
> to the physical IOMMU.
> 
> The assumption is that guest to host device ID mapping should be
> resolved prior to calling IOMMU driver. Based on the device handle,
> host IOMMU driver can replace certain fields before submit to the
> invalidation queue.
> 
> Signed-off-by: Liu, Yi L 
> Signed-off-by: Ashok Raj 
> Signed-off-by: Jacob Pan 
> ---
>  drivers/iommu/intel-iommu.c | 170 
> 
>  1 file changed, 170 insertions(+)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index cae4042..c765448 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -4973,6 +4973,175 @@ static void intel_iommu_detach_device(struct 
> iommu_domain *domain,
>   dmar_remove_one_dev_info(to_dmar_domain(domain), dev);
>  }
>  
> +/*
> + * 3D array for converting IOMMU generic type-granularity to VT-d granularity
> + * X indexed by enum iommu_inv_type
> + * Y indicates request without and with PASID
> + * Z indexed by enum iommu_inv_granularity
> + *
> + * For an example, if we want to find the VT-d granularity encoding for IOTLB
> + * type, DMA request with PASID, and page selective. The look up indices are:
> + * [1][1][8], where
> + * 1: IOMMU_INV_TYPE_TLB
> + * 1: with PASID
> + * 8: IOMMU_INV_GRANU_PAGE_PASID
> + *
> + * Granu_map array indicates validity of the table. 1: valid, 0: invalid
> + *
> + */
> +const static int 
> inv_type_granu_map[IOMMU_INV_NR_TYPE][2][IOMMU_INV_NR_GRANU] = {
> + /* extended dev IOTLBs, for dev-IOTLB, only global is valid,
> +for dev-EXIOTLB, two valid granu */
> + {
> + {1},
> + {0, 0, 0, 0, 1, 1, 0, 0, 0}
> + },
> + /* IOTLB and EIOTLB */
> + {
> + {1, 1, 0, 1, 0, 0, 0, 0, 0},
> + {0, 0, 0, 0, 1, 0, 1, 1, 1}
> + },
> + /* PASID cache */
> + {
> + {0},
> + {0, 0, 0, 0, 1, 1, 0, 0, 0}
> + },
> + /* context cache */
> + {
> + {1, 1, 1}
> + }
> +};
> +
> +const static u64 
> inv_type_granu_table[IOMMU_INV_NR_TYPE][2][IOMMU_INV_NR_GRANU] = {
> + /* extended dev IOTLBs, only global is valid */
> + {
> + {QI_DEV_IOTLB_GRAN_ALL},
> + {0, 0, 0, 0, QI_DEV_IOTLB_GRAN_ALL, 
> QI_DEV_IOTLB_GRAN_PASID_SEL, 0, 0, 0}
> + },
> + /* IOTLB and EIOTLB */
> + {
> + {DMA_TLB_GLOBAL_FLUSH, DMA_TLB_DSI_FLUSH, 0, DMA_TLB_PSI_FLUSH},
> + {0, 0, 0, 0, QI_GRAN_ALL_ALL, 0, QI_GRAN_NONG_ALL, 
> QI_GRAN_NONG_PASID, QI_GRAN_PSI_PASID}
> + },
> + /* PASID cache */
> + {
> + {0},
> + {0, 0, 0, 0, QI_PC_ALL_PASIDS, QI_PC_PASID_SEL}
> + },
> + /* context cache */
> + {
> + {DMA_CCMD_GLOBAL_INVL, DMA_CCMD_DOMAIN_INVL, 
> DMA_CCMD_DEVICE_INVL}
> + }
> +};
> +
> +static inline int to_vtd_granularity(int type, int granu, int with_pasid, 
> u64 *vtd_granu)
> +{
> + if (type >= IOMMU_INV_NR_TYPE || granu >= IOMMU_INV_NR_GRANU || 
> with_pasid > 1)
> + return -EINVAL;
> +
> + if (inv_type_granu_map[type][with_pasid][granu] == 0)
> + return -EINVAL;
> +
> + *vtd_granu = inv_type_granu_table[type][with_pasid][granu];
> +
> + return 0;
> +}
> +
> +static int intel_iommu_sva_invalidate(struct iommu_domain *domain,
> + struct device *dev, struct tlb_invalidate_info *inv_info)

inv_info->hdr.version is never checked, why do we have these if they're
not used?

> +{
> + struct intel_iommu *iommu;
> + struct dmar_domain *dmar_domain = to_dmar_domain(domain);
> + struct device_domain_info *info;
> + u16 did, sid;
> + u8 bus, devfn;
> + int ret = 0;
> + u64 granu;
> + unsigned long flags;
> +
> + if (!inv_info || !dmar_domain)
> + return -EINVAL;
> +
> + iommu = device_to_iommu(dev, , );
> + if (!iommu)
> + return -ENODEV;
> +
> + if (!dev || !dev_is_pci(dev))
> + return -ENODEV;
> +
> + did = dmar_domain->iommu_did[iommu->seq_id];
> + sid = PCI_DEVID(bus, devfn);
> + ret = to_vtd_granularity(inv_info->hdr.type, inv_info->granularity,
> + !!(inv_info->flags & 
> IOMMU_INVALIDATE_PASID_TAGGED), );
> + if (ret) {
> + pr_err("Invalid range type %d, granu %d\n", 

[PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Ulf Hansson 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mmc/host/Kconfig | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c9046f14b1..3978d0418958bf6b 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support"
depends on ARCH_MESON || COMPILE_TEST
depends on COMMON_CLK
-   depends on HAS_DMA
depends on OF
help
  This selects support for the SD/MMC Host Controller on
@@ -401,7 +400,6 @@ config MMC_OMAP
 
 config MMC_OMAP_HS
tristate "TI OMAP High Speed Multimedia Card Interface support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
help
  This selects the TI OMAP High Speed Multimedia card Interface.
@@ -511,7 +509,6 @@ config MMC_DAVINCI
 
 config MMC_GOLDFISH
tristate "goldfish qemu Multimedia Card Interface support"
-   depends on HAS_DMA
depends on GOLDFISH || COMPILE_TEST
help
  This selects the Goldfish Multimedia card Interface emulation
@@ -605,7 +602,7 @@ config MMC_SDHI
 
 config MMC_SDHI_SYS_DMAC
tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if (SUPERH || ARM)
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
 config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
depends on ARM64 || COMPILE_TEST
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if ARM64
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -669,7 +666,6 @@ config MMC_CAVIUM_THUNDERX
 
 config MMC_DW
tristate "Synopsys DesignWare Memory Card Interface"
-   depends on HAS_DMA
depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
help
  This selects support for the Synopsys DesignWare Mobile Storage IP
@@ -748,7 +744,6 @@ config MMC_DW_ZX
 
 config MMC_SH_MMCIF
tristate "SuperH Internal MMCIF support"
-   depends on HAS_DMA
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
help
  This selects the MMC Host Interface controller (MMCIF) found in 
various
@@ -868,7 +863,6 @@ config MMC_TOSHIBA_PCI
 config MMC_BCM2835
tristate "Broadcom BCM2835 SDHOST MMC Controller support"
depends on ARCH_BCM2835 || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the BCM2835 SDHOST MMC controller. If you have
  a BCM2835 platform with SD or MMC devices, say Y or M here.
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 19/20] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Greg Kroah-Hartman 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/staging/vc04_services/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/Kconfig 
b/drivers/staging/vc04_services/Kconfig
index f5aaf7d629f0fae9..98064ce2c2b47c7f 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -1,6 +1,5 @@
 menuconfig BCM_VIDEOCORE
tristate "Broadcom VideoCore support"
-   depends on HAS_DMA
depends on OF
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
default y
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 05/20] firewire: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/firewire/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 145974f9662b63e6..4199849e37585181 100644
--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -1,5 +1,4 @@
 menu "IEEE 1394 (FireWire) support"
-   depends on HAS_DMA
depends on PCI || COMPILE_TEST
# firewire-core does not depend on PCI but is
# not useful without PCI controller driver
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 12/20] media: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
HAS_DMA, as they are selected by several individual drivers.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,
  - Handle new VIDEO_RENESAS_CEU symbol,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on
HAS_DMA,
  - Split per subsystem.
---
 drivers/media/common/videobuf2/Kconfig   |  2 --
 drivers/media/pci/dt3155/Kconfig |  1 -
 drivers/media/pci/intel/ipu3/Kconfig |  1 -
 drivers/media/pci/solo6x10/Kconfig   |  1 -
 drivers/media/pci/sta2x11/Kconfig|  1 -
 drivers/media/pci/tw5864/Kconfig |  1 -
 drivers/media/pci/tw686x/Kconfig |  1 -
 drivers/media/platform/Kconfig   | 42 ++--
 drivers/media/platform/am437x/Kconfig|  2 +-
 drivers/media/platform/atmel/Kconfig |  4 +--
 drivers/media/platform/davinci/Kconfig   |  6 
 drivers/media/platform/marvell-ccic/Kconfig  |  3 +-
 drivers/media/platform/rcar-vin/Kconfig  |  2 +-
 drivers/media/platform/soc_camera/Kconfig|  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig |  2 +-
 drivers/media/v4l2-core/Kconfig  |  2 --
 drivers/staging/media/davinci_vpfe/Kconfig   |  1 -
 drivers/staging/media/omap4iss/Kconfig   |  1 -
 18 files changed, 21 insertions(+), 55 deletions(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 17c32ea58395d78f..4ed11b46676ac4d0 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS
 
 config VIDEOBUF2_DMA_CONTIG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
select DMA_SHARED_BUFFER
@@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC
 
 config VIDEOBUF2_DMA_SG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
 
diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig
index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644
--- a/drivers/media/pci/dt3155/Kconfig
+++ b/drivers/media/pci/dt3155/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_DT3155
tristate "DT3155 frame grabber"
depends on PCI && VIDEO_DEV && VIDEO_V4L2
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe277d2cdec..2533ec1cb1177715 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2
depends on VIDEO_V4L2_SUBDEV_API
depends on X86 || COMPILE_TEST
depends on MEDIA_CONTROLLER
-   depends on HAS_DMA
depends on ACPI
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/solo6x10/Kconfig 
b/drivers/media/pci/solo6x10/Kconfig
index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644
--- a/drivers/media/pci/solo6x10/Kconfig
+++ b/drivers/media/pci/solo6x10/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_SOLO6X10
tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)"
depends on PCI && VIDEO_DEV && SND && I2C
-   depends on HAS_DMA
select BITREVERSE
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index e03587b1af714199..7b856395ede9295c 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
depends on STA2X11
-   depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/Kconfig
index 87c8f327e2d49dfa..760fb11dfeaef47b 100644
--- a/drivers/media/pci/tw5864/Kconfig
+++ b/drivers/media/pci/tw5864/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_TW5864
tristate "Techwell TW5864 video/audio grabber and encoder"
depends on VIDEO_DEV && PCI && VIDEO_V4L2
-   

[PATCH v3 07/20] i2c: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/i2c/busses/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c4865b08d7fb9e3b..8d21b9825d71764d 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -707,7 +707,6 @@ config I2C_MPC
 config I2C_MT65XX
tristate "MediaTek I2C adapter"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the MediaTek(R) Integrated Inter Circuit bus driver
  for MT65xx and MT81xx.
@@ -885,7 +884,6 @@ config I2C_SH7760
 
 config I2C_SH_MOBILE
tristate "SuperH Mobile I2C Controller"
-   depends on HAS_DMA
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  If you say yes to this option, support will be included for the
@@ -1098,7 +1096,6 @@ config I2C_XLP9XX
 
 config I2C_RCAR
tristate "Renesas R-Car I2C Controller"
-   depends on HAS_DMA
depends on ARCH_RENESAS || COMPILE_TEST
select I2C_SLAVE
help
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 14/20] mtd: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA,
  - Split per subsystem.
---
 drivers/mtd/nand/raw/Kconfig | 8 ++--
 drivers/mtd/spi-nor/Kconfig  | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 19a2b283fbbe627e..6871ff0fd300bb81 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -46,7 +46,7 @@ config MTD_NAND_DENALI
 config MTD_NAND_DENALI_PCI
 tristate "Support Denali NAND controller on Intel Moorestown"
select MTD_NAND_DENALI
-   depends on HAS_DMA && PCI
+   depends on PCI
 help
   Enable the driver for NAND flash on Intel Moorestown, using the
   Denali NAND controller core.
@@ -152,7 +152,6 @@ config MTD_NAND_S3C2410_CLKSTOP
 config MTD_NAND_TANGO
tristate "NAND Flash support for Tango chips"
depends on ARCH_TANGO || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables the NAND Flash controller on Tango chips.
 
@@ -285,7 +284,7 @@ config MTD_NAND_MARVELL
tristate "NAND controller support on Marvell boards"
depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \
   COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables the NAND flash controller driver for Marvell boards,
  including:
@@ -447,7 +446,6 @@ config MTD_NAND_SH_FLCTL
tristate "Support for NAND on Renesas SuperH FLCTL"
depends on SUPERH || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
help
  Several Renesas SuperH CPU has FLCTL. This option enables support
  for NAND Flash using FLCTL.
@@ -515,7 +513,6 @@ config MTD_NAND_SUNXI
 config MTD_NAND_HISI504
tristate "Support for NAND controller on Hisilicon SoC Hip04"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on Hisilicon SoC Hip04.
 
@@ -529,7 +526,6 @@ config MTD_NAND_QCOM
 config MTD_NAND_MTK
tristate "Support for NAND controller on MTK SoCs"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on MTK SoCs.
  This controller is found on mt27xx, mt81xx, mt65xx SoCs.
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89da88e591215db1..c493b8230a38c059 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI
 config SPI_HISI_SFC
tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables support for hisilicon SPI-NOR flash controller.
 
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 06/20] fpga: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Alan Tull 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/fpga/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index f47ef848bcd056d5..fd539132542e30ee 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP
 config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on ARCH_ZYNQ || COMPILE_TEST
-   depends on HAS_DMA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 16/20] remoteproc: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Bjorn Andersson 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/remoteproc/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 027274008b086d6f..cd1c168fd18898dc 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -24,7 +24,6 @@ config IMX_REMOTEPROC
 
 config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
-   depends on HAS_DMA
depends on ARCH_OMAP4 || SOC_OMAP5
depends on OMAP_IOMMU
select MAILBOX
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 02/20] ata: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/ata/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2b16e7c8fff35764..39b181d6bd0d8cf2 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG
 
 config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
-   depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
  This option enables support for the Calxeda Highbank SoC's
@@ -408,7 +407,6 @@ config SATA_HIGHBANK
 
 config SATA_MV
tristate "Marvell SATA support"
-   depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 00/20] Allow compile-testing NO_DMA (drivers)

[Geert Uytterhoeven]

Hi all,

As of v4.17-rc1, patch series "[PATCH v2 0/5] Allow compile-testing
NO_DMA (core)" (https://lkml.org/lkml/2018/3/16/435) has been included
upstream, and drivers using the DMA API can be compile-tested on
platforms selecting NO_DMA.

This follow-up patch series removes dependencies on HAS_DMA for symbols
that already have platform dependencies implying HAS_DMA, which increases
compile-coverage.

Please apply to your tree if appropriate.

Changes compared to v2:
  - Add Acked-by,
  - Rebased to v4.17-rc1, dropping applied patch for scsi/hisi_sas,
  - Handle new VIDEO_RENESAS_CEU symbol,
  - Drop obsolete note about FSL_FMAN.

Changes compared to v1:
  - Add Reviewed-by, Acked-by,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
MTD_NAND_MARVELL on HAS_DMA,
  - Split in per-subsystem patches,
  - Split-off the core part in a separate series.

This series is against v4.17-rc1. It can also be found at
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v3

It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.

Thanks for applying!

Geert Uytterhoeven (20):
  ASoC: Remove depends on HAS_DMA in case of platform dependency
  ata: Remove depends on HAS_DMA in case of platform dependency
  crypto: Remove depends on HAS_DMA in case of platform dependency
  fbdev: Remove depends on HAS_DMA in case of platform dependency
  firewire: Remove depends on HAS_DMA in case of platform dependency
  fpga: Remove depends on HAS_DMA in case of platform dependency
  i2c: Remove depends on HAS_DMA in case of platform dependency
  iio: adc: Remove depends on HAS_DMA in case of platform dependency
  iommu: Remove depends on HAS_DMA in case of platform dependency
  lightnvm: Remove depends on HAS_DMA in case of platform dependency
  mailbox: Remove depends on HAS_DMA in case of platform dependency
  media: Remove depends on HAS_DMA in case of platform dependency
  mmc: Remove depends on HAS_DMA in case of platform dependency
  mtd: Remove depends on HAS_DMA in case of platform dependency
  net: Remove depends on HAS_DMA in case of platform dependency
  remoteproc: Remove depends on HAS_DMA in case of platform dependency
  serial: Remove depends on HAS_DMA in case of platform dependency
  spi: Remove depends on HAS_DMA in case of platform dependency
  staging: vc04_services: Remove depends on HAS_DMA in case of platform
dependency
  usb: Remove depends on HAS_DMA in case of platform dependency

 drivers/ata/Kconfig |  2 --
 drivers/crypto/Kconfig  | 14 +++--
 drivers/firewire/Kconfig|  1 -
 drivers/fpga/Kconfig|  1 -
 drivers/i2c/busses/Kconfig  |  3 --
 drivers/iio/adc/Kconfig |  2 --
 drivers/iommu/Kconfig   |  5 ++-
 drivers/lightnvm/Kconfig|  2 +-
 drivers/mailbox/Kconfig |  2 --
 drivers/media/common/videobuf2/Kconfig  |  2 --
 drivers/media/pci/dt3155/Kconfig|  1 -
 drivers/media/pci/intel/ipu3/Kconfig|  1 -
 drivers/media/pci/solo6x10/Kconfig  |  1 -
 drivers/media/pci/sta2x11/Kconfig   |  1 -
 drivers/media/pci/tw5864/Kconfig|  1 -
 drivers/media/pci/tw686x/Kconfig|  1 -
 drivers/media/platform/Kconfig  | 42 +
 drivers/media/platform/am437x/Kconfig   |  2 +-
 drivers/media/platform/atmel/Kconfig|  4 +--
 drivers/media/platform/davinci/Kconfig  |  6 
 drivers/media/platform/marvell-ccic/Kconfig |  3 +-
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/soc_camera/Kconfig   |  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig|  2 +-
 drivers/media/v4l2-core/Kconfig |  2 --
 drivers/mmc/host/Kconfig| 10 ++
 drivers/mtd/nand/raw/Kconfig|  8 ++---
 drivers/mtd/spi-nor/Kconfig |  2 +-
 drivers/net/ethernet/amd/Kconfig|  2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   |  1 -
 drivers/net/ethernet/apm/xgene/Kconfig  |  1 -
 drivers/net/ethernet/arc/Kconfig|  6 ++--
 drivers/net/ethernet/broadcom/Kconfig   |  2 --
 drivers/net/ethernet/calxeda/Kconfig|  2 +-
 drivers/net/ethernet/hisilicon/Kconfig  |  2 +-
 drivers/net/ethernet/marvell/Kconfig|  8 ++---
 drivers/net/ethernet/mellanox/mlxsw/Kconfig |  2 +-
 drivers/net/ethernet/renesas/Kconfig|  2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig |  1 -
 

[PATCH v3 11/20] mailbox: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,
  - Removed bogus notes,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mailbox/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index a2bb27446dce4e2b..725dce5ba62d5baf 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -162,7 +162,6 @@ config XGENE_SLIMPRO_MBOX
 config BCM_PDC_MBOX
tristate "Broadcom FlexSparx DMA Mailbox"
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
help
  Mailbox implementation for the Broadcom FlexSparx DMA ring manager,
  which provides access to various offload engines on Broadcom
@@ -172,7 +171,6 @@ config BCM_FLEXRM_MBOX
tristate "Broadcom FlexRM Mailbox"
depends on ARM64
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
select GENERIC_MSI_IRQ_DOMAIN
default m if ARCH_BCM_IPROC
help
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU

[Robin Murphy]

On 17/04/18 18:46, Hook, Gary wrote:

On 4/6/2018 9:17 AM, Gary R Hook wrote:

Provide base enablement for using debugfs to expose internal data of
an IOMMU driver. When called, create the /sys/kernel/debug/iommu
directory.  Emit a strong warning at boot time to indicate that this
feature is enabled.

This patch adds a top-level function that will create the (above)
directory, under which a driver may create a hw-specific directory for
its use. The function

iommu_debugfs_setup()

returns a pointer to the new dentry structure created for
/sys/kernel/debug/iommu, or NULL in the event of a failure. An IOMMU
driver should call this function first, and then create a directory
beneath it. A driver implementation might look something like:

static struct dentry *my_debugfs;

struct dentry *d_top;
if (!my_debugfs) {
    d_top = iommu_debugfs_setup();
    if (d_top)
    my_debugfs = debugfs_create_dir("vendor", d_top);
}

Since the IOMMU driver can not be removed from the running system, this
patch only provides an "on" function.

Signed-off-by: Gary R Hook 
---
  drivers/iommu/Kconfig |   11 
  drivers/iommu/Makefile    |    1 +
  drivers/iommu/iommu-debugfs.c |   58 
+

  include/linux/iommu.h |    4 +++
  4 files changed, 74 insertions(+)
  create mode 100644 drivers/iommu/iommu-debugfs.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f3a21343e636..c1e39dabfec2 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -60,6 +60,17 @@ config IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
  endmenu
+config IOMMU_DEBUG
+    bool "Enable IOMMU internals in DebugFS"
+    depends on DEBUG_FS
+    default n
+    help
+  Allows exposure of IOMMU device internals. This option enables
+  the use of debugfs by IOMMU drivers as required. Devices can,
+  at initialization time, cause the IOMMU code to create a top-level
+  debug/iommu directory, and then populate a subdirectory with
+  entries as required.


I should explicitly ask about this:

Joerg had suggested IOMMU_DEBUGFS, but here I've changed to IOMMU_DEBUG. 
I'm not seeing a lot of CONFIG options that use DEBUGFS for debugfs 
options, so I chose to follow an implied convention.


Question: should this indeed be IOMMU_DEBUGFS?
     ^


Personally I'd say yes, since there is at least some precedent for 
*_DEBUGFS already, and it does help make the intent that much clearer 
(*_DEBUG often just means lots of dmesg spam rather than an actual 
debugfs interface).


Robin.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU

[Hook, Gary]

On 4/17/2018 1:55 PM, Robin Murphy wrote:

On 17/04/18 18:36, Hook, Gary wrote:

On 4/13/2018 7:55 PM, Mehta, Sohil wrote:

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:

+struct dentry *iommu_debugfs_setup(void)
+{
+    if (!debugfs_initialized())


This check is probably not needed.


Ah, so it isn't. Thank you.




+    return NULL;
+
+    if (!iommu_debugfs_dir)
+    iommu_debugfs_dir = debugfs_create_dir("iommu",
NULL);
+
+    if (iommu_debugfs_dir)
+    pr_warn("WARNING: IOMMU DEBUGFS SUPPORT HAS BEEN
ENABLED IN THIS KERNEL\n");
+


As this gets called for each IOMMU, do you want to use pr_warn_once?


That works, yes.


Or I guess you could just roll the pr_warn() into the previous if() 
condition, i.e. only warn when the singleton debugfs_dir is actually 
created.


That makes more sense for a code path this isn't going to be hit more 
than a few times at most.




Robin.






+    return iommu_debugfs_dir;
+}
+EXPORT_SYMBOL_GPL(iommu_debugfs_setup);


-Sohil



___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

[Robin Murphy]

On 17/04/18 18:42, Hook, Gary wrote:

On 4/16/2018 8:52 PM, Mehta, Sohil wrote:

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:


diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 5eb1121d54b9..0ca250f626d9 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_IOMMU_IOVA) += iova.o
  obj-$(CONFIG_OF_IOMMU) += of_iommu.o
  obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o
  obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o
+obj-$(CONFIG_IOMMU_DEBUG) += amd_iommu_debugfs.o


Compiling amd_iommu_debugfs.c seems to depend only
on CONFIG_IOMMU_DEBUG. Can we prevent the code within
amd_iommu_debugfs.c from getting compiled when either CONFIG_AMD_IOMMU
or CONFIG_IOMMU_DEBUG is disabled?


That's a good point. My intention was that only one switch was required 
to incorporate any DebugFS support, but I see now that I didn't consider 
all of the cases.


It appears that a per-device switch is also necessary. Unless someone 
has a better idea.


Well, you could do a makefile-level dependency i.e.:

ifeq ($(CONFIG_IOMMU_DEBUG), y)
obj-$(CONFIG_AMD_IOMMU) += amd_iommu_debugfs.o
obj-$(CONFIG_BLAH_IOMMU) += blah_iommu_debugfs.o
...
endif

Or alternatively have an intermediate silent Kconfig option:

config AMD_IOMMU_DEBUG
def_bool y
depends on AMD_IOMMU && IOMMU_DEBUG

The makefile option is arguably ugly, but does at least scale better ;)

Robin.


  obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
  obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
  obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU

[Robin Murphy]

On 17/04/18 18:36, Hook, Gary wrote:

On 4/13/2018 7:55 PM, Mehta, Sohil wrote:

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:

+struct dentry *iommu_debugfs_setup(void)
+{
+    if (!debugfs_initialized())


This check is probably not needed.


Ah, so it isn't. Thank you.




+    return NULL;
+
+    if (!iommu_debugfs_dir)
+    iommu_debugfs_dir = debugfs_create_dir("iommu",
NULL);
+
+    if (iommu_debugfs_dir)
+    pr_warn("WARNING: IOMMU DEBUGFS SUPPORT HAS BEEN
ENABLED IN THIS KERNEL\n");
+


As this gets called for each IOMMU, do you want to use pr_warn_once?


That works, yes.


Or I guess you could just roll the pr_warn() into the previous if() 
condition, i.e. only warn when the singleton debugfs_dir is actually 
created.


Robin.






+    return iommu_debugfs_dir;
+}
+EXPORT_SYMBOL_GPL(iommu_debugfs_setup);


-Sohil



___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 20/20] usb: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Felipe Balbi  [drivers/usb/gadget/]
Acked-by: Greg Kroah-Hartman 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/usb/gadget/udc/Kconfig | 4 ++--
 drivers/usb/mtu3/Kconfig   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee9395..9c3b4f86965e80c7 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -179,7 +179,7 @@ config USB_R8A66597
 
 config USB_RENESAS_USBHS_UDC
tristate 'Renesas USBHS controller'
-   depends on USB_RENESAS_USBHS && HAS_DMA
+   depends on USB_RENESAS_USBHS
help
   Renesas USBHS is a discrete USB host and peripheral controller chip
   that supports both full and high speed USB 2.0 data transfers.
@@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC
 config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
-   depends on EXTCON && HAS_DMA
+   depends on EXTCON
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd61947beea51e..c0c0eb88e5eafc74 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
 
 config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
-   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on EXTCON && (USB || USB_GADGET)
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 09/20] iommu: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Joerg Roedel 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iommu/Kconfig | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index df171cb8582296b9..c76157e57f6ba4ba 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE
 config IOMMU_IO_PGTABLE_LPAE
bool "ARMv7/v8 Long Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && 
!GENERIC_ATOMIC64))
+   depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
help
  Enable support for the ARM long descriptor pagetable format.
  This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page
@@ -42,7 +42,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
 config IOMMU_IO_PGTABLE_ARMV7S
bool "ARMv7/v8 Short Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST)
+   depends on ARM || ARM64 || COMPILE_TEST
help
  Enable support for the ARM Short-descriptor pagetable format.
  This supports 32-bit virtual and physical addresses mapped using
@@ -376,7 +376,6 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on HAS_DMA
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 01/20] ASoC: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various SND_SOC_LPASS_* symbols had to loose their dependencies
on HAS_DMA, as they are selected by SND_SOC_STORM and/or
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Mark Brown 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Split per subsystem.
---
 sound/soc/bcm/Kconfig  | 3 +--
 sound/soc/kirkwood/Kconfig | 1 -
 sound/soc/pxa/Kconfig  | 1 -
 sound/soc/qcom/Kconfig | 7 ++-
 4 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index edf367100ebd2f17..02f50b7a966ff262 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -11,9 +11,8 @@ config SND_BCM2835_SOC_I2S
 config SND_SOC_CYGNUS
tristate "SoC platform audio for Broadcom Cygnus chips"
depends on ARCH_BCM_CYGNUS || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y if you want to add support for ASoC audio on Broadcom
  Cygnus chips (bcm958300, bcm958305, bcm911360)
 
- If you don't know what to do here, say N.
\ No newline at end of file
+ If you don't know what to do here, say N.
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index bc3c7b5ac752e471..132bb83f8e99aff3 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,7 +1,6 @@
 config SND_KIRKWOOD_SOC
tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
depends on ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y or M if you want to add support for codecs attached to
  the Kirkwood I2S interface. You will also need to select the
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 484ab3c2ad672fc8..960744e46edc0549 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -1,7 +1,6 @@
 config SND_PXA2XX_SOC
tristate "SoC Audio for the Intel PXA2xx chip"
depends on ARCH_PXA || COMPILE_TEST
-   depends on HAS_DMA
select SND_PXA2XX_LIB
help
  Say Y or M if you want to add support for codecs attached to
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 8ec9a074b38bd702..3cc252e55468eaab 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -11,24 +11,21 @@ config SND_SOC_LPASS_CPU
 
 config SND_SOC_LPASS_PLATFORM
tristate
-   depends on HAS_DMA
select REGMAP_MMIO
 
 config SND_SOC_LPASS_IPQ806X
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_LPASS_APQ8016
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_IPQ806X
select SND_SOC_MAX98357A
help
@@ -37,7 +34,7 @@ config SND_SOC_STORM
 
 config SND_SOC_APQ8016_SBC
tristate "SoC Audio support for APQ8016 SBC platforms"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_APQ8016
help
   Support for Qualcomm Technologies LPASS audio block in
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 08/20] iio: adc: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Jonathan Cameron 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iio/adc/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 15606f237480dacb..88bbcd0e98632273 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -157,7 +157,6 @@ config AT91_SAMA5D2_ADC
tristate "Atmel AT91 SAMA5D2 ADC"
depends on ARCH_AT91 || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
select IIO_TRIGGERED_BUFFER
help
  Say yes here to build support for Atmel SAMA5D2 ADC which is
@@ -646,7 +645,6 @@ config SD_ADC_MODULATOR
 config STM32_ADC_CORE
tristate "STMicroelectronics STM32 adc core"
depends on ARCH_STM32 || COMPILE_TEST
-   depends on HAS_DMA
depends on OF
depends on REGULATOR
select IIO_BUFFER
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 10/20] lightnvm: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Reviewed-by: Matias Bjørling 
---
v3:
  - Add Reviewed-by,
  - Rebase to v4.17-rc1,
  - Removed bogus notes,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/lightnvm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index 10c08982185a572f..9c03f35d9df113c6 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig NVM
bool "Open-Channel SSD target support"
-   depends on BLOCK && HAS_DMA && PCI
+   depends on BLOCK && PCI
select BLK_DEV_NVME
help
  Say Y here to get to enable Open-channel SSDs.
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 03/20] crypto: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Herbert Xu 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/crypto/Kconfig | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index d1ea1a07cecbb36c..3dbc47528667b77c 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG
 config CRYPTO_DEV_S5P
tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_BLKCIPHER
help
@@ -466,7 +466,6 @@ endif # if CRYPTO_DEV_UX500
 
 config CRYPTO_DEV_ATMEL_AUTHENC
tristate "Support for Atmel IPSEC/SSL hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AUTHENC
select CRYPTO_DEV_ATMEL_AES
@@ -479,7 +478,6 @@ config CRYPTO_DEV_ATMEL_AUTHENC
 
 config CRYPTO_DEV_ATMEL_AES
tristate "Support for Atmel AES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -494,7 +492,6 @@ config CRYPTO_DEV_ATMEL_AES
 
 config CRYPTO_DEV_ATMEL_TDES
tristate "Support for Atmel DES/TDES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_DES
select CRYPTO_BLKCIPHER
@@ -508,7 +505,6 @@ config CRYPTO_DEV_ATMEL_TDES
 
 config CRYPTO_DEV_ATMEL_SHA
tristate "Support for Atmel SHA hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_HASH
help
@@ -574,7 +570,8 @@ config CRYPTO_DEV_CAVIUM_ZIP
 
 config CRYPTO_DEV_QCE
tristate "Qualcomm crypto engine accelerator"
-   depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_DES
select CRYPTO_ECB
@@ -598,7 +595,6 @@ source "drivers/crypto/vmx/Kconfig"
 config CRYPTO_DEV_IMGTEC_HASH
tristate "Imagination Technologies hardware hash accelerator"
depends on MIPS || COMPILE_TEST
-   depends on HAS_DMA
select CRYPTO_MD5
select CRYPTO_SHA1
select CRYPTO_SHA256
@@ -650,7 +646,6 @@ config CRYPTO_DEV_ROCKCHIP
 
 config CRYPTO_DEV_MEDIATEK
tristate "MediaTek's EIP97 Cryptographic Engine driver"
-   depends on HAS_DMA
depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -688,7 +683,7 @@ source "drivers/crypto/stm32/Kconfig"
 
 config CRYPTO_DEV_SAFEXCEL
tristate "Inside Secure's SafeXcel cryptographic engine driver"
-   depends on HAS_DMA && OF
+   depends on OF
depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT)
select CRYPTO_AES
select CRYPTO_BLKCIPHER
@@ -706,7 +701,6 @@ config CRYPTO_DEV_SAFEXCEL
 config CRYPTO_DEV_ARTPEC6
tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration."
depends on ARM && (ARCH_ARTPEC || COMPILE_TEST)
-   depends on HAS_DMA
depends on OF
select CRYPTO_AEAD
select CRYPTO_AES
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v3 15/20] net: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,
  - Drop obsolete note about FSL_FMAN,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/net/ethernet/amd/Kconfig| 2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   | 1 -
 drivers/net/ethernet/apm/xgene/Kconfig  | 1 -
 drivers/net/ethernet/arc/Kconfig| 6 --
 drivers/net/ethernet/broadcom/Kconfig   | 2 --
 drivers/net/ethernet/calxeda/Kconfig| 2 +-
 drivers/net/ethernet/hisilicon/Kconfig  | 2 +-
 drivers/net/ethernet/marvell/Kconfig| 8 +++-
 drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
 drivers/net/ethernet/renesas/Kconfig| 2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
 drivers/net/wireless/quantenna/qtnfmac/Kconfig  | 2 +-
 12 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index d5c15e8bb3de706b..f273af136fc7c995 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -173,7 +173,7 @@ config SUNLANCE
 
 config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
-   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && 
HAS_DMA
+   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM
depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig 
b/drivers/net/ethernet/apm/xgene-v2/Kconfig
index 1205861b631896a0..eedd3f3dd22e2201 100644
--- a/drivers/net/ethernet/apm/xgene-v2/Kconfig
+++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE_V2
tristate "APM X-Gene SoC Ethernet-v2 Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
help
  This is the Ethernet driver for the on-chip ethernet interface
diff --git a/drivers/net/ethernet/apm/xgene/Kconfig 
b/drivers/net/ethernet/apm/xgene/Kconfig
index afccb033177b3923..e4e33c900b577161 100644
--- a/drivers/net/ethernet/apm/xgene/Kconfig
+++ b/drivers/net/ethernet/apm/xgene/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE
tristate "APM X-Gene SoC Ethernet Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
select PHYLIB
select MDIO_XGENE
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index e743ddf46343302f..5d0ab8e74b680cc6 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -24,7 +24,8 @@ config ARC_EMAC_CORE
 config ARC_EMAC
tristate "ARC EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST)
+   depends on OF_IRQ && OF_NET
+   depends on ARC || COMPILE_TEST
---help---
  On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x
  non-standard on-chip ethernet device ARC EMAC 10/100 is used.
@@ -33,7 +34,8 @@ config ARC_EMAC
 config EMAC_ROCKCHIP
tristate "Rockchip EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP 
|| COMPILE_TEST)
+   depends on OF_IRQ && OF_NET && REGULATOR
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
---help---
  Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers.
  This selects Rockchip SoC glue layer support for the
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index af75156919edfead..4c3bfde6e8de00f2 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -157,7 +157,6 @@ config BGMAC
 config BGMAC_BCMA
tristate "Broadcom iProc GBit BCMA support"
depends on BCMA && BCMA_HOST_SOC
-   depends on HAS_DMA
depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST
select BGMAC
select PHYLIB
@@ -170,7 +169,6 @@ config BGMAC_BCMA
 
 config BGMAC_PLATFORM
tristate "Broadcom iProc GBit platform support"
-   depends on HAS_DMA
depends on ARCH_BCM_IPROC || COMPILE_TEST
depends on OF
select BGMAC
diff --git a/drivers/net/ethernet/calxeda/Kconfig 
b/drivers/net/ethernet/calxeda/Kconfig
index 07d2201530d26c85..9fdd496b90ff47cb 100644

[PATCH v3 04/20] fbdev: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Bartlomiej Zolnierkiewicz 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/video/fbdev/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index d94254263ea5caa7..4f9853ec1721950f 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2075,7 +2075,8 @@ config FB_XILINX
 
 config FB_GOLDFISH
tristate "Goldfish Framebuffer"
-   depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST)
+   depends on FB
+   depends on GOLDFISH || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.7.4

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

[Geert Uytterhoeven]

Hi Rob,

On Thu, Apr 5, 2018 at 2:32 AM, Rob Herring  wrote:
> On Fri, Mar 16, 2018 at 8:51 AM, Geert Uytterhoeven
>  wrote:
>> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
>> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>>
>> The intention of this is twofold:
>>   1. To catch users of the DMA API on systems that do no support the DMA
>>  mapping API,
>>   2. To avoid building drivers that cannot work on such systems anyway.
>>
>> However, the disadvantage is that we have to keep on adding dependencies
>> on HAS_DMA all over the place.
>>
>> Thanks to the COMPILE_TEST symbol, lots of drivers now depend on one or
>> more platform dependencies (that imply HAS_DMA) || COMPILE_TEST, thus
>> already covering intention #2.  Having to add an explicit dependency on
>> HAS_DMA here is cumbersome, and hinders compile-testing.
>
> The same can be said for CONFIG_IOMEM and CONFIG_OF. Any plans to
> remove those too? CONFIG_IOMEM is mostly just a !CONFIG_UM option.

Perhaps, if time permits...

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU

[Hook, Gary]

On 4/6/2018 9:17 AM, Gary R Hook wrote:

Provide base enablement for using debugfs to expose internal data of
an IOMMU driver. When called, create the /sys/kernel/debug/iommu
directory.  Emit a strong warning at boot time to indicate that this
feature is enabled.

This patch adds a top-level function that will create the (above)
directory, under which a driver may create a hw-specific directory for
its use. The function

iommu_debugfs_setup()

returns a pointer to the new dentry structure created for
/sys/kernel/debug/iommu, or NULL in the event of a failure. An IOMMU
driver should call this function first, and then create a directory
beneath it. A driver implementation might look something like:

static struct dentry *my_debugfs;

struct dentry *d_top;
if (!my_debugfs) {
d_top = iommu_debugfs_setup();
if (d_top)
my_debugfs = debugfs_create_dir("vendor", d_top);
}

Since the IOMMU driver can not be removed from the running system, this
patch only provides an "on" function.

Signed-off-by: Gary R Hook 
---
  drivers/iommu/Kconfig |   11 
  drivers/iommu/Makefile|1 +
  drivers/iommu/iommu-debugfs.c |   58 +
  include/linux/iommu.h |4 +++
  4 files changed, 74 insertions(+)
  create mode 100644 drivers/iommu/iommu-debugfs.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f3a21343e636..c1e39dabfec2 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -60,6 +60,17 @@ config IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
  
  endmenu
  
+config IOMMU_DEBUG

+   bool "Enable IOMMU internals in DebugFS"
+   depends on DEBUG_FS
+   default n
+   help
+ Allows exposure of IOMMU device internals. This option enables
+ the use of debugfs by IOMMU drivers as required. Devices can,
+ at initialization time, cause the IOMMU code to create a top-level
+ debug/iommu directory, and then populate a subdirectory with
+ entries as required.


I should explicitly ask about this:

Joerg had suggested IOMMU_DEBUGFS, but here I've changed to IOMMU_DEBUG. 
I'm not seeing a lot of CONFIG options that use DEBUGFS for debugfs 
options, so I chose to follow an implied convention.


Question: should this indeed be IOMMU_DEBUGFS?
^

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

[Hook, Gary]

On 4/16/2018 8:52 PM, Mehta, Sohil wrote:

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:


diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 5eb1121d54b9..0ca250f626d9 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_IOMMU_IOVA) += iova.o
  obj-$(CONFIG_OF_IOMMU) += of_iommu.o
  obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o
  obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o
+obj-$(CONFIG_IOMMU_DEBUG) += amd_iommu_debugfs.o


Compiling amd_iommu_debugfs.c seems to depend only
on CONFIG_IOMMU_DEBUG. Can we prevent the code within
amd_iommu_debugfs.c from getting compiled when either CONFIG_AMD_IOMMU
or CONFIG_IOMMU_DEBUG is disabled?


That's a good point. My intention was that only one switch was required 
to incorporate any DebugFS support, but I see now that I didn't consider 
all of the cases.


It appears that a per-device switch is also necessary. Unless someone 
has a better idea.



  obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
  obj-$(CONFIG_ARM_SMMU) += arm-smmu.o
  obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

[Hook, Gary]

On 4/13/2018 8:08 PM, Mehta, Sohil wrote:

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
  
+

+void amd_iommu_debugfs_setup(struct amd_iommu *iommu)
+{
+   char name[MAX_NAME_LEN + 1];
+   struct dentry *d_top;
+
+   if (!debugfs_initialized())


Probably not needed.


Right.




+   return;
+
+   mutex_lock(_iommu_debugfs_lock);
+   if (!amd_iommu_debugfs) {
+   d_top = iommu_debugfs_setup();
+   if (d_top)
+   amd_iommu_debugfs =
debugfs_create_dir("amd", d_top);
+   }
+   mutex_unlock(_iommu_debugfs_lock);



You can do the above only once if you iterate over the IOMMUs here
  instead of doing it in amd_iommu_init.


I'm not sure it matters, given the finite number of IOMMUs in a system, 
and the fact that this work is done exactly once. However, removal of a 
lock is fine thing, so I'll move this around.





+   if (amd_iommu_debugfs) {
+   snprintf(name, MAX_NAME_LEN, "iommu%02d", iommu-

index);

+   iommu->debugfs = debugfs_create_dir(name,
+   amd_iommu_debugf
s);
+   if (!iommu->debugfs) {
+   debugfs_remove_recursive(amd_iommu_debugfs);
+   amd_iommu_debugfs = NULL;
+   }
+   }
+}


-Sohil



___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU

[Hook, Gary]

On 4/13/2018 7:55 PM, Mehta, Sohil wrote:

On Fri, 2018-04-06 at 08:17 -0500, Gary R Hook wrote:
  
  
+struct dentry *iommu_debugfs_setup(void)

+{
+   if (!debugfs_initialized())


This check is probably not needed.


Ah, so it isn't. Thank you.




+   return NULL;
+
+   if (!iommu_debugfs_dir)
+   iommu_debugfs_dir = debugfs_create_dir("iommu",
NULL);
+
+   if (iommu_debugfs_dir)
+   pr_warn("WARNING: IOMMU DEBUGFS SUPPORT HAS BEEN
ENABLED IN THIS KERNEL\n");
+


As this gets called for each IOMMU, do you want to use pr_warn_once?


That works, yes.




+   return iommu_debugfs_dir;
+}
+EXPORT_SYMBOL_GPL(iommu_debugfs_setup);


-Sohil



___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Robin Murphy]

On 17/04/18 11:21, Nipun Gupta wrote:

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

Signed-off-by: Nipun Gupta 
---
  drivers/iommu/of_iommu.c | 106 +--


Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess 
you don't want fsl-mc to have to depend on PCI, but this looks like a 
step in the wrong direction.


I'm not entirely sure where of_map_rid() fits best, but from a quick 
look around the least-worst option might be drivers/of/of_address.c, 
unless Rob and Frank have a better idea of where generic DT-based ID 
translation routines could live?



  drivers/of/irq.c |   6 +--
  drivers/pci/of.c | 101 
  include/linux/of_iommu.h |  11 +
  include/linux/of_pci.h   |  10 -
  5 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..4e7712f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
return ops->of_xlate(dev, iommu_spec);
  }
  
+/**

+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+   of_node_put(phandle_node);
+   else
+   *target = phandle_node;
+
+   if (*target != phandle_node)
+   continue;
+   }
+
+   if (id_out)
+   *id_out = masked_rid - rid_base + out_base;
+
+   pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, 
length: %08x, rid: %08x -> %08x\n",
+   np, map_name, map_mask, rid_base, out_base,
+   rid_len, rid, masked_rid - rid_base + out_base);

Re: [PATCH v2] iommu/rockchip: make clock handling optional

[Enric Balletbo Serra]

2018-04-17 14:09 GMT+02:00 Heiko Stuebner :
> iommu clocks are optional, so the driver should not fail if they are not
> present. Instead just set the number of clocks to 0, which the clk-blk APIs
> can handle just fine.
>
> Fixes: f2e3a5f557ad ("iommu/rockchip: Control clocks needed to access the 
> IOMMU")
> Signed-off-by: Heiko Stuebner 
> Reviewed-by: Robin Murphy 
> ---
> changes in v2:
> - keep it required in the binding for future variants
>   but optional in the code for backwards compatiblity
> - follow Robin Murphy's beautification suggestion
>
> As the original changes breaks a lot of display support in 4.17-rc1,
> this should abviously go in as fix into 4.17.
>
>  drivers/iommu/rockchip-iommu.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 5fc8656c60f9..422d22990289 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -1175,8 +1175,15 @@ static int rk_iommu_probe(struct platform_device *pdev)
> for (i = 0; i < iommu->num_clocks; ++i)
> iommu->clocks[i].id = rk_iommu_clocks[i];
>
> +   /*
> +* iommu clocks should be present for all new devices and devicetrees
> +* but there are older devicetrees without clocks out in the wild.
> +* So clocks as optional for the time being.
> +*/
> err = devm_clk_bulk_get(iommu->dev, iommu->num_clocks, iommu->clocks);
> -   if (err)
> +   if (err == -ENOENT)
> +   iommu->num_clocks = 0;
> +   else if (err)
> return err;
>
> err = clk_bulk_prepare(iommu->num_clocks, iommu->clocks);
> --
> 2.16.2
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Thanks to this patch my display is back :)

Tested-by: Enric Balletbo i Serra 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 01/12] iommu-common: move to arch/sparc

[Michael Ellerman]

Anshuman Khandual  writes:
> On 04/16/2018 07:28 PM, David Miller wrote:
>> From: Anshuman Khandual 
>> Date: Mon, 16 Apr 2018 14:26:07 +0530
>> 
>>> On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
 This code is only used by sparc, and all new iommu drivers should use the
 drivers/iommu/ framework.  Also remove the unused exports.

 Signed-off-by: Christoph Hellwig 
>>>
>>> Right, these functions are used only from SPARC architecture. Simple
>>> git grep confirms it as well. Hence it makes sense to move them into
>>> arch code instead.
>> 
>> Well, we put these into a common location and used type friendly for
>> powerpc because we hoped powerpc would convert over to using this
>> common piece of code as well.
>> 
>> But nobody did the powerpc work.
 
Sorry.

>> If you look at the powerpc iommu support, it's the same code basically
>> for entry allocation.
>
> I understand. But there are some differences in iommu_table structure,
> how both regular and large IOMMU pools are being initialized etc. So
> if the movement of code into SPARC help cleaning up these generic config
> options in general, I guess we should do that. But I will leave it upto
> others who have more experience in this area.
>
> +mpe

This is the first I've heard of it, I guess it's probably somewhere on
Ben's append-only TODO list.

Some of the code does look very similar, but not 100%. So someone would
need to do some work to reconcile the two and test the result. TBH I
doubt we're going to get around to it any time soon. Unless we have a
volunteer?

cheers
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v2] iommu/rockchip: make clock handling optional

[Heiko Stuebner]

iommu clocks are optional, so the driver should not fail if they are not
present. Instead just set the number of clocks to 0, which the clk-blk APIs
can handle just fine.

Fixes: f2e3a5f557ad ("iommu/rockchip: Control clocks needed to access the 
IOMMU")
Signed-off-by: Heiko Stuebner 
Reviewed-by: Robin Murphy 
---
changes in v2:
- keep it required in the binding for future variants
  but optional in the code for backwards compatiblity
- follow Robin Murphy's beautification suggestion

As the original changes breaks a lot of display support in 4.17-rc1,
this should abviously go in as fix into 4.17.

 drivers/iommu/rockchip-iommu.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 5fc8656c60f9..422d22990289 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1175,8 +1175,15 @@ static int rk_iommu_probe(struct platform_device *pdev)
for (i = 0; i < iommu->num_clocks; ++i)
iommu->clocks[i].id = rk_iommu_clocks[i];
 
+   /*
+* iommu clocks should be present for all new devices and devicetrees
+* but there are older devicetrees without clocks out in the wild.
+* So clocks as optional for the time being.
+*/
err = devm_clk_bulk_get(iommu->dev, iommu->num_clocks, iommu->clocks);
-   if (err)
+   if (err == -ENOENT)
+   iommu->num_clocks = 0;
+   else if (err)
return err;
 
err = clk_bulk_prepare(iommu->num_clocks, iommu->clocks);
-- 
2.16.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/2] dt-bindings: iommu/rockchip: Make clock properties optional

[Heiko Stuebner]

Am Freitag, 13. April 2018, 23:02:26 CEST schrieb Rob Herring:
> On Tue, Apr 10, 2018 at 01:26:41PM +0200, Heiko Stuebner wrote:
> > Hi Robin,
> > 
> > Am Dienstag, 10. April 2018, 13:18:48 CEST schrieb Robin Murphy:
> > > On 10/04/18 10:26, Heiko Stuebner wrote:
> > > > Rockchip IOMMUs are used without explicit clock handling for 4 years
> > > > now, so we should keep compatibility with old devicetrees if possible.
> > > > Therefore make iommu clocks optional.
> > > 
> > > Do we need to touch the binding itself? Obviously the driver has to 
> > > treat clocks as optional in existing DTs (and I feel a bit dumb now for 
> > > managing to overlook that in review), but the binding effectively only 
> > > covers future DTs, and I'd assume we want to encourage the clocks to be 
> > > correctly specified there.
> 
> I'd prefer the DT docs reflect what is correct for new/current dts 
> files. That's the only way the docs can validate the dts files.
> 
> > I guess that depends on your definition of the timespan for backwards
> > compatibility. I'm always starting out at indefinite till convinced
> > otherwise ;-). Hence the clocks would need to stay optional for (nearly)
> > forever.
> > 
> > Also, having the binding claim them as required but the code handling
> > them as optional just calls for someone to remove the optional handling :-D
> 
> A comment in the code saying why missing clocks are allowed should 
> suffice.
> 
> > Not sure if there is a established way of saying
> > "we want this for all future devices, but allow it to be missing for old 
> > dts".
> 
> We don't really...

Ok, I'll drop the binding change and add a code comment then.


Heiko
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

Fsl-mc bus now support the iommu-map property. Comply to this binding for
fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration.

Signed-off-by: Nipun Gupta 
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1b1c5eb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta 
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
and make corresponding changes for dma configuration of devices on
fsl-mc bus

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  |  39 +++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c|  16 ++-
 drivers/iommu/arm-smmu.c   |   7 ++
 drivers/iommu/iommu.c  |  21 
 drivers/iommu/of_iommu.c   | 126 -
 drivers/of/irq.c   |   6 +-
 drivers/pci/of.c   | 101 -
 include/linux/fsl/mc.h |   8 ++
 include/linux/iommu.h  |   2 +
 include/linux/of_iommu.h   |  11 ++
 include/linux/of_pci.h |  10 --
 12 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 4e7712f..af4fc3b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/of_iommu.c | 106 +--
 drivers/of/irq.c |   6 +--
 drivers/pci/of.c | 101 
 include/linux/of_iommu.h |  11 +
 include/linux/of_pci.h   |  10 -
 5 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..4e7712f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
return ops->of_xlate(dev, iommu_spec);
 }
 
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+   of_node_put(phandle_node);
+   else
+   *target = phandle_node;
+
+   if (*target != phandle_node)
+   continue;
+   }
+
+   if (id_out)
+   *id_out = masked_rid - rid_base + out_base;
+
+   pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: 
%08x, length: %08x, rid: %08x -> %08x\n",
+   np, map_name, map_mask, rid_base, out_base,
+   rid_len, rid, masked_rid - rid_base + out_base);
+   return 0;
+   }
+
+   pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
+   np, map_name, rid, target && *target ? *target : NULL);
+   return -EFAULT;
+}
+
 struct of_pci_iommu_alias_info {
struct device *dev;
struct device_node *np;
@@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 

[PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta 
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <2>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 11/12] swiotlb: move the SWIOTLB config symbol to lib/Kconfig

[Anshuman Khandual]

On 04/15/2018 08:29 PM, Christoph Hellwig wrote:
> This way we have one central definition of it, and user can select it as
> needed.  Note that we also add a second ARCH_HAS_SWIOTLB symbol to
> indicate the architecture supports swiotlb at all, so that we can still
> make the usage optional for a few architectures that want this feature
> to be user selectable.
> 
> Signed-off-by: Christoph Hellwig 


snip

> +
> +config SWIOTLB
> + bool "SWIOTLB support"
> + default ARCH_HAS_SWIOTLB
> + select DMA_DIRECT_OPS
> + select NEED_DMA_MAP_STATE
> + select NEED_SG_DMA_LENGTH
> + ---help---
> +   Support for IO bounce buffering for systems without an IOMMU.
> +   This allows us to DMA to the full physical address space on
> +   platforms where the size of a physical address is larger
> +   than the bus address.  If unsure, say Y.
> +
>  config CHECK_SIGNATURE
>   bool

Pulling DMA_DIRECT_OPS config option by default when SWIOTLB is enabled
makes sense. This option was also needed to be enabled separately even
to use swiotlb_dma_ops.

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu