From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753583AbdIDM4n (ORCPT <rfc822;w@1wt.eu>);
        Mon, 4 Sep 2017 08:56:43 -0400
Received: from conssluserg-03.nifty.com ([210.131.2.82]:26701 "EHLO
        conssluserg-03.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1753537AbdIDM4l (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 4 Sep 2017 08:56:41 -0400
DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-03.nifty.com v84CuK0v028066
X-Nifty-SrcIP: [209.85.161.180]
X-Google-Smtp-Source: ADKCNb5PMuVhdiWfEEYuOZh8xOgjTIdYj/wcM+OKZzZ8Xg7+RSaZnVJI3+/UXp8kO/hTMuNLahwzZn1cFqiTNT3vS+I=
MIME-Version: 1.0
In-Reply-To: <1504221620-358-2-git-send-email-hayashibara.keiji@socionext.com>
References: <1504221620-358-1-git-send-email-hayashibara.keiji@socionext.com> <1504221620-358-2-git-send-email-hayashibara.keiji@socionext.com>
From: Masahiro Yamada <yamada.masahiro@socionext.com>
Date: Mon, 4 Sep 2017 21:55:39 +0900
X-Gmail-Original-Message-ID: <CAK7LNASLh4vYqZhM9g2AL1uUtieviAmmWOp_Mzoj0zG=Ejz0cA@mail.gmail.com>
Message-ID: <CAK7LNASLh4vYqZhM9g2AL1uUtieviAmmWOp_Mzoj0zG=Ejz0cA@mail.gmail.com>
Subject: Re: [PATCH v1 1/3] dt-bindings: nvmem: add description for UniPhier eFuse
To: Keiji Hayashibara <hayashibara.keiji@socionext.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Rob Herring <robh+dt@kernel.org>, devicetree@vger.kernel.org,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Masami Hiramatsu <masami.hiramatsu@linaro.org>,
        Jassi Brar <jaswinder.singh@linaro.org>,
        Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
        Kiyoshi Owada <owada.kiyoshi@socionext.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

2017-09-01 8:20 GMT+09:00 Keiji Hayashibara <hayashibara.keiji@socionext.com>:
> Add uniphier-efuse dt-bindings documentation.
>
> Signed-off-by: Keiji Hayashibara <hayashibara.keiji@socionext.com>
> ---
>  .../devicetree/bindings/nvmem/uniphier-efuse.txt   | 45 ++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
> new file mode 100644
> index 0000000..09024a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt
> @@ -0,0 +1,45 @@
> += UniPhier eFuse device tree bindings =
> +
> +This UniPhier eFuse must be under soc-glue.
> +
> +Required properties:
> +- compatible: should be "socionext,uniphier-efuse"
> +- reg: should contain the register base and length
> +
> += Data cells =
> +Are child nodes of efuse, bindings of which as described in
> +bindings/nvmem/nvmem.txt
> +
> +Example:
> +
> +       soc-glue@5f900000 {
> +               compatible = "socionext,uniphier-ld20-soc-glue-debug",
> +                            "simple-mfd";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               ranges = <0x0 0x5f900000 0x2000>;


IMHO, I think an empty "ranges;" will clarify the code,
but it is up to your taste.


> +
> +               efuse {
> +                       compatible = "socionext,uniphier-efuse",
> +                                    "syscon";


You are adding a dedicated driver for "socionext,uniphier-efuse".

Then, "syscon" as well?




> +                       reg = <0x100 0xf00>;


Not so many efuse registers exist on the SoC.

reg = <0x100 0x200>; will be enough.


Or if you want to be strict to the hw spec, you can write as follows:

        soc-glue@5f900000 {
               compatible = "socionext,uniphier-ld20-soc-glue-debug";
                            "simple-mfd";
               #address-cells = <1>;
               #size-cells = <1>;
               ranges = <0x0 0x5f900000 0x2000>;

               efuse@100 {
                           compatible = "socionext,uniphier-efuse";
                           reg = <0x100 0x28>;
               };

               efuse@200 {
                           compatible = "socionext,uniphier-efuse";
                           reg = <0x200 0x68>;
               };
       };




> +                       #address-cells = <1>;
> +                       #size-cells = <1>;
> +
> +                       /* Data cells */
> +                       usb_mon: usb_mon {
> +                               reg = <0x154 0xc>;
> +                       };


This <0x154 0xc> represents 0x5f900254 in CPU address view.
(0x5f900000 + 0x100 + 0x154)

So many ranges conversion, and how error-prone..





> +       };
> +
> += Data consumers =
> +Are device nodes which consume nvmem data cells.
> +
> +Example:
> +
> +       usb {
> +               ...
> +               nvmem-cells = <&usb_mon>;
> +               nvmem-cell-names = "usb_mon";
> +       }
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada