* [PATCH 01/10] iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
@ 2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 0:47 ` [PATCH 02/10] iommmu/of: Do not return struct iommu_ops from of_iommu_configure() Jason Gunthorpe
` (8 subsequent siblings)
9 siblings, 0 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:47 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
This is not being used to pass ops, it is just a way to tell if an
iommu driver was probed. These days this can be detected directly via
device_iommu_mapped(). Call device_iommu_mapped() in the two places that
need to check it and remove the iommu parameter everywhere.
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Moritz Fischer <mdf@kernel.org>
Acked-by: Christoph Hellwig <hch@lst.de>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
arch/arc/mm/dma.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 2 +-
arch/arm/mm/dma-mapping.c | 10 +++++-----
arch/arm64/mm/dma-mapping.c | 4 ++--
arch/mips/mm/dma-noncoherent.c | 2 +-
arch/riscv/mm/dma-noncoherent.c | 2 +-
drivers/acpi/scan.c | 3 +--
drivers/hv/hv_common.c | 2 +-
drivers/of/device.c | 2 +-
include/linux/dma-map-ops.h | 4 ++--
10 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 2a7fbbb83b7056..197707bc765889 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -91,7 +91,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
* Plug in direct dma map ops.
*/
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
/*
* IOC hardware snoops all DMA traffic keeping the caches consistent
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index cfd9c933d2f09c..b94850b579952a 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -34,7 +34,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
}
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
if (IS_ENABLED(CONFIG_CPU_V7M)) {
/*
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 5409225b4abc06..6c359a3af8d9c7 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1713,7 +1713,7 @@ void arm_iommu_detach_device(struct device *dev)
EXPORT_SYMBOL_GPL(arm_iommu_detach_device);
static void arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
struct dma_iommu_mapping *mapping;
@@ -1748,7 +1748,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev)
#else
static void arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
}
@@ -1757,7 +1757,7 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) { }
#endif /* CONFIG_ARM_DMA_USE_IOMMU */
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
/*
* Due to legacy code that sets the ->dma_coherent flag from a bus
@@ -1776,8 +1776,8 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
if (dev->dma_ops)
return;
- if (iommu)
- arm_setup_iommu_dma_ops(dev, dma_base, size, iommu, coherent);
+ if (device_iommu_mapped(dev))
+ arm_setup_iommu_dma_ops(dev, dma_base, size, coherent);
xen_setup_dma_ops(dev);
dev->archdata.dma_ops_setup = true;
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3cb101e8cb29ba..61886e43e3a10f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -47,7 +47,7 @@ void arch_teardown_dma_ops(struct device *dev)
#endif
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
int cls = cache_line_size_of_cpu();
@@ -58,7 +58,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
ARCH_DMA_MINALIGN, cls);
dev->dma_coherent = coherent;
- if (iommu)
+ if (device_iommu_mapped(dev))
iommu_setup_dma_ops(dev, dma_base, dma_base + size - 1);
xen_setup_dma_ops(dev);
diff --git a/arch/mips/mm/dma-noncoherent.c b/arch/mips/mm/dma-noncoherent.c
index 3c4fc97b9f394b..0f3cec663a12cd 100644
--- a/arch/mips/mm/dma-noncoherent.c
+++ b/arch/mips/mm/dma-noncoherent.c
@@ -138,7 +138,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
#ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
dev->dma_coherent = coherent;
}
diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
index 4e4e469b8dd66c..843107f834b231 100644
--- a/arch/riscv/mm/dma-noncoherent.c
+++ b/arch/riscv/mm/dma-noncoherent.c
@@ -129,7 +129,7 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
}
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent)
+ bool coherent)
{
WARN_TAINT(!coherent && riscv_cbom_block_size > ARCH_DMA_MINALIGN,
TAINT_CPU_OUT_OF_SPEC,
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 02bb2cce423f47..444a0b3c72f2d8 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1641,8 +1641,7 @@ int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
if (PTR_ERR(iommu) == -EPROBE_DEFER)
return -EPROBE_DEFER;
- arch_setup_dma_ops(dev, 0, U64_MAX,
- iommu, attr == DEV_DMA_COHERENT);
+ arch_setup_dma_ops(dev, 0, U64_MAX, attr == DEV_DMA_COHERENT);
return 0;
}
diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
index 4372f5d146ab22..0285a74363b3d1 100644
--- a/drivers/hv/hv_common.c
+++ b/drivers/hv/hv_common.c
@@ -488,7 +488,7 @@ void hv_setup_dma_ops(struct device *dev, bool coherent)
* Hyper-V does not offer a vIOMMU in the guest
* VM, so pass 0/NULL for the IOMMU settings
*/
- arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
+ arch_setup_dma_ops(dev, 0, 0, coherent);
}
EXPORT_SYMBOL_GPL(hv_setup_dma_ops);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1ca42ad9dd159d..65c71be71a8d45 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -193,7 +193,7 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
dev_dbg(dev, "device is%sbehind an iommu\n",
iommu ? " " : " not ");
- arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
+ arch_setup_dma_ops(dev, dma_start, size, coherent);
if (!iommu)
of_dma_set_restricted_buffer(dev, np);
diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index a52e508d1869f6..e9cc317e9d7de6 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -427,10 +427,10 @@ bool arch_dma_unmap_sg_direct(struct device *dev, struct scatterlist *sg,
#ifdef CONFIG_ARCH_HAS_SETUP_DMA_OPS
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
- const struct iommu_ops *iommu, bool coherent);
+ bool coherent);
#else
static inline void arch_setup_dma_ops(struct device *dev, u64 dma_base,
- u64 size, const struct iommu_ops *iommu, bool coherent)
+ u64 size, bool coherent)
{
}
#endif /* CONFIG_ARCH_HAS_SETUP_DMA_OPS */
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 02/10] iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
2023-11-29 0:47 ` [PATCH 01/10] iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops() Jason Gunthorpe
@ 2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 3:09 ` Baolu Lu
2023-11-29 0:47 ` [PATCH 03/10] iommu/of: Use -ENODEV consistently in of_iommu_configure() Jason Gunthorpe
` (7 subsequent siblings)
9 siblings, 1 reply; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:47 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/of_iommu.c | 31 +++++++++++++++++++------------
drivers/of/device.c | 22 +++++++++++++++-------
include/linux/of_iommu.h | 13 ++++++-------
3 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5ecca53847d325..c6510d7e7b241b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -107,16 +107,22 @@ static int of_iommu_configure_device(struct device_node *master_np,
of_iommu_configure_dev(master_np, dev);
}
-const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np,
- const u32 *id)
+/*
+ * Returns:
+ * 0 on success, an iommu was configured
+ * -ENODEV if the device does not have any IOMMU
+ * -EPROBEDEFER if probing should be tried again
+ * -errno fatal errors
+ */
+int of_iommu_configure(struct device *dev, struct device_node *master_np,
+ const u32 *id)
{
const struct iommu_ops *ops = NULL;
struct iommu_fwspec *fwspec;
int err = NO_IOMMU;
if (!master_np)
- return NULL;
+ return -ENODEV;
/* Serialise to make dev->iommu stable under our potential fwspec */
mutex_lock(&iommu_probe_device_lock);
@@ -124,7 +130,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
if (fwspec) {
if (fwspec->ops) {
mutex_unlock(&iommu_probe_device_lock);
- return fwspec->ops;
+ return 0;
}
/* In the deferred case, start again from scratch */
iommu_fwspec_free(dev);
@@ -169,14 +175,15 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
err = iommu_probe_device(dev);
/* Ignore all other errors apart from EPROBE_DEFER */
- if (err == -EPROBE_DEFER) {
- ops = ERR_PTR(err);
- } else if (err < 0) {
- dev_dbg(dev, "Adding to IOMMU failed: %d\n", err);
- ops = NULL;
+ if (err < 0) {
+ if (err == -EPROBE_DEFER)
+ return err;
+ dev_dbg(dev, "Adding to IOMMU failed: %pe\n", ERR_PTR(err));
+ return err;
}
-
- return ops;
+ if (!ops)
+ return -ENODEV;
+ return 0;
}
static enum iommu_resv_type __maybe_unused
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 65c71be71a8d45..873d933e8e6d1d 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -93,12 +93,12 @@ of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
int of_dma_configure_id(struct device *dev, struct device_node *np,
bool force_dma, const u32 *id)
{
- const struct iommu_ops *iommu;
const struct bus_dma_region *map = NULL;
struct device_node *bus_np;
u64 dma_start = 0;
u64 mask, end, size = 0;
bool coherent;
+ int iommu_ret;
int ret;
if (np == dev->of_node)
@@ -181,21 +181,29 @@ int of_dma_configure_id(struct device *dev, struct device_node *np,
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");
- iommu = of_iommu_configure(dev, np, id);
- if (PTR_ERR(iommu) == -EPROBE_DEFER) {
+ iommu_ret = of_iommu_configure(dev, np, id);
+ if (iommu_ret == -EPROBE_DEFER) {
/* Don't touch range map if it wasn't set from a valid dma-ranges */
if (!ret)
dev->dma_range_map = NULL;
kfree(map);
return -EPROBE_DEFER;
- }
+ } else if (iommu_ret == -ENODEV) {
+ dev_dbg(dev, "device is not behind an iommu\n");
+ } else if (iommu_ret) {
+ dev_err(dev, "iommu configuration for device failed with %pe\n",
+ ERR_PTR(iommu_ret));
- dev_dbg(dev, "device is%sbehind an iommu\n",
- iommu ? " " : " not ");
+ /*
+ * Historically this routine doesn't fail driver probing
+ * due to errors in of_iommu_configure()
+ */
+ } else
+ dev_dbg(dev, "device is behind an iommu\n");
arch_setup_dma_ops(dev, dma_start, size, coherent);
- if (!iommu)
+ if (iommu_ret)
of_dma_set_restricted_buffer(dev, np);
return 0;
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 9a5e6b410dd2fb..e61cbbe12dac6f 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -8,20 +8,19 @@ struct iommu_ops;
#ifdef CONFIG_OF_IOMMU
-extern const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np,
- const u32 *id);
+extern int of_iommu_configure(struct device *dev, struct device_node *master_np,
+ const u32 *id);
extern void of_iommu_get_resv_regions(struct device *dev,
struct list_head *list);
#else
-static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
- struct device_node *master_np,
- const u32 *id)
+static inline int of_iommu_configure(struct device *dev,
+ struct device_node *master_np,
+ const u32 *id)
{
- return NULL;
+ return -ENODEV;
}
static inline void of_iommu_get_resv_regions(struct device *dev,
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 02/10] iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
2023-11-29 0:47 ` [PATCH 02/10] iommmu/of: Do not return struct iommu_ops from of_iommu_configure() Jason Gunthorpe
@ 2023-11-29 3:09 ` Baolu Lu
0 siblings, 0 replies; 30+ messages in thread
From: Baolu Lu @ 2023-11-29 3:09 UTC (permalink / raw)
To: Jason Gunthorpe, David Airlie, Alyssa Rosenzweig, Albert Ou,
asahi, Catalin Marinas, Danilo Krummrich, Daniel Vetter,
Dexuan Cui, devicetree, dmaengine, dri-devel, David Woodhouse,
Frank Rowand, Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter,
Joerg Roedel, Karol Herbst, Krzysztof Kozlowski,
K. Y. Srinivasan, Laxman Dewangan, Len Brown, linux-acpi,
linux-arm-kernel, linux-hyperv, linux-mips, linux-riscv,
linux-snps-arc, linux-tegra, Russell King, Lorenzo Pieralisi,
Lyude Paul, Marek Szyprowski, nouveau, Palmer Dabbelt,
Paul Walmsley, Rafael J. Wysocki, Rob Herring, Robin Murphy,
Sudeep Holla, Suravee Suthikulpanit, Sven Peter,
Thomas Bogendoerfer, Vineet Gupta, Vinod Koul, Wei Liu,
Will Deacon
Cc: baolu.lu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On 2023/11/29 8:47, Jason Gunthorpe wrote:
> Nothing needs this pointer. Return a normal error code with the usual
> IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
>
> Reviewed-by: Jerry Snitselaar<jsnitsel@redhat.com>
> Acked-by: Rob Herring<robh@kernel.org>
> Tested-by: Hector Martin<marcan@marcan.st>
> Signed-off-by: Jason Gunthorpe<jgg@nvidia.com>
> ---
> drivers/iommu/of_iommu.c | 31 +++++++++++++++++++------------
> drivers/of/device.c | 22 +++++++++++++++-------
> include/linux/of_iommu.h | 13 ++++++-------
> 3 files changed, 40 insertions(+), 26 deletions(-)
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Best regards,
baolu
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 03/10] iommu/of: Use -ENODEV consistently in of_iommu_configure()
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
2023-11-29 0:47 ` [PATCH 01/10] iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops() Jason Gunthorpe
2023-11-29 0:47 ` [PATCH 02/10] iommmu/of: Do not return struct iommu_ops from of_iommu_configure() Jason Gunthorpe
@ 2023-11-29 0:47 ` Jason Gunthorpe
2023-11-29 6:04 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep Jason Gunthorpe
` (6 subsequent siblings)
9 siblings, 1 reply; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:47 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
Instead of returning 1 and trying to handle positive error codes just
stick to the convention of returning -ENODEV. Remove references to ops
from of_iommu_configure(), a NULL ops will already generate an error code.
There is no reason to check dev->bus, if err=0 at this point then the
called configure functions thought there was an iommu and we should try to
probe it. Remove it.
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Tested-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/of_iommu.c | 49 ++++++++++++----------------------------
1 file changed, 15 insertions(+), 34 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index c6510d7e7b241b..164317bfb8a81f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -17,8 +17,6 @@
#include <linux/slab.h>
#include <linux/fsl/mc.h>
-#define NO_IOMMU 1
-
static int of_iommu_xlate(struct device *dev,
struct of_phandle_args *iommu_spec)
{
@@ -29,7 +27,7 @@ static int of_iommu_xlate(struct device *dev,
ops = iommu_ops_from_fwnode(fwnode);
if ((ops && !ops->of_xlate) ||
!of_device_is_available(iommu_spec->np))
- return NO_IOMMU;
+ return -ENODEV;
ret = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
if (ret)
@@ -61,7 +59,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np,
"iommu-map-mask", &iommu_spec.np,
iommu_spec.args);
if (err)
- return err == -ENODEV ? NO_IOMMU : err;
+ return err;
err = of_iommu_xlate(dev, &iommu_spec);
of_node_put(iommu_spec.np);
@@ -72,7 +70,7 @@ static int of_iommu_configure_dev(struct device_node *master_np,
struct device *dev)
{
struct of_phandle_args iommu_spec;
- int err = NO_IOMMU, idx = 0;
+ int err = -ENODEV, idx = 0;
while (!of_parse_phandle_with_args(master_np, "iommus",
"#iommu-cells",
@@ -117,9 +115,8 @@ static int of_iommu_configure_device(struct device_node *master_np,
int of_iommu_configure(struct device *dev, struct device_node *master_np,
const u32 *id)
{
- const struct iommu_ops *ops = NULL;
struct iommu_fwspec *fwspec;
- int err = NO_IOMMU;
+ int err;
if (!master_np)
return -ENODEV;
@@ -153,37 +150,21 @@ int of_iommu_configure(struct device *dev, struct device_node *master_np,
} else {
err = of_iommu_configure_device(master_np, dev, id);
}
-
- /*
- * Two success conditions can be represented by non-negative err here:
- * >0 : there is no IOMMU, or one was unavailable for non-fatal reasons
- * 0 : we found an IOMMU, and dev->fwspec is initialised appropriately
- * <0 : any actual error
- */
- if (!err) {
- /* The fwspec pointer changed, read it again */
- fwspec = dev_iommu_fwspec_get(dev);
- ops = fwspec->ops;
- }
mutex_unlock(&iommu_probe_device_lock);
- /*
- * If we have reason to believe the IOMMU driver missed the initial
- * probe for dev, replay it to get things in order.
- */
- if (!err && dev->bus)
- err = iommu_probe_device(dev);
-
- /* Ignore all other errors apart from EPROBE_DEFER */
- if (err < 0) {
- if (err == -EPROBE_DEFER)
- return err;
- dev_dbg(dev, "Adding to IOMMU failed: %pe\n", ERR_PTR(err));
+ if (err == -ENODEV || err == -EPROBE_DEFER)
return err;
- }
- if (!ops)
- return -ENODEV;
+ if (err)
+ goto err_log;
+
+ err = iommu_probe_device(dev);
+ if (err)
+ goto err_log;
return 0;
+
+err_log:
+ dev_dbg(dev, "Adding to IOMMU failed: %pe\n", ERR_PTR(err));
+ return err;
}
static enum iommu_resv_type __maybe_unused
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 03/10] iommu/of: Use -ENODEV consistently in of_iommu_configure()
2023-11-29 0:47 ` [PATCH 03/10] iommu/of: Use -ENODEV consistently in of_iommu_configure() Jason Gunthorpe
@ 2023-11-29 6:04 ` Moritz Fischer
0 siblings, 0 replies; 30+ messages in thread
From: Moritz Fischer @ 2023-11-29 6:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On Tue, Nov 28, 2023 at 08:47:59PM -0400, Jason Gunthorpe wrote:
> Instead of returning 1 and trying to handle positive error codes just
> stick to the convention of returning -ENODEV. Remove references to ops
> from of_iommu_configure(), a NULL ops will already generate an error code.
> There is no reason to check dev->bus, if err=0 at this point then the
> called configure functions thought there was an iommu and we should try to
> probe it. Remove it.
> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
> Tested-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/of_iommu.c | 49 ++++++++++++----------------------------
> 1 file changed, 15 insertions(+), 34 deletions(-)
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index c6510d7e7b241b..164317bfb8a81f 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -17,8 +17,6 @@
> #include <linux/slab.h>
> #include <linux/fsl/mc.h>
> -#define NO_IOMMU 1
> -
> static int of_iommu_xlate(struct device *dev,
> struct of_phandle_args *iommu_spec)
> {
> @@ -29,7 +27,7 @@ static int of_iommu_xlate(struct device *dev,
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> !of_device_is_available(iommu_spec->np))
> - return NO_IOMMU;
> + return -ENODEV;
> ret = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> if (ret)
> @@ -61,7 +59,7 @@ static int of_iommu_configure_dev_id(struct device_node
> *master_np,
> "iommu-map-mask", &iommu_spec.np,
> iommu_spec.args);
> if (err)
> - return err == -ENODEV ? NO_IOMMU : err;
> + return err;
> err = of_iommu_xlate(dev, &iommu_spec);
> of_node_put(iommu_spec.np);
> @@ -72,7 +70,7 @@ static int of_iommu_configure_dev(struct device_node
> *master_np,
> struct device *dev)
> {
> struct of_phandle_args iommu_spec;
> - int err = NO_IOMMU, idx = 0;
> + int err = -ENODEV, idx = 0;
> while (!of_parse_phandle_with_args(master_np, "iommus",
> "#iommu-cells",
> @@ -117,9 +115,8 @@ static int of_iommu_configure_device(struct
> device_node *master_np,
> int of_iommu_configure(struct device *dev, struct device_node *master_np,
> const u32 *id)
> {
> - const struct iommu_ops *ops = NULL;
> struct iommu_fwspec *fwspec;
> - int err = NO_IOMMU;
> + int err;
> if (!master_np)
> return -ENODEV;
> @@ -153,37 +150,21 @@ int of_iommu_configure(struct device *dev, struct
> device_node *master_np,
> } else {
> err = of_iommu_configure_device(master_np, dev, id);
> }
> -
> - /*
> - * Two success conditions can be represented by non-negative err here:
> - * >0 : there is no IOMMU, or one was unavailable for non-fatal reasons
> - * 0 : we found an IOMMU, and dev->fwspec is initialised appropriately
> - * <0 : any actual error
> - */
> - if (!err) {
> - /* The fwspec pointer changed, read it again */
> - fwspec = dev_iommu_fwspec_get(dev);
> - ops = fwspec->ops;
> - }
> mutex_unlock(&iommu_probe_device_lock);
> - /*
> - * If we have reason to believe the IOMMU driver missed the initial
> - * probe for dev, replay it to get things in order.
> - */
> - if (!err && dev->bus)
> - err = iommu_probe_device(dev);
> -
> - /* Ignore all other errors apart from EPROBE_DEFER */
> - if (err < 0) {
> - if (err == -EPROBE_DEFER)
> - return err;
> - dev_dbg(dev, "Adding to IOMMU failed: %pe\n", ERR_PTR(err));
> + if (err == -ENODEV || err == -EPROBE_DEFER)
> return err;
> - }
> - if (!ops)
> - return -ENODEV;
> + if (err)
> + goto err_log;
> +
> + err = iommu_probe_device(dev);
> + if (err)
> + goto err_log;
> return 0;
> +
> +err_log:
> + dev_dbg(dev, "Adding to IOMMU failed: %pe\n", ERR_PTR(err));
> + return err;
> }
> static enum iommu_resv_type __maybe_unused
> --
> 2.42.0
Reviewed-by: Moritz Fischer <moritzf@google.com>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
` (2 preceding siblings ...)
2023-11-29 0:47 ` [PATCH 03/10] iommu/of: Use -ENODEV consistently in of_iommu_configure() Jason Gunthorpe
@ 2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 3:11 ` Baolu Lu
2023-11-29 6:06 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 05/10] iommu: Mark dev_iommu_priv_set() with a lockdep Jason Gunthorpe
` (5 subsequent siblings)
9 siblings, 2 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:48 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
Allocation of dev->iommu must be done under the
iommu_probe_device_lock. Mark this with lockdep to discourage future
mistakes.
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Tested-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 0d25468d53a68a..4323b6276e977f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -334,6 +334,8 @@ static struct dev_iommu *dev_iommu_get(struct device *dev)
{
struct dev_iommu *param = dev->iommu;
+ lockdep_assert_held(&iommu_probe_device_lock);
+
if (param)
return param;
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep
2023-11-29 0:48 ` [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep Jason Gunthorpe
@ 2023-11-29 3:11 ` Baolu Lu
2023-11-29 6:06 ` Moritz Fischer
1 sibling, 0 replies; 30+ messages in thread
From: Baolu Lu @ 2023-11-29 3:11 UTC (permalink / raw)
To: Jason Gunthorpe, David Airlie, Alyssa Rosenzweig, Albert Ou,
asahi, Catalin Marinas, Danilo Krummrich, Daniel Vetter,
Dexuan Cui, devicetree, dmaengine, dri-devel, David Woodhouse,
Frank Rowand, Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter,
Joerg Roedel, Karol Herbst, Krzysztof Kozlowski,
K. Y. Srinivasan, Laxman Dewangan, Len Brown, linux-acpi,
linux-arm-kernel, linux-hyperv, linux-mips, linux-riscv,
linux-snps-arc, linux-tegra, Russell King, Lorenzo Pieralisi,
Lyude Paul, Marek Szyprowski, nouveau, Palmer Dabbelt,
Paul Walmsley, Rafael J. Wysocki, Rob Herring, Robin Murphy,
Sudeep Holla, Suravee Suthikulpanit, Sven Peter,
Thomas Bogendoerfer, Vineet Gupta, Vinod Koul, Wei Liu,
Will Deacon
Cc: baolu.lu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On 2023/11/29 8:48, Jason Gunthorpe wrote:
> Allocation of dev->iommu must be done under the
> iommu_probe_device_lock. Mark this with lockdep to discourage future
> mistakes.
>
> Reviewed-by: Jerry Snitselaar<jsnitsel@redhat.com>
> Tested-by: Hector Martin<marcan@marcan.st>
> Signed-off-by: Jason Gunthorpe<jgg@nvidia.com>
> ---
> drivers/iommu/iommu.c | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Best regards,
baolu
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep
2023-11-29 0:48 ` [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep Jason Gunthorpe
2023-11-29 3:11 ` Baolu Lu
@ 2023-11-29 6:06 ` Moritz Fischer
1 sibling, 0 replies; 30+ messages in thread
From: Moritz Fischer @ 2023-11-29 6:06 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On Tue, Nov 28, 2023 at 08:48:00PM -0400, Jason Gunthorpe wrote:
> Allocation of dev->iommu must be done under the
> iommu_probe_device_lock. Mark this with lockdep to discourage future
> mistakes.
> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
> Tested-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/iommu.c | 2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 0d25468d53a68a..4323b6276e977f 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -334,6 +334,8 @@ static struct dev_iommu *dev_iommu_get(struct device
> *dev)
> {
> struct dev_iommu *param = dev->iommu;
> + lockdep_assert_held(&iommu_probe_device_lock);
> +
> if (param)
> return param;
> --
> 2.42.0
Reviewed-by: Moritz Fischer <moritzf@google.com>
Cheers,
Moritz
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 05/10] iommu: Mark dev_iommu_priv_set() with a lockdep
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
` (3 preceding siblings ...)
2023-11-29 0:48 ` [PATCH 04/10] iommu: Mark dev_iommu_get() with lockdep Jason Gunthorpe
@ 2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 0:48 ` [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock Jason Gunthorpe
` (4 subsequent siblings)
9 siblings, 0 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:48 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
A perfect driver would only call dev_iommu_priv_set() from its probe
callback. We've made it functionally correct to call it from the of_xlate
by adding a lock around that call.
lockdep assert that iommu_probe_device_lock is held to discourage misuse.
Exclude PPC kernels with CONFIG_FSL_PAMU turned on because FSL_PAMU uses a
global static for its priv and abuses priv for its domain.
Remove the pointless stores of NULL, all these are on paths where the core
code will free dev->iommu after the op returns.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Tested-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/amd/iommu.c | 2 --
drivers/iommu/apple-dart.c | 1 -
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 -
drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 -
drivers/iommu/intel/iommu.c | 2 --
drivers/iommu/iommu.c | 9 +++++++++
drivers/iommu/omap-iommu.c | 1 -
include/linux/iommu.h | 5 +----
8 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 9f706436082833..be58644a6fa518 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -551,8 +551,6 @@ static void amd_iommu_uninit_device(struct device *dev)
if (dev_data->domain)
detach_device(dev);
- dev_iommu_priv_set(dev, NULL);
-
/*
* We keep dev_data around for unplugged devices and reuse it when the
* device is re-plugged - not doing so would introduce a ton of races.
diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c
index 7438e9c82ba982..25135440b5dd54 100644
--- a/drivers/iommu/apple-dart.c
+++ b/drivers/iommu/apple-dart.c
@@ -743,7 +743,6 @@ static void apple_dart_release_device(struct device *dev)
{
struct apple_dart_master_cfg *cfg = dev_iommu_priv_get(dev);
- dev_iommu_priv_set(dev, NULL);
kfree(cfg);
}
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index fc4317c25b6d53..1855d3892b15f8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -2695,7 +2695,6 @@ static struct iommu_device *arm_smmu_probe_device(struct device *dev)
err_free_master:
kfree(master);
- dev_iommu_priv_set(dev, NULL);
return ERR_PTR(ret);
}
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
index 4d09c004789274..adc7937fd8a3a3 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
@@ -1420,7 +1420,6 @@ static void arm_smmu_release_device(struct device *dev)
arm_smmu_rpm_put(cfg->smmu);
- dev_iommu_priv_set(dev, NULL);
kfree(cfg);
}
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 897159dba47de4..511589341074f0 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4461,7 +4461,6 @@ static struct iommu_device *intel_iommu_probe_device(struct device *dev)
ret = intel_pasid_alloc_table(dev);
if (ret) {
dev_err(dev, "PASID table allocation failed\n");
- dev_iommu_priv_set(dev, NULL);
kfree(info);
return ERR_PTR(ret);
}
@@ -4479,7 +4478,6 @@ static void intel_iommu_release_device(struct device *dev)
dmar_remove_one_dev_info(dev);
intel_pasid_free_table(dev);
intel_iommu_debugfs_remove_dev(info);
- dev_iommu_priv_set(dev, NULL);
kfree(info);
set_dma_ops(dev, NULL);
}
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 4323b6276e977f..08f29a1dfcd5f8 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -387,6 +387,15 @@ static u32 dev_iommu_get_max_pasids(struct device *dev)
return min_t(u32, max_pasids, dev->iommu->iommu_dev->max_pasids);
}
+void dev_iommu_priv_set(struct device *dev, void *priv)
+{
+ /* FSL_PAMU does something weird */
+ if (!IS_ENABLED(CONFIG_FSL_PAMU))
+ lockdep_assert_held(&iommu_probe_device_lock);
+ dev->iommu->priv = priv;
+}
+EXPORT_SYMBOL_GPL(dev_iommu_priv_set);
+
/*
* Init the dev->iommu and dev->iommu_group in the struct device and get the
* driver probed
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c66b070841dd41..c9528065a59afa 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1719,7 +1719,6 @@ static void omap_iommu_release_device(struct device *dev)
if (!dev->of_node || !arch_data)
return;
- dev_iommu_priv_set(dev, NULL);
kfree(arch_data);
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index c7394b39599c84..c24933a1d0d643 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -840,10 +840,7 @@ static inline void *dev_iommu_priv_get(struct device *dev)
return NULL;
}
-static inline void dev_iommu_priv_set(struct device *dev, void *priv)
-{
- dev->iommu->priv = priv;
-}
+void dev_iommu_priv_set(struct device *dev, void *priv);
extern struct mutex iommu_probe_device_lock;
int iommu_probe_device(struct device *dev);
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
` (4 preceding siblings ...)
2023-11-29 0:48 ` [PATCH 05/10] iommu: Mark dev_iommu_priv_set() with a lockdep Jason Gunthorpe
@ 2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 17:58 ` Robin Murphy
2023-11-29 0:48 ` [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id() Jason Gunthorpe
` (3 subsequent siblings)
9 siblings, 1 reply; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:48 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
The iommu_device_lock protects the iommu_device_list which is only read by
iommu_ops_from_fwnode().
This is now always called under the iommu_probe_device_lock, so we don't
need to double lock the linked list. Use the iommu_probe_device_lock on
the write side too.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/iommu.c | 30 +++++++++++++-----------------
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 08f29a1dfcd5f8..9557c2ec08d915 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -146,7 +146,6 @@ struct iommu_group_attribute iommu_group_attr_##_name = \
container_of(_kobj, struct iommu_group, kobj)
static LIST_HEAD(iommu_device_list);
-static DEFINE_SPINLOCK(iommu_device_lock);
static const struct bus_type * const iommu_buses[] = {
&platform_bus_type,
@@ -262,9 +261,9 @@ int iommu_device_register(struct iommu_device *iommu,
if (hwdev)
iommu->fwnode = dev_fwnode(hwdev);
- spin_lock(&iommu_device_lock);
+ mutex_lock(&iommu_probe_device_lock);
list_add_tail(&iommu->list, &iommu_device_list);
- spin_unlock(&iommu_device_lock);
+ mutex_unlock(&iommu_probe_device_lock);
for (int i = 0; i < ARRAY_SIZE(iommu_buses) && !err; i++)
err = bus_iommu_probe(iommu_buses[i]);
@@ -279,9 +278,9 @@ void iommu_device_unregister(struct iommu_device *iommu)
for (int i = 0; i < ARRAY_SIZE(iommu_buses); i++)
bus_for_each_dev(iommu_buses[i], NULL, iommu, remove_iommu_group);
- spin_lock(&iommu_device_lock);
+ mutex_lock(&iommu_probe_device_lock);
list_del(&iommu->list);
- spin_unlock(&iommu_device_lock);
+ mutex_unlock(&iommu_probe_device_lock);
/* Pairs with the alloc in generic_single_device_group() */
iommu_group_put(iommu->singleton_group);
@@ -316,9 +315,9 @@ int iommu_device_register_bus(struct iommu_device *iommu,
if (err)
return err;
- spin_lock(&iommu_device_lock);
+ mutex_lock(&iommu_probe_device_lock);
list_add_tail(&iommu->list, &iommu_device_list);
- spin_unlock(&iommu_device_lock);
+ mutex_unlock(&iommu_probe_device_lock);
err = bus_iommu_probe(bus);
if (err) {
@@ -2033,9 +2032,9 @@ bool iommu_present(const struct bus_type *bus)
for (int i = 0; i < ARRAY_SIZE(iommu_buses); i++) {
if (iommu_buses[i] == bus) {
- spin_lock(&iommu_device_lock);
+ mutex_lock(&iommu_probe_device_lock);
ret = !list_empty(&iommu_device_list);
- spin_unlock(&iommu_device_lock);
+ mutex_unlock(&iommu_probe_device_lock);
}
}
return ret;
@@ -2980,17 +2979,14 @@ EXPORT_SYMBOL_GPL(iommu_default_passthrough);
const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode)
{
- const struct iommu_ops *ops = NULL;
struct iommu_device *iommu;
- spin_lock(&iommu_device_lock);
+ lockdep_assert_held(&iommu_probe_device_lock);
+
list_for_each_entry(iommu, &iommu_device_list, list)
- if (iommu->fwnode == fwnode) {
- ops = iommu->ops;
- break;
- }
- spin_unlock(&iommu_device_lock);
- return ops;
+ if (iommu->fwnode == fwnode)
+ return iommu->ops;
+ return NULL;
}
int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock
2023-11-29 0:48 ` [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock Jason Gunthorpe
@ 2023-11-29 17:58 ` Robin Murphy
2023-11-29 19:04 ` Jason Gunthorpe
0 siblings, 1 reply; 30+ messages in thread
From: Robin Murphy @ 2023-11-29 17:58 UTC (permalink / raw)
To: Jason Gunthorpe, David Airlie, Alyssa Rosenzweig, Albert Ou,
asahi, Catalin Marinas, Danilo Krummrich, Daniel Vetter,
Dexuan Cui, devicetree, dmaengine, dri-devel, David Woodhouse,
Frank Rowand, Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter,
Joerg Roedel, Karol Herbst, Krzysztof Kozlowski,
K. Y. Srinivasan, Laxman Dewangan, Len Brown, linux-acpi,
linux-arm-kernel, linux-hyperv, linux-mips, linux-riscv,
linux-snps-arc, linux-tegra, Russell King, Lorenzo Pieralisi,
Lyude Paul, Marek Szyprowski, nouveau, Palmer Dabbelt,
Paul Walmsley, Rafael J. Wysocki, Rob Herring, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
> The iommu_device_lock protects the iommu_device_list which is only read by
> iommu_ops_from_fwnode().
>
> This is now always called under the iommu_probe_device_lock, so we don't
> need to double lock the linked list. Use the iommu_probe_device_lock on
> the write side too.
Please no, iommu_probe_device_lock() is a hack and we need to remove the
*reason* it exists at all. And IMO just because iommu_present() is
deprecated doesn't justify making it look utterly nonsensical - in no
way does that have any relationship with probe_device, much less need to
serialise against it!
Thanks,
Robin.
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/iommu.c | 30 +++++++++++++-----------------
> 1 file changed, 13 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 08f29a1dfcd5f8..9557c2ec08d915 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -146,7 +146,6 @@ struct iommu_group_attribute iommu_group_attr_##_name = \
> container_of(_kobj, struct iommu_group, kobj)
>
> static LIST_HEAD(iommu_device_list);
> -static DEFINE_SPINLOCK(iommu_device_lock);
>
> static const struct bus_type * const iommu_buses[] = {
> &platform_bus_type,
> @@ -262,9 +261,9 @@ int iommu_device_register(struct iommu_device *iommu,
> if (hwdev)
> iommu->fwnode = dev_fwnode(hwdev);
>
> - spin_lock(&iommu_device_lock);
> + mutex_lock(&iommu_probe_device_lock);
> list_add_tail(&iommu->list, &iommu_device_list);
> - spin_unlock(&iommu_device_lock);
> + mutex_unlock(&iommu_probe_device_lock);
>
> for (int i = 0; i < ARRAY_SIZE(iommu_buses) && !err; i++)
> err = bus_iommu_probe(iommu_buses[i]);
> @@ -279,9 +278,9 @@ void iommu_device_unregister(struct iommu_device *iommu)
> for (int i = 0; i < ARRAY_SIZE(iommu_buses); i++)
> bus_for_each_dev(iommu_buses[i], NULL, iommu, remove_iommu_group);
>
> - spin_lock(&iommu_device_lock);
> + mutex_lock(&iommu_probe_device_lock);
> list_del(&iommu->list);
> - spin_unlock(&iommu_device_lock);
> + mutex_unlock(&iommu_probe_device_lock);
>
> /* Pairs with the alloc in generic_single_device_group() */
> iommu_group_put(iommu->singleton_group);
> @@ -316,9 +315,9 @@ int iommu_device_register_bus(struct iommu_device *iommu,
> if (err)
> return err;
>
> - spin_lock(&iommu_device_lock);
> + mutex_lock(&iommu_probe_device_lock);
> list_add_tail(&iommu->list, &iommu_device_list);
> - spin_unlock(&iommu_device_lock);
> + mutex_unlock(&iommu_probe_device_lock);
>
> err = bus_iommu_probe(bus);
> if (err) {
> @@ -2033,9 +2032,9 @@ bool iommu_present(const struct bus_type *bus)
>
> for (int i = 0; i < ARRAY_SIZE(iommu_buses); i++) {
> if (iommu_buses[i] == bus) {
> - spin_lock(&iommu_device_lock);
> + mutex_lock(&iommu_probe_device_lock);
> ret = !list_empty(&iommu_device_list);
> - spin_unlock(&iommu_device_lock);
> + mutex_unlock(&iommu_probe_device_lock);
> }
> }
> return ret;
> @@ -2980,17 +2979,14 @@ EXPORT_SYMBOL_GPL(iommu_default_passthrough);
>
> const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode)
> {
> - const struct iommu_ops *ops = NULL;
> struct iommu_device *iommu;
>
> - spin_lock(&iommu_device_lock);
> + lockdep_assert_held(&iommu_probe_device_lock);
> +
> list_for_each_entry(iommu, &iommu_device_list, list)
> - if (iommu->fwnode == fwnode) {
> - ops = iommu->ops;
> - break;
> - }
> - spin_unlock(&iommu_device_lock);
> - return ops;
> + if (iommu->fwnode == fwnode)
> + return iommu->ops;
> + return NULL;
> }
>
> int iommu_fwspec_init(struct device *dev, struct fwnode_handle *iommu_fwnode,
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock
2023-11-29 17:58 ` Robin Murphy
@ 2023-11-29 19:04 ` Jason Gunthorpe
0 siblings, 0 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 19:04 UTC (permalink / raw)
To: Robin Murphy
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On Wed, Nov 29, 2023 at 05:58:08PM +0000, Robin Murphy wrote:
> On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
> > The iommu_device_lock protects the iommu_device_list which is only read by
> > iommu_ops_from_fwnode().
> >
> > This is now always called under the iommu_probe_device_lock, so we don't
> > need to double lock the linked list. Use the iommu_probe_device_lock on
> > the write side too.
>
> Please no, iommu_probe_device_lock() is a hack and we need to remove the
> *reason* it exists at all.
Yes, I agree that goal is good
However, it is doing a lot of things, removing it is not so easy.
One thing it is quietly doing is keeping the ops and iommu_device
pointers alive during the entire probe process against(deeply broken,
but whatever) concurrent iommu driver removal.
It is also protecting access to dev->iommu_group during the group
formation process.
So, it is a little more complex. My specific interest was to make it
not a spinlock.
> And IMO just because iommu_present() is
> deprecated doesn't justify making it look utterly nonsensical - in no way
> does that have any relationship with probe_device, much less need to
> serialise against it!
The naming is poor now, I agree, but it is not nonsensical since it
still holds the correct lock for the data it is accessing.
Thanks,
Jason
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id()
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
` (5 preceding siblings ...)
2023-11-29 0:48 ` [PATCH 06/10] iommu: Replace iommu_device_lock with iommu_probe_device_lock Jason Gunthorpe
@ 2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 3:09 ` Baolu Lu
2023-11-29 6:09 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places Jason Gunthorpe
` (2 subsequent siblings)
9 siblings, 2 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:48 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
Nothing needs this pointer. Return a normal error code with the usual
IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Tested-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/acpi/scan.c | 29 +++++++++++++++++------------
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 444a0b3c72f2d8..340ba720c72129 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1562,8 +1562,7 @@ static inline const struct iommu_ops *acpi_iommu_fwspec_ops(struct device *dev)
return fwspec ? fwspec->ops : NULL;
}
-static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
- const u32 *id_in)
+static int acpi_iommu_configure_id(struct device *dev, const u32 *id_in)
{
int err;
const struct iommu_ops *ops;
@@ -1577,7 +1576,7 @@ static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
ops = acpi_iommu_fwspec_ops(dev);
if (ops) {
mutex_unlock(&iommu_probe_device_lock);
- return ops;
+ return 0;
}
err = iort_iommu_configure_id(dev, id_in);
@@ -1594,12 +1593,14 @@ static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
/* Ignore all other errors apart from EPROBE_DEFER */
if (err == -EPROBE_DEFER) {
- return ERR_PTR(err);
+ return err;
} else if (err) {
dev_dbg(dev, "Adding to IOMMU failed: %d\n", err);
- return NULL;
+ return -ENODEV;
}
- return acpi_iommu_fwspec_ops(dev);
+ if (!acpi_iommu_fwspec_ops(dev))
+ return -ENODEV;
+ return 0;
}
#else /* !CONFIG_IOMMU_API */
@@ -1611,10 +1612,9 @@ int acpi_iommu_fwspec_init(struct device *dev, u32 id,
return -ENODEV;
}
-static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
- const u32 *id_in)
+static int acpi_iommu_configure_id(struct device *dev, const u32 *id_in)
{
- return NULL;
+ return -ENODEV;
}
#endif /* !CONFIG_IOMMU_API */
@@ -1628,7 +1628,7 @@ static const struct iommu_ops *acpi_iommu_configure_id(struct device *dev,
int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
const u32 *input_id)
{
- const struct iommu_ops *iommu;
+ int ret;
if (attr == DEV_DMA_NOT_SUPPORTED) {
set_dma_ops(dev, &dma_dummy_ops);
@@ -1637,10 +1637,15 @@ int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
acpi_arch_dma_setup(dev);
- iommu = acpi_iommu_configure_id(dev, input_id);
- if (PTR_ERR(iommu) == -EPROBE_DEFER)
+ ret = acpi_iommu_configure_id(dev, input_id);
+ if (ret == -EPROBE_DEFER)
return -EPROBE_DEFER;
+ /*
+ * Historically this routine doesn't fail driver probing due to errors
+ * in acpi_iommu_configure_id()
+ */
+
arch_setup_dma_ops(dev, 0, U64_MAX, attr == DEV_DMA_COHERENT);
return 0;
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id()
2023-11-29 0:48 ` [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id() Jason Gunthorpe
@ 2023-11-29 3:09 ` Baolu Lu
2023-11-29 6:09 ` Moritz Fischer
1 sibling, 0 replies; 30+ messages in thread
From: Baolu Lu @ 2023-11-29 3:09 UTC (permalink / raw)
To: Jason Gunthorpe, David Airlie, Alyssa Rosenzweig, Albert Ou,
asahi, Catalin Marinas, Danilo Krummrich, Daniel Vetter,
Dexuan Cui, devicetree, dmaengine, dri-devel, David Woodhouse,
Frank Rowand, Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter,
Joerg Roedel, Karol Herbst, Krzysztof Kozlowski,
K. Y. Srinivasan, Laxman Dewangan, Len Brown, linux-acpi,
linux-arm-kernel, linux-hyperv, linux-mips, linux-riscv,
linux-snps-arc, linux-tegra, Russell King, Lorenzo Pieralisi,
Lyude Paul, Marek Szyprowski, nouveau, Palmer Dabbelt,
Paul Walmsley, Rafael J. Wysocki, Rob Herring, Robin Murphy,
Sudeep Holla, Suravee Suthikulpanit, Sven Peter,
Thomas Bogendoerfer, Vineet Gupta, Vinod Koul, Wei Liu,
Will Deacon
Cc: baolu.lu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On 2023/11/29 8:48, Jason Gunthorpe wrote:
> Nothing needs this pointer. Return a normal error code with the usual
> IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
>
> Acked-by: Rafael J. Wysocki<rafael.j.wysocki@intel.com>
> Reviewed-by: Jerry Snitselaar<jsnitsel@redhat.com>
> Tested-by: Hector Martin<marcan@marcan.st>
> Signed-off-by: Jason Gunthorpe<jgg@nvidia.com>
> ---
> drivers/acpi/scan.c | 29 +++++++++++++++++------------
> 1 file changed, 17 insertions(+), 12 deletions(-)
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Best regards,
baolu
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id()
2023-11-29 0:48 ` [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id() Jason Gunthorpe
2023-11-29 3:09 ` Baolu Lu
@ 2023-11-29 6:09 ` Moritz Fischer
1 sibling, 0 replies; 30+ messages in thread
From: Moritz Fischer @ 2023-11-29 6:09 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On Tue, Nov 28, 2023 at 08:48:03PM -0400, Jason Gunthorpe wrote:
> Nothing needs this pointer. Return a normal error code with the usual
> IOMMU semantic that ENODEV means 'there is no IOMMU driver'.
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
> Tested-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/acpi/scan.c | 29 +++++++++++++++++------------
> 1 file changed, 17 insertions(+), 12 deletions(-)
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 444a0b3c72f2d8..340ba720c72129 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1562,8 +1562,7 @@ static inline const struct iommu_ops
> *acpi_iommu_fwspec_ops(struct device *dev)
> return fwspec ? fwspec->ops : NULL;
> }
> -static const struct iommu_ops *acpi_iommu_configure_id(struct device
> *dev,
> - const u32 *id_in)
> +static int acpi_iommu_configure_id(struct device *dev, const u32 *id_in)
> {
> int err;
> const struct iommu_ops *ops;
> @@ -1577,7 +1576,7 @@ static const struct iommu_ops
> *acpi_iommu_configure_id(struct device *dev,
> ops = acpi_iommu_fwspec_ops(dev);
> if (ops) {
> mutex_unlock(&iommu_probe_device_lock);
> - return ops;
> + return 0;
> }
> err = iort_iommu_configure_id(dev, id_in);
> @@ -1594,12 +1593,14 @@ static const struct iommu_ops
> *acpi_iommu_configure_id(struct device *dev,
> /* Ignore all other errors apart from EPROBE_DEFER */
> if (err == -EPROBE_DEFER) {
> - return ERR_PTR(err);
> + return err;
> } else if (err) {
> dev_dbg(dev, "Adding to IOMMU failed: %d\n", err);
> - return NULL;
> + return -ENODEV;
> }
> - return acpi_iommu_fwspec_ops(dev);
> + if (!acpi_iommu_fwspec_ops(dev))
> + return -ENODEV;
> + return 0;
> }
> #else /* !CONFIG_IOMMU_API */
> @@ -1611,10 +1612,9 @@ int acpi_iommu_fwspec_init(struct device *dev, u32
> id,
> return -ENODEV;
> }
> -static const struct iommu_ops *acpi_iommu_configure_id(struct device
> *dev,
> - const u32 *id_in)
> +static int acpi_iommu_configure_id(struct device *dev, const u32 *id_in)
> {
> - return NULL;
> + return -ENODEV;
> }
> #endif /* !CONFIG_IOMMU_API */
> @@ -1628,7 +1628,7 @@ static const struct iommu_ops
> *acpi_iommu_configure_id(struct device *dev,
> int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
> const u32 *input_id)
> {
> - const struct iommu_ops *iommu;
> + int ret;
> if (attr == DEV_DMA_NOT_SUPPORTED) {
> set_dma_ops(dev, &dma_dummy_ops);
> @@ -1637,10 +1637,15 @@ int acpi_dma_configure_id(struct device *dev,
> enum dev_dma_attr attr,
> acpi_arch_dma_setup(dev);
> - iommu = acpi_iommu_configure_id(dev, input_id);
> - if (PTR_ERR(iommu) == -EPROBE_DEFER)
> + ret = acpi_iommu_configure_id(dev, input_id);
> + if (ret == -EPROBE_DEFER)
> return -EPROBE_DEFER;
> + /*
> + * Historically this routine doesn't fail driver probing due to errors
> + * in acpi_iommu_configure_id()
> + */
> +
> arch_setup_dma_ops(dev, 0, U64_MAX, attr == DEV_DMA_COHERENT);
> return 0;
> --
> 2.42.0
Reviewed-by: Moritz Fischer <moritzf@google.com>
Cheers,
Moritz
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
` (6 preceding siblings ...)
2023-11-29 0:48 ` [PATCH 07/10] acpi: Do not return struct iommu_ops from acpi_iommu_configure_id() Jason Gunthorpe
@ 2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 16:23 ` Thierry Reding
2023-11-29 0:48 ` [PATCH 09/10] ACPI: IORT: Cast from ULL to phys_addr_t Jason Gunthorpe
2023-11-29 0:48 ` [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT Jason Gunthorpe
9 siblings, 1 reply; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:48 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
This API was defined to formalize the access to internal iommu details on
some Tegra SOCs, but a few callers got missed. Add them.
The helper already masks by 0xFFFF so remove this code from the callers.
Suggested-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/dma/tegra186-gpc-dma.c | 8 +++-----
drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 7 ++-----
drivers/memory/tegra/tegra186.c | 12 ++++++------
3 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
index fa4d4142a68a21..88547a23825b18 100644
--- a/drivers/dma/tegra186-gpc-dma.c
+++ b/drivers/dma/tegra186-gpc-dma.c
@@ -1348,8 +1348,8 @@ static int tegra_dma_program_sid(struct tegra_dma_channel *tdc, int stream_id)
static int tegra_dma_probe(struct platform_device *pdev)
{
const struct tegra_dma_chip_data *cdata = NULL;
- struct iommu_fwspec *iommu_spec;
- unsigned int stream_id, i;
+ unsigned int i;
+ u32 stream_id;
struct tegra_dma *tdma;
int ret;
@@ -1378,12 +1378,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
tdma->dma_dev.dev = &pdev->dev;
- iommu_spec = dev_iommu_fwspec_get(&pdev->dev);
- if (!iommu_spec) {
+ if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id)) {
dev_err(&pdev->dev, "Missing iommu stream-id\n");
return -EINVAL;
}
- stream_id = iommu_spec->ids[0] & 0xffff;
ret = device_property_read_u32(&pdev->dev, "dma-channel-mask",
&tdma->chan_mask);
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
index e7e8fdf3adab7a..b40fd1dbb21617 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
@@ -28,16 +28,13 @@ static void
gp10b_ltc_init(struct nvkm_ltc *ltc)
{
struct nvkm_device *device = ltc->subdev.device;
- struct iommu_fwspec *spec;
+ u32 sid;
nvkm_wr32(device, 0x17e27c, ltc->ltc_nr);
nvkm_wr32(device, 0x17e000, ltc->ltc_nr);
nvkm_wr32(device, 0x100800, ltc->ltc_nr);
- spec = dev_iommu_fwspec_get(device->dev);
- if (spec) {
- u32 sid = spec->ids[0] & 0xffff;
-
+ if (tegra_dev_iommu_get_stream_id(device->dev, &sid)) {
/* stream ID */
nvkm_wr32(device, 0x160000, sid << 2);
}
diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
index 533f85a4b2bdb7..3e4fbe94dd666e 100644
--- a/drivers/memory/tegra/tegra186.c
+++ b/drivers/memory/tegra/tegra186.c
@@ -111,21 +111,21 @@ static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
{
#if IS_ENABLED(CONFIG_IOMMU_API)
- struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct of_phandle_args args;
unsigned int i, index = 0;
+ u32 sid;
+ WARN_ON(!tegra_dev_iommu_get_stream_id(dev, &sid));
while (!of_parse_phandle_with_args(dev->of_node, "interconnects", "#interconnect-cells",
index, &args)) {
if (args.np == mc->dev->of_node && args.args_count != 0) {
for (i = 0; i < mc->soc->num_clients; i++) {
const struct tegra_mc_client *client = &mc->soc->clients[i];
- if (client->id == args.args[0]) {
- u32 sid = fwspec->ids[0] & MC_SID_STREAMID_OVERRIDE_MASK;
-
- tegra186_mc_client_sid_override(mc, client, sid);
- }
+ if (client->id == args.args[0])
+ tegra186_mc_client_sid_override(
+ mc, client,
+ sid & MC_SID_STREAMID_OVERRIDE_MASK);
}
}
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places
2023-11-29 0:48 ` [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places Jason Gunthorpe
@ 2023-11-29 16:23 ` Thierry Reding
2023-11-29 19:26 ` Jason Gunthorpe
0 siblings, 1 reply; 30+ messages in thread
From: Thierry Reding @ 2023-11-29 16:23 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring
[-- Attachment #1.1: Type: text/plain, Size: 3969 bytes --]
On Tue, Nov 28, 2023 at 08:48:04PM -0400, Jason Gunthorpe wrote:
> This API was defined to formalize the access to internal iommu details on
> some Tegra SOCs, but a few callers got missed. Add them.
>
> The helper already masks by 0xFFFF so remove this code from the callers.
>
> Suggested-by: Thierry Reding <thierry.reding@gmail.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/dma/tegra186-gpc-dma.c | 8 +++-----
> drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 7 ++-----
> drivers/memory/tegra/tegra186.c | 12 ++++++------
> 3 files changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-dma.c
> index fa4d4142a68a21..88547a23825b18 100644
> --- a/drivers/dma/tegra186-gpc-dma.c
> +++ b/drivers/dma/tegra186-gpc-dma.c
> @@ -1348,8 +1348,8 @@ static int tegra_dma_program_sid(struct tegra_dma_channel *tdc, int stream_id)
> static int tegra_dma_probe(struct platform_device *pdev)
> {
> const struct tegra_dma_chip_data *cdata = NULL;
> - struct iommu_fwspec *iommu_spec;
> - unsigned int stream_id, i;
> + unsigned int i;
> + u32 stream_id;
> struct tegra_dma *tdma;
> int ret;
>
> @@ -1378,12 +1378,10 @@ static int tegra_dma_probe(struct platform_device *pdev)
>
> tdma->dma_dev.dev = &pdev->dev;
>
> - iommu_spec = dev_iommu_fwspec_get(&pdev->dev);
> - if (!iommu_spec) {
> + if (!tegra_dev_iommu_get_stream_id(&pdev->dev, &stream_id)) {
> dev_err(&pdev->dev, "Missing iommu stream-id\n");
> return -EINVAL;
> }
> - stream_id = iommu_spec->ids[0] & 0xffff;
>
> ret = device_property_read_u32(&pdev->dev, "dma-channel-mask",
> &tdma->chan_mask);
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> index e7e8fdf3adab7a..b40fd1dbb21617 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> @@ -28,16 +28,13 @@ static void
> gp10b_ltc_init(struct nvkm_ltc *ltc)
> {
> struct nvkm_device *device = ltc->subdev.device;
> - struct iommu_fwspec *spec;
> + u32 sid;
>
> nvkm_wr32(device, 0x17e27c, ltc->ltc_nr);
> nvkm_wr32(device, 0x17e000, ltc->ltc_nr);
> nvkm_wr32(device, 0x100800, ltc->ltc_nr);
>
> - spec = dev_iommu_fwspec_get(device->dev);
> - if (spec) {
> - u32 sid = spec->ids[0] & 0xffff;
> -
> + if (tegra_dev_iommu_get_stream_id(device->dev, &sid)) {
> /* stream ID */
> nvkm_wr32(device, 0x160000, sid << 2);
We could probably also remove the comment now since the function and
variable names make it obvious what's being written here.
> }
> diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> index 533f85a4b2bdb7..3e4fbe94dd666e 100644
> --- a/drivers/memory/tegra/tegra186.c
> +++ b/drivers/memory/tegra/tegra186.c
> @@ -111,21 +111,21 @@ static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
> static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> {
> #if IS_ENABLED(CONFIG_IOMMU_API)
> - struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> struct of_phandle_args args;
> unsigned int i, index = 0;
> + u32 sid;
>
> + WARN_ON(!tegra_dev_iommu_get_stream_id(dev, &sid));
I know the code previously didn't check for any errors, but we may want
to do so now. If tegra_dev_iommu_get_stream_id() ever fails we may end
up writing some undefined value into the override register.
I'm also unsure if WARN_ON() is appropriate here. I vaguely recall that
->probe_device() was called for all devices on the bus and not all of
them may have been associated with the IOMMU. Not all of them may in
fact access memory in the first place.
Perhaps I'm misremembering and the IOMMU core now takes care of only
calling this when fwspec is indeed valid?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places
2023-11-29 16:23 ` Thierry Reding
@ 2023-11-29 19:26 ` Jason Gunthorpe
2023-12-01 11:22 ` Thierry Reding
0 siblings, 1 reply; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 19:26 UTC (permalink / raw)
To: Thierry Reding
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring
On Wed, Nov 29, 2023 at 05:23:13PM +0100, Thierry Reding wrote:
> > diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> > index 533f85a4b2bdb7..3e4fbe94dd666e 100644
> > --- a/drivers/memory/tegra/tegra186.c
> > +++ b/drivers/memory/tegra/tegra186.c
> > @@ -111,21 +111,21 @@ static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
> > static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> > {
> > #if IS_ENABLED(CONFIG_IOMMU_API)
> > - struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > struct of_phandle_args args;
> > unsigned int i, index = 0;
> > + u32 sid;
> >
> > + WARN_ON(!tegra_dev_iommu_get_stream_id(dev, &sid));
>
> I know the code previously didn't check for any errors, but we may want
> to do so now. If tegra_dev_iommu_get_stream_id() ever fails we may end
> up writing some undefined value into the override register.
My assumption was it never fails otherwise this probably already
doesn't work?
> I'm also unsure if WARN_ON() is appropriate here. I vaguely recall that
> ->probe_device() was called for all devices on the bus and not all of
> them may have been associated with the IOMMU. Not all of them may in
> fact access memory in the first place.
So you are thinkin that of_parse_phandle_with_args() is a NOP
sometimes so it will tolerate the failure?
Seems like the best thing to do is just continue to ignore it then?
> Perhaps I'm misremembering and the IOMMU core now takes care of only
> calling this when fwspec is indeed valid?
Can't advise, I have no idea what tegra_mc_ops is for :)
Jason
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places
2023-11-29 19:26 ` Jason Gunthorpe
@ 2023-12-01 11:22 ` Thierry Reding
0 siblings, 0 replies; 30+ messages in thread
From: Thierry Reding @ 2023-12-01 11:22 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring
[-- Attachment #1.1: Type: text/plain, Size: 3582 bytes --]
On Wed, Nov 29, 2023 at 03:26:03PM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 29, 2023 at 05:23:13PM +0100, Thierry Reding wrote:
> > > diff --git a/drivers/memory/tegra/tegra186.c b/drivers/memory/tegra/tegra186.c
> > > index 533f85a4b2bdb7..3e4fbe94dd666e 100644
> > > --- a/drivers/memory/tegra/tegra186.c
> > > +++ b/drivers/memory/tegra/tegra186.c
> > > @@ -111,21 +111,21 @@ static void tegra186_mc_client_sid_override(struct tegra_mc *mc,
> > > static int tegra186_mc_probe_device(struct tegra_mc *mc, struct device *dev)
> > > {
> > > #if IS_ENABLED(CONFIG_IOMMU_API)
> > > - struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
> > > struct of_phandle_args args;
> > > unsigned int i, index = 0;
> > > + u32 sid;
> > >
> > > + WARN_ON(!tegra_dev_iommu_get_stream_id(dev, &sid));
> >
> > I know the code previously didn't check for any errors, but we may want
> > to do so now. If tegra_dev_iommu_get_stream_id() ever fails we may end
> > up writing some undefined value into the override register.
>
> My assumption was it never fails otherwise this probably already
> doesn't work?
I guess the point I was trying to make is that previously we would not
have written anything to the stream ID register and so ignoring the
error here might end up writing to a register that previously we would
not have written to. Looking at the current code more closely I see now
that the reason why we wouldn't have written to the register is because
we would've crashed before.
So I think this okay.
>
> > I'm also unsure if WARN_ON() is appropriate here. I vaguely recall that
> > ->probe_device() was called for all devices on the bus and not all of
> > them may have been associated with the IOMMU. Not all of them may in
> > fact access memory in the first place.
>
> So you are thinkin that of_parse_phandle_with_args() is a NOP
> sometimes so it will tolerate the failure?
>
> Seems like the best thing to do is just continue to ignore it then?
Yeah, exactly. It would've just skipped over everything, basically.
> > Perhaps I'm misremembering and the IOMMU core now takes care of only
> > calling this when fwspec is indeed valid?
>
> Can't advise, I have no idea what tegra_mc_ops is for :)
In a nutshell, it's a hook that allows us to configure the memory
controller when a device is attached to the IOMMU. The memory controller
contains a set of registers that specify which memory client uses which
stream ID by default. For some devices this can be overridden (which is
where tegra_dev_iommu_get_stream_id() comes into play in those drivers)
and for other devices we can't override, which is when the memory
controller defaults come into play.
Anyway, I took a closer look at this and ran some tests. Turns out that
tegra186_mc_probe_device() really only gets called for devices that have
their fwspec properly initialized anyway, so I don't think there's
anything special we need to do here.
Strictly from a static analysis point of view I suppose we could now
have a situation that sid is uninitialized when the call to
tegra_dev_iommu_get_stream_id() fails and so using it in the loop is not
correct, theoretically, but I think that's just not a case that we'll
ever hit in practice.
So either way is fine with me. I have a slight preference for just
returning 0 in case tegra_dev_iommu_get_stream_id() fails, because it's
simple to do and avoids any of these (theoretical) ambiguities. So
whichever way you decide:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 09/10] ACPI: IORT: Cast from ULL to phys_addr_t
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
` (7 preceding siblings ...)
2023-11-29 0:48 ` [PATCH 08/10] iommu/tegra: Use tegra_dev_iommu_get_stream_id() in the remaining places Jason Gunthorpe
@ 2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 6:18 ` Moritz Fischer
2023-11-29 0:48 ` [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT Jason Gunthorpe
9 siblings, 1 reply; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:48 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
gcc on i386 (when compile testing) warns:
drivers/acpi/arm64/iort.c:2014:18: warning: implicit conversion from 'unsigned long long' to 'phys_addr_t' (aka 'unsigned int') changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
local_limit = DMA_BIT_MASK(ncomp->memory_address_limit);
Because DMA_BIT_MASK returns a large ULL constant. Explicitly truncate it
to phys_addr_t.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/acpi/arm64/iort.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6496ff5a6ba20d..bdaf9256870d92 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -2011,7 +2011,8 @@ phys_addr_t __init acpi_iort_dma_get_max_cpu_address(void)
case ACPI_IORT_NODE_NAMED_COMPONENT:
ncomp = (struct acpi_iort_named_component *)node->node_data;
- local_limit = DMA_BIT_MASK(ncomp->memory_address_limit);
+ local_limit = (phys_addr_t)DMA_BIT_MASK(
+ ncomp->memory_address_limit);
limit = min_not_zero(limit, local_limit);
break;
@@ -2020,7 +2021,8 @@ phys_addr_t __init acpi_iort_dma_get_max_cpu_address(void)
break;
rc = (struct acpi_iort_root_complex *)node->node_data;
- local_limit = DMA_BIT_MASK(rc->memory_address_limit);
+ local_limit = (phys_addr_t)DMA_BIT_MASK(
+ rc->memory_address_limit);
limit = min_not_zero(limit, local_limit);
break;
}
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 09/10] ACPI: IORT: Cast from ULL to phys_addr_t
2023-11-29 0:48 ` [PATCH 09/10] ACPI: IORT: Cast from ULL to phys_addr_t Jason Gunthorpe
@ 2023-11-29 6:18 ` Moritz Fischer
0 siblings, 0 replies; 30+ messages in thread
From: Moritz Fischer @ 2023-11-29 6:18 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On Tue, Nov 28, 2023 at 08:48:05PM -0400, Jason Gunthorpe wrote:
> gcc on i386 (when compile testing) warns:
This is a weird test. The Makefile for drivers/acpi/arm64 is conditional
on CONFIG_ARM64. How does this happen?
> 8->8
obj-$(CONFIG_ARM64) += arm64/
> 8->8
> drivers/acpi/arm64/iort.c:2014:18: warning: implicit conversion
> from 'unsigned long long' to 'phys_addr_t' (aka 'unsigned int') changes
> value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
> local_limit =
> DMA_BIT_MASK(ncomp->memory_address_limit);
> Because DMA_BIT_MASK returns a large ULL constant. Explicitly truncate it
> to phys_addr_t.
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/acpi/arm64/iort.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 6496ff5a6ba20d..bdaf9256870d92 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -2011,7 +2011,8 @@ phys_addr_t __init
> acpi_iort_dma_get_max_cpu_address(void)
> case ACPI_IORT_NODE_NAMED_COMPONENT:
> ncomp = (struct acpi_iort_named_component *)node->node_data;
> - local_limit = DMA_BIT_MASK(ncomp->memory_address_limit);
> + local_limit = (phys_addr_t)DMA_BIT_MASK(
> + ncomp->memory_address_limit);
> limit = min_not_zero(limit, local_limit);
> break;
> @@ -2020,7 +2021,8 @@ phys_addr_t __init
> acpi_iort_dma_get_max_cpu_address(void)
> break;
> rc = (struct acpi_iort_root_complex *)node->node_data;
> - local_limit = DMA_BIT_MASK(rc->memory_address_limit);
> + local_limit = (phys_addr_t)DMA_BIT_MASK(
> + rc->memory_address_limit);
> limit = min_not_zero(limit, local_limit);
> break;
> }
> --
> 2.42.0
Cheers,
Moritz
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-29 0:47 [PATCH 00/10] IOMMU related FW parsing cleanup Jason Gunthorpe
` (8 preceding siblings ...)
2023-11-29 0:48 ` [PATCH 09/10] ACPI: IORT: Cast from ULL to phys_addr_t Jason Gunthorpe
@ 2023-11-29 0:48 ` Jason Gunthorpe
2023-11-29 6:20 ` Moritz Fischer
` (2 more replies)
9 siblings, 3 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 0:48 UTC (permalink / raw)
To: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
enable the IORT code so it can be COMPILE_TEST'd too.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/acpi/Kconfig | 2 --
drivers/acpi/Makefile | 2 +-
drivers/acpi/arm64/Kconfig | 1 +
drivers/acpi/arm64/Makefile | 2 +-
drivers/iommu/Kconfig | 1 +
5 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index f819e760ff195a..3b7f77b227d13a 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -541,9 +541,7 @@ config ACPI_PFRUT
To compile the drivers as modules, choose M here:
the modules will be called pfr_update and pfr_telemetry.
-if ARM64
source "drivers/acpi/arm64/Kconfig"
-endif
config ACPI_PPTT
bool
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index eaa09bf52f1760..4e77ae37b80726 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -127,7 +127,7 @@ obj-y += pmic/
video-objs += acpi_video.o video_detect.o
obj-y += dptf/
-obj-$(CONFIG_ARM64) += arm64/
+obj-y += arm64/
obj-$(CONFIG_ACPI_VIOT) += viot.o
diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
index b3ed6212244c1e..537d49d8ace69e 100644
--- a/drivers/acpi/arm64/Kconfig
+++ b/drivers/acpi/arm64/Kconfig
@@ -11,6 +11,7 @@ config ACPI_GTDT
config ACPI_AGDI
bool "Arm Generic Diagnostic Dump and Reset Device Interface"
+ depends on ARM64
depends on ARM_SDE_INTERFACE
help
Arm Generic Diagnostic Dump and Reset Device Interface (AGDI) is
diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
index 143debc1ba4a9d..71d0e635599390 100644
--- a/drivers/acpi/arm64/Makefile
+++ b/drivers/acpi/arm64/Makefile
@@ -4,4 +4,4 @@ obj-$(CONFIG_ACPI_IORT) += iort.o
obj-$(CONFIG_ACPI_GTDT) += gtdt.o
obj-$(CONFIG_ACPI_APMT) += apmt.o
obj-$(CONFIG_ARM_AMBA) += amba.o
-obj-y += dma.o init.o
+obj-$(CONFIG_ARM64) += dma.o init.o
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 7673bb82945b6c..309378e76a9bc9 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -318,6 +318,7 @@ config ARM_SMMU
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
+ select ACPI_IORT if ACPI
help
Support for implementations of the ARM System MMU architecture
versions 1 and 2.
--
2.42.0
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-29 0:48 ` [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT Jason Gunthorpe
@ 2023-11-29 6:20 ` Moritz Fischer
2023-11-29 12:55 ` Lorenzo Pieralisi
2023-11-30 14:10 ` Robin Murphy
2 siblings, 0 replies; 30+ messages in thread
From: Moritz Fischer @ 2023-11-29 6:20 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On Tue, Nov 28, 2023 at 08:48:06PM -0400, Jason Gunthorpe wrote:
> The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
> enable the IORT code so it can be COMPILE_TEST'd too.
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/acpi/Kconfig | 2 --
> drivers/acpi/Makefile | 2 +-
> drivers/acpi/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Makefile | 2 +-
> drivers/iommu/Kconfig | 1 +
> 5 files changed, 4 insertions(+), 4 deletions(-)
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index f819e760ff195a..3b7f77b227d13a 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -541,9 +541,7 @@ config ACPI_PFRUT
> To compile the drivers as modules, choose M here:
> the modules will be called pfr_update and pfr_telemetry.
> -if ARM64
> source "drivers/acpi/arm64/Kconfig"
> -endif
> config ACPI_PPTT
> bool
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index eaa09bf52f1760..4e77ae37b80726 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -127,7 +127,7 @@ obj-y += pmic/
> video-objs += acpi_video.o video_detect.o
> obj-y += dptf/
> -obj-$(CONFIG_ARM64) += arm64/
> +obj-y += arm64/
> obj-$(CONFIG_ACPI_VIOT) += viot.o
> diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
> index b3ed6212244c1e..537d49d8ace69e 100644
> --- a/drivers/acpi/arm64/Kconfig
> +++ b/drivers/acpi/arm64/Kconfig
> @@ -11,6 +11,7 @@ config ACPI_GTDT
> config ACPI_AGDI
> bool "Arm Generic Diagnostic Dump and Reset Device Interface"
> + depends on ARM64
> depends on ARM_SDE_INTERFACE
> help
> Arm Generic Diagnostic Dump and Reset Device Interface (AGDI) is
> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
> index 143debc1ba4a9d..71d0e635599390 100644
> --- a/drivers/acpi/arm64/Makefile
> +++ b/drivers/acpi/arm64/Makefile
> @@ -4,4 +4,4 @@ obj-$(CONFIG_ACPI_IORT) += iort.o
> obj-$(CONFIG_ACPI_GTDT) += gtdt.o
> obj-$(CONFIG_ACPI_APMT) += apmt.o
> obj-$(CONFIG_ARM_AMBA) += amba.o
> -obj-y += dma.o init.o
> +obj-$(CONFIG_ARM64) += dma.o init.o
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7673bb82945b6c..309378e76a9bc9 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -318,6 +318,7 @@ config ARM_SMMU
> select IOMMU_API
> select IOMMU_IO_PGTABLE_LPAE
> select ARM_DMA_USE_IOMMU if ARM
> + select ACPI_IORT if ACPI
> help
> Support for implementations of the ARM System MMU architecture
> versions 1 and 2.
> --
> 2.42.0
Reviewed-by: Moritz Fischer <moritzf@google.com>
Ok, now the previous patch makes sense :)
Cheers,
Moritz
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-29 0:48 ` [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT Jason Gunthorpe
2023-11-29 6:20 ` Moritz Fischer
@ 2023-11-29 12:55 ` Lorenzo Pieralisi
2023-11-29 19:12 ` Jason Gunthorpe
2023-11-30 14:10 ` Robin Murphy
2 siblings, 1 reply; 30+ messages in thread
From: Lorenzo Pieralisi @ 2023-11-29 12:55 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lyude Paul, Marek Szyprowski, nouveau,
Palmer Dabbelt, Paul Walmsley, Rafael J. Wysocki, Rob Herring,
Robin Murphy, Sudeep Holla, Suravee Suthikulpanit, Sven Peter,
Thomas Bogendoerfer, Vineet Gupta, Vinod Koul, Wei Liu,
Will Deacon, Lu Baolu, Christoph Hellwig, Jerry Snitselaar,
Hector Martin, Moritz Fischer, patches, Rafael J. Wysocki,
Rob Herring, Thierry Reding
On Tue, Nov 28, 2023 at 08:48:06PM -0400, Jason Gunthorpe wrote:
> The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
> enable the IORT code so it can be COMPILE_TEST'd too.
>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/acpi/Kconfig | 2 --
> drivers/acpi/Makefile | 2 +-
> drivers/acpi/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Makefile | 2 +-
> drivers/iommu/Kconfig | 1 +
> 5 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index f819e760ff195a..3b7f77b227d13a 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -541,9 +541,7 @@ config ACPI_PFRUT
> To compile the drivers as modules, choose M here:
> the modules will be called pfr_update and pfr_telemetry.
>
> -if ARM64
> source "drivers/acpi/arm64/Kconfig"
> -endif
>
> config ACPI_PPTT
> bool
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index eaa09bf52f1760..4e77ae37b80726 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -127,7 +127,7 @@ obj-y += pmic/
> video-objs += acpi_video.o video_detect.o
> obj-y += dptf/
>
> -obj-$(CONFIG_ARM64) += arm64/
> +obj-y += arm64/
>
> obj-$(CONFIG_ACPI_VIOT) += viot.o
>
> diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
> index b3ed6212244c1e..537d49d8ace69e 100644
> --- a/drivers/acpi/arm64/Kconfig
> +++ b/drivers/acpi/arm64/Kconfig
> @@ -11,6 +11,7 @@ config ACPI_GTDT
>
> config ACPI_AGDI
> bool "Arm Generic Diagnostic Dump and Reset Device Interface"
> + depends on ARM64
> depends on ARM_SDE_INTERFACE
> help
> Arm Generic Diagnostic Dump and Reset Device Interface (AGDI) is
> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
> index 143debc1ba4a9d..71d0e635599390 100644
> --- a/drivers/acpi/arm64/Makefile
> +++ b/drivers/acpi/arm64/Makefile
> @@ -4,4 +4,4 @@ obj-$(CONFIG_ACPI_IORT) += iort.o
> obj-$(CONFIG_ACPI_GTDT) += gtdt.o
> obj-$(CONFIG_ACPI_APMT) += apmt.o
> obj-$(CONFIG_ARM_AMBA) += amba.o
> -obj-y += dma.o init.o
> +obj-$(CONFIG_ARM64) += dma.o init.o
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7673bb82945b6c..309378e76a9bc9 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -318,6 +318,7 @@ config ARM_SMMU
> select IOMMU_API
> select IOMMU_IO_PGTABLE_LPAE
> select ARM_DMA_USE_IOMMU if ARM
> + select ACPI_IORT if ACPI
> help
> Support for implementations of the ARM System MMU architecture
> versions 1 and 2.
> --
I don't think it should be done this way. Is the goal compile testing
IORT code ? If so, why are we forcing it through the SMMU (only because
it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
This looks a bit artificial (and it is unclear from the Kconfig
file why only that driver selects IORT, it looks like eg the SMMUv3
does not have the same dependency - there is also the SMMUv3 perf
driver to consider).
Maybe we can move IORT code into drivers/acpi and add a silent config
option there with a dependency on ARM64 || COMPILE_TEST.
Don't know but at least it is clearer. As for the benefits of compile
testing IORT code - yes the previous patch is a warning to fix but
I am not so sure about the actual benefits.
Thanks,
Lorenzo
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-29 12:55 ` Lorenzo Pieralisi
@ 2023-11-29 19:12 ` Jason Gunthorpe
2023-11-30 11:12 ` Lorenzo Pieralisi
0 siblings, 1 reply; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-29 19:12 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lyude Paul, Marek Szyprowski, nouveau,
Palmer Dabbelt, Paul Walmsley, Rafael J. Wysocki, Rob Herring,
Robin Murphy, Sudeep Holla, Suravee Suthikulpanit, Sven Peter,
Thomas Bogendoerfer, Vineet Gupta, Vinod Koul, Wei Liu,
Will Deacon, Lu Baolu, Christoph Hellwig, Jerry Snitselaar,
Hector Martin, Moritz Fischer, patches, Rafael J. Wysocki,
Rob Herring, Thierry Reding
On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> I don't think it should be done this way. Is the goal compile testing
> IORT code ?
Yes
> If so, why are we forcing it through the SMMU (only because
> it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
Because something needs to select it, and SMMU is one of the places
that are implicitly using it.
It isn't (and shouldn't be) a user selectable kconfig. Currently the
only thing that selects it is the ARM64 master kconfig.
> This looks a bit artificial (and it is unclear from the Kconfig
> file why only that driver selects IORT, it looks like eg the SMMUv3
> does not have the same dependency - there is also the SMMUv3 perf
> driver to consider).
SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
dependency and not put in the places that directly need it.
"perf driver" ? There is a bunch of GIC stuff that uses this too but I
don't know if it compile tests.
> Maybe we can move IORT code into drivers/acpi and add a silent config
> option there with a dependency on ARM64 || COMPILE_TEST.
That seems pretty weird to me, this is the right way to approach it,
IMHO. Making an entire directory condition is pretty incompatible with
COMPILE_TEST as a philosophy.
> Don't know but at least it is clearer. As for the benefits of compile
> testing IORT code - yes the previous patch is a warning to fix but
> I am not so sure about the actual benefits.
IMHO COMPILE_TEST is an inherently good thing. It makes development
easier for everyone because you have a less fractured code base to
work with.
Jason
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-29 19:12 ` Jason Gunthorpe
@ 2023-11-30 11:12 ` Lorenzo Pieralisi
2023-11-30 12:21 ` Jason Gunthorpe
0 siblings, 1 reply; 30+ messages in thread
From: Lorenzo Pieralisi @ 2023-11-30 11:12 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-hyperv, Karol Herbst, Rafael J. Wysocki, Catalin Marinas,
Jerry Snitselaar, dri-devel, patches, Laxman Dewangan,
Hanjun Guo, linux-riscv, K. Y. Srinivasan, Frank Rowand,
Christoph Hellwig, Alyssa Rosenzweig, Marek Szyprowski, Wei Liu,
Joerg Roedel, Rafael J. Wysocki, Dexuan Cui, Russell King,
Jon Hunter, linux-acpi, iommu, Danilo Krummrich, nouveau,
linux-snps-arc, Len Brown, devicetree, Albert Ou,
Suravee Suthikulpanit, Will Deacon, Sven Peter, Haiyang Zhang,
Vineet Gupta, Rob Herring, Moritz Fischer, Paul Walmsley,
linux-tegra, linux-arm-kernel, Vinod Koul, Thomas Bogendoerfer,
Robin Murphy, Hector Martin, linux-mips, Krzysztof Kozlowski,
Thierry Reding, Palmer Dabbelt, asahi, Sudeep Holla, dmaengine,
David Woodhouse, Lu Baolu
On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
>
> > I don't think it should be done this way. Is the goal compile testing
> > IORT code ?
>
> Yes
>
> > If so, why are we forcing it through the SMMU (only because
> > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
>
> Because something needs to select it, and SMMU is one of the places
> that are implicitly using it.
>
> It isn't (and shouldn't be) a user selectable kconfig. Currently the
> only thing that selects it is the ARM64 master kconfig.
I never said it should be a user selectable kconfig. I said that
I don't like using the SMMU entry (only) to select it just because
that entry allows COMPILE_TEST.
> > This looks a bit artificial (and it is unclear from the Kconfig
> > file why only that driver selects IORT, it looks like eg the SMMUv3
> > does not have the same dependency - there is also the SMMUv3 perf
> > driver to consider).
>
> SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> dependency and not put in the places that directly need it.
Because IORT is used by few ARM64 system IPs (that are enabled by
default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).
> "perf driver" ? There is a bunch of GIC stuff that uses this too but I
> don't know if it compile tests.
"SMMUv3 perf driver" drivers/perf/arm_smmuv3_pmu.c
> > Maybe we can move IORT code into drivers/acpi and add a silent config
> > option there with a dependency on ARM64 || COMPILE_TEST.
>
> That seems pretty weird to me, this is the right way to approach it,
> IMHO. Making an entire directory condition is pretty incompatible with
> COMPILE_TEST as a philosophy.
That's not what I was suggesting. I was suggesting to move iort.c (or
some portions of it) into drivers/acpi if we care enough to compile test
it on arches !ARM64.
It is also weird to have a file in drivers/acpi/arm64 that you want
to compile test on other arches IMO (and I don't think it is very useful
to compile test it either).
> > Don't know but at least it is clearer. As for the benefits of compile
> > testing IORT code - yes the previous patch is a warning to fix but
> > I am not so sure about the actual benefits.
>
> IMHO COMPILE_TEST is an inherently good thing. It makes development
> easier for everyone because you have a less fractured code base to
> work with.
I am talking about IORT code, not COMPILE_TEST as a whole.
I am not sure what "less fractured" means in this context.
Anyway - it is not a big deal either way but I don't like selecting
ACPI_IORT only on kconfig entries that allow COMPILE_TEST to implicitly
compile test it so *if* we want to do it we will have to do it
differently.
Thanks,
Lorenzo
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-30 11:12 ` Lorenzo Pieralisi
@ 2023-11-30 12:21 ` Jason Gunthorpe
0 siblings, 0 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-30 12:21 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: linux-hyperv, Karol Herbst, Rafael J. Wysocki, Catalin Marinas,
Jerry Snitselaar, dri-devel, patches, Laxman Dewangan,
Hanjun Guo, linux-riscv, K. Y. Srinivasan, Frank Rowand,
Christoph Hellwig, Alyssa Rosenzweig, Marek Szyprowski, Wei Liu,
Joerg Roedel, Rafael J. Wysocki, Dexuan Cui, Russell King,
Jon Hunter, linux-acpi, iommu, Danilo Krummrich, nouveau,
linux-snps-arc, Len Brown, devicetree, Albert Ou,
Suravee Suthikulpanit, Will Deacon, Sven Peter, Haiyang Zhang,
Vineet Gupta, Rob Herring, Moritz Fischer, Paul Walmsley,
linux-tegra, linux-arm-kernel, Vinod Koul, Thomas Bogendoerfer,
Robin Murphy, Hector Martin, linux-mips, Krzysztof Kozlowski,
Thierry Reding, Palmer Dabbelt, asahi, Sudeep Holla, dmaengine,
David Woodhouse, Lu Baolu
On Thu, Nov 30, 2023 at 12:12:26PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Nov 29, 2023 at 03:12:40PM -0400, Jason Gunthorpe wrote:
> > On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote:
> >
> > > I don't think it should be done this way. Is the goal compile testing
> > > IORT code ?
> >
> > Yes
> >
> > > If so, why are we forcing it through the SMMU (only because
> > > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ?
> >
> > Because something needs to select it, and SMMU is one of the places
> > that are implicitly using it.
> >
> > It isn't (and shouldn't be) a user selectable kconfig. Currently the
> > only thing that selects it is the ARM64 master kconfig.
>
> I never said it should be a user selectable kconfig. I said that
> I don't like using the SMMU entry (only) to select it just because
> that entry allows COMPILE_TEST.
So you would like each of the drivers that use it to select it?
> > SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity
> > through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig
> > dependency and not put in the places that directly need it.
>
> Because IORT is used by few ARM64 system IPs (that are enabled by
> default, eg GIC), it makes sense to have a generic ARM64 select (if ACPI).
IMHO that is not a good way to use kconfig, it is obfuscating and
doesn't support things like COMPILE_TEST.
> > > Maybe we can move IORT code into drivers/acpi and add a silent config
> > > option there with a dependency on ARM64 || COMPILE_TEST.
> >
> > That seems pretty weird to me, this is the right way to approach it,
> > IMHO. Making an entire directory condition is pretty incompatible with
> > COMPILE_TEST as a philosophy.
>
> That's not what I was suggesting. I was suggesting to move iort.c (or
> some portions of it) into drivers/acpi if we care enough to compile test
> it on arches !ARM64.
>
> It is also weird to have a file in drivers/acpi/arm64 that you want
> to compile test on other arches IMO (and I don't think it is very useful
> to compile test it either).
Why? Just because the directory is named "arm64" doesn't mean it
should be excluded from COMPILE_TEST. arch/arm64 yes, but not random
directories in the driver tree.
Stuff under drivers/ should strive to get 100% COMPILE_TEST coverage
as much as practical. This makes everyone else's life easier.
Jason
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-29 0:48 ` [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT Jason Gunthorpe
2023-11-29 6:20 ` Moritz Fischer
2023-11-29 12:55 ` Lorenzo Pieralisi
@ 2023-11-30 14:10 ` Robin Murphy
2023-11-30 15:36 ` Jason Gunthorpe
2 siblings, 1 reply; 30+ messages in thread
From: Robin Murphy @ 2023-11-30 14:10 UTC (permalink / raw)
To: Jason Gunthorpe, David Airlie, Alyssa Rosenzweig, Albert Ou,
asahi, Catalin Marinas, Danilo Krummrich, Daniel Vetter,
Dexuan Cui, devicetree, dmaengine, dri-devel, David Woodhouse,
Frank Rowand, Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter,
Joerg Roedel, Karol Herbst, Krzysztof Kozlowski,
K. Y. Srinivasan, Laxman Dewangan, Len Brown, linux-acpi,
linux-arm-kernel, linux-hyperv, linux-mips, linux-riscv,
linux-snps-arc, linux-tegra, Russell King, Lorenzo Pieralisi,
Lyude Paul, Marek Szyprowski, nouveau, Palmer Dabbelt,
Paul Walmsley, Rafael J. Wysocki, Rob Herring, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon
Cc: Lu Baolu, Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On 29/11/2023 12:48 am, Jason Gunthorpe wrote:
> The arm-smmu driver can COMPILE_TEST on x86, so expand this to also
> enable the IORT code so it can be COMPILE_TEST'd too.
>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/acpi/Kconfig | 2 --
> drivers/acpi/Makefile | 2 +-
> drivers/acpi/arm64/Kconfig | 1 +
> drivers/acpi/arm64/Makefile | 2 +-
> drivers/iommu/Kconfig | 1 +
> 5 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index f819e760ff195a..3b7f77b227d13a 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -541,9 +541,7 @@ config ACPI_PFRUT
> To compile the drivers as modules, choose M here:
> the modules will be called pfr_update and pfr_telemetry.
>
> -if ARM64
> source "drivers/acpi/arm64/Kconfig"
> -endif
>
> config ACPI_PPTT
> bool
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index eaa09bf52f1760..4e77ae37b80726 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -127,7 +127,7 @@ obj-y += pmic/
> video-objs += acpi_video.o video_detect.o
> obj-y += dptf/
>
> -obj-$(CONFIG_ARM64) += arm64/
> +obj-y += arm64/
>
> obj-$(CONFIG_ACPI_VIOT) += viot.o
>
> diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
> index b3ed6212244c1e..537d49d8ace69e 100644
> --- a/drivers/acpi/arm64/Kconfig
> +++ b/drivers/acpi/arm64/Kconfig
> @@ -11,6 +11,7 @@ config ACPI_GTDT
>
> config ACPI_AGDI
> bool "Arm Generic Diagnostic Dump and Reset Device Interface"
> + depends on ARM64
> depends on ARM_SDE_INTERFACE
> help
> Arm Generic Diagnostic Dump and Reset Device Interface (AGDI) is
> diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
> index 143debc1ba4a9d..71d0e635599390 100644
> --- a/drivers/acpi/arm64/Makefile
> +++ b/drivers/acpi/arm64/Makefile
> @@ -4,4 +4,4 @@ obj-$(CONFIG_ACPI_IORT) += iort.o
> obj-$(CONFIG_ACPI_GTDT) += gtdt.o
> obj-$(CONFIG_ACPI_APMT) += apmt.o
> obj-$(CONFIG_ARM_AMBA) += amba.o
> -obj-y += dma.o init.o
> +obj-$(CONFIG_ARM64) += dma.o init.o
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7673bb82945b6c..309378e76a9bc9 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -318,6 +318,7 @@ config ARM_SMMU
> select IOMMU_API
> select IOMMU_IO_PGTABLE_LPAE
> select ARM_DMA_USE_IOMMU if ARM
> + select ACPI_IORT if ACPI
This is incomplete. If you want the driver to be responsible for
enabling its own probing mechanisms then you need to select OF and ACPI
too. And all the other drivers which probe from IORT should surely also
select ACPI_IORT, and thus ACPI as well. And maybe the PCI core should
as well because there are general properties of PCI host bridges and
devices described in there?
But of course that's clearly backwards nonsense, because drivers do not
and should not do that, so this change is not appropriate either. The
IORT code may not be *functionally* arm64-specific, but logically it
very much is - it serves a specification which is tied to the Arm
architecture and describes Arm-architecture-specific concepts, within
the wider context of ACPI on Arm itself only supporting AArch64, and not
AArch32. It's also not like it's driver code that someone might use as
an example and copy to a similar driver which could then run on
different architectures where a latent theoretical bug becomes real.
There's really no practical value to be had from compile-testing IORT.
Thanks,
Robin.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 10/10] ACPI: IORT: Allow COMPILE_TEST of IORT
2023-11-30 14:10 ` Robin Murphy
@ 2023-11-30 15:36 ` Jason Gunthorpe
0 siblings, 0 replies; 30+ messages in thread
From: Jason Gunthorpe @ 2023-11-30 15:36 UTC (permalink / raw)
To: Robin Murphy
Cc: David Airlie, Alyssa Rosenzweig, Albert Ou, asahi,
Catalin Marinas, Danilo Krummrich, Daniel Vetter, Dexuan Cui,
devicetree, dmaengine, dri-devel, David Woodhouse, Frank Rowand,
Hanjun Guo, Haiyang Zhang, iommu, Jon Hunter, Joerg Roedel,
Karol Herbst, Krzysztof Kozlowski, K. Y. Srinivasan,
Laxman Dewangan, Len Brown, linux-acpi, linux-arm-kernel,
linux-hyperv, linux-mips, linux-riscv, linux-snps-arc,
linux-tegra, Russell King, Lorenzo Pieralisi, Lyude Paul,
Marek Szyprowski, nouveau, Palmer Dabbelt, Paul Walmsley,
Rafael J. Wysocki, Rob Herring, Sudeep Holla,
Suravee Suthikulpanit, Sven Peter, Thomas Bogendoerfer,
Vineet Gupta, Vinod Koul, Wei Liu, Will Deacon, Lu Baolu,
Christoph Hellwig, Jerry Snitselaar, Hector Martin,
Moritz Fischer, patches, Rafael J. Wysocki, Rob Herring,
Thierry Reding
On Thu, Nov 30, 2023 at 02:10:48PM +0000, Robin Murphy wrote:
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 7673bb82945b6c..309378e76a9bc9 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -318,6 +318,7 @@ config ARM_SMMU
> > select IOMMU_API
> > select IOMMU_IO_PGTABLE_LPAE
> > select ARM_DMA_USE_IOMMU if ARM
> > + select ACPI_IORT if ACPI
>
> This is incomplete. If you want the driver to be responsible for enabling
> its own probing mechanisms then you need to select OF and ACPI too.
Well, yes, we do have that minor issue today that drivers can be
compiled without any way to parse any FW and are thus completely
useless.
Certainly one could make the case this should be
depends on OF || ACPI
select ACPI_IORT if ACPI
And similar in other drivers so they have the minimum dependencies to
actually be able to work. This would be the correct way to use
kconfig.
But who cares? I'm not trying to fix everything here, I'm trying to
allow COMPILE_TEST for more sub components of this one driver.
> And all the other drivers which probe from IORT should surely also
> select ACPI_IORT, and thus ACPI as well. And maybe the PCI core
> should as well because there are general properties of PCI host
> bridges and devices described in there?
Now you are just arguring to an absurdity.
> But of course that's clearly backwards nonsense, because drivers do not and
> should not do that, so this change is not appropriate either.
This patch is about COMPILE_TEST.
> theoretical bug becomes real. There's really no practical value to be had
> from compile-testing IORT.
COMPILE_TEST is to make it easier to maintain the kernel code by
reducing the neccessary combinations required to get complete compile
coverage. 100% compile test is a laudible goal on its own.
I have no idea what you are talking about with "no practical value"
just because you don't use COMPILE_TEST doesn't mean it has "no
practical value". It exists, people like me use, we can make it
better. Why is this even a point of debate? :(
Jason
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 30+ messages in thread