devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Chen <hzpeterchen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Alan Stern
	<stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	valentin.longchamp-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	balbi-l0cyMroinI0@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
Subject: Re: [PATCH v3 1/1] USB: core: let USB device know device node
Date: Fri, 22 Jan 2016 14:59:01 +0800	[thread overview]
Message-ID: <20160122065901.GA31145@shlinux2> (raw)
In-Reply-To: <2930830.FLp5q7oBTi@wuerfel>

On Thu, Jan 21, 2016 at 11:24:21PM +0100, Arnd Bergmann wrote:
> On Thursday 21 January 2016 10:21:15 Alan Stern wrote:
> > On Thu, 21 Jan 2016, Arnd Bergmann wrote:
> > 
> > > On Thursday 21 January 2016 17:48:32 Peter Chen wrote:
> > > > 
> > > > > 
> > > > > So two hubs at ports 1 and 2 of the USB controller that integrates
> > > > > the root hub and shares a device node with it.
> > > > > 
> > > > Ok, so the "reg" is the address for certain root hub (HS or SS), not
> > > > the unity address for the whole controller, if it is, do we really
> > > > need to add two nodes for one physical port, HS and SS will not be used
> > > > at the same time. And if the reg is the same, how can we know
> > > > which node is from current recognized device.
> > > 
> > > The "reg" is the address that the parent device uses to talk to the child
> > > device. If you know which of the two that child is attached to, then I
> > > think you don't need both, but I think we have to use the entire addressing.
> > > 
> > > In Alan's example, there are six HS ports and three SS ports, but as I
> > > understand it, there is no guarantee that the numbering between the two
> > > is identical, and that the three SS ports always refer to the three HS
> > > ports. In particular for devices soldered on-board (rather than connected
> > > through a standard plug), I would guess that it is possible to connect
> > > them to separate child devices though I have to admit that I do not
> > > understand enough of the standard to know for sure.
> > 
> > The spec allows for a lot of flexibility.  It even allows for "tier 
> > mismatches", in which (for example) the SS connection for a particular 
> > port is routed directly to the root hub while the HS connection for the 
> > same port is routed through an intermediate hub!
> > 
> > There is only one major constraint: With the exception of hubs, no USB
> > device is allowed to use both the SS and the HS buses at the same time.  
> > A device has to decide on one speed and use only the corresponding bus.
> > USB-3 hubs, on the other hand, are required to connect to both buses.  
> > They appear as two separate logical devices: a SS hub on the SS bus and
> > a HS hub on the HS bus.
> 
> Ok, thanks for the explanation. This means there is no strict relation
> between the SS and HS ports and we have to represent them separately.
> 
> I can also see what you explained now on my PC by plugging in a couple
> of devices into a hub on a single SS port:
> 
> /:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
>     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
>         |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
>         |__ Port 4: Dev 3, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M
> /:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
>     |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
>         |__ Port 2: Dev 5, If 0, Class=Wireless, Driver=btusb, 12M
>         |__ Port 2: Dev 5, If 1, Class=Wireless, Driver=btusb, 12M
> 
> In this case, the DT representation would be
> 
> 
> 	usb@... { /* host controller and root hub */
> 		compatible = "xhci-generic";
> 		#address-cells = <1>;
> 		#size-cells = <0>;
> 
> 		hub@1 { /* external hub, superspeed mode class 9/subclass 0/proto 3 */
> 			compatible = "usb2109,0812.591",
> 				     "usb2109,0812",
> 				     "usb2109,class9.0.3",
> 				     "usb2109,class9.0",
> 				     "usb2109,class9";
> 			compatible = "usb2109,0812";

Do we really need to write "compatible" so complicated?

> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 			reg = <1>;
> 
> 			communications@4 { /* superspeed ethernet device */
> 				compatible = "usb0b95,1790.100",
> 					     "usb0b95,1790",
> 					     "usb0b95,class255.255.0",
> 					     "usb0b95,class255.255",
> 					     "usb0b95,class255",
> 					     "usbif0b95,1790.100",
> 					     "usbif0b95,1790",
> 					     "usbif0b95,class255.255.0",
> 					     "usbif0b95,class255.255,
> 					     "usbif0b95,class255";
> 				reg = <4>;
> 			};
> 
> 			storage@1 { /* superspeed flash drive */
> 				compatible = "usb1234,5678.600",
> 					     "usb1234,5678",
> 					     "usbif1234,class8.6.80",
> 					     "usbif1234,class8.6",
> 					     "usbif1234,class8",
> 					     "usbif,class8.6.80",
> 					     "usbif,class8.6",
> 					     "usbif,class8";
> 				reg = <1>;
> 			};
> 		};
> 	
> 		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?

> 			wireless@2 { /* bluetooth device */
> 				compatible = "usb0a12,0001.134",
> 					     "usb0a12,0001",
> 					     "usb0a12,class224.1.1",
> 					     "usb0a12,class224.1",
> 					     "usb0a12,class224",
> 					     "usb0a12,class224.1.1",
> 					     "usb0a12,class224.1",
> 					     "usb0a12,class224";
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 				reg = <2>;
> 
> 				wireless@0,0 { /* bluetooth config 0, if 0 */
> 					compatible = "usbif0a12,0001.134.config0.0",
> 							"usbif0a12,0001.config0.0",
> 							"usbif0a12,class224.1.1",
> 							"usbif0a12,class224.1",
> 							"usbif0a12,class224",
> 							"usbif,class224.1.1",
> 							"usbif,class224.1",
> 							"usbif,class224";
> 					reg = <0 0>;
> 				};
> 
> 				wireless@0,1 { /* bluetooth config 0, if 1 */
> 					compatible = "usbif0a12,0001.134.config0.1",
> 							"usbif0a12,0001.config0.1",
> 							"usbif0a12,class224.1.1",
> 							"usbif0a12,class224.1",
> 							"usbif0a12,class224",
> 							"usbif,class224.1.1",
> 							"usbif,class224.1",
> 							"usbif,class224";
> 					reg = <0 0>;
> 				};
> 			};
> 		};
> 	};
> 
> In that description, I have included all four kinds of nodes from
> the spec: host controller, device (wireless@2), interface (wireless@0.1,
> wireless@0.2) and combined (hub@1, hub@3, storage@1, communications@4).
> 
> Peter's example only contained hubs in combined nodes, no device or
> interface nodes. I wonder if the code is able to parse all four
> kinds of nodes though, and if we actually need that.
> 

My proposal patch only handles the node under the USB device, not include
the USB interfaces under such device, we can add it after finalize
how to describe it at device tree.

> Do we have a 'struct device' for each interface?
> 

Yes, we have, but there are different 'struct device' between USB device
and USB interfaces under this USB device. See usb_set_configuration,
drivers/usb/core/message.c

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

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-01-22  6:59 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15  9:17 [PATCH v3 1/1] USB: core: let USB device know device node Peter Chen
     [not found] ` <1452849447-25025-1-git-send-email-peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2016-01-15 11:11   ` Arnd Bergmann
2016-01-15 15:11     ` Alan Stern
     [not found]       ` <Pine.LNX.4.44L0.1601151006330.1533-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-15 23:03         ` Arnd Bergmann
2016-01-16 16:40           ` Alan Stern
     [not found]             ` <Pine.LNX.4.44L0.1601161115050.11338-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-18  8:15               ` Peter Chen
2016-01-18 16:46                 ` Alan Stern
     [not found]                   ` <Pine.LNX.4.44L0.1601181139150.25155-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-19  3:08                     ` Peter Chen
2016-01-19 11:33                       ` Arnd Bergmann
2016-01-19 15:12                         ` Alan Stern
     [not found]                           ` <Pine.LNX.4.44L0.1601191009190.1727-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-20  3:48                             ` Peter Chen
2016-01-20  9:07                               ` Arnd Bergmann
2016-01-20 12:50                                 ` Peter Chen
2016-01-20 14:19                                   ` Arnd Bergmann
2016-01-21  3:15                                     ` Peter Chen
2016-01-21  8:41                                       ` Arnd Bergmann
2016-01-21  9:48                                         ` Peter Chen
2016-01-21 10:10                                           ` Arnd Bergmann
2016-01-21 15:21                                             ` Alan Stern
     [not found]                                               ` <Pine.LNX.4.44L0.1601211015010.2275-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-21 22:24                                                 ` Arnd Bergmann
2016-01-22  6:59                                                   ` Peter Chen [this message]
2016-01-22 10:18                                                     ` Arnd Bergmann
2016-01-22 15:55                                                       ` Alan Stern
     [not found]                                                         ` <Pine.LNX.4.44L0.1601221023350.1626-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-22 16:23                                                           ` Arnd Bergmann
2016-01-22 19:29                                                             ` Alan Stern
2016-01-25  1:55                                                           ` Peter Chen
2016-01-25  3:57                                                       ` Peter Chen
     [not found]                                                         ` <CAL411-qfzcynzc=YrepzcA6EmFuxy-Ri4xRQ+R-QVBDEPZXtZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-25  8:50                                                           ` Arnd Bergmann
2016-01-25  9:31                                                             ` Peter Chen
2016-01-25 15:23                                                               ` Alan Stern
2016-01-18 10:24               ` Arnd Bergmann
2016-01-18  7:44         ` Peter Chen
2016-01-18  7:42     ` Peter Chen
2016-01-15 17:07   ` Philipp Zabel
     [not found]     ` <1452877630.6067.97.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2016-01-15 17:30       ` Alan Stern
     [not found]         ` <Pine.LNX.4.44L0.1601151220020.1533-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-18  7:13           ` Peter Chen
2016-01-18 16:39             ` Alan Stern
     [not found]               ` <Pine.LNX.4.44L0.1601181129340.25155-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-01-19  2:52                 ` Peter Chen
2016-01-18  7:10       ` Peter Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160122065901.GA31145@shlinux2 \
    --to=hzpeterchen-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=arnd-r2nGTMty4D4@public.gmane.org \
    --cc=balbi-l0cyMroinI0@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
    --cc=peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
    --cc=stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=valentin.longchamp-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).