Re: USB port power off discussion

Re: USB port power off discussion

[Sarah Sharp]

On Mon, Oct 15, 2012 at 08:42:47AM +0200, Rafael J. Wysocki wrote:
> Sorry for the delay, I have been distracted by a number of things.

Me too. :)

> On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
> > On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote:
> > > What about hubs connected to such ports?  I don't think they're going to
> > > work when power is removed from it, are they?
> > 
> > USB hubs would have remote wakeup enabled, so we would never power off
> > their port with the "auto" policy.
> 
> Here's my idea how to arrange things.
> 
> Why don't make runtime PM manage the USB port power on/off such that the
> port's .runtime_suspend() routine will remove power from it, if
> PM_QOS_FLAG_NO_POWER_OFF is not (effectively) set for it, and its
> .runtime_resume() will restore power to it (if removed previously).

Ok, so you're basically proposing we power off suspended devices, except
when userspace (or perhaps the kernel) sets PM_QOS_FLAG_NO_POWER_OFF?

What happens if userspace clears the PM_QOS_FLAG_NO_POWER_OFF flag while
the port is suspended?  Does the USB core then re-power it on?  Should
it also resume the device?

> The USB core will then do pm_runtime_get_sync() on the port every time
> a device depending on it is added and pm_runtime_put() every time such
> a device is removed.

Are you saying that every time a device is connected to an _external_
hub, the USB core would call pm_runtime_get_sync()?  If you apply that
policy to roothubs, then you're basically disabling port power off when
a device is connected, which doesn't make sense in conjunction to your
last sentence, so now I'm just confused, sorry.

Wouldn't it make more sense to call pm_runtime_get_sync() when remote
wakeup is enabled for a device, and pm_runtime_put() when remote wakeup
is disabled?  That way, when an external hub is attached to the port, it
always has remote wakeup enabled, so we will always increment the PM
counter. [1]

> The initial setting of PM_QOS_FLAG_NO_POWER_OFF in the PM QoS request
> structure used by user space will depend on the type of the port (e.g.
> it will be unset for ports that aren't visible to the user and connectable).
> 
> That should allow things to work automatically and it should allow user space
> to override the defaults in any case, either by disabling runtime PM for the
> ports altogether (by writing "on" to their device objects' "control" sysfs
> files), or by setting/unsetting PM_QOS_FLAG_NO_POWER_OFF in the PM QoS
> request controlled by it as desired.

Are you then pushing the policy decision for whether ports should be
powered off completely into userspace then?  I.e. you want userspace to
read the ACPI port connect type info and clear PM_QOS_FLAG_NO_POWER_OFF
in the userspace structure if the port is not user visible and not
connectable?

Or are you thinking the kernel will set PM_QOS_FLAG_NO_POWER_OFF based
on the ACPI tables and userspace will have the option to override it?

We also probably need to allow USB interface drivers to set
PM_QOS_FLAG_NO_POWER_OFF as well, for cases like devices that have
firmware or other internal state.  We probably need a USB core API to
add a request for PM_QOS_FLAG_NO_POWER_OFF to be set, and a way to clear
that flag if the driver is unbound or the driver decides it's safe to
power off the device.

> > There are things like USB lights or fans that pull port power, but don't
> > actually enumerate as a USB device.  So to the OS, those would be
> > "empty" ports.  But they would be external ports, so the default "auto"
> > policy would never power off external ports.  The user could write a
> > small script to PWM the fan on and off to control the speed.  It would
> > just be a novelty though, as Alan said.
> 
> For those things we can provide a "raw port driver" with ioctls allowing
> user space to get the port's physical location information from the kernel,
> if available, and manipulate the port's power on the low level.

Sure, I think it's fine to push that corner case off to usbdevfs.

Sarah Sharp

[1] The above sentence doesn't apply to VIA USB 3.0 hubs, because they
don't actually advertise remote wakeup in their device descriptors.
However, the USB core will never suspend those hubs, so we'll never
power off the USB 3.0 port the device is connected to.  Not sure how
they'll react to having the USB 2.0 portion powered off while the USB
3.0 potion is powered.  We'll see.  I really hate these uncertified
hubs.

Re: USB port power off discussion

[Alan Stern]

On Mon, 22 Oct 2012, Sarah Sharp wrote:

> On Mon, Oct 15, 2012 at 08:42:47AM +0200, Rafael J. Wysocki wrote:
> > Sorry for the delay, I have been distracted by a number of things.
> 
> Me too. :)
> 
> > On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
> > > On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote:
> > > > What about hubs connected to such ports?  I don't think they're going to
> > > > work when power is removed from it, are they?
> > > 
> > > USB hubs would have remote wakeup enabled, so we would never power off
> > > their port with the "auto" policy.
> > 
> > Here's my idea how to arrange things.
> > 
> > Why don't make runtime PM manage the USB port power on/off such that the
> > port's .runtime_suspend() routine will remove power from it, if
> > PM_QOS_FLAG_NO_POWER_OFF is not (effectively) set for it, and its
> > .runtime_resume() will restore power to it (if removed previously).
> 
> Ok, so you're basically proposing we power off suspended devices, except
> when userspace (or perhaps the kernel) sets PM_QOS_FLAG_NO_POWER_OFF?

Rafael is suggesting that the interface to control when ports get
powered off should be associated with the usb_port device, rather than
with the usb_device attached to the port.

> What happens if userspace clears the PM_QOS_FLAG_NO_POWER_OFF flag while
> the port is suspended?  Does the USB core then re-power it on?  Should
> it also resume the device?

I don't know how the PM QOS flags interact with runtime PM.  Rafael may 
still be working on that.

At any rate, runtime suspend for the usb_port will remove power.  
Runtime resume will turn power back on.  But if there's a usb_device 
attached to the port, resuming the port will not necessarily resume the 
device.  (However, we will be careful to make sure that the port cannot 
be runtime suspended unless the device is suspended first.)

> > The USB core will then do pm_runtime_get_sync() on the port every time
> > a device depending on it is added and pm_runtime_put() every time such
> > a device is removed.
> 
> Are you saying that every time a device is connected to an _external_
> hub, the USB core would call pm_runtime_get_sync()?  If you apply that
> policy to roothubs, then you're basically disabling port power off when
> a device is connected, which doesn't make sense in conjunction to your
> last sentence, so now I'm just confused, sorry.

He is saying that the core would call pm_runtime_get_sync(&port->dev),
not pm_runtime_get_sync(&udev->dev).  And this would only be for while
the device was active, not for when the device is suspended (unless the 
device can't handle loss of power).

> Wouldn't it make more sense to call pm_runtime_get_sync() when remote
> wakeup is enabled for a device, and pm_runtime_put() when remote wakeup
> is disabled?  That way, when an external hub is attached to the port, it
> always has remote wakeup enabled, so we will always increment the PM
> counter. [1]
> 
> > The initial setting of PM_QOS_FLAG_NO_POWER_OFF in the PM QoS request
> > structure used by user space will depend on the type of the port (e.g.
> > it will be unset for ports that aren't visible to the user and connectable).
> > 
> > That should allow things to work automatically and it should allow user space
> > to override the defaults in any case, either by disabling runtime PM for the
> > ports altogether (by writing "on" to their device objects' "control" sysfs
> > files), or by setting/unsetting PM_QOS_FLAG_NO_POWER_OFF in the PM QoS
> > request controlled by it as desired.
> 
> Are you then pushing the policy decision for whether ports should be
> powered off completely into userspace then?  I.e. you want userspace to
> read the ACPI port connect type info and clear PM_QOS_FLAG_NO_POWER_OFF
> in the userspace structure if the port is not user visible and not
> connectable?
> 
> Or are you thinking the kernel will set PM_QOS_FLAG_NO_POWER_OFF based
> on the ACPI tables and userspace will have the option to override it?

The latter.

> We also probably need to allow USB interface drivers to set
> PM_QOS_FLAG_NO_POWER_OFF as well, for cases like devices that have
> firmware or other internal state.  We probably need a USB core API to
> add a request for PM_QOS_FLAG_NO_POWER_OFF to be set, and a way to clear
> that flag if the driver is unbound or the driver decides it's safe to
> power off the device.

How about adding a no_power_off flag to the usb_interface structure, 
analogous to the needs_remote_wakeup flag?

Alan Stern

Re: USB port power off discussion

[Lan Tianyu]

于 2012/10/23 2:37, Alan Stern 写道:
> On Mon, 22 Oct 2012, Sarah Sharp wrote:
>
>> On Mon, Oct 15, 2012 at 08:42:47AM +0200, Rafael J. Wysocki wrote:
>>> Sorry for the delay, I have been distracted by a number of things.
>>
>> Me too. :)
>>
>>> On Monday 24 of September 2012 15:10:36 Sarah Sharp wrote:
>>>> On Tue, Sep 25, 2012 at 12:09:06AM +0200, Rafael J. Wysocki wrote:
>>>>> What about hubs connected to such ports?  I don't think they're going to
>>>>> work when power is removed from it, are they?
>>>>
>>>> USB hubs would have remote wakeup enabled, so we would never power off
>>>> their port with the "auto" policy.
>>>
>>> Here's my idea how to arrange things.
>>>
>>> Why don't make runtime PM manage the USB port power on/off such that the
>>> port's .runtime_suspend() routine will remove power from it, if
>>> PM_QOS_FLAG_NO_POWER_OFF is not (effectively) set for it, and its
>>> .runtime_resume() will restore power to it (if removed previously).
>>
>> Ok, so you're basically proposing we power off suspended devices, except
>> when userspace (or perhaps the kernel) sets PM_QOS_FLAG_NO_POWER_OFF?
>
> Rafael is suggesting that the interface to control when ports get
> powered off should be associated with the usb_port device, rather than
> with the usb_device attached to the port.

That means we should add a driver for usb port device?

>
>> What happens if userspace clears the PM_QOS_FLAG_NO_POWER_OFF flag while
>> the port is suspended?  Does the USB core then re-power it on?  Should
>> it also resume the device?
>
> I don't know how the PM QOS flags interact with runtime PM.  Rafael may
> still be working on that.
I think we can add a notifier event for PM Qos flags, just like the one for
PM Qos latency. Add notifier callback to check whether PM_QOS_FLAG_NO_POWER_OFF
is clear or set when flags was changed.

For both setting or clearing PM_QOS_FLAG_NO_POWER_OFF, invoking 
pm_runtime_get_sync()
to resume port device and then pm_runtime_put_sync()(device will be suspended again
and power off or not depending on the setting).

>
> At any rate, runtime suspend for the usb_port will remove power.
> Runtime resume will turn power back on.  But if there's a usb_device
> attached to the port, resuming the port will not necessarily resume the
> device.  (However, we will be careful to make sure that the port cannot
> be runtime suspended unless the device is suspended first.)
>
>>> The USB core will then do pm_runtime_get_sync() on the port every time
>>> a device depending on it is added and pm_runtime_put() every time such
>>> a device is removed.
>>
>> Are you saying that every time a device is connected to an _external_
>> hub, the USB core would call pm_runtime_get_sync()?  If you apply that
>> policy to roothubs, then you're basically disabling port power off when
>> a device is connected, which doesn't make sense in conjunction to your
>> last sentence, so now I'm just confused, sorry.
>
> He is saying that the core would call pm_runtime_get_sync(&port->dev),
> not pm_runtime_get_sync(&udev->dev).  And this would only be for while
> the device was active, not for when the device is suspended (unless the
> device can't handle loss of power).
>
>> Wouldn't it make more sense to call pm_runtime_get_sync() when remote
>> wakeup is enabled for a device, and pm_runtime_put() when remote wakeup
>> is disabled?  That way, when an external hub is attached to the port, it
>> always has remote wakeup enabled, so we will always increment the PM
>> counter. [1]
>>
>>> The initial setting of PM_QOS_FLAG_NO_POWER_OFF in the PM QoS request
>>> structure used by user space will depend on the type of the port (e.g.
>>> it will be unset for ports that aren't visible to the user and connectable).
>>>
>>> That should allow things to work automatically and it should allow user space
>>> to override the defaults in any case, either by disabling runtime PM for the
>>> ports altogether (by writing "on" to their device objects' "control" sysfs
>>> files), or by setting/unsetting PM_QOS_FLAG_NO_POWER_OFF in the PM QoS
>>> request controlled by it as desired.
>>
>> Are you then pushing the policy decision for whether ports should be
>> powered off completely into userspace then?  I.e. you want userspace to
>> read the ACPI port connect type info and clear PM_QOS_FLAG_NO_POWER_OFF
>> in the userspace structure if the port is not user visible and not
>> connectable?
>>
>> Or are you thinking the kernel will set PM_QOS_FLAG_NO_POWER_OFF based
>> on the ACPI tables and userspace will have the option to override it?
>
> The latter.
>
>> We also probably need to allow USB interface drivers to set
>> PM_QOS_FLAG_NO_POWER_OFF as well, for cases like devices that have
>> firmware or other internal state.  We probably need a USB core API to
>> add a request for PM_QOS_FLAG_NO_POWER_OFF to be set, and a way to clear
>> that flag if the driver is unbound or the driver decides it's safe to
>> power off the device.
>
> How about adding a no_power_off flag to the usb_interface structure,
> analogous to the needs_remote_wakeup flag?
I think we can add a new request for kernel space to set pm qos flags.
Now Rafael has added a request for user space. Because user choice should
be kept. So we should add one for kernel space. We can issue the request
where a device can not be power off in the driver or remote wakeup is
enabled/disabled.

usb interfaces also have pm qos flags in their struct device. So we can
reuse it. When usb device are being suspended, check all its interface
NO_POWER_OFF flag and issue request to set its NO_POWER_OFF flag.

>
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Best regards
Tianyu Lan