--- /dev/null
+From 2b8760100e1de69b6ff004c986328a82947db4ad Mon Sep 17 00:00:00 2001
+From: Lv Zheng <lv.zheng@intel.com>
+Date: Mon, 13 Apr 2015 11:48:58 +0800
+Subject: ACPICA: Utilities: split IO address types from data type models.
+
+From: Lv Zheng <lv.zheng@intel.com>
+
+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 <paulepanter@users.sourceforge.net>
+Reported-and-tested-by: Sial Nije <sialnije@gmail.com>
+Signed-off-by: Lv Zheng <lv.zheng@intel.com>
+Signed-off-by: Bob Moore <robert.moore@intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From linux@roeck-us.net Sat May 2 18:20:25 2015
+From: Guenter Roeck <linux@roeck-us.net>
+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 <gregkh@linuxfoundation.org>, Jiri Slaby <jslaby@suse.cz>, Guenter Roeck <linux@roeck-us.net>
+Message-ID: <1429766634-26546-1-git-send-email-linux@roeck-us.net>
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+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 <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+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
--- /dev/null
+From 61819549f572edd7fce53f228c0d8420cdc85f71 Mon Sep 17 00:00:00 2001
+From: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Date: Thu, 2 Apr 2015 17:11:11 +0200
+Subject: gpio: mvebu: Fix mask/unmask managment per irq chip type
+
+From: Gregory CLEMENT <gregory.clement@free-electrons.com>
+
+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 <dushistov@mail.ru>
+Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From 9a5cbce421a283e6aea3c4007f141735bf9da8c3 Mon Sep 17 00:00:00 2001
+From: Anton Blanchard <anton@samba.org>
+Date: Tue, 14 Apr 2015 07:51:03 +1000
+Subject: powerpc/perf: Cap 64bit userspace backtraces to PERF_MAX_STACK_DEPTH
+
+From: Anton Blanchard <anton@samba.org>
+
+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 <anton@samba.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 8de580742fee8bc34d116f57a20b22b9a5f08403 Mon Sep 17 00:00:00 2001
+From: "K. Y. Srinivasan" <kys@microsoft.com>
+Date: Fri, 27 Mar 2015 00:27:18 -0700
+Subject: scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
+
+From: "K. Y. Srinivasan" <kys@microsoft.com>
+
+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 <kys@microsoft.com>
+Reviewed-by: Long Li <longli@microsoft.com>
+Signed-off-by: James Bottomley <JBottomley@Odin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From f82263c6989c31ae9b94cecddffb29dcbec38710 Mon Sep 17 00:00:00 2001
+From: Thomas D <whissi@whissi.de>
+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 <whissi@whissi.de>
+
+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. <whissi@whissi.de>
+Cc: Mark Asselstine <mark.asselstine@windriver.com>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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"'
--- /dev/null
+From 8eef7d70f7c6772c3490f410ee2bceab3b543fa1 Mon Sep 17 00:00:00 2001
+From: Brian Norris <computersforpeace@gmail.com>
+Date: Sat, 28 Feb 2015 02:23:25 -0800
+Subject: UBI: account for bitflips in both the VID header and data
+
+From: Brian Norris <computersforpeace@gmail.com>
+
+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 <computersforpeace@gmail.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 299d0c5b27346a77a0777c993372bf8777d4f2e5 Mon Sep 17 00:00:00 2001
+From: Brian Norris <computersforpeace@gmail.com>
+Date: Sat, 28 Feb 2015 02:23:28 -0800
+Subject: UBI: fix check for "too many bytes"
+
+From: Brian Norris <computersforpeace@gmail.com>
+
+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 <computersforpeace@gmail.com>
+[rw: Fixed comparison]
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From d74adbdb9abf0d2506a6c4afa534d894f28b763f Mon Sep 17 00:00:00 2001
+From: Brian Norris <computersforpeace@gmail.com>
+Date: Sat, 28 Feb 2015 02:23:26 -0800
+Subject: UBI: fix out of bounds write
+
+From: Brian Norris <computersforpeace@gmail.com>
+
+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 <computersforpeace@gmail.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+ }
+
--- /dev/null
+From f16db8071ce18819fbd705ddcc91c6f392fb61f8 Mon Sep 17 00:00:00 2001
+From: Brian Norris <computersforpeace@gmail.com>
+Date: Sat, 28 Feb 2015 02:23:27 -0800
+Subject: UBI: initialize LEB number variable
+
+From: Brian Norris <computersforpeace@gmail.com>
+
+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 <computersforpeace@gmail.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 01e84c70fe40c8111f960987bcf7f931842e6d07 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+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 <jcmvbkbc@gmail.com>
+
+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 <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 4949009eb8d40a441dcddcd96e101e77d31cf1b2 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Fri, 27 Feb 2015 06:28:00 +0300
+Subject: xtensa: xtfpga: fix hardware lockup caused by LCD driver
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+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 <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 <linux/delay.h>
+ #include <linux/init.h>
+ #include <linux/io.h>
+
+ #include <platform/hardware.h>
+ #include <platform/lcd.h>
+-#include <linux/delay.h>
+
+-#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);
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
