Re: port power is on again after turning off by user space

[Peter Chen <peter.chen@nxp.com>]

On 20-12-16 10:51:44, Alan Stern wrote:
> 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.

Sorry, Alan. Due to holiday season, the U.S team doesn't reply me the
use case. I think the basic use cases are emulate the hot-plug test for
USB devices, the USB devices could be Flash Drive on market or DUT (Device
Under test) for the same controller works at device mode. Assume one
typical test case:

Plug in Flash Drive at port 1-1.1 during the boots up:

while (1) {
- Check Flash Drive is there (eg, cat /proc/partitions)
- Turn port 1 at 1-1 off
- Check Flash Drive is gone
- Turn port 1 at 1-1 on
}

> 
> 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.
> 

Yes, I think this is one of the use cases. We want power power control
at one application (A), but different with our test application(B), it means
if the user claims the port, and power off using A, then the A will end.
After the B finished running, A runs again for power on, but at this time,
the port owner has changed.

-- 

Thanks,
Peter Chen