rpms/kernel/devel TODO, 1.37, 1.38 linux-2.6-acpi-clear-wake-status.patch, 1.1, 1.2 linux-2.6-acpi-ignore-reset_reg_sup.patch, 1.1, 1.2 linux-2.6-input-dell-keyboard-keyup.patch, 1.1, 1.2

Thu Oct 30 20:36:23 UTC 2008

Author: cebbert

Update of /cvs/pkgs/rpms/kernel/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31799

Modified Files:
	TODO linux-2.6-acpi-clear-wake-status.patch 
	linux-2.6-acpi-ignore-reset_reg_sup.patch 
	linux-2.6-input-dell-keyboard-keyup.patch 
Log Message:
more upstream patches


Index: TODO
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/TODO,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38

--- TODO	30 Oct 2008 19:58:56 -0000	1.37
+++ TODO	30 Oct 2008 20:35:51 -0000	1.38
@@ -14,13 +14,14 @@
 
 linux-2.6-acpi-clear-wake-status.patch
 linux-2.6-input-dell-keyboard-keyup.patch
+	Upstream in 2.6.28-rc, should go to -stable
+
 linux-2.6-eeepc-laptop-update.patch
-	mjg59 ACPI/laptop bits.
-	Upstreamable for 2.6.28 ?
+	Upstream but slightly different (commit a195dcdc)
 
 linux-2.6-acpi-ignore-reset_reg_sup.patch
 	Fixes reboot after suspend/resume (https://bugzilla.redhat.com/show_bug.cgi?id=461228)
-	Upstream in .28rc1
+	Upstream in .28rc1, should go to stable
 
 linux-2.6-at76.patch
 linux-2.6-iwlwifi-use-dma_alloc_coherent.patch
@@ -183,7 +184,7 @@
 	The drm patch should be fixed up to not conflict with the upstream patch.
 
 linux-2.6-libata-pata_it821x-fix-lba48-on-raid-volumes.patch
-	should be sent for -stable
+	upstream, should be sent for -stable
 
 linux-2.6-usb-storage-unusual-devs-jmicron-ata-bridge.patch
 	sent for stable

linux-2.6-acpi-clear-wake-status.patch:

Index: linux-2.6-acpi-clear-wake-status.patch
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/linux-2.6-acpi-clear-wake-status.patch,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- linux-2.6-acpi-clear-wake-status.patch	6 Aug 2008 18:21:53 -0000	1.1
+++ linux-2.6-acpi-clear-wake-status.patch	30 Oct 2008 20:35:51 -0000	1.2
@@ -1,3 +1,27 @@
+From: Matthew Garrett <mjg59 at srcf.ucam.org>
+Date: Wed, 6 Aug 2008 18:12:04 +0000 (+0100)
+Subject: ACPI: Clear WAK_STS on resume
+X-Git-Tag: v2.6.28-rc1~26^2~12^2~4
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=a68823ee5285e65b51ceb96f8b13a5b4f99a6888
+
+ACPI: Clear WAK_STS on resume
+
+The leading other brand OS appears to clear the WAK_STS flag on resume.
+When rebooted, certain BIOSes assume that the system is actually
+resuming if it's still set and so fail to reboot correctly. Make sure
+that it's cleared at resume time.
+
+Comment clarified as suggested by Bob Moore
+
+http://bugzilla.kernel.org/show_bug.cgi?id=11634
+
+Signed-off-by: Matthew Garrett <mjg at redhat.com>
+Signed-off-by: Andi Kleen <ak at linux.intel.com>
+Tested-by: Christian Borntraeger <borntraeger at de.ibm.com>
+Tested-by: Romano Giannetti <romano.giannetti at gmail.com>
+Signed-off-by: Len Brown <len.brown at intel.com>
+---
+
 diff --git a/drivers/acpi/hardware/hwsleep.c b/drivers/acpi/hardware/hwsleep.c
 index dba3cfb..130a44b 100644
 --- a/drivers/acpi/hardware/hwsleep.c

linux-2.6-acpi-ignore-reset_reg_sup.patch:

Index: linux-2.6-acpi-ignore-reset_reg_sup.patch
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/linux-2.6-acpi-ignore-reset_reg_sup.patch,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- linux-2.6-acpi-ignore-reset_reg_sup.patch	27 Oct 2008 16:36:10 -0000	1.1
+++ linux-2.6-acpi-ignore-reset_reg_sup.patch	30 Oct 2008 20:35:51 -0000	1.2
@@ -1,15 +1,26 @@
-Subject: ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
 From: Zhao Yakui <yakui.zhao at intel.com>
+Date: Fri, 17 Oct 2008 18:22:27 +0000 (-0400)
+Subject: ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
+X-Git-Tag: v2.6.28-rc1~26^2~22^2
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=8fd145917fb62368a9b80db59562c20576238f5a
+
+ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
+
+According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
+whether the ACPI reboot mechanism is supported.
+
+However, some boxes have this bit clear, have a valid
+ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
+mechanism that works for them after S3.
+
+This suggests that other operating systems may not be checking
+the RESET_REG_SUP bit, and are using other means to decide
+whether to use the ACPI reboot mechanism or not.
 
-       According to ACPI 3.0 spec the RESET_REG_SUP bit of FADT flag indicates
-whether the acpi reboot is supported. On some boxes this flag bit is zero. But
-there exists the definition of ACPI_RESET_REG & RESET_VALUE. And on such boxes
-the system can be rebooted only by using ACPI reboot after the cycle of
-suspend/resume.
-       So in such case it is unnecessary to check the flag bit any more. When 
-acpi reboot is expected, only the reset_register is checked. If the following
-conditions are meeted, it indicates that the reset register is supported.
-Otherwise it means that reset register is unsupported.
+Here we stop checking RESET_REG_SUP.
+Instead, When acpi reboot is requested,
+only the reset_register is checked. If the following
+conditions are met, it indicates that the reset register is supported.
 	a. reset_register is not zero
 	b. the access width is eight
 	c. the bit_offset is zero
@@ -18,15 +29,14 @@
 http://bugzilla.kernel.org/show_bug.cgi?id=1148
 
 Signed-off-by: Zhao Yakui <yakui.zhao at intel.com>
+Signed-off-by: Len Brown <len.brown at intel.com>
 ---
- drivers/acpi/reboot.c |   21 ++++++++++++++++++---
- 1 file changed, 18 insertions(+), 3 deletions(-)
 
-Index: linux-2.6/drivers/acpi/reboot.c
-===================================================================
---- linux-2.6.orig/drivers/acpi/reboot.c
-+++ linux-2.6/drivers/acpi/reboot.c
-@@ -15,9 +15,24 @@ void acpi_reboot(void)
+diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
+index a6b662c..755baf2 100644
+--- a/drivers/acpi/reboot.c
++++ b/drivers/acpi/reboot.c
+@@ -15,9 +15,28 @@ void acpi_reboot(void)
  
  	rr = &acpi_gbl_FADT.reset_register;
  
@@ -34,21 +44,25 @@
 -	if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) ||
 -	    rr->bit_width != 8 || rr->bit_offset != 0)
 +	/*
-+	 * Is the reset register supported?
-+	 * According to ACPI 3.0 spec the RESET_REG_SUP bit of FADT flag
-+	 * indicates whether the acpi reboot is supported. On some
-+	 * boxes this bit is zero. But there exists the definition of
-+	 * ACPI_RESET_REG & RESET_VALUE.
-+	 * And on such boxes the system can be rebooted only by using ACPI
-+	 * reboot after the cycle of suspend/resume.
-+	 * So in such case it is unnecessary to check the flag bit any more.
-+	 * When acpi reboot is expected, only the reset_register is checked.
-+	 * If the following conditions are meeted, it indicates that the reset
-+	 * register is supported. Otherwise it means that reset register is
-+	 * unsupported.
-+	 * a. reset_register is not zero
-+	 * b. the access width is eight
-+	 * c. the bit_offset is zero
++	 * Is the ACPI reset register supported?
++	 *
++	 * According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
++	 * whether the ACPI reset mechanism is supported.
++	 *
++	 * However, some boxes have this bit clear, yet a valid
++	 * ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
++	 * mechanism that works for them after S3.
++	 *
++	 * This suggests that other operating systems may not be checking
++	 * the RESET_REG_SUP bit, and are using other means to decide
++	 * whether to use the ACPI reboot mechanism or not.
++	 *
++	 * So when acpi reboot is requested,
++	 * only the reset_register is checked. If the following
++	 * conditions are met, it indicates that the reset register is supported.
++	 * 	a. reset_register is not zero
++	 * 	b. the access width is eight
++	 * 	c. the bit_offset is zero
 +	 */
 +	if (!(rr->address) || rr->bit_width != 8 || rr->bit_offset != 0)
  		return;

linux-2.6-input-dell-keyboard-keyup.patch:

Index: linux-2.6-input-dell-keyboard-keyup.patch
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/linux-2.6-input-dell-keyboard-keyup.patch,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- linux-2.6-input-dell-keyboard-keyup.patch	14 Aug 2008 14:07:14 -0000	1.1
+++ linux-2.6-input-dell-keyboard-keyup.patch	30 Oct 2008 20:35:51 -0000	1.2
@@ -1,5 +1,22 @@
+From: Matthew Garrett <mjg59 at srcf.ucam.org>
+Date: Fri, 15 Aug 2008 17:54:51 +0000 (-0400)
+Subject: Input: atkbd - expand Latitude's force release quirk to other Dells
+X-Git-Tag: v2.6.28-rc1~289^2^2~15
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=61579ba83934d397a4fa2bb7372de9ae112587d5
+
+Input: atkbd - expand Latitude's force release quirk to other Dells
+
+Dell laptops fail to send key up events for several of their special
+keys. There's an existing quirk in the kernel to handle this, but it's
+limited to the Latitude range. This patch extends it to cover all
+portable Dells.
+
+Signed-off-by: Matthew Garrett <mjg at redhat.com>
+Signed-off-by: Dmitry Torokhov <dtor at mail.ru>
+---
+
 diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
-index b1ce10f..e32c24d 100644
+index 4474572..22016ca 100644
 --- a/drivers/input/keyboard/atkbd.c
 +++ b/drivers/input/keyboard/atkbd.c
 @@ -834,10 +834,10 @@ static void atkbd_disconnect(struct serio *serio)
@@ -15,7 +32,7 @@
  {
  	const unsigned int forced_release_keys[] = {
  		0x85, 0x86, 0x87, 0x88, 0x89, 0x8a, 0x8b, 0x8f, 0x93,
-@@ -1461,13 +1461,13 @@ static int __init atkbd_setup_fixup(const struct dmi_system_id *id)
+@@ -1451,13 +1451,13 @@ static int __init atkbd_setup_fixup(const struct dmi_system_id *id)
  
  static struct dmi_system_id atkbd_dmi_quirk_table[] __initdata = {
  	{


