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: <D59DC84C-837E-4856-8FED-580381F748FF@goldelico.com>
Date:   Sat, 22 Feb 2020 17:34:06 +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 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?

> 
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clock-names
> so it is not required here (but "- clocks" (not "- clock") as said in earlier
> mail).

Well, this is another example where I do not yet see any improvement by yaml.
It is the same amount of guessing what should be written where. Is this to
be added or not? When is it and why, when not and why?

BR and thanks,
Nikolaus