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 4BCF3C433FE for ; Tue, 11 Oct 2022 16:38:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229508AbiJKQi1 (ORCPT ); Tue, 11 Oct 2022 12:38:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229747AbiJKQiX (ORCPT ); Tue, 11 Oct 2022 12:38:23 -0400 Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B22CA62A8E for ; Tue, 11 Oct 2022 09:38:21 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id z8so4071791qtv.5 for ; Tue, 11 Oct 2022 09:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QY6WyTHOtNVOWNT2T4wR6tUw0MK2Z6zU5+UbTJRR4tc=; b=LEg8IGV5qy1f4Ls0uTv3AByar4HiiDxIwsDKEhd1O3xBrraCFAScNYyn0CRQWX99TD ShlqA8pojnv0xNOdhZlj4K0NCqWlqdzblrcblq+HuJTHZvC2J4F5cn7BFcbgHDPYWHF7 qHzdA9/fr79n+ObD0DllHTbQB4OH2+jcfYrj5heT+Ssk0cmsq6BGxhVAbWgyU/bZ1OBJ 4Xw56h8FS775SUNOojVN+hK9z/twXXMQ0SkXkM2b2ZkT1df9zEBBJAXBMmFIflHUu2FR joWqB9dh6xRCkeK83NAvUkRsL6Ti980Daj99a6FoHp3T66M9ZlQbAQjF8tq15WmLfmFd LjIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QY6WyTHOtNVOWNT2T4wR6tUw0MK2Z6zU5+UbTJRR4tc=; b=T/MXxiA5PTwyYnbVad8SwRUojgo7DV4+1e07/wS7Uq0qUo383+xy7muDGxbXDjRngW y8k8NfL48V9kskNYmyPd851rQN3kYMUF6anENoIrB0w+omoOkV4L7uIRIWNeAlfdSvtb VjCClHBjizYEvlVcmYZ8qsQJZBbwoNN8YO9HmYBxpGKG3Bi8OK1Z437IThp6BLa3Oz2a dCSXIT5i2Dk6w55paZKM8NQfC6wFYjx3Rx5wMfPgpPqLMMrIIEr4pOGGwOtz5N75nMkz xRbsFHIS0XW1lB4BlapPTOgkJQQrI2xdQQGCn9Wwo2i0JZ5PXTsIcGyq/6Ngjmgrs2Gb sd5Q== X-Gm-Message-State: ACrzQf1h/wqPE3qhv1AA8+E1gMnndXX/JGhNA8rKjaVe4/q/81Gf/Ium mRLRpMT7tCu4oIeL0UkLiBDPvsPYLpP8MQ== X-Google-Smtp-Source: AMsMyM6ZR0Jj5RCA2gjlIscZ4R49LE0rwlWp+wlpIGZOb1PmOQmoWN5UpcMrnDWhs1cwnY4FWY3c0w== X-Received: by 2002:a05:622a:2c6:b0:39c:42ee:932d with SMTP id a6-20020a05622a02c600b0039c42ee932dmr3355086qtx.156.1665506300783; Tue, 11 Oct 2022 09:38:20 -0700 (PDT) Received: from [192.168.1.57] (cpe-72-225-192-120.nyc.res.rr.com. [72.225.192.120]) by smtp.gmail.com with ESMTPSA id i11-20020a05620a404b00b006a5d2eb58b2sm13979752qko.33.2022.10.11.09.38.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Oct 2022 09:38:20 -0700 (PDT) Message-ID: <2f1d1afd-3c97-6ce0-8247-6e1c4a24e548@linaro.org> Date: Tue, 11 Oct 2022 12:36:08 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: [PATCH v1 12/30] dt-bindings: reset: Add starfive,jh7110-reset bindings Content-Language: en-US To: Hal Feng , Rob Herring Cc: linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org, Krzysztof Kozlowski , Paul Walmsley , Palmer Dabbelt , Albert Ou , Daniel Lezcano , Thomas Gleixner , Marc Zyngier , Philipp Zabel , Stephen Boyd , Michael Turquette , Linus Walleij , Emil Renner Berthing , linux-kernel@vger.kernel.org References: <20220929143225.17907-1-hal.feng@linux.starfivetech.com> <20220929175147.19749-1-hal.feng@linux.starfivetech.com> <20220929184349.GA2551443-robh@kernel.org> <8BEAFAD2C4CE6E4A+0a00376c-1e3e-f597-bcf6-106ff294859a@linux.starfivetech.com> From: Krzysztof Kozlowski In-Reply-To: <8BEAFAD2C4CE6E4A+0a00376c-1e3e-f597-bcf6-106ff294859a@linux.starfivetech.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 11/10/2022 11:30, Hal Feng wrote: > On Thu, 29 Sep 2022 13:43:49 -0500, Rob Herring wrote: >> On Fri, Sep 30, 2022 at 01:51:47AM +0800, Hal Feng wrote: >>> Add bindings for the reset controller on the JH7110 RISC-V >>> SoC by StarFive Technology Ltd. >>> >>> Signed-off-by: Hal Feng >>> --- >>> .../bindings/reset/starfive,jh7110-reset.yaml | 54 +++++++++++++++++++ >>> 1 file changed, 54 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/reset/starfive,jh7110-reset.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/reset/starfive,jh7110-reset.yaml b/Documentation/devicetree/bindings/reset/starfive,jh7110-reset.yaml >>> new file mode 100644 >>> index 000000000000..bb0010c200f9 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/reset/starfive,jh7110-reset.yaml >>> @@ -0,0 +1,54 @@ >>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/reset/starfive,jh7110-reset.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: StarFive JH7110 SoC Reset Controller Device Tree Bindings >>> + >>> +maintainers: >>> + - Emil Renner Berthing >>> + - Hal Feng >>> + >>> +properties: >>> + compatible: >>> + enum: >>> + - starfive,jh7110-reset >> >> 'reg' needed? Is this a sub-block of something else? > > Yes, the reset node is a child node of the syscon node, see patch 27 for detail. > You might not see the complete patches at that time due to technical issue of > our smtp email server. Again, I feel so sorry about that. > > syscrg: syscrg@13020000 { > compatible = "syscon", "simple-mfd"; > reg = <0x0 0x13020000 0x0 0x10000>; > > syscrg_clk: clock-controller@13020000 { > compatible = "starfive,jh7110-clkgen-sys"; > clocks = <&osc>, <&gmac1_rmii_refin>, > <&gmac1_rgmii_rxin>, > <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, > <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, > <&tdm_ext>, <&mclk_ext>; > clock-names = "osc", "gmac1_rmii_refin", > "gmac1_rgmii_rxin", > "i2stx_bclk_ext", "i2stx_lrck_ext", > "i2srx_bclk_ext", "i2srx_lrck_ext", > "tdm_ext", "mclk_ext"; > #clock-cells = <1>; > }; > > syscrg_rst: reset-controller@13020000 { > compatible = "starfive,jh7110-reset"; > #reset-cells = <1>; So the answer to the "reg needed?" is what? You have unit address but no reg, so this is not correct. > starfive,assert-offset = <0x2F8>; > starfive,status-offset= <0x308>; > starfive,nr-resets = ; > }; > }; > > In this case, we get the memory mapped space through the parent node with syscon > APIs. You can see patch 13 for detail. > > static int reset_starfive_register(struct platform_device *pdev, const u32 *asserted) > { (...) > >> >>> + >>> + "#reset-cells": >>> + const: 1 >>> + >>> + starfive,assert-offset: >>> + description: Offset of the first ASSERT register >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + >>> + starfive,status-offset: >>> + description: Offset of the first STATUS register >>> + $ref: /schemas/types.yaml#/definitions/uint32 >> >> These can't be implied from the compatible string? > > These two properties are the key differences among different reset controllers. Different as in different compatibles? Please answer the questions... > There are five memory regions for clock and reset in StarFive JH7110 SoC. They > are "syscrg", "aoncrg", "stgcrg", "ispcrg" and "voutcrg". Each memory region > has different reset ASSERT/STATUS register offset and different number of reset > signals. Then these are not exactly the same devices, so using one compatible for them does not look correct. > After storing them in dt, the reset driver can register all reset > controllers with the same compatible string. Which is not how the compatible should be used... > All we expect is that all reset > controllers in a single SoC use the same compatible string for matching and the > reset driver can be applied to all StarFive SoCs using different compatible strings. Keep driver out of the talks. > Just like Existing bad pattern is not an argument to keep it going. Fix bad patterns instead. > > arch/riscv/boot/dts/starfive/jh7100.dtsi: > > rstgen: reset-controller@11840000 { > compatible = "starfive,jh7100-reset"; > reg = <0x0 0x11840000 0x0 0x10000>; > #reset-cells = <1>; > starfive,assert-offset = <0x0>; > starfive,status-offset= <0x10>; > starfive,nr-resets = ; > }; > > arch/riscv/boot/dts/starfive/jh7110.dtsi: > > syscrg: syscrg@13020000 { > compatible = "syscon", "simple-mfd"; > reg = <0x0 0x13020000 0x0 0x10000>; > > syscrg_clk: clock-controller@13020000 { > compatible = "starfive,jh7110-clkgen-sys"; > ... > }; > > syscrg_rst: reset-controller@13020000 { > compatible = "starfive,jh7110-reset"; > #reset-cells = <1>; > starfive,assert-offset = <0x2F8>; > starfive,status-offset= <0x308>; > starfive,nr-resets = ; > }; > }; > > aoncrg: aoncrg@17000000 { > compatible = "syscon", "simple-mfd"; > reg = <0x0 0x17000000 0x0 0x10000>; > > aoncrg_clk: clock-controller@17000000 { > compatible = "starfive,jh7110-clkgen-aon"; > ... > }; > > aoncrg_rst: reset-controller@17000000 { > compatible = "starfive,jh7110-reset"; > #reset-cells = <1>; > starfive,assert-offset = <0x38>; > starfive,status-offset= <0x3C>; > starfive,nr-resets = ; > }; > }; > > stgcrg: stgcrg@10230000 { //Not submmited yet > compatible = "syscon", "simple-mfd"; > reg = <0x0 0x10230000 0x0 0x10000>; > > stgcrg_clk: clock-controller@10230000 { > compatible = "starfive,jh7110-clkgen-stg"; > ... > }; > > stgcrg_rst: reset-controller@10230000 { > compatible = "starfive,jh7110-reset"; > #reset-cells = <1>; > starfive,assert-offset = <0x74>; > starfive,status-offset= <0x78>; > starfive,nr-resets = ; > }; > }; > ... > >> >>> + >>> + starfive,nr-resets: >>> + description: Number of reset signals >>> + $ref: /schemas/types.yaml#/definitions/uint32 >> >> Why do you need this? Most bindings don't. If just to validate 'resets' >> args, then don't. > > Can be removed. Instead, the reset driver should includes some related > binding headers or defines some macros for pointing out the number of > reset signals of each reset controller. > > Best regards, > Hal > >> >> >>> + >>> +required: >>> + - compatible >>> + - "#reset-cells" >>> + - starfive,assert-offset >>> + - starfive,status-offset >>> + - starfive,nr-resets >>> + >>> +additionalProperties: false >>> + >>> +examples: >>> + - | >>> + #include >>> + >>> + syscrg_rst: reset-controller@13020000 { Please test your patches. Best regards, Krzysztof