From 3c5f37a0326725f1c8fa449a21b7571b96c2ea27 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 26 Jul 2014 10:58:15 -0700 Subject: [PATCH] 3.15-stable patches added patches: alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch cpufreq-move-policy-kobj-to-policy-cpu-at-resume.patch drm-qxl-return-irq_none-if-it-was-not-our-irq.patch drm-radeon-avoid-leaking-edid-data.patch drm-radeon-set-default-bl-level-to-something-reasonable.patch hwrng-fetch-randomness-only-after-device-init.patch irqchip-gic-add-binding-probe-for-arm-gic400.patch irqchip-gic-add-support-for-cortex-a7-compatible-string.patch irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch mwifiex-fix-tx-timeout-issue.patch perf-do-not-allow-optimized-switch-for-non-cloned-events.patch perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch random-check-for-increase-of-entropy_count-because-of-signed-conversion.patch revert-drm-i915-reverse-dp-link-param-selection-prefer-fast-over-wide-again.patch ring-buffer-fix-polling-on-trace_pipe.patch x86-tsc-fix-cpufreq-lockup.patch --- ...larm-timers-were-treated-as-absolute.patch | 77 +++++++++++++ ...-policy-kobj-to-policy-cpu-at-resume.patch | 61 ++++++++++ ...eturn-irq_none-if-it-was-not-our-irq.patch | 37 +++++++ .../drm-radeon-avoid-leaking-edid-data.patch | 42 +++++++ ...ult-bl-level-to-something-reasonable.patch | 57 ++++++++++ ...ch-randomness-only-after-device-init.patch | 101 +++++++++++++++++ ...gic-add-binding-probe-for-arm-gic400.patch | 40 +++++++ ...port-for-cortex-a7-compatible-string.patch | 35 ++++++ ...lation-when-topology-is-read-from-dt.patch | 58 ++++++++++ ...ve-and-elm_context_restore-functions.patch | 39 +++++++ queue-3.15/mwifiex-fix-tx-timeout-issue.patch | 49 +++++++++ ...timized-switch-for-non-cloned-events.patch | 50 +++++++++ ...chgd-bit-to-avoid-false-nmi-handling.patch | 104 ++++++++++++++++++ ...y_count-because-of-signed-conversion.patch | 75 +++++++++++++ ...election-prefer-fast-over-wide-again.patch | 40 +++++++ ...ing-buffer-fix-polling-on-trace_pipe.patch | 59 ++++++++++ queue-3.15/series | 17 +++ queue-3.15/x86-tsc-fix-cpufreq-lockup.patch | 56 ++++++++++ 18 files changed, 997 insertions(+) create mode 100644 queue-3.15/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch create mode 100644 queue-3.15/cpufreq-move-policy-kobj-to-policy-cpu-at-resume.patch create mode 100644 queue-3.15/drm-qxl-return-irq_none-if-it-was-not-our-irq.patch create mode 100644 queue-3.15/drm-radeon-avoid-leaking-edid-data.patch create mode 100644 queue-3.15/drm-radeon-set-default-bl-level-to-something-reasonable.patch create mode 100644 queue-3.15/hwrng-fetch-randomness-only-after-device-init.patch create mode 100644 queue-3.15/irqchip-gic-add-binding-probe-for-arm-gic400.patch create mode 100644 queue-3.15/irqchip-gic-add-support-for-cortex-a7-compatible-string.patch create mode 100644 queue-3.15/irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch create mode 100644 queue-3.15/mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch create mode 100644 queue-3.15/mwifiex-fix-tx-timeout-issue.patch create mode 100644 queue-3.15/perf-do-not-allow-optimized-switch-for-non-cloned-events.patch create mode 100644 queue-3.15/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch create mode 100644 queue-3.15/random-check-for-increase-of-entropy_count-because-of-signed-conversion.patch create mode 100644 queue-3.15/revert-drm-i915-reverse-dp-link-param-selection-prefer-fast-over-wide-again.patch create mode 100644 queue-3.15/ring-buffer-fix-polling-on-trace_pipe.patch create mode 100644 queue-3.15/x86-tsc-fix-cpufreq-lockup.patch diff --git a/queue-3.15/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch b/queue-3.15/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch new file mode 100644 index 00000000000..484e46fc098 --- /dev/null +++ b/queue-3.15/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch @@ -0,0 +1,77 @@ +From 16927776ae757d0d132bdbfabbfe2c498342bd59 Mon Sep 17 00:00:00 2001 +From: John Stultz +Date: Mon, 7 Jul 2014 14:06:11 -0700 +Subject: alarmtimer: Fix bug where relative alarm timers were treated as absolute + +From: John Stultz + +commit 16927776ae757d0d132bdbfabbfe2c498342bd59 upstream. + +Sharvil noticed with the posix timer_settime interface, using the +CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users +tried to specify a relative time timer, it would incorrectly be +treated as absolute regardless of the state of the flags argument. + +This patch corrects this, properly checking the absolute/relative flag, +as well as adds further error checking that no invalid flag bits are set. + +Reported-by: Sharvil Nanavati +Signed-off-by: John Stultz +Cc: Thomas Gleixner +Cc: Ingo Molnar +Cc: Prarit Bhargava +Cc: Sharvil Nanavati +Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.org +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/time/alarmtimer.c | 20 ++++++++++++++++++-- + 1 file changed, 18 insertions(+), 2 deletions(-) + +--- a/kernel/time/alarmtimer.c ++++ b/kernel/time/alarmtimer.c +@@ -585,9 +585,14 @@ static int alarm_timer_set(struct k_itim + struct itimerspec *new_setting, + struct itimerspec *old_setting) + { ++ ktime_t exp; ++ + if (!rtcdev) + return -ENOTSUPP; + ++ if (flags & ~TIMER_ABSTIME) ++ return -EINVAL; ++ + if (old_setting) + alarm_timer_get(timr, old_setting); + +@@ -597,8 +602,16 @@ static int alarm_timer_set(struct k_itim + + /* start the timer */ + timr->it.alarm.interval = timespec_to_ktime(new_setting->it_interval); +- alarm_start(&timr->it.alarm.alarmtimer, +- timespec_to_ktime(new_setting->it_value)); ++ exp = timespec_to_ktime(new_setting->it_value); ++ /* Convert (if necessary) to absolute time */ ++ if (flags != TIMER_ABSTIME) { ++ ktime_t now; ++ ++ now = alarm_bases[timr->it.alarm.alarmtimer.type].gettime(); ++ exp = ktime_add(now, exp); ++ } ++ ++ alarm_start(&timr->it.alarm.alarmtimer, exp); + return 0; + } + +@@ -730,6 +743,9 @@ static int alarm_timer_nsleep(const cloc + if (!alarmtimer_get_rtcdev()) + return -ENOTSUPP; + ++ if (flags & ~TIMER_ABSTIME) ++ return -EINVAL; ++ + if (!capable(CAP_WAKE_ALARM)) + return -EPERM; + diff --git a/queue-3.15/cpufreq-move-policy-kobj-to-policy-cpu-at-resume.patch b/queue-3.15/cpufreq-move-policy-kobj-to-policy-cpu-at-resume.patch new file mode 100644 index 00000000000..1562728e9f6 --- /dev/null +++ b/queue-3.15/cpufreq-move-policy-kobj-to-policy-cpu-at-resume.patch @@ -0,0 +1,61 @@ +From 92c14bd9477a20a83144f08c0ca25b0308bf0730 Mon Sep 17 00:00:00 2001 +From: Viresh Kumar +Date: Thu, 17 Jul 2014 10:48:25 +0530 +Subject: cpufreq: move policy kobj to policy->cpu at resume + +From: Viresh Kumar + +commit 92c14bd9477a20a83144f08c0ca25b0308bf0730 upstream. + +This is only relevant to implementations with multiple clusters, where clusters +have separate clock lines but all CPUs within a cluster share it. + +Consider a dual cluster platform with 2 cores per cluster. During suspend we +start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj +would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its +kobj as we want to retain permissions/values/etc. + +Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev(). +We will recover the old policy and update policy->cpu from 3 to 2 from +update_policy_cpu(). + +But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a +link for CPU2, but would try that for CPU3 while bringing it online. Which will +report errors as CPU3 already has kobj assigned to it. + +This bug got introduced with commit 42f921a, which overlooked this scenario. + +To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a +cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here +only for the first CPU of a non-boot cluster. And we can't recover from this +situation, if kobject_move() fails. + +Fixes: 42f921a6f10c (cpufreq: remove sysfs files for CPUs which failed to come back after resume) +Reported-and-tested-by: Bu Yitian +Reported-by: Saravana Kannan +Reviewed-by: Srivatsa S. Bhat +Signed-off-by: Viresh Kumar +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/cpufreq/cpufreq.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/cpufreq/cpufreq.c ++++ b/drivers/cpufreq/cpufreq.c +@@ -1139,10 +1139,12 @@ static int __cpufreq_add_dev(struct devi + * the creation of a brand new one. So we need to perform this update + * by invoking update_policy_cpu(). + */ +- if (recover_policy && cpu != policy->cpu) ++ if (recover_policy && cpu != policy->cpu) { + update_policy_cpu(policy, cpu); +- else ++ WARN_ON(kobject_move(&policy->kobj, &dev->kobj)); ++ } else { + policy->cpu = cpu; ++ } + + cpumask_copy(policy->cpus, cpumask_of(cpu)); + diff --git a/queue-3.15/drm-qxl-return-irq_none-if-it-was-not-our-irq.patch b/queue-3.15/drm-qxl-return-irq_none-if-it-was-not-our-irq.patch new file mode 100644 index 00000000000..814cb10ba59 --- /dev/null +++ b/queue-3.15/drm-qxl-return-irq_none-if-it-was-not-our-irq.patch @@ -0,0 +1,37 @@ +From fbb60fe35ad579b511de8604b06a30b43846473b Mon Sep 17 00:00:00 2001 +From: Jason Wang +Date: Mon, 12 May 2014 16:35:39 +0800 +Subject: drm/qxl: return IRQ_NONE if it was not our irq + +From: Jason Wang + +commit fbb60fe35ad579b511de8604b06a30b43846473b upstream. + +Return IRQ_NONE if it was not our irq. This is necessary for the case +when qxl is sharing irq line with a device A in a crash kernel. If qxl +is initialized before A and A's irq was raised during this gap, +returning IRQ_HANDLED in this case will cause this irq to be raised +again after EOI since kernel think it was handled but in fact it was +not. + +Cc: Gerd Hoffmann +Signed-off-by: Jason Wang +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/qxl/qxl_irq.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/qxl/qxl_irq.c ++++ b/drivers/gpu/drm/qxl/qxl_irq.c +@@ -33,6 +33,9 @@ irqreturn_t qxl_irq_handler(int irq, voi + + pending = xchg(&qdev->ram_header->int_pending, 0); + ++ if (!pending) ++ return IRQ_NONE; ++ + atomic_inc(&qdev->irq_received); + + if (pending & QXL_INTERRUPT_DISPLAY) { diff --git a/queue-3.15/drm-radeon-avoid-leaking-edid-data.patch b/queue-3.15/drm-radeon-avoid-leaking-edid-data.patch new file mode 100644 index 00000000000..d071f6b12a1 --- /dev/null +++ b/queue-3.15/drm-radeon-avoid-leaking-edid-data.patch @@ -0,0 +1,42 @@ +From 0ac66effe7fcdee55bda6d5d10d3372c95a41920 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 14 Jul 2014 17:57:19 -0400 +Subject: drm/radeon: avoid leaking edid data + +From: Alex Deucher + +commit 0ac66effe7fcdee55bda6d5d10d3372c95a41920 upstream. + +In some cases we fetch the edid in the detect() callback +in order to determine what sort of monitor is connected. +If that happens, don't fetch the edid again in the get_modes() +callback or we will leak the edid. + +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_display.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpu/drm/radeon/radeon_display.c ++++ b/drivers/gpu/drm/radeon/radeon_display.c +@@ -757,6 +757,10 @@ int radeon_ddc_get_modes(struct radeon_c + struct radeon_device *rdev = dev->dev_private; + int ret = 0; + ++ /* don't leak the edid if we already fetched it in detect() */ ++ if (radeon_connector->edid) ++ goto got_edid; ++ + /* on hw with routers, select right port */ + if (radeon_connector->router.ddc_valid) + radeon_router_select_ddc_port(radeon_connector); +@@ -795,6 +799,7 @@ int radeon_ddc_get_modes(struct radeon_c + radeon_connector->edid = radeon_bios_get_hardcoded_edid(rdev); + } + if (radeon_connector->edid) { ++got_edid: + drm_mode_connector_update_edid_property(&radeon_connector->base, radeon_connector->edid); + ret = drm_add_edid_modes(&radeon_connector->base, radeon_connector->edid); + drm_edid_to_eld(&radeon_connector->base, radeon_connector->edid); diff --git a/queue-3.15/drm-radeon-set-default-bl-level-to-something-reasonable.patch b/queue-3.15/drm-radeon-set-default-bl-level-to-something-reasonable.patch new file mode 100644 index 00000000000..0b725d0c27c --- /dev/null +++ b/queue-3.15/drm-radeon-set-default-bl-level-to-something-reasonable.patch @@ -0,0 +1,57 @@ +From 201bb62402e0227375c655446ea04fcd0acf7287 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 15 Jul 2014 09:48:53 -0400 +Subject: drm/radeon: set default bl level to something reasonable + +From: Alex Deucher + +commit 201bb62402e0227375c655446ea04fcd0acf7287 upstream. + +If the value in the scratch register is 0, set it to the +max level. This fixes an issue where the console fb blanking +code calls back into the backlight driver on unblank and then +sets the backlight level to 0 after the driver has already +set the mode and enabled the backlight. + +bugs: +https://bugs.freedesktop.org/show_bug.cgi?id=81382 +https://bugs.freedesktop.org/show_bug.cgi?id=70207 + +Signed-off-by: Alex Deucher +Tested-by: David Heidelberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/atombios_encoders.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/radeon/atombios_encoders.c ++++ b/drivers/gpu/drm/radeon/atombios_encoders.c +@@ -183,7 +183,6 @@ void radeon_atom_backlight_init(struct r + struct backlight_properties props; + struct radeon_backlight_privdata *pdata; + struct radeon_encoder_atom_dig *dig; +- u8 backlight_level; + char bl_name[16]; + + /* Mac laptops with multiple GPUs use the gmux driver for backlight +@@ -222,12 +221,17 @@ void radeon_atom_backlight_init(struct r + + pdata->encoder = radeon_encoder; + +- backlight_level = radeon_atom_get_backlight_level_from_reg(rdev); +- + dig = radeon_encoder->enc_priv; + dig->bl_dev = bd; + + bd->props.brightness = radeon_atom_backlight_get_brightness(bd); ++ /* Set a reasonable default here if the level is 0 otherwise ++ * fbdev will attempt to turn the backlight on after console ++ * unblanking and it will try and restore 0 which turns the backlight ++ * off again. ++ */ ++ if (bd->props.brightness == 0) ++ bd->props.brightness = RADEON_MAX_BL_LEVEL; + bd->props.power = FB_BLANK_UNBLANK; + backlight_update_status(bd); + diff --git a/queue-3.15/hwrng-fetch-randomness-only-after-device-init.patch b/queue-3.15/hwrng-fetch-randomness-only-after-device-init.patch new file mode 100644 index 00000000000..9ed64475f2f --- /dev/null +++ b/queue-3.15/hwrng-fetch-randomness-only-after-device-init.patch @@ -0,0 +1,101 @@ +From d3cc7996473a7bdd33256029988ea690754e4e2a Mon Sep 17 00:00:00 2001 +From: Amit Shah +Date: Thu, 10 Jul 2014 15:42:34 +0530 +Subject: hwrng: fetch randomness only after device init + +From: Amit Shah + +commit d3cc7996473a7bdd33256029988ea690754e4e2a upstream. + +Commit d9e7972619334 "hwrng: add randomness to system from rng sources" +added a call to rng_get_data() from the hwrng_register() function. +However, some rng devices need initialization before data can be read +from them. + +This commit makes the call to rng_get_data() depend on no init fn +pointer being registered by the device. If an init function is +registered, this call is made after device init. + +CC: Kees Cook +CC: Jason Cooper +CC: Herbert Xu +Signed-off-by: Amit Shah +Reviewed-by: Jason Cooper +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/hw_random/core.c | 41 +++++++++++++++++++++++++++++++++-------- + 1 file changed, 33 insertions(+), 8 deletions(-) + +--- a/drivers/char/hw_random/core.c ++++ b/drivers/char/hw_random/core.c +@@ -55,16 +55,35 @@ static DEFINE_MUTEX(rng_mutex); + static int data_avail; + static u8 *rng_buffer; + ++static inline int rng_get_data(struct hwrng *rng, u8 *buffer, size_t size, ++ int wait); ++ + static size_t rng_buffer_size(void) + { + return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES; + } + ++static void add_early_randomness(struct hwrng *rng) ++{ ++ unsigned char bytes[16]; ++ int bytes_read; ++ ++ bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); ++ if (bytes_read > 0) ++ add_device_randomness(bytes, bytes_read); ++} ++ + static inline int hwrng_init(struct hwrng *rng) + { +- if (!rng->init) +- return 0; +- return rng->init(rng); ++ if (rng->init) { ++ int ret; ++ ++ ret = rng->init(rng); ++ if (ret) ++ return ret; ++ } ++ add_early_randomness(rng); ++ return 0; + } + + static inline void hwrng_cleanup(struct hwrng *rng) +@@ -304,8 +323,6 @@ int hwrng_register(struct hwrng *rng) + { + int err = -EINVAL; + struct hwrng *old_rng, *tmp; +- unsigned char bytes[16]; +- int bytes_read; + + if (rng->name == NULL || + (rng->data_read == NULL && rng->read == NULL)) +@@ -347,9 +364,17 @@ int hwrng_register(struct hwrng *rng) + INIT_LIST_HEAD(&rng->list); + list_add_tail(&rng->list, &rng_list); + +- bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); +- if (bytes_read > 0) +- add_device_randomness(bytes, bytes_read); ++ if (old_rng && !rng->init) { ++ /* ++ * Use a new device's input to add some randomness to ++ * the system. If this rng device isn't going to be ++ * used right away, its init function hasn't been ++ * called yet; so only use the randomness from devices ++ * that don't need an init callback. ++ */ ++ add_early_randomness(rng); ++ } ++ + out_unlock: + mutex_unlock(&rng_mutex); + out: diff --git a/queue-3.15/irqchip-gic-add-binding-probe-for-arm-gic400.patch b/queue-3.15/irqchip-gic-add-binding-probe-for-arm-gic400.patch new file mode 100644 index 00000000000..5debd03f79f --- /dev/null +++ b/queue-3.15/irqchip-gic-add-binding-probe-for-arm-gic400.patch @@ -0,0 +1,40 @@ +From 144cb08864ed44be52d8634ac69cd98e5efcf527 Mon Sep 17 00:00:00 2001 +From: Suravee Suthikulpanit +Date: Tue, 15 Jul 2014 00:03:03 +0200 +Subject: irqchip: gic: Add binding probe for ARM GIC400 + +From: Suravee Suthikulpanit + +commit 144cb08864ed44be52d8634ac69cd98e5efcf527 upstream. + +Commit 3ab72f9156bb "dt-bindings: add GIC-400 binding" added the +"arm,gic-400" compatible string, but the corresponding IRQCHIP_DECLARE +was never added to the gic driver. + +Therefore add the missing irqchip declaration for it. + +Signed-off-by: Suravee Suthikulpanit +Signed-off-by: Greg Kroah-Hartman + +Removed additional empty line and adapted commit message to mark it +as fixing an issue. +Signed-off-by: Heiko Stuebner +Acked-by: Will Deacon +Fixes: 3ab72f9156bb ("dt-bindings: add GIC-400 binding") +Link: https://lkml.kernel.org/r/2621565.f5eISveXXJ@diego +Signed-off-by: Jason Cooper + +--- + drivers/irqchip/irq-gic.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/irqchip/irq-gic.c ++++ b/drivers/irqchip/irq-gic.c +@@ -1071,6 +1071,7 @@ gic_of_init(struct device_node *node, st + gic_cnt++; + return 0; + } ++IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init); + IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init); + IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init); + IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init); diff --git a/queue-3.15/irqchip-gic-add-support-for-cortex-a7-compatible-string.patch b/queue-3.15/irqchip-gic-add-support-for-cortex-a7-compatible-string.patch new file mode 100644 index 00000000000..b3c09871017 --- /dev/null +++ b/queue-3.15/irqchip-gic-add-support-for-cortex-a7-compatible-string.patch @@ -0,0 +1,35 @@ +From a97e8027b1d28eafe6bafe062556c1ec926a49c6 Mon Sep 17 00:00:00 2001 +From: Matthias Brugger +Date: Thu, 3 Jul 2014 13:58:52 +0200 +Subject: irqchip: gic: Add support for cortex a7 compatible string + +From: Matthias Brugger + +commit a97e8027b1d28eafe6bafe062556c1ec926a49c6 upstream. + +Patch 0a68214b "ARM: DT: Add binding for GIC virtualization extentions (VGIC)" added +the "arm,cortex-a7-gic" compatible string, but the corresponding IRQCHIP_DECLARE +was never added to the gic driver. + +To let real Cortex-A7 SoCs use it, add the necessary declaration to the device driver. + +Signed-off-by: Matthias Brugger +Link: https://lkml.kernel.org/r/1404388732-28890-1-git-send-email-matthias.bgg@gmail.com +Fixes: 0a68214b76ca ("ARM: DT: Add binding for GIC virtualization extentions (VGIC)") +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-gic.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/irqchip/irq-gic.c ++++ b/drivers/irqchip/irq-gic.c +@@ -1073,6 +1073,7 @@ gic_of_init(struct device_node *node, st + } + IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init); + IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init); ++IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init); + IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init); + IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init); + diff --git a/queue-3.15/irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch b/queue-3.15/irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch new file mode 100644 index 00000000000..2a87983e512 --- /dev/null +++ b/queue-3.15/irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch @@ -0,0 +1,58 @@ +From 29e697b11853d3f83b1864ae385abdad4aa2c361 Mon Sep 17 00:00:00 2001 +From: Tomasz Figa +Date: Thu, 17 Jul 2014 17:23:44 +0200 +Subject: irqchip: gic: Fix core ID calculation when topology is read from DT + +From: Tomasz Figa + +commit 29e697b11853d3f83b1864ae385abdad4aa2c361 upstream. + +Certain GIC implementation, namely those found on earlier, single +cluster, Exynos SoCs, have registers mapped without per-CPU banking, +which means that the driver needs to use different offset for each CPU. + +Currently the driver calculates the offset by multiplying value returned +by cpu_logical_map() by CPU offset parsed from DT. This is correct when +CPU topology is not specified in DT and aforementioned function returns +core ID alone. However when DT contains CPU topology, the function +changes to return cluster ID as well, which is non-zero on mentioned +SoCs and so breaks the calculation in GIC driver. + +This patch fixes this by masking out cluster ID in CPU offset +calculation so that only core ID is considered. Multi-cluster Exynos +SoCs already have banked GIC implementations, so this simple fix should +be enough. + +Reported-by: Lorenzo Pieralisi +Reported-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Tomasz Figa +Fixes: db0d4db22a78d ("ARM: gic: allow GIC to support non-banked setups") +Link: https://lkml.kernel.org/r/1405610624-18722-1-git-send-email-t.figa@samsung.com +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-gic.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/irqchip/irq-gic.c ++++ b/drivers/irqchip/irq-gic.c +@@ -42,6 +42,7 @@ + #include + #include + ++#include + #include + #include + #include +@@ -954,7 +955,9 @@ void __init gic_init_bases(unsigned int + } + + for_each_possible_cpu(cpu) { +- unsigned long offset = percpu_offset * cpu_logical_map(cpu); ++ u32 mpidr = cpu_logical_map(cpu); ++ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0); ++ unsigned long offset = percpu_offset * core_id; + *per_cpu_ptr(gic->dist_base.percpu_base, cpu) = dist_base + offset; + *per_cpu_ptr(gic->cpu_base.percpu_base, cpu) = cpu_base + offset; + } diff --git a/queue-3.15/mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch b/queue-3.15/mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch new file mode 100644 index 00000000000..e68bcfa98ec --- /dev/null +++ b/queue-3.15/mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch @@ -0,0 +1,39 @@ +From 6938ad40cb97a52d88a763008935340729a4acc7 Mon Sep 17 00:00:00 2001 +From: Ted Juan +Date: Fri, 20 Jun 2014 17:32:05 +0800 +Subject: mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions + +From: Ted Juan + +commit 6938ad40cb97a52d88a763008935340729a4acc7 upstream. + +These two function's switch case lack the 'break' that make them always +return error. + +Signed-off-by: Ted Juan +Acked-by: Pekon Gupta +Signed-off-by: Brian Norris +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/devices/elm.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/mtd/devices/elm.c ++++ b/drivers/mtd/devices/elm.c +@@ -445,6 +445,7 @@ static int elm_context_save(struct elm_i + ELM_SYNDROME_FRAGMENT_1 + offset); + regs->elm_syndrome_fragment_0[i] = elm_read_reg(info, + ELM_SYNDROME_FRAGMENT_0 + offset); ++ break; + default: + return -EINVAL; + } +@@ -483,6 +484,7 @@ static int elm_context_restore(struct el + regs->elm_syndrome_fragment_1[i]); + elm_write_reg(info, ELM_SYNDROME_FRAGMENT_0 + offset, + regs->elm_syndrome_fragment_0[i]); ++ break; + default: + return -EINVAL; + } diff --git a/queue-3.15/mwifiex-fix-tx-timeout-issue.patch b/queue-3.15/mwifiex-fix-tx-timeout-issue.patch new file mode 100644 index 00000000000..2d54de46a2c --- /dev/null +++ b/queue-3.15/mwifiex-fix-tx-timeout-issue.patch @@ -0,0 +1,49 @@ +From d76744a93246eccdca1106037e8ee29debf48277 Mon Sep 17 00:00:00 2001 +From: Amitkumar Karwar +Date: Fri, 20 Jun 2014 11:45:25 -0700 +Subject: mwifiex: fix Tx timeout issue + +From: Amitkumar Karwar + +commit d76744a93246eccdca1106037e8ee29debf48277 upstream. + +https://bugzilla.kernel.org/show_bug.cgi?id=70191 +https://bugzilla.kernel.org/show_bug.cgi?id=77581 + +It is observed that sometimes Tx packet is downloaded without +adding driver's txpd header. This results in firmware parsing +garbage data as packet length. Sometimes firmware is unable +to read the packet if length comes out as invalid. This stops +further traffic and timeout occurs. + +The root cause is uninitialized fields in tx_info(skb->cb) of +packet used to get garbage values. In this case if +MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd +header was skipped. This patch makes sure that tx_info is +correctly initialized to fix the problem. + +Reported-by: Andrew Wiley +Reported-by: Linus Gasser +Reported-by: Michael Hirsch +Tested-by: Xinming Hu +Signed-off-by: Amitkumar Karwar +Signed-off-by: Maithili Hinge +Signed-off-by: Avinash Patil +Signed-off-by: Bing Zhao +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/mwifiex/main.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/wireless/mwifiex/main.c ++++ b/drivers/net/wireless/mwifiex/main.c +@@ -647,6 +647,7 @@ mwifiex_hard_start_xmit(struct sk_buff * + } + + tx_info = MWIFIEX_SKB_TXCB(skb); ++ memset(tx_info, 0, sizeof(*tx_info)); + tx_info->bss_num = priv->bss_num; + tx_info->bss_type = priv->bss_type; + tx_info->pkt_len = skb->len; diff --git a/queue-3.15/perf-do-not-allow-optimized-switch-for-non-cloned-events.patch b/queue-3.15/perf-do-not-allow-optimized-switch-for-non-cloned-events.patch new file mode 100644 index 00000000000..5151e041fde --- /dev/null +++ b/queue-3.15/perf-do-not-allow-optimized-switch-for-non-cloned-events.patch @@ -0,0 +1,50 @@ +From 1f9a7268c67f0290837aada443d28fd953ddca90 Mon Sep 17 00:00:00 2001 +From: Jiri Olsa +Date: Tue, 24 Jun 2014 10:20:25 +0200 +Subject: perf: Do not allow optimized switch for non-cloned events + +From: Jiri Olsa + +commit 1f9a7268c67f0290837aada443d28fd953ddca90 upstream. + +The context check in perf_event_context_sched_out allows +non-cloned context to be part of the optimized schedule +out switch. + +This could move non-cloned context into another workload +child. Once this child exits, the context is closed and +leaves all original (parent) events in closed state. + +Any other new cloned event will have closed state and not +measure anything. And probably causing other odd bugs. + +Signed-off-by: Jiri Olsa +Signed-off-by: Peter Zijlstra +Cc: Arnaldo Carvalho de Melo +Cc: Paul Mackerras +Cc: Frederic Weisbecker +Cc: Namhyung Kim +Cc: Paul Mackerras +Cc: Corey Ashford +Cc: David Ahern +Cc: Jiri Olsa +Cc: Linus Torvalds +Link: http://lkml.kernel.org/r/1403598026-2310-2-git-send-email-jolsa@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/events/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -2315,7 +2315,7 @@ static void perf_event_context_sched_out + next_parent = rcu_dereference(next_ctx->parent_ctx); + + /* If neither context have a parent context; they cannot be clones. */ +- if (!parent && !next_parent) ++ if (!parent || !next_parent) + goto unlock; + + if (next_parent == ctx || next_ctx == parent || next_parent == parent) { diff --git a/queue-3.15/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch b/queue-3.15/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch new file mode 100644 index 00000000000..a6e4e8f8958 --- /dev/null +++ b/queue-3.15/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch @@ -0,0 +1,104 @@ +From b292d7a10487aee6e74b1c18b8d95b92f40d4a4f Mon Sep 17 00:00:00 2001 +From: HATAYAMA Daisuke +Date: Wed, 25 Jun 2014 10:09:07 +0900 +Subject: perf/x86/intel: ignore CondChgd bit to avoid false NMI handling +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: HATAYAMA Daisuke + +commit b292d7a10487aee6e74b1c18b8d95b92f40d4a4f upstream. + +Currently, any NMI is falsely handled by a NMI handler of NMI watchdog +if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set. + +For example, we use external NMI to make system panic to get crash +dump, but in this case, the external NMI is falsely handled do to the +issue. + +This commit deals with the issue simply by ignoring CondChgd bit. + +Here is explanation in detail. + +On x86 NMI watchdog uses performance monitoring feature to +periodically signal NMI each time performance counter gets overflowed. + +intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI +handler of NMI watchdog, perf_event_nmi_handler(). It identifies an +owner of a given NMI by looking at overflow status bits in +MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it +handles the given NMI as its own NMI. + +The problem is that the intel_pmu_handle_irq() doesn't distinguish +CondChgd bit from other bits. Unlike the other status bits, CondChgd +bit doesn't represent overflow status for performance counters. Thus, +CondChgd bit cannot be thought of as a mark indicating a given NMI is +NMI watchdog's. + +As a result, if CondChgd bit is set, any NMI is falsely handled by the +NMI handler of NMI watchdog. Also, if type of the falsely handled NMI +is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding +action is never performed until CondChgd bit is cleared. + +I noticed this behavior on systems with Ivy Bridge processors: Intel +Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems, +CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set +in the beginning at boot. Then the CondChgd bit is immediately cleared +by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain +0. + +On the other hand, on older processors such as Nehalem, Xeon E7540, +CondChgd bit is not set in the beginning at boot. + +I'm not sure about exact behavior of CondChgd bit, in particular when +this bit is set. Although I read Intel System Programmer's Manual to +figure out that, the descriptions I found are: + + In 18.9.1: + + "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to + indicate changes to the state of performancmonitoring hardware" + + In Table 35-2 IA-32 Architectural MSRs + + 63 CondChg: status bits of this register has changed. + +These are different from the bahviour I see on the actual system as I +explained above. + +At least, I think ignoring CondChgd bit should be enough for NMI +watchdog perspective. + +Signed-off-by: HATAYAMA Daisuke +Acked-by: Don Zickus +Signed-off-by: Peter Zijlstra +Cc: Arnaldo Carvalho de Melo +Cc: Linus Torvalds +Cc: linux-kernel@vger.kernel.org +Link: http://lkml.kernel.org/r/20140625.103503.409316067.d.hatayama@jp.fujitsu.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/perf_event_intel.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/arch/x86/kernel/cpu/perf_event_intel.c ++++ b/arch/x86/kernel/cpu/perf_event_intel.c +@@ -1382,6 +1382,15 @@ again: + intel_pmu_lbr_read(); + + /* ++ * CondChgd bit 63 doesn't mean any overflow status. Ignore ++ * and clear the bit. ++ */ ++ if (__test_and_clear_bit(63, (unsigned long *)&status)) { ++ if (!status) ++ goto done; ++ } ++ ++ /* + * PEBS overflow sets bit 62 in the global status register + */ + if (__test_and_clear_bit(62, (unsigned long *)&status)) { diff --git a/queue-3.15/random-check-for-increase-of-entropy_count-because-of-signed-conversion.patch b/queue-3.15/random-check-for-increase-of-entropy_count-because-of-signed-conversion.patch new file mode 100644 index 00000000000..5888730472d --- /dev/null +++ b/queue-3.15/random-check-for-increase-of-entropy_count-because-of-signed-conversion.patch @@ -0,0 +1,75 @@ +From 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc Mon Sep 17 00:00:00 2001 +From: Hannes Frederic Sowa +Date: Fri, 18 Jul 2014 17:26:41 -0400 +Subject: random: check for increase of entropy_count because of signed conversion + +From: Hannes Frederic Sowa + +commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc upstream. + +The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could +actually increase entropy_count if during assignment of the unsigned +expression on the RHS (mind the -=) we reduce the value modulo +2^width(int) and assign it to entropy_count. Trinity found this. + +[ Commit modified by tytso to add an additional safety check for a + negative entropy_count -- which should never happen, and to also add + an additional paranoia check to prevent overly large count values to + be passed into urandom_read(). ] + +Reported-by: Dave Jones +Signed-off-by: Hannes Frederic Sowa +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/random.c | 17 ++++++++++++++--- + 1 file changed, 14 insertions(+), 3 deletions(-) + +--- a/drivers/char/random.c ++++ b/drivers/char/random.c +@@ -641,7 +641,7 @@ retry: + } while (unlikely(entropy_count < pool_size-2 && pnfrac)); + } + +- if (entropy_count < 0) { ++ if (unlikely(entropy_count < 0)) { + pr_warn("random: negative entropy/overflow: pool %s count %d\n", + r->name, entropy_count); + WARN_ON(1); +@@ -980,7 +980,7 @@ static size_t account(struct entropy_sto + int reserved) + { + int entropy_count, orig; +- size_t ibytes; ++ size_t ibytes, nfrac; + + BUG_ON(r->entropy_count > r->poolinfo->poolfracbits); + +@@ -998,7 +998,17 @@ retry: + } + if (ibytes < min) + ibytes = 0; +- if ((entropy_count -= ibytes << (ENTROPY_SHIFT + 3)) < 0) ++ ++ if (unlikely(entropy_count < 0)) { ++ pr_warn("random: negative entropy count: pool %s count %d\n", ++ r->name, entropy_count); ++ WARN_ON(1); ++ entropy_count = 0; ++ } ++ nfrac = ibytes << (ENTROPY_SHIFT + 3); ++ if ((size_t) entropy_count > nfrac) ++ entropy_count -= nfrac; ++ else + entropy_count = 0; + + if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig) +@@ -1375,6 +1385,7 @@ urandom_read(struct file *file, char __u + "with %d bits of entropy available\n", + current->comm, nonblocking_pool.entropy_total); + ++ nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3)); + ret = extract_entropy_user(&nonblocking_pool, buf, nbytes); + + trace_urandom_read(8 * nbytes, ENTROPY_BITS(&nonblocking_pool), diff --git a/queue-3.15/revert-drm-i915-reverse-dp-link-param-selection-prefer-fast-over-wide-again.patch b/queue-3.15/revert-drm-i915-reverse-dp-link-param-selection-prefer-fast-over-wide-again.patch new file mode 100644 index 00000000000..c39182105cc --- /dev/null +++ b/queue-3.15/revert-drm-i915-reverse-dp-link-param-selection-prefer-fast-over-wide-again.patch @@ -0,0 +1,40 @@ +From c6930992948adf0f8fc1f6ff1da51c5002a2cf95 Mon Sep 17 00:00:00 2001 +From: Dave Airlie +Date: Mon, 14 Jul 2014 11:04:39 +1000 +Subject: Revert "drm/i915: reverse dp link param selection, prefer fast over wide again" + +From: Dave Airlie + +commit c6930992948adf0f8fc1f6ff1da51c5002a2cf95 upstream. + +This reverts commit 38aecea0ccbb909d635619cba22f1891e589b434. + +This breaks Haswell Thinkpad + Lenovo dock in SST mode with a HDMI monitor attached. + +Before this we can 1920x1200 mode, after this we only ever get 1024x768, and +a lot of deferring. + +This didn't revert clean, but this should be fine. + +bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1117008 +Signed-off-by: Dave Airlie +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_dp.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_dp.c ++++ b/drivers/gpu/drm/i915/intel_dp.c +@@ -833,8 +833,8 @@ intel_dp_compute_config(struct intel_enc + mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, + bpp); + +- for (lane_count = min_lane_count; lane_count <= max_lane_count; lane_count <<= 1) { +- for (clock = min_clock; clock <= max_clock; clock++) { ++ for (clock = min_clock; clock <= max_clock; clock++) { ++ for (lane_count = min_lane_count; lane_count <= max_lane_count; lane_count <<= 1) { + link_clock = drm_dp_bw_code_to_link_rate(bws[clock]); + link_avail = intel_dp_max_data_rate(link_clock, + lane_count); diff --git a/queue-3.15/ring-buffer-fix-polling-on-trace_pipe.patch b/queue-3.15/ring-buffer-fix-polling-on-trace_pipe.patch new file mode 100644 index 00000000000..b9dfab3cf44 --- /dev/null +++ b/queue-3.15/ring-buffer-fix-polling-on-trace_pipe.patch @@ -0,0 +1,59 @@ +From 97b8ee845393701edc06e27ccec2876ff9596019 Mon Sep 17 00:00:00 2001 +From: Martin Lau +Date: Mon, 9 Jun 2014 23:06:42 -0700 +Subject: ring-buffer: Fix polling on trace_pipe + +From: Martin Lau + +commit 97b8ee845393701edc06e27ccec2876ff9596019 upstream. + +ring_buffer_poll_wait() should always put the poll_table to its wait_queue +even there is immediate data available. Otherwise, the following epoll and +read sequence will eventually hang forever: + +1. Put some data to make the trace_pipe ring_buffer read ready first +2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee) +3. epoll_wait() +4. read(trace_pipe_fd) till EAGAIN +5. Add some more data to the trace_pipe ring_buffer +6. epoll_wait() -> this epoll_wait() will block forever + +~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2, + ring_buffer_poll_wait() returns immediately without adding poll_table, + which has poll_table->_qproc pointing to ep_poll_callback(), to its + wait_queue. +~ During the epoll_wait() call in step 3 and step 6, + ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue + because the poll_table->_qproc is NULL and it is how epoll works. +~ When there is new data available in step 6, ring_buffer does not know + it has to call ep_poll_callback() because it is not in its wait queue. + Hence, block forever. + +Other poll implementation seems to call poll_wait() unconditionally as the very +first thing to do. For example, tcp_poll() in tcp.c. + +Link: http://lkml.kernel.org/p/20140610060637.GA14045@devbig242.prn2.facebook.com + +Fixes: 2a2cc8f7c4d0 "ftrace: allow the event pipe to be polled" +Reviewed-by: Chris Mason +Signed-off-by: Martin Lau +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/ring_buffer.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -616,10 +616,6 @@ int ring_buffer_poll_wait(struct ring_bu + struct ring_buffer_per_cpu *cpu_buffer; + struct rb_irq_work *work; + +- if ((cpu == RING_BUFFER_ALL_CPUS && !ring_buffer_empty(buffer)) || +- (cpu != RING_BUFFER_ALL_CPUS && !ring_buffer_empty_cpu(buffer, cpu))) +- return POLLIN | POLLRDNORM; +- + if (cpu == RING_BUFFER_ALL_CPUS) + work = &buffer->irq_work; + else { diff --git a/queue-3.15/series b/queue-3.15/series index 0ab1c979e4d..91aabcbb1fe 100644 --- a/queue-3.15/series +++ b/queue-3.15/series @@ -76,3 +76,20 @@ xen-netback-fix-handling-frag_list-on-grant-op-error-path.patch xen-netback-fix-releasing-frag_list-skbs-in-error-path.patch xen-netback-fix-releasing-header-slot-on-error-path.patch xen-netback-fix-pointer-incrementation-to-avoid-incorrect-logging.patch +perf-do-not-allow-optimized-switch-for-non-cloned-events.patch +perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch +mwifiex-fix-tx-timeout-issue.patch +ring-buffer-fix-polling-on-trace_pipe.patch +irqchip-gic-add-support-for-cortex-a7-compatible-string.patch +irqchip-gic-add-binding-probe-for-arm-gic400.patch +irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch +drm-radeon-set-default-bl-level-to-something-reasonable.patch +drm-qxl-return-irq_none-if-it-was-not-our-irq.patch +drm-radeon-avoid-leaking-edid-data.patch +revert-drm-i915-reverse-dp-link-param-selection-prefer-fast-over-wide-again.patch +alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch +hwrng-fetch-randomness-only-after-device-init.patch +x86-tsc-fix-cpufreq-lockup.patch +cpufreq-move-policy-kobj-to-policy-cpu-at-resume.patch +random-check-for-increase-of-entropy_count-because-of-signed-conversion.patch +mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch diff --git a/queue-3.15/x86-tsc-fix-cpufreq-lockup.patch b/queue-3.15/x86-tsc-fix-cpufreq-lockup.patch new file mode 100644 index 00000000000..7e884b1e734 --- /dev/null +++ b/queue-3.15/x86-tsc-fix-cpufreq-lockup.patch @@ -0,0 +1,56 @@ +From 3896c329df8092661dac80f55a8c3f60136fd61a Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Tue, 24 Jun 2014 14:48:19 +0200 +Subject: x86, tsc: Fix cpufreq lockup + +From: Peter Zijlstra + +commit 3896c329df8092661dac80f55a8c3f60136fd61a upstream. + +Mauro reported that his AMD X2 using the powernow-k8 cpufreq driver +locked up when doing cpu hotplug. + +Because we called set_cyc2ns_scale() from the time_cpufreq_notifier() +unconditionally, it gets called multiple times for each freq change, +instead of only the once, when the tsc_khz value actually changes. + +Because it gets called more than once, we run out of cyc2ns data slots +and stall, waiting for a free one, but because we're half way offline, +there's no consumers to free slots. + +By placing the call inside the condition that actually changes tsc_khz +we avoid superfluous calls and avoid the problem. + +Reported-by: Mauro +Tested-by: Mauro +Fixes: 20d1c86a5776 ("sched/clock, x86: Rewrite cyc2ns() to avoid the need to disable IRQs") +Cc: "Rafael J. Wysocki" +Cc: Viresh Kumar +Cc: Bin Gao +Cc: Linus Torvalds +Cc: Mika Westerberg +Cc: Paul Gortmaker +Cc: Stefani Seibold +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Peter Zijlstra +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/tsc.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/tsc.c ++++ b/arch/x86/kernel/tsc.c +@@ -920,9 +920,9 @@ static int time_cpufreq_notifier(struct + tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new); + if (!(freq->flags & CPUFREQ_CONST_LOOPS)) + mark_tsc_unstable("cpufreq changes"); +- } + +- set_cyc2ns_scale(tsc_khz, freq->cpu); ++ set_cyc2ns_scale(tsc_khz, freq->cpu); ++ } + + return 0; + } -- 2.47.3