Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit a9030986 authored by Alan Stern's avatar Alan Stern Committed by Greg Kroah-Hartman
Browse files

USB: deprecate the power/level sysfs attribute 



This patch (as1367) deprecates USB's power/level sysfs attribute in
favor of the power/control attribute provided by the runtime PM core.
The two attributes do the same thing.

It would be nice to replace power/level with a symlink to
power/control, but at the moment sysfs doesn't offer any way to do so.

Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
parent 9e18c821

Documentation/ABI/obsolete/sysfs-bus-usb

0 → 100644
+31 −0
Original line number Diff line number Diff line 
What:		/sys/bus/usb/devices/.../power/level

Date:		March 2007

KernelVersion:	2.6.21

Contact:	Alan Stern <stern@rowland.harvard.edu>

Description:

		Each USB device directory will contain a file named

		power/level.  This file holds a power-level setting for

		the device, either "on" or "auto".



		"on" means that the device is not allowed to autosuspend,

		although normal suspends for system sleep will still

		be honored.  "auto" means the device will autosuspend

		and autoresume in the usual manner, according to the

		capabilities of its driver.



		During normal use, devices should be left in the "auto"

		level.  The "on" level is meant for administrative uses.

		If you want to suspend a device immediately but leave it

		free to wake up in response to I/O requests, you should

		write "0" to power/autosuspend.



		Device not capable of proper suspend and resume should be

		left in the "on" level.  Although the USB spec requires

		devices to support suspend/resume, many of them do not.

		In fact so many don't that by default, the USB core

		initializes all non-hub devices in the "on" level.  Some

		drivers may change this setting when they are bound.



		This file is deprecated and will be removed after 2010.

		Use the power/control file instead; it does exactly the

		same thing.

Documentation/ABI/testing/sysfs-bus-usb

+0 −28
Original line number Diff line number Diff line
@@ -14,34 +14,6 @@ Description: 
		The autosuspend delay for newly-created devices is set to

		the value of the usbcore.autosuspend module parameter.



What:		/sys/bus/usb/devices/.../power/level

Date:		March 2007

KernelVersion:	2.6.21

Contact:	Alan Stern <stern@rowland.harvard.edu>

Description:

		Each USB device directory will contain a file named

		power/level.  This file holds a power-level setting for

		the device, either "on" or "auto".



		"on" means that the device is not allowed to autosuspend,

		although normal suspends for system sleep will still

		be honored.  "auto" means the device will autosuspend

		and autoresume in the usual manner, according to the

		capabilities of its driver.



		During normal use, devices should be left in the "auto"

		level.  The "on" level is meant for administrative uses.

		If you want to suspend a device immediately but leave it

		free to wake up in response to I/O requests, you should

		write "0" to power/autosuspend.



		Device not capable of proper suspend and resume should be

		left in the "on" level.  Although the USB spec requires

		devices to support suspend/resume, many of them do not.

		In fact so many don't that by default, the USB core

		initializes all non-hub devices in the "on" level.  Some

		drivers may change this setting when they are bound.



What:		/sys/bus/usb/devices/.../power/persist

Date:		May 2007

KernelVersion:	2.6.23

Documentation/usb/power-management.txt

+11 −8
Original line number Diff line number Diff line
@@ -107,7 +107,9 @@ allowed to issue dynamic suspends. 
The user interface for controlling dynamic PM is located in the power/

subdirectory of each USB device's sysfs directory, that is, in

/sys/bus/usb/devices/.../power/ where "..." is the device's ID.  The

relevant attribute files are: wakeup, level, and autosuspend.

relevant attribute files are: wakeup, control, and autosuspend.

(There may also be a file named "level"; this file was deprecated

as of the 2.6.35 kernel and replaced by the "control" file.)



	power/wakeup
@@ -120,7 +122,7 @@ relevant attribute files are: wakeup, level, and autosuspend. 
		while the device is suspended, the change won't take

		effect until the following suspend.)



	power/level

	power/control



		This file contains one of two words: "on" or "auto".

		You can write those words to the file to change the
@@ -148,14 +150,15 @@ relevant attribute files are: wakeup, level, and autosuspend. 
		never to autosuspend.  You can write a number to the

		file to change the autosuspend idle-delay time.



Writing "-1" to power/autosuspend and writing "on" to power/level do

Writing "-1" to power/autosuspend and writing "on" to power/control do

essentially the same thing -- they both prevent the device from being

autosuspended.  Yes, this is a redundancy in the API.



(In 2.6.21 writing "0" to power/autosuspend would prevent the device

from being autosuspended; the behavior was changed in 2.6.22.  The

power/autosuspend attribute did not exist prior to 2.6.21, and the

power/level attribute did not exist prior to 2.6.22.)

power/level attribute did not exist prior to 2.6.22.  power/control

was added in 2.6.34.)





	Changing the default idle-delay time
@@ -212,7 +215,7 @@ among printers and scanners, but plenty of other types of device have 
the same deficiency.



For this reason, by default the kernel disables autosuspend (the

power/level attribute is initialized to "on") for all devices other

power/control attribute is initialized to "on") for all devices other

than hubs.  Hubs, at least, appear to be reasonably well-behaved in

this regard.
@@ -373,7 +376,7 @@ usb_autopm_put_interface() in its close or release routine. But other 
patterns are possible.



The autosuspend attempts mentioned above will often fail for one

reason or another.  For example, the power/level attribute might be

reason or another.  For example, the power/control attribute might be

set to "on", or another interface in the same device might not be

idle.  This is perfectly normal.  If the reason for failure was that

the device hasn't been idle for long enough, a timer is scheduled to
@@ -394,12 +397,12 @@ Drivers can enable autosuspend for their devices by calling 


in their probe() routine, if they know that the device is capable of

suspending and resuming correctly.  This is exactly equivalent to

writing "auto" to the device's power/level attribute.  Likewise,

writing "auto" to the device's power/control attribute.  Likewise,

drivers can disable autosuspend by calling



	usb_disable_autosuspend(struct usb_device *udev);



This is exactly the same as writing "on" to the power/level attribute.

This is exactly the same as writing "on" to the power/control attribute.



Sometimes a driver needs to make sure that remote wakeup is enabled

during autosuspend.  For example, there's not much point

drivers/usb/core/sysfs.c

+12 −0
Original line number Diff line number Diff line
@@ -383,12 +383,23 @@ static DEVICE_ATTR(autosuspend, S_IRUGO | S_IWUSR, 
static const char on_string[] = "on";

static const char auto_string[] = "auto";



static void warn_level(void) {

	static int level_warned;



	if (!level_warned) {

		level_warned = 1;

		printk(KERN_WARNING "WARNING! power/level is deprecated; "

				"use power/control instead\n");

	}

}



static ssize_t

show_level(struct device *dev, struct device_attribute *attr, char *buf)

{

	struct usb_device *udev = to_usb_device(dev);

	const char *p = auto_string;



	warn_level();

	if (udev->state != USB_STATE_SUSPENDED && !udev->dev.power.runtime_auto)

		p = on_string;

	return sprintf(buf, "%s\n", p);
@@ -403,6 +414,7 @@ set_level(struct device *dev, struct device_attribute *attr, 
	char *cp;

	int rc = count;



	warn_level();

	cp = memchr(buf, '\n', count);

	if (cp)

		len = cp - buf;