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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux