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.yamldiff --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