Greg, The company i work for (mutualink.net) is building a compound device for controlling radios. It has two USB audio codecs, a Serial port (FTDI) and a board controller implemented in a USB AVR microcontroller all sitting behind a HUB. Depending on the application, we have a need to turn off one of the codecs, or cycle power on a single device. Power is provided to these devices individually via the USB port power for each of the ports. I can certainly turn off the power to each of the HUB's ports, and can confirm it with external measurements. This is done with setFeature packets and LibUSB1.0. The problem is that KHub has no idea that the power was removed. I am uncomfortable messing with KHubs resources without it being in the loop, which is why i am bringing this up. Although, I would have expected a port change bit to notify khub that something has changed, but i have not seen that happen. This application is obviously an embedded one and not the normal desktop user. So the requirements here are different than probably 90% of the users out there. I absolutely am not trying to suggest changes that aren't architecturally sound, but i think since the USB Hub Committee thought it was useful it can lend some credibility to it. ;) -lenny On Tue, Sep 20, 2011 at 10:02 AM, Greg KH <greg@xxxxxxxxx> wrote: > 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
