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

[Alan Stern <stern@rowland.harvard.edu>]

On Mon, Dec 21, 2020 at 05:37:29AM +0000, Peter Chen wrote:
> 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
> }

Okay.  This can be done as follows:

while (1) {
- Check Flash Drive is there (eg, cat /proc/partitions)
- Claim port 1 on 1-1
- Turn port 1 at 1-1 off
- Check Flash Drive is gone
- Release port 1 on 1-1
- Turn port 1 at 1-1 on
- Delay for 10 seconds (time for device probing)
}


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

Yes, that won't work.  If you want to keep the port power turned off 
then you have to keep the usbfs device file open -- which means your 
program A must not end and then restart.

(Acutally, I'm not certain about that.  If you claim a port, turn off 
its power, and then release the port, I don't remember whether the hub 
driver will then turn the power back on right away.  It might not.  
But in any case, it isn't good programming to release a port without 
turning its power back on.)

Can A be rewritten so that it doesn't end when B is running?

ALan Stern