> > > In fact I also want to see the USB device tree exposed using better > > > names -- as in, ones that expose the device tree, hubs in their proper > > > places, instead of being based on unstable device addressing. > > > > So a topology tree? That's a good thing, and is what I think the > > driverfs interface will show (as the new driver model needs a tree for > > power management to work properly.)
Yes, that's just what I meant. (I keep calling that "device filesystem", since it's what I wanted out of a "devfs". Gotta remember that ... :) > I've never liked this idea. It only serves to complicate things. The > only use for the topology is to budget power and power management. Or to provide "stable" device names. Which are the only practical way to distinguish many USB devices from each other. Unless you don't really want to distinguish the garden camera from that one in the bedroom? :) > We currently keep the necessary information for power budgeting but > don't actually do it yet. > > For power management, I don't think we have much choice and must > internally track the topology so the ordering is done correctly. Likewise for suspend/resume processing, which is distinct from power budgeting (not overcommitting port power usage during device config) but is also part of power management. Devices on the other side of a bus-powered hub would better be disconnected than suspended, for example. And remote wakeup has similar topology constraints. > The rest of the USB code just doesn't care. I think exposing it via > usbdevfs will just complicate things where it isn't needed. I think I sketched how it can come out for "free" already, modulo some changes to the naming convention (no new directories), but the new "driver fs" work likely plays in that same pool. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
