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

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

[Sarah Sharp]

On Mon, Apr 08, 2013 at 09:01:44AM -0700, Greg KH wrote:
> On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote:
> > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote:
> > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote:
> > > > Hi Alan & Sarah:
> > > > 	I just recall why I put power off and power on in one ioctl.
> > > > At first, I also tried to make power on and power off into two ioctls.
> > > > But I found after powering off a device, the usbfs device node will
> > > > be removed and so can't power on the port via the same usbfs node.
> > > > 
> > > > For this point, we should add usbfs node for usb port?
> > > 
> > > No.
> > 
> > I agree that we shouldn't add more usbfs files without thinking very
> > carefully about it, since lots of tools like libusb use them.  However,
> > we do need a way to manually power off a port, wait a variable length of
> > time (or perhaps for a distro-specific event like screen unblank), and
> > turn the port on.
> > 
> > So how do we turn the port power back on with the options we have?
> > Would userspace have to turn the port power off via usbfs, and then
> > manually back on by setting the port's sysfs power/control to 'on'?
> 
> Whatever method we use, it should be the same interface for both on
> and off, so I would prefer to just use the sysfs one, as usbfs does not
> represent ports, only USB devices.

I would prefer that as well.  However, the port power sysfs file
power/control is created by the runtime PM core, and I think it doesn't
have a way to manually turn power off.  All we get with the current
framework is 'on' or 'auto'.  There may be times when userspace wants to
override the kernel's policy for 'auto' and force a port power off.

Perhaps the runtime PM core needs to be extended to have a way to allow
userspace to manually force a device into a lower power state?

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Rafael J. Wysocki]

On Monday, April 08, 2013 10:33:54 AM Sarah Sharp wrote:
> On Mon, Apr 08, 2013 at 09:01:44AM -0700, Greg KH wrote:
> > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote:
> > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote:
> > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote:
> > > > > Hi Alan & Sarah:
> > > > > 	I just recall why I put power off and power on in one ioctl.
> > > > > At first, I also tried to make power on and power off into two ioctls.
> > > > > But I found after powering off a device, the usbfs device node will
> > > > > be removed and so can't power on the port via the same usbfs node.
> > > > > 
> > > > > For this point, we should add usbfs node for usb port?
> > > > 
> > > > No.
> > > 
> > > I agree that we shouldn't add more usbfs files without thinking very
> > > carefully about it, since lots of tools like libusb use them.  However,
> > > we do need a way to manually power off a port, wait a variable length of
> > > time (or perhaps for a distro-specific event like screen unblank), and
> > > turn the port on.
> > > 
> > > So how do we turn the port power back on with the options we have?
> > > Would userspace have to turn the port power off via usbfs, and then
> > > manually back on by setting the port's sysfs power/control to 'on'?
> > 
> > Whatever method we use, it should be the same interface for both on
> > and off, so I would prefer to just use the sysfs one, as usbfs does not
> > represent ports, only USB devices.
> 
> I would prefer that as well.  However, the port power sysfs file
> power/control is created by the runtime PM core, and I think it doesn't
> have a way to manually turn power off.  All we get with the current
> framework is 'on' or 'auto'.  There may be times when userspace wants to
> override the kernel's policy for 'auto' and force a port power off.
> 
> Perhaps the runtime PM core needs to be extended to have a way to allow
> userspace to manually force a device into a lower power state?

We actually considered that when the PM core's runtime PM framework was
being implemented and the answer was "no".  The reason being that user space
has no idea whether or not the device *can* be turned off at the given
time, so the kernel can't guarantee any requests to turn devices off to be
satisfied at any given time.  I believe this is the case for USB ports too.

I don't think anything has changed in that respect since then.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Sarah Sharp]

Cc-ing the linux-pm list and some Intel power devs, as I think this
specific discussion could benefit from a broader audience.

On Mon, Apr 08, 2013 at 12:33:00PM -0400, Alan Stern wrote:
> On Mon, 8 Apr 2013, Greg KH wrote:
> 
> > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote:
> > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote:
> > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote:
> > > > > On 2013/3/30 4:24, Alan Stern wrote:
> > > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote:
> > > > > Hi Alan & Sarah:
> > > > > 	I just recall why I put power off and power on in one ioctl.
> > > > > At first, I also tried to make power on and power off into two ioctls.
> > > > > But I found after powering off a device, the usbfs device node will
> > > > > be removed and so can't power on the port via the same usbfs node.
> > > > > 
> > > > > For this point, we should add usbfs node for usb port?
> > > > 
> > > > No.
> > > 
> > > I agree that we shouldn't add more usbfs files without thinking very
> > > carefully about it, since lots of tools like libusb use them.  However,
> > > we do need a way to manually power off a port, wait a variable length of
> > > time (or perhaps for a distro-specific event like screen unblank), and
> > > turn the port on.
> > > 
> > > So how do we turn the port power back on with the options we have?
> > > Would userspace have to turn the port power off via usbfs, and then
> > > manually back on by setting the port's sysfs power/control to 'on'?
> > 
> > Whatever method we use, it should be the same interface for both on
> > and off, so I would prefer to just use the sysfs one, as usbfs does not
> > represent ports, only USB devices.
> 
> There is a way we can do it using the existing usbfs framework.  The
> new ioctls could be sent to the parent hub, instead of the device
> attached to the port.  Rather like USBDEVFS_CLAIM_PORT and
> USBDEVFS_RELEASE_PORT.

That could work.  However, we have to think about future platform power
changes as well.  Coming up with a USB specific way to work around the
runtime PM core will hurt us in the long run, if we end up having to
change the runtime PM core for another kernel user.

Len, Rafael, and Kristen, is there a need from any of the future power
work to have an 'off' mechanism added to the runtime PM core, so that
power/control would have 'on', 'auto', and 'off' options?  It currently
only has 'on' and 'auto'.

The kernel is always going to be more conservative about what policies
cause the 'auto' option to turn off USB ports.  A Linux distro may want
to override those policies and force the port off, or power off a
misbehaving device for a hard reset.  That's why we need an 'off'
extension to power/control to bypass the runtime PM usage counts and
power something off.

Are there analogous needs for other users of power/control?

Sarah Sharp

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

[Alan Stern]

On Mon, 8 Apr 2013, Sarah Sharp wrote:

> That could work.  However, we have to think about future platform power
> changes as well.  Coming up with a USB specific way to work around the
> runtime PM core will hurt us in the long run, if we end up having to
> change the runtime PM core for another kernel user.
> 
> Len, Rafael, and Kristen, is there a need from any of the future power
> work to have an 'off' mechanism added to the runtime PM core, so that
> power/control would have 'on', 'auto', and 'off' options?  It currently
> only has 'on' and 'auto'.

I can't say anything about future power work -- Len, Rafael, et al.  
will have to speak to that -- but the current design of the runtime PM
core doesn't allow for a distinction between "low power" and "no
power".  As far as the core is concerned, either the device is fully
active or else it isn't (i.e., it is suspended).  To change this would
be a major rewrite.

> The kernel is always going to be more conservative about what policies
> cause the 'auto' option to turn off USB ports.  A Linux distro may want
> to override those policies and force the port off, or power off a
> misbehaving device for a hard reset.  That's why we need an 'off'
> extension to power/control to bypass the runtime PM usage counts and
> power something off.
> 
> Are there analogous needs for other users of power/control?

In fact, some other people have made similar requests.  I can't 
remember the exact contexts now...  One of them may have been related 
to the PCI D4cold stuff.

Alan Stern

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

[Rafael J. Wysocki]

On Monday, April 08, 2013 10:55:19 AM Sarah Sharp wrote:
> Cc-ing the linux-pm list and some Intel power devs, as I think this
> specific discussion could benefit from a broader audience.
> 
> On Mon, Apr 08, 2013 at 12:33:00PM -0400, Alan Stern wrote:
> > On Mon, 8 Apr 2013, Greg KH wrote:
> > 
> > > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote:
> > > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote:
> > > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote:
> > > > > > On 2013/3/30 4:24, Alan Stern wrote:
> > > > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote:
> > > > > > Hi Alan & Sarah:
> > > > > > 	I just recall why I put power off and power on in one ioctl.
> > > > > > At first, I also tried to make power on and power off into two ioctls.
> > > > > > But I found after powering off a device, the usbfs device node will
> > > > > > be removed and so can't power on the port via the same usbfs node.
> > > > > > 
> > > > > > For this point, we should add usbfs node for usb port?
> > > > > 
> > > > > No.
> > > > 
> > > > I agree that we shouldn't add more usbfs files without thinking very
> > > > carefully about it, since lots of tools like libusb use them.  However,
> > > > we do need a way to manually power off a port, wait a variable length of
> > > > time (or perhaps for a distro-specific event like screen unblank), and
> > > > turn the port on.
> > > > 
> > > > So how do we turn the port power back on with the options we have?
> > > > Would userspace have to turn the port power off via usbfs, and then
> > > > manually back on by setting the port's sysfs power/control to 'on'?
> > > 
> > > Whatever method we use, it should be the same interface for both on
> > > and off, so I would prefer to just use the sysfs one, as usbfs does not
> > > represent ports, only USB devices.
> > 
> > There is a way we can do it using the existing usbfs framework.  The
> > new ioctls could be sent to the parent hub, instead of the device
> > attached to the port.  Rather like USBDEVFS_CLAIM_PORT and
> > USBDEVFS_RELEASE_PORT.
> 
> That could work.  However, we have to think about future platform power
> changes as well.  Coming up with a USB specific way to work around the
> runtime PM core will hurt us in the long run, if we end up having to
> change the runtime PM core for another kernel user.
> 
> Len, Rafael, and Kristen, is there a need from any of the future power
> work to have an 'off' mechanism added to the runtime PM core, so that
> power/control would have 'on', 'auto', and 'off' options?  It currently
> only has 'on' and 'auto'.

There's no such work for the reason given in another message a while ago.

> The kernel is always going to be more conservative about what policies
> cause the 'auto' option to turn off USB ports.  A Linux distro may want
> to override those policies and force the port off, or power off a
> misbehaving device for a hard reset.  That's why we need an 'off'
> extension to power/control to bypass the runtime PM usage counts and
> power something off.

Then please make it USB-specific.  Although I believe it would be
dangerous, too, if used without care (say, for a storage device attached
via USB).

I *think* it might be better to have a "force power cycle" interface for
USB ports that would be clearly named and documented so that there's no
confusion as to what it is for.

> Are there analogous needs for other users of power/control?

No, there aren't.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

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

[Sarah Sharp]

On Mon, Apr 08, 2013 at 09:39:07PM +0200, Rafael J. Wysocki wrote:
> On Monday, April 08, 2013 10:55:19 AM Sarah Sharp wrote:
> > Cc-ing the linux-pm list and some Intel power devs, as I think this
> > specific discussion could benefit from a broader audience.
> > 
> > On Mon, Apr 08, 2013 at 12:33:00PM -0400, Alan Stern wrote:
> > > On Mon, 8 Apr 2013, Greg KH wrote:
> > > 
> > > > On Mon, Apr 08, 2013 at 08:57:43AM -0700, Sarah Sharp wrote:
> > > > > On Mon, Apr 08, 2013 at 06:29:36AM -0700, Greg KH wrote:
> > > > > > On Mon, Apr 08, 2013 at 08:58:09PM +0800, Lan Tianyu wrote:
> > > > > > > On 2013/3/30 4:24, Alan Stern wrote:
> > > > > > > >On Fri, 29 Mar 2013, Sarah Sharp wrote:
> > > > > > > Hi Alan & Sarah:
> > > > > > > 	I just recall why I put power off and power on in one ioctl.
> > > > > > > At first, I also tried to make power on and power off into two ioctls.
> > > > > > > But I found after powering off a device, the usbfs device node will
> > > > > > > be removed and so can't power on the port via the same usbfs node.
> > > > > > > 
> > > > > > > For this point, we should add usbfs node for usb port?
> > > > > > 
> > > > > > No.
> > > > > 
> > > > > I agree that we shouldn't add more usbfs files without thinking very
> > > > > carefully about it, since lots of tools like libusb use them.  However,
> > > > > we do need a way to manually power off a port, wait a variable length of
> > > > > time (or perhaps for a distro-specific event like screen unblank), and
> > > > > turn the port on.
> > > > > 
> > > > > So how do we turn the port power back on with the options we have?
> > > > > Would userspace have to turn the port power off via usbfs, and then
> > > > > manually back on by setting the port's sysfs power/control to 'on'?
> > > > 
> > > > Whatever method we use, it should be the same interface for both on
> > > > and off, so I would prefer to just use the sysfs one, as usbfs does not
> > > > represent ports, only USB devices.
> > > 
> > > There is a way we can do it using the existing usbfs framework.  The
> > > new ioctls could be sent to the parent hub, instead of the device
> > > attached to the port.  Rather like USBDEVFS_CLAIM_PORT and
> > > USBDEVFS_RELEASE_PORT.
> > 
> > That could work.  However, we have to think about future platform power
> > changes as well.  Coming up with a USB specific way to work around the
> > runtime PM core will hurt us in the long run, if we end up having to
> > change the runtime PM core for another kernel user.
> > 
> > Len, Rafael, and Kristen, is there a need from any of the future power
> > work to have an 'off' mechanism added to the runtime PM core, so that
> > power/control would have 'on', 'auto', and 'off' options?  It currently
> > only has 'on' and 'auto'.
> 
> There's no such work for the reason given in another message a while ago.
> 
> > The kernel is always going to be more conservative about what policies
> > cause the 'auto' option to turn off USB ports.  A Linux distro may want
> > to override those policies and force the port off, or power off a
> > misbehaving device for a hard reset.  That's why we need an 'off'
> > extension to power/control to bypass the runtime PM usage counts and
> > power something off.
> 
> Then please make it USB-specific.  Although I believe it would be
> dangerous, too, if used without care (say, for a storage device attached
> via USB).

All right, then let's make this USB specific.  Alan's idea of making the
ioctls bind to the parent hub makes sense.

And yes, userspace will have to take care about which ports it powers
off.  I think we currently expose enough information about what devices
are attached to which ports to allow Linux distros to make smart
decisions about what to allow to be powered off.

Sarah Sharp