Re: [linux-usb-devel] Re: [PATCH] driverfs support for USB - take 2

David Brownell (david-b@pacbell.net)
Sat, 02 Feb 2002 11:27:44 -0800


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

Sure it's a hub (with the firmware provided by Linux :) but it's also a
PCI device. The extra indirection is the one which makes the root
hub be a different device than the PCI device. It'll have some
attributes that relate to its PCI device role, others that relate to
the more specialized "USB root hub" role.

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

Not useful to this user ... and I'm unclear why it'd be useful to
any others. Initialization order can change, and embedding
it in device naming is basically just trouble.

> If presented with a tree
> that doesn't have the pci? and usb directories, it just looks like a
> random tree of different numbers.

Just like most directories. That's why I commented that it might
be desirable to have any typing information just show up as one
of the directory attributes.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/