Thread (8 messages) 8 messages, 3 authors, 2019-10-18

Re: [PATCH v2 1/2] dt-bindings: gpio: brcm: Add bindings for xgs-iproc

From: Rob Herring <robh@kernel.org>
Date: 2019-10-18 19:07:31
Also in: linux-devicetree, linux-gpio, lkml

On Fri, Oct 18, 2019 at 1:00 AM Bartosz Golaszewski
[off-list ref] wrote:
czw., 17 paź 2019 o 21:24 Rob Herring [off-list ref] napisał(a):
quoted
On Thu, Oct 17, 2019 at 04:10:50PM +1300, Chris Packham wrote:
quoted
This GPIO controller is present on a number of Broadcom switch ASICs
with integrated SoCs. It is similar to the nsp-gpio and iproc-gpio
blocks but different enough to require a separate driver.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---

Notes:
    Changes in v2:
    - Document as DT schema
    - Include ngpios, #gpio-cells and gpio-controller properties

 .../bindings/gpio/brcm,xgs-iproc.yaml         | 83 +++++++++++++++++++
 1 file changed, 83 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
diff --git a/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
new file mode 100644
index 000000000000..71998551209e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/brcm,xgs-iproc.yaml
@@ -0,0 +1,83 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/brcm,xgs-iproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom XGS iProc GPIO controller
+
+maintainers:
+  - Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+description: |
+  This controller is the Chip Common A GPIO present on a number of Broadcom
+  switch ASICs with integrated SoCs.
+
+properties:
+  compatible:
+    enum:
+      - brcm,iproc-gpio-cca
enum vs. const usage depends on whether you think you'll add more
compatibles.
What if you don't know yet? For instance we use a const compatible and
then a new chip is released for which we can reuse the driver?
Then you just change it to an enum (or oneOf if the new compatible has
a fallback to the old one). Not really a big deal.
Is this
something that is expected to remain stable in the binding document?
No, only in the sense we want to minimize changes.
The question is unrelated to this patch, I'm just unsure about my own
approach to writing yaml bindings.
We could perhaps just say single entries should always be 'const'
because then we could write a meta-schema enforcing that:

properties:
  enum:
    minItems: 2

I don't think we should be that strict though unless it becomes a
frequent review topic. So either way is fine, it's up to your
judgement, and let's stop talking about it before I change my mind. :)

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help