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 smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 3B39AC433F5 for ; Wed, 18 May 2022 18:43:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id E16CD60F1F; Wed, 18 May 2022 18:43:45 +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 V75Mof4oT_TI; Wed, 18 May 2022 18:43:45 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTPS id BC13F60F6D; Wed, 18 May 2022 18:43:44 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8FBA1C0032; Wed, 18 May 2022 18:43:44 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6AC19C002D for ; Wed, 18 May 2022 18:43:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 66D9F4102B for ; Wed, 18 May 2022 18:43:43 +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 Po0pMQiwoE7h for ; Wed, 18 May 2022 18:43:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) by smtp2.osuosl.org (Postfix) with ESMTPS id 5094840374 for ; Wed, 18 May 2022 18:43:42 +0000 (UTC) Received: by mail-oi1-f171.google.com with SMTP id i66so3713452oia.11 for ; Wed, 18 May 2022 11:43:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nSo8w7W+OSVBY2zTRn/yV76t4zc61Jk0JXEwQ0qGoEY=; b=b9X3y8l6tTklfBg1+wcKekMUkbeFnig2ERgHPSt8oPHeYNpii2N6f5tCS86VSQvxVB gFrtlsjbQoKU4q7+oyOnO/ayCcIx9sQrOEIz5TqsVta+jsOAxs1Oa2FE4N/625TbQ8am bwiDm1DeVTFJk20BmdfcAHn6XuRG1j1tRKTtYKWC9qsQX7fM0jnFLYNaYKUHe8meNTix Sta4I4WO+OvV18xkWDutjfcCJp9gD3s1RK1K/SVIgvCu7qfdXv9sdEM0nP3tQkThgcfz wacdz706vxQ+Z3RlfGskX+1RhI+FmuzMELfvpupNJrK6M29nfC/e6R2HYg+EQFvPc3tC omWQ== X-Gm-Message-State: AOAM532VD5DDufOdpJNps0UeERsQ/UJ/AKmUQBwO3/QDdveZrtp0vzMD HtZrH+j377I7kM1WrzPWaQ== X-Google-Smtp-Source: ABdhPJxURTR1dLIW0z+AO7IFoBsGn5LcndospzqQor1Bg/tjfzW1ykX2baF3rSpYYdFTb74t+ZoaaA== X-Received: by 2002:a05:6808:f8e:b0:328:a601:a425 with SMTP id o14-20020a0568080f8e00b00328a601a425mr590558oiw.253.1652899421160; Wed, 18 May 2022 11:43:41 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id q19-20020a4a8353000000b00333220959b9sm1265718oog.1.2022.05.18.11.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 11:43:40 -0700 (PDT) Received: (nullmailer pid 3669786 invoked by uid 1000); Wed, 18 May 2022 18:43:39 -0000 Date: Wed, 18 May 2022 13:43:39 -0500 From: Rob Herring To: AngeloGioacchino Del Regno Subject: Re: [PATCH 7/8] dt-bindings: iommu: mediatek: Require mediatek,infracfg for mt2712/8173 Message-ID: <20220518184339.GJ3302100-robh@kernel.org> References: <20220517132107.195932-1-angelogioacchino.delregno@collabora.com> <20220517132107.195932-8-angelogioacchino.delregno@collabora.com> <20220518014143.GA2024242-robh@kernel.org> <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, will@kernel.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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Wed, May 18, 2022 at 10:14:43AM +0200, AngeloGioacchino Del Regno wrote: > Il 18/05/22 03:41, Rob Herring ha scritto: > > On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote: > > > Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to > > > the required properties for these SoCs to deprecate the old way of > > > looking for SoC-specific infracfg compatible in the entire devicetree. > > > > Wait, what? If there's only one possible node that can match, I prefer > > the 'old way'. Until we implemented a phandle cache, searching the > > entire tree was how phandle lookups worked too, so not any better. > > > > But if this makes things more consistent, > > > > Acked-by: Rob Herring > > > Hello Rob, > > This makes things definitely more consistent, as it's done like that on > mtk-pm-domains and other mtk drivers as well. > > The main reason why this phandle is useful, here and in other drivers, is > that we're seeing a list of compatibles that is growing more and more, so > you see stuff like (mockup names warning): > > switch (some_model) > case MT1000: > p = "mediatek,mt1000-infracfg"; > break; > case MT1001: > p = "mediatek,mt1001-infracfg"; > break; > case MT1002: > p = "mediatek,mt1002-infracfg"; > break; > .....add another 20 SoCs, replicate this switch for 4/5 drivers.... This type of property is used for poking random bits in another block (that's usually a collection of random bits). These interfaces don't tend to be that stable across many SoC generations. As there's no abstraction beyond perhaps what the offset is, the client side ends up needing to know the specifics of that block anyways. If the block is that stable, then perhaps it needs a common fallback compatible. Sometimes these instances are also just places we haven't created a common subsystem for. > and this is why I want the mtk_iommu driver to also get that phandle like > some other drivers are already doing. As I said, fine. Rob _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.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 D8D35C433F5 for ; Wed, 18 May 2022 18:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9RITadcaPMT7mS0vLDvA93KSp4bFBHYyKRrdXh8CHew=; b=wnB38vmh2q4zfX rzoDYWPEEsIS4iHegAaq70POK5KFlNbjI06PRE28g++TabW0Q6qJu43qZyDpKFmUO4xWD8a450jjp bjBVksSo/hPQQI79SRjJKjWQ87sSsw/36B94BZxRU33uT7Gtw6GtK1Qp7ZZvCvs33HIWOR/4DhJHE jkNiDkGdpHvYgMzFfroSEfw3sJywFEPHx00sAwsHtXnkU6QWxuaANcm6HUJ0gZn3hPRz1+kRqMJS1 2V3LnIcDoaahlXyDDsbK6MWTxhgXTUt7tbP4Q45ixJMrmqR4u2cS42X9JwFNw+0nKF/O4PzXi/OA6 4SyT33XCOkxeO823uKVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrOeD-003TcJ-8q; Wed, 18 May 2022 18:43:49 +0000 Received: from mail-oi1-f171.google.com ([209.85.167.171]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrOe7-003TYZ-Ry; Wed, 18 May 2022 18:43:47 +0000 Received: by mail-oi1-f171.google.com with SMTP id v65so3719412oig.10; Wed, 18 May 2022 11:43:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nSo8w7W+OSVBY2zTRn/yV76t4zc61Jk0JXEwQ0qGoEY=; b=aAqP4GGtaNcm9fHQTfXcDrdjL8HyjH9WqhTqfLsC5bHp3aXIX7Nlsexxh1Po5qXkbT G3cj8ghHCAvpoFkaRPAhbJdqlVhMIlbwX3UP0nLRrCHqA2MGzG2dQk0vM8wGFISt0Uaa Rn+bImVG52OUj/lrnn7iElPpk2fLgC0tDKoN0Y0r/oPJMfyREcfXaC4qxSMicIlOIEQu XtwN9TbvP4i8hf6sq986kbPmfCnCBh/PBxkeLI/Qk9RGDyCGGZEi9HB3zBb9zimBiy0s Dorf5O+w5IPkcvfUWR7MkhacYF1mAkndpSfRWWr7jSzcxzR0FN0dvjMvHC3Z1mWKtBhk JdSw== X-Gm-Message-State: AOAM533tMoo/YRs0NKR/ucBgPfQdoqkhkTtlnU679UjMF/ifjWP8FbNX s2zWEIC+6PP4ZXzA9rgpTQ== X-Google-Smtp-Source: ABdhPJxURTR1dLIW0z+AO7IFoBsGn5LcndospzqQor1Bg/tjfzW1ykX2baF3rSpYYdFTb74t+ZoaaA== X-Received: by 2002:a05:6808:f8e:b0:328:a601:a425 with SMTP id o14-20020a0568080f8e00b00328a601a425mr590558oiw.253.1652899421160; Wed, 18 May 2022 11:43:41 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id q19-20020a4a8353000000b00333220959b9sm1265718oog.1.2022.05.18.11.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 11:43:40 -0700 (PDT) Received: (nullmailer pid 3669786 invoked by uid 1000); Wed, 18 May 2022 18:43:39 -0000 Date: Wed, 18 May 2022 13:43:39 -0500 From: Rob Herring To: AngeloGioacchino Del Regno Cc: yong.wu@mediatek.com, joro@8bytes.org, will@kernel.org, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, iommu@lists.linux-foundation.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 7/8] dt-bindings: iommu: mediatek: Require mediatek,infracfg for mt2712/8173 Message-ID: <20220518184339.GJ3302100-robh@kernel.org> References: <20220517132107.195932-1-angelogioacchino.delregno@collabora.com> <20220517132107.195932-8-angelogioacchino.delregno@collabora.com> <20220518014143.GA2024242-robh@kernel.org> <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220518_114343_956025_4B5EE739 X-CRM114-Status: GOOD ( 22.88 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Wed, May 18, 2022 at 10:14:43AM +0200, AngeloGioacchino Del Regno wrote: > Il 18/05/22 03:41, Rob Herring ha scritto: > > On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote: > > > Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to > > > the required properties for these SoCs to deprecate the old way of > > > looking for SoC-specific infracfg compatible in the entire devicetree. > > > > Wait, what? If there's only one possible node that can match, I prefer > > the 'old way'. Until we implemented a phandle cache, searching the > > entire tree was how phandle lookups worked too, so not any better. > > > > But if this makes things more consistent, > > > > Acked-by: Rob Herring > > > Hello Rob, > > This makes things definitely more consistent, as it's done like that on > mtk-pm-domains and other mtk drivers as well. > > The main reason why this phandle is useful, here and in other drivers, is > that we're seeing a list of compatibles that is growing more and more, so > you see stuff like (mockup names warning): > > switch (some_model) > case MT1000: > p = "mediatek,mt1000-infracfg"; > break; > case MT1001: > p = "mediatek,mt1001-infracfg"; > break; > case MT1002: > p = "mediatek,mt1002-infracfg"; > break; > .....add another 20 SoCs, replicate this switch for 4/5 drivers.... This type of property is used for poking random bits in another block (that's usually a collection of random bits). These interfaces don't tend to be that stable across many SoC generations. As there's no abstraction beyond perhaps what the offset is, the client side ends up needing to know the specifics of that block anyways. If the block is that stable, then perhaps it needs a common fallback compatible. Sometimes these instances are also just places we haven't created a common subsystem for. > and this is why I want the mtk_iommu driver to also get that phandle like > some other drivers are already doing. As I said, fine. Rob _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.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 9D2CDC433F5 for ; Wed, 18 May 2022 18:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=X5aPl/5UMuI4eCZKJsKnwyGIXWZ0w542viKX66MCYgo=; b=C0x1bzfVwYtNhR tKPoG8LdRcBkaG0/LU2BYRSSIUtQAJBoW8ZODvsCn+7JzGzLQ9PmI9hsMGPD6KAegNBQ++bGbaWCi Ajk20q/qy6y43xFFAAHv2Mv2i4A5thjKPiyuVVY7xsA39XHEzYP6T/lKOpTcrQwqbOJSlcnmBypmg 9oqsnq3RwgnaoOzjC7BKtti8UGQ7bX0r7ToonHJu+LiYClspWDLOqGkzAwTUbsdj71BMd+o/ALdgf C+WjQjSXdDbwMy8j4TOkiTfaK4leCi9k1WzzQUF8LXKoBlgOQqHTDdJaGGIyM15DJXiP4Thl7dP/B KBDVvsZUWOrf/umfXj3Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrOeE-003TcY-GB; Wed, 18 May 2022 18:43:50 +0000 Received: from mail-oi1-f171.google.com ([209.85.167.171]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrOe7-003TYZ-Ry; Wed, 18 May 2022 18:43:47 +0000 Received: by mail-oi1-f171.google.com with SMTP id v65so3719412oig.10; Wed, 18 May 2022 11:43:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nSo8w7W+OSVBY2zTRn/yV76t4zc61Jk0JXEwQ0qGoEY=; b=aAqP4GGtaNcm9fHQTfXcDrdjL8HyjH9WqhTqfLsC5bHp3aXIX7Nlsexxh1Po5qXkbT G3cj8ghHCAvpoFkaRPAhbJdqlVhMIlbwX3UP0nLRrCHqA2MGzG2dQk0vM8wGFISt0Uaa Rn+bImVG52OUj/lrnn7iElPpk2fLgC0tDKoN0Y0r/oPJMfyREcfXaC4qxSMicIlOIEQu XtwN9TbvP4i8hf6sq986kbPmfCnCBh/PBxkeLI/Qk9RGDyCGGZEi9HB3zBb9zimBiy0s Dorf5O+w5IPkcvfUWR7MkhacYF1mAkndpSfRWWr7jSzcxzR0FN0dvjMvHC3Z1mWKtBhk JdSw== X-Gm-Message-State: AOAM533tMoo/YRs0NKR/ucBgPfQdoqkhkTtlnU679UjMF/ifjWP8FbNX s2zWEIC+6PP4ZXzA9rgpTQ== X-Google-Smtp-Source: ABdhPJxURTR1dLIW0z+AO7IFoBsGn5LcndospzqQor1Bg/tjfzW1ykX2baF3rSpYYdFTb74t+ZoaaA== X-Received: by 2002:a05:6808:f8e:b0:328:a601:a425 with SMTP id o14-20020a0568080f8e00b00328a601a425mr590558oiw.253.1652899421160; Wed, 18 May 2022 11:43:41 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id q19-20020a4a8353000000b00333220959b9sm1265718oog.1.2022.05.18.11.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 11:43:40 -0700 (PDT) Received: (nullmailer pid 3669786 invoked by uid 1000); Wed, 18 May 2022 18:43:39 -0000 Date: Wed, 18 May 2022 13:43:39 -0500 From: Rob Herring To: AngeloGioacchino Del Regno Cc: yong.wu@mediatek.com, joro@8bytes.org, will@kernel.org, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, iommu@lists.linux-foundation.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 7/8] dt-bindings: iommu: mediatek: Require mediatek,infracfg for mt2712/8173 Message-ID: <20220518184339.GJ3302100-robh@kernel.org> References: <20220517132107.195932-1-angelogioacchino.delregno@collabora.com> <20220517132107.195932-8-angelogioacchino.delregno@collabora.com> <20220518014143.GA2024242-robh@kernel.org> <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220518_114343_956025_4B5EE739 X-CRM114-Status: GOOD ( 22.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, May 18, 2022 at 10:14:43AM +0200, AngeloGioacchino Del Regno wrote: > Il 18/05/22 03:41, Rob Herring ha scritto: > > On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote: > > > Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to > > > the required properties for these SoCs to deprecate the old way of > > > looking for SoC-specific infracfg compatible in the entire devicetree. > > > > Wait, what? If there's only one possible node that can match, I prefer > > the 'old way'. Until we implemented a phandle cache, searching the > > entire tree was how phandle lookups worked too, so not any better. > > > > But if this makes things more consistent, > > > > Acked-by: Rob Herring > > > Hello Rob, > > This makes things definitely more consistent, as it's done like that on > mtk-pm-domains and other mtk drivers as well. > > The main reason why this phandle is useful, here and in other drivers, is > that we're seeing a list of compatibles that is growing more and more, so > you see stuff like (mockup names warning): > > switch (some_model) > case MT1000: > p = "mediatek,mt1000-infracfg"; > break; > case MT1001: > p = "mediatek,mt1001-infracfg"; > break; > case MT1002: > p = "mediatek,mt1002-infracfg"; > break; > .....add another 20 SoCs, replicate this switch for 4/5 drivers.... This type of property is used for poking random bits in another block (that's usually a collection of random bits). These interfaces don't tend to be that stable across many SoC generations. As there's no abstraction beyond perhaps what the offset is, the client side ends up needing to know the specifics of that block anyways. If the block is that stable, then perhaps it needs a common fallback compatible. Sometimes these instances are also just places we haven't created a common subsystem for. > and this is why I want the mtk_iommu driver to also get that phandle like > some other drivers are already doing. As I said, fine. Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68A83C433EF for ; Wed, 18 May 2022 18:43:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241520AbiERSnn (ORCPT ); Wed, 18 May 2022 14:43:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241507AbiERSnm (ORCPT ); Wed, 18 May 2022 14:43:42 -0400 Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC73F229FC7; Wed, 18 May 2022 11:43:41 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id m25so3769966oih.2; Wed, 18 May 2022 11:43:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nSo8w7W+OSVBY2zTRn/yV76t4zc61Jk0JXEwQ0qGoEY=; b=SHV6PYnlUN8AMBsiC0jO/VprGHwi5z6Rsr6YCjmXu+QooHFk2VlaFmk04Tq1CRJ6x1 iFTPVQPMy3UnBLuPZUztLFghIsiOY9PiI6I4O7t+JrlbLfr5y978xPCLhXQXlng2mWs2 0t5txWnINGr2d15/cvuq6JIackbAW760mJu5yDY/SSNAurAGTSdzyFoMNEmncz3NAiyI jmt0XwTNw5N6/mrrgwB+ziZ2n0aYgPGGCs++43hMaXxZRePGGNabEV6sdx5VWl0DQW9W OAGuJFyr0mD/uWv2PMklt5p0tyyovgaUeiKL217hRoP148tWx2Hf/SmcRrrUnTMBbNym iMAQ== X-Gm-Message-State: AOAM531Iwcrt2/njF/7LmLIFoInmy+KG36hoPFdCj/X8vBIjqGYlcC4b osU/GNHXlXLpDoBmvfBBWQ== X-Google-Smtp-Source: ABdhPJxURTR1dLIW0z+AO7IFoBsGn5LcndospzqQor1Bg/tjfzW1ykX2baF3rSpYYdFTb74t+ZoaaA== X-Received: by 2002:a05:6808:f8e:b0:328:a601:a425 with SMTP id o14-20020a0568080f8e00b00328a601a425mr590558oiw.253.1652899421160; Wed, 18 May 2022 11:43:41 -0700 (PDT) Received: from robh.at.kernel.org (66-90-144-107.dyn.grandenetworks.net. [66.90.144.107]) by smtp.gmail.com with ESMTPSA id q19-20020a4a8353000000b00333220959b9sm1265718oog.1.2022.05.18.11.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 11:43:40 -0700 (PDT) Received: (nullmailer pid 3669786 invoked by uid 1000); Wed, 18 May 2022 18:43:39 -0000 Date: Wed, 18 May 2022 13:43:39 -0500 From: Rob Herring To: AngeloGioacchino Del Regno Cc: yong.wu@mediatek.com, joro@8bytes.org, will@kernel.org, krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com, iommu@lists.linux-foundation.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 7/8] dt-bindings: iommu: mediatek: Require mediatek,infracfg for mt2712/8173 Message-ID: <20220518184339.GJ3302100-robh@kernel.org> References: <20220517132107.195932-1-angelogioacchino.delregno@collabora.com> <20220517132107.195932-8-angelogioacchino.delregno@collabora.com> <20220518014143.GA2024242-robh@kernel.org> <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ed63c3a-ec47-5801-ab89-b7d1a597c0da@collabora.com> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, May 18, 2022 at 10:14:43AM +0200, AngeloGioacchino Del Regno wrote: > Il 18/05/22 03:41, Rob Herring ha scritto: > > On Tue, May 17, 2022 at 03:21:06PM +0200, AngeloGioacchino Del Regno wrote: > > > Both MT2712 and MT8173 got a mediatek,infracfg phandle: add that to > > > the required properties for these SoCs to deprecate the old way of > > > looking for SoC-specific infracfg compatible in the entire devicetree. > > > > Wait, what? If there's only one possible node that can match, I prefer > > the 'old way'. Until we implemented a phandle cache, searching the > > entire tree was how phandle lookups worked too, so not any better. > > > > But if this makes things more consistent, > > > > Acked-by: Rob Herring > > > Hello Rob, > > This makes things definitely more consistent, as it's done like that on > mtk-pm-domains and other mtk drivers as well. > > The main reason why this phandle is useful, here and in other drivers, is > that we're seeing a list of compatibles that is growing more and more, so > you see stuff like (mockup names warning): > > switch (some_model) > case MT1000: > p = "mediatek,mt1000-infracfg"; > break; > case MT1001: > p = "mediatek,mt1001-infracfg"; > break; > case MT1002: > p = "mediatek,mt1002-infracfg"; > break; > .....add another 20 SoCs, replicate this switch for 4/5 drivers.... This type of property is used for poking random bits in another block (that's usually a collection of random bits). These interfaces don't tend to be that stable across many SoC generations. As there's no abstraction beyond perhaps what the offset is, the client side ends up needing to know the specifics of that block anyways. If the block is that stable, then perhaps it needs a common fallback compatible. Sometimes these instances are also just places we haven't created a common subsystem for. > and this is why I want the mtk_iommu driver to also get that phandle like > some other drivers are already doing. As I said, fine. Rob