Re: PNP: do not stop/start devices in suspend/resume path
On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas [EMAIL PROTECTED] wrote: PNP: do not stop/start devices in suspend/resume path Do not disable PNP devices in the suspend path. We still call the driver's suspend method, which should prevent further use of the device, and the protocol suspend method, which may put the device in a low-power state. I'm told that Windows puts devices in a low-power state (Linux does this in the protocol suspend method), but does not use _DIS in the suspend path. Other relevant references: - In the ACPI 3.0b spec, I can't find any mention of _DIS in connection with sleep. And Device Object Notifications, Section 5.6.3, Table 5-43, says we should get a bus check after awakening if hardware was removed while we slept. - This: http://msdn2.microsoft.com/en-us/library/ms810079.aspx makes a similar point about how the OS re-enumerates devices as a result of a power state change (3rd last paragraph of text). - This: http://msdn2.microsoft.com/en-us/library/aa489874.aspx suggests that Windows only stops a device to rebalance hardware resources. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Tested-by: Pierre Ossman [EMAIL PROTECTED] No noticeable issues with suspend or hibernate using this patch. Rgds Pierre signature.asc Description: PGP signature
[GIT PATCH] thinkpad-acpi queue for 2.6.24-rc
Len, Please send this patch series (which is composed of a single patch) to Linus for merging in 2.6.24-rc. It fixes problems on the latest Lenovo ThinkPads (the *61 series), on most Linux distros. Thank you. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ACPI: thinkpad-acpi: fix lenovo keymap for brightness
Several reports from X60 users complained that the default Lenovo keymap issuing EV_KEY KEY_BRIGHTNESS_UP/DOWN input events caused major issues when the proper brightness support through ACPI video.c was loaded. Therefore, remove the generation of these events by default, which is the right thing for T60, X60, R60, T61, X61 and R61 with their latest BIOSes. Distros that want to misuse these events into OSD reporting (which requires an ugly hack from hell in HAL) are welcome to set up the key map they need through HAL. That way, we don't break everyone else's systems. Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED] --- drivers/misc/thinkpad_acpi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index ab23a32..cf56647 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -987,9 +987,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) KEY_UNKNOWN,/* 0x0C: FN+BACKSPACE */ KEY_UNKNOWN,/* 0x0D: FN+INSERT */ KEY_UNKNOWN,/* 0x0E: FN+DELETE */ - KEY_BRIGHTNESSUP, /* 0x0F: FN+HOME (brightness up) */ + KEY_RESERVED, /* 0x0F: FN+HOME (brightness up) */ /* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */ - KEY_BRIGHTNESSDOWN, /* 0x10: FN+END (brightness down) */ + KEY_RESERVED, /* 0x10: FN+END (brightness down) */ KEY_RESERVED, /* 0x11: FN+PGUP (thinklight toggle) */ KEY_UNKNOWN,/* 0x12: FN+PGDOWN */ KEY_ZOOM, /* 0x13: FN+SPACE (zoom) */ -- 1.5.3.2 - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc4-mm1: acpi reboots machine... solved
On Thursday 13 December 2007 12:09:23 am Borislav Petkov wrote:
On Wed, Dec 12, 2007 at 09:21:41AM -0700, Bjorn Helgaas wrote:
On Wednesday 12 December 2007 03:11:23 am Borislav Petkov wrote:
On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
From what i can roughly tell so far it seems like an resource
conflict between acpi and
the pnp requested regions in your patch which result in the
acpi_thermal code
to read the wrong (0xff) temperature value and halt the machine, but
i might be
wrong on the details since acpi is such a big code chunk to swallow.
I think Alexey is on the right track with the PCI resource allocation
failure.
Then it should be the SMBus controller, PCI id 00:1f:3, which is having
problems
registering its io ports region 4, AFAICT.
Yes, it looks like the ioport region 0x540-0x55f is described both in
PNP and ACPI:
/sys/devices/pnp0/00:0d/resources:state = active
/sys/devices/pnp0/00:0d/resources:io 0x540-0x55f
/sys/devices/pnp0/00:0d/resources:io 0x400-0x47f
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 03)
Subsystem: ASUSTeK Computer Inc. Unknown device 1869
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin B routed to IRQ 0
Region 4: I/O ports at 0540 [size=32]
The PCI SMBus device was enabled by a quirk, asus_hides_smbus_lpc().
This quirk seems dangerous to me, and the comments above asus_hides_smbus
allude to problems similar to what you're seeing. It's obvious that a
lot of blood, sweat, and tears have gone into this quirk, so I'm not
suggesting that it's time to revert it, but I would be interested in
knowing whether the critical temperature problem goes away if we leave
the PCI device hidden, e.g., with the following patch:
Index: linux-mm/drivers/pci/quirks.c
===
--- linux-mm.orig/drivers/pci/quirks.c 2007-12-13 09:11:31.0 -0700
+++ linux-mm/drivers/pci/quirks.c 2007-12-13 09:12:27.0 -0700
@@ -1073,12 +1073,7 @@
pci_read_config_word(dev, 0xF2, val);
if (val 0x8) {
- pci_write_config_word(dev, 0xF2, val (~0x8));
- pci_read_config_word(dev, 0xF2, val);
- if (val 0x8)
- printk(KERN_INFO PCI: i801 SMBus device continues to
play 'hide and seek'! 0x%x\n, val);
- else
- printk(KERN_INFO PCI: Enabled i801 SMBus device\n);
+ printk(KERN_INFO PCI: Leaving i801 SMBus device hidden\n);
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801AA_0,
asus_hides_smbus_lpc);
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] tc1100-wmi: Add driver for HP Compaq TC1100 Tablets
On Wednesday 12 December 2007 07:26:24 Joshua Wise wrote: On Wed, 12 Dec 2007, Carlos Corbacho wrote: + case TC1100_INSTANCE_BLUETOOTH: + *out = (tmp == 1) ? 1 : 0; + return 0; This doesn't actually control Bluetooth. This controls whether the jog dial is in normal mode or brightness select mode. Is this a mistake then from the original tc1100-wmi (the 'bluetooth' file never controlled bluetooth, it always controlled the jog dial), or a mistake in my patch (it should control bluetooth, but is changing the jog dial instead)? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
laptop Benq s41 acpi sleep (now plain text)
Sleep mode (on close laptop) work with both acpi_apic_instance=2 and acpi_osi=!Linux 1. ACPI: BIOS bug: multiple APIC/MADT found, using 2 [0.00] ACPI: If acpi_apic_instance=0 works better, notify linux-acpi@vger.kernel.org 2. [ 23.806190] ACPI: Please test with acpi_osi=!Linux [ 23.806191] Please send dmidecode to linux-acpi@vger.kernel.org dmidecode: # dmidecode 2.9 SMBIOS 2.4 present. 42 structures occupying 1444 bytes. Table at 0x3FEDF000. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: Phoenix Technologies LTD Version: 01.09 Release Date: 08/31/2007 Address: 0xE7F40 Runtime Size: 98496 bytes ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported ACPI is supported USB legacy is supported AGP is supported BIOS boot specification is supported Targeted content distribution is supported Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: BenQ Product Name: Joybook S41 Version: 2.4 Serial Number: 9H07701R3273807770DHS400 UUID: 55F26796-0F00-0010-835C-E801E400F065 Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified Handle 0x0002, DMI type 2, 8 bytes Base Board Information Manufacturer: BenQ Product Name: Joybook S41 Version: 2.4 Serial Number: 9H07701R3273807770DHS400 Handle 0x0003, DMI type 3, 17 bytes Chassis Information Manufacturer: f Type: Other Lock: Not Present Version: N/A Serial Number: None Asset Tag: No Asset Tag Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x1234 Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: U2E1 Type: Central Processor Family: Other Manufacturer: Intel ID: FD 06 00 00 FF FB EB BF Version: CPU Version Voltage: 3.3 V External Clock: Unknown Max Speed: 4096 MHz Current Speed: 2000 MHz Status: Populated, Enabled Upgrade: ZIF Socket L1 Cache Handle: 0x0005 L2 Cache Handle: 0x0006 L3 Cache Handle: Not Provided Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0005, DMI type 7, 19 bytes Cache Information Socket Designation: L1 Cache Configuration: Enabled, Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 64 KB Maximum Size: 64 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: Unknown System Type: Unknown Associativity: Unknown Handle 0x0006, DMI type 7, 19 bytes Cache Information Socket Designation: L2 Cache Configuration: Enabled, Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 2048 KB Maximum Size: 4096 KB Supported SRAM Types: Burst Pipeline Burst Asynchronous Installed SRAM Type: Burst Speed: Unknown Error Correction Type: Unknown System Type: Unknown Associativity: Unknown Handle 0x0007, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J19 Internal Connector Type: 9 Pin Dual Inline (pin 10 cut) External Reference Designator: COM 1 External Connector Type: DB-9 male Port Type: Serial Port 16550A Compatible Handle 0x0008, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1A1 Internal Connector Type: None External Reference Designator: Keyboard External Connector Type: Circular DIN-8 male Port Type: Keyboard Port Handle 0x0009, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: J1A1 Internal Connector Type: None External Reference Designator: PS/2 Mouse External Connector Type: Circular DIN-8 male Port Type: Mouse Port Handle 0x000A, DMI type 9, 13 bytes System Slot Information Designation: PCI Slot J8B3 Type: 32-bit PCI Current Usage: Available Length: Long ID: 3 Characteristics: 5.0 V is provided 3.3 V is provided Handle 0x000B, DMI type 9, 13 bytes System Slot Information Designation: PCI Slot S9B1 Type: 32-bit PCI Current Usage: Unknown Length: Long ID: 0 Characteristics: 5.0 V is provided 3.3 V is provided Handle 0x000C, DMI type 9, 13 bytes System Slot Information Designation: PEG Slot J6B2 Type: 32-bit PCI Express Current Usage: In Use Length: Long ID: 6 Characteristics: 5.0 V is provided 3.3 V is provided Handle 0x000D, DMI type 9, 13 bytes System Slot Information
Re: [PATCH 3/5] tc1100-wmi: Add driver for HP Compaq TC1100 Tablets
On Thu, 13 Dec 2007, Carlos Corbacho wrote: Is this a mistake then from the original tc1100-wmi (the 'bluetooth' file never controlled bluetooth, it always controlled the jog dial), or a mistake in my patch (it should control bluetooth, but is changing the jog dial instead)? This is, as far as I know, a mistake in the original tc1100-wmi. joshua -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: acpi_osi Linux report and questions
On Thursday 13 December 2007 00:06, jason hu wrote: Hi All, With acpi_osi=Linux, which dmesg suggested, I got something changed in the dmesg output(I just listed out the most important things): diff !Linux Linux 79c80 Detected 1733.505 MHz processor. --- Detected 1733.456 MHz processor. 95c96 Calibrating delay using timer specific routine.. 3470.37 BogoMIPS (lpj=1735185) --- Calibrating delay using timer specific routine.. 3470.36 BogoMIPS (lpj=1735181) 121c122 Calibrating delay using timer specific routine.. 3466.35 BogoMIPS (lpj=1733178) --- Calibrating delay using timer specific routine.. 3466.36 BogoMIPS (lpj=1733183) These are not important. PCI: Cannot allocate resource region 7 of bridge :00:06.0 PCI: Cannot allocate resource region 8 of bridge :00:06.0 207c206 MEM window: disabled. --- MEM window: c010-c01f These may be important. It seems with acpi_osi=Linux, it mainly made the two processors equals in BogoMIPS and made a PCI device window available. I am not so familiar with ACPI, so can you tell me what is acpi_osi=Linux used for, and why it made such changes above? Thank you! The BIOS uses it to figure out if the OS is compatible with the capabilities of Linux. Unfortunately, the capabilities of Linux are changing over time, and mose BIOS detection of Linux leads to worse behaviour rather than better... Please file a bug report. attach the output from acpidump, both dmesg, and the dmidecode output. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI power down problem
On Wednesday 12 December 2007 17:40, Stephan Seidl wrote: Dear Len, 2.6.17.4 with maxcpus=1 does not switch off the power (still bad). 2.6.23.9 does switch off the power (works fine). So I am not sure what should be the next step, perhaps a simple Debian bug report. Yes, since latest upstream stable kernel works fine, it is a debian specific (and/or old upstream) issue. You might try some of the older upstream kernels to give the debian folks an idea of how much newer than 2.6.18 they need to go to get the fix. thanks, -Len On Thu, Dec 06, 2007 at 10:51:01PM -0500, Len Brown wrote: On Thursday 06 December 2007 20:18, Stephan Seidl wrote: Hi, I would like to ask two questions, but firstly some history. Normally Debian Sarge is running with the kernel 2.6.14.3 with several patches and all works fine since Dec 2005. In Jul, 2006, I tried another kernel, 2.6.17.4, again with several patches, and again all worked fine with the exception of the fact that the machine did not switch off the power on `/sbin/shutdown -t5 -h -P now'. So I rejected the kernel 2.6.17.4 hoping that the problems would disappear by itself with the time. But, it did not. In Aug 2007, Debian 4.0 r1 appeared with a kernel 2.6.18..., still having the power down problem. Obviously, the problem has been introduced between 2.6.14.3 and 2.6.17.4 and I am the only who has it. The concerning board can be described by Award Medallion BIOS v6.0, An Energy Star Ally ASUS P4B ACPI BIOS Revision 1013 Beta 004 Award Plug and Play BIOS Extension v1.0A This week, to tackle the problem, I addionally applied the patches in the attachment to have the console messages somewhat longer on the screen. I got the same output with the two kernels, 2.6.14.3 and 2.6.17.4, namely Power down. acpi_power_off called hwsleep-0284 [01] enter_sleep_state : Entering sleep state [S5] whereat the line numer 0284 changed to 0283 for 2.6.17.4. What in fact happens after the above has been seen for 20 seconds is that the same machine switches off in case of 2.6.14.3, and wrongly reboots in case of 2.6.17.4. Now the questions, firstly, is that a kernel bug ? From my point of view, yes, it seems to be one. Secondly, if I would more or less stupidly put the debugging into execution, is there anyone who could guide me, because in the ACPI kernel environment, yes, it is a bug. please try linux-2.6.23.stable and see if it still resets on poweroff there. see if there is any difference when you boot with maxcpus=1. cheers, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: acpi -video_device_list corruption
On Wednesday 12 December 2007 07:12, Mikael Pettersson wrote: Acked-by: Mikael Pettersson [EMAIL PROTECTED] applied. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc4-mm1: acpi reboots machine... solved
On Thu, Dec 13, 2007 at 09:17:18AM -0700, Bjorn Helgaas wrote:
On Thursday 13 December 2007 12:09:23 am Borislav Petkov wrote:
On Wed, Dec 12, 2007 at 09:21:41AM -0700, Bjorn Helgaas wrote:
On Wednesday 12 December 2007 03:11:23 am Borislav Petkov wrote:
On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
From what i can roughly tell so far it seems like an resource
conflict between acpi and
the pnp requested regions in your patch which result in the
acpi_thermal code
to read the wrong (0xff) temperature value and halt the machine,
but i might be
wrong on the details since acpi is such a big code chunk to swallow.
I think Alexey is on the right track with the PCI resource allocation
failure.
Then it should be the SMBus controller, PCI id 00:1f:3, which is having
problems
registering its io ports region 4, AFAICT.
Yes, it looks like the ioport region 0x540-0x55f is described both in
PNP and ACPI:
/sys/devices/pnp0/00:0d/resources:state = active
/sys/devices/pnp0/00:0d/resources:io 0x540-0x55f
/sys/devices/pnp0/00:0d/resources:io 0x400-0x47f
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 03)
Subsystem: ASUSTeK Computer Inc. Unknown device 1869
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Interrupt: pin B routed to IRQ 0
Region 4: I/O ports at 0540 [size=32]
The PCI SMBus device was enabled by a quirk, asus_hides_smbus_lpc().
This quirk seems dangerous to me, and the comments above asus_hides_smbus
allude to problems similar to what you're seeing. It's obvious that a
lot of blood, sweat, and tears have gone into this quirk, so I'm not
suggesting that it's time to revert it, but I would be interested in
knowing whether the critical temperature problem goes away if we leave
the PCI device hidden, e.g., with the following patch:
Index: linux-mm/drivers/pci/quirks.c
===
--- linux-mm.orig/drivers/pci/quirks.c2007-12-13 09:11:31.0
-0700
+++ linux-mm/drivers/pci/quirks.c 2007-12-13 09:12:27.0 -0700
@@ -1073,12 +1073,7 @@
pci_read_config_word(dev, 0xF2, val);
if (val 0x8) {
- pci_write_config_word(dev, 0xF2, val (~0x8));
- pci_read_config_word(dev, 0xF2, val);
- if (val 0x8)
- printk(KERN_INFO PCI: i801 SMBus device continues to
play 'hide and seek'! 0x%x\n, val);
- else
- printk(KERN_INFO PCI: Enabled i801 SMBus device\n);
+ printk(KERN_INFO PCI: Leaving i801 SMBus device hidden\n);
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82801AA_0, asus_hides_smbus_lpc);
yep, this fixes it. Bootlog attached.
--
Regards/Gruß,
Boris.
bootlog-smbus-hidden.bz2
Description: Binary data
Re: + git-acpi-build-fix.patch added to -mm tree
On Thursday, 13 of December 2007, [EMAIL PROTECTED] wrote:
The patch titled
git-acpi build fix
has been added to the -mm tree. Its filename is
git-acpi-build-fix.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
--
Subject: git-acpi build fix
From: Andrew Morton [EMAIL PROTECTED]
ia64 allmodconfig:
kernel/power/main.c:493: error: `pm_test_attr' undeclared here (not in a
function)
Cc: Len Brown [EMAIL PROTECTED]
Cc: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
kernel/power/main.c |3 ---
1 file changed, 3 deletions(-)
diff -puN kernel/power/main.c~git-acpi-build-fix kernel/power/main.c
--- a/kernel/power/main.c~git-acpi-build-fix
+++ a/kernel/power/main.c
@@ -489,9 +489,6 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_TRACE
pm_trace_attr.attr,
#endif
-#ifdef CONFIG_PM_DEBUG
- pm_test_attr.attr,
-#endif
Doesn't it kill pm_test_attr on all architectures?
The proper (hopefully) fix is appended (Len, please add it to the suspend
branch).
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Fix compilation problems related to the /sys/power/pm_test attribute.
Namely, this attribute should also be available when
CONFIG_HIBERNATION is set and CONFIG_SUSPEND is unset and it should
not break compilation when neither of them is set.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/power/main.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/kernel/power/main.c
===
--- linux-2.6.orig/kernel/power/main.c
+++ linux-2.6/kernel/power/main.c
@@ -50,10 +50,6 @@ int pm_notifier_call_chain(unsigned long
== NOTIFY_BAD) ? -EINVAL : 0;
}
-#endif /* CONFIG_PM_SLEEP */
-
-#ifdef CONFIG_SUSPEND
-
#ifdef CONFIG_PM_DEBUG
int pm_test_level = TEST_NONE;
@@ -127,6 +123,10 @@ power_attr(pm_test);
static inline int suspend_test(int level) { return 0; }
#endif /* !CONFIG_PM_DEBUG */
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_SUSPEND
+
/* This is just an arbitrary number */
#define FREE_PAGE_NUMBER (100)
@@ -484,7 +484,7 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_TRACE
pm_trace_attr.attr,
#endif
-#ifdef CONFIG_PM_DEBUG
+#if defined(CONFIG_PM_SLEEP) defined(CONFIG_PM_DEBUG)
pm_test_attr.attr,
#endif
NULL,
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 4/8] ACPI: Add reboot mechanism
From: Aaron Durbin [EMAIL PROTECTED]
Add the ability to reset the machine using the RESET_REG in ACPI's FADT table.
[EMAIL PROTECTED]: cleanups]
Signed-off-by: Aaron Durbin [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/Makefile |2 -
drivers/acpi/reboot.c | 44
include/acpi/reboot.h | 10 +
3 files changed, 55 insertions(+), 1 deletion(-)
diff -puN drivers/acpi/Makefile~acpi-add-reboot-mechanism drivers/acpi/Makefile
--- a/drivers/acpi/Makefile~acpi-add-reboot-mechanism
+++ a/drivers/acpi/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_X86) += blacklist.o
#
# ACPI Core Subsystem (Interpreter)
#
-obj-y += osl.o utils.o \
+obj-y += osl.o utils.o reboot.o \
dispatcher/ events/ executer/ hardware/ \
namespace/ parser/ resources/ tables/ \
utilities/
diff -puN /dev/null drivers/acpi/reboot.c
--- /dev/null
+++ a/drivers/acpi/reboot.c
@@ -0,0 +1,44 @@
+
+#include linux/pci.h
+#include acpi/acpi.h
+
+void acpi_reboot(void)
+{
+ struct acpi_generic_address *rr;
+ struct pci_bus *bus0;
+ u8 reset_value;
+ unsigned int devfn;
+
+ rr = acpi_gbl_FADT.reset_register;
+
+ /* Is the reset register supported? */
+ if (!(acpi_gbl_FADT.flags ACPI_FADT_RESET_REGISTER) ||
+ rr-bit_width != 8 || rr-bit_offset != 0)
+ return;
+
+ reset_value = acpi_gbl_FADT.reset_value;
+
+ /* The reset register can only exist in I/O, Memory or PCI config space
+* on a device on bus 0. */
+ switch (rr-space_id) {
+ case ACPI_ADR_SPACE_PCI_CONFIG:
+ /* The reset register can only live on bus 0. */
+ bus0 = pci_find_bus(0, 0);
+ if (!bus0)
+ return;
+ /* Form PCI device/function pair. */
+ devfn = PCI_DEVFN((rr-address 32) 0x,
+ (rr-address 16) 0x);
+ printk(KERN_DEBUG Resetting with ACPI PCI RESET_REG.);
+ /* Write the value that resets us. */
+ pci_bus_write_config_byte(bus0, devfn,
+ (rr-address 0x), reset_value);
+ break;
+
+ case ACPI_ADR_SPACE_SYSTEM_MEMORY:
+ case ACPI_ADR_SPACE_SYSTEM_IO:
+ printk(KERN_DEBUG ACPI MEMORY or I/O RESET_REG.);
+ acpi_hw_low_level_write(8, reset_value, rr);
+ break;
+ }
+}
diff -puN /dev/null include/acpi/reboot.h
--- /dev/null
+++ a/include/acpi/reboot.h
@@ -0,0 +1,10 @@
+#ifndef __ACPI_REBOOT_H
+#define __ACPI_REBOOT_H
+
+#ifdef CONFIG_ACPI
+extern void acpi_reboot(void);
+#else
+static inline void acpi_reboot(void) { }
+#endif
+
+#endif
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/8] git-acpi build fix
From: Andrew Morton [EMAIL PROTECTED]
ia64 allmodconfig:
kernel/power/main.c:493: error: `pm_test_attr' undeclared here (not in a
function)
Cc: Len Brown [EMAIL PROTECTED]
Cc: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
kernel/power/main.c |3 ---
1 file changed, 3 deletions(-)
diff -puN kernel/power/main.c~git-acpi-build-fix kernel/power/main.c
--- a/kernel/power/main.c~git-acpi-build-fix
+++ a/kernel/power/main.c
@@ -489,9 +489,6 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_TRACE
pm_trace_attr.attr,
#endif
-#ifdef CONFIG_PM_DEBUG
- pm_test_attr.attr,
-#endif
NULL,
};
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 8/8] acpi_pci_irq_find_prt_entry(): use list_for_each_entry() instead of list_for_each()
From: Matthias Kaehlcke [EMAIL PROTECTED]
acpi_pci_irq_find_prt_entry(): use list_for_each_entry() instead of
list_for_each()
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/pci_irq.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff -puN
drivers/acpi/pci_irq.c~acpi_pci_irq_find_prt_entry-use-list_for_each_entry-instead-of-list_for_each
drivers/acpi/pci_irq.c
---
a/drivers/acpi/pci_irq.c~acpi_pci_irq_find_prt_entry-use-list_for_each_entry-instead-of-list_for_each
+++ a/drivers/acpi/pci_irq.c
@@ -51,10 +51,8 @@ static struct acpi_prt_entry *acpi_pci_i
int bus,
int device, int pin)
{
- struct list_head *node = NULL;
struct acpi_prt_entry *entry = NULL;
-
if (!acpi_prt.count)
return NULL;
@@ -64,8 +62,7 @@ static struct acpi_prt_entry *acpi_pci_i
*
*/
spin_lock(acpi_prt_lock);
- list_for_each(node, acpi_prt.entries) {
- entry = list_entry(node, struct acpi_prt_entry, node);
+ list_for_each_entry(entry, acpi_prt.entries, node) {
if ((segment == entry-id.segment)
(bus == entry-id.bus)
(device == entry-id.device)
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 7/8] acpi: remove duplicated warning message
From: Miguel Botón [EMAIL PROTECTED]
Remove duplicated warning message in acpi_power_transition()
This warning message is printed by acpi_bus_set_power() so we don't
need to print it again.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/power.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff -puN drivers/acpi/power.c~acpi-remove-duplicated-warning-message
drivers/acpi/power.c
--- a/drivers/acpi/power.c~acpi-remove-duplicated-warning-message
+++ a/drivers/acpi/power.c
@@ -458,11 +458,9 @@ int acpi_power_transition(struct acpi_de
}
end:
- if (result) {
+ if (result)
device-power.state = ACPI_STATE_UNKNOWN;
- printk(KERN_WARNING PREFIX Transitioning device [%s] to D%d\n,
- device-pnp.bus_id, state);
- } else {
+ else {
/* We shouldn't change the state till all above operations succeed */
device-power.state = state;
}
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/8] acpi: enable C3 Power State on Dell Inspiron 8200
From: Arjan van de Ven [EMAIL PROTECTED]
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=8703
[EMAIL PROTECTED]: fix warning]
Cc: Dag Bakke [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/processor_idle.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff -puN
drivers/acpi/processor_idle.c~acpi-enable-c3-power-state-on-dell-inspiron-8200
drivers/acpi/processor_idle.c
---
a/drivers/acpi/processor_idle.c~acpi-enable-c3-power-state-on-dell-inspiron-8200
+++ a/drivers/acpi/processor_idle.c
@@ -96,6 +96,8 @@ static int acpi_processor_set_power_poli
#endif
+static int forced_c3;
+
/*
* IBM ThinkPad R40e crashes mysteriously when going into C2 or C3.
* For now disable this. Probably a bug somewhere else.
@@ -116,6 +118,19 @@ static int set_max_cstate(const struct d
return 0;
}
+/*
+ * Some (Dell) machines have a too large C3 latency set, but it still works
+ * completely. Dell provides a driver for other operating systems to hack
+ * around this bug, so we know it's safe.
+ */
+static int dmi_force_c3(const struct dmi_system_id *id)
+{
+ forced_c3 = 1;
+ printk(KERN_NOTICE PREFIX %s detected - Force enabling C3.,
+ id-ident);
+ return 0;
+}
+
/* Actually this shouldn't be __cpuinitdata, would be better to fix the
callers to only run once -AK */
static struct dmi_system_id __cpuinitdata processor_power_dmi_table[] = {
@@ -174,6 +189,9 @@ static struct dmi_system_id __cpuinitdat
DMI_MATCH(DMI_BIOS_VENDOR,Phoenix Technologies LTD),
DMI_MATCH(DMI_BIOS_VERSION,SHE845M0.86C.0013.D.0302131307)},
(void *)2},
+ { dmi_force_c3, Dell Inspiron 8200, {
+ DMI_MATCH(DMI_SYS_VENDOR,Dell Computer Corporation),
+ DMI_MATCH(DMI_PRODUCT_NAME,Inspiron 8200) }, NULL},
{},
};
@@ -993,11 +1011,12 @@ static void acpi_processor_power_verify_
* C3 latency must be less than or equal to 1000
* microseconds.
*/
- else if (cx-latency ACPI_PROCESSOR_MAX_C3_LATENCY) {
+ if (cx-latency ACPI_PROCESSOR_MAX_C3_LATENCY !forced_c3) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
latency too large [%d]\n, cx-latency));
return;
- }
+ } else if (forced_c3)
+ cx-latency = ACPI_PROCESSOR_MAX_C3_LATENCY;
/*
* PIIX4 Erratum #18: We don't support C3 when Type-F (fast)
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 6/8] acpi4asus: add support for F3Sa
From: Luca Tettamanti [EMAIL PROTECTED]
Add support for ASUS F3Sa notebook. Features:
- LCD on/off
- Brightness
- Wifi kill
- Bluetooth kill
Signed-off-by: Luca Tettamanti [EMAIL PROTECTED]
Cc: Corentin Chary [EMAIL PROTECTED]
Cc: Karol Kozimor [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/asus_acpi.c | 55 ++---
1 file changed, 45 insertions(+), 10 deletions(-)
diff -puN drivers/acpi/asus_acpi.c~acpi4asus-add-support-for-f3sa
drivers/acpi/asus_acpi.c
--- a/drivers/acpi/asus_acpi.c~acpi4asus-add-support-for-f3sa
+++ a/drivers/acpi/asus_acpi.c
@@ -142,6 +142,7 @@ struct asus_hotk {
xxN,//M2400N, M3700N, M5200N, M6800N, S1300N, S5200N
A4S,//Z81sp
//(Centrino)
+ F3Sa,
END_MODEL
} model;//Models currently supported
u16 event_count[128]; //count for each event TODO make this better
@@ -405,7 +406,20 @@ static struct model_data model_conf[END_
.brightness_get= GPLV,
.mt_bt_switch = BLED,
.mt_wled = WLED
- }
+ },
+
+ {
+ .name = F3Sa,
+ .mt_bt_switch = BLED,
+ .mt_wled= WLED,
+ .mt_mled= MLED,
+ .brightness_get = GPLV,
+ .brightness_set = SPLV,
+ .mt_lcd_switch = \\_SB.PCI0.SBRG.EC0._Q10,
+ .lcd_status = \\_SB.PCI0.SBRG.EC0.RPIN,
+ .display_get= \\ADVG,
+ .display_set= SDSP,
+ },
};
@@ -710,15 +724,8 @@ static int get_lcd_state(void)
{
int lcd = 0;
- if (hotk-model != L3H) {
- /* We don't have to check anything if we are here */
- if (!read_acpi_int(NULL, hotk-methods-lcd_status, lcd))
- printk(KERN_WARNING
- Asus ACPI: Error reading LCD status\n);
-
- if (hotk-model == L2D)
- lcd = ~lcd;
- } else {/* L3H and the like have to be handled
differently */
+ if (hotk-model == L3H) {
+ /* L3H and the like have to be handled differently */
acpi_status status = 0;
struct acpi_object_list input;
union acpi_object mt_params[2];
@@ -745,6 +752,32 @@ static int get_lcd_state(void)
if (out_obj.type == ACPI_TYPE_INTEGER)
/* That's what the AML code does */
lcd = out_obj.integer.value 8;
+ } else if (hotk-model == F3Sa) {
+ unsigned long tmp;
+ union acpi_object param;
+ struct acpi_object_list input;
+ acpi_status status;
+
+ /* Read pin 11 */
+ param.type = ACPI_TYPE_INTEGER;
+ param.integer.value = 0x11;
+ input.count = 1;
+ input.pointer = param;
+
+ status = acpi_evaluate_integer(NULL, hotk-methods-lcd_status,
+ input, tmp);
+ if (status != AE_OK)
+ return -1;
+
+ lcd = tmp;
+ } else {
+ /* We don't have to check anything if we are here */
+ if (!read_acpi_int(NULL, hotk-methods-lcd_status, lcd))
+ printk(KERN_WARNING
+ Asus ACPI: Error reading LCD status\n);
+
+ if (hotk-model == L2D)
+ lcd = ~lcd;
}
return (lcd 1);
@@ -1134,6 +1167,8 @@ static int asus_model_match(char *model)
return W5A;
else if (strncmp(model, A4S, 3) == 0)
return A4S;
+ else if (strncmp(model, F3Sa, 4) == 0)
+ return F3Sa;
else
return END_MODEL;
}
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 5/8] rtc: don't write RTC century when setting a wake alarm
From: Mark Lord [EMAIL PROTECTED]
Fix /proc/acpi/alarm to not overwrite the RTC century field when setting a
wake alarm. The alarm hardware doesn't have a century field, and we really
should not be fiddling with the RTC century field here.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Cc: Len Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/acpi/sleep/proc.c |5 -
1 file changed, 5 deletions(-)
diff -puN
drivers/acpi/sleep/proc.c~rtc-dont-write-rtc-century-when-setting-a-wake-alarm
drivers/acpi/sleep/proc.c
---
a/drivers/acpi/sleep/proc.c~rtc-dont-write-rtc-century-when-setting-a-wake-alarm
+++ a/drivers/acpi/sleep/proc.c
@@ -268,7 +268,6 @@ acpi_system_write_alarm(struct file *fil
day -= 31;
}
if (mo 12) {
- yr += 1;
mo -= 12;
}
@@ -277,7 +276,6 @@ acpi_system_write_alarm(struct file *fil
rtc_control = CMOS_READ(RTC_CONTROL);
if (adjust) {
- yr += cmos_bcd_read(RTC_YEAR, rtc_control);
mo += cmos_bcd_read(RTC_MONTH, rtc_control);
day += cmos_bcd_read(RTC_DAY_OF_MONTH, rtc_control);
hr += cmos_bcd_read(RTC_HOURS, rtc_control);
@@ -304,7 +302,6 @@ acpi_system_write_alarm(struct file *fil
day -= 31;
}
if (mo 12) {
- yr++;
mo -= 12;
}
@@ -331,8 +328,6 @@ acpi_system_write_alarm(struct file *fil
cmos_bcd_write(day, acpi_gbl_FADT.day_alarm, rtc_control);
if (acpi_gbl_FADT.month_alarm)
cmos_bcd_write(mo, acpi_gbl_FADT.month_alarm, rtc_control);
- if (acpi_gbl_FADT.century)
- cmos_bcd_write(yr / 100, acpi_gbl_FADT.century, rtc_control);
/* enable the rtc alarm interrupt */
rtc_control |= RTC_AIE;
CMOS_WRITE(rtc_control, RTC_CONTROL);
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/8] git-acpi: ia64 build fix
From: Andrew Morton [EMAIL PROTECTED]
arch/ia64/kernel/acpi.c: In function `acpi_get_sysname':
arch/ia64/kernel/acpi.c:81: error: implicit declaration of function
`acpi_find_rsdp'
arch/ia64/kernel/acpi.c: At top level:
arch/ia64/kernel/acpi.c:631: error: conflicting types for 'acpi_find_rsdp'
arch/ia64/kernel/acpi.c:81: error: previous implicit declaration of
'acpi_find_rsdp' was here
Cc: Len Brown [EMAIL PROTECTED]
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
arch/ia64/kernel/acpi.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff -puN arch/ia64/kernel/acpi.c~git-acpi-ia64-build-fix
arch/ia64/kernel/acpi.c
--- a/arch/ia64/kernel/acpi.c~git-acpi-ia64-build-fix
+++ a/arch/ia64/kernel/acpi.c
@@ -67,7 +67,19 @@ EXPORT_SYMBOL(pm_power_off);
unsigned int acpi_cpei_override;
unsigned int acpi_cpei_phys_cpuid;
-unsigned long acpi_wakeup_address = 0;
+unsigned long acpi_wakeup_address;
+
+unsigned long __init acpi_find_rsdp(void)
+{
+ unsigned long rsdp_phys = 0;
+
+ if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
+ rsdp_phys = efi.acpi20;
+ else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
+ printk(KERN_WARNING PREFIX
+ v1.0/r0.71 tables no longer supported\n);
+ return rsdp_phys;
+}
const char __init *
acpi_get_sysname(void)
@@ -627,18 +639,6 @@ static int __init acpi_parse_fadt(struct
return 0;
}
-unsigned long __init acpi_find_rsdp(void)
-{
- unsigned long rsdp_phys = 0;
-
- if (efi.acpi20 != EFI_INVALID_TABLE_ADDR)
- rsdp_phys = efi.acpi20;
- else if (efi.acpi != EFI_INVALID_TABLE_ADDR)
- printk(KERN_WARNING PREFIX
- v1.0/r0.71 tables no longer supported\n);
- return rsdp_phys;
-}
-
int __init acpi_boot_init(void)
{
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/8] git-acpi build fix
On Friday, 14 of December 2007, [EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
ia64 allmodconfig:
kernel/power/main.c:493: error: `pm_test_attr' undeclared here (not in a
function)
I've already sent a better fix for that, thanks.
Cc: Len Brown [EMAIL PROTECTED]
Cc: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
kernel/power/main.c |3 ---
1 file changed, 3 deletions(-)
diff -puN kernel/power/main.c~git-acpi-build-fix kernel/power/main.c
--- a/kernel/power/main.c~git-acpi-build-fix
+++ a/kernel/power/main.c
@@ -489,9 +489,6 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_TRACE
pm_trace_attr.attr,
#endif
-#ifdef CONFIG_PM_DEBUG
- pm_test_attr.attr,
-#endif
NULL,
};
_
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/8] git-acpi build fix
On Friday, 14 of December 2007, Andrew Morton wrote: On Fri, 14 Dec 2007 01:24:32 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 14 of December 2007, [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] ia64 allmodconfig: kernel/power/main.c:493: error: `pm_test_attr' undeclared here (not in a function) I've already sent a better fix for that, thanks. I don't think I was cc'ed. Please make sure that I see fixes to trees which are in -mm? Well, my mailer testifies that it was To: you and Len. [I was beating it really hard, but it wouldn't confess to lying.] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/8] git-acpi build fix
On Fri, 14 Dec 2007 01:24:32 +0100 Rafael J. Wysocki [EMAIL PROTECTED] wrote: On Friday, 14 of December 2007, [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] ia64 allmodconfig: kernel/power/main.c:493: error: `pm_test_attr' undeclared here (not in a function) I've already sent a better fix for that, thanks. I don't think I was cc'ed. Please make sure that I see fixes to trees which are in -mm? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: + git-acpi-build-fix.patch added to -mm tree
On Thursday 13 December 2007 19:07, Rafael J. Wysocki wrote:
On Thursday, 13 of December 2007, [EMAIL PROTECTED] wrote:
The patch titled
git-acpi build fix
has been added to the -mm tree. Its filename is
git-acpi-build-fix.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
--
Subject: git-acpi build fix
From: Andrew Morton [EMAIL PROTECTED]
ia64 allmodconfig:
ah, good to know that ia64 allmodconfig is supposed to build.
A while back it looked so hopeless that I deleted it from
my test builds and it never got back onto my list.
I guess I should kick off an ia64 allyesconfig and see how that does too...
kernel/power/main.c:493: error: `pm_test_attr' undeclared here (not in a
function)
Cc: Len Brown [EMAIL PROTECTED]
Cc: Rafael J. Wysocki [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
kernel/power/main.c |3 ---
1 file changed, 3 deletions(-)
diff -puN kernel/power/main.c~git-acpi-build-fix kernel/power/main.c
--- a/kernel/power/main.c~git-acpi-build-fix
+++ a/kernel/power/main.c
@@ -489,9 +489,6 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_TRACE
pm_trace_attr.attr,
#endif
-#ifdef CONFIG_PM_DEBUG
- pm_test_attr.attr,
-#endif
Doesn't it kill pm_test_attr on all architectures?
The proper (hopefully) fix is appended (Len, please add it to the suspend
branch).
---
From: Rafael J. Wysocki [EMAIL PROTECTED]
Fix compilation problems related to the /sys/power/pm_test attribute.
Namely, this attribute should also be available when
CONFIG_HIBERNATION is set and CONFIG_SUSPEND is unset and it should
not break compilation when neither of them is set.
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
kernel/power/main.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6/kernel/power/main.c
===
--- linux-2.6.orig/kernel/power/main.c
+++ linux-2.6/kernel/power/main.c
@@ -50,10 +50,6 @@ int pm_notifier_call_chain(unsigned long
== NOTIFY_BAD) ? -EINVAL : 0;
}
-#endif /* CONFIG_PM_SLEEP */
-
-#ifdef CONFIG_SUSPEND
-
#ifdef CONFIG_PM_DEBUG
int pm_test_level = TEST_NONE;
@@ -127,6 +123,10 @@ power_attr(pm_test);
static inline int suspend_test(int level) { return 0; }
#endif /* !CONFIG_PM_DEBUG */
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_SUSPEND
+
/* This is just an arbitrary number */
#define FREE_PAGE_NUMBER (100)
@@ -484,7 +484,7 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_TRACE
pm_trace_attr.attr,
#endif
-#ifdef CONFIG_PM_DEBUG
+#if defined(CONFIG_PM_SLEEP) defined(CONFIG_PM_DEBUG)
pm_test_attr.attr,
#endif
NULL,
Applied.
thanks,
-Len
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI related Warning in 2.6.24-rc3-git2
On Wednesday 28 November 2007 03:31, Lukas Hejtmanek wrote: On Wed, Nov 28, 2007 at 02:11:55AM -0200, Henrique de Moraes Holschuh wrote: On Tue, 27 Nov 2007, Rafael J. Wysocki wrote: in recent kernel, I got the following warnings while booting. It's ACPI related. Does anybode care? Lenovo ThinkPad T61 (6465CTO). Could we know the BIOS version, please? 7LET56WW (1.26 ) (according to hal, 1.26 is definitely correct, can be seen in BIOS as well) I've udpated the BIOS on my T61 to 1.26 to match yours, but running 2.6.24-rc5 I don't see the issue you reported. If it still fails for you, please send me your .config thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ACPI: thinkpad-acpi: fix lenovo keymap for brightness
Applied. thanks, -Len On Thursday 13 December 2007 09:14, Henrique de Moraes Holschuh wrote: Several reports from X60 users complained that the default Lenovo keymap issuing EV_KEY KEY_BRIGHTNESS_UP/DOWN input events caused major issues when the proper brightness support through ACPI video.c was loaded. Therefore, remove the generation of these events by default, which is the right thing for T60, X60, R60, T61, X61 and R61 with their latest BIOSes. Distros that want to misuse these events into OSD reporting (which requires an ugly hack from hell in HAL) are welcome to set up the key map they need through HAL. That way, we don't break everyone else's systems. Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED] --- drivers/misc/thinkpad_acpi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c index ab23a32..cf56647 100644 --- a/drivers/misc/thinkpad_acpi.c +++ b/drivers/misc/thinkpad_acpi.c @@ -987,9 +987,9 @@ static int __init hotkey_init(struct ibm_init_struct *iibm) KEY_UNKNOWN,/* 0x0C: FN+BACKSPACE */ KEY_UNKNOWN,/* 0x0D: FN+INSERT */ KEY_UNKNOWN,/* 0x0E: FN+DELETE */ - KEY_BRIGHTNESSUP, /* 0x0F: FN+HOME (brightness up) */ + KEY_RESERVED, /* 0x0F: FN+HOME (brightness up) */ /* Scan codes 0x10 to 0x1F: Extended ACPI HKEY hot keys */ - KEY_BRIGHTNESSDOWN, /* 0x10: FN+END (brightness down) */ + KEY_RESERVED, /* 0x10: FN+END (brightness down) */ KEY_RESERVED, /* 0x11: FN+PGUP (thinklight toggle) */ KEY_UNKNOWN,/* 0x12: FN+PGDOWN */ KEY_ZOOM, /* 0x13: FN+SPACE (zoom) */ - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Kernel Bugs Weekly (maybe bi-weekly)
This is the listing of open bugs that are not new time wise, mostly over a month old, which is a long time for current rate of development. Most bugs need initial response, and all need attention (tlc). It would be appreciated if the corresponding maintenance team could take a look at the bugs, close off any which are fixed and see if they can fix any which aren't. It would be best to make a note to the reporter and others who are searching for answers in bugzillas that bug is being worked on. (After all, bugzilla is not just a tracking tool, it is a knowledge base for many grateful users.) It is also encouraged setting status to assigned in those bugs that are taken. Thanks. FILESYSTEMS= reiserfs NET=n build error http://bugzilla.kernel.org/show_bug.cgi?id=9205 Kernel: 2.6.19, believed to still exist with current kernel unlink broken in hfsplus - hard links http://bugzilla.kernel.org/show_bug.cgi?id=9204 Kernel: 2.6.22 possible recursive locking near reiserfs_xattr_set http://bugzilla.kernel.org/show_bug.cgi?id=9136 Kernel: 2.6.23-rc8-mm2 Asus A7V133-C desktop AMD Athlon XP 1600+ Assertion failure in journal_stop() (ext3) http://bugzilla.kernel.org/show_bug.cgi?id=9109 Kernel: 2.6.23-rc3 ... Oct 1 17:19:09 wiga kernel: kernel BUG at fs/jbd/transaction.c:1335! Oct 1 17:19:09 wiga kernel: invalid opcode: [#1] ... Oct 1 17:19:09 wiga kernel: EIP is at journal_stop+0x91/0x1b8 ... recent reiserfs bugs http://bugzilla.kernel.org/show_bug.cgi?id=9108 Kernel: 2.6.23-rc8-git2 (opened by Randy Dunlap) MEMORY MANAGEMENT== Dysfunctional applications consume all the system memory, system freezes. http://bugzilla.kernel.org/show_bug.cgi?id=9202 Kernel: 2.6.22+ ACPI== ACPI several problems on ACER 5050-4697 http://bugzilla.kernel.org/show_bug.cgi?id=9175 Kernel: 2.6.22 ACER aspire 5050-4872 (AMD64 laptop) kernel acpi reads wrong temperature - critical shutdown http://bugzilla.kernel.org/show_bug.cgi?id=9041 Kernel: 2.6.18+ (Reporter asked to test with recent kernel) NETWORKING=== (net forcedeth) frequent network ups and downs http://bugzilla.kernel.org/show_bug.cgi?id=9200 Kernel: 2.6.23 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) rtl8187 very unreliable (wireless) http://bugzilla.kernel.org/show_bug.cgi?id=9143 Kernel: 2.6.23 John Linville started looking in it Unable to associate rt25xx USB key with a WPA AP (wireless) http://bugzilla.kernel.org/show_bug.cgi?id=9388 Kernel: 2.6.24-rc2 D-Link DWL-G122 Wifi 11b/g USB key USB=== usb 1-2: clear tt 2 (90b1) error -32 http://bugzilla.kernel.org/show_bug.cgi?id=9199 Kernel: 2.6.23 usblp0: USB Bidirectional printer dev 11 if 0 alt 1 proto 2 vid 0x03F0 pid 0x0417 David Brownell started looking in it BUG on USB disconnect http://bugzilla.kernel.org/show_bug.cgi?id=9196 Kernel: 2.6.23 IBM TP42p. Connected (through dock) are USB mouse and Plantronics 400 headset usb_id: segfault and abnormal exit msgs upon boot http://bugzilla.kernel.org/show_bug.cgi?id=9176 Kernel: 2.6.23 Athlon XP 2.4+, VT82C686 UHCI USB 1.1 Controller Entire system freezes randomly with USB modem in full swing http://bugzilla.kernel.org/show_bug.cgi?id=9154 Kernel: 2.6.23 HUAWEI E220 USB modem sysfs latency_timer for FT232RL chip http://bugzilla.kernel.org/show_bug.cgi?id=9120 Kernel: 2.6.22.9 FTDI FT232RL based dongle for serial communication VT6212L fails with Empia EM2820 on MIPS http://bugzilla.kernel.org/show_bug.cgi?id=9114 Kernel: 2.6.22 Asus WL-500g Premium Broadcom BCM3302 V0.6 32MB RAM USB host: VIA VT6212L Video grabber: Empia EM2820 with SAA7113H PROBLEM: kernel hang in ohci init (pci-quirks) http://bugzilla.kernel.org/show_bug.cgi?id=9026 Kernel: 2.6.22 Regression nvidia MCP51-Chipset (David Brownell started looking at it) Syslog flooded with hci_scodata_packet: hci0 SCO packet for unknown connection handle 92 message http://bugzilla.kernel.org/show_bug.cgi?id=9027 Kernel: 2.6.22 usb bluetooth dongle usb/serial/pl2303: support for BenQ Siemens Mobile Phone S81 http://bugzilla.kernel.org/show_bug.cgi?id=9065 Kernel: 2.6.22 I/O STORAGE== [pata_via probe]: CD-Rom devices are being recognized as DISKs when using pata driver http://bugzilla.kernel.org/show_bug.cgi?id=9178 Kernel: 2.6.23 chipset VIA VT8633 [Apollo Pro266] IDE: VIA VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06 __bread and 2TiB problem http://bugzilla.kernel.org/show_bug.cgi?id=9171 Kernel: 2.6.22 floppy device fails; floppy unexpected interrupt' and 'floppy timeout called' http://bugzilla.kernel.org/show_bug.cgi?id=9119 Kernel: 2.6.22.9 Regression (Ingo is looking at it?) Strange
ATA ACPI needs Mr interpreter, would you please shut up? flag
Hello, all. During 2.6.24-rc1, libata enabled ATA-ACPI support by default and there have been a lot of regression reports stemming from it. I have patchset ready to fix most of the problems. With these patches applied, libata should be able to cope with most failures pretty well. There is one remaining issue tho. libata caches the result of _GTM during controller for later use. The primary use is to peek at how BIOS configured the controller. Some controllers (pata_via and pata_amd) lack proper cable detection and BIOS configured values are used as reference. This caching is done before any other operation is performed on the port to avoid caching corrupted data. Problem is that _GTM implementation on certain BIOSen crap themselves if invoked on empty channels. However, as written above, because initial _GTM caching is done before any actual operation is performed on the port, libata can't determine whether the port is occupied or not when trying to cache _GTM result. Unfortunately, VIA PATA is on both categories - it needs _GTM caching but can't cope with _GTM invocation on empty ports. Yay! libata doesn't need _GTM to succeed. If the information can be acquired, it will use it. If not, it will do just fine without it and for pata_via, this works perfectly well because the information is available when actually needed (device present). The only problem is that _GTM evaluation failure will print ugly messages during boot. We can twist ATA probing such that _GTM caching is done between device detection but before mode is reset to PIO0 but I don't think that's a good idea for two reasons. 1. That would require pushing PIO0 enforcement after reset. IMHO, it's wiser to put controller into PIO0 before initiating reset. 2. Presence detection sometimes requires actually issuing IDENTIFY DEVICE command which in turn needs PIO0 configuration. So, I think the logical solution here is to tell ACPI interpreter that the _GTM evaluation may fail and there's no need to alert the user about that. Maybe printing with KERN_DEBUG is good enough. libata can print additional message after failure (again w/ KERN_DEBUG) telling the user that there's nothing to worry about. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATA ACPI needs Mr interpreter, would you please shut up? flag
Tejun Heo wrote: Hello, all. During 2.6.24-rc1, libata enabled ATA-ACPI support by default and there have been a lot of regression reports stemming from it. I have patchset ready to fix most of the problems. With these patches applied, libata should be able to cope with most failures pretty well. There is one remaining issue tho. libata caches the result of _GTM during controller for later use. The primary use is to peek at how BIOS configured the controller. Some controllers (pata_via and pata_amd) lack proper cable detection and BIOS configured values are used as reference. This caching is done before any other operation is performed on the port to avoid caching corrupted data. Problem is that _GTM implementation on certain BIOSen crap themselves if invoked on empty channels. However, as written above, because initial _GTM caching is done before any actual operation is performed on the port, libata can't determine whether the port is occupied or not when trying to cache _GTM result. Unfortunately, VIA PATA is on both categories - it needs _GTM caching but can't cope with _GTM invocation on empty ports. Yay! I seem to have lost the thread/bug report where we decided that one board always choked on an empty channel. Maybe it's not that and it's just another case of the same issue where our resetting default timing values on the controller before calling _GTM would choke the _GTM method? -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: 2.6.24-rc5-mm1 - pci-disable-decoding-during-sizing-of-bars.patch -- list_add corruption. prev-next should be next (dfe221f0), but was dfe22100. (prev=dfe221f0).
On Fri, 14 Dec 2007 01:00:19 -0500 Miles Lane [EMAIL PROTECTED] wrote: I first hit this BUG with straight 2.6.24-rc5-mm1, and then reproduced it with the pci-disable-decoding-during-sizing-of-bars patch removed. hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x00bf000c lp: driver loaded but no devices found Adding 570268k swap on /dev/sda5. Priority:-1 extents:1 across:570268k EXT3 FS on sda3, internal journal list_add corruption. prev-next should be next (dfe221f0), but was dfe22100. (prev=dfe221f0). BUG: using smp_processor_id() in preemptible [0001] code: modprobe/3107 caller is die+0x5d/0x1db Pid: 3107, comm: modprobe Not tainted 2.6.24-rc5-mm1 #24 [c0108eb2] show_trace_log_lvl+0x12/0x25 [c0109659] show_trace+0xd/0x10 [c0109981] dump_stack+0x57/0x5f [c02017f5] debug_smp_processor_id+0x99/0xb0 [c0109174] die+0x5d/0x1db [c03cdf38] do_trap+0x8a/0xa3 [c0109509] do_invalid_op+0x6c/0x76 [c03cdd02] error_code+0x72/0x78 [f8a446c7] acpi_video_bus_add+0x85b/0xbf4 [video] [c023b3cf] acpi_device_probe+0x3e/0xdb [c02725cd] driver_probe_device+0xaf/0x12a [c0272760] __driver_attach+0x6c/0xa5 [c0271b27] bus_for_each_dev+0x3e/0x60 [c0272455] driver_attach+0x14/0x16 [c0272279] bus_add_driver+0xa9/0x1b0 [c0272957] driver_register+0x47/0xa3 [c023b748] acpi_bus_register_driver+0x3a/0x3c [f8a1d032] acpi_video_init+0x32/0x51 [video] [c014eafb] sys_init_module+0x142b/0x14f4 [c0107cea] sysenter_past_esp+0x6b/0xc1 The above is a silly debugging thing - it's a missed raw_smp_processor_id(). Fix appended. === [ cut here ] kernel BUG at lib/list_debug.c:33! invalid opcode: [#1] PREEMPT SMP last sysfs file: /sys/class/vc/vcsa6/dev Modules linked in: video backlight output dm_crypt sbp2 parport_pc lp parport arc4 ecb crypto_blkcipher cryptomgr snd_hda_intel crypto_algapi snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss pcmcia snd_seq_midi snd_rawmidi iwl3945 snd_seq_midi_event snd_seq sky2 mac80211 tifm_7xx1 snd_timer snd_seq_device tifm_core cfg80211 iTCO_wdt iTCO_vendor_support yenta_socket rsrc_nonstatic pcmcia_core snd watchdog_core soundcore watchdog_dev shpchp pci_hotplug snd_page_alloc ata_generic firewire_ohci piix firewire_core crc_itu_t ide_core Pid: 3107, comm: modprobe Not tainted (2.6.24-rc5-mm1 #24) BUG: using smp_processor_id() in preemptible [0001] code: modprobe/3107 caller is __show_registers+0x8d/0x1af Pid: 3107, comm: modprobe Not tainted 2.6.24-rc5-mm1 #24 [c0108eb2] show_trace_log_lvl+0x12/0x25 [c0109659] show_trace+0xd/0x10 [c0109981] dump_stack+0x57/0x5f [c02017f5] debug_smp_processor_id+0x99/0xb0 [c0106358] __show_registers+0x8d/0x1af [c0108f73] show_registers+0x19/0x1bd [c010922e] die+0x117/0x1db [c03cdf38] do_trap+0x8a/0xa3 [c0109509] do_invalid_op+0x6c/0x76 [c03cdd02] error_code+0x72/0x78 [f8a446c7] acpi_video_bus_add+0x85b/0xbf4 [video] [c023b3cf] acpi_device_probe+0x3e/0xdb [c02725cd] driver_probe_device+0xaf/0x12a [c0272760] __driver_attach+0x6c/0xa5 [c0271b27] bus_for_each_dev+0x3e/0x60 [c0272455] driver_attach+0x14/0x16 [c0272279] bus_add_driver+0xa9/0x1b0 [c0272957] driver_register+0x47/0xa3 [c023b748] acpi_bus_register_driver+0x3a/0x3c [f8a1d032] acpi_video_init+0x32/0x51 [video] [c014eafb] sys_init_module+0x142b/0x14f4 [c0107cea] sysenter_past_esp+0x6b/0xc1 === EIP: 0060:[c0201893] EFLAGS: 00010246 CPU: 0 EIP is at __list_add+0x34/0x4a Well, that's a list_head handling bug in drivers/acpi/video.c. list_add_tail(data-entry, video-video_device_list); went bad.. From: Andrew Morton [EMAIL PROTECTED] We missed one: BUG: using smp_processor_id() in preemptible [0001] code: modprobe/3107 caller is die+0x5d/0x1db Pid: 3107, comm: modprobe Not tainted 2.6.24-rc5-mm1 #24 [c0108eb2] show_trace_log_lvl+0x12/0x25 [c0109659] show_trace+0xd/0x10 [c0109981] dump_stack+0x57/0x5f [c02017f5] debug_smp_processor_id+0x99/0xb0 [c0109174] die+0x5d/0x1db [c03cdf38] do_trap+0x8a/0xa3 [c0109509] do_invalid_op+0x6c/0x76 [c03cdd02] error_code+0x72/0x78 [f8a446c7] acpi_video_bus_add+0x85b/0xbf4 [video] [c023b3cf] acpi_device_probe+0x3e/0xdb Convert the other debugging smp_processor_id() calls in there too - perhaps they are also callable under conditions where preemption is thought to be enabled. Miles Lane [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Cc: Thomas Gleixner [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- arch/x86/kernel/traps_32.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff -puN arch/x86/kernel/traps_32.c~a arch/x86/kernel/traps_32.c --- a/arch/x86/kernel/traps_32.c~a +++ a/arch/x86/kernel/traps_32.c @@ -375,7 +375,7 @@ void die(const char * str, struct pt_reg console_verbose(); __raw_spin_lock(die.lock);
Re: ACPI related Warning in 2.6.24-rc3-git2
On Thu, Dec 13, 2007 at 09:41:23PM -0500, Len Brown wrote: I've udpated the BIOS on my T61 to 1.26 to match yours, but running 2.6.24-rc5 I don't see the issue you reported. If it still fails for you, please send me your .config It has been fixed in -rc4 I guess. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATA ACPI needs Mr interpreter, would you please shut up? flag
Robert Hancock wrote: Problem is that _GTM implementation on certain BIOSen crap themselves if invoked on empty channels. However, as written above, because initial _GTM caching is done before any actual operation is performed on the port, libata can't determine whether the port is occupied or not when trying to cache _GTM result. Unfortunately, VIA PATA is on both categories - it needs _GTM caching but can't cope with _GTM invocation on empty ports. Yay! I seem to have lost the thread/bug report where we decided that one board always choked on an empty channel. Maybe it's not that and it's just another case of the same issue where our resetting default timing values on the controller before calling _GTM would choke the _GTM method? Could be. Hans' machine on bug 9320 is the affected one (PATA on via CN700). I asked him to test the final version. If it indeed is caused by the same problem, there won't be evaluation failures. Anyways, table-based implementations like the NVidia and VIA ones are bound to fail on certain conditions. libata reconfigures transfer mode aggressively under certain failure conditions and _GTM invocation will fail if the port is in a mode which is not on ACPI's mode table (which doesn't seem to be too comprehensive anyway). So, there's always possibility of _GTM failure for those boards, which in turn can fail _GTF evaluation. As _GTM, _STM and _GTF aren't strictly necessary for operation anyway, I think it's better to print ATA ACPI evaluation failure messages using KERN_DEBUG. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] ACPI patches for 2.6.24-rc5
On Fri, 14 Dec 2007 01:26:11 -0500 Len Brown [EMAIL PROTECTED] wrote: please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release This will update the files shown below. thanks! -Len ps. individual patches are available on linux-acpi@vger.kernel.org and a consolidated plain patch is available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.24/acpi-release-20070126-2.6.24-rc5.diff.gz drivers/acpi/battery.c |2 +- drivers/acpi/numa.c |4 ++-- drivers/acpi/video.c |4 ++-- drivers/misc/thinkpad_acpi.c |4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) What's happening with Alexey's sbs regression fixes? - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
