All of lore.kernel.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: Sat, 16 Jan 2016 00:03:37 +0100	[thread overview]
Message-ID: <5216704.YbueADHOOR@wuerfel> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1601151006330.1533-100000@iolanthe.rowland.org>

On Friday 15 January 2016 10:11:06 Alan Stern wrote:
> On Fri, 15 Jan 2016, Arnd Bergmann wrote:
> 
> > On Friday 15 January 2016 17:17:27 Peter Chen wrote:
> > > Although most of USB devices are hot-plug's, there are still some devices
> > > are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> > > If these kinds of USB devices are multiple functions, and they can supply
> > > other interfaces like i2c, gpios for other devices, we may need to
> > > describe these at device tree.
> > > 
> > > In this commit, it uses "reg" in dts as port number to match the port
> > > number decided by USB core, if they are the same, then the device node
> > > is for the device we are creating for USB core.
> > > 
> > > Signed-off-by: Peter Chen <peter.chen@freescale.com>
> > 
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > 
> > Just one last question:
> > 
> > >  	dev->active_duration = -jiffies;
> > >  #endif
> > > -	if (root_hub)	/* Root hub always ok [and always wired] */
> > > +	if (root_hub) {	/* Root hub always ok [and always wired] */
> > >  		dev->authorized = 1;
> > > -	else {
> > > +		dev->of_node = bus->controller->of_node;
> > 
> > 
> > You are adding the of_node of the controller to the root hub, which I
> > guess means that we now have two 'struct device' instances with the
> > same of_node. They have different bus_types, so I think that is ok,
> > but I wonder if it would be better to leave out the of_node for the
> > root hub to avoid the confusion. Can you think of a case where we
> > actually want to add properties for the root hub that we can't do
> > more easily in the host controller?
> 
> There may not be any such cases, but there's still a good reason for
> setting the root hub's of_node pointer: to initialize the recursion
> along the USB device tree.
> 
> This leaves the question of whether OF will always use the same node to
> represent the host controller and the root hub.  In other words, if a
> motherboard has a fixed device plugged into a fixed root-hub port, will
> the DT description make that device a child of the host controller?  
> Or will there be a node in between (to represent the root hub)?

Good question. I'm sure the answer is somewhere in this document

http://www.firmware.org/1275/bindings/usb/usb-1_0.ps

but unfortunately I don't understand USB addressing well enough
to answer this. I think the key sentence is the definition of the
"reg" property:

| prop-encoded-array: one integer, encoded as with encode-int.
| The "reg" property for a device node shall consist of the number of the
| USB hub port or the USB host controller port to which this USB device
| is attached. As specified in [2] section 11.11.2.1, port numbers range
| from 1 to 255.

Does the root hub have a port number relative to the host controller,
or is it identical to the host controller from the addressing
perspective?

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	balbi-l0cyMroinI0@public.gmane.org,
	valentin.longchamp-SkAbAL50j+5BDgjK7y7TUQ@public.gmane.org,
	s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH v3 1/1] USB: core: let USB device know device node
Date: Sat, 16 Jan 2016 00:03:37 +0100	[thread overview]
Message-ID: <5216704.YbueADHOOR@wuerfel> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1601151006330.1533-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>

On Friday 15 January 2016 10:11:06 Alan Stern wrote:
> On Fri, 15 Jan 2016, Arnd Bergmann wrote:
> 
> > On Friday 15 January 2016 17:17:27 Peter Chen wrote:
> > > Although most of USB devices are hot-plug's, there are still some devices
> > > are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
> > > If these kinds of USB devices are multiple functions, and they can supply
> > > other interfaces like i2c, gpios for other devices, we may need to
> > > describe these at device tree.
> > > 
> > > In this commit, it uses "reg" in dts as port number to match the port
> > > number decided by USB core, if they are the same, then the device node
> > > is for the device we are creating for USB core.
> > > 
> > > Signed-off-by: Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > 
> > Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > 
> > 
> > Just one last question:
> > 
> > >  	dev->active_duration = -jiffies;
> > >  #endif
> > > -	if (root_hub)	/* Root hub always ok [and always wired] */
> > > +	if (root_hub) {	/* Root hub always ok [and always wired] */
> > >  		dev->authorized = 1;
> > > -	else {
> > > +		dev->of_node = bus->controller->of_node;
> > 
> > 
> > You are adding the of_node of the controller to the root hub, which I
> > guess means that we now have two 'struct device' instances with the
> > same of_node. They have different bus_types, so I think that is ok,
> > but I wonder if it would be better to leave out the of_node for the
> > root hub to avoid the confusion. Can you think of a case where we
> > actually want to add properties for the root hub that we can't do
> > more easily in the host controller?
> 
> There may not be any such cases, but there's still a good reason for
> setting the root hub's of_node pointer: to initialize the recursion
> along the USB device tree.
> 
> This leaves the question of whether OF will always use the same node to
> represent the host controller and the root hub.  In other words, if a
> motherboard has a fixed device plugged into a fixed root-hub port, will
> the DT description make that device a child of the host controller?  
> Or will there be a node in between (to represent the root hub)?

Good question. I'm sure the answer is somewhere in this document

http://www.firmware.org/1275/bindings/usb/usb-1_0.ps

but unfortunately I don't understand USB addressing well enough
to answer this. I think the key sentence is the definition of the
"reg" property:

| prop-encoded-array: one integer, encoded as with encode-int.
| The "reg" property for a device node shall consist of the number of the
| USB hub port or the USB host controller port to which this USB device
| is attached. As specified in [2] section 11.11.2.1, port numbers range
| from 1 to 255.

Does the root hub have a port number relative to the host controller,
or is it identical to the host controller from the addressing
perspective?

	Arnd
--
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-15 23:03 UTC|newest]

Thread overview: 78+ 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  9:17 ` Peter Chen
2016-01-15 11:11 ` Arnd Bergmann
2016-01-15 11:11   ` Arnd Bergmann
2016-01-15 15:11   ` Alan Stern
2016-01-15 15:11     ` Alan Stern
2016-01-15 23:03     ` Arnd Bergmann [this message]
2016-01-15 23:03       ` Arnd Bergmann
2016-01-16 16:40       ` Alan Stern
2016-01-16 16:40         ` Alan Stern
2016-01-18  8:15         ` Peter Chen
2016-01-18  8:15           ` Peter Chen
2016-01-18 16:46           ` Alan Stern
2016-01-18 16:46             ` Alan Stern
2016-01-19  3:08             ` Peter Chen
2016-01-19  3:08               ` Peter Chen
2016-01-19 11:33               ` Arnd Bergmann
2016-01-19 11:33                 ` Arnd Bergmann
2016-01-19 15:12                 ` Alan Stern
2016-01-19 15:12                   ` Alan Stern
2016-01-20  3:48                   ` Peter Chen
2016-01-20  3:48                     ` Peter Chen
2016-01-20  9:07                     ` Arnd Bergmann
2016-01-20  9:07                       ` Arnd Bergmann
2016-01-20 12:50                       ` Peter Chen
2016-01-20 12:50                         ` Peter Chen
2016-01-20 14:19                         ` Arnd Bergmann
2016-01-20 14:19                           ` Arnd Bergmann
2016-01-21  3:15                           ` Peter Chen
2016-01-21  3:15                             ` Peter Chen
2016-01-21  8:41                             ` Arnd Bergmann
2016-01-21  8:41                               ` Arnd Bergmann
2016-01-21  9:48                               ` Peter Chen
2016-01-21  9:48                                 ` Peter Chen
2016-01-21 10:10                                 ` Arnd Bergmann
2016-01-21 10:10                                   ` Arnd Bergmann
2016-01-21 15:21                                   ` Alan Stern
2016-01-21 15:21                                     ` Alan Stern
2016-01-21 22:24                                     ` Arnd Bergmann
2016-01-21 22:24                                       ` Arnd Bergmann
2016-01-22  6:59                                       ` Peter Chen
2016-01-22  6:59                                         ` Peter Chen
2016-01-22 10:18                                         ` Arnd Bergmann
2016-01-22 10:18                                           ` Arnd Bergmann
2016-01-22 15:55                                           ` Alan Stern
2016-01-22 15:55                                             ` Alan Stern
2016-01-22 16:23                                             ` Arnd Bergmann
2016-01-22 16:23                                               ` Arnd Bergmann
2016-01-22 19:29                                               ` Alan Stern
2016-01-22 19:29                                                 ` Alan Stern
2016-01-25  1:55                                             ` Peter Chen
2016-01-25  1:55                                               ` Peter Chen
2016-01-25  3:57                                           ` Peter Chen
2016-01-25  3:57                                             ` Peter Chen
2016-01-25  8:50                                             ` Arnd Bergmann
2016-01-25  8:50                                               ` Arnd Bergmann
2016-01-25  9:31                                               ` Peter Chen
2016-01-25  9:31                                                 ` Peter Chen
2016-01-25 15:23                                                 ` Alan Stern
2016-01-25 15:23                                                   ` Alan Stern
2016-01-18 10:24         ` Arnd Bergmann
2016-01-18 10:24           ` Arnd Bergmann
2016-01-18  7:44     ` Peter Chen
2016-01-18  7:44       ` Peter Chen
2016-01-18  7:42   ` Peter Chen
2016-01-18  7:42     ` Peter Chen
2016-01-15 17:07 ` Philipp Zabel
2016-01-15 17:07   ` Philipp Zabel
2016-01-15 17:30   ` Alan Stern
2016-01-15 17:30     ` Alan Stern
2016-01-18  7:13     ` Peter Chen
2016-01-18  7:13       ` Peter Chen
2016-01-18 16:39       ` Alan Stern
2016-01-18 16:39         ` Alan Stern
2016-01-19  2:52         ` Peter Chen
2016-01-19  2:52           ` Peter Chen
2016-01-18  7:10   ` 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=5216704.YbueADHOOR@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.