On Tue, Sep 20, 2011 at 09:54:21AM -0400, Lenny Story wrote: > Greg, et al, > > it makes sense that the Hub Daemon is responsible for managing Hub > events, which includes Change Detection, Over Current, and power > control. It responds to the hardware events correctly from what i can > tell, but only in cases of hardware changes. What is needed is a > programmatic interface that another process can use to control the > ports also. By "other process", do you mean something within the kernel, or from userspace? > A process can certainly read out the Hub Descriptor and get > information on the Hub Characteristics, and Port status. But it cannot > control it without subverting KHubs role. Nor should it :) > What is needed is a simple IOCTL, that routes through KHub to turn off > the Port Power, enable test mode, etc. I think if you have a control > path you also need a status path to confirm the change, so status > should be there too. (Which i believe it is in USBDEVFS_DEV_PORTINFO). So you want to do this from userspace? Why? And are you sure that you really can turn off port power properly for all hubs? Same for test mode? I thought we already knew how to do this from userspace, no kernel changes needed today? > One can certainly just issue setFeature calls to the HUB itself and > turn off the ports power, but without KHUB also notifying the linux > device subsystem of the device removal, the job is only half > accomplished. So, KHub needs to be part of the process, and because he > is in the position to control the HUB anyways, it makes sense that It > should do the removal too. > > Does this make sense architecturally ? Possibly, patches would make more sense to show exactly what you are referring to. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
