From: Greg Kroah-Hartman Date: Fri, 7 Feb 2014 04:23:24 +0000 (-0800) Subject: 3.12-stable patches X-Git-Tag: v3.4.80~79 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f8e4fbf64cbeaa98ac5f131276217962550201c2;p=thirdparty%2Fkernel%2Fstable-queue.git 3.12-stable patches added patches: acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch arm-mvebu-fix-kernel-hang-in-mvebu_soc_id_init-when-of_iomap-failed.patch arm-orion-provide-c-style-interrupt-handler-for-multi_irq_handler.patch slub-fix-calculation-of-cpu-slabs.patch turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch --- diff --git a/queue-3.12/acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch b/queue-3.12/acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch new file mode 100644 index 00000000000..848ee9ee703 --- /dev/null +++ b/queue-3.12/acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch @@ -0,0 +1,66 @@ +From 49a12877d2777cadcb838981c3c4f5a424aef310 Mon Sep 17 00:00:00 2001 +From: Mark Brown +Date: Mon, 27 Jan 2014 00:32:14 +0000 +Subject: ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API + +From: Mark Brown + +commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream. + +There is currently no facility in ACPI to express the hookup of voltage +regulators, the expectation is that the regulators that exist in the +system will be handled transparently by firmware if they need software +control at all. This means that if for some reason the regulator API is +enabled on such a system it should assume that any supplies that devices +need are provided by the system at all relevant times without any software +intervention. + +Tell the regulator core to make this assumption by calling +regulator_has_full_constraints(). Do this as soon as we know we are using +ACPI so that the information is available to the regulator core as early +as possible. This will cause the regulator core to pretend that there is +an always on regulator supplying any supply that is requested but that has +not otherwise been mapped which is the behaviour expected on a system with +ACPI. + +Should the ability to specify regulators be added in future revisions of +ACPI then once we have support for ACPI mappings in the kernel the same +assumptions will apply. It is also likely that systems will default to a +mode of operation which does not require any interpretation of these +mappings in order to be compatible with existing operating system releases +so it should remain safe to make these assumptions even if the mappings +exist but are not supported by the kernel. + +Signed-off-by: Mark Brown +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/bus.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/drivers/acpi/bus.c ++++ b/drivers/acpi/bus.c +@@ -33,6 +33,7 @@ + #include + #include + #include ++#include + #ifdef CONFIG_X86 + #include + #endif +@@ -575,6 +576,14 @@ void __init acpi_early_init(void) + goto error0; + } + ++ /* ++ * If the system is using ACPI then we can be reasonably ++ * confident that any regulators are managed by the firmware ++ * so tell the regulator core it has everything it needs to ++ * know. ++ */ ++ regulator_has_full_constraints(); ++ + return; + + error0: diff --git a/queue-3.12/arm-mvebu-fix-kernel-hang-in-mvebu_soc_id_init-when-of_iomap-failed.patch b/queue-3.12/arm-mvebu-fix-kernel-hang-in-mvebu_soc_id_init-when-of_iomap-failed.patch new file mode 100644 index 00000000000..0c4c6e5fcbd --- /dev/null +++ b/queue-3.12/arm-mvebu-fix-kernel-hang-in-mvebu_soc_id_init-when-of_iomap-failed.patch @@ -0,0 +1,35 @@ +From dc4910d9e93f8cc56b190dd8fc9e789135978216 Mon Sep 17 00:00:00 2001 +From: Gregory CLEMENT +Date: Mon, 20 Jan 2014 15:59:50 +0100 +Subject: ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed + +From: Gregory CLEMENT + +commit dc4910d9e93f8cc56b190dd8fc9e789135978216 upstream. + +When pci_base is accessed whereas it has not been properly mapped by +of_iomap() the kernel hang. The check of this pointer made an improper +use of IS_ERR() instead of comparing to NULL. This patch fix this +issue. + +Signed-off-by: Gregory CLEMENT +Reported-by: Ezequiel Garcia +Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support) +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-mvebu/mvebu-soc-id.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/mach-mvebu/mvebu-soc-id.c ++++ b/arch/arm/mach-mvebu/mvebu-soc-id.c +@@ -88,7 +88,7 @@ static int __init mvebu_soc_id_init(void + } + + pci_base = of_iomap(child, 0); +- if (IS_ERR(pci_base)) { ++ if (pci_base == NULL) { + pr_err("cannot map registers\n"); + ret = -ENOMEM; + goto res_ioremap; diff --git a/queue-3.12/arm-orion-provide-c-style-interrupt-handler-for-multi_irq_handler.patch b/queue-3.12/arm-orion-provide-c-style-interrupt-handler-for-multi_irq_handler.patch new file mode 100644 index 00000000000..5fa9987b501 --- /dev/null +++ b/queue-3.12/arm-orion-provide-c-style-interrupt-handler-for-multi_irq_handler.patch @@ -0,0 +1,102 @@ +From f28d7de6bd4d41774744e011141945affa127da4 Mon Sep 17 00:00:00 2001 +From: Sebastian Hesselbarth +Date: Thu, 16 Jan 2014 09:10:31 +0100 +Subject: ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER + +From: Sebastian Hesselbarth + +commit f28d7de6bd4d41774744e011141945affa127da4 upstream. + +DT-enabled Marvell Kirkwood and Dove SoCs make use of an irqchip +driver. As expected for irqchip drivers, it uses a C-style +interrupt handler and therefore selects MULTI_IRQ_HANDLER. + +Now, compiling a kernel with both non-DT and DT support enabled, +selecting MULTI_IRQ_HANDLER will break ASM irq handler used by +non-DT boards. + +Therefore, we provide a C-style irq handler even for non-DT boards, +if MULTI_IRQ_HANDLER is set. By installing the C-style irq handler +in orion_irq_init this is transparent to all non-DT board files. + +While the regression report was filed on Marvell Kirkwood, also +Marvell Dove non-DT boards are affected and fixed by this patch. + +Signed-off-by: Sebastian Hesselbarth +Tested-by: Ian Campbell +Reported-by: Ian Campbell +Fixes: 2326f04321a9 ("ARM: kirkwood: convert to DT irqchip and clocksource") +Fixes: f07d73e33d0e ("ARM: dove: convert to DT irqchip and clocksource") +Acked-by: Andrew Lunn +Signed-off-by: Jason Cooper +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/plat-orion/irq.c | 47 ++++++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 47 insertions(+) + +--- a/arch/arm/plat-orion/irq.c ++++ b/arch/arm/plat-orion/irq.c +@@ -15,8 +15,51 @@ + #include + #include + #include ++#include + #include + #include ++#include ++ ++#ifdef CONFIG_MULTI_IRQ_HANDLER ++/* ++ * Compiling with both non-DT and DT support enabled, will ++ * break asm irq handler used by non-DT boards. Therefore, ++ * we provide a C-style irq handler even for non-DT boards, ++ * if MULTI_IRQ_HANDLER is set. ++ * ++ * Notes: ++ * - this is prepared for Kirkwood and Dove only, update ++ * accordingly if you add Orion5x or MV78x00. ++ * - Orion5x uses different macro names and has only one ++ * set of CAUSE/MASK registers. ++ * - MV78x00 uses the same macro names but has a third ++ * set of CAUSE/MASK registers. ++ * ++ */ ++ ++static void __iomem *orion_irq_base = IRQ_VIRT_BASE; ++ ++asmlinkage void ++__exception_irq_entry orion_legacy_handle_irq(struct pt_regs *regs) ++{ ++ u32 stat; ++ ++ stat = readl_relaxed(orion_irq_base + IRQ_CAUSE_LOW_OFF); ++ stat &= readl_relaxed(orion_irq_base + IRQ_MASK_LOW_OFF); ++ if (stat) { ++ unsigned int hwirq = __fls(stat); ++ handle_IRQ(hwirq, regs); ++ return; ++ } ++ stat = readl_relaxed(orion_irq_base + IRQ_CAUSE_HIGH_OFF); ++ stat &= readl_relaxed(orion_irq_base + IRQ_MASK_HIGH_OFF); ++ if (stat) { ++ unsigned int hwirq = 32 + __fls(stat); ++ handle_IRQ(hwirq, regs); ++ return; ++ } ++} ++#endif + + void __init orion_irq_init(unsigned int irq_start, void __iomem *maskaddr) + { +@@ -35,6 +78,10 @@ void __init orion_irq_init(unsigned int + ct->chip.irq_unmask = irq_gc_mask_set_bit; + irq_setup_generic_chip(gc, IRQ_MSK(32), IRQ_GC_INIT_MASK_CACHE, + IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE); ++ ++#ifdef CONFIG_MULTI_IRQ_HANDLER ++ set_handle_irq(orion_legacy_handle_irq); ++#endif + } + + #ifdef CONFIG_OF diff --git a/queue-3.12/series b/queue-3.12/series index 5a49429c3ac..5b546b6037e 100644 --- a/queue-3.12/series +++ b/queue-3.12/series @@ -22,3 +22,9 @@ mm-don-t-lose-the-soft_dirty-flag-on-mprotect.patch mmc-fix-host-release-issue-after-discard-operation.patch mmc-atmel-mci-fix-timeout-errors-in-sdio-mode-when-using-dma.patch mmc-core-sd-implement-proper-support-for-sd3.0-au-sizes.patch +arm-orion-provide-c-style-interrupt-handler-for-multi_irq_handler.patch +arm-mvebu-fix-kernel-hang-in-mvebu_soc_id_init-when-of_iomap-failed.patch +slub-fix-calculation-of-cpu-slabs.patch +turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch +turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch +acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch diff --git a/queue-3.12/slub-fix-calculation-of-cpu-slabs.patch b/queue-3.12/slub-fix-calculation-of-cpu-slabs.patch new file mode 100644 index 00000000000..319b6746536 --- /dev/null +++ b/queue-3.12/slub-fix-calculation-of-cpu-slabs.patch @@ -0,0 +1,54 @@ +From 8afb1474db4701d1ab80cd8251137a3260e6913e Mon Sep 17 00:00:00 2001 +From: Li Zefan +Date: Tue, 10 Sep 2013 11:43:37 +0800 +Subject: slub: Fix calculation of cpu slabs + +From: Li Zefan + +commit 8afb1474db4701d1ab80cd8251137a3260e6913e upstream. + + /sys/kernel/slab/:t-0000048 # cat cpu_slabs + 231 N0=16 N1=215 + /sys/kernel/slab/:t-0000048 # cat slabs + 145 N0=36 N1=109 + +See, the number of slabs is smaller than that of cpu slabs. + +The bug was introduced by commit 49e2258586b423684f03c278149ab46d8f8b6700 +("slub: per cpu cache for partial pages"). + +We should use page->pages instead of page->pobjects when calculating +the number of cpu partial slabs. This also fixes the mapping of slabs +and nodes. + +As there's no variable storing the number of total/active objects in +cpu partial slabs, and we don't have user interfaces requiring those +statistics, I just add WARN_ON for those cases. + +Acked-by: Christoph Lameter +Reviewed-by: Wanpeng Li +Signed-off-by: Li Zefan +Signed-off-by: Pekka Enberg +Signed-off-by: Greg Kroah-Hartman + +--- + mm/slub.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -4272,7 +4272,13 @@ static ssize_t show_slab_objects(struct + + page = ACCESS_ONCE(c->partial); + if (page) { +- x = page->pobjects; ++ node = page_to_nid(page); ++ if (flags & SO_TOTAL) ++ WARN_ON_ONCE(1); ++ else if (flags & SO_OBJECTS) ++ WARN_ON_ONCE(1); ++ else ++ x = page->pages; + total += x; + nodes[node] += x; + } diff --git a/queue-3.12/turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch b/queue-3.12/turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch new file mode 100644 index 00000000000..1146ddea4a3 --- /dev/null +++ b/queue-3.12/turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch @@ -0,0 +1,68 @@ +From b731f3119de57144e16c19fd593b8daeb637843e Mon Sep 17 00:00:00 2001 +From: Josh Triplett +Date: Tue, 20 Aug 2013 17:20:12 -0700 +Subject: turbostat: Don't put unprocessed uapi headers in the include path + +From: Josh Triplett + +commit b731f3119de57144e16c19fd593b8daeb637843e upstream. + +turbostat's Makefile puts arch/x86/include/uapi/ in the include path, so +that it can include from it. It isn't in general safe to +include even uapi headers directly from the kernel tree without +processing them through scripts/headers_install.sh, but asm/msr.h +happens to work. + +However, that include path can break with some versions of system +headers, by overriding some system headers with the unprocessed versions +directly from the kernel source. For instance: + +In file included from /build/x86-generic/usr/include/bits/sigcontext.h:28:0, + from /build/x86-generic/usr/include/signal.h:339, + from /build/x86-generic/usr/include/sys/wait.h:31, + from turbostat.c:27: +../../../../arch/x86/include/uapi/asm/sigcontext.h:4:28: fatal error: linux/compiler.h: No such file or directory + +This occurs because the system bits/sigcontext.h on that build system +includes , and asm/sigcontext.h in the kernel source +includes , which scripts/headers_install.sh would have +filtered out. + +Since turbostat really only wants a single header, just include that one +header rather than putting an entire directory of kernel headers on the +include path. + +In the process, switch from msr.h to msr-index.h, since turbostat just +wants the MSR numbers. + +Signed-off-by: Josh Triplett +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + tools/power/x86/turbostat/Makefile | 2 +- + tools/power/x86/turbostat/turbostat.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/tools/power/x86/turbostat/Makefile ++++ b/tools/power/x86/turbostat/Makefile +@@ -5,7 +5,7 @@ DESTDIR := + + turbostat : turbostat.c + CFLAGS += -Wall +-CFLAGS += -I../../../../arch/x86/include/uapi/ ++CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"' + + %: %.c + @mkdir -p $(BUILD_OUTPUT) +--- a/tools/power/x86/turbostat/turbostat.c ++++ b/tools/power/x86/turbostat/turbostat.c +@@ -20,7 +20,7 @@ + */ + + #define _GNU_SOURCE +-#include ++#include MSRHEADER + #include + #include + #include diff --git a/queue-3.12/turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch b/queue-3.12/turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch new file mode 100644 index 00000000000..cf8c1cd677f --- /dev/null +++ b/queue-3.12/turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch @@ -0,0 +1,88 @@ +From 2b92865e648ce04a39fda4f903784a5d01ecb0dc Mon Sep 17 00:00:00 2001 +From: Josh Triplett +Date: Tue, 20 Aug 2013 17:20:14 -0700 +Subject: turbostat: Use GCC's CPUID functions to support PIC +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Josh Triplett + +commit 2b92865e648ce04a39fda4f903784a5d01ecb0dc upstream. + +turbostat uses inline assembly to call cpuid. On 32-bit x86, on systems +that have certain security features enabled by default that make -fPIC +the default, this causes a build error: + +turbostat.c: In function ‘check_cpuid’: +turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’ + asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx"); + ^ + +GCC provides a header cpuid.h, containing a __get_cpuid function that +works with both PIC and non-PIC. (On PIC, it saves and restores ebx +around the cpuid instruction.) Use that instead. + +Signed-off-by: Josh Triplett +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + tools/power/x86/turbostat/turbostat.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/tools/power/x86/turbostat/turbostat.c ++++ b/tools/power/x86/turbostat/turbostat.c +@@ -35,6 +35,7 @@ + #include + #include + #include ++#include + + char *proc_stat = "/proc/stat"; + unsigned int interval_sec = 5; /* set with -i interval_sec */ +@@ -1894,7 +1895,7 @@ void check_cpuid() + + eax = ebx = ecx = edx = 0; + +- asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0)); ++ __get_cpuid(0, &max_level, &ebx, &ecx, &edx); + + if (ebx == 0x756e6547 && edx == 0x49656e69 && ecx == 0x6c65746e) + genuine_intel = 1; +@@ -1903,7 +1904,7 @@ void check_cpuid() + fprintf(stderr, "CPUID(0): %.4s%.4s%.4s ", + (char *)&ebx, (char *)&edx, (char *)&ecx); + +- asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx"); ++ __get_cpuid(1, &fms, &ebx, &ecx, &edx); + family = (fms >> 8) & 0xf; + model = (fms >> 4) & 0xf; + stepping = fms & 0xf; +@@ -1925,7 +1926,7 @@ void check_cpuid() + * This check is valid for both Intel and AMD. + */ + ebx = ecx = edx = 0; +- asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0x80000000)); ++ __get_cpuid(0x80000000, &max_level, &ebx, &ecx, &edx); + + if (max_level < 0x80000007) { + fprintf(stderr, "CPUID: no invariant TSC (max_level 0x%x)\n", max_level); +@@ -1936,7 +1937,7 @@ void check_cpuid() + * Non-Stop TSC is advertised by CPUID.EAX=0x80000007: EDX.bit8 + * this check is valid for both Intel and AMD + */ +- asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0x80000007)); ++ __get_cpuid(0x80000007, &eax, &ebx, &ecx, &edx); + has_invariant_tsc = edx & (1 << 8); + + if (!has_invariant_tsc) { +@@ -1949,7 +1950,7 @@ void check_cpuid() + * this check is valid for both Intel and AMD + */ + +- asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0x6)); ++ __get_cpuid(0x6, &eax, &ebx, &ecx, &edx); + has_aperf = ecx & (1 << 0); + do_dts = eax & (1 << 0); + do_ptm = eax & (1 << 6);