On 2022-07-11 13:27, Krzysztof Kozlowski wrote:
On 08/07/2022 15:18, Sam Protsenko wrote:
On Sun, 3 Jul 2022 at 21:50, Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
On 02/07/2022 23:37, Sam Protsenko wrote:
SysMMU v5+ supports 36 bit physical address space. Set corresponding DMA
mask to avoid falling back to SWTLBIO usage in dma_map_single() because
of failed dma_capable() check.
The original code for this fix was suggested by Marek.
Originally-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
This is some tip specific tag, I don't think checkpatch allows it.
Either use suggesgted-by or co-developed-by + SoB.
Yes, checkpatch is swearing at that line, though I encountered that
tag mentioning somewhere in Documentation. Will rework it in v2.
Yes, in tip. It did not go outside of tip.
Signed-off-by: Sam Protsenko <semen.protsenko@xxxxxxxxxx>
---
drivers/iommu/exynos-iommu.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 71f2018e23fe..28f8c8d93aa3 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -647,6 +647,14 @@ static int exynos_sysmmu_probe(struct platform_device *pdev)
}
}
+ if (MMU_MAJ_VER(data->version) >= 5) {
+ ret = dma_set_mask(dev, DMA_BIT_MASK(36));
+ if (ret) {
+ dev_err(dev, "Unable to set DMA mask: %d\n", ret);
Missing cleanup: iommu_device_unregister
and probably also: iommu_device_sysfs_remove
Right. Also the correct cleanup should be added for failing
iommu_device_register() case, above of the quoted code. Will do that
in v2, thanks.
Another thing is that "remove" method is missing. But guess I'll get
to it later, when adding modularization support for this driver.
remove is independent of modules, so it should be here already.
.suppress_bind_attrs is set in the driver, so a .remove method on its
own would be dead code, since there's no way for it to be called. We can
permit module unloading since the module itself can be reference counted
(which in practice usually means that unloading will be denied). However
that's not the case for driver binding itself, so it's better not to
even pretend that removing an IOMMU's driver while other drivers are
using it (usually via DMA ops without even realising) is going to have
anything other than catastrophic results.
Thanks,
Robin.
