From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1A211C433F5 for ; Tue, 17 May 2022 14:12:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C7B03405C8; Tue, 17 May 2022 14:12:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j4VKjVabMkQ; Tue, 17 May 2022 14:12:27 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id F13F54051F; Tue, 17 May 2022 14:12:26 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id C1674C0039; Tue, 17 May 2022 14:12:26 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1DB13C002D for ; Tue, 17 May 2022 14:12:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0BD5D60D72 for ; Tue, 17 May 2022 14:12:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm7OJLDoxTN3 for ; Tue, 17 May 2022 14:12:23 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp3.osuosl.org (Postfix) with ESMTP id 93A90607C1 for ; Tue, 17 May 2022 14:12:23 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C8B2B1042; Tue, 17 May 2022 07:12:22 -0700 (PDT) Received: from [10.57.82.55] (unknown [10.57.82.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 02C113F718; Tue, 17 May 2022 07:12:20 -0700 (PDT) Message-ID: <16fb07d9-28d8-5c73-1eb5-ec13544d22e5@arm.com> Date: Tue, 17 May 2022 15:12:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 2/8] iommu: mtk_iommu: Lookup phandle to retrieve syscon to infracfg Content-Language: en-GB To: AngeloGioacchino Del Regno , yong.wu@mediatek.com References: <20220517132107.195932-1-angelogioacchino.delregno@collabora.com> <20220517132107.195932-3-angelogioacchino.delregno@collabora.com> From: Robin Murphy In-Reply-To: <20220517132107.195932-3-angelogioacchino.delregno@collabora.com> Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, robh+dt@kernel.org, linux-mediatek@lists.infradead.org, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, will@kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2022-05-17 14:21, AngeloGioacchino Del Regno wrote: > This driver will get support for more SoCs and the list of infracfg > compatibles is expected to grow: in order to prevent getting this > situation out of control and see a long list of compatible strings, > add support to retrieve a handle to infracfg's regmap through a > new "mediatek,infracfg" phandle. > > In order to keep retrocompatibility with older devicetrees, the old > way is kept in place, but also a dev_warn() was added to advertise > this change in hope that the user will see it and eventually update > the devicetree if this is possible. > > Signed-off-by: AngeloGioacchino Del Regno > --- > drivers/iommu/mtk_iommu.c | 40 +++++++++++++++++++++++++-------------- > 1 file changed, 26 insertions(+), 14 deletions(-) > > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c > index 71b2ace74cd6..cfaaa98d2b50 100644 > --- a/drivers/iommu/mtk_iommu.c > +++ b/drivers/iommu/mtk_iommu.c > @@ -1134,22 +1134,34 @@ static int mtk_iommu_probe(struct platform_device *pdev) > data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN); > > if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) { > - switch (data->plat_data->m4u_plat) { > - case M4U_MT2712: > - p = "mediatek,mt2712-infracfg"; > - break; > - case M4U_MT8173: > - p = "mediatek,mt8173-infracfg"; > - break; > - default: > - p = NULL; > + infracfg = syscon_regmap_lookup_by_phandle(dev->of_node, "mediatek,infracfg"); > + if (IS_ERR(infracfg)) { > + dev_warn(dev, "Cannot find phandle to mediatek,infracfg:" > + " Please update your devicetree.\n"); Is this really a dev_warn-level problem? There's no functional impact, given that we can't stop supporting the original binding any time soon, if ever, so I suspect this is more likely to just annoy users and CI systems than effect any significant change. > + /* > + * Legacy devicetrees will not specify a phandle to > + * mediatek,infracfg: in that case, we use the older > + * way to retrieve a syscon to infra. > + * > + * This is for retrocompatibility purposes only, hence > + * no more compatibles shall be added to this. > + */ > + switch (data->plat_data->m4u_plat) { > + case M4U_MT2712: > + p = "mediatek,mt2712-infracfg"; > + break; > + case M4U_MT8173: > + p = "mediatek,mt8173-infracfg"; > + break; > + default: > + p = NULL; > + } > + > + infracfg = syscon_regmap_lookup_by_compatible(p); Would it not make sense to punt this over to the same mechanism as for pericfg, such that it simplifies down to something like: if (IS_ERR(infracfg) && plat_data->infracfg) { infracfg = syscon_regmap_lookup_by_compatible(plat_data->infracfg); ... } ? TBH if we're still going to have a load of per-SoC data in the driver anyway then I don't see that we really gain much by delegating one aspect of it to DT, but meh. I would note that with the phandle approach, you still need some *other* flag in the driver to know whether a phandle is expected to be present or not, whereas a NULL vs. non-NULL string is at least neatly self-describing. Robin. > + if (IS_ERR(infracfg)) > + return PTR_ERR(infracfg); > } > > - infracfg = syscon_regmap_lookup_by_compatible(p); > - > - if (IS_ERR(infracfg)) > - return PTR_ERR(infracfg); > - > ret = regmap_read(infracfg, REG_INFRA_MISC, &val); > if (ret) > return ret; _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu