--- /dev/null
+From b7db60f45d74497c723dc7ae1370cf0b37dfb0d8 Mon Sep 17 00:00:00 2001
+From: Feng Tang <feng.tang@intel.com>
+Date: Tue, 31 Jul 2012 12:44:43 +0800
+Subject: ACPI processor: Fix tick_broadcast_mask online/offline regression
+
+From: Feng Tang <feng.tang@intel.com>
+
+commit b7db60f45d74497c723dc7ae1370cf0b37dfb0d8 upstream.
+
+In commit 99b725084 "ACPI processor hotplug: Delay acpi_processor_start()
+call for hotplugged cores", acpi_processor_hotplug(pr) was wrongly replaced
+by acpi_processor_cst_has_changed() inside the acpi_cpu_soft_notify(). This
+patch will restore it back, fixing the tick_broadcast_mask regression:
+ https://lkml.org/lkml/2012/7/30/169
+
+Signed-off-by: Feng Tang <feng.tang@intel.com>
+Cc: Thomas Renninger <trenn@suse.de>
+Reviewed-by: Rafael J. Wysocki <rjw@sisk.pl>
+Reviewed-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/processor_driver.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/acpi/processor_driver.c
++++ b/drivers/acpi/processor_driver.c
+@@ -442,7 +442,7 @@ static int acpi_cpu_soft_notify(struct n
+ /* Normal CPU soft online event */
+ } else {
+ acpi_processor_ppc_has_changed(pr, 0);
+- acpi_processor_cst_has_changed(pr);
++ acpi_processor_hotplug(pr);
+ acpi_processor_reevaluate_tstate(pr, action);
+ acpi_processor_tstate_has_changed(pr);
+ }
--- /dev/null
+From d4e5979c0da95791aa717c18e162540c7a596360 Mon Sep 17 00:00:00 2001
+From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
+Date: Thu, 2 Aug 2012 11:58:50 +0530
+Subject: ath9k: Add PID/VID support for AR1111
+
+From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
+
+commit d4e5979c0da95791aa717c18e162540c7a596360 upstream.
+
+AR1111 is same as AR9485. The h/w
+difference between them is quite insignificant,
+Felix suggests only very few baseband features
+may not be available in AR1111. The h/w code for
+AR9485 is already present, so AR1111 should
+work fine with the addition of its PID/VID.
+
+Reported-by: Tim Bentley <Tim.Bentley@Gmail.com>
+Cc: Felix Bitterli <felixb@qca.qualcomm.com>
+Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
+Tested-by: Tim Bentley <Tim.Bentley@Gmail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/ath/ath9k/hw.c | 1 +
+ drivers/net/wireless/ath/ath9k/hw.h | 1 +
+ drivers/net/wireless/ath/ath9k/pci.c | 1 +
+ 3 files changed, 3 insertions(+)
+
+--- a/drivers/net/wireless/ath/ath9k/hw.c
++++ b/drivers/net/wireless/ath/ath9k/hw.c
+@@ -676,6 +676,7 @@ int ath9k_hw_init(struct ath_hw *ah)
+ case AR9300_DEVID_AR9340:
+ case AR9300_DEVID_AR9580:
+ case AR9300_DEVID_AR9462:
++ case AR9485_DEVID_AR1111:
+ break;
+ default:
+ if (common->bus_ops->ath_bus_type == ATH_USB)
+--- a/drivers/net/wireless/ath/ath9k/hw.h
++++ b/drivers/net/wireless/ath/ath9k/hw.h
+@@ -48,6 +48,7 @@
+ #define AR9300_DEVID_AR9580 0x0033
+ #define AR9300_DEVID_AR9462 0x0034
+ #define AR9300_DEVID_AR9330 0x0035
++#define AR9485_DEVID_AR1111 0x0037
+
+ #define AR5416_AR9100_DEVID 0x000b
+
+--- a/drivers/net/wireless/ath/ath9k/pci.c
++++ b/drivers/net/wireless/ath/ath9k/pci.c
+@@ -35,6 +35,7 @@ static DEFINE_PCI_DEVICE_TABLE(ath_pci_i
+ { PCI_VDEVICE(ATHEROS, 0x0032) }, /* PCI-E AR9485 */
+ { PCI_VDEVICE(ATHEROS, 0x0033) }, /* PCI-E AR9580 */
+ { PCI_VDEVICE(ATHEROS, 0x0034) }, /* PCI-E AR9462 */
++ { PCI_VDEVICE(ATHEROS, 0x0037) }, /* PCI-E AR1111/AR9485 */
+ { 0 }
+ };
+
--- /dev/null
+From dd4c9260e7f23f2e951cbfb2726e468c6d30306c Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 1 Aug 2012 21:03:21 +0200
+Subject: mac80211: cancel mesh path timer
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit dd4c9260e7f23f2e951cbfb2726e468c6d30306c upstream.
+
+The mesh path timer needs to be canceled when
+leaving the mesh as otherwise it could fire
+after the interface has been removed already.
+
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/mac80211/mesh.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/mac80211/mesh.c
++++ b/net/mac80211/mesh.c
+@@ -595,6 +595,7 @@ void ieee80211_stop_mesh(struct ieee8021
+
+ del_timer_sync(&sdata->u.mesh.housekeeping_timer);
+ del_timer_sync(&sdata->u.mesh.mesh_path_root_timer);
++ del_timer_sync(&sdata->u.mesh.mesh_path_timer);
+ /*
+ * If the timer fired while we waited for it, it will have
+ * requeued the work. Now the work will be running again
--- /dev/null
+From b7219ccb33aa0df9949a60c68b5e9f712615e56f Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Tue, 31 Jul 2012 10:05:34 +1000
+Subject: md/raid1: don't abort a resync on the first badblock.
+
+From: NeilBrown <neilb@suse.de>
+
+commit b7219ccb33aa0df9949a60c68b5e9f712615e56f upstream.
+
+If a resync of a RAID1 array with 2 devices finds a known bad block
+one device it will neither read from, or write to, that device for
+this block offset.
+So there will be one read_target (The other device) and zero write
+targets.
+This condition causes md/raid1 to abort the resync assuming that it
+has finished - without known bad blocks this would be true.
+
+When there are no write targets because of the presence of bad blocks
+we should only skip over the area covered by the bad block.
+RAID10 already gets this right, raid1 doesn't. Or didn't.
+
+As this can cause a 'sync' to abort early and appear to have succeeded
+it could lead to some data corruption, so it suitable for -stable.
+
+Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid1.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/raid1.c
++++ b/drivers/md/raid1.c
+@@ -2429,7 +2429,10 @@ static sector_t sync_request(struct mdde
+ /* There is nowhere to write, so all non-sync
+ * drives must be failed - so we are finished
+ */
+- sector_t rv = max_sector - sector_nr;
++ sector_t rv;
++ if (min_bad > 0)
++ max_sector = sector_nr + min_bad;
++ rv = max_sector - sector_nr;
+ *skipped = 1;
+ put_buf(r1_bio);
+ return rv;
--- /dev/null
+From 3ad3d901bbcfb15a5e4690e55350db0899095a68 Mon Sep 17 00:00:00 2001
+From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
+Date: Tue, 31 Jul 2012 16:45:52 -0700
+Subject: mm: mmu_notifier: fix freed page still mapped in secondary MMU
+
+From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
+
+commit 3ad3d901bbcfb15a5e4690e55350db0899095a68 upstream.
+
+mmu_notifier_release() is called when the process is exiting. It will
+delete all the mmu notifiers. But at this time the page belonging to the
+process is still present in page tables and is present on the LRU list, so
+this race will happen:
+
+ CPU 0 CPU 1
+mmu_notifier_release: try_to_unmap:
+ hlist_del_init_rcu(&mn->hlist);
+ ptep_clear_flush_notify:
+ mmu nofifler not found
+ free page !!!!!!
+ /*
+ * At the point, the page has been
+ * freed, but it is still mapped in
+ * the secondary MMU.
+ */
+
+ mn->ops->release(mn, mm);
+
+Then the box is not stable and sometimes we can get this bug:
+
+[ 738.075923] BUG: Bad page state in process migrate-perf pfn:03bec
+[ 738.075931] page:ffffea00000efb00 count:0 mapcount:0 mapping: (null) index:0x8076
+[ 738.075936] page flags: 0x20000000000014(referenced|dirty)
+
+The same issue is present in mmu_notifier_unregister().
+
+We can call ->release before deleting the notifier to ensure the page has
+been unmapped from the secondary MMU before it is freed.
+
+Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
+Cc: Avi Kivity <avi@redhat.com>
+Cc: Marcelo Tosatti <mtosatti@redhat.com>
+Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mmu_notifier.c | 45 +++++++++++++++++++++++----------------------
+ 1 file changed, 23 insertions(+), 22 deletions(-)
+
+--- a/mm/mmu_notifier.c
++++ b/mm/mmu_notifier.c
+@@ -33,6 +33,24 @@
+ void __mmu_notifier_release(struct mm_struct *mm)
+ {
+ struct mmu_notifier *mn;
++ struct hlist_node *n;
++
++ /*
++ * RCU here will block mmu_notifier_unregister until
++ * ->release returns.
++ */
++ rcu_read_lock();
++ hlist_for_each_entry_rcu(mn, n, &mm->mmu_notifier_mm->list, hlist)
++ /*
++ * if ->release runs before mmu_notifier_unregister it
++ * must be handled as it's the only way for the driver
++ * to flush all existing sptes and stop the driver
++ * from establishing any more sptes before all the
++ * pages in the mm are freed.
++ */
++ if (mn->ops->release)
++ mn->ops->release(mn, mm);
++ rcu_read_unlock();
+
+ spin_lock(&mm->mmu_notifier_mm->lock);
+ while (unlikely(!hlist_empty(&mm->mmu_notifier_mm->list))) {
+@@ -46,23 +64,6 @@ void __mmu_notifier_release(struct mm_st
+ * mmu_notifier_unregister to return.
+ */
+ hlist_del_init_rcu(&mn->hlist);
+- /*
+- * RCU here will block mmu_notifier_unregister until
+- * ->release returns.
+- */
+- rcu_read_lock();
+- spin_unlock(&mm->mmu_notifier_mm->lock);
+- /*
+- * if ->release runs before mmu_notifier_unregister it
+- * must be handled as it's the only way for the driver
+- * to flush all existing sptes and stop the driver
+- * from establishing any more sptes before all the
+- * pages in the mm are freed.
+- */
+- if (mn->ops->release)
+- mn->ops->release(mn, mm);
+- rcu_read_unlock();
+- spin_lock(&mm->mmu_notifier_mm->lock);
+ }
+ spin_unlock(&mm->mmu_notifier_mm->lock);
+
+@@ -284,16 +285,13 @@ void mmu_notifier_unregister(struct mmu_
+ {
+ BUG_ON(atomic_read(&mm->mm_count) <= 0);
+
+- spin_lock(&mm->mmu_notifier_mm->lock);
+ if (!hlist_unhashed(&mn->hlist)) {
+- hlist_del_rcu(&mn->hlist);
+-
+ /*
+ * RCU here will force exit_mmap to wait ->release to finish
+ * before freeing the pages.
+ */
+ rcu_read_lock();
+- spin_unlock(&mm->mmu_notifier_mm->lock);
++
+ /*
+ * exit_mmap will block in mmu_notifier_release to
+ * guarantee ->release is called before freeing the
+@@ -302,8 +300,11 @@ void mmu_notifier_unregister(struct mmu_
+ if (mn->ops->release)
+ mn->ops->release(mn, mm);
+ rcu_read_unlock();
+- } else
++
++ spin_lock(&mm->mmu_notifier_mm->lock);
++ hlist_del_rcu(&mn->hlist);
+ spin_unlock(&mm->mmu_notifier_mm->lock);
++ }
+
+ /*
+ * Wait any running method to finish, of course including
--- /dev/null
+From 9e62bb4458ad2cf28bd701aa5fab380b846db326 Mon Sep 17 00:00:00 2001
+From: Boaz Harrosh <bharrosh@panasas.com>
+Date: Wed, 1 Aug 2012 17:48:36 +0300
+Subject: ore: Fix out-of-bounds access in _ios_obj()
+
+From: Boaz Harrosh <bharrosh@panasas.com>
+
+commit 9e62bb4458ad2cf28bd701aa5fab380b846db326 upstream.
+
+_ios_obj() is accessed by group_index not device_table index.
+
+The oc->comps array is only a group_full of devices at a time
+it is not like ore_comp_dev() which is indexed by a global
+device_table index.
+
+This did not BUG until now because exofs only uses a single
+COMP for all devices. But with other FSs like PanFS this is
+not true.
+
+This bug was only in the write_path, all other users were
+using it correctly
+
+[This is a bug since 3.2 Kernel]
+
+Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/exofs/ore.c | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+--- a/fs/exofs/ore.c
++++ b/fs/exofs/ore.c
+@@ -837,11 +837,11 @@ static int _write_mirror(struct ore_io_s
+ bio->bi_rw |= REQ_WRITE;
+ }
+
+- osd_req_write(or, _ios_obj(ios, dev), per_dev->offset,
+- bio, per_dev->length);
++ osd_req_write(or, _ios_obj(ios, cur_comp),
++ per_dev->offset, bio, per_dev->length);
+ ORE_DBGMSG("write(0x%llx) offset=0x%llx "
+ "length=0x%llx dev=%d\n",
+- _LLU(_ios_obj(ios, dev)->id),
++ _LLU(_ios_obj(ios, cur_comp)->id),
+ _LLU(per_dev->offset),
+ _LLU(per_dev->length), dev);
+ } else if (ios->kern_buff) {
+@@ -853,20 +853,20 @@ static int _write_mirror(struct ore_io_s
+ (ios->si.unit_off + ios->length >
+ ios->layout->stripe_unit));
+
+- ret = osd_req_write_kern(or, _ios_obj(ios, per_dev->dev),
++ ret = osd_req_write_kern(or, _ios_obj(ios, cur_comp),
+ per_dev->offset,
+ ios->kern_buff, ios->length);
+ if (unlikely(ret))
+ goto out;
+ ORE_DBGMSG2("write_kern(0x%llx) offset=0x%llx "
+ "length=0x%llx dev=%d\n",
+- _LLU(_ios_obj(ios, dev)->id),
++ _LLU(_ios_obj(ios, cur_comp)->id),
+ _LLU(per_dev->offset),
+ _LLU(ios->length), per_dev->dev);
+ } else {
+- osd_req_set_attributes(or, _ios_obj(ios, dev));
++ osd_req_set_attributes(or, _ios_obj(ios, cur_comp));
+ ORE_DBGMSG2("obj(0x%llx) set_attributes=%d dev=%d\n",
+- _LLU(_ios_obj(ios, dev)->id),
++ _LLU(_ios_obj(ios, cur_comp)->id),
+ ios->out_attr_len, dev);
+ }
+
alsa-hda-add-dock-support-for-thinkpad-x230.patch
alsa-hda-remove-quirk-for-dell-vostro-1015.patch
alsa-hda-fix-double-quirk-for-quanta-fl1-lenovo-ideapad.patch
+mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch
+md-raid1-don-t-abort-a-resync-on-the-first-badblock.patch
+video-smscufx-fix-line-counting-in-fb_write.patch
+ore-fix-out-of-bounds-access-in-_ios_obj.patch
+acpi-processor-fix-tick_broadcast_mask-online-offline-regression.patch
+mac80211-cancel-mesh-path-timer.patch
+ath9k-add-pid-vid-support-for-ar1111.patch
+wireless-reg-restore-previous-behaviour-of-chan-max_power-calculations.patch
--- /dev/null
+From 2fe2d9f47cfe1a3e66e7d087368b3d7155b04c15 Mon Sep 17 00:00:00 2001
+From: Alexander Holler <holler@ahsoftware.de>
+Date: Sat, 21 Apr 2012 00:11:07 +0200
+Subject: video/smscufx: fix line counting in fb_write
+
+From: Alexander Holler <holler@ahsoftware.de>
+
+commit 2fe2d9f47cfe1a3e66e7d087368b3d7155b04c15 upstream.
+
+Line 0 and 1 were both written to line 0 (on the display) and all subsequent
+lines had an offset of -1. The result was that the last line on the display
+was never overwritten by writes to /dev/fbN.
+
+The origin of this bug seems to have been udlfb.
+
+Signed-off-by: Alexander Holler <holler@ahsoftware.de>
+Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/smscufx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/video/smscufx.c
++++ b/drivers/video/smscufx.c
+@@ -904,7 +904,7 @@ static ssize_t ufx_ops_write(struct fb_i
+ result = fb_sys_write(info, buf, count, ppos);
+
+ if (result > 0) {
+- int start = max((int)(offset / info->fix.line_length) - 1, 0);
++ int start = max((int)(offset / info->fix.line_length), 0);
+ int lines = min((u32)((result / info->fix.line_length) + 1),
+ (u32)info->var.yres);
+
--- /dev/null
+From 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 Mon Sep 17 00:00:00 2001
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Tue, 24 Jul 2012 08:35:39 +0200
+Subject: wireless: reg: restore previous behaviour of chan->max_power calculations
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+commit 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 upstream.
+
+commit eccc068e8e84c8fe997115629925e0422a98e4de
+Author: Hong Wu <Hong.Wu@dspg.com>
+Date: Wed Jan 11 20:33:39 2012 +0200
+
+ wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit pow
+
+changed the way we calculate chan->max_power as min(chan->max_power,
+chan->max_reg_power). That broke rt2x00 (and perhaps some other
+drivers) that do not set chan->max_power. It is not so easy to fix this
+problem correctly in rt2x00.
+
+According to commit eccc068e8 changelog, change claim only to save
+maximum regulatory power - changing setting of chan->max_power was side
+effect. This patch restore previous calculations of chan->max_power and
+do not touch chan->max_reg_power.
+
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Acked-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/wireless/reg.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+--- a/net/wireless/reg.c
++++ b/net/wireless/reg.c
+@@ -891,7 +891,21 @@ static void handle_channel(struct wiphy
+ chan->max_antenna_gain = min(chan->orig_mag,
+ (int) MBI_TO_DBI(power_rule->max_antenna_gain));
+ chan->max_reg_power = (int) MBM_TO_DBM(power_rule->max_eirp);
+- chan->max_power = min(chan->max_power, chan->max_reg_power);
++ if (chan->orig_mpwr) {
++ /*
++ * Devices that have their own custom regulatory domain
++ * but also use WIPHY_FLAG_STRICT_REGULATORY will follow the
++ * passed country IE power settings.
++ */
++ if (initiator == NL80211_REGDOM_SET_BY_COUNTRY_IE &&
++ wiphy->flags & WIPHY_FLAG_CUSTOM_REGULATORY &&
++ wiphy->flags & WIPHY_FLAG_STRICT_REGULATORY)
++ chan->max_power = chan->max_reg_power;
++ else
++ chan->max_power = min(chan->orig_mpwr,
++ chan->max_reg_power);
++ } else
++ chan->max_power = chan->max_reg_power;
+ }
+
+ static void handle_band(struct wiphy *wiphy,
projects / thirdparty / kernel / stable-queue.git / commitdiff
