| Message ID | 20171008211713.18696-2-martin.blumenstingl@googlemail.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Sun, Oct 8, 2017 at 11:17 PM, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: > A USB root-hub may have several PHYs which need to be configured before > the root-hub starts working. > This adds the documentation for such a USB root-hub as well as a hint > regarding the child-nodes on XHCI controllers which can include the > roothub. > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> > Acked-by: Rob Herring <robh@kernel.org> Have you checked that this still works with DT properties on a USB device that is listed in the DT? A common use-case is to provide the MAC address of a soldered-down USB-ethernet that lacks its own eeprom, and it seems you are changing the way the parent devices of that get represented, so the dev->of_node pointer in the USB device might no longer refer to the correct device. Arnd
Hi Arnd, thank you for reviewing this patch! On Mon, Oct 9, 2017 at 12:24 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Sun, Oct 8, 2017 at 11:17 PM, Martin Blumenstingl > <martin.blumenstingl@googlemail.com> wrote: >> A USB root-hub may have several PHYs which need to be configured before >> the root-hub starts working. >> This adds the documentation for such a USB root-hub as well as a hint >> regarding the child-nodes on XHCI controllers which can include the >> roothub. >> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> >> Acked-by: Rob Herring <robh@kernel.org> > > Have you checked that this still works with DT properties on a USB device > that is listed in the DT? A common use-case is to provide the MAC address > of a soldered-down USB-ethernet that lacks its own eeprom, and it seems > you are changing the way the parent devices of that get represented, > so the dev->of_node pointer in the USB device might no longer refer > to the correct device. I haven't tested the described use-case. however, this patch is not supposed to change the binding for actual devices. USB device numbering starts at 1, while 0 is reserved for the root-hub (at least from what I know). before this patch there was no way to describe the root-hub via .dts. this however is required for some platforms that need to set up a PHY for each port on the root-hub (Amlogic Meson GXL platform is one example: there are two ports enabled on dwc3's root-hub with 2x USB2 and 1x USB3 PHYs) - so this patch uses a similar binding as we already have (to describe the devices) to describe the root-hub Regards, Martin
On Thu, 12 Oct 2017, Martin Blumenstingl wrote: > I haven't tested the described use-case. however, this patch is not > supposed to change the binding for actual devices. > USB device numbering starts at 1, while 0 is reserved for the root-hub > (at least from what I know). Actually 1 is reserved for the root hub. External devices are numbered starting from 2. (We can't use 0 for the root hub because, as you said, USB device numbering starts at 1!) Alan Stern > before this patch there was no way to > describe the root-hub via .dts. this however is required for some > platforms that need to set up a PHY for each port on the root-hub > (Amlogic Meson GXL platform is one example: there are two ports > enabled on dwc3's root-hub with 2x USB2 and 1x USB3 PHYs) - so this > patch uses a similar binding as we already have (to describe the > devices) to describe the root-hub > > > Regards, > Martin > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > >
Hi Alan, On Thu, Oct 12, 2017 at 11:17 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 12 Oct 2017, Martin Blumenstingl wrote: > >> I haven't tested the described use-case. however, this patch is not >> supposed to change the binding for actual devices. >> USB device numbering starts at 1, while 0 is reserved for the root-hub >> (at least from what I know). > > Actually 1 is reserved for the root hub. External devices are numbered > starting from 2. (We can't use 0 for the root hub because, as you > said, USB device numbering starts at 1!) I just had a look at lsusb again: $ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M however, for the devicetree bindings the devices are supposed to use 1-31: [0] Alan: just to make sure I understood you correctly: do you agree with this patch? > Alan Stern > >> before this patch there was no way to >> describe the root-hub via .dts. this however is required for some >> platforms that need to set up a PHY for each port on the root-hub >> (Amlogic Meson GXL platform is one example: there are two ports >> enabled on dwc3's root-hub with 2x USB2 and 1x USB3 PHYs) - so this >> patch uses a similar binding as we already have (to describe the >> devices) to describe the root-hub >> >> >> Regards, >> Martin >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > Regards, Martin [0] http://elixir.free-electrons.com/linux/v4.14-rc4/source/Documentation/devicetree/bindings/usb/usb-device.txt
On Thu, 12 Oct 2017, Martin Blumenstingl wrote: > Hi Alan, > > On Thu, Oct 12, 2017 at 11:17 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > > On Thu, 12 Oct 2017, Martin Blumenstingl wrote: > > > >> I haven't tested the described use-case. however, this patch is not > >> supposed to change the binding for actual devices. > >> USB device numbering starts at 1, while 0 is reserved for the root-hub > >> (at least from what I know). > > > > Actually 1 is reserved for the root hub. External devices are numbered > > starting from 2. (We can't use 0 for the root hub because, as you > > said, USB device numbering starts at 1!) > I just had a look at lsusb again: > $ lsusb -t > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M > > however, for the devicetree bindings the devices are supposed to use 1-31: [0] > > Alan: just to make sure I understood you correctly: do you agree with > this patch? I have no idea. I haven't read the patch and I'm not familiar with the details of DeviceTree. I was just trying to clear up your misunderstanding of USB device numbering. Alan Stern
Hi Alan, On Fri, Oct 13, 2017 at 4:15 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 12 Oct 2017, Martin Blumenstingl wrote: > >> Hi Alan, >> >> On Thu, Oct 12, 2017 at 11:17 PM, Alan Stern <stern@rowland.harvard.edu> wrote: >> > On Thu, 12 Oct 2017, Martin Blumenstingl wrote: >> > >> >> I haven't tested the described use-case. however, this patch is not >> >> supposed to change the binding for actual devices. >> >> USB device numbering starts at 1, while 0 is reserved for the root-hub >> >> (at least from what I know). >> > >> > Actually 1 is reserved for the root hub. External devices are numbered >> > starting from 2. (We can't use 0 for the root hub because, as you >> > said, USB device numbering starts at 1!) >> I just had a look at lsusb again: >> $ lsusb -t >> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M >> >> however, for the devicetree bindings the devices are supposed to use 1-31: [0] >> >> Alan: just to make sure I understood you correctly: do you agree with >> this patch? > > I have no idea. I haven't read the patch and I'm not familiar with the > details of DeviceTree. I was just trying to clear up your > misunderstanding of USB device numbering. thank you for clarifying this. I tested it and the devicetree numbering is "off by one" compared to the lsusb output - this however has nothing to do with my patch. so my previous statements that basically said "0 is used for the roothub" should be "0 is used for the roothub in .dts/.dtsi files" Regards, Martin
diff --git a/Documentation/devicetree/bindings/usb/usb-roothub.txt b/Documentation/devicetree/bindings/usb/usb-roothub.txt new file mode 100644 index 000000000000..fc0797d7cee9 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-roothub.txt @@ -0,0 +1,46 @@ +Generic USB root-hub Properties + +similar to the USB device bindings (documented in usb-device.txt from the +current directory) this provides support for configuring the root-hub. + +Required properties: +- compatible: should be at least one of "usb1d6b,3", "usb1d6b,2" +- reg: must be 0. +- address-cells: must be 1 +- size-cells: must be 0 + +Required sub-nodes: +a sub-node per actual USB port is required. each sub-node supports the +following properties: + Required properties: + - reg: the port number on the root-hub (mandatory) + Optional properties: + - phys: optional, from the *Generic PHY* bindings (mandatory needed + when phy-names is given) + - phy-names: optional, from the *Generic PHY* bindings; supported names + are "usb2-phy" or "usb3-phy" + +Example: + &usb1 { + #address-cells = <1>; + #size-cells = <0>; + + roothub@0 { + compatible = "usb1d6b,3", "usb1d6b,2"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + port@1 { + reg = <1>; + phys = <&usb2_phy1>, <&usb3_phy1>; + phy-names = "usb2-phy", "usb3-phy"; + }; + + port@2 { + reg = <2>; + phys = <&usb2_phy2>, <&usb3_phy2>; + phy-names = "usb2-phy", "usb3-phy"; + }; + }; + } diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index ae6e484a8d7c..5b49ba9f2f9a 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -30,6 +30,13 @@ Optional properties: - usb3-lpm-capable: determines if platform is USB3 LPM capable - quirk-broken-port-ped: set if the controller has broken port disable mechanism +sub-nodes: +- optionally there can be a node for the root-hub, see usb-roothub.txt in the + current directory +- one or more nodes with reg 1-31 for each port to which a device is connected. + See usb-device.txt in the current directory for more information. + + Example: usb@f0931000 { compatible = "generic-xhci";