Thread (17 messages) read the whole thread 17 messages, 3 authors, 2020-02-24

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

From: Andreas Kemnade <andreas@kemnade.info>
Date: 2020-02-22 16:47:02
Also in: linux-mips, lkml

On Sat, 22 Feb 2020 17:34:06 +0100
"H. Nikolaus Schaller" [off-list ref] wrote:
quoted
Am 22.02.2020 um 16:57 schrieb Andreas Kemnade [off-list ref]:

On Sat, 22 Feb 2020 11:25:37 +0100
"H. Nikolaus Schaller" [off-list ref] wrote:
  
quoted
From: PrasannaKumar Muralidharan <redacted>

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 <redacted>
Signed-off-by: PrasannaKumar Muralidharan <redacted>
Signed-off-by: Mathieu Malaterre <redacted>
Signed-off-by: H. Nikolaus Schaller <redacted>
[converted to yaml]
Signed-off-by: Andreas Kemnade <andreas@kemnade.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@gmail.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
quoted
- "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.
---

Regards,
Andreas

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help