--- /dev/null
+From 6027277e77df2d2893d906c42f5c9f9abcb731e0 Mon Sep 17 00:00:00 2001
+From: Manoj Iyer <manoj.iyer@canonical.com>
+Date: Tue, 23 Nov 2010 07:43:44 +0100
+Subject: ALSA: hda - Enable jack sense for Thinkpad Edge 11
+
+From: Manoj Iyer <manoj.iyer@canonical.com>
+
+commit 6027277e77df2d2893d906c42f5c9f9abcb731e0 upstream.
+
+Add a quirk entry for Thinkpad Edge 11 as well as other TP Edge models.
+
+Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/pci/hda/patch_conexant.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_conexant.c
++++ b/sound/pci/hda/patch_conexant.c
+@@ -3099,6 +3099,7 @@ static struct snd_pci_quirk cxt5066_cfg_
+ SND_PCI_QUIRK(0x17aa, 0x21b2, "Thinkpad X100e", CXT5066_IDEAPAD),
+ SND_PCI_QUIRK(0x17aa, 0x21b3, "Thinkpad Edge 13 (197)", CXT5066_IDEAPAD),
+ SND_PCI_QUIRK(0x17aa, 0x21b4, "Thinkpad Edge", CXT5066_IDEAPAD),
++ SND_PCI_QUIRK(0x17aa, 0x21c8, "Thinkpad Edge 11", CXT5066_IDEAPAD),
+ SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo Thinkpad", CXT5066_THINKPAD),
+ SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo G series", CXT5066_IDEAPAD),
+ SND_PCI_QUIRK(0x17aa, 0x390a, "Lenovo S10-3t", CXT5066_IDEAPAD),
--- /dev/null
+From bc4cf2bb271b2d557fc510426755da786fc985be Mon Sep 17 00:00:00 2001
+From: Chris Metcalf <cmetcalf@tilera.com>
+Date: Tue, 14 Dec 2010 15:57:49 -0500
+Subject: arch/tile: handle CLONE_SETTLS in copy_thread(), not user space
+
+From: Chris Metcalf <cmetcalf@tilera.com>
+
+commit bc4cf2bb271b2d557fc510426755da786fc985be upstream.
+
+Previously we were just setting up the "tp" register in the
+new task as started by clone() in libc. However, this is not
+quite right, since in principle a signal might be delivered to
+the new task before it had its TLS set up. (Of course, this race
+window still exists for resetting the libc getpid() cached value
+in the new task, in principle. But in any case, we are now doing
+this exactly the way all other architectures do it.)
+
+This change is important for 2.6.37 since the tile glibc we will
+be submitting upstream will not set TLS in user space any more,
+so it will only work on a kernel that has this fix. It should
+also be taken for 2.6.36.x in the stable tree if possible.
+
+Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/tile/kernel/process.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/arch/tile/kernel/process.c
++++ b/arch/tile/kernel/process.c
+@@ -212,6 +212,13 @@ int copy_thread(unsigned long clone_flag
+ childregs->sp = sp; /* override with new user stack pointer */
+
+ /*
++ * If CLONE_SETTLS is set, set "tp" in the new task to "r4",
++ * which is passed in as arg #5 to sys_clone().
++ */
++ if (clone_flags & CLONE_SETTLS)
++ childregs->tp = regs->regs[4];
++
++ /*
+ * Copy the callee-saved registers from the passed pt_regs struct
+ * into the context-switch callee-saved registers area.
+ * We have to restore the callee-saved registers since we may
--- /dev/null
+From 3bfa321e662edf90fb8123a02c987c2965fa50bb Mon Sep 17 00:00:00 2001
+From: Yan Li <yan.i.li@intel.com>
+Date: Tue, 30 Nov 2010 23:51:03 -0800
+Subject: Input: synaptics - fix handling of 2-button ClickPads
+
+From: Yan Li <yan.i.li@intel.com>
+
+commit 3bfa321e662edf90fb8123a02c987c2965fa50bb upstream.
+
+Lenovo S10-3t's ClickPad is a 2-button ClickPad that reports BTN_LEFT
+and BTN_RIGHT as normal touchpad, unlike the 1-button ClickPad used in
+HP mini 210 that reports solely BTN_MIDDLE.
+
+In 0xc0-cap response, the 1-button ClickPad has the 20-bit set while
+2-button ClickPad has the 8-bit set.
+
+This patch makes the kernel only handle 1-button ClickPad specially,
+and treat 2-button ClickPad in the same fashion as regular touchpads.
+
+This fixes kernel bug #18122 and MeeGo bug #4807.
+
+Signed-off-by: Yan Li <yan.i.li@intel.com>
+Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/input/mouse/synaptics.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/input/mouse/synaptics.h
++++ b/drivers/input/mouse/synaptics.h
+@@ -51,7 +51,8 @@
+ #define SYN_EXT_CAP_REQUESTS(c) (((c) & 0x700000) >> 20)
+ #define SYN_CAP_MULTI_BUTTON_NO(ec) (((ec) & 0x00f000) >> 12)
+ #define SYN_CAP_PRODUCT_ID(ec) (((ec) & 0xff0000) >> 16)
+-#define SYN_CAP_CLICKPAD(ex0c) ((ex0c) & 0x100100)
++#define SYN_CAP_CLICKPAD(ex0c) ((ex0c) & 0x100000) /* 1-button ClickPad */
++#define SYN_CAP_CLICKPAD2BTN(ex0c) ((ex0c) & 0x000100) /* 2-button ClickPad */
+ #define SYN_CAP_MAX_DIMENSIONS(ex0c) ((ex0c) & 0x020000)
+
+ /* synaptics modes query bits */
--- /dev/null
+From 462e635e5b73ba9a4c03913b77138cd57ce4b050 Mon Sep 17 00:00:00 2001
+From: Tavis Ormandy <taviso@cmpxchg8b.com>
+Date: Thu, 9 Dec 2010 15:29:42 +0100
+Subject: install_special_mapping skips security_file_mmap check.
+
+From: Tavis Ormandy <taviso@cmpxchg8b.com>
+
+commit 462e635e5b73ba9a4c03913b77138cd57ce4b050 upstream.
+
+The install_special_mapping routine (used, for example, to setup the
+vdso) skips the security check before insert_vm_struct, allowing a local
+attacker to bypass the mmap_min_addr security restriction by limiting
+the available pages for special mappings.
+
+bprm_mm_init() also skips the check, and although I don't think this can
+be used to bypass any restrictions, I don't see any reason not to have
+the security check.
+
+ $ uname -m
+ x86_64
+ $ cat /proc/sys/vm/mmap_min_addr
+ 65536
+ $ cat install_special_mapping.s
+ section .bss
+ resb BSS_SIZE
+ section .text
+ global _start
+ _start:
+ mov eax, __NR_pause
+ int 0x80
+ $ nasm -D__NR_pause=29 -DBSS_SIZE=0xfffed000 -f elf -o install_special_mapping.o install_special_mapping.s
+ $ ld -m elf_i386 -Ttext=0x10000 -Tbss=0x11000 -o install_special_mapping install_special_mapping.o
+ $ ./install_special_mapping &
+ [1] 14303
+ $ cat /proc/14303/maps
+ 0000f000-00010000 r-xp 00000000 00:00 0 [vdso]
+ 00010000-00011000 r-xp 00001000 00:19 2453665 /home/taviso/install_special_mapping
+ 00011000-ffffe000 rwxp 00000000 00:00 0 [stack]
+
+It's worth noting that Red Hat are shipping with mmap_min_addr set to
+4096.
+
+Signed-off-by: Tavis Ormandy <taviso@google.com>
+Acked-by: Kees Cook <kees@ubuntu.com>
+Acked-by: Robert Swiecki <swiecki@google.com>
+[ Changed to not drop the error code - akpm ]
+Reviewed-by: James Morris <jmorris@namei.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/exec.c | 5 +++++
+ mm/mmap.c | 16 ++++++++++++----
+ 2 files changed, 17 insertions(+), 4 deletions(-)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -268,6 +268,11 @@ static int __bprm_mm_init(struct linux_b
+ vma->vm_flags = VM_STACK_FLAGS | VM_STACK_INCOMPLETE_SETUP;
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ INIT_LIST_HEAD(&vma->anon_vma_chain);
++
++ err = security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1);
++ if (err)
++ goto err;
++
+ err = insert_vm_struct(mm, vma);
+ if (err)
+ goto err;
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -2460,6 +2460,7 @@ int install_special_mapping(struct mm_st
+ unsigned long addr, unsigned long len,
+ unsigned long vm_flags, struct page **pages)
+ {
++ int ret;
+ struct vm_area_struct *vma;
+
+ vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
+@@ -2477,16 +2478,23 @@ int install_special_mapping(struct mm_st
+ vma->vm_ops = &special_mapping_vmops;
+ vma->vm_private_data = pages;
+
+- if (unlikely(insert_vm_struct(mm, vma))) {
+- kmem_cache_free(vm_area_cachep, vma);
+- return -ENOMEM;
+- }
++ ret = security_file_mmap(NULL, 0, 0, 0, vma->vm_start, 1);
++ if (ret)
++ goto out;
++
++ ret = insert_vm_struct(mm, vma);
++ if (ret)
++ goto out;
+
+ mm->total_vm += len >> PAGE_SHIFT;
+
+ perf_event_mmap(vma);
+
+ return 0;
++
++out:
++ kmem_cache_free(vm_area_cachep, vma);
++ return ret;
+ }
+
+ static DEFINE_MUTEX(mm_all_locks_mutex);
--- /dev/null
+From 1a855a0606653d2d82506281e2c686bacb4b2f45 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Thu, 9 Dec 2010 16:36:28 +1100
+Subject: md: fix bug with re-adding of partially recovered device.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 1a855a0606653d2d82506281e2c686bacb4b2f45 upstream.
+
+With v0.90 metadata, a hot-spare does not become a full member of the
+array until recovery is complete. So if we re-add such a device to
+the array, we know that all of it is as up-to-date as the event count
+would suggest, and so it a bitmap-based recovery is possible.
+
+However with v1.x metadata, the hot-spare immediately becomes a full
+member of the array, but it record how much of the device has been
+recovered. If the array is stopped and re-assembled recovery starts
+from this point.
+
+When such a device is hot-added to an array we currently lose the 'how
+much is recovered' information and incorrectly included it as a full
+in-sync member (after bitmap-based fixup).
+This is wrong and unsafe and could corrupt data.
+
+So be more careful about setting saved_raid_disk - which is what
+guides the re-adding of devices back into an array.
+The new code matches the code in slot_store which does a similar
+thing, which is encouraging.
+
+This is suitable for any -stable kernel.
+
+Reported-by: "Dailey, Nate" <Nate.Dailey@stratus.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/md/md.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -5150,7 +5150,7 @@ static int add_new_disk(mddev_t * mddev,
+ PTR_ERR(rdev));
+ return PTR_ERR(rdev);
+ }
+- /* set save_raid_disk if appropriate */
++ /* set saved_raid_disk if appropriate */
+ if (!mddev->persistent) {
+ if (info->state & (1<<MD_DISK_SYNC) &&
+ info->raid_disk < mddev->raid_disks)
+@@ -5160,7 +5160,10 @@ static int add_new_disk(mddev_t * mddev,
+ } else
+ super_types[mddev->major_version].
+ validate_super(mddev, rdev);
+- rdev->saved_raid_disk = rdev->raid_disk;
++ if (test_bit(In_sync, &rdev->flags))
++ rdev->saved_raid_disk = rdev->raid_disk;
++ else
++ rdev->saved_raid_disk = -1;
+
+ clear_bit(In_sync, &rdev->flags); /* just to be sure */
+ if (info->state & (1<<MD_DISK_WRITEMOSTLY))
--- /dev/null
+From 589a594be1fb8815b3f18e517be696c48664f728 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Thu, 9 Dec 2010 17:02:14 +1100
+Subject: md: protect against NULL reference when waiting to start a raid10.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 589a594be1fb8815b3f18e517be696c48664f728 upstream.
+
+When we fail to start a raid10 for some reason, we call
+md_unregister_thread to kill the thread that was created.
+
+Unfortunately md_thread() will then make one call into the handler
+(raid10d) even though md_wakeup_thread has not been called. This is
+not safe and as md_unregister_thread is called after mddev->private
+has been set to NULL, it will definitely cause a NULL dereference.
+
+So fix this at both ends:
+ - md_thread should only call the handler if THREAD_WAKEUP has been
+ set.
+ - raid10 should call md_unregister_thread before setting things
+ to NULL just like all the other raid modules do.
+
+This is applicable to 2.6.35 and later.
+
+Reported-by: "Citizen" <citizen_lee@thecus.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/md/md.c | 5 ++---
+ drivers/md/raid10.c | 2 +-
+ 2 files changed, 3 insertions(+), 4 deletions(-)
+
+--- a/drivers/md/md.c
++++ b/drivers/md/md.c
+@@ -6040,9 +6040,8 @@ static int md_thread(void * arg)
+ || kthread_should_stop(),
+ thread->timeout);
+
+- clear_bit(THREAD_WAKEUP, &thread->flags);
+-
+- thread->run(thread->mddev);
++ if (test_and_clear_bit(THREAD_WAKEUP, &thread->flags))
++ thread->run(thread->mddev);
+ }
+
+ return 0;
+--- a/drivers/md/raid10.c
++++ b/drivers/md/raid10.c
+@@ -2396,13 +2396,13 @@ static int run(mddev_t *mddev)
+ return 0;
+
+ out_free_conf:
++ md_unregister_thread(mddev->thread);
+ if (conf->r10bio_pool)
+ mempool_destroy(conf->r10bio_pool);
+ safe_put_page(conf->tmppage);
+ kfree(conf->mirrors);
+ kfree(conf);
+ mddev->private = NULL;
+- md_unregister_thread(mddev->thread);
+ out:
+ return -EIO;
+ }
--- /dev/null
+From ba34fcee476d11e7c9df95932787a22a96ff6e68 Mon Sep 17 00:00:00 2001
+From: David Kilroy <kilroyd@googlemail.com>
+Date: Sun, 5 Dec 2010 15:45:58 +0000
+Subject: orinoco: clear countermeasure setting on commit
+
+From: David Kilroy <kilroyd@googlemail.com>
+
+commit ba34fcee476d11e7c9df95932787a22a96ff6e68 upstream.
+
+... and interface up.
+
+In these situations, you are usually trying to connect to a new AP, so
+keeping TKIP countermeasures active is confusing. This is already how
+the driver behaves (inadvertently). However, querying SIOCGIWAUTH may
+tell userspace that countermeasures are active when they aren't.
+
+Clear the setting so that the reporting matches what the driver has
+done..
+
+Signed-off by: David Kilroy <kilroyd@googlemail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/orinoco/main.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/net/wireless/orinoco/main.c
++++ b/drivers/net/wireless/orinoco/main.c
+@@ -1813,6 +1813,12 @@ static int __orinoco_commit(struct orino
+ struct net_device *dev = priv->ndev;
+ int err = 0;
+
++ /* If we've called commit, we are reconfiguring or bringing the
++ * interface up. Maintaining countermeasures across this would
++ * be confusing, so note that we've disabled them. The port will
++ * be enabled later in orinoco_commit or __orinoco_up. */
++ priv->tkip_cm_active = 0;
++
+ err = orinoco_hw_program_rids(priv);
+
+ /* FIXME: what about netif_tx_lock */
--- /dev/null
+From 0a54917c3fc295cb61f3fb52373c173fd3b69f48 Mon Sep 17 00:00:00 2001
+From: David Kilroy <kilroyd@googlemail.com>
+Date: Sun, 5 Dec 2010 15:43:55 +0000
+Subject: orinoco: fix TKIP countermeasure behaviour
+
+From: David Kilroy <kilroyd@googlemail.com>
+
+commit 0a54917c3fc295cb61f3fb52373c173fd3b69f48 upstream.
+
+Enable the port when disabling countermeasures, and disable it on
+enabling countermeasures.
+
+This bug causes the response of the system to certain attacks to be
+ineffective.
+
+It also prevents wpa_supplicant from getting scan results, as
+wpa_supplicant disables countermeasures on startup - preventing the
+hardware from scanning.
+
+wpa_supplicant works with ap_mode=2 despite this bug because the commit
+handler re-enables the port.
+
+The log tends to look like:
+
+State: DISCONNECTED -> SCANNING
+Starting AP scan for wildcard SSID
+Scan requested (ret=0) - scan timeout 5 seconds
+EAPOL: disable timer tick
+EAPOL: Supplicant port status: Unauthorized
+Scan timeout - try to get results
+Failed to get scan results
+Failed to get scan results - try scanning again
+Setting scan request: 1 sec 0 usec
+Starting AP scan for wildcard SSID
+Scan requested (ret=-1) - scan timeout 5 seconds
+Failed to initiate AP scan.
+
+Reported by: Giacomo Comes <comes@naic.edu>
+Signed-off by: David Kilroy <kilroyd@googlemail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/orinoco/wext.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/wireless/orinoco/wext.c
++++ b/drivers/net/wireless/orinoco/wext.c
+@@ -904,10 +904,10 @@ static int orinoco_ioctl_set_auth(struct
+ */
+ if (param->value) {
+ priv->tkip_cm_active = 1;
+- ret = hermes_enable_port(hw, 0);
++ ret = hermes_disable_port(hw, 0);
+ } else {
+ priv->tkip_cm_active = 0;
+- ret = hermes_disable_port(hw, 0);
++ ret = hermes_enable_port(hw, 0);
+ }
+ break;
+
--- /dev/null
+From 8d1331b37d5b656a7a8e561f8e9d7661dd00c910 Mon Sep 17 00:00:00 2001
+From: Ivo van Doorn <ivdoorn@gmail.com>
+Date: Mon, 23 Aug 2010 19:56:07 +0200
+Subject: rt2x00: Fix max TX power settings
+
+From: Ivo van Doorn <ivdoorn@gmail.com>
+
+commit 8d1331b37d5b656a7a8e561f8e9d7661dd00c910 upstream.
+
+During initialization each driver reads the default TX power
+for each individual channel. However mac80211 only accepts the
+maximum value (which is also handled as default value).
+
+As a result, the TX power of the device was being limited to
+the default value, which is often quite low compared to the
+real maximum acceptable value.
+
+This patch allows each driver to set the maximum value on a
+per-channel basis which is forwarded to mac80211. The default
+value will be preserved for now, in case we want to update
+mac80211 to differentiate between the maximum and default txpower.
+
+This fixes bug complaining about limited TX power values like:
+https://bugzilla.kernel.org/show_bug.cgi?id=16358
+
+Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
+Acked-by: Helmut Schaa <helmut.schaa@googlemail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/net/wireless/rt2x00/rt2400pci.c | 6 ++-
+ drivers/net/wireless/rt2x00/rt2500pci.c | 12 ++++--
+ drivers/net/wireless/rt2x00/rt2500usb.c | 12 ++++--
+ drivers/net/wireless/rt2x00/rt2800.h | 7 +++
+ drivers/net/wireless/rt2x00/rt2800lib.c | 59 ++++++++++++++++++--------------
+ drivers/net/wireless/rt2x00/rt2x00.h | 5 +-
+ drivers/net/wireless/rt2x00/rt2x00dev.c | 2 -
+ drivers/net/wireless/rt2x00/rt61pci.c | 12 ++++--
+ drivers/net/wireless/rt2x00/rt73usb.c | 12 ++++--
+ 9 files changed, 82 insertions(+), 45 deletions(-)
+
+--- a/drivers/net/wireless/rt2x00/rt2400pci.c
++++ b/drivers/net/wireless/rt2x00/rt2400pci.c
+@@ -1488,8 +1488,10 @@ static int rt2400pci_probe_hw_mode(struc
+ spec->channels_info = info;
+
+ tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_START);
+- for (i = 0; i < 14; i++)
+- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ for (i = 0; i < 14; i++) {
++ info[i].max_power = TXPOWER_FROM_DEV(MAX_TXPOWER);
++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ }
+
+ return 0;
+ }
+--- a/drivers/net/wireless/rt2x00/rt2500pci.c
++++ b/drivers/net/wireless/rt2x00/rt2500pci.c
+@@ -1802,12 +1802,16 @@ static int rt2500pci_probe_hw_mode(struc
+ spec->channels_info = info;
+
+ tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_START);
+- for (i = 0; i < 14; i++)
+- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ for (i = 0; i < 14; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ }
+
+ if (spec->num_channels > 14) {
+- for (i = 14; i < spec->num_channels; i++)
+- info[i].tx_power1 = DEFAULT_TXPOWER;
++ for (i = 14; i < spec->num_channels; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = DEFAULT_TXPOWER;
++ }
+ }
+
+ return 0;
+--- a/drivers/net/wireless/rt2x00/rt2500usb.c
++++ b/drivers/net/wireless/rt2x00/rt2500usb.c
+@@ -1705,12 +1705,16 @@ static int rt2500usb_probe_hw_mode(struc
+ spec->channels_info = info;
+
+ tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_START);
+- for (i = 0; i < 14; i++)
+- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ for (i = 0; i < 14; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ }
+
+ if (spec->num_channels > 14) {
+- for (i = 14; i < spec->num_channels; i++)
+- info[i].tx_power1 = DEFAULT_TXPOWER;
++ for (i = 14; i < spec->num_channels; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = DEFAULT_TXPOWER;
++ }
+ }
+
+ return 0;
+--- a/drivers/net/wireless/rt2x00/rt2800.h
++++ b/drivers/net/wireless/rt2x00/rt2800.h
+@@ -1841,6 +1841,13 @@ struct mac_iveiv_entry {
+ #define EEPROM_RSSI_A2_LNA_A2 FIELD16(0xff00)
+
+ /*
++ * EEPROM Maximum TX power values
++ */
++#define EEPROM_MAX_TX_POWER 0x0027
++#define EEPROM_MAX_TX_POWER_24GHZ FIELD16(0x00ff)
++#define EEPROM_MAX_TX_POWER_5GHZ FIELD16(0xff00)
++
++/*
+ * EEPROM TXpower delta: 20MHZ AND 40 MHZ use different power.
+ * This is delta in 40MHZ.
+ * VALUE: Tx Power dalta value (MAX=4)
+--- a/drivers/net/wireless/rt2x00/rt2800lib.c
++++ b/drivers/net/wireless/rt2x00/rt2800lib.c
+@@ -1120,27 +1120,27 @@ static void rt2800_config_channel_rf2xxx
+ * double meaning, and we should set a 7DBm boost flag.
+ */
+ rt2x00_set_field32(&rf->rf3, RF3_TXPOWER_A_7DBM_BOOST,
+- (info->tx_power1 >= 0));
++ (info->default_power1 >= 0));
+
+- if (info->tx_power1 < 0)
+- info->tx_power1 += 7;
++ if (info->default_power1 < 0)
++ info->default_power1 += 7;
+
+ rt2x00_set_field32(&rf->rf3, RF3_TXPOWER_A,
+- TXPOWER_A_TO_DEV(info->tx_power1));
++ TXPOWER_A_TO_DEV(info->default_power1));
+
+ rt2x00_set_field32(&rf->rf4, RF4_TXPOWER_A_7DBM_BOOST,
+- (info->tx_power2 >= 0));
++ (info->default_power2 >= 0));
+
+- if (info->tx_power2 < 0)
+- info->tx_power2 += 7;
++ if (info->default_power2 < 0)
++ info->default_power2 += 7;
+
+ rt2x00_set_field32(&rf->rf4, RF4_TXPOWER_A,
+- TXPOWER_A_TO_DEV(info->tx_power2));
++ TXPOWER_A_TO_DEV(info->default_power2));
+ } else {
+ rt2x00_set_field32(&rf->rf3, RF3_TXPOWER_G,
+- TXPOWER_G_TO_DEV(info->tx_power1));
++ TXPOWER_G_TO_DEV(info->default_power1));
+ rt2x00_set_field32(&rf->rf4, RF4_TXPOWER_G,
+- TXPOWER_G_TO_DEV(info->tx_power2));
++ TXPOWER_G_TO_DEV(info->default_power2));
+ }
+
+ rt2x00_set_field32(&rf->rf4, RF4_HT40, conf_is_ht40(conf));
+@@ -1180,13 +1180,11 @@ static void rt2800_config_channel_rf3xxx
+ rt2800_rfcsr_write(rt2x00dev, 6, rfcsr);
+
+ rt2800_rfcsr_read(rt2x00dev, 12, &rfcsr);
+- rt2x00_set_field8(&rfcsr, RFCSR12_TX_POWER,
+- TXPOWER_G_TO_DEV(info->tx_power1));
++ rt2x00_set_field8(&rfcsr, RFCSR12_TX_POWER, info->default_power1);
+ rt2800_rfcsr_write(rt2x00dev, 12, rfcsr);
+
+ rt2800_rfcsr_read(rt2x00dev, 13, &rfcsr);
+- rt2x00_set_field8(&rfcsr, RFCSR13_TX_POWER,
+- TXPOWER_G_TO_DEV(info->tx_power2));
++ rt2x00_set_field8(&rfcsr, RFCSR13_TX_POWER, info->default_power2);
+ rt2800_rfcsr_write(rt2x00dev, 13, rfcsr);
+
+ rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr);
+@@ -2516,6 +2514,13 @@ int rt2800_validate_eeprom(struct rt2x00
+ default_lna_gain);
+ rt2x00_eeprom_write(rt2x00dev, EEPROM_RSSI_A2, word);
+
++ rt2x00_eeprom_read(rt2x00dev, EEPROM_MAX_TX_POWER, &word);
++ if (rt2x00_get_field16(word, EEPROM_MAX_TX_POWER_24GHZ) == 0xff)
++ rt2x00_set_field16(&word, EEPROM_MAX_TX_POWER_24GHZ, MAX_G_TXPOWER);
++ if (rt2x00_get_field16(word, EEPROM_MAX_TX_POWER_5GHZ) == 0xff)
++ rt2x00_set_field16(&word, EEPROM_MAX_TX_POWER_5GHZ, MAX_A_TXPOWER);
++ rt2x00_eeprom_write(rt2x00dev, EEPROM_MAX_TX_POWER, word);
++
+ return 0;
+ }
+ EXPORT_SYMBOL_GPL(rt2800_validate_eeprom);
+@@ -2755,9 +2760,10 @@ int rt2800_probe_hw_mode(struct rt2x00_d
+ {
+ struct hw_mode_spec *spec = &rt2x00dev->spec;
+ struct channel_info *info;
+- char *tx_power1;
+- char *tx_power2;
++ char *default_power1;
++ char *default_power2;
+ unsigned int i;
++ unsigned short max_power;
+ u16 eeprom;
+
+ /*
+@@ -2871,21 +2877,26 @@ int rt2800_probe_hw_mode(struct rt2x00_d
+
+ spec->channels_info = info;
+
+- tx_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG1);
+- tx_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
++ rt2x00_eeprom_read(rt2x00dev, EEPROM_MAX_TX_POWER, &eeprom);
++ max_power = rt2x00_get_field16(eeprom, EEPROM_MAX_TX_POWER_24GHZ);
++ default_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG1);
++ default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_BG2);
+
+ for (i = 0; i < 14; i++) {
+- info[i].tx_power1 = TXPOWER_G_FROM_DEV(tx_power1[i]);
+- info[i].tx_power2 = TXPOWER_G_FROM_DEV(tx_power2[i]);
++ info[i].max_power = max_power;
++ info[i].default_power1 = TXPOWER_G_FROM_DEV(default_power1[i]);
++ info[i].default_power2 = TXPOWER_G_FROM_DEV(default_power2[i]);
+ }
+
+ if (spec->num_channels > 14) {
+- tx_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A1);
+- tx_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A2);
++ max_power = rt2x00_get_field16(eeprom, EEPROM_MAX_TX_POWER_5GHZ);
++ default_power1 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A1);
++ default_power2 = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A2);
+
+ for (i = 14; i < spec->num_channels; i++) {
+- info[i].tx_power1 = TXPOWER_A_FROM_DEV(tx_power1[i]);
+- info[i].tx_power2 = TXPOWER_A_FROM_DEV(tx_power2[i]);
++ info[i].max_power = max_power;
++ info[i].default_power1 = TXPOWER_A_FROM_DEV(default_power1[i]);
++ info[i].default_power2 = TXPOWER_A_FROM_DEV(default_power2[i]);
+ }
+ }
+
+--- a/drivers/net/wireless/rt2x00/rt2x00.h
++++ b/drivers/net/wireless/rt2x00/rt2x00.h
+@@ -212,8 +212,9 @@ struct channel_info {
+ unsigned int flags;
+ #define GEOGRAPHY_ALLOWED 0x00000001
+
+- short tx_power1;
+- short tx_power2;
++ short max_power;
++ short default_power1;
++ short default_power2;
+ };
+
+ /*
+--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
++++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
+@@ -710,7 +710,7 @@ static int rt2x00lib_probe_hw_modes(stru
+ for (i = 0; i < spec->num_channels; i++) {
+ rt2x00lib_channel(&channels[i],
+ spec->channels[i].channel,
+- spec->channels_info[i].tx_power1, i);
++ spec->channels_info[i].max_power, i);
+ }
+
+ /*
+--- a/drivers/net/wireless/rt2x00/rt61pci.c
++++ b/drivers/net/wireless/rt2x00/rt61pci.c
+@@ -2661,13 +2661,17 @@ static int rt61pci_probe_hw_mode(struct
+ spec->channels_info = info;
+
+ tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_G_START);
+- for (i = 0; i < 14; i++)
+- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ for (i = 0; i < 14; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ }
+
+ if (spec->num_channels > 14) {
+ tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A_START);
+- for (i = 14; i < spec->num_channels; i++)
+- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ for (i = 14; i < spec->num_channels; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ }
+ }
+
+ return 0;
+--- a/drivers/net/wireless/rt2x00/rt73usb.c
++++ b/drivers/net/wireless/rt2x00/rt73usb.c
+@@ -2091,13 +2091,17 @@ static int rt73usb_probe_hw_mode(struct
+ spec->channels_info = info;
+
+ tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_G_START);
+- for (i = 0; i < 14; i++)
+- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ for (i = 0; i < 14; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ }
+
+ if (spec->num_channels > 14) {
+ tx_power = rt2x00_eeprom_addr(rt2x00dev, EEPROM_TXPOWER_A_START);
+- for (i = 14; i < spec->num_channels; i++)
+- info[i].tx_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ for (i = 14; i < spec->num_channels; i++) {
++ info[i].max_power = MAX_TXPOWER;
++ info[i].default_power1 = TXPOWER_FROM_DEV(tx_power[i]);
++ }
+ }
+
+ return 0;
mips-jz4740-qi_lb60-fix-gpio-for-the-6th-row-of-the-keyboard-matrix.patch
pm-runtime-fix-pm_runtime_suspended.patch
inotify-stop-kernel-memory-leak-on-file-creation-failure.patch
+orinoco-fix-tkip-countermeasure-behaviour.patch
+orinoco-clear-countermeasure-setting-on-commit.patch
+x86-amd-fix-panic-on-amd-cpu-family-0x15.patch
+md-fix-bug-with-re-adding-of-partially-recovered-device.patch
+md-protect-against-null-reference-when-waiting-to-start-a-raid10.patch
+tracing-fix-panic-when-lseek-called-on-trace-opened-for-writing.patch
+arch-tile-handle-clone_settls-in-copy_thread-not-user-space.patch
+x86-gcc-4.6-use-gcc-m-options-when-building-vdso.patch
+x86-enable-the-intr-remap-fault-handling-after-local-apic-setup.patch
+x86-vt-d-handle-previous-faults-after-enabling-fault-handling.patch
+x86-vt-d-fix-the-vt-d-fault-handling-irq-migration-in-the-x2apic-mode.patch
+x86-vt-d-quirk-for-masking-vtd-spec-errors-to-platform-error-handling-logic.patch
+rt2x00-fix-max-tx-power-settings.patch
+alsa-hda-enable-jack-sense-for-thinkpad-edge-11.patch
+input-synaptics-fix-handling-of-2-button-clickpads.patch
+install_special_mapping-skips-security_file_mmap-check.patch
--- /dev/null
+From 364829b1263b44aa60383824e4c1289d83d78ca7 Mon Sep 17 00:00:00 2001
+From: Slava Pestov <slavapestov@google.com>
+Date: Wed, 24 Nov 2010 15:13:16 -0800
+Subject: tracing: Fix panic when lseek() called on "trace" opened for writing
+
+From: Slava Pestov <slavapestov@google.com>
+
+commit 364829b1263b44aa60383824e4c1289d83d78ca7 upstream.
+
+The file_ops struct for the "trace" special file defined llseek as seq_lseek().
+However, if the file was opened for writing only, seq_open() was not called,
+and the seek would dereference a null pointer, file->private_data.
+
+This patch introduces a new wrapper for seq_lseek() which checks if the file
+descriptor is opened for reading first. If not, it does nothing.
+
+Signed-off-by: Slava Pestov <slavapestov@google.com>
+LKML-Reference: <1290640396-24179-1-git-send-email-slavapestov@google.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ kernel/trace/trace.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -2320,11 +2320,19 @@ tracing_write_stub(struct file *filp, co
+ return count;
+ }
+
++static loff_t tracing_seek(struct file *file, loff_t offset, int origin)
++{
++ if (file->f_mode & FMODE_READ)
++ return seq_lseek(file, offset, origin);
++ else
++ return 0;
++}
++
+ static const struct file_operations tracing_fops = {
+ .open = tracing_open,
+ .read = seq_read,
+ .write = tracing_write_stub,
+- .llseek = seq_lseek,
++ .llseek = tracing_seek,
+ .release = tracing_release,
+ };
+
--- /dev/null
+From andreas.herrmann3@amd.com Mon Dec 20 15:36:51 2010
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+Date: Thu, 16 Dec 2010 21:29:37 +0100
+Subject: x86, amd: Fix panic on AMD CPU family 0x15
+To: "stable@kernel.org" <stable@kernel.org>
+Message-ID: <20101216202937.GF29531@alberich.amd.com>
+Content-Disposition: inline
+
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+
+[The mainline kernel doesn't have this problem. Commit "(23588c3) x86,
+amd: Add support for CPUID topology extension of AMD CPUs" removed the
+family check. But 2.6.32.y needs to be fixed.]
+
+This CPU family check is not required -- existence of the NodeId MSR
+is indicated by a CPUID feature flag which is already checked in
+amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be
+called for newer AMD CPUs.
+
+In worst case this can lead to a panic in the scheduler code for AMD
+family 0x15 multi-node AMD CPUs. I just have a picture of VGA console
+output so I can't copy-and-paste it herein, but the call stack of such
+a panic looked like:
+
+ do_divide_error
+ ...
+ find_busiest_group
+ run_rebalance_domains
+ ...
+ apic_timer_interrupt
+ ...
+ cpu_idle
+
+The mainline kernel doesn't have this problem. Commit "(23588c3) x86,
+amd: Add support for CPUID topology extension of AMD CPUs" removed the
+family check. But 2.6.32.y needs to be fixed.
+
+Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/cpu/amd.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/cpu/amd.c
++++ b/arch/x86/kernel/cpu/amd.c
+@@ -305,8 +305,7 @@ static void __cpuinit amd_detect_cmp(str
+ /* use socket ID also for last level cache */
+ per_cpu(cpu_llc_id, cpu) = c->phys_proc_id;
+ /* fixup topology information on multi-node processors */
+- if ((c->x86 == 0x10) && (c->x86_model == 9))
+- amd_fixup_dcm(c);
++ amd_fixup_dcm(c);
+ #endif
+ }
+
--- /dev/null
+From 7f7fbf45c6b748074546f7f16b9488ca71de99c1 Mon Sep 17 00:00:00 2001
+From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
+Date: Tue, 30 Nov 2010 22:22:28 -0800
+Subject: x86: Enable the intr-remap fault handling after local APIC setup
+
+From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
+
+commit 7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream.
+
+Interrupt-remapping gets enabled very early in the boot, as it determines the
+apic mode that the processor can use. And the current code enables the vt-d
+fault handling before the setup_local_APIC(). And hence the APIC LDR registers
+and data structure in the memory may not be initialized. So the vt-d fault
+handling in logical xapic/x2apic modes were broken.
+
+Fix this by enabling the vt-d fault handling in the end_local_APIC_setup()
+
+A cleaner fix of enabling fault handling while enabling intr-remapping
+will be addressed for v2.6.38. [ Enabling intr-remapping determines the
+usage of x2apic mode and the apic mode determines the fault-handling
+configuration. ]
+
+Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
+LKML-Reference: <20101201062244.541996375@intel.com>
+Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
+Acked-by: Chris Wright <chrisw@sous-sol.org>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/apic/apic.c | 8 ++++++++
+ arch/x86/kernel/apic/probe_64.c | 7 -------
+ 2 files changed, 8 insertions(+), 7 deletions(-)
+
+--- a/arch/x86/kernel/apic/apic.c
++++ b/arch/x86/kernel/apic/apic.c
+@@ -1340,6 +1340,14 @@ void __cpuinit end_local_APIC_setup(void
+
+ setup_apic_nmi_watchdog(NULL);
+ apic_pm_activate();
++
++ /*
++ * Now that local APIC setup is completed for BP, configure the fault
++ * handling for interrupt remapping.
++ */
++ if (!smp_processor_id() && intr_remapping_enabled)
++ enable_drhd_fault_handling();
++
+ }
+
+ #ifdef CONFIG_X86_X2APIC
+--- a/arch/x86/kernel/apic/probe_64.c
++++ b/arch/x86/kernel/apic/probe_64.c
+@@ -76,13 +76,6 @@ void __init default_setup_apic_routing(v
+ /* need to update phys_pkg_id */
+ apic->phys_pkg_id = apicid_phys_pkg_id;
+ }
+-
+- /*
+- * Now that apic routing model is selected, configure the
+- * fault handling for intr remapping.
+- */
+- if (intr_remapping_enabled)
+- enable_drhd_fault_handling();
+ }
+
+ /* Same for both flat and physical. */
--- /dev/null
+From de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 Mon Sep 17 00:00:00 2001
+From: H. Peter Anvin <hpa@linux.intel.com>
+Date: Mon, 13 Dec 2010 16:01:38 -0800
+Subject: x86, gcc-4.6: Use gcc -m options when building vdso
+
+From: H. Peter Anvin <hpa@linux.intel.com>
+
+commit de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream.
+
+The vdso Makefile passes linker-style -m options not to the linker but
+to gcc. This happens to work with earlier gcc, but fails with gcc
+4.6. Pass gcc-style -m options, instead.
+
+Note: all currently supported versions of gcc supports -m32, so there
+is no reason to conditionalize it any more.
+
+Reported-by: H. J. Lu <hjl.tools@gmail.com>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+LKML-Reference: <tip-*@git.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/vdso/Makefile | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/vdso/Makefile
++++ b/arch/x86/vdso/Makefile
+@@ -25,7 +25,7 @@ targets += vdso.so vdso.so.dbg vdso.lds
+
+ export CPPFLAGS_vdso.lds += -P -C
+
+-VDSO_LDFLAGS_vdso.lds = -m elf_x86_64 -Wl,-soname=linux-vdso.so.1 \
++VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
+ -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096
+
+ $(obj)/vdso.o: $(src)/vdso.S $(obj)/vdso.so
+@@ -69,7 +69,7 @@ vdso32.so-$(VDSO32-y) += sysenter
+ vdso32-images = $(vdso32.so-y:%=vdso32-%.so)
+
+ CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
+-VDSO_LDFLAGS_vdso32.lds = -m elf_i386 -Wl,-soname=linux-gate.so.1
++VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1
+
+ # This makes sure the $(obj) subdirectory exists even though vdso32/
+ # is not a kbuild sub-make subdirectory.
--- /dev/null
+From 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 Mon Sep 17 00:00:00 2001
+From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
+Date: Wed, 1 Dec 2010 09:40:32 -0800
+Subject: x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode
+
+From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
+
+commit 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream.
+
+In x2apic mode, we need to set the upper address register of the fault
+handling interrupt register of the vt-d hardware. Without this
+irq migration of the vt-d fault handling interrupt is broken.
+
+Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
+LKML-Reference: <1291225233.2648.39.camel@sbsiddha-MOBL3>
+Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
+Acked-by: Chris Wright <chrisw@sous-sol.org>
+Tested-by: Takao Indoh <indou.takao@jp.fujitsu.com>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/apic/io_apic.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kernel/apic/io_apic.c
++++ b/arch/x86/kernel/apic/io_apic.c
+@@ -3626,6 +3626,7 @@ static int dmar_msi_set_affinity(unsigne
+ msg.data |= MSI_DATA_VECTOR(cfg->vector);
+ msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
+ msg.address_lo |= MSI_ADDR_DEST_ID(dest);
++ msg.address_hi = MSI_ADDR_BASE_HI | MSI_ADDR_EXT_DEST_ID(dest);
+
+ dmar_msi_write(irq, &msg);
+
--- /dev/null
+From 7f99d946e71e71d484b7543b49e990508e70d0c0 Mon Sep 17 00:00:00 2001
+From: Suresh Siddha <suresh.b.siddha@intel.com>
+Date: Tue, 30 Nov 2010 22:22:29 -0800
+Subject: x86, vt-d: Handle previous faults after enabling fault handling
+
+From: Suresh Siddha <suresh.b.siddha@intel.com>
+
+commit 7f99d946e71e71d484b7543b49e990508e70d0c0 upstream.
+
+Fault handling is getting enabled after enabling the interrupt-remapping (as
+the success of interrupt-remapping can affect the apic mode and hence the
+fault handling mode).
+
+Hence there can potentially be some faults between the window of enabling
+interrupt-remapping in the vt-d and the fault-handling of the vt-d units.
+
+Handle any previous faults after enabling the vt-d fault handling.
+
+For v2.6.38 cleanup, need to check if we can remove the dmar_fault() in the
+enable_intr_remapping() and see if we can enable fault handling along with
+enabling intr-remapping.
+
+Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
+LKML-Reference: <20101201062244.630417138@intel.com>
+Acked-by: Chris Wright <chrisw@sous-sol.org>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/dmar.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/pci/dmar.c
++++ b/drivers/pci/dmar.c
+@@ -1414,6 +1414,11 @@ int __init enable_drhd_fault_handling(vo
+ (unsigned long long)drhd->reg_base_addr, ret);
+ return -1;
+ }
++
++ /*
++ * Clear any previous faults.
++ */
++ dmar_fault(iommu->irq, iommu);
+ }
+
+ return 0;
--- /dev/null
+From 254e42006c893f45bca48f313536fcba12206418 Mon Sep 17 00:00:00 2001
+From: Suresh Siddha <suresh.b.siddha@intel.com>
+Date: Mon, 6 Dec 2010 12:26:30 -0800
+Subject: x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
+
+From: Suresh Siddha <suresh.b.siddha@intel.com>
+
+commit 254e42006c893f45bca48f313536fcba12206418 upstream.
+
+On platforms with Intel 7500 chipset, there were some reports of system
+hang/NMI's during kexec/kdump in the presence of interrupt-remapping enabled.
+
+During kdump, there is a window where the devices might be still using old
+kernel's interrupt information, while the kdump kernel is coming up. This can
+cause vt-d faults as the interrupt configuration from the old kernel map to
+null IRTE entries in the new kernel etc. (with out interrupt-remapping enabled,
+we still have the same issue but in this case we will see benign spurious
+interrupt hit the new kernel).
+
+Based on platform config settings, these platforms seem to generate NMI/SMI
+when a vt-d fault happens and there were reports that the resulting SMI causes
+the system to hang.
+
+Fix it by masking vt-d spec defined errors to platform error reporting logic.
+VT-d spec related errors are already handled by the VT-d OS code, so need to
+report the same error through other channels.
+
+Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
+LKML-Reference: <1291667190.2675.8.camel@sbsiddha-MOBL3.sc.intel.com>
+Reported-by: Max Asbock <masbock@linux.vnet.ibm.com>
+Reported-and-tested-by: Takao Indoh <indou.takao@jp.fujitsu.com>
+Acked-by: Chris Wright <chrisw@sous-sol.org>
+Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/quirks.c | 23 +++++++++++++++++++++++
+ 1 file changed, 23 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -2714,6 +2714,29 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_RI
+ DECLARE_PCI_FIXUP_RESUME_EARLY(PCI_VENDOR_ID_RICOH, PCI_DEVICE_ID_RICOH_R5C832, ricoh_mmc_fixup_r5c832);
+ #endif /*CONFIG_MMC_RICOH_MMC*/
+
++#if defined(CONFIG_DMAR) || defined(CONFIG_INTR_REMAP)
++#define VTUNCERRMSK_REG 0x1ac
++#define VTD_MSK_SPEC_ERRORS (1 << 31)
++/*
++ * This is a quirk for masking vt-d spec defined errors to platform error
++ * handling logic. With out this, platforms using Intel 7500, 5500 chipsets
++ * (and the derivative chipsets like X58 etc) seem to generate NMI/SMI (based
++ * on the RAS config settings of the platform) when a vt-d fault happens.
++ * The resulting SMI caused the system to hang.
++ *
++ * VT-d spec related errors are already handled by the VT-d OS code, so no
++ * need to report the same error through other channels.
++ */
++static void vtd_mask_spec_errors(struct pci_dev *dev)
++{
++ u32 word;
++
++ pci_read_config_dword(dev, VTUNCERRMSK_REG, &word);
++ pci_write_config_dword(dev, VTUNCERRMSK_REG, word | VTD_MSK_SPEC_ERRORS);
++}
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x342e, vtd_mask_spec_errors);
++DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x3c28, vtd_mask_spec_errors);
++#endif
+
+ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
+ struct pci_fixup *end)
projects / thirdparty / kernel / stable-queue.git / commitdiff
