Thread (32 messages) 32 messages, 4 authors, 2020-11-30

Re: [PATCH v4 10/18] dt-bindings: usb: Convert DWC USB3 bindings to DT schema

From: Serge Semin <hidden>
Date: 2020-11-11 09:40:42
Also in: linux-arm-kernel, linux-devicetree, linux-mips, linux-usb, lkml

On Wed, Nov 11, 2020 at 10:34:10AM +0100, Krzysztof Kozlowski wrote:
On Wed, 11 Nov 2020 at 10:32, Serge Semin
[off-list ref] wrote:
quoted
On Wed, Nov 11, 2020 at 10:16:28AM +0100, Krzysztof Kozlowski wrote:
quoted
On Wed, Nov 11, 2020 at 12:08:45PM +0300, Serge Semin wrote:
quoted
DWC USB3 DT node is supposed to be compliant with the Generic xHCI
Controller schema, but with additional vendor-specific properties, the
controller-specific reference clocks and PHYs. So let's convert the
currently available legacy text-based DWC USB3 bindings to the DT schema
and make sure the DWC USB3 nodes are also validated against the
usb-xhci.yaml schema.

Note we have to discard the nodename restriction of being prefixed with
"dwc3@" string, since in accordance with the usb-hcd.yaml schema USB nodes
are supposed to be named as "^usb(@.*)".

Signed-off-by: Serge Semin <redacted>

---

Changelog v2:
- Discard '|' from the descriptions, since we don't need to preserve
  the text formatting in any of them.
- Drop quotes from around the string constants.
- Fix the "clock-names" prop description to be referring the enumerated
  clock-names instead of the ones from the Databook.

Changelog v3:
- Apply usb-xhci.yaml# schema only if the controller is supposed to work
  as either host or otg.

Changelog v4:
- Apply usb-drd.yaml schema first. If the controller is configured
  to work in a gadget mode only, then apply the usb.yaml schema too,
  otherwise apply the usb-xhci.yaml schema.
- Discard the Rob'es Reviewed-by tag. Please review the patch one more
  time.
---
 .../devicetree/bindings/usb/dwc3.txt          | 125 --------
 .../devicetree/bindings/usb/snps,dwc3.yaml    | 303 ++++++++++++++++++
 2 files changed, 303 insertions(+), 125 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
 create mode 100644 Documentation/devicetree/bindings/usb/snps,dwc3.yaml
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
deleted file mode 100644
index d03edf9d3935..000000000000
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ /dev/null
@@ -1,125 +0,0 @@
-synopsys DWC3 CORE
-
-DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties
-      as described in 'usb/generic.txt'
-
-Required properties:
- - compatible: must be "snps,dwc3"
- - reg : Address and length of the register set for the device
- - interrupts: Interrupts used by the dwc3 controller.
quoted
quoted
- - clock-names: list of clock names. Ideally should be "ref",
-                "bus_early", "suspend" but may be less or more.
- - clocks: list of phandle and clock specifier pairs corresponding to
-           entries in the clock-names property.
-
-Exception for clocks:
-  clocks are optional if the parent node (i.e. glue-layer) is compatible to
-  one of the following:
-    "cavium,octeon-7130-usb-uctl"
-    "qcom,dwc3"
-    "samsung,exynos5250-dwusb3"
-    "samsung,exynos5433-dwusb3"
-    "samsung,exynos7-dwusb3"
-    "sprd,sc9860-dwc3"
-    "st,stih407-dwc3"
-    "ti,am437x-dwc3"
-    "ti,dwc3"
-    "ti,keystone-dwc3"
-    "rockchip,rk3399-dwc3"
-    "xlnx,zynqmp-dwc3"
What happened with this part of dtschema? It sees you removed it.
You meant "bindings", right?

I don't think it's a good idea to implement that weak binding in the
generic DWC USB3 DT schema. Of course I could have created it under
the allOf conditional schema and stuff. But in that case we would have
needed to support the clock-related vendor-specific peculiarities in
both the generic DWC USB3 DT schema and in the vendor-specific binding
files. That wouldn't be that maintainable. As I see it all the
vendor-specific clock requirements should be reflected in the
glue-node DT schema. The DWC USB3 node binding just declares the
clocks as optional. Moreover the DWC USB3 driver also considers them
as optional.
Sure, rationale is good, but it needs to be explained in commit msg.
Otherwise you state that you just "convert" but it's not a simple
conversion. The meaning is changed.
Right. I should have explained it in the commit log. It has just
slipped out of my mind. If v3 is needed I'll add the proper text in the
commit message.

-Sergey

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