| Message ID | 51d8c78e2ecc6696ac5907526580209ea6da167f.1673553587.git.robin.murphy@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iommu: Tidy up io-pgtable dependencies | expand |
On Thu, Jan 12, 2023 at 07:59:47PM +0000, Robin Murphy wrote: > drivers/iommu/Kconfig | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) Applied, thanks Robin.
Hey Robin, On Thu, Jan 12, 2023 at 07:59:47PM +0000, Robin Murphy wrote: > Some io-pgtable implementations, and thus their users too, carry a > slightly odd dependency to get around the GENERIC_ATOMIC64 version of > cmpxchg64() often failing to compile. Since this is a functional > dependency, it's a bit misleading and untidy to tie it explicitly to > COMPILE_TEST while assuming that it's also implied by the other > platform/architecture options. Make things clearer by separating these > functional dependencies into distinct statements from those controlling > visibility, and since they do look a bit non-obvious to the uninitiated, > also commenting them for good measure. > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > --- > drivers/iommu/Kconfig | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) > config IPMMU_VMSA > bool "Renesas VMSA-compatible IPMMU" > - depends on ARCH_RENESAS || (COMPILE_TEST && !GENERIC_ATOMIC64) > + depends on ARCH_RENESAS || COMPILE_TEST > + depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE > select IOMMU_API > select IOMMU_IO_PGTABLE_LPAE > select ARM_DMA_USE_IOMMU This is a fix for the broken riscv32 allmodconfig stuff that Palmer reported, right? https://lore.kernel.org/all/20221214180409.7354-1-palmer@rivosinc.com/ I did a dfn:drivers/iommu/Kconfig search on lore & saw this, but AFAICT the patch was applied to next rather than fixes. Apologies if I'm off here, I have had that report in my follow-up-on queue for a while & since Christmas happened in between I've lost track of when the build failure was introduced. Last I remember, Guo Ren sent a patch that was not to your liking, but I didn't see anything after that. Thanks, Conor.
On 2023-01-13 22:17, Conor Dooley wrote: > Hey Robin, > > On Thu, Jan 12, 2023 at 07:59:47PM +0000, Robin Murphy wrote: >> Some io-pgtable implementations, and thus their users too, carry a >> slightly odd dependency to get around the GENERIC_ATOMIC64 version of >> cmpxchg64() often failing to compile. Since this is a functional >> dependency, it's a bit misleading and untidy to tie it explicitly to >> COMPILE_TEST while assuming that it's also implied by the other >> platform/architecture options. Make things clearer by separating these >> functional dependencies into distinct statements from those controlling >> visibility, and since they do look a bit non-obvious to the uninitiated, >> also commenting them for good measure. >> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com> >> --- >> drivers/iommu/Kconfig | 18 ++++++++++++------ >> 1 file changed, 12 insertions(+), 6 deletions(-) > >> config IPMMU_VMSA >> bool "Renesas VMSA-compatible IPMMU" >> - depends on ARCH_RENESAS || (COMPILE_TEST && !GENERIC_ATOMIC64) >> + depends on ARCH_RENESAS || COMPILE_TEST >> + depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE >> select IOMMU_API >> select IOMMU_IO_PGTABLE_LPAE >> select ARM_DMA_USE_IOMMU > > This is a fix for the broken riscv32 allmodconfig stuff that Palmer > reported, right? Indirectly - that made it clear that the whole area was worth cleaning up in general, so I did this expecting to rebase it around one of the other fix patches, but none of those seem to have gone anywhere. In the meantime I guess it might now be simplest to apply Palmer's config workaround if you want something more expedient. Cheers, Robin. > https://lore.kernel.org/all/20221214180409.7354-1-palmer@rivosinc.com/ > > I did a dfn:drivers/iommu/Kconfig search on lore & saw this, but AFAICT > the patch was applied to next rather than fixes. > > Apologies if I'm off here, I have had that report in my follow-up-on > queue for a while & since Christmas happened in between I've lost track > of when the build failure was introduced. > > Last I remember, Guo Ren sent a patch that was not to your liking, but I > didn't see anything after that. > > Thanks, > Conor.
On Mon, Jan 16, 2023 at 10:56:21AM +0000, Robin Murphy wrote: > On 2023-01-13 22:17, Conor Dooley wrote: > > Hey Robin, > > > > On Thu, Jan 12, 2023 at 07:59:47PM +0000, Robin Murphy wrote: > > > Some io-pgtable implementations, and thus their users too, carry a > > > slightly odd dependency to get around the GENERIC_ATOMIC64 version of > > > cmpxchg64() often failing to compile. Since this is a functional > > > dependency, it's a bit misleading and untidy to tie it explicitly to > > > COMPILE_TEST while assuming that it's also implied by the other > > > platform/architecture options. Make things clearer by separating these > > > functional dependencies into distinct statements from those controlling > > > visibility, and since they do look a bit non-obvious to the uninitiated, > > > also commenting them for good measure. > > > > > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > > > --- > > > drivers/iommu/Kconfig | 18 ++++++++++++------ > > > 1 file changed, 12 insertions(+), 6 deletions(-) > > > > > config IPMMU_VMSA > > > bool "Renesas VMSA-compatible IPMMU" > > > - depends on ARCH_RENESAS || (COMPILE_TEST && !GENERIC_ATOMIC64) > > > + depends on ARCH_RENESAS || COMPILE_TEST > > > + depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE > > > select IOMMU_API > > > select IOMMU_IO_PGTABLE_LPAE > > > select ARM_DMA_USE_IOMMU > > > > This is a fix for the broken riscv32 allmodconfig stuff that Palmer > > reported, right? > > Indirectly - that made it clear that the whole area was worth cleaning up in > general, so I did this expecting to rebase it around one of the other fix > patches, but none of those seem to have gone anywhere. > > In the meantime I guess it might now be simplest to apply Palmer's config > workaround if you want something more expedient. I amn't too bothered about workarounds, I don't build 32-bit allmodconfig. I was hoping that an actual fix would show up, but it's clear that no-one other than Palmer does actively build it. Do you mind if I rip this part out of here & submit it standalone, since no-one seems to be bothered by the failure enough to re-submit your suggestion from the original threads? Thanks, Conor. > > https://lore.kernel.org/all/20221214180409.7354-1-palmer@rivosinc.com/ > > > > I did a dfn:drivers/iommu/Kconfig search on lore & saw this, but AFAICT > > the patch was applied to next rather than fixes. > > > > Apologies if I'm off here, I have had that report in my follow-up-on > > queue for a while & since Christmas happened in between I've lost track > > of when the build failure was introduced. > > > > Last I remember, Guo Ren sent a patch that was not to your liking, but I > > didn't see anything after that.
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 79707685d54a..889c7efd050b 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -32,7 +32,8 @@ config IOMMU_IO_PGTABLE config IOMMU_IO_PGTABLE_LPAE bool "ARMv7/v8 Long Descriptor Format" select IOMMU_IO_PGTABLE - depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64) + depends on ARM || ARM64 || COMPILE_TEST + depends on !GENERIC_ATOMIC64 # for cpmxchg64() help Enable support for the ARM long descriptor pagetable format. This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page @@ -70,7 +71,8 @@ config IOMMU_IO_PGTABLE_ARMV7S_SELFTEST config IOMMU_IO_PGTABLE_DART bool "Apple DART Formats" select IOMMU_IO_PGTABLE - depends on ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64) + depends on ARM64 || COMPILE_TEST + depends on !GENERIC_ATOMIC64 # for cpmxchg64() help Enable support for the Apple DART pagetable formats. These include the t8020 and t6000/t8110 DART formats used in Apple M1/M2 family @@ -284,7 +286,8 @@ config EXYNOS_IOMMU_DEBUG config IPMMU_VMSA bool "Renesas VMSA-compatible IPMMU" - depends on ARCH_RENESAS || (COMPILE_TEST && !GENERIC_ATOMIC64) + depends on ARCH_RENESAS || COMPILE_TEST + depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE select IOMMU_API select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU @@ -304,7 +307,8 @@ config SPAPR_TCE_IOMMU config APPLE_DART tristate "Apple DART IOMMU Support" - depends on ARCH_APPLE || (COMPILE_TEST && !GENERIC_ATOMIC64) + depends on ARCH_APPLE || COMPILE_TEST + depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_DART select IOMMU_API select IOMMU_IO_PGTABLE_DART default ARCH_APPLE @@ -319,7 +323,8 @@ config APPLE_DART # ARM IOMMU support config ARM_SMMU tristate "ARM Ltd. System MMU (SMMU) Support" - depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64) + depends on ARM64 || ARM || COMPILE_TEST + depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE select IOMMU_API select IOMMU_IO_PGTABLE_LPAE select ARM_DMA_USE_IOMMU if ARM @@ -466,7 +471,8 @@ config MTK_IOMMU_V1 config QCOM_IOMMU # Note: iommu drivers cannot (yet?) be built as modules bool "Qualcomm IOMMU Support" - depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64) + depends on ARCH_QCOM || COMPILE_TEST + depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE select QCOM_SCM select IOMMU_API select IOMMU_IO_PGTABLE_LPAE
Some io-pgtable implementations, and thus their users too, carry a slightly odd dependency to get around the GENERIC_ATOMIC64 version of cmpxchg64() often failing to compile. Since this is a functional dependency, it's a bit misleading and untidy to tie it explicitly to COMPILE_TEST while assuming that it's also implied by the other platform/architecture options. Make things clearer by separating these functional dependencies into distinct statements from those controlling visibility, and since they do look a bit non-obvious to the uninitiated, also commenting them for good measure. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- drivers/iommu/Kconfig | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-)