| Message ID | 20230115114146.12628-2-quic_kriskura@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add multiport support for DWC3 controllers | expand |
On Sun, 15 Jan 2023 17:11:42 +0530, Krishna Kurapati wrote: > Add bindings to indicate properties required to support multiport > on Snps Dwc3 controller. > > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> > --- > .../devicetree/bindings/usb/snps,dwc3.yaml | 53 ++++++++++++++++--- > 1 file changed, 47 insertions(+), 6 deletions(-) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/usb/snps,dwc3.yaml:90:5: [warning] wrong indentation: expected 6 but found 4 (indentation) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230115114146.12628-2-quic_kriskura@quicinc.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On Sun, Jan 15, 2023 at 05:11:42PM +0530, Krishna Kurapati wrote: > Add bindings to indicate properties required to support multiport > on Snps Dwc3 controller. > > Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> > --- > .../devicetree/bindings/usb/snps,dwc3.yaml | 53 ++++++++++++++++--- > 1 file changed, 47 insertions(+), 6 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > index 6d78048c4613..3ea051beb2f8 100644 > --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml > @@ -81,15 +81,26 @@ properties: > > phys: > minItems: 1 > - maxItems: 2 > + maxItems: 8 > > phy-names: > minItems: 1 > - maxItems: 2 > - items: > - enum: > - - usb2-phy > - - usb3-phy > + maxItems: 8 > + oneOf: > + - items: > + enum: > + - usb2-phy > + - usb3-phy > + - items: > + enum: > + - usb2-phy_port0 > + - usb2-phy_port1 > + - usb2-phy_port2 > + - usb2-phy_port3 > + - usb3-phy_port0 > + - usb3-phy_port1 > + - usb3-phy_port2 > + - usb3-phy_port3 usbN-portM > > resets: > minItems: 1 > @@ -360,6 +371,22 @@ properties: > description: > Enable USB remote wakeup. > > + num-ports: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + This property indicates the number of ports present on the target that > + are to be serviced by the DWC3 controller. > + minimum: 1 > + maximum: 4 > + > + num-ss-ports: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + This property indicates the number of SS capable ports present on the > + target that are to be serviced by the DWC3 controller. > + minimum: 1 > + maximum: 4 This information is redundant. 'phy-names' tells you how many ports of each. > + > unevaluatedProperties: false > > required: > @@ -388,4 +415,18 @@ examples: > snps,dis_u2_susphy_quirk; > snps,dis_enblslpm_quirk; > }; > + - | > + usb@4a000000 { > + compatible = "snps,dwc3"; > + reg = <0x4a000000 0xcfff>; > + interrupts = <0 92 4>; > + clocks = <&clk 1>, <&clk 2>, <&clk 3>; > + clock-names = "bus_early", "ref", "suspend"; > + num-ports = <2>; > + num-ss-ports = <1>; > + phys = <&usb2_phy0>, <&usb3_phy0>, <&usb2_phy1>; > + phy-names = "usb2-phy_port0", "usb3-phy_port0", "usb2-phy_port1"; > + snps,dis_u2_susphy_quirk; > + snps,dis_enblslpm_quirk; > + }; Does a different number of phys really need its own example? Rob
On 1/16/2023 10:04 PM, Rob Herring wrote: > On Sun, Jan 15, 2023 at 05:11:42PM +0530, Krishna Kurapati wrote: >> Add bindings to indicate properties required to support multiport >> on Snps Dwc3 controller. >> >> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> >> --- >> .../devicetree/bindings/usb/snps,dwc3.yaml | 53 ++++++++++++++++--- >> 1 file changed, 47 insertions(+), 6 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >> index 6d78048c4613..3ea051beb2f8 100644 >> --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >> @@ -81,15 +81,26 @@ properties: >> >> phys: >> minItems: 1 >> - maxItems: 2 >> + maxItems: 8 >> >> phy-names: >> minItems: 1 >> - maxItems: 2 >> - items: >> - enum: >> - - usb2-phy >> - - usb3-phy >> + maxItems: 8 >> + oneOf: >> + - items: >> + enum: >> + - usb2-phy >> + - usb3-phy >> + - items: >> + enum: >> + - usb2-phy_port0 >> + - usb2-phy_port1 >> + - usb2-phy_port2 >> + - usb2-phy_port3 >> + - usb3-phy_port0 >> + - usb3-phy_port1 >> + - usb3-phy_port2 >> + - usb3-phy_port3 > > usbN-portM > >> >> resets: >> minItems: 1 >> @@ -360,6 +371,22 @@ properties: >> description: >> Enable USB remote wakeup. >> >> + num-ports: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + This property indicates the number of ports present on the target that >> + are to be serviced by the DWC3 controller. >> + minimum: 1 >> + maximum: 4 >> + >> + num-ss-ports: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + This property indicates the number of SS capable ports present on the >> + target that are to be serviced by the DWC3 controller. >> + minimum: 1 >> + maximum: 4 > > This information is redundant. 'phy-names' tells you how many ports of > each. > Hi Rob, Thanks for the review. The reason I wanted to introduce two more variables is to get info on number of ports and ss-capable ports present on hardware whether or not the user provides them in DTSI file. In the code there are two types of per port / per phy operations: a) Modifying GUSB2PFYCFG and GUSB3PIPECTL registers per phy. b) Generic Phy operations - per phy. In today's code, if someone doesn't mention the SSPHY in DTSI, dwc->usb3_generic_phy will be NULL and any call to phy operations will just bail out. And irrespective of whether we provide SS Phy in DTSI or not, we still configure GUSB3PIPECTL register. Consider the following cases: 1. There are 3 ports and 2 of them are SS capable and all phy's are mentioned in DTSI. phy-names= "usb2-port0", "usb3-port0", "usb2-port1", "usb3-port1", "usb2-port2" When we count them in the driver, we get num ports as 3 (presuming num-ports = num of hs ports) and num-ss-ports = 2. Since there is no ambiguity in which all ports to configure, we can modify GUSB2PHYCFG registers for all 3 HS Phy's and GUSB3PIPECTL for both SS Phy's. This is a proper scenario. 2. If the user skips providing SS Phy on Port-0, then: phy-names= "usb2-port0", "usb2-port1", "usb3-port1", "usb2-port2" If we count the phys, we end up getting num-ports=3 and num-ss-ports=1. Since in the driver code, we are not keeping track of which ports are SS capable and which ones are not, we end up configuring GUSB2PIPECTL(port-0) instead of port-1 as the num-ss-ports is "1" which is incorrect. 3. If the user skips providing one complete port, in this case port-1 is skipped, then: phy-names= "usb2-port0", "usb3-port0", "usb2-port2" If we count the phys, we end up getting num-ports=2 and num-ss-ports=1. Since in the driver code, we are not keeping track of which ports are SS capable and which ones are not, we end up configuring GUSB2PHYCFG(port-0) and GUSB2PHYCFG(port-1) instead of port-2 which is incorrect. To avoid these scenarios, if we can get the exact number of SS Ports and Ports in total present on the HW, we can configure all the registers whether the phy's are provided in DTSI or not. (This is of no harm I believe as it still works in today's code) Incase the 2nd and 3rd scenarios are not allowed and user *MUST* declare all the phy's in the DTSI, then I can go ahead and remove these properties and count them in the driver code. Thanks, Krishna, >> + >> unevaluatedProperties: false >> >> required: >> @@ -388,4 +415,18 @@ examples: >> snps,dis_u2_susphy_quirk; >> snps,dis_enblslpm_quirk; >> }; >> + - | >> + usb@4a000000 { >> + compatible = "snps,dwc3"; >> + reg = <0x4a000000 0xcfff>; >> + interrupts = <0 92 4>; >> + clocks = <&clk 1>, <&clk 2>, <&clk 3>; >> + clock-names = "bus_early", "ref", "suspend"; >> + num-ports = <2>; >> + num-ss-ports = <1>; >> + phys = <&usb2_phy0>, <&usb3_phy0>, <&usb2_phy1>; >> + phy-names = "usb2-phy_port0", "usb3-phy_port0", "usb2-phy_port1"; >> + snps,dis_u2_susphy_quirk; >> + snps,dis_enblslpm_quirk; >> + }; > > Does a different number of phys really need its own example? > > Rob
On 17/01/2023 10:01, Krishna Kurapati PSSNV wrote: > > > On 1/16/2023 10:04 PM, Rob Herring wrote: >> On Sun, Jan 15, 2023 at 05:11:42PM +0530, Krishna Kurapati wrote: >>> Add bindings to indicate properties required to support multiport >>> on Snps Dwc3 controller. >>> >>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> >>> --- >>> .../devicetree/bindings/usb/snps,dwc3.yaml | 53 ++++++++++++++++--- >>> 1 file changed, 47 insertions(+), 6 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >>> index 6d78048c4613..3ea051beb2f8 100644 >>> --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >>> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >>> @@ -81,15 +81,26 @@ properties: >>> >>> phys: >>> minItems: 1 >>> - maxItems: 2 >>> + maxItems: 8 >>> >>> phy-names: >>> minItems: 1 >>> - maxItems: 2 >>> - items: >>> - enum: >>> - - usb2-phy >>> - - usb3-phy >>> + maxItems: 8 >>> + oneOf: >>> + - items: >>> + enum: >>> + - usb2-phy >>> + - usb3-phy >>> + - items: >>> + enum: >>> + - usb2-phy_port0 >>> + - usb2-phy_port1 >>> + - usb2-phy_port2 >>> + - usb2-phy_port3 >>> + - usb3-phy_port0 >>> + - usb3-phy_port1 >>> + - usb3-phy_port2 >>> + - usb3-phy_port3 >> >> usbN-portM >> >>> >>> resets: >>> minItems: 1 >>> @@ -360,6 +371,22 @@ properties: >>> description: >>> Enable USB remote wakeup. >>> >>> + num-ports: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: >>> + This property indicates the number of ports present on the target that >>> + are to be serviced by the DWC3 controller. >>> + minimum: 1 >>> + maximum: 4 >>> + >>> + num-ss-ports: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: >>> + This property indicates the number of SS capable ports present on the >>> + target that are to be serviced by the DWC3 controller. >>> + minimum: 1 >>> + maximum: 4 >> >> This information is redundant. 'phy-names' tells you how many ports of >> each. >> > Hi Rob, > > Thanks for the review. The reason I wanted to introduce two more > variables is to get info on number of ports and ss-capable ports > present on hardware whether or not the user provides them in DTSI file. > > In the code there are two types of per port / per phy operations: > a) Modifying GUSB2PFYCFG and GUSB3PIPECTL registers per phy. > b) Generic Phy operations - per phy. > > In today's code, if someone doesn't mention the SSPHY in DTSI, > dwc->usb3_generic_phy will be NULL and any call to phy operations will > just bail out. And irrespective of whether we provide SS Phy in DTSI or > not, we still configure GUSB3PIPECTL register. > > Consider the following cases: > > 1. There are 3 ports and 2 of them are SS capable and all phy's are > mentioned in DTSI. > > phy-names= "usb2-port0", "usb3-port0", "usb2-port1", "usb3-port1", > "usb2-port2" > > When we count them in the driver, we get num ports as 3 (presuming > num-ports = num of hs ports) and num-ss-ports = 2. > > Since there is no ambiguity in which all ports to configure, we can > modify GUSB2PHYCFG registers for all 3 HS Phy's and GUSB3PIPECTL for > both SS Phy's. > This is a proper scenario. > > 2. If the user skips providing SS Phy on Port-0, then: > > phy-names= "usb2-port0", "usb2-port1", "usb3-port1", "usb2-port2" > > If we count the phys, we end up getting num-ports=3 and num-ss-ports=1. > > Since in the driver code, we are not keeping track of which ports are SS > capable and which ones are not, we end up configuring > GUSB2PIPECTL(port-0) instead of port-1 as the num-ss-ports is "1" which > is incorrect. > > 3. If the user skips providing one complete port, in this case port-1 is > skipped, then: > > phy-names= "usb2-port0", "usb3-port0", "usb2-port2" > > If we count the phys, we end up getting num-ports=2 and num-ss-ports=1. > > Since in the driver code, we are not keeping track of which ports are SS > capable and which ones are not, we end up configuring > GUSB2PHYCFG(port-0) and GUSB2PHYCFG(port-1) instead of port-2 which is > incorrect. Why? You know you have port-2 from the phy name, so why would you ignore this information? > > To avoid these scenarios, if we can get the exact number of SS Ports and > Ports in total present on the HW, we can configure all the registers > whether the phy's are provided in DTSI or not. (This is of no harm I > believe as it still works in today's code) Doesn't the driver know how many phys it has in such case through respective compatible? > > Incase the 2nd and 3rd scenarios are not allowed and user *MUST* declare > all the phy's in the DTSI, then I can go ahead and remove these > properties and count them in the driver code. Why you cannot then configure all phys in the driver all ports as some safe default and then customize it depending on the actual port used? Best regards, Krzysztof
On 1/17/2023 4:32 PM, Krzysztof Kozlowski wrote: > On 17/01/2023 10:01, Krishna Kurapati PSSNV wrote: >> >> >> On 1/16/2023 10:04 PM, Rob Herring wrote: >>> On Sun, Jan 15, 2023 at 05:11:42PM +0530, Krishna Kurapati wrote: >>>> Add bindings to indicate properties required to support multiport >>>> on Snps Dwc3 controller. >>>> >>>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> >>>> --- >>>> .../devicetree/bindings/usb/snps,dwc3.yaml | 53 ++++++++++++++++--- >>>> 1 file changed, 47 insertions(+), 6 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >>>> index 6d78048c4613..3ea051beb2f8 100644 >>>> --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >>>> +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml >>>> @@ -81,15 +81,26 @@ properties: >>>> >>>> phys: >>>> minItems: 1 >>>> - maxItems: 2 >>>> + maxItems: 8 >>>> >>>> phy-names: >>>> minItems: 1 >>>> - maxItems: 2 >>>> - items: >>>> - enum: >>>> - - usb2-phy >>>> - - usb3-phy >>>> + maxItems: 8 >>>> + oneOf: >>>> + - items: >>>> + enum: >>>> + - usb2-phy >>>> + - usb3-phy >>>> + - items: >>>> + enum: >>>> + - usb2-phy_port0 >>>> + - usb2-phy_port1 >>>> + - usb2-phy_port2 >>>> + - usb2-phy_port3 >>>> + - usb3-phy_port0 >>>> + - usb3-phy_port1 >>>> + - usb3-phy_port2 >>>> + - usb3-phy_port3 >>> >>> usbN-portM >>> >>>> >>>> resets: >>>> minItems: 1 >>>> @@ -360,6 +371,22 @@ properties: >>>> description: >>>> Enable USB remote wakeup. >>>> >>>> + num-ports: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + This property indicates the number of ports present on the target that >>>> + are to be serviced by the DWC3 controller. >>>> + minimum: 1 >>>> + maximum: 4 >>>> + >>>> + num-ss-ports: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + This property indicates the number of SS capable ports present on the >>>> + target that are to be serviced by the DWC3 controller. >>>> + minimum: 1 >>>> + maximum: 4 >>> >>> This information is redundant. 'phy-names' tells you how many ports of >>> each. >>> >> Hi Rob, >> >> Thanks for the review. The reason I wanted to introduce two more >> variables is to get info on number of ports and ss-capable ports >> present on hardware whether or not the user provides them in DTSI file. >> >> In the code there are two types of per port / per phy operations: >> a) Modifying GUSB2PFYCFG and GUSB3PIPECTL registers per phy. >> b) Generic Phy operations - per phy. >> >> In today's code, if someone doesn't mention the SSPHY in DTSI, >> dwc->usb3_generic_phy will be NULL and any call to phy operations will >> just bail out. And irrespective of whether we provide SS Phy in DTSI or >> not, we still configure GUSB3PIPECTL register. >> >> Consider the following cases: >> >> 1. There are 3 ports and 2 of them are SS capable and all phy's are >> mentioned in DTSI. >> >> phy-names= "usb2-port0", "usb3-port0", "usb2-port1", "usb3-port1", >> "usb2-port2" >> >> When we count them in the driver, we get num ports as 3 (presuming >> num-ports = num of hs ports) and num-ss-ports = 2. >> >> Since there is no ambiguity in which all ports to configure, we can >> modify GUSB2PHYCFG registers for all 3 HS Phy's and GUSB3PIPECTL for >> both SS Phy's. >> This is a proper scenario. >> >> 2. If the user skips providing SS Phy on Port-0, then: >> >> phy-names= "usb2-port0", "usb2-port1", "usb3-port1", "usb2-port2" >> >> If we count the phys, we end up getting num-ports=3 and num-ss-ports=1. >> >> Since in the driver code, we are not keeping track of which ports are SS >> capable and which ones are not, we end up configuring >> GUSB2PIPECTL(port-0) instead of port-1 as the num-ss-ports is "1" which >> is incorrect. >> >> 3. If the user skips providing one complete port, in this case port-1 is >> skipped, then: >> >> phy-names= "usb2-port0", "usb3-port0", "usb2-port2" >> >> If we count the phys, we end up getting num-ports=2 and num-ss-ports=1. >> >> Since in the driver code, we are not keeping track of which ports are SS >> capable and which ones are not, we end up configuring >> GUSB2PHYCFG(port-0) and GUSB2PHYCFG(port-1) instead of port-2 which is >> incorrect. > > Why? You know you have port-2 from the phy name, so why would you ignore > this information? > Hi Krzysztof, Thanks for the review, The concern I had with that approach is that, we need to keep track of per port supported speeds in some array /flags and check them whenever we are modifying the dwc3-phy registers. This makes the code a little unreadable. >> >> To avoid these scenarios, if we can get the exact number of SS Ports and >> Ports in total present on the HW, we can configure all the registers >> whether the phy's are provided in DTSI or not. (This is of no harm I >> believe as it still works in today's code) > > Doesn't the driver know how many phys it has in such case through > respective compatible? > The core driver has only one compatible currently "snps,dwc3". Are you suggesting to add new compatible to driver core in case any multiport device is being used and get this info from there ? >> >> Incase the 2nd and 3rd scenarios are not allowed and user *MUST* declare >> all the phy's in the DTSI, then I can go ahead and remove these >> properties and count them in the driver code. > > > Why you cannot then configure all phys in the driver all ports as some > safe default and then customize it depending on the actual port used? > To do this, we still need to get info on number of hs/ss phy's present on hardware and currently there is no register I believe in DWC3 core global address space that can give this info. I see that HCSPARAMS1 Reg gives some info but that is not accessible from driver core. According to databook: "Number of Ports (MaxPorts) -> Number of ports implemented is defined by the parameter (`DWC_USB3_HOST_NUM_U2_ROOT_PORTS + `DWC_USB3_HOST_NUM_U3_ROOT_PORTS) -> Number of ports enabled is controlled by the core input signals host_num_u2_port[3:0]+host_num_u3_port[3:0]" Regards, Krishna,
On Sun, Jan 15, 2023 at 05:11:42PM +0530, Krishna Kurapati wrote: > diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml [..] > phy-names: > minItems: 1 > - maxItems: 2 > - items: > - enum: > - - usb2-phy > - - usb3-phy > + maxItems: 8 > + oneOf: > + - items: > + enum: > + - usb2-phy > + - usb3-phy > + - items: > + enum: > + - usb2-phy_port0 > + - usb2-phy_port1 > + - usb2-phy_port2 > + - usb2-phy_port3 > + - usb3-phy_port0 > + - usb3-phy_port1 > + - usb3-phy_port2 > + - usb3-phy_port3 How about expressing this as: oneOf: - items: enum: [ usb2-phy, usb3-phy ] - items: pattern: "^usb[23]-phy_port[0-3]$" Regards, Bjorn
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 6d78048c4613..3ea051beb2f8 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -81,15 +81,26 @@ properties: phys: minItems: 1 - maxItems: 2 + maxItems: 8 phy-names: minItems: 1 - maxItems: 2 - items: - enum: - - usb2-phy - - usb3-phy + maxItems: 8 + oneOf: + - items: + enum: + - usb2-phy + - usb3-phy + - items: + enum: + - usb2-phy_port0 + - usb2-phy_port1 + - usb2-phy_port2 + - usb2-phy_port3 + - usb3-phy_port0 + - usb3-phy_port1 + - usb3-phy_port2 + - usb3-phy_port3 resets: minItems: 1 @@ -360,6 +371,22 @@ properties: description: Enable USB remote wakeup. + num-ports: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This property indicates the number of ports present on the target that + are to be serviced by the DWC3 controller. + minimum: 1 + maximum: 4 + + num-ss-ports: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + This property indicates the number of SS capable ports present on the + target that are to be serviced by the DWC3 controller. + minimum: 1 + maximum: 4 + unevaluatedProperties: false required: @@ -388,4 +415,18 @@ examples: snps,dis_u2_susphy_quirk; snps,dis_enblslpm_quirk; }; + - | + usb@4a000000 { + compatible = "snps,dwc3"; + reg = <0x4a000000 0xcfff>; + interrupts = <0 92 4>; + clocks = <&clk 1>, <&clk 2>, <&clk 3>; + clock-names = "bus_early", "ref", "suspend"; + num-ports = <2>; + num-ss-ports = <1>; + phys = <&usb2_phy0>, <&usb3_phy0>, <&usb2_phy1>; + phy-names = "usb2-phy_port0", "usb3-phy_port0", "usb2-phy_port1"; + snps,dis_u2_susphy_quirk; + snps,dis_enblslpm_quirk; + }; ...
Add bindings to indicate properties required to support multiport on Snps Dwc3 controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> --- .../devicetree/bindings/usb/snps,dwc3.yaml | 53 ++++++++++++++++--- 1 file changed, 47 insertions(+), 6 deletions(-)