+Linus W

On Tue, Aug 25, 2020 at 6:26 AM Alan Cooper [off-list ref] wrote:

On Mon, Aug 24, 2020 at 7:30 PM Rob Herring [off-list ref] wrote:

quoted

On Wed, Aug 12, 2020 at 04:20:16PM -0400, Al Cooper wrote:

quoted

Add DT bindings for the Broadcom USB pin map driver. This driver allows
some USB input and output signals to be mapped to any GPIO instead
of the normal dedicated pins to/from the XHCI controller.

Is this a driver or h/w block because bindings are for h/w blocks?

This is a hardware block. I'll remove "driver" from the description.

Another question, this kind of looks like a pin mux controller. Is
that not a fit for this? If not, why?

quoted

quoted

Signed-off-by: Al Cooper <alcooperx@gmail.com>
---
 .../bindings/usb/brcm,usb-pinmap.yaml         | 63 +++++++++++++++++++
 1 file changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml

diff --git a/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
new file mode 100644
index 000000000000..19cf6ad36373
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml

@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/brcm,usb-pinmap.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom USB pin map Controller Device Tree Bindings
+
+maintainers:
+  - Al Cooper <alcooperx@gmail.com>
+
+properties:
+  compatible:
+      items:
+          - const: brcm,usb-pinmap

2 space indentation please.

Fixed.

quoted

quoted

+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+    description: Must be defined if any out-gpios are specified.

'dependencies' can express this in schema.

Okay.

quoted

quoted

+
+  in-gpios:
+    description: Array of one or more GPIO pins used for input signals.

You need to define how many GPIOs are valid.

I tried to avoid doing this because there is a possibility that future
chips will have a few more signals added and the driver was written so
new signals can be added entirely in device tree without any changes
to the driver. If this is unacceptable, I can add the current max in
and out valid gpios.

A 'should be enough for a while' value is fine. The driver doesn't
have to have a max. I'd expect the binding to be updated for new SoCs
anyways.

quoted

quoted

+
+  in-names:
+    description: Array of input signal names, one per gpio in in-gpios.

No, this isn't how we name GPIOs. The part before '-gpios' is how.

This is the meant to be a description of how each gpio is being used
to help with error messages in the driver.
What if I use "brcmstb,in-functions" instead?

'brcmstb' is not a vendor. But brcm,in-functions is fine.

quoted

quoted

+
+  in-masks:
+    description: Array of enable and mask pairs, one per gpio in-gpios.

Needs a vendor prefix.

I'll change it to "brcmstb,in-masks"

quoted

quoted

+
+  out-gpios:
+    description: Array of one or more GPIO pins used for output signals.
+
+  out-names:
+    description: Array of output signal names, one per gpio in out-gpios.
+
+  out-masks:
+    description: Array of enable, value, changed and clear masks, one
+      per gpio in out-gpios.
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    usb_pinmap: usb-pinmap@22000d0 {
+        compatible = "brcm,usb-pinmap";
+        reg = <0x22000d0 0x4>;
+        in-gpios = <&gpio 18 0>, <&gpio 19 0>;
+        in-names = "VBUS", "PWRFLT";
+        in-masks = <0x8000 0x40000 0x10000 0x80000>;
+        out-gpios = <&gpio 20 0>;
+        out-names = "PWRON";
+        out-masks = <0x20000 0x800000 0x400000 0x200000>;
+        interrupts = <0x0 0xb2 0x4>;
+    };
+
+...
--
2.17.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel