--- /dev/null
+From 867f9d463b82462793ea4610e748be0b04b37fc7 Mon Sep 17 00:00:00 2001
+From: Andy Whitcroft <apw@canonical.com>
+Date: Thu, 19 Jun 2014 11:19:16 +0100
+Subject: ACPI / resources: only reject zero length resources based at address zero
+
+From: Andy Whitcroft <apw@canonical.com>
+
+commit 867f9d463b82462793ea4610e748be0b04b37fc7 upstream.
+
+The recently merged change (in v3.14-rc6) to ACPI resource detection
+(below) causes all zero length ACPI resources to be elided from the
+table:
+
+ commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
+ Author: Zhang Rui <rui.zhang@intel.com>
+ Date: Thu Feb 27 11:37:15 2014 +0800
+
+ ACPI / resources: ignore invalid ACPI device resources
+
+This change has caused a regression in (at least) serial port detection
+for a number of machines (see LP#1313981 [1]). These seem to represent
+their IO regions (presumably incorrectly) as a zero length region.
+Reverting the above commit restores these serial devices.
+
+Only elide zero length resources which lie at address 0.
+
+Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources)
+Signed-off-by: Andy Whitcroft <apw@canonical.com>
+Acked-by: Zhang Rui <rui.zhang@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/resource.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -77,7 +77,7 @@ bool acpi_dev_resource_memory(struct acp
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_MEMORY24:
+ memory24 = &ares->data.memory24;
+- if (!memory24->address_length)
++ if (!memory24->minimum && !memory24->address_length)
+ return false;
+ acpi_dev_get_memresource(res, memory24->minimum,
+ memory24->address_length,
+@@ -85,7 +85,7 @@ bool acpi_dev_resource_memory(struct acp
+ break;
+ case ACPI_RESOURCE_TYPE_MEMORY32:
+ memory32 = &ares->data.memory32;
+- if (!memory32->address_length)
++ if (!memory32->minimum && !memory32->address_length)
+ return false;
+ acpi_dev_get_memresource(res, memory32->minimum,
+ memory32->address_length,
+@@ -93,7 +93,7 @@ bool acpi_dev_resource_memory(struct acp
+ break;
+ case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
+ fixed_memory32 = &ares->data.fixed_memory32;
+- if (!fixed_memory32->address_length)
++ if (!fixed_memory32->address && !fixed_memory32->address_length)
+ return false;
+ acpi_dev_get_memresource(res, fixed_memory32->address,
+ fixed_memory32->address_length,
+@@ -150,7 +150,7 @@ bool acpi_dev_resource_io(struct acpi_re
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_IO:
+ io = &ares->data.io;
+- if (!io->address_length)
++ if (!io->minimum && !io->address_length)
+ return false;
+ acpi_dev_get_ioresource(res, io->minimum,
+ io->address_length,
+@@ -158,7 +158,7 @@ bool acpi_dev_resource_io(struct acpi_re
+ break;
+ case ACPI_RESOURCE_TYPE_FIXED_IO:
+ fixed_io = &ares->data.fixed_io;
+- if (!fixed_io->address_length)
++ if (!fixed_io->address && !fixed_io->address_length)
+ return false;
+ acpi_dev_get_ioresource(res, fixed_io->address,
+ fixed_io->address_length,
--- /dev/null
+From c024044d4da2c9c3b32933b4235df1e409293b84 Mon Sep 17 00:00:00 2001
+From: Axel Lin <axel.lin@ingics.com>
+Date: Thu, 3 Jul 2014 22:45:45 +0800
+Subject: hwmon: (adm1021) Fix cache problem when writing temperature limits
+
+From: Axel Lin <axel.lin@ingics.com>
+
+commit c024044d4da2c9c3b32933b4235df1e409293b84 upstream.
+
+The module test script for the adm1021 driver exposes a cache problem
+when writing temperature limits. temp_min and temp_max are expected
+to be stored in milli-degrees C but are stored in degrees C.
+
+Reported-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Axel Lin <axel.lin@ingics.com>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/adm1021.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/drivers/hwmon/adm1021.c
++++ b/drivers/hwmon/adm1021.c
+@@ -185,7 +185,7 @@ static ssize_t set_temp_max(struct devic
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adm1021_data *data = i2c_get_clientdata(client);
+ long temp;
+- int err;
++ int reg_val, err;
+
+ err = kstrtol(buf, 10, &temp);
+ if (err)
+@@ -193,10 +193,11 @@ static ssize_t set_temp_max(struct devic
+ temp /= 1000;
+
+ mutex_lock(&data->update_lock);
+- data->temp_max[index] = clamp_val(temp, -128, 127);
++ reg_val = clamp_val(temp, -128, 127);
++ data->temp_max[index] = reg_val * 1000;
+ if (!read_only)
+ i2c_smbus_write_byte_data(client, ADM1021_REG_TOS_W(index),
+- data->temp_max[index]);
++ reg_val);
+ mutex_unlock(&data->update_lock);
+
+ return count;
+@@ -210,7 +211,7 @@ static ssize_t set_temp_min(struct devic
+ struct i2c_client *client = to_i2c_client(dev);
+ struct adm1021_data *data = i2c_get_clientdata(client);
+ long temp;
+- int err;
++ int reg_val, err;
+
+ err = kstrtol(buf, 10, &temp);
+ if (err)
+@@ -218,10 +219,11 @@ static ssize_t set_temp_min(struct devic
+ temp /= 1000;
+
+ mutex_lock(&data->update_lock);
+- data->temp_min[index] = clamp_val(temp, -128, 127);
++ reg_val = clamp_val(temp, -128, 127);
++ data->temp_min[index] = reg_val * 1000;
+ if (!read_only)
+ i2c_smbus_write_byte_data(client, ADM1021_REG_THYST_W(index),
+- data->temp_min[index]);
++ reg_val);
+ mutex_unlock(&data->update_lock);
+
+ return count;
--- /dev/null
+From 1035a9e3e9c76b64a860a774f5b867d28d34acc2 Mon Sep 17 00:00:00 2001
+From: Axel Lin <axel.lin@ingics.com>
+Date: Wed, 2 Jul 2014 08:29:55 +0800
+Subject: hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
+
+From: Axel Lin <axel.lin@ingics.com>
+
+commit 1035a9e3e9c76b64a860a774f5b867d28d34acc2 upstream.
+
+Writing to fanX_div does not clear the cache. As a result, reading
+from fanX_div may return the old value for up to two seconds
+after writing a new value.
+
+This patch ensures the fan_div cache is updated in set_fan_div().
+
+Reported-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Axel Lin <axel.lin@ingics.com>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/adm1029.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/hwmon/adm1029.c
++++ b/drivers/hwmon/adm1029.c
+@@ -232,6 +232,9 @@ static ssize_t set_fan_div(struct device
+ /* Update the value */
+ reg = (reg & 0x3F) | (val << 6);
+
++ /* Update the cache */
++ data->fan_div[attr->index] = reg;
++
+ /* Write value */
+ i2c_smbus_write_byte_data(client,
+ ADM1029_REG_FAN_DIV[attr->index], reg);
--- /dev/null
+From 145e74a4e5022225adb84f4e5d4fff7938475c35 Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Thu, 3 Jul 2014 13:44:23 -0700
+Subject: hwmon: (adm1031) Fix writes to limit registers
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit 145e74a4e5022225adb84f4e5d4fff7938475c35 upstream.
+
+Upper limit for write operations to temperature limit registers
+was clamped to a fractional value. However, limit registers do
+not support fractional values. As a result, upper limits of 127.5
+degrees C or higher resulted in a rounded limit of 128 degrees C.
+Since limit registers are signed, this was stored as -128 degrees C.
+Clamp limits to (-55, +127) degrees C to solve the problem.
+
+Value on writes to auto_temp[12]_min and auto_temp[12]_max were not
+clamped at all, but masked. As a result, out-of-range writes resulted
+in a more or less arbitrary limit. Clamp those attributes to (0, 127)
+degrees C for more predictable results.
+
+Cc: Axel Lin <axel.lin@ingics.com>
+Reviewed-by: Jean Delvare <jdelvare@suse.de>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/adm1031.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/hwmon/adm1031.c
++++ b/drivers/hwmon/adm1031.c
+@@ -365,6 +365,7 @@ set_auto_temp_min(struct device *dev, st
+ if (ret)
+ return ret;
+
++ val = clamp_val(val, 0, 127000);
+ mutex_lock(&data->update_lock);
+ data->auto_temp[nr] = AUTO_TEMP_MIN_TO_REG(val, data->auto_temp[nr]);
+ adm1031_write_value(client, ADM1031_REG_AUTO_TEMP(nr),
+@@ -394,6 +395,7 @@ set_auto_temp_max(struct device *dev, st
+ if (ret)
+ return ret;
+
++ val = clamp_val(val, 0, 127000);
+ mutex_lock(&data->update_lock);
+ data->temp_max[nr] = AUTO_TEMP_MAX_TO_REG(val, data->auto_temp[nr],
+ data->pwm[nr]);
+@@ -696,7 +698,7 @@ static ssize_t set_temp_min(struct devic
+ if (ret)
+ return ret;
+
+- val = clamp_val(val, -55000, nr == 0 ? 127750 : 127875);
++ val = clamp_val(val, -55000, 127000);
+ mutex_lock(&data->update_lock);
+ data->temp_min[nr] = TEMP_TO_REG(val);
+ adm1031_write_value(client, ADM1031_REG_TEMP_MIN(nr),
+@@ -717,7 +719,7 @@ static ssize_t set_temp_max(struct devic
+ if (ret)
+ return ret;
+
+- val = clamp_val(val, -55000, nr == 0 ? 127750 : 127875);
++ val = clamp_val(val, -55000, 127000);
+ mutex_lock(&data->update_lock);
+ data->temp_max[nr] = TEMP_TO_REG(val);
+ adm1031_write_value(client, ADM1031_REG_TEMP_MAX(nr),
+@@ -738,7 +740,7 @@ static ssize_t set_temp_crit(struct devi
+ if (ret)
+ return ret;
+
+- val = clamp_val(val, -55000, nr == 0 ? 127750 : 127875);
++ val = clamp_val(val, -55000, 127000);
+ mutex_lock(&data->update_lock);
+ data->temp_crit[nr] = TEMP_TO_REG(val);
+ adm1031_write_value(client, ADM1031_REG_TEMP_CRIT(nr),
--- /dev/null
+From df86754b746e9a0ff6f863f690b1c01d408e3cdc Mon Sep 17 00:00:00 2001
+From: Axel Lin <axel.lin@ingics.com>
+Date: Wed, 2 Jul 2014 07:44:44 +0800
+Subject: hwmon: (amc6821) Fix permissions for temp2_input
+
+From: Axel Lin <axel.lin@ingics.com>
+
+commit df86754b746e9a0ff6f863f690b1c01d408e3cdc upstream.
+
+temp2_input should not be writable, fix it.
+
+Reported-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Axel Lin <axel.lin@ingics.com>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/amc6821.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/hwmon/amc6821.c
++++ b/drivers/hwmon/amc6821.c
+@@ -707,7 +707,7 @@ static SENSOR_DEVICE_ATTR(temp1_max_alar
+ get_temp_alarm, NULL, IDX_TEMP1_MAX);
+ static SENSOR_DEVICE_ATTR(temp1_crit_alarm, S_IRUGO,
+ get_temp_alarm, NULL, IDX_TEMP1_CRIT);
+-static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO | S_IWUSR,
++static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO,
+ get_temp, NULL, IDX_TEMP2_INPUT);
+ static SENSOR_DEVICE_ATTR(temp2_min, S_IRUGO | S_IWUSR, get_temp,
+ set_temp, IDX_TEMP2_MIN);
--- /dev/null
+From b50a6c584bb47b370f84bfd746770c0bbe7129b7 Mon Sep 17 00:00:00 2001
+From: Joel Stanley <joel@jms.id.au>
+Date: Tue, 8 Jul 2014 16:08:22 +0930
+Subject: powerpc/perf: Clear MMCR2 when enabling PMU
+
+From: Joel Stanley <joel@jms.id.au>
+
+commit b50a6c584bb47b370f84bfd746770c0bbe7129b7 upstream.
+
+On POWER8 when switching to a KVM guest we set bits in MMCR2 to freeze
+the PMU counters. Aside from on boot they are then never reset,
+resulting in stuck perf counters for any user in the guest or host.
+
+We now set MMCR2 to 0 whenever enabling the PMU, which provides a sane
+state for perf to use the PMU counters under either the guest or the
+host.
+
+This was manifesting as a bug with ppc64_cpu --frequency:
+
+ $ sudo ppc64_cpu --frequency
+ WARNING: couldn't run on cpu 0
+ WARNING: couldn't run on cpu 8
+ ...
+ WARNING: couldn't run on cpu 144
+ WARNING: couldn't run on cpu 152
+ min: 18446744073.710 GHz (cpu -1)
+ max: 0.000 GHz (cpu -1)
+ avg: 0.000 GHz
+
+The command uses a perf counter to measure CPU cycles over a fixed
+amount of time, in order to approximate the frequency of the machine.
+The counters were returning zero once a guest was started, regardless of
+weather it was still running or had been shut down.
+
+By dumping the value of MMCR2, it was observed that once a guest is
+running MMCR2 is set to 1s - which stops counters from running:
+
+ $ sudo sh -c 'echo p > /proc/sysrq-trigger'
+ CPU: 0 PMU registers, ppmu = POWER8 n_counters = 6
+ PMC1: 5b635e38 PMC2: 00000000 PMC3: 00000000 PMC4: 00000000
+ PMC5: 1bf5a646 PMC6: 5793d378 PMC7: deadbeef PMC8: deadbeef
+ MMCR0: 0000000080000000 MMCR1: 000000001e000000 MMCRA: 0000040000000000
+ MMCR2: fffffffffffffc00 EBBHR: 0000000000000000
+ EBBRR: 0000000000000000 BESCR: 0000000000000000
+ SIAR: 00000000000a51cc SDAR: c00000000fc40000 SIER: 0000000001000000
+
+This is done unconditionally in book3s_hv_interrupts.S upon entering the
+guest, and the original value is only save/restored if the host has
+indicated it was using the PMU. This is okay, however the user of the
+PMU needs to ensure that it is in a defined state when it starts using
+it.
+
+Fixes: e05b9b9e5c10 ("powerpc/perf: Power8 PMU support")
+Signed-off-by: Joel Stanley <joel@jms.id.au>
+Acked-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/perf/core-book3s.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/powerpc/perf/core-book3s.c
++++ b/arch/powerpc/perf/core-book3s.c
+@@ -1342,6 +1342,9 @@ static int can_go_on_limited_pmc(struct
+ if (ppmu->limited_pmc_event(ev))
+ return 1;
+
++ if (ppmu->flags & PPMU_ARCH_207S)
++ mtspr(SPRN_MMCR2, 0);
++
+ /*
+ * The requested event_id isn't on a limited PMC already;
+ * see if any alternative code goes on a limited PMC.
--- /dev/null
+From f56029410a13cae3652d1f34788045c40a13ffc7 Mon Sep 17 00:00:00 2001
+From: Anton Blanchard <anton@samba.org>
+Date: Thu, 29 May 2014 08:15:38 +1000
+Subject: powerpc/perf: Never program book3s PMCs with values >= 0x80000000
+
+From: Anton Blanchard <anton@samba.org>
+
+commit f56029410a13cae3652d1f34788045c40a13ffc7 upstream.
+
+We are seeing a lot of PMU warnings on POWER8:
+
+ Can't find PMC that caused IRQ
+
+Looking closer, the active PMC is 0 at this point and we took a PMU
+exception on the transition from negative to 0. Some versions of POWER8
+have an issue where they edge detect and not level detect PMC overflows.
+
+A number of places program the PMC with (0x80000000 - period_left),
+where period_left can be negative. We can either fix all of these or
+just ensure that period_left is always >= 1.
+
+This patch takes the second option.
+
+Signed-off-by: Anton Blanchard <anton@samba.org>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/perf/core-book3s.c | 17 ++++++++++++++++-
+ 1 file changed, 16 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/perf/core-book3s.c
++++ b/arch/powerpc/perf/core-book3s.c
+@@ -749,7 +749,22 @@ static void power_pmu_read(struct perf_e
+ } while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
+
+ local64_add(delta, &event->count);
+- local64_sub(delta, &event->hw.period_left);
++
++ /*
++ * A number of places program the PMC with (0x80000000 - period_left).
++ * We never want period_left to be less than 1 because we will program
++ * the PMC with a value >= 0x800000000 and an edge detected PMC will
++ * roll around to 0 before taking an exception. We have seen this
++ * on POWER8.
++ *
++ * To fix this, clamp the minimum value of period_left to 1.
++ */
++ do {
++ prev = local64_read(&event->hw.period_left);
++ val = prev - delta;
++ if (val < 1)
++ val = 1;
++ } while (local64_cmpxchg(&event->hw.period_left, prev, val) != prev);
+ }
+
+ /*
workqueue-fix-dev_set_uevent_suppress-imbalance.patch
cpuset-mempolicy-fix-sleeping-function-called-from-invalid-context.patch
workqueue-zero-cpumask-of-wq_numa_possible_cpumask-on-init.patch
+hwmon-amc6821-fix-permissions-for-temp2_input.patch
+hwmon-adm1031-fix-writes-to-limit-registers.patch
+hwmon-adm1029-ensure-the-fan_div-cache-is-updated-in-set_fan_div.patch
+hwmon-adm1021-fix-cache-problem-when-writing-temperature-limits.patch
+acpi-resources-only-reject-zero-length-resources-based-at-address-zero.patch
+powerpc-perf-never-program-book3s-pmcs-with-values-0x80000000.patch
+powerpc-perf-clear-mmcr2-when-enabling-pmu.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
