login
Search
/proc/acpi/alarm can't be set correctly, here is a sample:
[root@localhost /]# echo "2006 09" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
2007-12-09 09:09:09
[root@localhost /]# echo "2006 04" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
2007-12-04 04:04:04
[root@localhost /]#Obviously, it is wrong, it should consider it as an invalid input.
This patch'll fix this issue, after applying this patch, the result is:
[root@localhost /]# echo "2008 09" > /proc/acpi/alarm
-bash: echo: write error: Invalid argument
[root@localhost /]#Signed-off by Yi Yang <yi.y.yang@intel.com>
diff --git a/drivers/acpi/sleep/proc.c b/drivers/acpi/sleep/proc.c
index 1538355..fce78fb 100644
--- a/drivers/acpi/sleep/proc.c
+++ b/drivers/acpi/sleep/proc.c
@@ -178,6 +178,9 @@ static int get_date_field(char **p, u32 * value)
* Try to find delimeter, only to insert null. The end of the
* string won't have one, but is still valid.
*/
+ if (*p == NULL)
+ return result;
+
next = strpbrk(*p, "- :");
if (next)
*next++ = '\0';
@@ -190,6 +193,8 @@ static int get_date_field(char **p, u32 * value)if (next)
*p = next;
+ else
+ *p = NULL;return result;
}--
In function acpi_system_write_alarm in file drivers/acpi/sleep/proc.c,
big sec, min, hr, mo, day and yr are counted twice to get reasonable
values, that is very superfluous, we can do that only once.In additon, /proc/acpi/alarm can set a related value which can be
specified as YYYY years MM months DD days HH hours MM minutes SS
senconds, it isn't a date, so you can specify as +0000-00-00 96:00:00
, that means 3 days later, current code can't handle such a case.This patch removes unnecessary code and does with the aforementioned
situation.Before applying this patch:
[root@localhost /]# cat /proc/acpi/alarm
2007-12-00 00:00:00
[root@localhost /]# echo "0000-00-00 96:180:180" > /proc/acpi/alarm
[root@localhost /]# cat /proc/acpi/alarm
0007-12-02 **:**:**
[root@localhost /]#After applying this patch:
[root@localhost ~]# echo "2007-12-00 00:00:00" > /proc/acpi/alarm
[root@localhost ~]# cat /proc/acpi/alarm
2007-12-00 00:00:00
[root@localhost ~]# echo "0000-00-00 96:180:180" > /proc/acpi/alarm
[root@localhost ~]# cat /proc/acpi/alarm
0007-12-04 03:03:00
[root@localhost ~]#Signed-off by Yi Yang <yi.y.yang@intel.com>
diff --git a/drivers/acpi/sleep/proc.c b/drivers/acpi/sleep/proc.c
index fce78fb..f8df521 100644
--- a/drivers/acpi/sleep/proc.c
+++ b/drivers/acpi/sleep/proc.c
@@ -256,27 +256,6 @@ acpi_system_write_alarm(struct file *file,
if ((result = get_date_field(&p, &sec)))
goto end;- if (sec > 59) {
- min += 1;
- sec -= 60;
- }
- if (min > 59) {
- hr += 1;
- min -= 60;
- }
- if (hr > 23) {
- day += 1;
- hr -= 24;
- }
- if (day > 31) {
- mo += 1;
- day -= 31;
- }
- if (mo > 12) {
- yr += 1;
- mo -= 12;
- }
-
spin_lock_irq(&rtc_lock);rtc_control = CMOS_READ(RTC_CONTROL);
@@ -293,24 +272,24 @@ acpi_system_write_alarm(struct file *file,
spin_unlock_irq(&rtc_lock);if (sec > 59) {
- min++;
- sec -= 60;
+ min += sec/60;
+ sec = sec%60;
}
if (min >...
Subject: ACPI: Correct wakeup set error and append a new column PCI ID
From: Yi Yang <yi.y.yang@intel.com>The user can't get any information when echo an invalid value to
/proc/acpi/wakeup although it is failed, but the user can set
/proc/acpi/wakeup successfully if echo an value whose prefix is a
valid value for /proc/acpi/wakeup no matter what the suffix is./proc/acpi/wakeup is also case-sensitive, case-insensitive is better.
This patch will fix the aforementioned issues, it will return the error
information if input is an invalid value, it also make /proc/acpi/wakeup
case-insensitive, i.e. it consider 'SLPB' and 'sLpb'are the same.In addtion, this patch appends a new column 'PCI ID' to /proc/acpi/wakeup
, the user can use it to get the corresponding device name very
conveniently because PCI ID is a unique identifier and platform-independent.Before applying this patch, the output is:
[root@localhost ~]# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
C093 S5 disabled pci:0000:00:1e.0
C0E8 S3 disabled pci:0000:00:1d.0
C0EF S3 disabled pci:0000:00:1d.1
C0F0 S3 disabled pci:0000:00:1d.2
C0F1 S3 disabled pci:0000:00:1d.3
C0F2 S3 disabled pci:0000:00:1d.7
C0F9 S0 disabled pci:0000:00:1c.0
C21D S0 disabled pci:0000:08:00.0
C109 S5 disabled pci:0000:00:1c.1
C228 S5 disabled pci:0000:10:00.0
C10F S5 disabled pci:0000:00:1c.3
C229 S5 disabled
[root@localhost ~]# echo "xyzw" > /proc/acpi/wakeup
[root@localhost ~]# echo "C093xxxxxxxxx" > /proc/acpi/wakeup
[root@localhost ~]# cat /proc/acpi/wakeup
Device S-state Status Sysfs node
C093 S5 enabled pci:0000:00:1e.0
C0E8 S3 disabled pci:0000:00:1d.0
C0EF S3 disabled pci:0000:00:1d.1
C0F0 S3 disabled pci:0000:00:1d.2
C0F1 S3 disabled pci:0000:00:1d.3
C0F2 S3 disabled pci:0000:00:1d.7
C0F9 S0 disabled pci:0000:...
Userland interface change...?
Maybe this file should be left for compatibility and we should present
something reasonable in /sys? Can't you already get PCI ID from sysfs
node?--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
A user uses device bus id like 'C093' to enable or disable wakeup of the
device, for exampleecho "C093" > /proc/acpi/wakeup
but i think "c093" should also be ok. i.e.
"echo 'c093' > /proc/acpi/wakeup" should have the same result as "echo
'C093' > /proc/acpi/wakeup".Not at all, i didn't find any userland application
assumes /proc/acpi/wakeup must be that kind of format.PCI ID can be gotten from sysfs, but it is a unique identifier for a
device, a user can get device name from /usr/share/hwdata/pci.ids in any
dstribution by PCI ID, he/she is unnecessary to use bus number to get
device name, bus number is platform-specific, but PCI ID is--
Why do you think so? Unix is generally case-sensitive. I see ascii
text in .../wakeup. Maybe some bios vendor is crazy enough to haveIf the same info can be gotten from 'sysfs node' field, new field
should not be added.--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
Of course, when you cat/proc/acpi/wakeup, you get "wake", but when you
want to enable or disable wakeup of the device "wake", you canecho "wAke" > /proc/acpi/wakeup
or
echo "wake" > /proc/acpi/wakeup
--
This is just for users' convenience, i believe you must think 0xff and
Assume you are a user of /proc/acpi/wakeup, when you
cat /proc/acpi/wakeup, you only get PCI bus id, then you need use PCI
bus id to get the device info, that is platform-specific, if you want to
use this PCI bus id to get the device info from another machines, that
is absolutely impossible, but it is ok if it is PCI ID.Moreover, you can very easily get the device info
from /usr/share/hwdata/pci.ids.grep <PCI ID> /usr/share/hwdata/pci.ids
That is more convenient than PCI bus id.
If we can provide PCI ID in /proc/acpi/wakeup, why we let users get that
--
Subject: ACPI: fix acpi fan state set error
From: Yi Yang <yi.y.yang@intel.com>Under /proc/acpi, there is a fan control interface, a user can
set 0 or 3 to /proc/acpi/fan/*/state, 0 denotes D0 state, 3
denotes D3 state, but in current implementation, a user can
set a fan to D1 state by any char excluding '1', '2' and '3'.For example:
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: off
[root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: on
[root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: off
[root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: onObviously, such inputs as "" and "xxxxx" are invalid for fan state.
This patch fixes this issue, it strictly limits fan state only to
accept 0, 1, 2 and 3, any other inputs are invalid.Before applying this patch, the test result is:
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: off
[root@localhost acpi]# echo "" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: on
[root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: off
[root@localhost acpi]# echo "xxxxx" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: on
[root@localhost acpi]# echo "3" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: off
[root@localhost acpi]# echo "3x" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# cat /proc/acpi/fan/C31B/state
status: off
[root@localhost acpi]# echo "-1x" > /proc/acpi/fan/C31B/state
[root@localhost acpi]# c...
Subject: ACPI: fix processor throttling set error
From: Yi Yang <yi.y.yang@intel.com>When echo some invalid values to /proc/acpi/processor/*/throttling,
there isn't any error info returned, on the contray, it sets
throttling value to some T* successfully, obviously, this is incorrect,
a correct way should be to let it fail and return error info.This patch fixed the aforementioned issue, it also enables
/proc/acpi/processor/*/throttling to accept such values as 't0' and 'T0',
it also strictly limits /proc/acpi/processor/*/throttling only to accept
"*", "t*" and "T*", "*" is the throttling state value the processor can
support, current, it is 0 - 7.Before applying this patch, the test result is below:
[root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T1
state available: T0 to T7
states:
T0: 100%
*T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
[root@localhost acpi]# echo "1xxxxxx" > /proc/acpi/processor/CPU0/throttling
[root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T1
state available: T0 to T7
states:
T0: 100%
*T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: 25%
T7: 12%
[root@localhost acpi]# echo "0" > /proc/acpi/processor/CPU0/throttling
[root@localhost acpi]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state: T0
state available: T0 to T7
states:
*T0: 100%
T1: 87%
T2: 75%
T3: 62%
T4: 50%
T5: 37%
T6: ...
Subject: ACPI: convert procfs to sysfs for /proc/acpi/wakeup
From: Yi Yang <yi.y.yang@intel.com>/proc/acpi/wakeup is deprecated but it has to exist because
we haven't a sysfs interface to replace it yet, this patch
converts /proc/acpi/wakeup to sysfs interface, under every
acpi device sysfs node, a user can see a directory "wakeup"
if the acpi device can support wakeup, there are six files
under this directory:acpi_bus_id bus_id pci_id run_wakeup sleep_state status
All the files are read-only exclude "status" which is used
to enable or disable wakeup of the acpi device."acpi_bus_id" is acpi bus ID of the acpi device.
"bus_id" is pci bus id of the device associated to the acpi
device, it will be empty if there isn't any device associated
to it."pci_id" is PCI ID of the pci device associated to the acpi
device, it will be empty if there isn't any device associated
to it."run_wake" is a flag indicating if a wakeup process is being
handled."sleep_state" is sleep state of the acpi device such as "S0".
"status" is wakeup status of the acpi device, it is enabled
or disabled, a user can change it be echoing "0", "1",
"disabled" or "enabled" to /sys/devices/.../wakeup/status.Here is the test result:
[root@localhost ~]# cat /proc/acpi/wakeup
Device S-state Status Sysfs node PCI ID
C093 S5 disabled pci:0000:00:1e.0 0x2448
C0E8 S3 disabled pci:0000:00:1d.0 0x27c8
C0EF S3 disabled pci:0000:00:1d.1 0x27c9
C0F0 S3 disabled pci:0000:00:1d.2 0x27ca
C0F1 S3 disabled pci:0000:00:1d.3 0x27cb
C0F2 S3 disabled pci:0000:00:1d.7 0x27cc
C0F9 S0 disabled pci:0000:00:1c.0 0x27d0
C21D S0 disabled pci:0000:08:00.0 0x16fd
C109 S5 disabled pci:0000:00:1c.1 0x27d2
C228 S5 disabled pci:0000:10:00.0 0x4222
C10F S5 disabled pci:0000:00:1c.3 0x27d6
C229 S5 disabled
[root@localhost ~]# find /sys ...
I think that it would be much much better to place wake-up attributes under
corresponding PCI and PNP devices.Probably it is even better to link this code to PCI code, so PCI drivers will be aware of ACPI.
For example it will fix the 'EHCI instantly wakes up the system from S4' on my system, since here USB doesn't wake
up anything from S4, and ACPI tables correctly show that.If ehci driver was aware of that it could disable #PME on entrance to S4.
And we even can reuse its 'wakeup' attribute, thus enabling wakeup automatically.Going ever further, I think that it will be great to get rid of ACPI device tree, since
most acpi devices are ether PCI of PNP ones.Or, even better have a small ACPI tree, that will contain 'true' ACPI devices, like cpus
thermal sensors, buttons, etc.Best regards,
Maxim Levitsky
--
I like this idea, maxim. :)
And that's what we actually did about half a year ago.Yi,
Please refer to http://bugzilla.kernel.org/show_bug.cgi?id=6892
and David's patch set here:
http://marc.info/?l=linux-mm-commits&m=117701595209299&w=2
http://marc.info/?l=linux-mm-commits&m=117701866524935&w=2
You can have a look at this thread as well:
http://marc.info/?l=linux-acpi&m=119982937409968&w=2thanks,
--
I checked those patches you mentioned, they did bind two wakeup flag to
some extent, but they can't be exchanged to use and they are just partly
in current linus tree, two flags bind isn't in linus tree.According to my test on the latest linus tree, wakeup flag of
acpi_device hasn't any association with device's, i don't know if they
are the same thing. if we enbale or disable it manually, what will
happen? From source code, it is just a flag, it doesn't trigger any--
Any news on this?
I ran into a problem with the current implementation:If one GPE is tight to several devices you get a message:
echo XYZ >/tmp/acpi/wakeup
ACPI: 'XXX' and 'XYZ' have the same GPE, can't disable/enable one
seperately
ACPI: 'YYY' and 'XYZ' have the same GPE, can't disable/enable one
seperately
and none of the devices are activated to be able to wake the machine up.
Which I expect is wrong, all should be enabled/disabled then IMO, but
it's probably not worth much fixing in /proc/acpi/...The correct interface to use seem to be:
drivers/base/power/sysfs.c
But this is rather broken?
Here an output of /proc/acpi/wakeup and /sys/...:
for x in `find /sys/ |grep wakeup`;do if [ $(cat $x) ];then echo $x; cat $x;fi;done
/sys/devices/pnp0/00:04/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-5/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-1/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.7/usb4/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.7/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.2/usb3/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.1/usb2/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.0/usb1/power/wakeup
enabled
trenn@stravinsky:/extern/trenn/packages/home:trenn> cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PCI0 S5 disabled no-bus:pci0000:00I still think (from comments in drivers/base/power/sysfs.c, not sure
whether it really is that appropriate) it is wakeup sysfs file that
should be used for this.
I wonder why each device has a wakeup file, it should be enough to
create them dynamically if wakeup enable/disable is supported for a
specific device?
Also a second file is missing from which state (S3,S4,S5) the device can
wake the machine up.If there can be multiple devices for one GPE, this information (the
power directory of multiple devices) could be linked together in sysfs?
E.g.
/sys/devices/pci0000:00/0000:00:1d.7/usb4/power/w...
"Can't disable/enable one seperately" is just a warning, all the devices
wakeup flag in this driver is a generic software flag in "struct
device", but the wakeup flag you see in /proc/acpi/wakeup is a hardware
wakeup flag in ACPI device, all the wakeup events triggered by hardware
devices are handled by ACPI driver.But i indeed regret wakeup flags in /sys/... and /proc/acpi/wakeup
haven't any association. They should be consolidated in my opinion.Zhang Rui said they are doing it, but i didn't get any information about
progress, i completely agree it should be done ASAP.If you need to enbale wakeup, you.d better enable wakeup flag in
both /proc/acpi/wakeup and /sys/..., i can use USB mouse to wake up my--
In current kernel the wakeup flag in /proc/acpi/wakeup means whether the
device can wakeup the sleeping system. It is only used to wake the
system from S1/S3/S4.
Now the power/wakeup sys I/F is created for every device. Maybe it is
better that the power/wakeup sys I/F is only created for the device
that can wake up the sleeping system. In order to determine whether the
device can wake up the sleeping system, it is necessary to check whether
the associated ACPI device can support wakeup and whether the native
device can support wakeup (For example: PCI device should support PMENow I am trying to do them. But the difficulty is that we should support
--
And I have some more split-out versions of those patches
now, too. Cleanups and simplifications should be more
directly mergeable, and the tricky bits affecting GPE use
can be addressed by folk who are actively involved in the
nitty-gritty of making the power management parts of ACPI
work right for Linux.I think I'll repost them soonish, to linux-pm and, as relevant,
Currently ACPI wakeup mechanisms are not at all integrated with
driver model mechanisms, or with non-ACPI bits of the system.The "why" of that is that those patches still haven't been merged;
and the "why" of *that* is, AFAICT, that ACPI sleep/wake/resume
support is still in serious flux.The current model is, yes, those are just flags ... and they only
kick in during driver state transitions. Someday we can hope
they will support runtime power management (e.g. putting PCI
devices in PCI_D3hot to save power, then letting them trigger
runtime wake events when external hardware asks for that) ...
but for now, those transitions only kick in when the system asThere's a bit of state in the ACPI device nodes that's not
currently visible through PCI or PNP. The patch I posted
a while back to cross-link ACPI nodes to the "real" nodes
should help sort out some of that. (Basically, it's justNot from me, but that sounds like a useful direction. In
the same vein, it'd make sense to properly root PCI from theIn short: only USB portions of the tree have those flags set,
since USB (a) has some workarounds for the lack of ACPI support
on OHCI and EHCI controllers, like 00:1d.7, and (b) supports
those flags for devices that ACPI doesn't know about, such as
most USB keyboards, hubs, mice, and so forth. Plus, (c) you
aren't using the rtc-cmos driver, which works better with the
rest of Linux than the legacy drivers/char/rtc driver.If you had applied patches like my "teach ACPI how to use the
Hmm, and (d) you've got a system that doesn't do much in terms
of ACPI wakeup: a PCI root bridge, and maybe...
Right. Now the system only supports that the device wakes the whole
sleeping system. Maybe it is necessary to add the runtime wakeup
It seems that the following only means that the PME is supported by the
USB PCI device.
> /sys/devices/pci0000:00/0000:00:1d.7/power/wakeup
When the system enters the sleeping state, whether the 1d.7 PCI device
can wake the system is related to the following two factors:
a. /proc/acpi/wakeup flag for 1d.7 PCI device is enabled.
b. the Power/wakeup flag in Sys I/F is enabled. ( It means that PME
Yes. the second file is ACPI-specific. We should add this file. And the
info should be obtained by the associated ACPI device. Maybe it is
better that it is create in the subdirectory of ACPI device and the link--
That's "barely" supported ... disabled by default, hard to
That'd go more smoothly if we first made the "easier" wake
event support work properly. After all, that's basically
just making code that's been there for years always kick
in during system sleep transitions, and helping to make sureIt's set by that HCD as it initializes, because ACPI still
doesn't do so. There are hardware flags the BIOS sets and
the HCD sees, which in this case partially make up for the
weak support from ACPI.And it's not specific to PME#, except with EHCI. With
OHCI for example those flags get set with "legacy" PCIAnd the /proc/acpi/wakeup stuff needs to go away, in favor
of standard driver model mechanisms that (a) aren't specific
to ACPI, and (b) don't default to "off, and hard to turn on".Note that on at least some systems it seems that the ACPI bits
aren't entirely necessary. When the driver enables PCI wakeup
mechanisms, the hardware reacts well enough to wake the system
even if ACPI has not *also* told it do do so. (Of course it'd
be better if there were no issues about whether ACPI has beenIf ACPI-specific state like that "should" be exported, it should
be in an ACPI-specific portion of the tree. And as for that link,
I'm still not clear on why the patch inhttp://marc.info/?l=linux-acpi&m=120500563430488&w=2
still hasn't merged ... that provides the relevant linkage in
--
Currently, all devices have had an wakeup attribute, it
is /sys/.../power/wakeup, for example:/sys/devices/pci0000\:00/0000\:00\:00.0/power/wakeup
/sys/class/tty/console/power/wakeupBut it isn't the same as acpi device's, you can get all acpi devices
with wakeup features from /proc/acpi/wakeup, you can also get all the
"power/wakeup" from /sys, they aren't 1:1.[yangyi@yangyi-dev ~]$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node PCI ID
SLPB S4 *enabled
P32 S4 disabled pci:0000:00:1e.0 0x244e
UAR1 S4 disabled pnp:00:09 0x0000
ILAN S4 disabled pci:0000:00:19.0 0x104b
PEGP S4 disabled pci:0000:00:01.0 0x29a1
PEX0 S4 disabled pci:0000:00:1c.0 0x283f
PEX1 S4 disabled pci:0000:00:1c.1 0x2841
PEX2 S4 disabled pci:0000:00:1c.2 0x2843
PEX3 S4 disabled pci:0000:00:1c.3 0x2845
PEX4 S4 disabled pci:0000:00:1c.4 0x2847
PEX5 S4 disabled
UHC1 S3 disabled pci:0000:00:1d.0 0x2830
UHC2 S3 disabled pci:0000:00:1d.1 0x2831
UHC3 S3 disabled pci:0000:00:1d.2 0x2832
UHC4 S3 disabled
EHCI S3 disabled pci:0000:00:1d.7 0x2836
EHC2 S3 disabled pci:0000:00:1a.7 0x283a
UH42 S3 disabled pci:0000:00:1a.0 0x2834
UHC5 S3 disabled pci:0000:00:1a.1 0x2835
AZAL S3 disabled pci:0000:00:1b.0 0x284b
[yangyi@yangyi-dev ~]$ /home/yangyi/wakeup.sh
/sys/devices/pci0000:00/0000:00:1a.0/usb1/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1a.1/usb2/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1a.7/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1a.7/usb6/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.0/usb3/power/wakeup
enabled
/sys/devices/pci0000:00/0000:00:1d.0/usb3/3-2/power/wakeup
enabled
/sys/devices/pci0000:...
This should tell you how bad is placing PCI ID into generic file.
NAK.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
Let's not merge this yet, then, otherwise we'll be forced to carry
around a sysfs API that's of no real use.--
Matthew Garrett | mjg59@srcf.ucam.org
--
Subject: ACPI: fix processor limit set error
From: Yi Yang <yi.y.yang@intel.com>when echo some invalid values to /proc/acpi/processor/CPU*/limit,
it doesn't return any error info, on the contrary, it successes
and sets some other values, for example:[root@localhost /]# echo "0:0A" >/proc/acpi/processor/CPU0/limit
[root@localhost /]# cat /proc/acpi/processor/CPU0/limit
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
[root@localhost /]# echo "0:0F" >/proc/acpi/processor/CPU0/limit
[root@localhost /]# cat /proc/acpi/processor/CPU0/limit
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
[root@localhost /]# echo "0:0 0:1 0:2" >/proc/acpi/processor/CPU0/limit
[root@localhost /]# cat /proc/acpi/processor/CPU0/limit
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
[root@localhost /]#A correct way is that it should fail and return error info.
This patch fixed this issue, it accepts not only such inputs as "*:*",
but also accepts such inputs as "p*:t*" or "P*:T*" or "p*:*" or "*:t*",
the former "*" in inputs means the allowed processor performance state,
currently it is only a stub and not set to the processor limit data
structure, the latter "*" means the allowed processor throttling state
which rages from 0 to 7 generally. This patch strictly limits inputs to
meet the above conditions, any input which can't meet the above conditions
is considered as invalid input.Before applying this patch, the test result is below:
[root@localhost /]# echo "0:0A" >/proc/acpi/processor/CPU0/limit
[root@localhost /]# cat /proc/acpi/processor/CPU0/limit
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
[root@localhost /]# echo "0:0F" >/proc/acpi/processor/CPU0/limit
[root@localhost /]# cat /proc/acpi/processor/CPU0/limit
active limit: P0:T0
user limit: P0:T0
thermal li...
Subject: ACPI: Create proc entry 'power' only C2 or C3 is supported
From: Yi Yang <yi.y.yang@intel.com>ACPI processor idle driver makes sense only if the processor supports
C2 or C3. For legacy C0 and C1, just the original pm_idle is working
, statistics info about promotion, demotion, latency, usage and
duration are empty or 0, so these are misleading, users'll think their
CPUs support C states (C2 or C3), /proc/acpi/processor/CPU*/power
shouldn't exist for this case at all.This patch fixes this issue, it makes ACPI processor idle driver to create
proc entry only if the processor supports C2 or C3.Signed-off-by: Yi Yang <yi.y.yang@intel.com>
---
processor_idle.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)--- a/drivers/acpi/processor_idle.c 2008-01-24 05:34:29.000000000 +0800
+++ b/drivers/acpi/processor_idle.c 2008-01-24 07:04:59.000000000 +0800
@@ -1738,17 +1738,17 @@ int __cpuinit acpi_processor_power_init(
pm_idle = acpi_processor_idle;
}
#endif
- }- /* 'power' [R] */
- entry = create_proc_entry(ACPI_PROCESSOR_FILE_POWER,
- S_IRUGO, acpi_device_dir(device));
- if (!entry)
- return -EIO;
- else {
- entry->proc_fops = &acpi_processor_power_fops;
- entry->data = acpi_driver_data(device);
- entry->owner = THIS_MODULE;
+ /* 'power' [R] */
+ entry = create_proc_entry(ACPI_PROCESSOR_FILE_POWER,
+ S_IRUGO, acpi_device_dir(device));
+ if (!entry)
+ return -EIO;
+ else {
+ entry->proc_fops = &acpi_processor_power_fops;
+ entry->data = acpi_driver_data(device);
+ entry->owner = THIS_MODULE;
+ }
}return 0;
@@ -1763,7 +1763,8 @@ int acpi_processor_power_exit(struct acp
#endif
pr->flags.power_setup_done = 0;- if (acpi_device_dir(device))
+ if (acpi_device_dir(device) &&
+ ((pr->flags.power) && (!boot_option_idle_override)))
remove_proc_entry(ACPI_PROCESSOR_FILE_POWER,
acpi_device_dir(device));...
..
On the other hand, this change might send many of us scrambling
to try and figure out which kernel CONFIG option is responsible
for the expected /proc/acpi/processor/CPU*/power entries not showing up.
Thus just adding to the confusion by as much as it saves.What do others think?
--
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Jeff Garzik | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Paul E. McKenney | [PATCH RFC 3/9] RCU: Preemptible RCU |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Gerrit Renker | [PATCH 13/37] dccp: Deprecate Ack Ratio sysctl |
| Patrick McHardy | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
