From 6e67955087e72f1a5f64dd8014c27e1d9317fbb4 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Tue, 19 Apr 2022 13:34:25 +0200 Subject: amba: Use driver_set_override() instead of open-coding Use a helper to set driver_override to reduce the amount of duplicated code. Make the driver_override field const char, because it is not modified by the core and it matches other subsystems. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220419113435.246203-3-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman --- include/linux/amba/bus.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'include/linux/amba') diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h index 6562f543c3e0..93799a72ff82 100644 --- a/include/linux/amba/bus.h +++ b/include/linux/amba/bus.h @@ -70,7 +70,11 @@ struct amba_device { unsigned int cid; struct amba_cs_uci_id uci; unsigned int irq[AMBA_NR_IRQS]; - char *driver_override; + /* + * Driver name to force a match. Do not set directly, because core + * frees it. Use driver_set_override() to set or clear it. + */ + const char *driver_override; }; struct amba_driver { -- cgit v1.2.3 From 512881eacfa72c2136b27b9934b7b27504a9efc2 Mon Sep 17 00:00:00 2001 From: Lu Baolu Date: Mon, 18 Apr 2022 08:49:53 +0800 Subject: bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers with the device DMA managed by kernel drivers or user-space applications. Unfortunately, multiple devices may be placed in the same IOMMU group because they cannot be isolated from each other. The DMA on these devices must either be entirely under kernel control or userspace control, never a mixture. Otherwise the driver integrity is not guaranteed because they could access each other through the peer-to-peer accesses which by-pass the IOMMU protection. This checks and sets the default DMA mode during driver binding, and cleanups during driver unbinding. In the default mode, the device DMA is managed by the device driver which handles DMA operations through the kernel DMA APIs (see Documentation/core-api/dma-api.rst). For cases where the devices are assigned for userspace control through the userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/ vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this default setting in the assumption that the drivers know what they are doing with the device DMA. Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure is currently a problem. As things stand, the IOMMU driver ignored the initial iommu_probe_device() call when the device was added, since at that point it had no fwspec yet. In this situation, {of,acpi}_iommu_configure() are retriggering iommu_probe_device() after the IOMMU driver has seen the firmware data via .of_xlate to learn that it actually responsible for the given device. As the result, before that gets fixed, iommu_use_default_domain() goes at the end, and calls arch_teardown_dma_ops() if it fails. Cc: Greg Kroah-Hartman Cc: Bjorn Helgaas Cc: Stuart Yoder Cc: Laurentiu Tudor Signed-off-by: Lu Baolu Reviewed-by: Greg Kroah-Hartman Reviewed-by: Jason Gunthorpe Reviewed-by: Robin Murphy Tested-by: Eric Auger Link: https://lore.kernel.org/r/20220418005000.897664-5-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel --- include/linux/amba/bus.h | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'include/linux/amba') diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h index 6562f543c3e0..2ddce9bcd00e 100644 --- a/include/linux/amba/bus.h +++ b/include/linux/amba/bus.h @@ -79,6 +79,14 @@ struct amba_driver { void (*remove)(struct amba_device *); void (*shutdown)(struct amba_device *); const struct amba_id *id_table; + /* + * For most device drivers, no need to care about this flag as long as + * all DMAs are handled through the kernel DMA API. For some special + * ones, for example VFIO drivers, they know how to manage the DMA + * themselves and set this flag so that the IOMMU layer will allow them + * to setup and manage their own I/O address space. + */ + bool driver_managed_dma; }; /* -- cgit v1.2.3 From 3ae2722c93c916b47bfe47a4326e88cc4abb9bf4 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 27 Apr 2022 14:55:57 +0200 Subject: mmc: mmci: Remove custom ios handler The custom boardfile ios handler isn't used anywhere in the kernel. Delete it. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220427125557.1608825-1-linus.walleij@linaro.org Signed-off-by: Ulf Hansson --- include/linux/amba/mmci.h | 6 ------ 1 file changed, 6 deletions(-) (limited to 'include/linux/amba') diff --git a/include/linux/amba/mmci.h b/include/linux/amba/mmci.h index c92ebc39fc1f..6f96dc2209c0 100644 --- a/include/linux/amba/mmci.h +++ b/include/linux/amba/mmci.h @@ -13,17 +13,11 @@ * @ocr_mask: available voltages on the 4 pins from the block, this * is ignored if a regulator is used, see the MMC_VDD_* masks in * mmc/host.h - * @ios_handler: a callback function to act on specfic ios changes, - * used for example to control a levelshifter - * mask into a value to be binary (or set some other custom bits - * in MMCIPWR) or:ed and written into the MMCIPWR register of the - * block. May also control external power based on the power_mode. * @status: if no GPIO line was given to the block in this function will * be called to determine whether a card is present in the MMC slot or not */ struct mmci_platform_data { unsigned int ocr_mask; - int (*ios_handler)(struct device *, struct mmc_ios *); unsigned int (*status)(struct device *); }; -- cgit v1.2.3