public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/1] USB: core: let USB device know device node
Date: Fri, 22 Jan 2016 11:18:07 +0100	[thread overview]
Message-ID: <2404899.20LhULZo7N@wuerfel> (raw)
In-Reply-To: <20160122065901.GA31145@shlinux2>

On Friday 22 January 2016 14:59:01 Peter Chen wrote:
> 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:
> > 		hub at 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?

The binding mandates it this way, but I guess we could decide to
make it a Linux-specific extension that we allow some of them to
be left out.

> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 			reg = <1>;
> > 
> > 			communications at 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 at 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 at 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 at 1 and reg=<1>;

I accidentally confused the port number and the device number.

> > 				wireless at 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 at 2), interface (wireless at 0.1,
> > wireless at 0.2) and combined (hub at 1, hub at 3, storage at 1, communications at 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.

We should at least handle the case of multiple hubs connected to one
another I think. No need to limit it to directly connected devices
when it's easy enough to do hubs as well.

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

Ok, got it. So we can set the of_node pointer of a struct usb_interface
to the child node of the usb->interface->usb_dev that matches the
configuration/interface tuple.

For combined device nodes (class 0 device, single configuration, single
interface), I suppose we have both a 'struct usb_device' and a 'struct
usb_interface' that we could attach the of_node to, but we can
decide to always just use one of the two, to avoid having the
same of_node pointer in multiple 'struct device' instances.

Or we simplify it so we always put the of_node just in the usb_device
or the usb_interface, even if both are listed.

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

	Arnd

  reply	other threads:[~2016-01-22 10:18 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
2016-01-15 11:11 ` Arnd Bergmann
2016-01-15 15:11   ` Alan Stern
2016-01-15 23:03     ` Arnd Bergmann
2016-01-16 16:40       ` Alan Stern
2016-01-18  8:15         ` Peter Chen
2016-01-18 16:46           ` Alan Stern
2016-01-19  3:08             ` Peter Chen
2016-01-19 11:33               ` Arnd Bergmann
2016-01-19 15:12                 ` Alan Stern
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
2016-01-21 22:24                                     ` Arnd Bergmann
2016-01-22  6:59                                       ` Peter Chen
2016-01-22 10:18                                         ` Arnd Bergmann [this message]
2016-01-22 15:55                                           ` Alan Stern
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
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
2016-01-15 17:30   ` Alan Stern
2016-01-18  7:13     ` Peter Chen
2016-01-18 16:39       ` Alan Stern
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=2404899.20LhULZo7N@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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