LZ4: *squashing minor updates*

lz4: add overrun checks to lz4_uncompress_unknownoutputsize()

      Jan points out that I forgot to make the needed fixes to the
      lz4_uncompress_unknownoutputsize() function to mirror the changes done
      in lz4_decompress() with regards to potential pointer overflows.

      The only in-kernel user of this function is the zram code, which only
      takes data from a valid compressed buffer that it made itself, so it's
      not a big issue.  But due to external kernel modules using this
      function, it's better to be safe here.

      Reported-by: Jan Beulich <JBeulich@suse.com>
      Cc: "Don A. Bailey" <donb@securitymouse.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

lz4: fix another possible overrun

      There is one other possible overrun in the lz4 code as implemented by
      Linux at this point in time (which differs from the upstream lz4
      codebase, but will get synced at in a future kernel release.)  As
      pointed out by Don, we also need to check the overflow in the data
      itself.

      While we are at it, replace the odd error return value with just a
      "simple" -1 value as the return value is never used for anything other
      than a basic "did this work or not" check.

      Reported-by: "Don A. Bailey" <donb@securitymouse.com>
      Reported-by: Willy Tarreau <w@1wt.eu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

lz4: ensure length does not wrap

      Given some pathologically compressed data, lz4 could possibly decide to
      wrap a few internal variables, causing unknown things to happen.  Catch
      this before the wrapping happens and abort the decompression.

      Reported-by: "Don A. Bailey" <donb@securitymouse.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

lib/decompress_unlz4.c: always set an error return code on failures

      "ret", being set to -1 early on, gets cleared by the first invocation of
      lz4_decompress()/lz4_decompress_unknownoutputsize(), and hence subsequent
      failures wouldn't be noticed by the caller without setting it back to -1
      right after those calls.

      Reported-by: Matthew Daley <mattjd@gmail.com>
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Cc: Kyungsik Lee <kyungsik.lee@lge.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lz4: fix compression/decompression signedness mismatch

LZ4 compression and decompression functions require different in
signedness input/output parameters: unsigned char for compression and
signed char for decompression.

Change decompression API to require "(const) unsigned char *".

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Yann Collet <yann.collet.73@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove pmem driver completely

PMEM is now completely deprecated in favor of other memory
management schemes. Remove it completely so no one ever tries
to use anything like it again. The header file is purposely
left in the tree for now until userspace applications properly
clean up references to it.

Change-Id: Ie1cd8f15098d4064b1f0f60645d2bd02008c6763
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>

---

msm: Remove ANDROID_PMEM from the Kconfig dependencies

msm: Don't depend on ANDROID_PMEM for contiguous region

ASoC: msm: Remove android_pmem.h header

msm: Remove android_pmem.h from board and devices files

msm: Remove default y from hw3d driver

      The hw3d driver does not cure cancer and we end up with
      compile failures when removing deprecated CONFIG_ANDROID_PMEM.
      Remove the default y.

msm: Remove all references to CONFIG_ANDROID_PMEM

msm: camera: Remove references to CONFIG_ANDROID_PMEM

msm: vidc: Remove all references to CONFIG_ANDROID_PMEM

crypto: msm: Remove use of PMEM

msm: kgsl: Remove all reference to CONFIG_ANDROID_PMEM

msm: remove references to CONFIG_ANDROID_PMEM

msm: kgsl: Using ion allocation instead of pmem for GEM

      In GEM object allocations that are requested to be in
      physical memory, pmem was used in the past.  Since pmem
      has been replaced with ion, we have updated the code to
      use ion to manage memory in DRM/GEM that needs to be
      shared with MDP.

msm: kgsl: Improved bounds checking on user specified parameters

      Verify that the user specified length for a PMEM region is smaller
      than the size of the entire region as reported by the kernel APIs.

msm: board-7627a: Remove pmem from 7627a/8625.

msm: Rename pmem variables and macros

      Since MSM no longer uses PMEM, the variables, macros, and kernel
      config (CONFIG_KERNEL_PMEM_EBI_REGION) relating to PMEM should be
      renamed to something more generic.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
huawei_battery.c: reduced charging voltage from 4350 mV to 4300 mV

...to prevent overcharging and increasing battery's longevity.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
cpufreq / stats: *squashing updates*

cpufreq / stats: fix race between stats allocation and first usage

      This patch forces complete struct cpufreq_stats allocation for all cpus before
      registering CPUFREQ_TRANSITION_NOTIFIER notifier, otherwise in some conditions
      cpufreq_stat_notifier_trans() can be called in the middle of stats allocation,
      in this case cpufreq_stats_table already exists, but stat->freq_table is NULL.

      Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq / stats: Get rid of CPUFREQ_STATDEVICE_ATTR

      Macro "CPUFREQ_STATDEVICE_ATTR" is defined local to cpufreq_stats.c file and is
      almost a copy of the generic version present in cpufreq.h file. Lets use the
      generic version instead.

      Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq_stats: do not remove sysfs files if frequency table is not present

      The sysfs files for cpufreq_stats are created in cpufreq_stats_create_table()
      called from cpufreq_stat_notifier_policy() when a policy is added to
      the cpu. cpufreq_stats_create_table() will not be called if the
      scaling driver does not export a frequency table to cpufreq.  Use the
      same fence on tear down.

      Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
      Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: stats: do cpufreq_cpu_put() corresponding to cpufreq_cpu_get()

      In cpufreq_stats_free_sysfs() we aren't balancing calls to
      cpufreq_cpu_get() with cpufreq_cpu_put(). This will never let us have
      ref count to policy->kobj as zero.

      We will get a hang if somehow cpufreq_driver_unregister() is called.
      And that can happen when we compile our driver as module and
      insmod/rmmod it.

      Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
      Acked-by: Amit Kucheria <amit.kucheria@linaro.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: Fix misplaced call to cpufreq_update_policy()

      The call to cpufreq_update_policy() is placed in the CPU hotplug callback
      of cpufreq_stats, which has a higher priority than the CPU hotplug callback
      of cpufreq-core. As a result, during CPU_ONLINE/CPU_ONLINE_FROZEN, we end up
      calling cpufreq_update_policy() *before* calling cpufreq_add_dev() !
      And for uninitialized CPUs, it just returns silently, not doing anything.

      To add to that, cpufreq_stats is not even the right place to call
      cpufreq_update_policy() to begin with. The cpufreq core ought to handle
      this in its own callback, from an elegance/relevance perspective.

      So move the invocation of cpufreq_update_policy() to cpufreq_cpu_callback,
      and place it *after* cpufreq_add_dev().

      Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: Fix wrong time unit conversion

      The time spent by a CPU under a given frequency is stored in jiffies unit
      in the cpu var cpufreq_stats_table->time_in_state[i], i being the index of
      the frequency.

      This is what is displayed in the following file on the right column:

	  cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state
	  2301000 19835820
	  2300000 3172
	  [...]

      Now cpufreq converts this jiffies unit delta to clock_t before returning it
      to the user as in the above file. And that conversion is achieved using the API
      cputime64_to_clock_t().

      Although it accidentally works on traditional tick based cputime accounting, where
      cputime_t maps directly to jiffies, it doesn't work with other types of cputime
      accounting such as CONFIG_VIRT_CPU_ACCOUNTING_* where cputime_t can map to nsecs
      or any granularity preffered by the architecture.

      For example we get a buggy zero delta on full dyntick configurations:

	  cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state
	  2301000 0
	  2300000 0
	  [...]

      Fix this with using the proper jiffies_64_t to clock_t conversion.

      Reported-and-tested-by: Carsten Emde <C.Emde@osadl.org>
      Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
      Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
      Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
ZRAM: switched to num_devices=2

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
config: *update*
ARM: Remove support for ARMv3 ARM610 and ARM710 CPUs

This patch removes support for ARMv3 CPUs, which haven't worked properly
for quite some time (see the FIXME comment in arch/arm/mm/fault.c).  The
only V3 parts left is the cache model for ARMv3, which is needed for some
odd reason by ARM740T CPUs, and being able to build with -march=armv3,
which is required for the RiscPC platform due to its bus structure.

Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: decompressor: *squashing updates*

ARM: Remove ARMv3 support from decompressor

      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: decompressor: avoid speculative prefetch from non-RAM areas

      We setup identity MMU mappings across the entire 4GB of space, which
      are permissionless because the domain is set to manager.

      This unfortunately allows ARMv6 and later CPUs to speculatively
      prefetch from the entire address space, which can cause undesirable
      side effects if those regions contain devices.

      As we setup the mappings with read/write permission, we can switch
      the domain to client mode, and then use the XN bit for ARMv6 and
      above to control speculative prefetch to non-RAM areas.

      Reported-by: R Sricharan <r.sricharan@ti.com>
      Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores

      When enabling the MMU for ARMv7 CPUs, the decompressor does not touch
      the ttbcr register, assuming that it will be zeroed (N == 0, EAE == 0).
      Given that only EAE is defined as 0 for non-secure copies of the
      register (and a bootloader such as kexec may leave it set to 1 anyway),
      we should ensure that we reset the register ourselves before turning on
      the MMU.

      This patch zeroes TTBCR.EAE and TTBCR.N prior to enabling the MMU for
      ARMv7 cores in the decompressor, configuring us exclusively for 32-bit
      translation tables via TTBR0.

      Cc: <stable@vger.kernel.org>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Matthew Leach <matthew.leach@arm.com>
      Signed-off-by: Will Deacon <will.deacon@arm.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7492/1: add strstr declaration for decompressors

      With the generic unaligned.h, more kernel headers get pulled in including
      dynamic_debug.h which needs strstr. As it is not really used, we only need
      a declaration here.

      Signed-off-by: Rob Herring <rob.herring@calxeda.com>
      Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7532/1: decompressor: reset SCTLR.TRE for VMSA ARMv7 cores

      This patch zeroes the SCTLR.TRE bit prior to setting the mapping as
      cacheable for ARMv7 cores in the decompressor, ensuring that the
      memory region attributes are obtained from the C and B bits, not from
      the page tables.

      Cc: Nicolas Pitre <nico@fluxnic.net>
      Reviewed-by: Will Deacon <will.deacon@arm.com>
      Signed-off-by: Matthew Leach <matthew.leach@arm.com>
      Signed-off-by: Will Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7666/1: decompressor: add -mno-single-pic-base for building the decompressor

      Before jumping to (position independent) C-code from the decompressor's
      assembler world we set-up the C environment. This setup currently does not
      set r9, which for arm-none-uclinux-uclibceabi toolchains is by default
      expected to be the PIC offset base register (IE should point to the
      beginning of the GOT).

      Currently, therefore, in order to build working kernels that use the
      decompressor it is necessary to use an arm-linux-gnueabi toolchain, or
      similar. uClinux toolchains cause a prefetch abort to occur at the beginning
      of the decompress_kernel function.

      This patch allows uClinux toolchains to build bootable zImages by forcing
      the -mno-single-pic-base option, which ensures that the location of the GOT
      is re-derived each time it is required, and r9 becomes free for use as a
      general purpose register.

      This has a small (4% in instruction terms) advantage over the alternative of
      setting r9 to point to the GOT before calling into the C-world.

      Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7750/1: update legacy CPU ID in decompressor cache support jump table

      The previous mask values for the legacy ARM CPU IDs were conflicting
      with the CPU ID assignments for late-generation CPUs (like the
      Qualcomm MSM/QSD or Broadcom Brahma-15 processors). This change
      corrects the legacy ARM CPU ID value so that the jump table can
      fall-through to the appropriate cache maintenance / MMU functions.

      Signed-off-by: Marc C <marc.ceeeee@gmail.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7751/1: zImage: don't overwrite ourself with a page table

      When zImage is loaded into RAM at a low address but TEXT_OFFSET
      is set higher, we risk overwriting ourself with the page table
      needed to turn on the cache as it is located relative to the relocation
      address.  Let's defer the cache setup after relocation in that case.

      Signed-off-by: Nicolas Pitre <nico@linaro.org>
      Reported-by: Stephen Boyd <sboyd@codeurora.org>
      Tested-by: Stephen Boyd <sboyd@codeurora.org>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7770/1: remove residual ARMv2 support from decompressor

      arm26 support in Linux is long gone, yet it left an interresting,
      fossilized trace in the decompressor.

      Remove it so people won't get confused about what teqp is actually
      doing here...

      Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7877/1: use built-in byte swap function

      Enable the compiler intrinsic for byte swapping on arch ARM. This
      allows the compiler to detect and be able to optimize out byte
      swappings, and has a very modest benefit on vmlinux size (Linaro gcc
      4.8):

      text data bss dec hex filename
      2840310 123932 61960 3026202 2e2d1a vmlinux-lart #orig
      2840152 123932 61960 3026044 2e2c7c vmlinux-lart #builtin-bswap

      6473120 314840 5616016 12403976 bd4508 vmlinux-mxs #orig
      6472586 314848 5616016 12403450 bd42fa vmlinux-mxs #builtin-bswap

      7419872 318372 379556 8117800 7bde28 vmlinux-imx_v6_v7 #orig
      7419170 318364 379556 8117090 7bdb62 vmlinux-imx_v6_v7 #builtin-bswap

      Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
      Reviewed-by: Nicolas Pitre <nico@linaro.org>
      Acked-by: David Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7992/1: boot: compressed: ignore bswapsdi2.S

      Commit 017f161a55b4 (ARM: 7877/1: use built-in byte swap function) added
      bswapsdi2.{o,S} to arch/arm/boot/compressed/Makefile, but didn't update
      the .gitignore. Thus after a a build git status shows bswapsdi2.S as a
      new file, which is a little annoying.

      This patch updates arch/arm/boot/compressed/.gitignore to ignore
      bswapsdi2.S, as we already do for ashldi3.S and others.

      Signed-off-by: Mark Rutland <mark.rutland@arm.com>
      Acked-by: Nicolas Pitre <nico@linaro.org>
      Acked-by: Kim Phillips <kim.phillips@freescale.com>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

byteorder: allow arch to opt to use GCC intrinsics for byteswapping

      Since GCC 4.4, there have been __builtin_bswap32() and __builtin_bswap16()
      intrinsics. A __builtin_bswap16() came a little later (4.6 for PowerPC,
      48 for other platforms).

      By using these instead of the inline assembler that most architectures
      have in their __arch_swabXX() macros, we let the compiler see what's
      actually happening. The resulting code should be at least as good, and
      much *better* in the cases where it can be combined with a nearby load
      or store, using a load-and-byteswap or store-and-byteswap instruction
      (e.g. lwbrx/stwbrx on PowerPC, movbe on Atom).

      When GCC is sufficiently recent *and* the architecture opts in to using
      the intrinsics by setting CONFIG_ARCH_USE_BUILTIN_BSWAP, they will be
      used in preference to the __arch_swabXX() macros. An architecture which
      does not set ARCH_USE_BUILTIN_BSWAP will continue to use its own
      hand-crafted macros.

      Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
      Acked-by: H. Peter Anvin <hpa@linux.intel.com>

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
ARM: prefetch: *squashing updates*

Missing commit (already add before):
      https://www.codeaurora.org/cgit/quic/la/kernel/msm/commit/arch/arm?h=korg/linux-3.15.y&id=9bb17be062de6f5a9c9643258951aa0935652ec3

---

ARM: prefetch: remove redundant "cc" clobber

      The pld instruction does not affect the condition flags, so don't bother
      clobbering them.

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Will Deacon <will.deacon@arm.com>

ARM: prefetch: add support for prefetchw using pldw on SMP ARMv7+ CPUs

      SMP ARMv7 CPUs implement the pldw instruction, which allows them to
      prefetch data cachelines in an exclusive state.

      This patch defines the prefetchw macro using pldw for CPUs that support
      it.

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Will Deacon <will.deacon@arm.com>

ARM: atomics: prefetch the destination word for write prior to strex

      The cost of changing a cacheline from shared to exclusive state can be
      significant, especially when this is triggered by an exclusive store,
      since it may result in having to retry the transaction.

      This patch prefixes our atomic access implementations with pldw
      instructions (on CPUs which support them) to try and grab the line in
      exclusive state from the start. Only the barrier-less functions are
      updated, since memory barriers can limit the usefulness of prefetching
      data.

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Will Deacon <will.deacon@arm.com>

ARM: bitops: prefetch the destination word for write prior to strex

      The cost of changing a cacheline from shared to exclusive state can be
      significant, especially when this is triggered by an exclusive store,
      since it may result in having to retry the transaction.

      This patch prefixes our atomic bitops implementation with prefetchw,
      to try and grab the line in exclusive state from the start. The testop
      macro is left alone, since the barrier semantics limit the usefulness
      of prefetching data.

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Will Deacon <will.deacon@arm.com>

ARM: 7984/1: prefetch: add prefetchw invocations for barriered atomics

      After a bunch of benchmarking on the interaction between dmb and pldw,
      it turns out that issuing the pldw *after* the dmb instruction can
      give modest performance gains (~3% atomic_add_return improvement on a
      dual A15).

      This patch adds prefetchw invocations to our barriered atomic operations
      including cmpxchg, test_and_xxx and futexes.

      Signed-off-by: Will Deacon <will.deacon@arm.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: smp_on_up: move inline asm ALT_SMP patching macro out of spinlock.h

      Patching UP/SMP alternatives inside inline assembly blocks is useful
      outside of the spinlock implementation, where it is used for sev and wfe.

      This patch lifts the macro into processor.h and gives it a scarier name
      to (a) avoid conflicts in the global namespace and (b) to try and deter
      its usage unless you "know what you're doing". The W macro for generating
      wide instructions when targetting Thumb-2 is also made available under
      the name WASM, to reduce the potential for conflicts with other headers.

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: 7479/1: mm: avoid NULL dereference when flushing gate_vma with VIVT caches

The vivt_flush_cache_{range,page} functions check that the mm_struct
of the VMA being flushed has been active on the current CPU before
performing the cache maintenance.

The gate_vma has a NULL mm_struct pointer and, as such, will cause a
kernel fault if we try to flush it with the above operations. This
happens during ELF core dumps, which include the gate_vma as it may be
useful for debugging purposes.

This patch adds checks to the VIVT cache flushing functions so that VMAs
with a NULL mm_struct are flushed unconditionally (the vectors page may
be dirty if we use it to store the current TLS pointer).

Cc: <stable@vger.kernel.org> # 3.4+
Reported-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Tested-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: mm: fix MMU mapping of CMA regions

Fix dma_contiguous_remap() so that it continues through all the
regions, even after encountering one that is outside lowmem.
Without this change, if you have two CMA regions, the first outside
lowmem and the seocnd inside lowmem, only the second one will get
set up in the MMU. Data written to that region then doesn't get
automatically flushed from the cache into memory.

Signed-off-by: Chris Brand <cbrand@broadcom.com>
[extended patch subject with 'fix' word]
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
ARM: 7660/1: tlb: add branch predictor maintenance operations

The ARM architecture requires explicit branch predictor maintenance
when updating an instruction stream for a given virtual address. In
reality, this isn't so much of a burden because the branch predictor
is flushed during the cache maintenance required to make the new
instructions visible to the I-side of the processor.

However, there are still some cases where explicit flushing is required,
so add a local_bp_flush_all operation to deal with this.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: mm: remove broken condition check for v4 flushing

There's no point having a conditional cache flush if we don't know the
state of the condition beforehand.

This patch makes the cacheflush in v4_flush_user_cache_range
unconditional.

signed-off-by: will deacon <will.deacon@arm.com>
ARM: 7691/1: mm: kill unused TLB_CAN_READ_FROM_L1_CACHE and use ALT_SMP instead

Many ARMv7 cores have hardware page table walkers that can read the L1
cache. This is discoverable from the ID_MMFR3 register, although this
can be expensive to access from the low-level set_pte functions and is a
pain to cache, particularly with multi-cluster systems.

A useful observation is that the multi-processing extensions for ARMv7
require coherent table walks, meaning that we can make use of ALT_SMP
patching in proc-v7-* to patch away the cache flush safely for these
cores.

Reported-by: Albin Tonnerre <Albin.Tonnerre@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7693/1: mm: clean-up in order to reduce to call kmap_high_get()

In kmap_atomic(), kmap_high_get() is invoked for checking already
mapped area. In __flush_dcache_page() and dma_cache_maint_page(),
we explicitly call kmap_high_get() before kmap_atomic()
when cache_is_vipt(), so kmap_high_get() can be invoked twice.
This is useless operation, so remove one.

v2: change cache_is_vipt() to cache_is_vipt_nonaliasing() in order to
be self-documented

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: smp: flush L1 cache in cpu_die()

Flush the L1 cache for the CPU which is going down in cpu_die() so
that we don't end up with all platforms doing this.  This ensures
that any cache lines we own are pushed out before the cache becomes
inaccessible.

We may end up subsequently creating some dirty cache lines - for
example, with the complete() call, but this update must become
visible to other CPUs before __cpu_die() can proceed.  Subsequent
accesses from the platforms cpu_die() function should _not_ matter.

Also place a mb() after the complete() call to ensure that this is
visible to other CPUs.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: cacheflush: add synchronization helpers for mixed cache state accesses

  Algorithms used by the MCPM layer rely on state variables which are
  accessed while the cache is either active or inactive, depending
  on the code path and the active state.

  This patch introduces generic cache maintenance helpers to provide the
  necessary cache synchronization for such state variables to always hit
  main memory in an ordered way.

  Signed-off-by: Nicolas Pitre <nico@linaro.org>
  Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
  Acked-by: Dave Martin <dave.martin@linaro.org>

ARM: 7918/1: clean up cache handling in core code

  We have a handy macro to replace open coded __cpuc_flush_dcache_area(()
  and outer_clean_range() sequences. Let's use it. No functional change.

  Signed-off-by: Nicolas Pitre <nico@linaro.org>
  Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7730/1: DMA-mapping: mark all !DMA_TO_DEVICE pages in unmapping as clean

It is common for one sg to include many pages, so mark all these
pages as clean to avoid unnecessary flushing on them in
set_pte_at() or update_mmu_cache().

The patch might improve loading performance of applciation code a bit.

On the below test code to read file(~1GByte size) from usb mass storage
disk to buffer created with mmap(PROT_READ | PROT_EXEC) on
Pandaboard, average ~1% improvement can be observed with the patch on
10 times test.

unsigned int sum = 0;
static unsigned long tv_diff(struct timeval *tv1, struct timeval *tv2)
{
	return (tv2->tv_sec - tv1->tv_sec) * 1000000 + (tv2->tv_usec - tv1->tv_usec);
}
int main(int argc, char *argv[])
{
	char *mbuffer;
	int fd;
	int i;
	unsigned long page_size, size;
	struct stat stat;
	struct timeval t1, t2;

	page_size = getpagesize();
	fd = open(argv[1], O_RDONLY);
	assert(fd >= 0);

	fstat(fd, &stat);
	size = stat.st_size;
	printf("%s: file %s, file size %lu, page size %lun", argv[0],
	        read_filename, size, page_size);

	gettimeofday(&t1, NULL);
	mbuffer = mmap(NULL, size, PROT_READ | PROT_EXEC, MAP_SHARED, fd, 0);
	for (i = 0 ; i < size ; i += page_size)
	        sum += mbuffer[i];
	munmap(mbuffer, page_size);
	gettimeofday(&t2, NULL);
	printf("tread mmaped time: %luusn", tv_diff(&t1, &t2));

	close(fd);
}

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7746/1: mm: lazy cache flushing on non-mapped pages

Currently flush_dcache_page() thinks pages as non-mapped if
mapping_mapped(mapping) return false. This approach is very
coase:
	- mmap on part of file may cause all pages backed on
	the file being thought as mmaped

	- file-backed pages aren't mapped into user space actually
	if the memory mmaped on the file isn't accessed

This patch uses page_mapped() to decide if the page has been
mapped.

From the attached test code, I find there is much performance
improvement(>25%) when accessing page caches via read under this
situations, so memcpy benefits a lot from not flushing cache
under this situation.

No.   read time without the patch	No. read time with the patch
================================================================
No. 0, time  22615636 us		No. 0, time  22014717 us
No. 1, time  4387851 us 		No. 1, time  3113184 us
No. 2, time  4276535 us 		No. 2, time  3005244 us
No. 3, time  4259821 us 		No. 3, time  3001565 us
No. 4, time  4263811 us 		No. 4, time  3002748 us
No. 5, time  4258486 us 		No. 5, time  3004104 us
No. 6, time  4253009 us 		No. 6, time  3002188 us
No. 7, time  4262809 us 		No. 7, time  2998196 us
No. 8, time  4264525 us 		No. 8, time  3007255 us
No. 9, time  4267795 us 		No. 9, time  3005094 us

1), No.0. is to read the file from storage device, and others are
to read the file from page caches basically.
2), file size is 512M, and is on ext4 over usb mass storage.
3), the test is done on Pandaboard.

unsigned int  sum = 0;
unsigned long sum_val = 0;

static unsigned long tv_diff(struct timeval *tv1, struct timeval *tv2)
{
	return (tv2->tv_sec - tv1->tv_sec) * 1000000 +
		(tv2->tv_usec - tv1->tv_usec);
}

int main(int argc, char *argv[])
{
	char *mbuf, fbuf;
	int fd;
	int i;
	unsigned long page_size, size;
	struct stat stat;
	struct timeval t1, t2;
	unsigned char *rbuf = malloc(32 * page_size);

	if (!rbuf) {
		printf("	%sn", "malloc failed");
		exit(-1);
	}

	page_size = getpagesize();
	fd = open(argv[1], O_RDWR);
	assert(fd >= 0);

	fstat(fd, &stat);
	size = stat.st_size;
	printf("%s: file %s, size %lu, page size %lun",
		argv[0],
		argv[1], size, page_size);

	gettimeofday(&t1, NULL);
	mbuf = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
	if (!mbuf) {
		printf("	%sn", "mmap failed");
		exit(-1);
	}

	for (i = 0 ; i < size ; i += (page_size * 32)) {
		int rcnt;
		lseek(fd, i, SEEK_SET);
		rcnt = read(fd, rbuf, page_size * 32);
		if (rcnt != page_size * 32) {
			printf("%s: read faildn", __func__);
			exit(-1);
		}
	}
	free(rbuf);
	munmap(mbuf, size);
	gettimeofday(&t2, NULL);
	printf("tread mmaped time: %luusn", tv_diff(&t1, &t2));

	close(fd);
}

Cc: Michel Lespinasse <walken@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: Will Deacon <will.deacon@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting

When scheduling an mm on a CPU where it hasn't previously been used, we
flush the icache on that CPU so that any code loaded previously on
a different core can be safely executed.

For cores with hardware broadcasting of cache maintenance operations,
this is clearly unnecessary, since the inner-shareable invalidation in
__sync_icache_dcache will affect all CPUs.

This patch conditionalises the icache flush in switch_mm based on
cache_ops_need_broadcast().

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Albin Tonnerre <albin.tonnerre@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>