Re: [PATCH 2/4] usb: introduce usb force power off mechanism

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

 



On Fri, 29 Mar 2013, Sarah Sharp wrote:

> However, what happens if you echo 0 to pm_qos_no_power_off, the
> power/control is set to auto, and there's a suspended USB device
> attached to the port with remote wakeup enabled?  Will the port be
> powered off?  I don't think it will with the current patchset, but I
> will have to double check.

It shouldn't be, because remote wakeup is enabled.  But what about the
case where remote wakeup is disabled?  Will writing a 0 to
pm_qos_no_power_off cause the power to be turned off?

Or what about the case where there's no device attached to the port?  I 
guess both questions amount to the same thing: When the user writes to 
a pm_qos_* file, does the code call pm_runtime_idle?

> Maybe you have an Android smartphone or tablet, the user pushes the
> button to turn off the screen.  In that case, you want to physically
> power off any USB devices, including ones that may be in USB device
> suspend with remote wakeup on, like a USB touchscreen.
> 
> With the proposed patchset, you can do that through usbfs, but it feels
> awkward to have the PM QOS constraints and the manual power off in two
> separate places.  I think if we're adding the usbfs interface, we should
> also add a manual 'off' to the port power/control file.

That's not so easy to do.  power/control is owned by the PM core, not 
by USB.  From the PM core's perspective, "power off" is merely a 
variant of "suspend".  The USB subsystem gets to choose which variant 
to use, based on various constraints that userspace has imposed.

In fact, if the user wants to, it is possible to set the port's pm_qos
file to allow power off and then manage the port's actual behavior
entirely by means of its power/control file.  I sort of think that 
would be a cleaner approach ... but there may have been some reason for 
using the separate pm_qos attribute; I can't remember.

Also, bear in mind that the proposed patch does not give userspace a 
way to power off ports via usbfs.  What the new code does is a 
power-off reset -- it turns off power to the port, waits a short time, 
and then turns power back on.

Alan Stern

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




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

  Powered by Linux