From: Greg KH <greg@kroah.com>
To: David Brownell <david-b@pacbell.net>
Cc: Patrick Mochel <mochel@osdl.org>,
linux-usb-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] Re: [PATCH] driverfs support for USB - take 2
Date: Fri, 1 Feb 2002 16:23:09 -0800 [thread overview]
Message-ID: <20020202002309.GD10313@kroah.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0201301018580.800-100000@segfault.osdlab.org> <0a1e01c1a9cc$15e164c0$6800000a@brownell.org>
In-Reply-To: <0a1e01c1a9cc$15e164c0$6800000a@brownell.org>
On Wed, Jan 30, 2002 at 12:24:13PM -0800, David Brownell wrote:
> "> " == "Patrick Mochel" <mochel@osdl.org>
>
> > You have a PCI device that is the USB controller. You create a child of
> > that represents the USB bus. Then, devices are added as children of that.
> >
> > Logically, couldn't you skip that extra layer of indirection and make USB
> > devices children of the USB controller? Or, do you see benefit in the
> > explicit distinction?
>
> Since I don't see a benefit from that extra indirection, I was going to ask
> almost that same question ... :)
But that device _is_ a USB device, it's a root hub. It has bandwidth
allocation, strings, a configuration, and other stuff. It operates a
bit differently from other hubs, but it's pretty close to the real
thing.
> But it's broader than that: Why shouldn't that apply to _every_ kind
> of bridge, not just USB controllers ("PCI-to-USB bridges")?
>
> For example, with PCI why should there ever be "pci0" directories,
> with children "00:??.?" and "pci1"?
It's information that is useful to the user. If presented with a tree
that doesn't have the pci? and usb directories, it just looks like a
random tree of different numbers. If we did that, we would really need
a lsdevice program just to determine what the different devices are
easily :)
I want to be able to easily see where the pci root buses, usb root
buses, ieee1394 root buses, etc. are in the system, by just looking at
the tree.
I'll play around more with the naming scheme next week and post the
results.
thanks,
greg k-h
next prev parent reply other threads:[~2002-02-02 0:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-30 0:24 [PATCH] driverfs support for USB - take 2 Greg KH
2002-01-30 1:03 ` Dave Jones
2002-01-30 1:09 ` Greg KH
2002-01-30 1:19 ` Patrick Mochel
2002-01-30 2:15 ` [linux-usb-devel] " David Brownell
2002-01-30 4:09 ` Greg KH
2002-01-30 20:07 ` [linux-usb-devel] " David Brownell
2002-02-02 0:18 ` Greg KH
2002-02-02 19:13 ` David Brownell
2002-02-05 6:49 ` Greg KH
2002-01-30 1:49 ` [linux-usb-devel] " Stephen J. Gowdy
2002-01-30 4:10 ` Greg KH
2002-01-30 18:26 ` Patrick Mochel
2002-01-30 20:24 ` [linux-usb-devel] " David Brownell
2002-02-02 0:23 ` Greg KH [this message]
2002-02-02 19:27 ` David Brownell
2002-01-31 12:49 ` Pavel Machek
2002-02-01 9:27 ` Horst von Brand
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=20020202002309.GD10313@kroah.com \
--to=greg@kroah.com \
--cc=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mochel@osdl.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