From: Greg Kroah-Hartman Date: Sat, 2 May 2015 16:43:43 +0000 (+0200) Subject: 3.10-stable patches X-Git-Tag: v3.10.77~36 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=26bf85db885dade08cfb9dbef3dd770bf304baba;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: acpica-utilities-split-io-address-types-from-data-type-models.patch drivers-parport-kconfig-exclude-arm64-for-parport_pc.patch gpio-mvebu-fix-mask-unmask-managment-per-irq-chip-type.patch powerpc-perf-cap-64bit-userspace-backtraces-to-perf_max_stack_depth.patch scsi-storvsc-fix-a-bug-in-copy_from_bounce_buffer.patch tools-power-turbostat-use-curdir-instead-of-pwd-and-add-support-for-o-option-in-makefile.patch ubi-account-for-bitflips-in-both-the-vid-header-and-data.patch ubi-fix-check-for-too-many-bytes.patch ubi-fix-out-of-bounds-write.patch ubi-initialize-leb-number-variable.patch xtensa-provide-__nr_sync_file_range2-instead-of-__nr_sync_file_range.patch xtensa-xtfpga-fix-hardware-lockup-caused-by-lcd-driver.patch --- diff --git a/queue-3.10/acpica-utilities-split-io-address-types-from-data-type-models.patch b/queue-3.10/acpica-utilities-split-io-address-types-from-data-type-models.patch new file mode 100644 index 00000000000..7632edab33b --- /dev/null +++ b/queue-3.10/acpica-utilities-split-io-address-types-from-data-type-models.patch @@ -0,0 +1,110 @@ +From 2b8760100e1de69b6ff004c986328a82947db4ad Mon Sep 17 00:00:00 2001 +From: Lv Zheng +Date: Mon, 13 Apr 2015 11:48:58 +0800 +Subject: ACPICA: Utilities: split IO address types from data type models. + +From: Lv Zheng + +commit 2b8760100e1de69b6ff004c986328a82947db4ad upstream. + +ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 + +It is reported that on a physically 64-bit addressed machine, 32-bit kernel +can trigger crashes in accessing the memory regions that are beyond the +32-bit boundary. The region field's start address should still be 32-bit +compliant, but after a calculation (adding some offsets), it may exceed the +32-bit boundary. This case is rare and buggy, but there are real BIOSes +leaked with such issues (see References below). + +This patch fixes this gap by always defining IO addresses as 64-bit, and +allows OSPMs to optimize it for a real 32-bit machine to reduce the size of +the internal objects. + +Internal acpi_physical_address usages in the structures that can be fixed +by this change include: + 1. struct acpi_object_region: + acpi_physical_address address; + 2. struct acpi_address_range: + acpi_physical_address start_address; + acpi_physical_address end_address; + 3. struct acpi_mem_space_context; + acpi_physical_address address; + 4. struct acpi_table_desc + acpi_physical_address address; +See known issues 1 for other usages. + +Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer +from same problem, so this patch changes it accordingly. + +For iasl, it will enforce acpi_physical_address as 32-bit to generate +32-bit OSPM compatible tables on 32-bit platforms, we need to define +ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. + +Known issues: + 1. Cleanup of mapped virtual address + In struct acpi_mem_space_context, acpi_physical_address is used as a virtual + address: + acpi_physical_address mapped_physical_address; + It is better to introduce acpi_virtual_address or use acpi_size instead. + This patch doesn't make such a change. Because this should be done along + with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). + There should be no functional problem to leave this unchanged except + that only this structure is enlarged unexpectedly. + +Link: https://github.com/acpica/acpica/commit/aacf863c +Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 +Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501 +Reported-and-tested-by: Paul Menzel +Reported-and-tested-by: Sial Nije +Signed-off-by: Lv Zheng +Signed-off-by: Bob Moore +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + include/acpi/actypes.h | 20 ++++++++++++++++++++ + include/acpi/platform/acenv.h | 1 + + 2 files changed, 21 insertions(+) + +--- a/include/acpi/actypes.h ++++ b/include/acpi/actypes.h +@@ -198,9 +198,29 @@ typedef int INT32; + typedef s32 acpi_native_int; + + typedef u32 acpi_size; ++ ++#ifdef ACPI_32BIT_PHYSICAL_ADDRESS ++ ++/* ++ * OSPMs can define this to shrink the size of the structures for 32-bit ++ * none PAE environment. ASL compiler may always define this to generate ++ * 32-bit OSPM compliant tables. ++ */ + typedef u32 acpi_io_address; + typedef u32 acpi_physical_address; + ++#else /* ACPI_32BIT_PHYSICAL_ADDRESS */ ++ ++/* ++ * It is reported that, after some calculations, the physical addresses can ++ * wrap over the 32-bit boundary on 32-bit PAE environment. ++ * https://bugzilla.kernel.org/show_bug.cgi?id=87971 ++ */ ++typedef u64 acpi_io_address; ++typedef u64 acpi_physical_address; ++ ++#endif /* ACPI_32BIT_PHYSICAL_ADDRESS */ ++ + #define ACPI_MAX_PTR ACPI_UINT32_MAX + #define ACPI_SIZE_MAX ACPI_UINT32_MAX + +--- a/include/acpi/platform/acenv.h ++++ b/include/acpi/platform/acenv.h +@@ -76,6 +76,7 @@ + #define ACPI_LARGE_NAMESPACE_NODE + #define ACPI_DATA_TABLE_DISASSEMBLY + #define ACPI_SINGLE_THREADED ++#define ACPI_32BIT_PHYSICAL_ADDRESS + #endif + + /* acpi_exec configuration. Multithreaded with full AML debugger */ diff --git a/queue-3.10/drivers-parport-kconfig-exclude-arm64-for-parport_pc.patch b/queue-3.10/drivers-parport-kconfig-exclude-arm64-for-parport_pc.patch new file mode 100644 index 00000000000..974da4af980 --- /dev/null +++ b/queue-3.10/drivers-parport-kconfig-exclude-arm64-for-parport_pc.patch @@ -0,0 +1,40 @@ +From linux@roeck-us.net Sat May 2 18:20:25 2015 +From: Guenter Roeck +Date: Wed, 22 Apr 2015 22:23:54 -0700 +Subject: drivers: parport: Kconfig: exclude arm64 for PARPORT_PC +To: stable@vger.kernel.org +Cc: Greg Kroah-Hartman , Jiri Slaby , Guenter Roeck +Message-ID: <1429766634-26546-1-git-send-email-linux@roeck-us.net> + +From: Guenter Roeck + +Fix build problem seen with arm64:allmodconfig. + +drivers/parport/parport_pc.c:67:25: fatal error: asm/parport.h: No such file or +directory + +arm64 does not support PARPORT_PC. + +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman +--- +Please consider applying this patch to 3.10 and 3.12 (only). + +There is no matching upstream commit; the problem was fixed differently +in later kernel versions. The upstream fix would require ~10 separate +patches and thus add more risk than it is worth (in my opinion). + + drivers/parport/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/parport/Kconfig ++++ b/drivers/parport/Kconfig +@@ -37,7 +37,7 @@ config PARPORT_PC + tristate "PC-style hardware" + depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \ + (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \ +- !XTENSA && !CRIS && !H8300 ++ !XTENSA && !CRIS && !H8300 && !ARM64 + + ---help--- + You should say Y here if you have a PC-style parallel port. All diff --git a/queue-3.10/gpio-mvebu-fix-mask-unmask-managment-per-irq-chip-type.patch b/queue-3.10/gpio-mvebu-fix-mask-unmask-managment-per-irq-chip-type.patch new file mode 100644 index 00000000000..7d496d187c6 --- /dev/null +++ b/queue-3.10/gpio-mvebu-fix-mask-unmask-managment-per-irq-chip-type.patch @@ -0,0 +1,108 @@ +From 61819549f572edd7fce53f228c0d8420cdc85f71 Mon Sep 17 00:00:00 2001 +From: Gregory CLEMENT +Date: Thu, 2 Apr 2015 17:11:11 +0200 +Subject: gpio: mvebu: Fix mask/unmask managment per irq chip type + +From: Gregory CLEMENT + +commit 61819549f572edd7fce53f228c0d8420cdc85f71 upstream. + +Level IRQ handlers and edge IRQ handler are managed by tow different +sets of registers. But currently the driver uses the same mask for the +both registers. It lead to issues with the following scenario: + +First, an IRQ is requested on a GPIO to be triggered on front. After, +this an other IRQ is requested for a GPIO of the same bank but +triggered on level. Then the first one will be also setup to be +triggered on level. It leads to an interrupt storm. + +The different kind of handler are already associated with two +different irq chip type. With this patch the driver uses a private +mask for each one which solves this issue. + +It has been tested on an Armada XP based board and on an Armada 375 +board. For the both boards, with this patch is applied, there is no +such interrupt storm when running the previous scenario. + +This bug was already fixed but in a different way in the legacy +version of this driver by Evgeniy Dushistov: +9ece8839b1277fb9128ff6833411614ab6c88d68 "ARM: orion: Fix for certain +sequence of request_irq can cause irq storm". The fact the new version +of the gpio drive could be affected had been discussed there: +http://thread.gmane.org/gmane.linux.ports.arm.kernel/344670/focus=364012 + +Reported-by: Evgeniy A. Dushistov +Signed-off-by: Gregory CLEMENT +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpio-mvebu.c | 24 ++++++++++++++++-------- + 1 file changed, 16 insertions(+), 8 deletions(-) + +--- a/drivers/gpio/gpio-mvebu.c ++++ b/drivers/gpio/gpio-mvebu.c +@@ -304,11 +304,13 @@ static void mvebu_gpio_edge_irq_mask(str + { + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); + struct mvebu_gpio_chip *mvchip = gc->private; ++ struct irq_chip_type *ct = irq_data_get_chip_type(d); + u32 mask = 1 << (d->irq - gc->irq_base); + + irq_gc_lock(gc); +- gc->mask_cache &= ~mask; +- writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip)); ++ ct->mask_cache_priv &= ~mask; ++ ++ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip)); + irq_gc_unlock(gc); + } + +@@ -316,11 +318,13 @@ static void mvebu_gpio_edge_irq_unmask(s + { + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); + struct mvebu_gpio_chip *mvchip = gc->private; ++ struct irq_chip_type *ct = irq_data_get_chip_type(d); ++ + u32 mask = 1 << (d->irq - gc->irq_base); + + irq_gc_lock(gc); +- gc->mask_cache |= mask; +- writel_relaxed(gc->mask_cache, mvebu_gpioreg_edge_mask(mvchip)); ++ ct->mask_cache_priv |= mask; ++ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_edge_mask(mvchip)); + irq_gc_unlock(gc); + } + +@@ -328,11 +332,13 @@ static void mvebu_gpio_level_irq_mask(st + { + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); + struct mvebu_gpio_chip *mvchip = gc->private; ++ struct irq_chip_type *ct = irq_data_get_chip_type(d); ++ + u32 mask = 1 << (d->irq - gc->irq_base); + + irq_gc_lock(gc); +- gc->mask_cache &= ~mask; +- writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip)); ++ ct->mask_cache_priv &= ~mask; ++ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip)); + irq_gc_unlock(gc); + } + +@@ -340,11 +346,13 @@ static void mvebu_gpio_level_irq_unmask( + { + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); + struct mvebu_gpio_chip *mvchip = gc->private; ++ struct irq_chip_type *ct = irq_data_get_chip_type(d); ++ + u32 mask = 1 << (d->irq - gc->irq_base); + + irq_gc_lock(gc); +- gc->mask_cache |= mask; +- writel_relaxed(gc->mask_cache, mvebu_gpioreg_level_mask(mvchip)); ++ ct->mask_cache_priv |= mask; ++ writel_relaxed(ct->mask_cache_priv, mvebu_gpioreg_level_mask(mvchip)); + irq_gc_unlock(gc); + } + diff --git a/queue-3.10/powerpc-perf-cap-64bit-userspace-backtraces-to-perf_max_stack_depth.patch b/queue-3.10/powerpc-perf-cap-64bit-userspace-backtraces-to-perf_max_stack_depth.patch new file mode 100644 index 00000000000..5868e4d9e1e --- /dev/null +++ b/queue-3.10/powerpc-perf-cap-64bit-userspace-backtraces-to-perf_max_stack_depth.patch @@ -0,0 +1,31 @@ +From 9a5cbce421a283e6aea3c4007f141735bf9da8c3 Mon Sep 17 00:00:00 2001 +From: Anton Blanchard +Date: Tue, 14 Apr 2015 07:51:03 +1000 +Subject: powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH + +From: Anton Blanchard + +commit 9a5cbce421a283e6aea3c4007f141735bf9da8c3 upstream. + +We cap 32bit userspace backtraces to PERF_MAX_STACK_DEPTH +(currently 127), but we forgot to do the same for 64bit backtraces. + +Signed-off-by: Anton Blanchard +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/perf/callchain.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/perf/callchain.c ++++ b/arch/powerpc/perf/callchain.c +@@ -243,7 +243,7 @@ static void perf_callchain_user_64(struc + sp = regs->gpr[1]; + perf_callchain_store(entry, next_ip); + +- for (;;) { ++ while (entry->nr < PERF_MAX_STACK_DEPTH) { + fp = (unsigned long __user *) sp; + if (!valid_user_sp(sp, 1) || read_user_stack_64(fp, &next_sp)) + return; diff --git a/queue-3.10/scsi-storvsc-fix-a-bug-in-copy_from_bounce_buffer.patch b/queue-3.10/scsi-storvsc-fix-a-bug-in-copy_from_bounce_buffer.patch new file mode 100644 index 00000000000..bd28cc147f5 --- /dev/null +++ b/queue-3.10/scsi-storvsc-fix-a-bug-in-copy_from_bounce_buffer.patch @@ -0,0 +1,53 @@ +From 8de580742fee8bc34d116f57a20b22b9a5f08403 Mon Sep 17 00:00:00 2001 +From: "K. Y. Srinivasan" +Date: Fri, 27 Mar 2015 00:27:18 -0700 +Subject: scsi: storvsc: Fix a bug in copy_from_bounce_buffer() + +From: "K. Y. Srinivasan" + +commit 8de580742fee8bc34d116f57a20b22b9a5f08403 upstream. + +We may exit this function without properly freeing up the maapings +we may have acquired. Fix the bug. + +Signed-off-by: K. Y. Srinivasan +Reviewed-by: Long Li +Signed-off-by: James Bottomley +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/storvsc_drv.c | 15 ++++++++------- + 1 file changed, 8 insertions(+), 7 deletions(-) + +--- a/drivers/scsi/storvsc_drv.c ++++ b/drivers/scsi/storvsc_drv.c +@@ -631,21 +631,22 @@ static unsigned int copy_to_bounce_buffe + if (bounce_sgl[j].length == PAGE_SIZE) { + /* full..move to next entry */ + sg_kunmap_atomic(bounce_addr); ++ bounce_addr = 0; + j++; ++ } + +- /* if we need to use another bounce buffer */ +- if (srclen || i != orig_sgl_count - 1) +- bounce_addr = sg_kmap_atomic(bounce_sgl,j); ++ /* if we need to use another bounce buffer */ ++ if (srclen && bounce_addr == 0) ++ bounce_addr = sg_kmap_atomic(bounce_sgl, j); + +- } else if (srclen == 0 && i == orig_sgl_count - 1) { +- /* unmap the last bounce that is < PAGE_SIZE */ +- sg_kunmap_atomic(bounce_addr); +- } + } + + sg_kunmap_atomic(src_addr - orig_sgl[i].offset); + } + ++ if (bounce_addr) ++ sg_kunmap_atomic(bounce_addr); ++ + local_irq_restore(flags); + + return total_copied; diff --git a/queue-3.10/series b/queue-3.10/series index 88fe9361624..c71a51e0ea7 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -34,3 +34,15 @@ console-disable-vga-text-console-support-on-cris.patch video-vgacon-don-t-build-on-arm64.patch arm64-kernel-compiling-issue-need-delete.patch ext4-make-fsync-to-sync-parent-dir-in-no-journal-for-real-this-time.patch +powerpc-perf-cap-64bit-userspace-backtraces-to-perf_max_stack_depth.patch +tools-power-turbostat-use-curdir-instead-of-pwd-and-add-support-for-o-option-in-makefile.patch +ubi-account-for-bitflips-in-both-the-vid-header-and-data.patch +ubi-fix-out-of-bounds-write.patch +ubi-initialize-leb-number-variable.patch +ubi-fix-check-for-too-many-bytes.patch +scsi-storvsc-fix-a-bug-in-copy_from_bounce_buffer.patch +drivers-parport-kconfig-exclude-arm64-for-parport_pc.patch +acpica-utilities-split-io-address-types-from-data-type-models.patch +xtensa-xtfpga-fix-hardware-lockup-caused-by-lcd-driver.patch +xtensa-provide-__nr_sync_file_range2-instead-of-__nr_sync_file_range.patch +gpio-mvebu-fix-mask-unmask-managment-per-irq-chip-type.patch diff --git a/queue-3.10/tools-power-turbostat-use-curdir-instead-of-pwd-and-add-support-for-o-option-in-makefile.patch b/queue-3.10/tools-power-turbostat-use-curdir-instead-of-pwd-and-add-support-for-o-option-in-makefile.patch new file mode 100644 index 00000000000..544ba2a60e8 --- /dev/null +++ b/queue-3.10/tools-power-turbostat-use-curdir-instead-of-pwd-and-add-support-for-o-option-in-makefile.patch @@ -0,0 +1,55 @@ +From f82263c6989c31ae9b94cecddffb29dcbec38710 Mon Sep 17 00:00:00 2001 +From: Thomas D +Date: Mon, 5 Jan 2015 21:37:23 +0100 +Subject: tools/power turbostat: Use $(CURDIR) instead of $(PWD) and add support for O= option in Makefile + +From: Thomas D + +commit f82263c6989c31ae9b94cecddffb29dcbec38710 upstream. + +Since commit ee0778a30153 +("tools/power: turbostat: make Makefile a bit more capable") +turbostat's Makefile is using + + [...] + BUILD_OUTPUT := $(PWD) + [...] + +which obviously causes trouble when building "turbostat" with + + make -C /usr/src/linux/tools/power/x86/turbostat ARCH=x86 turbostat + +because GNU make does not update nor guarantee that $PWD is set. + +This patch changes the Makefile to use $CURDIR instead, which GNU make +guarantees to set and update (i.e. when using "make -C ...") and also +adds support for the O= option (see "make help" in your root of your +kernel source tree for more details). + +Link: https://bugs.gentoo.org/show_bug.cgi?id=533918 +Fixes: ee0778a30153 ("tools/power: turbostat: make Makefile a bit more capable") +Signed-off-by: Thomas D. +Cc: Mark Asselstine +Signed-off-by: Len Brown +Signed-off-by: Greg Kroah-Hartman + +--- + tools/power/x86/turbostat/Makefile | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/tools/power/x86/turbostat/Makefile ++++ b/tools/power/x86/turbostat/Makefile +@@ -1,8 +1,12 @@ + CC = $(CROSS_COMPILE)gcc +-BUILD_OUTPUT := $(PWD) ++BUILD_OUTPUT := $(CURDIR) + PREFIX := /usr + DESTDIR := + ++ifeq ("$(origin O)", "command line") ++ BUILD_OUTPUT := $(O) ++endif ++ + turbostat : turbostat.c + CFLAGS += -Wall + CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"' diff --git a/queue-3.10/ubi-account-for-bitflips-in-both-the-vid-header-and-data.patch b/queue-3.10/ubi-account-for-bitflips-in-both-the-vid-header-and-data.patch new file mode 100644 index 00000000000..9029cfb013f --- /dev/null +++ b/queue-3.10/ubi-account-for-bitflips-in-both-the-vid-header-and-data.patch @@ -0,0 +1,34 @@ +From 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Sat, 28 Feb 2015 02:23:25 -0800 +Subject: UBI: account for bitflips in both the VID header and data + +From: Brian Norris + +commit 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 upstream. + +We are completely discarding the earlier value of 'bitflips', which +could reflect a bitflip found in ubi_io_read_vid_hdr(). Let's use the +bitwise OR of header and data 'bitflip' statuses instead. + +Coverity CID #1226856 + +Signed-off-by: Brian Norris +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ubi/attach.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mtd/ubi/attach.c ++++ b/drivers/mtd/ubi/attach.c +@@ -408,7 +408,7 @@ int ubi_compare_lebs(struct ubi_device * + second_is_newer = !second_is_newer; + } else { + dbg_bld("PEB %d CRC is OK", pnum); +- bitflips = !!err; ++ bitflips |= !!err; + } + mutex_unlock(&ubi->buf_mutex); + diff --git a/queue-3.10/ubi-fix-check-for-too-many-bytes.patch b/queue-3.10/ubi-fix-check-for-too-many-bytes.patch new file mode 100644 index 00000000000..e3cac36e4ff --- /dev/null +++ b/queue-3.10/ubi-fix-check-for-too-many-bytes.patch @@ -0,0 +1,35 @@ +From 299d0c5b27346a77a0777c993372bf8777d4f2e5 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Sat, 28 Feb 2015 02:23:28 -0800 +Subject: UBI: fix check for "too many bytes" + +From: Brian Norris + +commit 299d0c5b27346a77a0777c993372bf8777d4f2e5 upstream. + +The comparison from the previous line seems to have been erroneously +(partially) copied-and-pasted onto the next. The second line should be +checking req.bytes, not req.lnum. + +Coverity CID #139400 + +Signed-off-by: Brian Norris +[rw: Fixed comparison] +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ubi/cdev.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mtd/ubi/cdev.c ++++ b/drivers/mtd/ubi/cdev.c +@@ -475,7 +475,7 @@ static long vol_cdev_ioctl(struct file * + /* Validate the request */ + err = -EINVAL; + if (req.lnum < 0 || req.lnum >= vol->reserved_pebs || +- req.bytes < 0 || req.lnum >= vol->usable_leb_size) ++ req.bytes < 0 || req.bytes > vol->usable_leb_size) + break; + + err = get_exclusive(desc); diff --git a/queue-3.10/ubi-fix-out-of-bounds-write.patch b/queue-3.10/ubi-fix-out-of-bounds-write.patch new file mode 100644 index 00000000000..c6b45c8a14a --- /dev/null +++ b/queue-3.10/ubi-fix-out-of-bounds-write.patch @@ -0,0 +1,34 @@ +From d74adbdb9abf0d2506a6c4afa534d894f28b763f Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Sat, 28 Feb 2015 02:23:26 -0800 +Subject: UBI: fix out of bounds write + +From: Brian Norris + +commit d74adbdb9abf0d2506a6c4afa534d894f28b763f upstream. + +If aeb->len >= vol->reserved_pebs, we should not be writing aeb into the +PEB->LEB mapping. + +Caught by Coverity, CID #711212. + +Signed-off-by: Brian Norris +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ubi/eba.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/ubi/eba.c ++++ b/drivers/mtd/ubi/eba.c +@@ -1362,7 +1362,8 @@ int ubi_eba_init(struct ubi_device *ubi, + * during re-size. + */ + ubi_move_aeb_to_list(av, aeb, &ai->erase); +- vol->eba_tbl[aeb->lnum] = aeb->pnum; ++ else ++ vol->eba_tbl[aeb->lnum] = aeb->pnum; + } + } + diff --git a/queue-3.10/ubi-initialize-leb-number-variable.patch b/queue-3.10/ubi-initialize-leb-number-variable.patch new file mode 100644 index 00000000000..64383cd3ffb --- /dev/null +++ b/queue-3.10/ubi-initialize-leb-number-variable.patch @@ -0,0 +1,38 @@ +From f16db8071ce18819fbd705ddcc91c6f392fb61f8 Mon Sep 17 00:00:00 2001 +From: Brian Norris +Date: Sat, 28 Feb 2015 02:23:27 -0800 +Subject: UBI: initialize LEB number variable + +From: Brian Norris + +commit f16db8071ce18819fbd705ddcc91c6f392fb61f8 upstream. + +In some of the 'out_not_moved' error paths, lnum may be used +uninitialized. Don't ignore the warning; let's fix it. + +This uninitialized variable doesn't have much visible effect in the end, +since we just schedule the PEB for erasure, and its LEB number doesn't +really matter (it just gets printed in debug messages). But let's get it +straight anyway. + +Coverity CID #113449 + +Signed-off-by: Brian Norris +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ubi/wl.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mtd/ubi/wl.c ++++ b/drivers/mtd/ubi/wl.c +@@ -999,7 +999,7 @@ static int wear_leveling_worker(struct u + int cancel) + { + int err, scrubbing = 0, torture = 0, protect = 0, erroneous = 0; +- int vol_id = -1, uninitialized_var(lnum); ++ int vol_id = -1, lnum = -1; + #ifdef CONFIG_MTD_UBI_FASTMAP + int anchor = wrk->anchor; + #endif diff --git a/queue-3.10/xtensa-provide-__nr_sync_file_range2-instead-of-__nr_sync_file_range.patch b/queue-3.10/xtensa-provide-__nr_sync_file_range2-instead-of-__nr_sync_file_range.patch new file mode 100644 index 00000000000..1eae3243766 --- /dev/null +++ b/queue-3.10/xtensa-provide-__nr_sync_file_range2-instead-of-__nr_sync_file_range.patch @@ -0,0 +1,35 @@ +From 01e84c70fe40c8111f960987bcf7f931842e6d07 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Fri, 27 Feb 2015 11:02:38 +0300 +Subject: xtensa: provide __NR_sync_file_range2 instead of __NR_sync_file_range + +From: Max Filippov + +commit 01e84c70fe40c8111f960987bcf7f931842e6d07 upstream. + +xtensa actually uses sync_file_range2 implementation, so it should +define __NR_sync_file_range2 as other architectures that use that +function. That fixes userspace interface (that apparently never worked) +and avoids special-casing xtensa in libc implementations. +See the thread ending at +http://lists.busybox.net/pipermail/uclibc/2015-February/048833.html +for more details. + +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman + +--- + arch/xtensa/include/uapi/asm/unistd.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/xtensa/include/uapi/asm/unistd.h ++++ b/arch/xtensa/include/uapi/asm/unistd.h +@@ -715,7 +715,7 @@ __SYSCALL(323, sys_process_vm_writev, 6) + __SYSCALL(324, sys_name_to_handle_at, 5) + #define __NR_open_by_handle_at 325 + __SYSCALL(325, sys_open_by_handle_at, 3) +-#define __NR_sync_file_range 326 ++#define __NR_sync_file_range2 326 + __SYSCALL(326, sys_sync_file_range2, 6) + #define __NR_perf_event_open 327 + __SYSCALL(327, sys_perf_event_open, 5) diff --git a/queue-3.10/xtensa-xtfpga-fix-hardware-lockup-caused-by-lcd-driver.patch b/queue-3.10/xtensa-xtfpga-fix-hardware-lockup-caused-by-lcd-driver.patch new file mode 100644 index 00000000000..35313cf8102 --- /dev/null +++ b/queue-3.10/xtensa-xtfpga-fix-hardware-lockup-caused-by-lcd-driver.patch @@ -0,0 +1,227 @@ +From 4949009eb8d40a441dcddcd96e101e77d31cf1b2 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Fri, 27 Feb 2015 06:28:00 +0300 +Subject: xtensa: xtfpga: fix hardware lockup caused by LCD driver + +From: Max Filippov + +commit 4949009eb8d40a441dcddcd96e101e77d31cf1b2 upstream. + +LCD driver is always built for the XTFPGA platform, but its base address +is not configurable, and is wrong for ML605/KC705. Its initialization +locks up KC705 board hardware. + +Make the whole driver optional, and its base address and bus width +configurable. Implement 4-bit bus access method. + +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman + +--- + arch/xtensa/Kconfig | 30 ++++++++ + arch/xtensa/platforms/xtfpga/Makefile | 3 + arch/xtensa/platforms/xtfpga/include/platform/hardware.h | 3 + arch/xtensa/platforms/xtfpga/include/platform/lcd.h | 15 ++++ + arch/xtensa/platforms/xtfpga/lcd.c | 55 +++++++++------ + 5 files changed, 81 insertions(+), 25 deletions(-) + +--- a/arch/xtensa/Kconfig ++++ b/arch/xtensa/Kconfig +@@ -287,6 +287,36 @@ menu "Executable file formats" + + source "fs/Kconfig.binfmt" + ++config XTFPGA_LCD ++ bool "Enable XTFPGA LCD driver" ++ depends on XTENSA_PLATFORM_XTFPGA ++ default n ++ help ++ There's a 2x16 LCD on most of XTFPGA boards, kernel may output ++ progress messages there during bootup/shutdown. It may be useful ++ during board bringup. ++ ++ If unsure, say N. ++ ++config XTFPGA_LCD_BASE_ADDR ++ hex "XTFPGA LCD base address" ++ depends on XTFPGA_LCD ++ default "0x0d0c0000" ++ help ++ Base address of the LCD controller inside KIO region. ++ Different boards from XTFPGA family have LCD controller at different ++ addresses. Please consult prototyping user guide for your board for ++ the correct address. Wrong address here may lead to hardware lockup. ++ ++config XTFPGA_LCD_8BIT_ACCESS ++ bool "Use 8-bit access to XTFPGA LCD" ++ depends on XTFPGA_LCD ++ default n ++ help ++ LCD may be connected with 4- or 8-bit interface, 8-bit access may ++ only be used with 8-bit interface. Please consult prototyping user ++ guide for your board for the correct interface width. ++ + endmenu + + source "net/Kconfig" +--- a/arch/xtensa/platforms/xtfpga/Makefile ++++ b/arch/xtensa/platforms/xtfpga/Makefile +@@ -6,4 +6,5 @@ + # + # Note 2! The CFLAGS definitions are in the main makefile... + +-obj-y = setup.o lcd.o ++obj-y += setup.o ++obj-$(CONFIG_XTFPGA_LCD) += lcd.o +--- a/arch/xtensa/platforms/xtfpga/include/platform/hardware.h ++++ b/arch/xtensa/platforms/xtfpga/include/platform/hardware.h +@@ -44,9 +44,6 @@ + + /* UART */ + #define DUART16552_PADDR (XCHAL_KIO_PADDR + 0x0D050020) +-/* LCD instruction and data addresses. */ +-#define LCD_INSTR_ADDR ((char *)IOADDR(0x0D040000)) +-#define LCD_DATA_ADDR ((char *)IOADDR(0x0D040004)) + + /* Misc. */ + #define XTFPGA_FPGAREGS_VADDR IOADDR(0x0D020000) +--- a/arch/xtensa/platforms/xtfpga/include/platform/lcd.h ++++ b/arch/xtensa/platforms/xtfpga/include/platform/lcd.h +@@ -11,10 +11,25 @@ + #ifndef __XTENSA_XTAVNET_LCD_H + #define __XTENSA_XTAVNET_LCD_H + ++#ifdef CONFIG_XTFPGA_LCD + /* Display string STR at position POS on the LCD. */ + void lcd_disp_at_pos(char *str, unsigned char pos); + + /* Shift the contents of the LCD display left or right. */ + void lcd_shiftleft(void); + void lcd_shiftright(void); ++#else ++static inline void lcd_disp_at_pos(char *str, unsigned char pos) ++{ ++} ++ ++static inline void lcd_shiftleft(void) ++{ ++} ++ ++static inline void lcd_shiftright(void) ++{ ++} ++#endif ++ + #endif +--- a/arch/xtensa/platforms/xtfpga/lcd.c ++++ b/arch/xtensa/platforms/xtfpga/lcd.c +@@ -1,50 +1,63 @@ + /* +- * Driver for the LCD display on the Tensilica LX60 Board. ++ * Driver for the LCD display on the Tensilica XTFPGA board family. ++ * http://www.mytechcorp.com/cfdata/productFile/File1/MOC-16216B-B-A0A04.pdf + * + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 2001, 2006 Tensilica Inc. ++ * Copyright (C) 2015 Cadence Design Systems Inc. + */ + +-/* +- * +- * FIXME: this code is from the examples from the LX60 user guide. +- * +- * The lcd_pause function does busy waiting, which is probably not +- * great. Maybe the code could be changed to use kernel timers, or +- * change the hardware to not need to wait. +- */ +- ++#include + #include + #include + + #include + #include +-#include + +-#define LCD_PAUSE_ITERATIONS 4000 ++/* LCD instruction and data addresses. */ ++#define LCD_INSTR_ADDR ((char *)IOADDR(CONFIG_XTFPGA_LCD_BASE_ADDR)) ++#define LCD_DATA_ADDR (LCD_INSTR_ADDR + 4) ++ + #define LCD_CLEAR 0x1 + #define LCD_DISPLAY_ON 0xc + + /* 8bit and 2 lines display */ + #define LCD_DISPLAY_MODE8BIT 0x38 ++#define LCD_DISPLAY_MODE4BIT 0x28 + #define LCD_DISPLAY_POS 0x80 + #define LCD_SHIFT_LEFT 0x18 + #define LCD_SHIFT_RIGHT 0x1c + ++static void lcd_put_byte(u8 *addr, u8 data) ++{ ++#ifdef CONFIG_XTFPGA_LCD_8BIT_ACCESS ++ ACCESS_ONCE(*addr) = data; ++#else ++ ACCESS_ONCE(*addr) = data & 0xf0; ++ ACCESS_ONCE(*addr) = (data << 4) & 0xf0; ++#endif ++} ++ + static int __init lcd_init(void) + { +- *LCD_INSTR_ADDR = LCD_DISPLAY_MODE8BIT; ++ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE8BIT; + mdelay(5); +- *LCD_INSTR_ADDR = LCD_DISPLAY_MODE8BIT; ++ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE8BIT; + udelay(200); +- *LCD_INSTR_ADDR = LCD_DISPLAY_MODE8BIT; ++ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE8BIT; ++ udelay(50); ++#ifndef CONFIG_XTFPGA_LCD_8BIT_ACCESS ++ ACCESS_ONCE(*LCD_INSTR_ADDR) = LCD_DISPLAY_MODE4BIT; ++ udelay(50); ++ lcd_put_byte(LCD_INSTR_ADDR, LCD_DISPLAY_MODE4BIT); + udelay(50); +- *LCD_INSTR_ADDR = LCD_DISPLAY_ON; ++#endif ++ lcd_put_byte(LCD_INSTR_ADDR, LCD_DISPLAY_ON); + udelay(50); +- *LCD_INSTR_ADDR = LCD_CLEAR; ++ lcd_put_byte(LCD_INSTR_ADDR, LCD_CLEAR); + mdelay(10); + lcd_disp_at_pos("XTENSA LINUX", 0); + return 0; +@@ -52,10 +65,10 @@ static int __init lcd_init(void) + + void lcd_disp_at_pos(char *str, unsigned char pos) + { +- *LCD_INSTR_ADDR = LCD_DISPLAY_POS | pos; ++ lcd_put_byte(LCD_INSTR_ADDR, LCD_DISPLAY_POS | pos); + udelay(100); + while (*str != 0) { +- *LCD_DATA_ADDR = *str; ++ lcd_put_byte(LCD_DATA_ADDR, *str); + udelay(200); + str++; + } +@@ -63,13 +76,13 @@ void lcd_disp_at_pos(char *str, unsigned + + void lcd_shiftleft(void) + { +- *LCD_INSTR_ADDR = LCD_SHIFT_LEFT; ++ lcd_put_byte(LCD_INSTR_ADDR, LCD_SHIFT_LEFT); + udelay(50); + } + + void lcd_shiftright(void) + { +- *LCD_INSTR_ADDR = LCD_SHIFT_RIGHT; ++ lcd_put_byte(LCD_INSTR_ADDR, LCD_SHIFT_RIGHT); + udelay(50); + } +