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. 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. 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). 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 ? Thoughts ? -Lenny On Mon, Sep 19, 2011 at 1:23 PM, Greg KH <greg@xxxxxxxxx> wrote: > On Mon, Sep 19, 2011 at 11:29:27AM -0400, Lenny Story wrote: >> Greetings, >> >> It seems to me that an important HUB Feature is per port power >> control. And although many people do not use it currently on the >> desktop, the ever increasing embedded nature of Linux is going to >> bring this requirement out. >> >> What are the thoughts of this group of providing such an API in KHubd ? > > What api are you thinking of? What do you want to do with the system? > > 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
