--- /dev/null
+From 83e92c513be4e0c48cd4f6bc458b01a4bba86ce0 Mon Sep 17 00:00:00 2001
+From: Henrik Rydberg <rydberg@euromail.se>
+Date: Wed, 2 Oct 2013 19:15:03 +0200
+Subject: hwmon: (applesmc) Always read until end of data
+
+From: Henrik Rydberg <rydberg@euromail.se>
+
+commit 25f2bd7f5add608c1d1405938f39c96927b275ca upstream.
+
+The crash reported and investigated in commit 5f4513 turned out to be
+caused by a change to the read interface on newer (2012) SMCs.
+
+Tests by Chris show that simply reading the data valid line is enough
+for the problem to go away. Additional tests show that the newer SMCs
+no longer wait for the number of requested bytes, but start sending
+data right away. Apparently the number of bytes to read is no longer
+specified as before, but instead found out by reading until end of
+data. Failure to read until end of data confuses the state machine,
+which eventually causes the crash.
+
+As a remedy, assuming bit0 is the read valid line, make sure there is
+nothing more to read before leaving the read function.
+
+Tested to resolve the original problem, and runtested on MBA3,1,
+MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on
+machines before 2012.
+
+Tested-by: Chris Murphy <chris@cmurf.com>
+Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+[bwh: Backported to 3.2: adjust context]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/applesmc.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/drivers/hwmon/applesmc.c
++++ b/drivers/hwmon/applesmc.c
+@@ -212,6 +212,7 @@ static int send_argument(const char *key
+
+ static int read_smc(u8 cmd, const char *key, u8 *buffer, u8 len)
+ {
++ u8 status, data = 0;
+ int i;
+
+ if (send_command(cmd) || send_argument(key)) {
+@@ -219,6 +220,7 @@ static int read_smc(u8 cmd, const char *
+ return -EIO;
+ }
+
++ /* This has no effect on newer (2012) SMCs */
+ outb(len, APPLESMC_DATA_PORT);
+
+ for (i = 0; i < len; i++) {
+@@ -229,6 +231,17 @@ static int read_smc(u8 cmd, const char *
+ buffer[i] = inb(APPLESMC_DATA_PORT);
+ }
+
++ /* Read the data port until bit0 is cleared */
++ for (i = 0; i < 16; i++) {
++ udelay(APPLESMC_MIN_WAIT);
++ status = inb(APPLESMC_CMD_PORT);
++ if (!(status & 0x01))
++ break;
++ data = inb(APPLESMC_DATA_PORT);
++ }
++ if (i)
++ pr_warn("flushed %d bytes, last value is: %d\n", i, data);
++
+ return 0;
+ }
+
--- /dev/null
+From a393ace58e47dffbdfc95d7a6f2db46ef8e2c834 Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Tue, 9 Oct 2012 13:23:57 -0700
+Subject: hwmon: (coretemp) Add support for Atom CE4110/4150/4170
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit 1102dcab849313bd5a340b299b5cf61b518fbc0f upstream.
+
+TjMax for the CE4100 series of Atom CPUs was previously reported to be
+110 degrees C.
+
+cpuinfo logs on the web show existing CPU types CE4110, CE4150, and CE4170,
+reported as "model name : Intel(R) Atom(TM) CPU CE41{1|5|7}0 @ 1.{2|6}0GHz"
+with model 28 (0x1c) and stepping 10 (0x0a). Add the three known variants
+to the tjmax table.
+
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Acked-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/hwmon/coretemp | 1 +
+ drivers/hwmon/coretemp.c | 7 +++++--
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/Documentation/hwmon/coretemp
++++ b/Documentation/hwmon/coretemp
+@@ -94,6 +94,7 @@ Process Processor TjMax(C)
+ 330/230 125
+ E680/660/640/620 90
+ E680T/660T/640T/620T 110
++ CE4170/4150/4110 110
+
+ 45nm Core2 Processors
+ Solo ULV SU3500/3300 100
+--- a/drivers/hwmon/coretemp.c
++++ b/drivers/hwmon/coretemp.c
+@@ -205,8 +205,11 @@ static struct tjmax __cpuinitconst tjmax
+ { "CPU N455", 100000 },
+ { "CPU N470", 100000 },
+ { "CPU N475", 100000 },
+- { "CPU 230", 100000 },
+- { "CPU 330", 125000 },
++ { "CPU 230", 100000 }, /* Model 0x1c, stepping 2 */
++ { "CPU 330", 125000 }, /* Model 0x1c, stepping 2 */
++ { "CPU CE4110", 110000 }, /* Model 0x1c, stepping 10 */
++ { "CPU CE4150", 110000 }, /* Model 0x1c, stepping 10 */
++ { "CPU CE4170", 110000 }, /* Model 0x1c, stepping 10 */
+ };
+
+ static int __cpuinit adjust_tjmax(struct cpuinfo_x86 *c, u32 id,
--- /dev/null
+From 1676fff2a36011956eaa7a5a6c892bb9ddc31e4d Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Sun, 17 Jun 2012 18:05:05 +0200
+Subject: hwmon: (coretemp) Add support for Atom D2000 and N2000 series CPU models
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit 5592906f8b01282ea3c2acaf641fd067ad4bb3dc upstream.
+
+Document the Atom series D2000 and N2000 (Cedar Trail) as being supported.
+List and set TjMax for those series.
+
+Cc: Fenghua Yu <fenghua.yu@intel.com>
+Cc: "R, Durgadoss" <durgadoss.r@intel.com>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/hwmon/coretemp | 5 ++++-
+ drivers/hwmon/coretemp.c | 3 +++
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+--- a/Documentation/hwmon/coretemp
++++ b/Documentation/hwmon/coretemp
+@@ -7,7 +7,8 @@ Supported chips:
+ CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
+ 0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
+ 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
+- 0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom)
++ 0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom),
++ 0x36 (Cedar Trail Atom)
+ Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
+ Volume 3A: System Programming Guide
+ http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
+@@ -68,6 +69,8 @@ Process Processor TjMax(C)
+
+ 32nm Atom Processors
+ Z2460 90
++ D2700/2550/2500 100
++ N2850/2800/2650/2600 100
+
+ 45nm Xeon Processors 5400 Quad-Core
+ X5492, X5482, X5472, X5470, X5460, X5450 85
+--- a/drivers/hwmon/coretemp.c
++++ b/drivers/hwmon/coretemp.c
+@@ -224,6 +224,9 @@ static int __cpuinit adjust_tjmax(struct
+ tjmax = 90000;
+
+ pci_dev_put(host_bridge);
++ } else if (c->x86_model == 0x36) {
++ usemsr_ee = 0;
++ tjmax = 100000;
+ }
+
+ if (c->x86_model > 0xe && usemsr_ee) {
--- /dev/null
+From 41e58a1f2b90c88d94b4bd84beb9927a4c2704e9 Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Sun, 17 Jun 2012 18:05:05 +0200
+Subject: hwmon: (coretemp) Improve support for TjMax detection on Atom CPUs
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit 41e58a1f2b90c88d94b4bd84beb9927a4c2704e9 upstream.
+
+Atom CPUs don't have a register to retrieve TjMax. Detection so far was
+incomplete. Use the X86 model ID to improve it.
+
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/coretemp.c | 25 +++++++++++++++++++++++++
+ 1 file changed, 25 insertions(+)
+
+--- a/drivers/hwmon/coretemp.c
++++ b/drivers/hwmon/coretemp.c
+@@ -191,6 +191,24 @@ static ssize_t show_temp(struct device *
+ return tdata->valid ? sprintf(buf, "%d\n", tdata->temp) : -EAGAIN;
+ }
+
++struct tjmax {
++ char const *id;
++ int tjmax;
++};
++
++static struct tjmax __cpuinitconst tjmax_table[] = {
++ { "CPU D410", 100000 },
++ { "CPU D425", 100000 },
++ { "CPU D510", 100000 },
++ { "CPU D525", 100000 },
++ { "CPU N450", 100000 },
++ { "CPU N455", 100000 },
++ { "CPU N470", 100000 },
++ { "CPU N475", 100000 },
++ { "CPU 230", 100000 },
++ { "CPU 330", 125000 },
++};
++
+ static int __cpuinit adjust_tjmax(struct cpuinfo_x86 *c, u32 id,
+ struct device *dev)
+ {
+@@ -202,6 +220,13 @@ static int __cpuinit adjust_tjmax(struct
+ int err;
+ u32 eax, edx;
+ struct pci_dev *host_bridge;
++ int i;
++
++ /* explicit tjmax table entries override heuristics */
++ for (i = 0; i < ARRAY_SIZE(tjmax_table); i++) {
++ if (strstr(c->x86_model_id, tjmax_table[i].id))
++ return tjmax_table[i].tjmax;
++ }
+
+ /* Early chips have no MSR for TjMax */
+
--- /dev/null
+From 9ce8ea33f11cc0fbdff0c837694a302b9e02cbe5 Mon Sep 17 00:00:00 2001
+From: Jean Delvare <khali@linux-fr.org>
+Date: Sun, 17 Jun 2012 18:05:05 +0200
+Subject: hwmon: (coretemp) Improve support of recent Atom CPU models
+
+From: Jean Delvare <khali@linux-fr.org>
+
+commit fcc14ac1a86931f38da047cf8fb634c6db7b58bc upstream.
+
+Document the new Atom series (Tunnel Creek and Medfield) as being
+supported, and list TjMax for the Atom E600 series.
+
+Also enable the Atom tjmax heuristic for these Atom CPU models.
+
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+Reviewed-by: Guenter Roeck <guenter.roeck@ericsson.com>
+Cc: Alexander Stein <alexander.stein@systec-electronic.com>
+Cc: Fenghua Yu <fenghua.yu@intel.com>
+Cc: "R, Durgadoss" <durgadoss.r@intel.com>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/hwmon/coretemp | 8 +++++++-
+ drivers/hwmon/coretemp.c | 3 ++-
+ 2 files changed, 9 insertions(+), 2 deletions(-)
+
+--- a/Documentation/hwmon/coretemp
++++ b/Documentation/hwmon/coretemp
+@@ -6,7 +6,8 @@ Supported chips:
+ Prefix: 'coretemp'
+ CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
+ 0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
+- 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
++ 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield),
++ 0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom)
+ Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
+ Volume 3A: System Programming Guide
+ http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
+@@ -65,6 +66,9 @@ Process Processor TjMax(C)
+ U3400 105
+ P4505/P4500 90
+
++32nm Atom Processors
++ Z2460 90
++
+ 45nm Xeon Processors 5400 Quad-Core
+ X5492, X5482, X5472, X5470, X5460, X5450 85
+ E5472, E5462, E5450/40/30/20/10/05 85
+@@ -85,6 +89,8 @@ Process Processor TjMax(C)
+ N475/470/455/450 100
+ N280/270 90
+ 330/230 125
++ E680/660/640/620 90
++ E680T/660T/640T/620T 110
+
+ 45nm Core2 Processors
+ Solo ULV SU3500/3300 100
+--- a/drivers/hwmon/coretemp.c
++++ b/drivers/hwmon/coretemp.c
+@@ -210,7 +210,8 @@ static int __cpuinit adjust_tjmax(struct
+
+ /* Atom CPUs */
+
+- if (c->x86_model == 0x1c) {
++ if (c->x86_model == 0x1c || c->x86_model == 0x26
++ || c->x86_model == 0x27) {
+ usemsr_ee = 0;
+
+ host_bridge = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
--- /dev/null
+From cf3f5a3dbf78b72541dc9f295101cb90a5465d5c Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 12 Dec 2013 08:05:33 +0100
+Subject: hwmon: Prevent some divide by zeros in FAN_TO_REG()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 3806b45ba4655147a011df03242cc197ab986c43 upstream.
+
+The "rpm * div" operations can overflow here, so this patch adds an
+upper limit to rpm to prevent that. Jean Delvare helped me with this
+patch.
+
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Acked-by: Roger Lucas <vt8231@hiddenengine.co.uk>
+Signed-off-by: Jean Delvare <khali@linux-fr.org>
+[bwh: Backported to 3.2: adjust context]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/lm78.c | 2 ++
+ drivers/hwmon/sis5595.c | 2 ++
+ drivers/hwmon/vt8231.c | 2 +-
+ 3 files changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/hwmon/lm78.c
++++ b/drivers/hwmon/lm78.c
+@@ -94,6 +94,8 @@ static inline u8 FAN_TO_REG(long rpm, in
+ {
+ if (rpm <= 0)
+ return 255;
++ if (rpm > 1350000)
++ return 1;
+ return SENSORS_LIMIT((1350000 + rpm * div / 2) / (rpm * div), 1, 254);
+ }
+
+--- a/drivers/hwmon/sis5595.c
++++ b/drivers/hwmon/sis5595.c
+@@ -141,6 +141,8 @@ static inline u8 FAN_TO_REG(long rpm, in
+ {
+ if (rpm <= 0)
+ return 255;
++ if (rpm > 1350000)
++ return 1;
+ return SENSORS_LIMIT((1350000 + rpm * div / 2) / (rpm * div), 1, 254);
+ }
+
+--- a/drivers/hwmon/vt8231.c
++++ b/drivers/hwmon/vt8231.c
+@@ -145,7 +145,7 @@ static const u8 regtempmin[] = { 0x3a, 0
+ */
+ static inline u8 FAN_TO_REG(long rpm, int div)
+ {
+- if (rpm == 0)
++ if (rpm <= 0 || rpm > 1310720)
+ return 0;
+ return SENSORS_LIMIT(1310720 / (rpm * div), 1, 255);
+ }
--- /dev/null
+From 3a0ae8e18c188a90c8a54fd26d18d6da5a084892 Mon Sep 17 00:00:00 2001
+From: Lauri Hintsala <lauri.hintsala@bluegiga.com>
+Date: Tue, 17 Jul 2012 17:16:10 +0300
+Subject: mmc: mxs-mmc: fix deadlock caused by recursion loop
+
+From: Lauri Hintsala <lauri.hintsala@bluegiga.com>
+
+commit fc108d24d3a6da63576a460e122fa1df0cbdea20 upstream.
+
+Release the lock before mmc_signal_sdio_irq is called by
+mxs_mmc_enable_sdio_irq.
+
+Backtrace:
+[ 65.470000] =============================================
+[ 65.470000] [ INFO: possible recursive locking detected ]
+[ 65.470000] 3.5.0-rc5 #2 Not tainted
+[ 65.470000] ---------------------------------------------
+[ 65.470000] ksdioirqd/mmc0/73 is trying to acquire lock:
+[ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
+[ 65.470000]
+[ 65.470000] but task is already holding lock:
+[ 65.470000] (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
+[ 65.470000]
+[ 65.470000] other info that might help us debug this:
+[ 65.470000] Possible unsafe locking scenario:
+[ 65.470000]
+[ 65.470000] CPU0
+[ 65.470000] ----
+[ 65.470000] lock(&(&host->lock)->rlock#2);
+[ 65.470000] lock(&(&host->lock)->rlock#2);
+[ 65.470000]
+[ 65.470000] *** DEADLOCK ***
+[ 65.470000]
+[ 65.470000] May be due to missing lock nesting notation
+[ 65.470000]
+[ 65.470000] 1 lock held by ksdioirqd/mmc0/73:
+[ 65.470000] #0: (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
+[ 65.470000]
+[ 65.470000] stack backtrace:
+[ 65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98)
+[ 65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108)
+[ 65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c)
+[ 65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
+[ 65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
+[ 65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
+[ 65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
+[ 65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
+[ 65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73
+[ 65.470000] lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0
+[ 65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144)
+[ 65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c)
+[ 65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
+[ 65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
+[ 65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
+[ 65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
+[ 65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
+
+Reported-by: Attila Kinali <attila@kinali.ch>
+Signed-off-by: Lauri Hintsala <lauri.hintsala@bluegiga.com>
+Acked-by: Shawn Guo <shawn.guo@linaro.org>
+Signed-off-by: Chris Ball <cjb@laptop.org>
+[bwh: Backported to 3.2:
+ - Adjust context
+ - HW_SSP_STATUS is a simple rather than function-like macro]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/mxs-mmc.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/mmc/host/mxs-mmc.c
++++ b/drivers/mmc/host/mxs-mmc.c
+@@ -639,10 +639,6 @@ static void mxs_mmc_enable_sdio_irq(stru
+ host->base + HW_SSP_CTRL0 + MXS_SET_ADDR);
+ writel(BM_SSP_CTRL1_SDIO_IRQ_EN,
+ host->base + HW_SSP_CTRL1 + MXS_SET_ADDR);
+-
+- if (readl(host->base + HW_SSP_STATUS) & BM_SSP_STATUS_SDIO_IRQ)
+- mmc_signal_sdio_irq(host->mmc);
+-
+ } else {
+ writel(BM_SSP_CTRL0_SDIO_IRQ_CHECK,
+ host->base + HW_SSP_CTRL0 + MXS_CLR_ADDR);
+@@ -651,6 +647,10 @@ static void mxs_mmc_enable_sdio_irq(stru
+ }
+
+ spin_unlock_irqrestore(&host->lock, flags);
++
++ if (enable && readl(host->base + HW_SSP_STATUS) & BM_SSP_STATUS_SDIO_IRQ)
++ mmc_signal_sdio_irq(host->mmc);
++
+ }
+
+ static const struct mmc_host_ops mxs_mmc_ops = {
--- /dev/null
+From 3fd4e8f0ecd916f761459f0dc7174940ce3a0b99 Mon Sep 17 00:00:00 2001
+From: Grazvydas Ignotas <notasas@gmail.com>
+Date: Tue, 21 Aug 2012 09:09:48 +0300
+Subject: OMAPFB: fix framebuffer console colors
+
+From: Grazvydas Ignotas <notasas@gmail.com>
+
+commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream.
+
+omapfb does not currently set pseudo palette correctly for color depths
+above 16bpp, making red text invisible, command like
+ echo -e '\e[0;31mRED' > /dev/tty1
+will display nothing on framebuffer console in 24bpp mode.
+This is because temporary variable is declared incorrectly, fix it.
+
+Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/video/omap2/omapfb/omapfb-main.c
++++ b/drivers/video/omap2/omapfb/omapfb-main.c
+@@ -1187,7 +1187,7 @@ static int _setcolreg(struct fb_info *fb
+ break;
+
+ if (regno < 16) {
+- u16 pal;
++ u32 pal;
+ pal = ((red >> (16 - var->red.length)) <<
+ var->red.offset) |
+ ((green >> (16 - var->green.length)) <<
--- /dev/null
+From b39bfb4cc09a0663d13b537e69e8241e6cc8ce71 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab@redhat.com>
+Date: Thu, 20 Sep 2012 12:09:30 -0300
+Subject: sb_edac: Avoid overflow errors at memory size calculation
+
+From: Mauro Carvalho Chehab <mchehab@redhat.com>
+
+commit deb09ddaff1435f72dd598d38f9b58354c68a5ec upstream.
+
+Sandy bridge EDAC is calculating the memory size with overflow.
+Basically, the size field and the integer calculation is using 32 bits.
+More bits are needed, when the DIMM memories have high density.
+
+The net result is that memories are improperly reported there, when
+high-density DIMMs are used:
+
+EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 0, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
+EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 1, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
+
+As the number of pages value is handled at the EDAC core as unsigned
+ints, the driver shows the 16 GB memories at sysfs interface as 16760832
+MB! The fix is simple: calculate the number of pages as unsigned 64-bits
+integer.
+
+After the patch, the memory size (16 GB) is properly detected:
+
+EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 0, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
+EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 1, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
+
+Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
+[bwh: Backported to 3.2:
+ - Adjust context
+ - Debug log function is debugf0(), not edac_dbg()]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/edac/sb_edac.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/edac/sb_edac.c
++++ b/drivers/edac/sb_edac.c
+@@ -555,7 +555,8 @@ static int get_dimm_config(const struct
+ {
+ struct sbridge_pvt *pvt = mci->pvt_info;
+ struct csrow_info *csr;
+- int i, j, banks, ranks, rows, cols, size, npages;
++ unsigned i, j, banks, ranks, rows, cols, npages;
++ u64 size;
+ int csrow = 0;
+ unsigned long last_page = 0;
+ u32 reg;
+@@ -627,10 +628,10 @@ static int get_dimm_config(const struct
+ cols = numcol(mtr);
+
+ /* DDR3 has 8 I/O banks */
+- size = (rows * cols * banks * ranks) >> (20 - 3);
++ size = ((u64)rows * cols * banks * ranks) >> (20 - 3);
+ npages = MiB_TO_PAGES(size);
+
+- debugf0("mc#%d: channel %d, dimm %d, %d Mb (%d pages) bank: %d, rank: %d, row: %#x, col: %#x\n",
++ debugf0("mc#%d: channel %d, dimm %d, %Ld Mb (%d pages) bank: %d, rank: %d, row: %#x, col: %#x\n",
+ pvt->sbridge_dev->mc, i, j,
+ size, npages,
+ banks, ranks, rows, cols);
alsa-hda-hdmi-fallback-to-alsa-allocation-when-selecting-ca.patch
alsa-pcsp-fix-the-order-of-input-device-unregistration.patch
alsa-hda-realtek-add-support-of-alc231-codec.patch
+hwmon-coretemp-improve-support-of-recent-atom-cpu-models.patch
+hwmon-coretemp-add-support-for-atom-d2000-and-n2000-series-cpu-models.patch
+hwmon-coretemp-improve-support-for-tjmax-detection-on-atom-cpus.patch
+hwmon-coretemp-add-support-for-atom-ce4110-4150-4170.patch
+hwmon-applesmc-always-read-until-end-of-data.patch
+hwmon-prevent-some-divide-by-zeros-in-fan_to_reg.patch
+tg3-add-new-5719-read-dma-workaround.patch
+tg3-wait-for-boot-code-to-finish-after-power-on.patch
+omapfb-fix-framebuffer-console-colors.patch
+mmc-mxs-mmc-fix-deadlock-caused-by-recursion-loop.patch
+sb_edac-avoid-overflow-errors-at-memory-size-calculation.patch
--- /dev/null
+From 638030fe4b54431ac8deadecfd54b435336c0c69 Mon Sep 17 00:00:00 2001
+From: Michael Chan <mchan@broadcom.com>
+Date: Sun, 29 Jul 2012 19:15:43 +0000
+Subject: tg3: Add New 5719 Read DMA workaround
+
+From: Michael Chan <mchan@broadcom.com>
+
+commit 091f0ea30074bc43f9250961b3247af713024bc6 upstream.
+
+After Power-on-reset, the 5719's TX DMA length registers may contain
+uninitialized values and cause TX DMA to stall. Check for invalid
+values and set a register bit to flush the TX channels. The bit
+needs to be turned off after the DMA channels have been flushed.
+
+Signed-off-by: Michael Chan <mchan@broadcom.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/broadcom/tg3.c | 23 +++++++++++++++++++++++
+ drivers/net/ethernet/broadcom/tg3.h | 7 ++++++-
+ 2 files changed, 29 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/broadcom/tg3.c
++++ b/drivers/net/ethernet/broadcom/tg3.c
+@@ -9161,6 +9161,19 @@ static int tg3_reset_hw(struct tg3 *tp,
+ tw32_f(RDMAC_MODE, rdmac_mode);
+ udelay(40);
+
++ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5719) {
++ for (i = 0; i < TG3_NUM_RDMA_CHANNELS; i++) {
++ if (tr32(TG3_RDMA_LENGTH + (i << 2)) > TG3_MAX_MTU(tp))
++ break;
++ }
++ if (i < TG3_NUM_RDMA_CHANNELS) {
++ val = tr32(TG3_LSO_RD_DMA_CRPTEN_CTRL);
++ val |= TG3_LSO_RD_DMA_TX_LENGTH_WA;
++ tw32(TG3_LSO_RD_DMA_CRPTEN_CTRL, val);
++ tg3_flag_set(tp, 5719_RDMA_BUG);
++ }
++ }
++
+ tw32(RCVDCC_MODE, RCVDCC_MODE_ENABLE | RCVDCC_MODE_ATTN_ENABLE);
+ if (!tg3_flag(tp, 5705_PLUS))
+ tw32(MBFREE_MODE, MBFREE_MODE_ENABLE);
+@@ -9416,6 +9429,16 @@ static void tg3_periodic_fetch_stats(str
+ TG3_STAT_ADD32(&sp->tx_ucast_packets, MAC_TX_STATS_UCAST);
+ TG3_STAT_ADD32(&sp->tx_mcast_packets, MAC_TX_STATS_MCAST);
+ TG3_STAT_ADD32(&sp->tx_bcast_packets, MAC_TX_STATS_BCAST);
++ if (unlikely(tg3_flag(tp, 5719_RDMA_BUG) &&
++ (sp->tx_ucast_packets.low + sp->tx_mcast_packets.low +
++ sp->tx_bcast_packets.low) > TG3_NUM_RDMA_CHANNELS)) {
++ u32 val;
++
++ val = tr32(TG3_LSO_RD_DMA_CRPTEN_CTRL);
++ val &= ~TG3_LSO_RD_DMA_TX_LENGTH_WA;
++ tw32(TG3_LSO_RD_DMA_CRPTEN_CTRL, val);
++ tg3_flag_clear(tp, 5719_RDMA_BUG);
++ }
+
+ TG3_STAT_ADD32(&sp->rx_octets, MAC_RX_STATS_OCTETS);
+ TG3_STAT_ADD32(&sp->rx_fragments, MAC_RX_STATS_FRAGMENTS);
+--- a/drivers/net/ethernet/broadcom/tg3.h
++++ b/drivers/net/ethernet/broadcom/tg3.h
+@@ -1376,7 +1376,11 @@
+ #define TG3_LSO_RD_DMA_CRPTEN_CTRL 0x00004910
+ #define TG3_LSO_RD_DMA_CRPTEN_CTRL_BLEN_BD_4K 0x00030000
+ #define TG3_LSO_RD_DMA_CRPTEN_CTRL_BLEN_LSO_4K 0x000c0000
+-/* 0x4914 --> 0x4c00 unused */
++#define TG3_LSO_RD_DMA_TX_LENGTH_WA 0x02000000
++/* 0x4914 --> 0x4be0 unused */
++
++#define TG3_NUM_RDMA_CHANNELS 4
++#define TG3_RDMA_LENGTH 0x00004be0
+
+ /* Write DMA control registers */
+ #define WDMAC_MODE 0x00004c00
+@@ -2924,6 +2928,7 @@ enum TG3_FLAGS {
+ TG3_FLAG_L1PLLPD_EN,
+ TG3_FLAG_APE_HAS_NCSI,
+ TG3_FLAG_4K_FIFO_LIMIT,
++ TG3_FLAG_5719_RDMA_BUG,
+ TG3_FLAG_RESET_TASK_PENDING,
+ TG3_FLAG_5705_PLUS,
+ TG3_FLAG_IS_5788,
--- /dev/null
+From 08647d0f99db39f73f37e00ebafc24ff3d3f4948 Mon Sep 17 00:00:00 2001
+From: Nithin Sujir <nsujir@broadcom.com>
+Date: Wed, 12 Jun 2013 11:08:59 -0700
+Subject: tg3: Wait for boot code to finish after power on
+
+From: Nithin Sujir <nsujir@broadcom.com>
+
+commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream.
+
+Some systems that don't need wake-on-lan may choose to power down the
+chip on system standby. Upon resume, the power on causes the boot code
+to startup and initialize the hardware. On one new platform, this is
+causing the device to go into a bad state due to a race between the
+driver and boot code, once every several hundred resumes. The same race
+exists on open since we come up from a power on.
+
+This patch adds a wait for boot code signature at the beginning of
+tg3_init_hw() which is common to both cases. If there has not been a
+power-off or the boot code has already completed, the signature will be
+present and poll_fw() returns immediately. Also return immediately if
+the device does not have firmware.
+
+Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
+Signed-off-by: Michael Chan <mchan@broadcom.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+[bwh: Backported to 3.2: adjust context]
+Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
+Cc: Qiang Huang <h.huangqiang@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/broadcom/tg3.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/net/ethernet/broadcom/tg3.c
++++ b/drivers/net/ethernet/broadcom/tg3.c
+@@ -1631,6 +1631,9 @@ static int tg3_poll_fw(struct tg3 *tp)
+ int i;
+ u32 val;
+
++ if (tg3_flag(tp, NO_FWARE_REPORTED))
++ return 0;
++
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
+ /* Wait up to 20ms for init done. */
+ for (i = 0; i < 200; i++) {
+@@ -9395,6 +9398,13 @@ static int tg3_reset_hw(struct tg3 *tp,
+ */
+ static int tg3_init_hw(struct tg3 *tp, int reset_phy)
+ {
++ /* Chip may have been just powered on. If so, the boot code may still
++ * be running initialization. Wait for it to finish to avoid races in
++ * accessing the hardware.
++ */
++ tg3_enable_register_access(tp);
++ tg3_poll_fw(tp);
++
+ tg3_switch_clocks(tp);
+
+ tw32(TG3PCI_MEM_WIN_BASE_ADDR, 0);
projects / thirdparty / kernel / stable-queue.git / commitdiff
