Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp5547359pxb; Mon, 14 Feb 2022 01:31:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJwBP2mS8ulXFPa+46aEVWqq5gGwaE3R7zXTbbzhrE6vblFXEXuHKgSJBHxCCUjFZUlM4Z9o X-Received: by 2002:a17:906:77c3:: with SMTP id m3mr10453627ejn.698.1644831077620; Mon, 14 Feb 2022 01:31:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644831077; cv=none; d=google.com; s=arc-20160816; b=dSmizAmPbGHyfPr0751Rgq1MvTQv3TzfBzuVO7JLZFf6hwMp9SkvY4Volvn2GtfJCO OoqI2uZxTmBe//QiBcoykynVNxUteX95XCfp1EKBgRkGxUufuOI4TbEQAfI9uQuPZ9ND Gq+n3tA2CZzU1Ai1DBibf2Hd52qLPa550Kiv2A81T8u02lkSrhZhaliQ2dAk9onWf5YI CZ+NRmXvVS018EcQlS1Ul5d0zih7oiJblCyKfUSpXhvfsxQFZtKcOltnIE2io41NhKYY H7PR/tNTvnVl4r2vlzoQUDXD37a0zRPknA+3qerbPaWa++w+VNU9ZP3WPuz4wAIfFJIW swHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=cEXqdohr4G9+8GbA7KQx27qyEW3APoDzbf1L0D0YWH8=; b=EztLHtQgP3zSYdYb8nkb2l3vUCpr2+MqwKQgHs2LlwyBSqxfT16PzhfkFlxQvrqiTi tzMC6JAW/5+e5ytoRdhGlOpkWApz6buZ2E/CzCrehh8/be4GkNKrDce8wptROLUCSEv5 +h9X3SSsNYnIHDdFxkyqWbCihBRh0TyP6aTSa03AYgfFHVYXDHFQ9h+KHkRogpXpvSuA ala9zNgNXZCQRVxet49TKhz/4Ct/T6iPf5azNyU34CzgOxCCChy0kVbKSglCtPo1VEgR vZM2/q6Xe6PE6X6b+wcREvwlw6CC7IRSbRVkcysnhU+UaVgqRPd63qeh1s3OV71pwhb/ Rm5Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ffxsUMJt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ho39si1626911ejc.171.2022.02.14.01.30.54; Mon, 14 Feb 2022 01:31:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ffxsUMJt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233904AbiBMWiJ (ORCPT + 99 others); Sun, 13 Feb 2022 17:38:09 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:54892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231864AbiBMWiH (ORCPT ); Sun, 13 Feb 2022 17:38:07 -0500 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BA5A54BCC; Sun, 13 Feb 2022 14:38:01 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id b14so56840ede.9; Sun, 13 Feb 2022 14:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=cEXqdohr4G9+8GbA7KQx27qyEW3APoDzbf1L0D0YWH8=; b=ffxsUMJtJAYyqcnlW20M2+b/TfBJ8V39bIEF3KCE580o77o6LZmQCS/y4WWWVKhaet PZf3lmLFTY5ZJvWRspWfYeiYvut0nvTcRd2LRAGAWvHqlyFtow5XfabfMHRNQGfdWt19 uKF8eAWo27i4oXe8k/ENNR9iSuZxXXXdd631n3UghpS6SVSV3J77RsrbF1UchTUFhkf8 xN2/Tik05F2ygZVzeMHwXw8rXCnBIj4+2tkRvBrN7c4r1L73fYUswKommSkkjFSEyBIn bYR9q0sJAyUvH4Yaz2OhwlgXx6h89RyrB87Dg27Fe1c6AizjXrrCxiDZd/cLBJl2EV7c lzjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=cEXqdohr4G9+8GbA7KQx27qyEW3APoDzbf1L0D0YWH8=; b=Nru4uPtNf3++5qF1Yl/2Tn5YkzraF1VWcLSVcIAyUfN6FpngPeTknazctu0ykEd4aG FTsfzGYdF+k/J6E3QuNFDXAZ7eH5N+Rz59ErG5XvQJa/VjIRyBf8W5IAB/QgYvusLDFB 8jIn8suNrUW0lN+5Cjop567JMjBkbg/0aYxu6Q8KY764Ik+bzdeMdK9pbv7NLIZtR532 EL5uy+8IKBp+nU8vQgfvOyzXdkbHkK1RS7da9l78tPigkb+QsdJ20xQMamUDXsjKAFhl J2/pRsIFbbMV5opUcHCT77q0gncXE8FytuR3F4DsHaqPadV8N+ZSKCzrrw7xv/YiAc05 Rr6w== X-Gm-Message-State: AOAM533DJaa6YYGMZMNUhJSR9f2v+TYkJo88d1kPCvKG/NK6McDEswW0 7srKzUsTlTT/MdcPrHFKCtpSTDJCqyJQnw== X-Received: by 2002:a05:6402:5113:: with SMTP id m19mr12526413edd.325.1644791879954; Sun, 13 Feb 2022 14:37:59 -0800 (PST) Received: from [192.168.2.1] (81-204-249-205.fixed.kpn.net. [81.204.249.205]) by smtp.gmail.com with ESMTPSA id j19sm1210807ejo.202.2022.02.13.14.37.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Feb 2022 14:37:59 -0800 (PST) Message-ID: Date: Sun, 13 Feb 2022 23:37:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3] dt-bindings: crypto: convert rockchip-crypto to yaml Content-Language: en-US To: LABBE Corentin , heiko@sntech.de, robh+dt@kernel.org Cc: davem@davemloft.net, herbert@gondor.apana.org.au, krzysztof.kozlowski@canonical.com, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org References: <20220211115925.3382735-1-clabbe@baylibre.com> From: Johan Jonker In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/11/22 20:48, LABBE Corentin wrote: > Le Fri, Feb 11, 2022 at 02:13:00PM +0100, Johan Jonker a écrit : >> >> >> On 2/11/22 12:59, Corentin Labbe wrote: >>> Convert rockchip-crypto to yaml >>> >>> Signed-off-by: Corentin Labbe >>> --- >>> Changes since v1: >>> - fixed example >>> - renamed to a new name >>> - fixed some maxItems >>> >>> Change since v2: >>> - Fixed maintainers section >>> >>> .../crypto/rockchip,rk3288-crypto.yaml | 66 +++++++++++++++++++ >>> .../bindings/crypto/rockchip-crypto.txt | 28 -------- >>> 2 files changed, 66 insertions(+), 28 deletions(-) >> >>> create mode 100644 Documentation/devicetree/bindings/crypto/rockchip,rk3288-crypto.yaml >>> delete mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt >> >> There's more possible to this document: >> >> dt-bindings: crypto: rockchip: add support for px30 >> https://github.com/rockchip-linux/kernel/commit/3655df1bc6114bda2a6417f39772a3cb008084ea >> >> crypto: rockchip - add px30 crypto aes/des support >> https://github.com/rockchip-linux/kernel/commit/ee082ae4f609f3b48f768420b31d8600448bd35a >> > > Hello > > The great advantage of out of tree code is that we can ignore it. See comment below. This is not about code, but about reusing the (generic) binding for more SoCs then just rk3288 that happened to have Linux support. See spi-rockchip.yaml rockchip-dw-mshc.yaml etc. > Anyway, if one day this code goes upstream, I think the new compatible should be in a new driver/module, both v1 and v2 are too different for me to be shared in the same driver. > > But before upstreaming this code, the one in mainline should be fixed first, it fail self tests. (I have some patch partialy fixing it in progress) > Success! Send us lots of patches... Is it possible to keep portability (to U-boot) in mind for multiple Rockchip SoC types. > Regards > Although DT and bindings are hosted in the Linux tree they are separate things. DT files and bindings can be used elsewhere. There's no need for (full) Linux driver support. For Rockchip crypto nodes this is mostly done in the Manufacturer U-boot tree. https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/crypto/rockchip/crypto_v1.c https://github.com/rockchip-linux/u-boot/blame/next-dev/drivers/crypto/rockchip/crypto_v2.c Given Krzysztof's comment: > file name: rockchip,crypto.yaml or rockchip,rk3288-crypto.yaml. > Kind of depends whether there is another binding possible for newer > Crypto blocks from Rockchip. For U-boot the Rockchip dtsi files are synced from the Linux tree, so it may well be possible that someone add them here and use them elsewhere if needed. From the links to the files above we can expect: crypto v1: { .compatible = "rockchip,rk312x-crypto" }, { .compatible = "rockchip,rk322x-crypto" }, { .compatible = "rockchip,rk3288-crypto" }, { .compatible = "rockchip,rk3328-crypto" }, { .compatible = "rockchip,rk3368-crypto" }, { .compatible = "rockchip,rk3399-crypto" }, crypto v2: { .compatible = "rockchip,px30-crypto" }, { .compatible = "rockchip,rk1808-crypto" }, { .compatible = "rockchip,rk3308-crypto" }, { .compatible = "rockchip,rv1126-crypto" }, { .compatible = "rockchip,rk3568-crypto" }, { .compatible = "rockchip,rk3588-crypto" }, With only small nodes differences for clocks we reuse the "generic" binding and NOT a (rk3288) SoC orientated one. Johan