linux-kernel - Re: [PATCH v5 2/6] Bindings: nvmem: add bindings for JZ4780 efuse

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <7EA5C99C-094E-43FC-BF04-A9056C8BB2B6@goldelico.com>
Date:   Sat, 22 Feb 2020 18:17:44 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>,
        Paul Cercueil <paul@...pouillou.net>,
        Mathieu Malaterre <malat@...ian.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Paul Burton <paulburton@...nel.org>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-mips@...r.kernel.org, letux-kernel@...nphoenux.org,
        kernel@...a-handheld.com
Subject: Re: [PATCH v5 2/6] Bindings: nvmem: add bindings for JZ4780 efuse


> Am 22.02.2020 um 17:46 schrieb Andreas Kemnade <andreas@...nade.info>:
> 
> On Sat, 22 Feb 2020 17:34:06 +0100
> "H. Nikolaus Schaller" <hns@...delico.com> wrote:
> 
>>> Am 22.02.2020 um 16:57 schrieb Andreas Kemnade <andreas@...nade.info>:
>>> 
>>> On Sat, 22 Feb 2020 11:25:37 +0100
>>> "H. Nikolaus Schaller" <hns@...delico.com> wrote:
>>> 
>>>> From: PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>
>>>> 
>>>> This patch brings support for the JZ4780 efuse. Currently it only exposes
>>>> a read only access to the entire 8K bits efuse memory.
>>>> 
>>>> Tested-by: Mathieu Malaterre <malat@...ian.org>
>>>> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>
>>>> Signed-off-by: Mathieu Malaterre <malat@...ian.org>
>>>> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
>>>> [converted to yaml]
>>>> Signed-off-by: Andreas Kemnade <andreas@...nade.info>
>>>> ---
>>>> .../bindings/nvmem/ingenic,jz4780-efuse.yaml  | 50 +++++++++++++++++++
>>>> 1 file changed, 50 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml
>>>> 
>>>> diff --git a/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml
>>>> new file mode 100644
>>>> index 000000000000..09a8ef937750
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/nvmem/ingenic,jz4780-efuse.yaml
>>>> @@ -0,0 +1,50 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/nvmem/ingenic,jz4780-efuse.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Ingenic JZ EFUSE driver bindings
>>>> +
>>>> +maintainers:
>>>> +  - PrasannaKumar Muralidharan <prasannatsmkumar@...il.com>
>>>> +
>>>> +allOf:
>>>> +  - $ref: "nvmem.yaml#"
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - ingenic,jz4780-efuse
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clocks:
>>>> +    # Handle for the ahb for the efuse.
>>>> +    maxItems: 1
>>>> +
>>>> +  clock-names:
>>>> +   items:
>>>> +     - const:  ahb2  
>>> as Rob said: probably not needed, since it is a single
>>> clock, and the driver uses devm_clk_get(dev, NULL), so it should be prepared
>>> for that without any extra work.  
>> 
>> The question is if a specific driver implementation should determine
>> what the DT requires or the other way round. I don't know...
>> 
>> I did interpret Rob's comment differently: there was
>> 
>>> - "clock-names"		Must be "bus_clk"  
>> 
>> and he did say: 
>> 
>> 	'clk' is redundant. How about 'ahb'?
>> 
>> So I thought he refers to the _clk suffix?
>> 
> 
> and he said to my first try:
> ---
>> +  clock-names:
>> +   items:
>> +     - const:  bus_clk  
> 
> My prior comment still applies.
> 
> Also, for a single clock, you don't really need a name.

Ah, ok. I may have missed that.

BR and thanks,
Nikolaus