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 9BE36C433F5 for ; Tue, 22 Mar 2022 12:01: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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FjEZbYXvjcuA3dYky6LQ/55a1eyfKr2KS5AqlH8cxp4=; b=X6gCgyXqIK6JtD EJnXA1eNd8/5rxL60jBZ4WYSke1GRIsiv0TbjFphdSInlwWdgpmgGWNj6XA39fK/hUwWKXWdkobG8 3BMv+757B9wuyXKRwYdOjQkiohuSX/tntuaLQz/PpqT0+JGc9sZsB1iXIvJvfJt3h8yqDu+ffIEY0 ZYXWR+aaULTdqpVpzYYnOXAV/xvs0IawMRwVHTybuXLaLxagdfkFu/VAPPGGxRDFDClfc1cZO2Zgl A5xDv6QaZCHLseeYRYBALcBWzNmcgeTzIwluBrQt6owRM2ufRpB0XemPxebZz28EIQYlmCiN4Tgdc zwMpx5LqOMgY5nwr0gkg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWdBS-00AsuO-DK; Tue, 22 Mar 2022 12:00:18 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWdBO-00Ast2-7z; Tue, 22 Mar 2022 12:00:15 +0000 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 3A58D153B; Tue, 22 Mar 2022 05:00:11 -0700 (PDT) Received: from [10.57.43.230] (unknown [10.57.43.230]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 956A63F73B; Tue, 22 Mar 2022 05:00:08 -0700 (PDT) Message-ID: <70422777-a3f9-b2f1-5faa-94d24fe200ac@arm.com> Date: Tue, 22 Mar 2022 12:00:06 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v3 18/26] arm64: dts: rockchip: rk3399: add crypto node Content-Language: en-GB To: Corentin Labbe , heiko@sntech.de, herbert@gondor.apana.org.au, krzk+dt@kernel.org, mturquette@baylibre.com, robh+dt@kernel.org, sboyd@kernel.org Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org References: <20220321200739.3572792-1-clabbe@baylibre.com> <20220321200739.3572792-19-clabbe@baylibre.com> From: Robin Murphy In-Reply-To: <20220321200739.3572792-19-clabbe@baylibre.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220322_050014_402327_AB03DA69 X-CRM114-Status: GOOD ( 20.53 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-03-21 20:07, Corentin Labbe wrote: > The rk3399 has a crypto IP handled by the rk3288 crypto driver so adds a > node for it. > > Signed-off-by: Corentin Labbe > --- > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > index 88f26d89eea1..ca2c658371a5 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > @@ -573,6 +573,18 @@ saradc: saradc@ff100000 { > status = "disabled"; > }; > > + crypto0: crypto@ff8b0000 { > + compatible = "rockchip,rk3399-crypto"; > + reg = <0x0 0xff8b0000 0x0 0x4000>, > + <0x0 0xff8b8000 0x0 0x4000>; > + interrupts = , > + ; > + clocks = <&cru SCLK_CRYPTO0>, <&cru HCLK_M_CRYPTO0>, <&cru HCLK_S_CRYPTO0>, > + <&cru SCLK_CRYPTO1>, <&cru HCLK_M_CRYPTO1>, <&cru HCLK_S_CRYPTO1>; > + resets = <&cru SRST_CRYPTO0>, <&cru SRST_CRYPTO0_S>, <&cru SRST_CRYPTO0_M>, > + <&cru SRST_CRYPTO1>, <&cru SRST_CRYPTO1_S>, <&cru SRST_CRYPTO1_M>; > + }; What's going on here? If these are simply two instances of the same IP block as the evidence suggests, why are they crammed into a single DT node rather than simply being described as two separate instances? I was rather wondering what all the confusing mess in patch #16 was about, until I got here. If there's something in the crypto API that means the driver can't simply naively register itself multiple times, there should be any number of ways for the probe routine to keep track of whether it's already registered something and associate any subsequent devices with the first one internally if need be. Linux implementation details should not leak out as non-standard DT weirdness. I know the Rockchip IOMMU driver does this, but in that case the two IOMMU instances are closely coupled and sharing work such that they effectively need to be programmed identically at all times, so it was a bit more justifiable. I don't know the full story here, but it certainly looks like rk_get_engine_number() is just a means to schedule work on any available unit independently, so looks like it wouldn't take much to select between distinct devices at that point, and actually end up a lot simpler and cleaner overall. Robin. > + > i2c1: i2c@ff110000 { > compatible = "rockchip,rk3399-i2c"; > reg = <0x0 0xff110000 0x0 0x1000>; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel