| Message ID | 20220712150627.1444761-1-alexander.stein@ew.tq-group.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/3] dt-bindings: usb: Add binding for TI USB8041 hub controller | expand |
Hi Alexander, On Tue, Jul 12, 2022 at 05:06:25PM +0200, Alexander Stein wrote: > The TI USB8041 is a USB 3.0 hub controller with 4 ports. > > This initial version of the binding only describes USB related aspects > of the USB8041, it does not cover the option of connecting the controller > as an i2c slave. > > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > --- > Well, this is essentially a ripoff of > Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs > replaced, reset-gpio added and example adjusted. > IMHO this should be merged together with realtek,rts5411.yaml. Is it ok > to rename bindings files? I guess a common onboard-usb-hub.yaml matching > the driver seens reasonable. Any recommendations how to proceed? It's a tradeoff between keeping the individual bindings simple and avoid unnecessary duplication. The current RTS5411 and TI USB8041 bindings are very similar, which suggests combining them. However over time hubs with diverging features could be added (e.g. with multiple regulators, a link to an I2C/SPI bus, a clock, ...). With that a common binding might become too messy. From a quick look through Documentation/devicetree/bindings it doesn't seem common to have generic bindings that cover components from multiple vendors. In that sense I'm leaning towards separate bindings. Rob, do you have any particular preference or suggestion? m. > .../devicetree/bindings/usb/ti,usb8041.yaml | 69 +++++++++++++++++++ > 1 file changed, 69 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > new file mode 100644 > index 000000000000..9a49d60527b1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > @@ -0,0 +1,69 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Binding for the TI USB8041 USB 3.0 hub controller > + > +maintainers: > + - Matthias Kaehlcke <mka@chromium.org> > + > +allOf: > + - $ref: usb-device.yaml# > + > +properties: > + compatible: > + items: > + - enum: > + - usb451,8140 > + - usb451,8142 > + > + reg: true > + > + reset-gpio: > + maxItems: 1 > + description: > + GPIO specifier for GSRT# pin. > + > + vdd-supply: > + description: > + phandle to the regulator that provides power to the hub. > + > + peer-hub: > + $ref: '/schemas/types.yaml#/definitions/phandle' > + description: > + phandle to the peer hub on the controller. > + > +required: > + - peer-hub > + - compatible > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/gpio/gpio.h> > + > + usb { > + dr_mode = "host"; > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* 2.0 hub on port 1 */ > + hub_2_0: hub@1 { > + compatible = "usb451,8142"; > + reg = <1>; > + peer-hub = <&hub_3_0>; > + reset-gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; > + }; > + > + /* 3.0 hub on port 2 */ > + hub_3_0: hub@2 { > + compatible = "usb451,8140"; > + reg = <2>; > + peer-hub = <&hub_2_0>; > + reset-gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; > + }; > + }; > -- > 2.25.1 >
On 12/07/2022 19:25, Matthias Kaehlcke wrote: > Hi Alexander, > > On Tue, Jul 12, 2022 at 05:06:25PM +0200, Alexander Stein wrote: >> The TI USB8041 is a USB 3.0 hub controller with 4 ports. >> >> This initial version of the binding only describes USB related aspects >> of the USB8041, it does not cover the option of connecting the controller >> as an i2c slave. >> >> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> >> --- >> Well, this is essentially a ripoff of >> Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs >> replaced, reset-gpio added and example adjusted. >> IMHO this should be merged together with realtek,rts5411.yaml. Is it ok >> to rename bindings files? I guess a common onboard-usb-hub.yaml matching >> the driver seens reasonable. Any recommendations how to proceed? > > It's a tradeoff between keeping the individual bindings simple and avoid > unnecessary duplication. The current RTS5411 and TI USB8041 bindings are > very similar, which suggests combining them. However over time hubs with > diverging features could be added (e.g. with multiple regulators, a link > to an I2C/SPI bus, a clock, ...). With that a common binding might become > too messy. > > From a quick look through Documentation/devicetree/bindings it doesn't > seem common to have generic bindings that cover components from multiple > vendors. In that sense I'm leaning towards separate bindings. > > Rob, do you have any particular preference or suggestion? Not Rob, but my suggestion is not to merge bindings of unrelated devices, even if they are the same class. By unrelated I mean, made by different companies, designed differently and having nothing in common by design. Bindings can be still similar, but should not be merged just because they are similar. Best regards, Krzysztof
On 12/07/2022 17:06, Alexander Stein wrote: > The TI USB8041 is a USB 3.0 hub controller with 4 ports. > > This initial version of the binding only describes USB related aspects > of the USB8041, it does not cover the option of connecting the controller > as an i2c slave. > > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > --- > Well, this is essentially a ripoff of > Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs > replaced, reset-gpio added and example adjusted. > IMHO this should be merged together with realtek,rts5411.yaml. Is it ok > to rename bindings files? I guess a common onboard-usb-hub.yaml matching > the driver seens reasonable. Any recommendations how to proceed? > > .../devicetree/bindings/usb/ti,usb8041.yaml | 69 +++++++++++++++++++ > 1 file changed, 69 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > new file mode 100644 > index 000000000000..9a49d60527b1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > @@ -0,0 +1,69 @@ > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Binding for the TI USB8041 USB 3.0 hub controller > + > +maintainers: > + - Matthias Kaehlcke <mka@chromium.org> > + > +allOf: > + - $ref: usb-device.yaml# > + > +properties: > + compatible: > + items: No items. It's just one item. > + - enum: > + - usb451,8140 > + - usb451,8142 > + > + reg: true > + > + reset-gpio: reset-gpios > + maxItems: 1 > + description: > + GPIO specifier for GSRT# pin. Combine maxItems and above into: items: - description: GPIO specifier for GSRT# pin. > + > + vdd-supply: > + description: > + phandle to the regulator that provides power to the hub. s/phandle to the regulator that provides// and create some nice sentence from left-over, like "VDD power supply to the hub" > + > + peer-hub: > + $ref: '/schemas/types.yaml#/definitions/phandle' No quotes. > + description: > + phandle to the peer hub on the controller. > + > +required: > + - peer-hub > + - compatible > + - reg Messed order. Use same as they appear in properties, so compatible+reg+peer-hub. But another question - why "peer-hub"? I remember some discussion about naming, so was peer preferred over companion? > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/gpio/gpio.h> > + > + usb { > + dr_mode = "host"; > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* 2.0 hub on port 1 */ > + hub_2_0: hub@1 { > + compatible = "usb451,8142"; > + reg = <1>; > + peer-hub = <&hub_3_0>; > + reset-gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; reset-gpios Best regards, Krzysztof
On Tue, Jul 12, 2022 at 11:12:06PM +0200, Krzysztof Kozlowski wrote: > On 12/07/2022 19:25, Matthias Kaehlcke wrote: > > Hi Alexander, > > > > On Tue, Jul 12, 2022 at 05:06:25PM +0200, Alexander Stein wrote: > >> The TI USB8041 is a USB 3.0 hub controller with 4 ports. > >> > >> This initial version of the binding only describes USB related aspects > >> of the USB8041, it does not cover the option of connecting the controller > >> as an i2c slave. > >> > >> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > >> --- > >> Well, this is essentially a ripoff of > >> Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs > >> replaced, reset-gpio added and example adjusted. > >> IMHO this should be merged together with realtek,rts5411.yaml. Is it ok > >> to rename bindings files? I guess a common onboard-usb-hub.yaml matching > >> the driver seens reasonable. Any recommendations how to proceed? > > > > It's a tradeoff between keeping the individual bindings simple and avoid > > unnecessary duplication. The current RTS5411 and TI USB8041 bindings are > > very similar, which suggests combining them. However over time hubs with > > diverging features could be added (e.g. with multiple regulators, a link > > to an I2C/SPI bus, a clock, ...). With that a common binding might become > > too messy. > > > > From a quick look through Documentation/devicetree/bindings it doesn't > > seem common to have generic bindings that cover components from multiple > > vendors. In that sense I'm leaning towards separate bindings. > > > > Rob, do you have any particular preference or suggestion? > > Not Rob, but my suggestion is not to merge bindings of unrelated > devices, even if they are the same class. By unrelated I mean, made by > different companies, designed differently and having nothing in common > by design. Bindings can be still similar, but should not be merged just > because they are similar. Thanks for your advice, let's keep separate bindings then.
On Tue, Jul 12, 2022 at 11:16:21PM +0200, Krzysztof Kozlowski wrote: > On 12/07/2022 17:06, Alexander Stein wrote: > > The TI USB8041 is a USB 3.0 hub controller with 4 ports. > > > > This initial version of the binding only describes USB related aspects > > of the USB8041, it does not cover the option of connecting the controller > > as an i2c slave. > > > > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > > --- > > Well, this is essentially a ripoff of > > Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs > > replaced, reset-gpio added and example adjusted. > > IMHO this should be merged together with realtek,rts5411.yaml. Is it ok > > to rename bindings files? I guess a common onboard-usb-hub.yaml matching > > the driver seens reasonable. Any recommendations how to proceed? > > > > .../devicetree/bindings/usb/ti,usb8041.yaml | 69 +++++++++++++++++++ > > 1 file changed, 69 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > > > diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > new file mode 100644 > > index 000000000000..9a49d60527b1 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > @@ -0,0 +1,69 @@ > > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Binding for the TI USB8041 USB 3.0 hub controller > > + > > +maintainers: > > + - Matthias Kaehlcke <mka@chromium.org> > > + > > +allOf: > > + - $ref: usb-device.yaml# > > + > > +properties: > > + compatible: > > + items: > > No items. It's just one item. > > > + - enum: > > + - usb451,8140 > > + - usb451,8142 > > + > > + reg: true > > + > > + reset-gpio: > > reset-gpios > > > + maxItems: 1 > > + description: > > + GPIO specifier for GSRT# pin. > > Combine maxItems and above into: > items: > - description: GPIO specifier for GSRT# pin. > > > + > > + vdd-supply: > > + description: > > + phandle to the regulator that provides power to the hub. > > s/phandle to the regulator that provides// > and create some nice sentence from left-over, like "VDD power supply to > the hub" > > > > + > > + peer-hub: > > + $ref: '/schemas/types.yaml#/definitions/phandle' > > No quotes. > > > + description: > > + phandle to the peer hub on the controller. > > + > > +required: > > + - peer-hub > > + - compatible > > + - reg > > Messed order. Use same as they appear in properties, so > compatible+reg+peer-hub. > > But another question - why "peer-hub"? I remember some discussion about > naming, so was peer preferred over companion? Yes, Alan Stern pointed out that 'companion' can be confusing in the context of USB: What do you mean by "companion hub"? I think you are using the wrong word here. If you're talking about the relation between the two logical hubs (one attached to the SuperSpeed bus and one attached to the Low/Full/High-speed bus) within a physical USB-3 hub, the correct term for this is "peer". See the existing usages in hub.h, hub.c, and port.c. "Companion" refers to something completely different (i.e., the UHCI or OHCI controllers that handle Low/Full-speed connections on behalf of a High-speed EHCI controller). https://patchwork.kernel.org/comment/24912563/
On 12/07/2022 23:25, Matthias Kaehlcke wrote: > On Tue, Jul 12, 2022 at 11:12:06PM +0200, Krzysztof Kozlowski wrote: >> On 12/07/2022 19:25, Matthias Kaehlcke wrote: >>> Hi Alexander, >>> >>> On Tue, Jul 12, 2022 at 05:06:25PM +0200, Alexander Stein wrote: >>>> The TI USB8041 is a USB 3.0 hub controller with 4 ports. >>>> >>>> This initial version of the binding only describes USB related aspects >>>> of the USB8041, it does not cover the option of connecting the controller >>>> as an i2c slave. >>>> >>>> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> >>>> --- >>>> Well, this is essentially a ripoff of >>>> Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs >>>> replaced, reset-gpio added and example adjusted. >>>> IMHO this should be merged together with realtek,rts5411.yaml. Is it ok >>>> to rename bindings files? I guess a common onboard-usb-hub.yaml matching >>>> the driver seens reasonable. Any recommendations how to proceed? >>> >>> It's a tradeoff between keeping the individual bindings simple and avoid >>> unnecessary duplication. The current RTS5411 and TI USB8041 bindings are >>> very similar, which suggests combining them. However over time hubs with >>> diverging features could be added (e.g. with multiple regulators, a link >>> to an I2C/SPI bus, a clock, ...). With that a common binding might become >>> too messy. >>> >>> From a quick look through Documentation/devicetree/bindings it doesn't >>> seem common to have generic bindings that cover components from multiple >>> vendors. In that sense I'm leaning towards separate bindings. >>> >>> Rob, do you have any particular preference or suggestion? >> >> Not Rob, but my suggestion is not to merge bindings of unrelated >> devices, even if they are the same class. By unrelated I mean, made by >> different companies, designed differently and having nothing in common >> by design. Bindings can be still similar, but should not be merged just >> because they are similar. > > Thanks for your advice, let's keep separate bindings then. Although for the record let me add that we did merge some trivial hwmon devices like LM75 or LM90 but their bindings are trivial and programming model is also similar between each other (handled by same device driver). I guess we can be here flexible, so the question would be how similar these USB hubs are. If in doubt, just keep it separate. Best regards, Krzysztof
On 12/07/2022 23:28, Matthias Kaehlcke wrote: >> >> But another question - why "peer-hub"? I remember some discussion about >> naming, so was peer preferred over companion? > > Yes, Alan Stern pointed out that 'companion' can be confusing in the context > of USB: > > What do you mean by "companion hub"? I think you are using the wrong > word here. If you're talking about the relation between the two logical > hubs (one attached to the SuperSpeed bus and one attached to the > Low/Full/High-speed bus) within a physical USB-3 hub, the correct term > for this is "peer". See the existing usages in hub.h, hub.c, and > port.c. > > "Companion" refers to something completely different (i.e., the UHCI or > OHCI controllers that handle Low/Full-speed connections on behalf of a > High-speed EHCI controller). > > https://patchwork.kernel.org/comment/24912563/ Thanks, that explains a lot! Best regards, Krzysztof
Hello Krzysztof, Am Dienstag, 12. Juli 2022, 23:32:12 CEST schrieb Krzysztof Kozlowski: > On 12/07/2022 23:25, Matthias Kaehlcke wrote: > > On Tue, Jul 12, 2022 at 11:12:06PM +0200, Krzysztof Kozlowski wrote: > >> On 12/07/2022 19:25, Matthias Kaehlcke wrote: > >>> Hi Alexander, > >>> > >>> On Tue, Jul 12, 2022 at 05:06:25PM +0200, Alexander Stein wrote: > >>>> The TI USB8041 is a USB 3.0 hub controller with 4 ports. > >>>> > >>>> This initial version of the binding only describes USB related aspects > >>>> of the USB8041, it does not cover the option of connecting the > >>>> controller > >>>> as an i2c slave. > >>>> > >>>> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > >>>> --- > >>>> Well, this is essentially a ripoff of > >>>> Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs > >>>> replaced, reset-gpio added and example adjusted. > >>>> IMHO this should be merged together with realtek,rts5411.yaml. Is it ok > >>>> to rename bindings files? I guess a common onboard-usb-hub.yaml > >>>> matching > >>>> the driver seens reasonable. Any recommendations how to proceed? > >>> > >>> It's a tradeoff between keeping the individual bindings simple and avoid > >>> unnecessary duplication. The current RTS5411 and TI USB8041 bindings are > >>> very similar, which suggests combining them. However over time hubs with > >>> diverging features could be added (e.g. with multiple regulators, a link > >>> to an I2C/SPI bus, a clock, ...). With that a common binding might > >>> become > >>> too messy. > >>> > >>> From a quick look through Documentation/devicetree/bindings it doesn't > >>> seem common to have generic bindings that cover components from multiple > >>> vendors. In that sense I'm leaning towards separate bindings. > >>> > >>> Rob, do you have any particular preference or suggestion? > >> > >> Not Rob, but my suggestion is not to merge bindings of unrelated > >> devices, even if they are the same class. By unrelated I mean, made by > >> different companies, designed differently and having nothing in common > >> by design. Bindings can be still similar, but should not be merged just > >> because they are similar. > > > > Thanks for your advice, let's keep separate bindings then. Ok, thanks for the feedback. > Although for the record let me add that we did merge some trivial hwmon > devices like LM75 or LM90 but their bindings are trivial and programming > model is also similar between each other (handled by same device > driver). I guess we can be here flexible, so the question would be how > similar these USB hubs are. > > If in doubt, just keep it separate. Right now it might seem sensible to have the bindings merged, as the features are quite similar. But things might change, if/once i2c support is added. So this is one additional matter to keep them separated. Best regards, Alexander
Hi Krzysztof, thanks for the feedback on DT bindings. Am Dienstag, 12. Juli 2022, 23:16:21 CEST schrieb Krzysztof Kozlowski: > On 12/07/2022 17:06, Alexander Stein wrote: > > The TI USB8041 is a USB 3.0 hub controller with 4 ports. > > > > This initial version of the binding only describes USB related aspects > > of the USB8041, it does not cover the option of connecting the controller > > as an i2c slave. > > > > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> > > --- > > Well, this is essentially a ripoff of > > Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs > > replaced, reset-gpio added and example adjusted. > > IMHO this should be merged together with realtek,rts5411.yaml. Is it ok > > to rename bindings files? I guess a common onboard-usb-hub.yaml matching > > the driver seens reasonable. Any recommendations how to proceed? > > > > .../devicetree/bindings/usb/ti,usb8041.yaml | 69 +++++++++++++++++++ > > 1 file changed, 69 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > > > diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml new file mode > > 100644 > > index 000000000000..9a49d60527b1 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > > @@ -0,0 +1,69 @@ > > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Binding for the TI USB8041 USB 3.0 hub controller > > + > > +maintainers: > > + - Matthias Kaehlcke <mka@chromium.org> > > + > > +allOf: > > + - $ref: usb-device.yaml# > > + > > +properties: > > + compatible: > > > + items: > No items. It's just one item. Sure, will change. > > + - enum: > > + - usb451,8140 > > + - usb451,8142 > > + > > + reg: true > > + > > > + reset-gpio: > reset-gpios Will change. > > + maxItems: 1 > > + description: > > + GPIO specifier for GSRT# pin. > > Combine maxItems and above into: > items: > - description: GPIO specifier for GSRT# pin. Will change, looks much nicer. > > + > > + vdd-supply: > > + description: > > + phandle to the regulator that provides power to the hub. > > s/phandle to the regulator that provides// > and create some nice sentence from left-over, like "VDD power supply to > the hub" Thanks for that suggestion. Will change. > > + > > + peer-hub: > > + $ref: '/schemas/types.yaml#/definitions/phandle' > > No quotes. Sure, will do so. > > + description: > > + phandle to the peer hub on the controller. > > + > > +required: > > + - peer-hub > > + - compatible > > + - reg > > Messed order. Use same as they appear in properties, so > compatible+reg+peer-hub. > > But another question - why "peer-hub"? I remember some discussion about > naming, so was peer preferred over companion? > > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include <dt-bindings/gpio/gpio.h> > > + > > + usb { > > + dr_mode = "host"; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + /* 2.0 hub on port 1 */ > > + hub_2_0: hub@1 { > > + compatible = "usb451,8142"; > > + reg = <1>; > > + peer-hub = <&hub_3_0>; > > + reset-gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; > > reset-gpios Yes, 'make dt_binding_check' does not raise any error about this binding. Thanks and best regards, Alexander
On 13/07/2022 09:20, Alexander Stein wrote:
> Yes, 'make dt_binding_check' does not raise any error about this binding.
Yes, I know. reset-gpio is still accepted, but the preferred (and
documented) naming for all GPIO properties is always "-gpios", even for
one-GPIO properties.
Best regards,
Krzysztof
diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml new file mode 100644 index 000000000000..9a49d60527b1 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for the TI USB8041 USB 3.0 hub controller + +maintainers: + - Matthias Kaehlcke <mka@chromium.org> + +allOf: + - $ref: usb-device.yaml# + +properties: + compatible: + items: + - enum: + - usb451,8140 + - usb451,8142 + + reg: true + + reset-gpio: + maxItems: 1 + description: + GPIO specifier for GSRT# pin. + + vdd-supply: + description: + phandle to the regulator that provides power to the hub. + + peer-hub: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: + phandle to the peer hub on the controller. + +required: + - peer-hub + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + usb { + dr_mode = "host"; + #address-cells = <1>; + #size-cells = <0>; + + /* 2.0 hub on port 1 */ + hub_2_0: hub@1 { + compatible = "usb451,8142"; + reg = <1>; + peer-hub = <&hub_3_0>; + reset-gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; + }; + + /* 3.0 hub on port 2 */ + hub_3_0: hub@2 { + compatible = "usb451,8140"; + reg = <2>; + peer-hub = <&hub_2_0>; + reset-gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; + }; + };
The TI USB8041 is a USB 3.0 hub controller with 4 ports. This initial version of the binding only describes USB related aspects of the USB8041, it does not cover the option of connecting the controller as an i2c slave. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> --- Well, this is essentially a ripoff of Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs replaced, reset-gpio added and example adjusted. IMHO this should be merged together with realtek,rts5411.yaml. Is it ok to rename bindings files? I guess a common onboard-usb-hub.yaml matching the driver seens reasonable. Any recommendations how to proceed? .../devicetree/bindings/usb/ti,usb8041.yaml | 69 +++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/ti,usb8041.yaml