ARM: 7990/1: asm: rename logical shift macros push pull into lspush lspull

Renames logical shift macros, 'push' and 'pull', defined in
arch/arm/include/asm/assembler.h, into 'lspush' and 'lspull'.
That eliminates name conflict between 'push' logical shift macro
and 'push' instruction mnemonic. That allows assembler.h to be
included in .S files that use 'push' instruction.

Suggested-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
workqueue: change BUG_ON() to WARN_ON()

This BUG_ON() can be triggered if you call schedule_work() before
calling INIT_WORK().  It is a bug definitely, but it's nicer to just
print a stack trace and return.

Reported-by: Matt Renzelmann <mjr@cs.wisc.edu>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
mm: page-writeback.c: local functions should not be exposed globally

The function global_dirtyable_memory is only referenced in this file and
should be marked static to prevent it from being exposed globally.

This quiets the sparse warning:

warning: symbol 'global_dirtyable_memory' was not declared. Should it be static?

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
cgroup: fix exit() vs rmdir() race

commit 71b5707e119653039e6e95213f00479668c79b75 upstream.

In cgroup_exit() put_css_set_taskexit() is called without any lock,
which might lead to accessing a freed cgroup:

thread1                           thread2
---------------------------------------------
exit()
  cgroup_exit()
    put_css_set_taskexit()
      atomic_dec(cgrp->count);
                                   rmdir();
      /* not safe !! */
      check_for_release(cgrp);

rcu_read_lock() can be used to make sure the cgroup is alive.

Signed-off-by: Li Zefan <lizefan@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[moddingg33k: backported for MSM-3.4 kernel]
Signed-off-by: moddingg33k <moddingg33k@t-online.de>
base: genlock: Zero a structure before sending it to user space

In the handler for GENLOCK_IOC_EXPORT zero the entire genlock_lock
structure before passing it to the user.

CRs-fixed: 552303
Change-Id: Ic0dedbad257bf0a448d0bf67a14a3932b7925bfc
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
usb: gadget: composite: Fix a bug in delayed status handling

The SET_CONFIGURATION control request's status phase is delayed
till the new config change is handled by the file-storage thread.
If the cable is disconnected or the bus is reset before the
previous config is handled, then composite driver is not notified
about the delayed status.  As a result of which, the delayed_status
field of composite device structure remains non-zero.  The status
phase of next SET_CONFIGURATION control request is not sent.
This makes the gadget unusable.

Calling usb_composite_setup_continue() after the disconnect or reset
does not make any sense.  If the host sends another control request
before the status phase of the previous control request is sent, the
delayed_status must be reset to zero.  This is not straight forward
as the UDC handles some control requests without delegating them to
the composite driver.  A simple fix would be resetting the delayed
status value after the disconnect/reset.

CRs-Fixed: 501527
Change-Id: I67c832afc88c9e7d025247e539b7223fd83644d7
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
msm: pm2: Update SPC LPM stats correctly

Currently StandalonePC stats are updating incorrectly even
for successful cases. After debug found that compiler has
optimized some of the instructions where the return value
from "msm_pm_power_collapse_standalone()" being compared
incorrectly and always log the stats as failed even for
success cases. Change the "exit_stat" variable to "volatile"
to avoid any optimization.

CRs-Fixed: 433578
Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
(cherry picked from commit f59048d29fd75a30cac8c294e068178d9d489af3)

Change-Id: If1f9313f7968e93f5dcd9fb33426496f5091d14a
Signed-off-by: Srivalli Oguri <oguri@codeaurora.org>
Enable setting security contexts on rootfs inodes.

rootfs (ramfs) can support setting of security contexts
by userspace due to the vfs fallback behavior of calling
the security module to set the in-core inode state
for security.* attributes when the filesystem does not
provide an xattr handler.  No xattr handler required
as the inodes are pinned in memory and have no backing
store.

This is useful in allowing early userspace to label individual
files within a rootfs while still providing a policy-defined
default via genfs.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Change-Id: I3436cf9ae27ade445e37376d7b9125746b1e506f
config: *update*
implement LoUIS API for cache maintenance ops

ARM: mm: implement LoUIS API for cache maintenance ops

      ARM v7 architecture introduced the concept of cache levels and related
      control registers. New processors like A7 and A15 embed an L2 unified cache
      controller that becomes part of the cache level hierarchy. Some operations in
      the kernel like cpu_suspend and __cpu_disable do not require a flush of the
      entire cache hierarchy to DRAM but just the cache levels belonging to the
      Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
      correspond to L1.

      The current cache flushing API used in cpu_suspend and __cpu_disable,
      flush_cache_all(), ends up flushing the whole cache hierarchy since for
      v7 it cleans and invalidates all cache levels up to Level of Coherency
      (LoC) which cripples system performance when used in hot paths like hotplug
      and cpuidle.

      Therefore a new kernel cache maintenance API must be added to cope with
      latest ARM system requirements.

      This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.

      This function cleans and invalidates all data cache levels up to the
      Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
      cache for processors that support it (> v7).

      This patch also creates an alias of the cache LoUIS function to flush_kern_all
      for all processor versions prior to v7, so that the current cache flushing
      behaviour is unchanged for those processors.

      v7 cache maintenance code implements a cache LoUIS function that cleans and
      invalidates the D-cache up to LoUIS and invalidates the I-cache, according
      to the new API.

      Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: Shawn Guo <shawn.guo@linaro.org>

ARM: mm: rename jump labels in v7_flush_dcache_all function

      This patch renames jump labels in v7_flush_dcache_all in order to define
      a specific flush cache levels entry point.

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: Shawn Guo <shawn.guo@linaro.org>

ARM: kernel: update cpu_suspend code to use cache LoUIS operations

      In processors like A15/A7 L2 cache is unified and integrated within the
      processor cache hierarchy, so that it is not considered an outer cache
      anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
      all cache levels up to Level of Coherency (LoC) that includes
      the L2 unified cache.

      When a single CPU is suspended (CPU idle) a complete L2 clean is not
      required, so generic cpu_suspend code must clean the data cache using the
      newly introduced cache LoUIS function.

      The context and stack pointer (context pointer) are cleaned to main memory
      using cache area functions that operate on MVA and guarantee that the data
      is written back to main memory (perform cache cleaning up to the Point of
      Coherency - PoC) so that the processor can fetch the context when the MMU
      is off in the cpu_resume code path.

      outer_cache management remains unchanged.

      Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Reviewed-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: Shawn Guo <shawn.guo@linaro.org>

ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API

      When a CPU is hotplugged out caches that reside in its power domain
      lose their contents and so must be cleaned to the next memory level.

      Currently, __cpu_disable calls flush_cache_all() that for new generation
      processor like A15/A7 ends up cleaning and invalidating all cache levels
      up to Level of Coherency, which includes the unified L2.

      This ends up being a waste of cycles since the L2 cache contents are not
      lost on power down.

      This patch updates __cpu_disable to use the new LoUIS API cache operations.

      Acked-by: Nicolas Pitre <nico@linaro.org>
      Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: Shawn Guo <shawn.guo@linaro.org>

ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API

      The ARMv7 processor setup function __v7_setup() cleans and invalidates the
      CPU cache before enabling MMU to start the CPU with a clean CPU local cache.

      But on ARMv7 architectures like Cortex-[A15/A8], this code will end
      up flushing the L2 caches(up to level of Coherency) which is undesirable
      and expensive. The setup functions are used in the CPU hotplug scenario too
      and hence flushing all cache levels should be avoided.

      This patch replaces the cache flushing call with the newly introduced
      v7 dcache LoUIS API where only cache levels up to LoUIS are cleaned and
      invalidated when a processors executes __v7_setup which is the expected
      behavior.

      For processors like A9 and A5 where the L2 cache is an outer one the
      behavior should be unchanged.

      Reviewed-by: Nicolas Pitre <nico@linaro.org>
      Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Tested-by: Shawn Guo <shawn.guo@linaro.org>

ARM: 7573/1: idmap: use flush_cache_louis() and flush TLBs only when necessary

      Flushing the cache is needed for the hardware to see the idmap table
      and therefore can be done at init time.  On ARMv7 it is not necessary to
      flush L2 so flush_cache_louis() is used here instead.

      There is no point flushing the cache in setup_mm_for_reboot() as the
      caller should, and already is, taking care of this.  If switching the
      memory map requires a cache flush, then cpu_switch_mm() already includes
      that operation.

      What is not done by cpu_switch_mm() on ASID capable CPUs is TLB flushing
      as the whole point of the ASID is to tag the TLBs and avoid flushing them
      on a context switch.  Since we don't have a clean ASID for the identity
      mapping, we need to flush the TLB explicitly in that case.  Otherwise
      this is already performed by cpu_switch_mm().

      Signed-off-by: Nicolas Pitre <nico@linaro.org>
      Acked-by: Will Deacon <will.deacon@arm.com>
      Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arm: missing checks of __get_user()/__put_user() return values

Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
arm: if there's no handler we need to restore sigmask, syscall or no syscall

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
msm: dma: upstream to CAF Ifaa5efdde8150f932a12d4f9eeccfb36ecb8f88f

    Highlights of the changes are:
    1. A workqueue is used to configure ADM only when
      the clocks need to be prepared & enabled.
      A function call is used to configure ADM in
      cases where the ADM driver is invoked for data
      transfer when the clock is already prepared &
      enabled.
    2. Replaced threaded irqs with hard irqs.

    Change-Id: Ifaa5efdde8150f932a12d4f9eeccfb36ecb8f88f
    Acked-by: John Nicholas <jnichola@qti.qualcomm.com>
    Signed-off-by: Venkatesh Yadav Abbarapu <quicvenkat@codeaurora.org>

---

  - includes older dma.c related patches as well
  - removes custom Huawei code

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
ARM: 7928/1: kconfig: select HAVE_EFFICIENT_UNALIGNED_ACCESS for CPUv6+ && MMU

Modern ARM CPUs can perform efficient unaligned memory accesses in
hardware and this feature is relied up on by code such as the dcache
word-at-a-time name hashing.

This patch selects HAVE_EFFICIENT_UNALIGNED_ACCESS for these cores and
reworks the kconfig select logic for DCACHE_WORD_ACCESS to use the new
symbol.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
block/partitions: optimize memory allocation in check_partition()

Currently, sizeof(struct parsed_partitions) may be 64KB in 32bit arch, so
it is easy to trigger page allocation failure by check_partition,
especially in hotplug block device situation(such as, USB mass storage,
MMC card, ...), and Felipe Balbi has observed the failure.

This patch does below optimizations on the allocation of struct
parsed_partitions to try to address the issue:

- make parsed_partitions.parts as pointer so that the pointed memory can
  fit in 32KB buffer, then approximate 32KB memory can be saved

- vmalloc the buffer pointed by parsed_partitions.parts because 32KB is
  still a bit big for kmalloc

- given that many devices have the partition count limit, so only
  allocate disk_max_parts() partitions instead of 256 partitions always

Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reported-by: Felipe Balbi <balbi@ti.com>
Cc: Jens Axboe <axboe@kernel.dk>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
jbd2: calculate statistics without holding j_state_lock and j_list_lock The two hottest locks, and thus the biggest scalability bottlenecks, in the jbd2 layer, are the j_list_lock and j_state_lock. This has inspired some people to do some truly unnatural things[1].

[1] https://www.usenix.org/system/files/conference/fast14/fast14-paper_kang.pdf

We don't need to be holding both j_state_lock and j_list_lock while
calculating the journal statistics, so move those calculations to the
very end of jbd2_journal_commit_transaction.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
cpufreq / ondemand: upstream mainline as of 01.03.2012

cpufreq: ondemand: Change the calculation of target frequency

    The ondemand governor calculates load in terms of frequency and
    increases it only if load_freq is greater than up_threshold
    multiplied by the current or average frequency.  This appears to
    produce oscillations of frequency between min and max because,
    for example, a relatively small load can easily saturate minimum
    frequency and lead the CPU to the max.  Then, it will decrease
    back to the min due to small load_freq.

    Change the calculation method of load and target frequency on the
    basis of the following two observations:

    - Load computation should not depend on the current or average
      measured frequency.  For example, absolute load of 80% at 100MHz
      is not necessarily equivalent to 8% at 1000MHz in the next
      sampling interval.

    - It should be possible to increase the target frequency to any
      value present in the frequency table proportional to the absolute
      load, rather than to the max only, so that:

      Target frequency = C * load

      where we take C = policy->cpuinfo.max_freq / 100.

    Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait.
    Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an
    increase ~1.5% in performance. cpufreq_stats (time_in_state) shows
    that middle frequencies are used more, with this patch.  Highest
    and lowest frequencies were used less by ~9%.

    [rjw: We have run multiple other tests on kernels with this
    change applied and in the vast majority of cases it turns out
    that the resulting performance improvement also leads to reduced
    consumption of energy.  The change is additionally justified by
    the overall simplification of the code in question.]

    Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
cpufreq: Introduce new relation for freq selection Introduce CPUFREQ_RELATION_C for frequency selection. It selects the frequency with the minimum euclidean distance to target. In case of equal distance between 2 frequencies, it will select the greater freq.

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
cpufreq: ondemand: Eliminate the dead band effect in low load
 Currently, ondemand calculates the target frequency proportional to load
 using the formula: 	Target frequency = C * load 	where C =
 policy->cpuinfo.max_freq / 100

Though, in many cases, the minimum available frequency is pretty high and
the above calculation introduces a dead band from load 0 to
100 * policy->cpuinfo.min_freq / policy->cpuinfo.max_freq where the target
frequency is always calculated to less than policy->cpuinfo.min_freq and
the minimum frequency is selected.

For example: on Intel i7-3770 @ 3.4GHz the policy->cpuinfo.min_freq = 1600000
and the policy->cpuinfo.max_freq = 3400000 (without turbo). Thus, the CPU
starts to scale up at a load above 47.
On quad core 1500MHz Krait the policy->cpuinfo.min_freq = 384000
and the policy->cpuinfo.max_freq = 1512000. Thus, the CPU starts to scale
at load above 25.

Change the calculation of target frequency to eliminate the above effect using
the formula:

	Target frequency = A + B * load
	where A = policy->cpuinfo.min_freq and
	      B = (policy->cpuinfo.max_freq - policy->cpuinfo->min_freq) / 100

This will map load values 0 to 100 linearly to cpuinfo.min_freq to
cpuinfo.max_freq.

Also, use the CPUFREQ_RELATION_C in __cpufreq_driver_target to select the
closest frequency in frequency_table. This is necessary to avoid selection
of minimum frequency only when load equals to 0. It will also help for selection
of frequencies using a more 'fair' criterion.

In tables below is presented the difference in selected frequency for specific
values of load without and with this patch. On Intel i7-3770 @ 3.40GHz:
	Without			With
Load	Target	Selected	Target	Selected
0	0	1600000		1600000	1600000
5	170050	1600000		1690050	1700000
10	340100	1600000		1780100	1700000
15	510150	1600000		1870150	1900000
20	680200	1600000		1960200	2000000
25	850250	1600000		2050250	2100000
30	1020300	1600000		2140300	2100000
35	1190350	1600000		2230350	2200000
40	1360400	1600000		2320400	2400000
45	1530450	1600000		2410450	2400000
50	1700500	1900000		2500500	2500000
55	1870550	1900000		2590550	2600000
60	2040600	2100000		2680600	2600000
65	2210650	2400000		2770650	2800000
70	2380700	2400000		2860700	2800000
75	2550750	2600000		2950750	3000000
80	2720800	2800000		3040800	3000000
85	2890850	2900000		3130850	3100000
90	3060900	3100000		3220900	3300000
95	3230950	3300000		3310950	3300000
100	3401000	3401000		3401000	3401000

On ARM quad core 1500MHz Krait:
	Without			With
Load	Target	Selected	Target	Selected
0	0	384000		384000	384000
5	75600	384000		440400	486000
10	151200	384000		496800	486000
15	226800	384000		553200	594000
20	302400	384000		609600	594000
25	378000	384000		666000	702000
30	453600	486000		722400	702000
35	529200	594000		778800	810000
40	604800	702000		835200	810000
45	680400	702000		891600	918000
50	756000	810000		948000	918000
55	831600	918000		1004400	1026000
60	907200	918000		1060800	1026000
65	982800	1026000		1117200	1134000
70	1058400	1134000		1173600	1134000
75	1134000	1134000		1230000	1242000
80	1209600	1242000		1286400	1242000
85	1285200	1350000		1342800	1350000
90	1360800	1458000		1399200	1350000
95	1436400	1458000		1455600	1458000
100	1512000	1512000		1512000	1512000

Tested on Intel i7-3770 CPU @ 3.40GHz and on ARM quad core 1500MHz Krait
(Android smartphone).

Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
Signed-off-by: moddingg33k <moddingg33k@t-online.de>
cpufreq: remove race while accessing cur_policy

While accessing cur_policy during executing events
CPUFREQ_GOV_START, CPUFREQ_GOV_STOP, CPUFREQ_GOV_LIMITS,
same mutex lock is not taken, dbs_data->mutex, which leads
to race and data corruption while running continious suspend
resume test. This is seen with ondemand governor with suspend
resume test using rtcwake.

Signed-off-by: Bibek Basu <bbasu@nvidia.com>

---

- DISABLED: cpufreq / ondemand: update frequency when limits are relaxed
      (Reevaluate CPU load and update frequency immediately whenever limits
       are changed. Currently ondemand doesn't do that when limits are
       relaxed, wasting power on systems with relatively low sampling rate.)