2.6.32-stable patches

added patches:
	documentation-update-stable-address.patch
	firmware-fix-an-oops-on-reading-fw_priv-fw-in-sysfs-loading-file.patch
	offb-fix-bug-in-calculating-requested-vram-size.patch
	offb-fix-setting-of-the-pseudo-palette-for-8bpp.patch

5 files changed, 251 insertions, 0 deletions

diff --git a/queue-2.6.32/documentation-update-stable-address.patch b/queue-2.6.32/documentation-update-stable-address.patch
new file mode 100644
index 0000000..f4ec06a
--- /dev/null
+++ b/queue-2.6.32/documentation-update-stable-address.patch
@@ -0,0 +1,52 @@
+From 2eb7f204db51969ea558802a6601d79c2fb273b9 Mon Sep 17 00:00:00 2001
+From: Joe Perches <joe@perches.com>
+Date: Fri, 9 Dec 2011 14:12:00 -0800
+Subject: Documentation: Update stable address
+
+From: Joe Perches <joe@perches.com>
+
+commit 2eb7f204db51969ea558802a6601d79c2fb273b9 upstream.
+
+The Japanese/Korean/Chinese versions still need updating.
+
+Also, the stable kernel 2.6.x.y descriptions are out of date
+and should be updated as well.
+
+Signed-off-by: Joe Perches <joe@perches.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ Documentation/HOWTO                         |    4 ++--
+ Documentation/development-process/5.Posting |    8 ++++----
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+--- a/Documentation/HOWTO
++++ b/Documentation/HOWTO
+@@ -275,8 +275,8 @@ versions.
+ If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
+ kernel is the current stable kernel.
+ 
+-2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
+-released as needs dictate.  The normal release period is approximately 
++2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
++are released as needs dictate.  The normal release period is approximately
+ two weeks, but it can be longer if there are no pressing problems.  A
+ security-related problem, instead, can cause a release to happen almost
+ instantly.
+--- a/Documentation/development-process/5.Posting
++++ b/Documentation/development-process/5.Posting
+@@ -267,10 +267,10 @@ copies should go to:
+    the linux-kernel list.
+ 
+  - If you are fixing a bug, think about whether the fix should go into the
+-   next stable update.  If so, stable@kernel.org should get a copy of the
+-   patch.  Also add a "Cc: stable@kernel.org" to the tags within the patch
+-   itself; that will cause the stable team to get a notification when your
+-   fix goes into the mainline.
++   next stable update.  If so, stable@vger.kernel.org should get a copy of
++   the patch.  Also add a "Cc: stable@vger.kernel.org" to the tags within
++   the patch itself; that will cause the stable team to get a notification
++   when your fix goes into the mainline.
+ 
+ When selecting recipients for a patch, it is good to have an idea of who
+ you think will eventually accept the patch and get it merged.  While it
diff --git a/queue-2.6.32/firmware-fix-an-oops-on-reading-fw_priv-fw-in-sysfs-loading-file.patch b/queue-2.6.32/firmware-fix-an-oops-on-reading-fw_priv-fw-in-sysfs-loading-file.patch
new file mode 100644
index 0000000..085ca3a
--- /dev/null
+++ b/queue-2.6.32/firmware-fix-an-oops-on-reading-fw_priv-fw-in-sysfs-loading-file.patch
@@ -0,0 +1,78 @@
+From eea915bb0d1358755f151eaefb8208a2d5f3e10c Mon Sep 17 00:00:00 2001
+From: Neil Horman <nhorman@tuxdriver.com>
+Date: Mon, 2 Jan 2012 15:31:23 -0500
+Subject: firmware: Fix an oops on reading fw_priv->fw in sysfs loading file
+
+From: Neil Horman <nhorman@tuxdriver.com>
+
+commit eea915bb0d1358755f151eaefb8208a2d5f3e10c upstream.
+
+This oops was reported recently:
+firmware_loading_store+0xf9/0x17b
+dev_attr_store+0x20/0x22
+sysfs_write_file+0x101/0x134
+vfs_write+0xac/0xf3
+sys_write+0x4a/0x6e
+system_call_fastpath+0x16/0x1b
+
+The complete backtrace was unfortunately not captured, but details can be found
+here:
+https://bugzilla.redhat.com/show_bug.cgi?id=769920
+
+The cause is fairly clear.
+
+Its caused by the fact that firmware_loading_store has a case 0 in its
+switch statement that reads and writes the fw_priv->fw poniter without the
+protection of the fw_lock mutex.  since there is a window between the time that
+_request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs
+file is unregistered, its possible for a user space application to race in, and
+write a zero to the loading file, causing a NULL dereference in
+firmware_loading_store.  Fix it by extending the protection of the fw_lock mutex
+to cover all of the firware_loading_store function.
+
+Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/base/firmware_class.c |   14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/drivers/base/firmware_class.c
++++ b/drivers/base/firmware_class.c
+@@ -161,13 +161,13 @@ static ssize_t firmware_loading_store(st
+ 	int loading = simple_strtol(buf, NULL, 10);
+ 	int i;
+ 
++	mutex_lock(&fw_lock);
++
++	if (!fw_priv->fw)
++		goto out;
++
+ 	switch (loading) {
+ 	case 1:
+-		mutex_lock(&fw_lock);
+-		if (!fw_priv->fw) {
+-			mutex_unlock(&fw_lock);
+-			break;
+-		}
+ 		firmware_free_data(fw_priv->fw);
+ 		memset(fw_priv->fw, 0, sizeof(struct firmware));
+ 		/* If the pages are not owned by 'struct firmware' */
+@@ -178,7 +178,6 @@ static ssize_t firmware_loading_store(st
+ 		fw_priv->page_array_size = 0;
+ 		fw_priv->nr_pages = 0;
+ 		set_bit(FW_STATUS_LOADING, &fw_priv->status);
+-		mutex_unlock(&fw_lock);
+ 		break;
+ 	case 0:
+ 		if (test_bit(FW_STATUS_LOADING, &fw_priv->status)) {
+@@ -209,7 +208,8 @@ static ssize_t firmware_loading_store(st
+ 		fw_load_abort(fw_priv);
+ 		break;
+ 	}
+-
++out:
++	mutex_unlock(&fw_lock);
+ 	return count;
+ }
+ 
diff --git a/queue-2.6.32/offb-fix-bug-in-calculating-requested-vram-size.patch b/queue-2.6.32/offb-fix-bug-in-calculating-requested-vram-size.patch
new file mode 100644
index 0000000..9a2f9d3
--- /dev/null
+++ b/queue-2.6.32/offb-fix-bug-in-calculating-requested-vram-size.patch
@@ -0,0 +1,30 @@
+From c055fe0797b7bd8f6f21a13598a55a16d5c13ae7 Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Tue, 3 Jan 2012 12:09:15 +1100
+Subject: offb: Fix bug in calculating requested vram size
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+commit c055fe0797b7bd8f6f21a13598a55a16d5c13ae7 upstream.
+
+We used to try to request 8 times more vram than needed, which would
+fail if the card has a too small BAR (observed with qemu & kvm).
+
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/video/offb.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/video/offb.c
++++ b/drivers/video/offb.c
+@@ -377,7 +377,7 @@ static void __init offb_init_fb(const ch
+ 				int pitch, unsigned long address,
+ 				int foreign_endian, struct device_node *dp)
+ {
+-	unsigned long res_size = pitch * height * (depth + 7) / 8;
++	unsigned long res_size = pitch * height;
+ 	struct offb_par *par = &default_par;
+ 	unsigned long res_start = address;
+ 	struct fb_fix_screeninfo *fix;
diff --git a/queue-2.6.32/offb-fix-setting-of-the-pseudo-palette-for-8bpp.patch b/queue-2.6.32/offb-fix-setting-of-the-pseudo-palette-for-8bpp.patch
new file mode 100644
index 0000000..8f8748e
--- /dev/null
+++ b/queue-2.6.32/offb-fix-setting-of-the-pseudo-palette-for-8bpp.patch
@@ -0,0 +1,87 @@
+From 1bb0b7d21584b3f878e2bc880db62351ddee5185 Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Wed, 28 Dec 2011 00:10:16 +0000
+Subject: offb: Fix setting of the pseudo-palette for >8bpp
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+commit 1bb0b7d21584b3f878e2bc880db62351ddee5185 upstream.
+
+When using a >8bpp framebuffer, offb advertises truecolor, not directcolor,
+and doesn't touch the color map even if it has a corresponding access method
+for the real hardware.
+
+Thus it needs to set the pseudo-palette with all 3 components of the color,
+like other truecolor framebuffers, not with copies of the color index like
+a directcolor framebuffer would do.
+
+This went unnoticed for a long time because it's pretty hard to get offb
+to kick in with anything but 8bpp (old BootX under MacOS will do that and
+qemu does it).
+
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/video/offb.c |   44 ++++++++++++++++++++------------------------
+ 1 file changed, 20 insertions(+), 24 deletions(-)
+
+--- a/drivers/video/offb.c
++++ b/drivers/video/offb.c
+@@ -100,36 +100,32 @@ static int offb_setcolreg(u_int regno, u
+ 			  u_int transp, struct fb_info *info)
+ {
+ 	struct offb_par *par = (struct offb_par *) info->par;
+-	int i, depth;
+-	u32 *pal = info->pseudo_palette;
+ 
+-	depth = info->var.bits_per_pixel;
+-	if (depth == 16)
+-		depth = (info->var.green.length == 5) ? 15 : 16;
++	if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
++		u32 *pal = info->pseudo_palette;
++		u32 cr = red >> (16 - info->var.red.length);
++		u32 cg = green >> (16 - info->var.green.length);
++		u32 cb = blue >> (16 - info->var.blue.length);
++		u32 value;
+ 
+-	if (regno > 255 ||
+-	    (depth == 16 && regno > 63) ||
+-	    (depth == 15 && regno > 31))
+-		return 1;
++		if (regno >= 16)
++			return -EINVAL;
+ 
+-	if (regno < 16) {
+-		switch (depth) {
+-		case 15:
+-			pal[regno] = (regno << 10) | (regno << 5) | regno;
+-			break;
+-		case 16:
+-			pal[regno] = (regno << 11) | (regno << 5) | regno;
+-			break;
+-		case 24:
+-			pal[regno] = (regno << 16) | (regno << 8) | regno;
+-			break;
+-		case 32:
+-			i = (regno << 8) | regno;
+-			pal[regno] = (i << 16) | i;
+-			break;
++		value = (cr << info->var.red.offset) |
++			(cg << info->var.green.offset) |
++			(cb << info->var.blue.offset);
++		if (info->var.transp.length > 0) {
++			u32 mask = (1 << info->var.transp.length) - 1;
++			mask <<= info->var.transp.offset;
++			value |= mask;
+ 		}
++		pal[regno] = value;
++		return 0;
+ 	}
+ 
++	if (regno > 255)
++		return -EINVAL;
++
+ 	red >>= 8;
+ 	green >>= 8;
+ 	blue >>= 8;
diff --git a/queue-2.6.32/series b/queue-2.6.32/series
index 26643c8..f85d830 100644
--- a/queue-2.6.32/series
+++ b/queue-2.6.32/series
@@ -1 +1,5 @@
 maintainers-stable-update-address.patch
+documentation-update-stable-address.patch
+firmware-fix-an-oops-on-reading-fw_priv-fw-in-sysfs-loading-file.patch
+offb-fix-setting-of-the-pseudo-palette-for-8bpp.patch
+offb-fix-bug-in-calculating-requested-vram-size.patch