On Friday 22 January 2016 10:55:01 Alan Stern wrote:
> On Fri, 22 Jan 2016, Arnd Bergmann wrote:
>
> > > > hub@3 { /* same external hub, highspeed mode */
> > > > compatible = "usb2109,0812.591",
> > > > "usb2109,0812",
> > > > "usb2109,class9.0.1",
> > > > "usb2109,class9.0",
> > > > "usb2109,class9";
> > > >
> > > > #address-cells = <1>;
> > > > #size-cells = <0>;
> > > > reg = <3>;
> > > >
> > >
> > > Why "reg" is 3 here?
> >
> > My mistake. It should be hub@1 and reg=<1>;
> >
> > I accidentally confused the port number and the device number.
>
> I thought you did it this way because you were numbering the SS
> root-hub ports 1-2 and the HS root-hub ports 3-4.
Right, I was confusing myself after the question. It was intentional
after all.
> There's something I should have made clear earlier. This scheme for
> putting SS and HS USB-3 root-hub ports in the same number space is part
> of the xHCI spec. It's not AFAIK required (or even mentioned) by the
> USB-3 spec, which means other types of USB-3 host controllers might do
> it differently.
>
> The scheme which numbers SS and HS ports separately, both starting from
> 1, is mandated by the USB-3 spec for non-root hubs. But since that
> spec doesn't say much about root hubs, the OS is free to treat them
> however it likes. We have chosen to make root hubs appear as similar
> as possible to non-root hubs; however I believe that Windows (for
> example) may do things differently.
>
> At any rate, since DT strives to reflect the actual hardware
> properties, you probably should use the xHCI numbering scheme when
> describing the ports of an xHCI root hub.
Yes, indeed that is what I was trying to say here.
> > > > Is it possible to have a hub in an interface of a multifunction device
> > > > or are they always single-configuration single-interface devices?
> > > >
> > >
> > > I have not seen such kinds of devices, but it is possible in theory.
> >
> > Ok, so if the USB spec allows it, we should probably try to handle it too.
>
> No, the spec does not allow it. In fact, the spec divides all USB
> devices into two classes: hubs and functions. A function is anything
> that isn't a hub. And a hub is never allowed to contain more than one
> configuration and interface.
Ok, that helps.
> The spec does allow for multiple functions to be packaged in the same
> physical device. In this case, the physical device contains a hub
> along with various functions permanently connected to it.
>
> For example, the old Apple USB keyboards are compound devices. They
> contain an internal 3-port hub; one of the ports is permanently wired
> to the keyboard controller and the other two are exposed to the user,
> allowing a mouse and something else to be attached.
Good, that is straightforward to represent in a way that matches both
the DT binding and the Linux-internal representation.
We just have to decide what to do for non-hub devices that the OF
specification calls "combined nodes" (device class 0, one configuration,
one interface) and that, like hubs do not have one of_node per interface
plus one per device, but only one node.
Should we bind the of_node to the usb_device, the usb_interface or both
in this case? Doing both might be problematic and would need more
testing to be sure it works.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
