--- /dev/null
+From 16927776ae757d0d132bdbfabbfe2c498342bd59 Mon Sep 17 00:00:00 2001
+From: John Stultz <john.stultz@linaro.org>
+Date: Mon, 7 Jul 2014 14:06:11 -0700
+Subject: alarmtimer: Fix bug where relative alarm timers were treated as absolute
+
+From: John Stultz <john.stultz@linaro.org>
+
+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 <sharvil@google.com>
+Signed-off-by: John Stultz <john.stultz@linaro.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Prarit Bhargava <prarit@redhat.com>
+Cc: Sharvil Nanavati <sharvil@google.com>
+Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.org
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From 92c14bd9477a20a83144f08c0ca25b0308bf0730 Mon Sep 17 00:00:00 2001
+From: Viresh Kumar <viresh.kumar@linaro.org>
+Date: Thu, 17 Jul 2014 10:48:25 +0530
+Subject: cpufreq: move policy kobj to policy->cpu at resume
+
+From: Viresh Kumar <viresh.kumar@linaro.org>
+
+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 <ybu@qti.qualcomm.com>
+Reported-by: Saravana Kannan <skannan@codeaurora.org>
+Reviewed-by: Srivatsa S. Bhat <srivatsa@mit.edu>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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));
+
--- /dev/null
+From fbb60fe35ad579b511de8604b06a30b43846473b Mon Sep 17 00:00:00 2001
+From: Jason Wang <jasowang@redhat.com>
+Date: Mon, 12 May 2014 16:35:39 +0800
+Subject: drm/qxl: return IRQ_NONE if it was not our irq
+
+From: Jason Wang <jasowang@redhat.com>
+
+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 <kraxel@redhat.com>
+Signed-off-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 0ac66effe7fcdee55bda6d5d10d3372c95a41920 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 14 Jul 2014 17:57:19 -0400
+Subject: drm/radeon: avoid leaking edid data
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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 <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 201bb62402e0227375c655446ea04fcd0acf7287 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 15 Jul 2014 09:48:53 -0400
+Subject: drm/radeon: set default bl level to something reasonable
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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 <alexander.deucher@amd.com>
+Tested-by: David Heidelberger <david.heidelberger@ixit.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From d3cc7996473a7bdd33256029988ea690754e4e2a Mon Sep 17 00:00:00 2001
+From: Amit Shah <amit.shah@redhat.com>
+Date: Thu, 10 Jul 2014 15:42:34 +0530
+Subject: hwrng: fetch randomness only after device init
+
+From: Amit Shah <amit.shah@redhat.com>
+
+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 <keescook@chromium.org>
+CC: Jason Cooper <jason@lakedaemon.net>
+CC: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Amit Shah <amit.shah@redhat.com>
+Reviewed-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From 144cb08864ed44be52d8634ac69cd98e5efcf527 Mon Sep 17 00:00:00 2001
+From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+Date: Tue, 15 Jul 2014 00:03:03 +0200
+Subject: irqchip: gic: Add binding probe for ARM GIC400
+
+From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+
+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 <Suravee.Suthikulpanit@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+Removed additional empty line and adapted commit message to mark it
+as fixing an issue.
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Acked-by: Will Deacon <will.deacon@arm.com>
+Fixes: 3ab72f9156bb ("dt-bindings: add GIC-400 binding")
+Link: https://lkml.kernel.org/r/2621565.f5eISveXXJ@diego
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+
+---
+ 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);
--- /dev/null
+From a97e8027b1d28eafe6bafe062556c1ec926a49c6 Mon Sep 17 00:00:00 2001
+From: Matthias Brugger <matthias.bgg@gmail.com>
+Date: Thu, 3 Jul 2014 13:58:52 +0200
+Subject: irqchip: gic: Add support for cortex a7 compatible string
+
+From: Matthias Brugger <matthias.bgg@gmail.com>
+
+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 <matthias.bgg@gmail.com>
+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 <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 29e697b11853d3f83b1864ae385abdad4aa2c361 Mon Sep 17 00:00:00 2001
+From: Tomasz Figa <t.figa@samsung.com>
+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 <t.figa@samsung.com>
+
+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 <lorenzo.pieralisi@arm.com>
+Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Tomasz Figa <t.figa@samsung.com>
+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 <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 <linux/irqchip/chained_irq.h>
+ #include <linux/irqchip/arm-gic.h>
+
++#include <asm/cputype.h>
+ #include <asm/irq.h>
+ #include <asm/exception.h>
+ #include <asm/smp_plat.h>
+@@ -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;
+ }
--- /dev/null
+From 6938ad40cb97a52d88a763008935340729a4acc7 Mon Sep 17 00:00:00 2001
+From: Ted Juan <ted.juan@gmail.com>
+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 <ted.juan@gmail.com>
+
+commit 6938ad40cb97a52d88a763008935340729a4acc7 upstream.
+
+These two function's switch case lack the 'break' that make them always
+return error.
+
+Signed-off-by: Ted Juan <ted.juan@gmail.com>
+Acked-by: Pekon Gupta <pekon@ti.com>
+Signed-off-by: Brian Norris <computersforpeace@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From d76744a93246eccdca1106037e8ee29debf48277 Mon Sep 17 00:00:00 2001
+From: Amitkumar Karwar <akarwar@marvell.com>
+Date: Fri, 20 Jun 2014 11:45:25 -0700
+Subject: mwifiex: fix Tx timeout issue
+
+From: Amitkumar Karwar <akarwar@marvell.com>
+
+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 <wiley.andrew.j@gmail.com>
+Reported-by: Linus Gasser <list@markas-al-nour.org>
+Reported-by: Michael Hirsch <hirsch@teufel.de>
+Tested-by: Xinming Hu <huxm@marvell.com>
+Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
+Signed-off-by: Maithili Hinge <maithili@marvell.com>
+Signed-off-by: Avinash Patil <patila@marvell.com>
+Signed-off-by: Bing Zhao <bzhao@marvell.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 1f9a7268c67f0290837aada443d28fd953ddca90 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@redhat.com>
+Date: Tue, 24 Jun 2014 10:20:25 +0200
+Subject: perf: Do not allow optimized switch for non-cloned events
+
+From: Jiri Olsa <jolsa@redhat.com>
+
+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 <jolsa@kernel.org>
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Frederic Weisbecker <fweisbec@gmail.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
+Cc: David Ahern <dsahern@gmail.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Link: http://lkml.kernel.org/r/1403598026-2310-2-git-send-email-jolsa@kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From b292d7a10487aee6e74b1c18b8d95b92f40d4a4f Mon Sep 17 00:00:00 2001
+From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
+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 <d.hatayama@jp.fujitsu.com>
+
+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 <d.hatayama@jp.fujitsu.com>
+Acked-by: Don Zickus <dzickus@redhat.com>
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)) {
--- /dev/null
+From 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc Mon Sep 17 00:00:00 2001
+From: Hannes Frederic Sowa <hannes@stressinduktion.org>
+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 <hannes@stressinduktion.org>
+
+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 <davej@redhat.com>
+Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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),
--- /dev/null
+From c6930992948adf0f8fc1f6ff1da51c5002a2cf95 Mon Sep 17 00:00:00 2001
+From: Dave Airlie <airlied@redhat.com>
+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 <airlied@redhat.com>
+
+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 <airlied@redhat.com>
+Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 97b8ee845393701edc06e27ccec2876ff9596019 Mon Sep 17 00:00:00 2001
+From: Martin Lau <kafai@fb.com>
+Date: Mon, 9 Jun 2014 23:06:42 -0700
+Subject: ring-buffer: Fix polling on trace_pipe
+
+From: Martin Lau <kafai@fb.com>
+
+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 <clm@fb.com>
+Signed-off-by: Martin Lau <kafai@fb.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 {
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
--- /dev/null
+From 3896c329df8092661dac80f55a8c3f60136fd61a Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Tue, 24 Jun 2014 14:48:19 +0200
+Subject: x86, tsc: Fix cpufreq lockup
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+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 <registosites@hotmail.com>
+Tested-by: Mauro <registosites@hotmail.com>
+Fixes: 20d1c86a5776 ("sched/clock, x86: Rewrite cyc2ns() to avoid the need to disable IRQs")
+Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
+Cc: Viresh Kumar <viresh.kumar@linaro.org>
+Cc: Bin Gao <bin.gao@intel.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
+Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
+Cc: Stefani Seibold <stefani@seibold.net>
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
