On Wed, 4 Oct 2006, Greg KH wrote: > On Wed, Oct 04, 2006 at 11:03:51AM -0400, Alan Stern wrote: > > Greg: > > > > I'm working on a patch to create class devices for USB hubs. Is this a > > reasonable thing to do? We already have classes for USB hosts and general > > USB devices. > > If you think you want an easy way to find all usb hubs in the system, > and /sys/bus/usb/drivers/hub/ isn't good enough for it, then yes, a > class could work.
In this case I guess a class isn't really needed. > > I don't have a good understanding of how class devices are supposed to > > work and what they should be used for. Nor is it clear which of the > > class-device APIs should be used. > > Traditionally classes are used for when we want to export a device node > for the device. In this case, like usb hosts, that isn't. Would it be fair to say that classes are also appropriate when you want to have a single API available for a bunch of different drivers? The way all Ethernet drivers share a single API? The usb_host class doesn't fit either of these paradigms. Perhaps it shouldn't exist? It doesn't seem to contain anything very useful, other than the list of all the hosts. They could just as well be replaced by symlinks. (Note that ehci-hcd and ohci-hcd both store their debugging attributes under /sys/class/usb_host. This appears to be a holdover from the past; obviously those files belong in debugfs.) > > You've been making some changes in that area; what's the current policy? > > Don't use struct class_device anymore. Just use a struct device. To > make it easy, just call device_create(). That's the recommended way. > If you have an example patch, I'd be glad to review it. Not yet, and it looks like I won't be using the usb_hub class after all. > > Someone has asked about a way to make the hub driver ignore certain ports > > (leave them permanently disabled). A list of ports to ignore seems like a > > good candidate for a class device attribute file. Another possibly useful > > attribute would be a list of ports with children attached. > > But that information can already be extracted from the existing sysfs > device tree, right (not the ignore stuff, I'm referring to the list.) You're right. Okay, that leaves only the "ignore" attribute, which can just as easily go in the regular device directory. > > Are these appropriate for a class device or should they go in the regular > > device directory? How do you decide which attributes go where? > > I'd start with just putting them in the device directory, unless you > find that it makes more sense for them in their own directory. If so, > then create a new device and add it to the tree. > > Play around and see what makes sense, we're still finding our way here > :) > > Hope this helps, Thanks, Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
