Re: [PATCH v12 5/7] iommu/mediatek: Add MT8188 IOMMU Support | linux-arm-kernel

quoted

On Thu, Aug 17, 2023 at 4:03 PM Yong Wu (吴勇) [off-list ref] wrote:
On Mon, 2023-08-14 at 16:21 +0800, Chen-Yu Tsai wrote:
External email : Please do not click links or open attachments until
you have verified the sender or the content.
 On Mon, Aug 14, 2023 at 3:14 PM Yong Wu (吴勇) [off-list ref]
wrote:
On Fri, 2023-08-11 at 11:30 +0800, Chen-Yu Tsai wrote:
External email : Please do not click links or open attachments
until
you have verified the sender or the content.
 On Thu, Aug 10, 2023 at 8:23 PM Yong Wu (吴勇) <
Yong.Wu@mediatek.com>
wrote:
On Tue, 2023-08-08 at 17:53 +0800, Chen-Yu Tsai wrote:
External email : Please do not click links or open
attachments
until
you have verified the sender or the content.
 On Fri, Jun 2, 2023 at 5:04 PM Yong Wu <yong.wu@mediatek.com

wrote:
From: "Chengci.Xu" <redacted>

MT8188 has 3 IOMMU, containing 2 MM IOMMUs, one is for vdo,
the
other
is for vpp. and 1 INFRA IOMMU.

Signed-off-by: Chengci.Xu <redacted>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <
angelogioacchino.delregno@collabora.com>
---
 drivers/iommu/mtk_iommu.c | 49
+++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/drivers/iommu/mtk_iommu.c
b/drivers/iommu/mtk_iommu.c
index 9c89cf894a4d..5c66af0c45a8 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -170,6 +170,7 @@ enum mtk_iommu_plat {
        M4U_MT8173,
        M4U_MT8183,
        M4U_MT8186,
+       M4U_MT8188,
        M4U_MT8192,
        M4U_MT8195,
        M4U_MT8365,
@@ -1593,6 +1594,51 @@ static const struct
mtk_iommu_plat_data
mt8186_data_mm = {
        .iova_region_larb_msk = mt8186_larb_region_msk,
 };

+static const struct mtk_iommu_plat_data mt8188_data_infra
= {
+       .m4u_plat         = M4U_MT8188,
+       .flags            = WR_THROT_EN | DCM_DISABLE |
STD_AXI_MODE | PM_CLK_AO |
+                           MTK_IOMMU_TYPE_INFRA |
IFA_IOMMU_PCIE_SUPPORT |
+                           PGTABLE_PA_35_EN |
CFG_IFA_MASTER_IN_ATF,

FWIW, CFG_IFA_MASTER_IN_ATF should not be tied to the
compatible
string,
but set via a DT property. The IOMMU controls are secured by
firmware.
It is not a property intrinsically tied to the hardware.
The flag CFG_IFA_MASTER_IN_ATF means the registers which
enable/disable
iommu are in the secure world. If the master like pcie want to
enable
iommu, we have to enter secure world to configure it. It should
be
HW
intrinsical, right?
If I understand correctly, this is forced by setting some
registers.
The registers are set by the firmware at boot time.
The register will be set before the masters that have the "iommus="
property probe. If the master doesn't have "iommus=" property in
its
dtsi node, this register won't be set, then its iommu will be
disabled
and it has to access continuous buffer.

So if a different firmware that doesn't set the registers is
used,
then the IOMMU is available to non-secure kernel, correct?
No. The meaning of this register is whether to enable iommu. If the
register are not set, the IOMMU for that master is disabled.
For clarity, I'm referring to PERI_MST_PROT [1], not the registers in
the
IOMMU or LARBs. So not any of the registers used in this patch.

If that register doesn't restrict access to IOMMU register space to
secure
only, then I assume it is controlled by fuses?
Thanks for the clarification. Understand this now. If that register
doesn't restrict this, the register for enabling the iommu could be
accessed in normal world.

[1]
https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/be457248c6b0a7f3c61bd95af58372938d13decd/plat/mediatek/drivers/iommu/mt8188/mtk_iommu_plat.c#93

That's why I said that it should not be tied to a particular
hardware
platform, but set using a boolean device tree property.

If on some other project there is no such security
requirement
and
the
IOMMU is opened up to non-secure world, and ATF not even
having
support
for the SMC call, this becomes unusable and hard to rectify
without
introducing a new compatible string.
Then this make sense. Sorry, I don't know if such project exist, I
guess no, right? we could add it when necessary?
I guess that works. It would be a negative property, such as
"mediatek,iommu-is-non-secure". However, since this lock down is orthogonal
to the SoC model, it would be better to model it as such from the beginning.

ChenYu

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help