2 more .32 patches

diff --git a/queue-2.6.32/series b/queue-2.6.32/series
index 4bd412b19d4d396a3fd79a644d748180209ce30a..80ec4066d8764e8ec492280f37e8eb333d386c2d 100644 (file)
--- a/queue-2.6.32/series
+++ b/queue-2.6.32/series
@@ -21,3 +21,5 @@ drm-i915-read-the-response-after-issuing-ddc-bus-switch-command.patch
 drm-i915-try-another-possible-ddc-bus-for-the-sdvo-device-with-multiple-outputs.patch
 block-bdev_stack_limits-wrapper.patch
 dm-fix-device-mapper-topology-stacking.patch
+x86-pci-pat-return-einval-for-pci-mmap-wc-request-for-pat_enabled.patch
+usb-fix-usbstorage-for-2770-915d-delivers-no-fat.patch

diff --git a/queue-2.6.32/usb-fix-usbstorage-for-2770-915d-delivers-no-fat.patch b/queue-2.6.32/usb-fix-usbstorage-for-2770-915d-delivers-no-fat.patch
new file mode 100644 (file)
index 0000000..a40855f
--- /dev/null
+++ b/queue-2.6.32/usb-fix-usbstorage-for-2770-915d-delivers-no-fat.patch
@@ -0,0 +1,50 @@
+From 10d2cdb6102669279bee2d9a00a22431b74583d5 Mon Sep 17 00:00:00 2001
+From: Ryan May <rmay31@gmail.com>
+Date: Wed, 6 Jan 2010 10:09:25 -0600
+Subject: USB: fix usbstorage for 2770:915d delivers no FAT
+
+From: Ryan May <rmay31@gmail.com>
+
+commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.
+
+Resolves kernel.org bug 14914.
+
+Remove entry for 2770:915d (usb digital camera with mass storage
+support) from unusual_devs.h. The fix triggered by the entry causes
+the file system on the camera to be completely inaccessible (no
+partition table, the device is not mountable).
+
+The patch works, but let me clarify a few things about it.  All the
+patch does is remove the entry for this device from the
+drivers/usb/storage/unusual_devs.h, which is supposed to help with a
+problem with the device's reported size (I think).  I'm pretty sure it
+was originally added for a reason, so I'm not sure removing it won't
+cause other problems to reappear.  Also, I should note that this
+unusual_devs.h entry was present (and activating workarounds) in
+2.6.29, but in that version everything works fine.  Starting with
+2.6.30, things no longer work.
+
+Signed-off-by: Ryan May <rmay31@gmail.com>
+Cc: Rohan Hart <rohan.hart17@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/storage/unusual_devs.h |    7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/drivers/usb/storage/unusual_devs.h
++++ b/drivers/usb/storage/unusual_devs.h
+@@ -1807,13 +1807,6 @@ UNUSUAL_DEV(  0x2735, 0x100b, 0x0000, 0x
+               US_SC_DEVICE, US_PR_DEVICE, NULL,
+               US_FL_GO_SLOW ),
+ 
+-/* Reported by Rohan Hart <rohan.hart17@gmail.com> */
+-UNUSUAL_DEV(  0x2770, 0x915d, 0x0010, 0x0010,
+-              "INTOVA",
+-              "Pixtreme",
+-              US_SC_DEVICE, US_PR_DEVICE, NULL,
+-              US_FL_FIX_CAPACITY ),
+-
+ /* Reported by Frederic Marchal <frederic.marchal@wowcompany.com>
+  * Mio Moov 330
+  */

diff --git a/queue-2.6.32/x86-pci-pat-return-einval-for-pci-mmap-wc-request-for-pat_enabled.patch b/queue-2.6.32/x86-pci-pat-return-einval-for-pci-mmap-wc-request-for-pat_enabled.patch
new file mode 100644 (file)
index 0000000..3607fc9
--- /dev/null
+++ b/queue-2.6.32/x86-pci-pat-return-einval-for-pci-mmap-wc-request-for-pat_enabled.patch
@@ -0,0 +1,56 @@
+From 2992e545ea006992ec9dc91c4fa996ce1e15f921 Mon Sep 17 00:00:00 2001
+From: Suresh Siddha <suresh.b.siddha@intel.com>
+Date: Mon, 26 Oct 2009 13:21:32 -0800
+Subject: x86/PCI/PAT: return EINVAL for pci mmap WC request for !pat_enabled
+
+From: Suresh Siddha <suresh.b.siddha@intel.com>
+
+commit 2992e545ea006992ec9dc91c4fa996ce1e15f921 upstream.
+
+Thomas Schlichter reported:
+> X.org uses libpciaccess which tries to mmap with write combining enabled via
+> /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the
+> kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded
+> mapping with write combining enabled and does not set up suited MTRR entries.
+> ;-(
+
+Instead of silently mapping pci mmap region as UC minus in the case
+of !pat_enabled and wc request, we can return error. Eric Anholt mentioned
+that caller (like X) typically follows up with UC minus pci mmap request and
+if there is a free mtrr slot, caller will manage adding WC mtrr.
+
+Jesse Barnes says:
+> Older versions of libpciaccess will behave better if we do it that way
+> (iirc it only allocates an MTRR if the resource_wc file doesn't exist or
+> fails to get mapped).
+
+Reported-by: Thomas Schlichter <thomas.schlichter@web.de>
+Signed-off-by: Thomas Schlichter <thomas.schlichter@web.de>
+Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
+Acked-by: Eric Anholt <eric@anholt.net>
+Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/pci/i386.c |    9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/arch/x86/pci/i386.c
++++ b/arch/x86/pci/i386.c
+@@ -282,6 +282,15 @@ int pci_mmap_page_range(struct pci_dev *
+               return -EINVAL;
+ 
+       prot = pgprot_val(vma->vm_page_prot);
++
++      /*
++       * Return error if pat is not enabled and write_combine is requested.
++       * Caller can followup with UC MINUS request and add a WC mtrr if there
++       * is a free mtrr slot.
++       */
++      if (!pat_enabled && write_combine)
++              return -EINVAL;
++
+       if (pat_enabled && write_combine)
+               prot |= _PAGE_CACHE_WC;
+       else if (pat_enabled || boot_cpu_data.x86 > 3)