On Wed, Dec 16, 2020 at 02:56:20AM +0000, Peter Chen wrote: > On 20-12-15 10:55:41, Alan Stern wrote: > > You've got the general idea. > > > > Normally ports are owned by the hub driver. If one of them loses power > > for some reason (for example, the user turns it off), the hub driver > > will turn the power back on. This is because the hub driver wants > > ports to be powered at all times unless they are in runtime suspend. > > > > The way to prevent the hub driver from managing the port power is to > > claim the port for the user, by issuing the USBDEVFS_CLAIM_PORT ioctl. > > Also, when that is done, the kernel wno't try to manage a device > > attached to the port -- that is, the kernel won't automatically install > > a configuration for a new device and it won't try to probe drivers for > > the device's interfaces if the user installs a config. > > > > Alan, we have several use cases for power switchable HUB, one of the use > cases is USB port is managed by kernel (eg, needs mass storage > class), but needs to toggle port power, is it reasonable we add a sysfs > entry to support it? Can you give more information about your use cases? After all, if the port power is turned off then the port can't possibly handle mass-storage devices -- or anything else. On the other hand, if the port is managed by the kernel then the kernel (not the user) should be responsible for deciding whether or not to turn off the port's power. If there's some real reason for turning the port power off for an extended period of time, the user can claim the port and turn off the power. Then later on, the user can release the port and turn the power back on. Alternatively, if you only need to turn off the port power for a short time, what you're already doing should be okay. I can't explain it any better than this unless I understand your use cases more fully. Alan Stern