no need for ULTRA overclock option, just name it OVERCLOCK

Conflicts:
	arch/arm/mach-msm/Kconfig
	arch/arm/mach-msm/acpuclock-8064.c
ext4: add ratelimiting to ext4 messages

In the case of a storage device that suddenly disappears, or in the
case of significant file system corruption, this can result in a huge
flood of messages being sent to the console.  This can overflow the
file system containing /var/log/messages, or if a serial console is
configured, this can slow down the system so much that a hardware
watchdog can end up triggering forcing a system reboot.

Google-Bug-Id: 7258357

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ext4: remove unused ac_ex_scanned

When looking at a bug report with:

> kernel: EXT4-fs: 0 scanned, 0 found

I thought wow, 0 scanned, that's odd?  But it's not odd; it's printing
a variable that is initialized to 0 and never touched again.

It's never been used since the original merge, so I don't really even
know what the original intent was, either.

If anyone knows how to hook it up, speak now via patch, otherwise just
yank it so it's not making a confusing situation more confusing in
kernel logs.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ext4: don't calculate total xattr header size unless needed

The function ext4_expand_extra_isize_ea() doesn't need the size of all
of the extended attribute headers.  So if we don't calculate it when
it is unneeded, it we can skip some undeeded memory references, and as
a bonus, we eliminate some kvetching by static code analysis tools.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ext4: address a benign compiler warning

When !defined(CONFIG_EXT4_DEBUG), mb_debug() should be defined as a
no_printk() statement instead of an empty statement in order to suppress
the following compiler warning:

fs/ext4/mballoc.c: In function ‘ext4_mb_cleanup_pa’:
fs/ext4/mballoc.c:2659:47: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
   mb_debug(1, "mballoc: %u PAs left\n", count);

Signed-off-by: Patrick Palka <patrick@parcs.ath.cx>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ext4: remove unreachable code in ext4_can_extents_be_merged()

Commit ("ext4: disable merging of uninitialized extents")
ensured that if either extent under consideration is uninit, we
decline to merge, and immediately return.

But right after that test, we test again for an uninit
extent; we can never hit this.  So just remove the impossible
test and associated variable.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ext4: remove unreachable code after ext4_can_extents_be_merged()

Commit ec22ba8e ("ext4: disable merging of uninitialized extents")
ensured that if either extent under consideration is uninit, we
decline to merge, and ext4_can_extents_be_merged() returns false.

So there is no need for the caller to then test whether the
extent under consideration is unitialized; if it were, we
wouldn't have gotten that far.

The comments were also inaccurate; ext4_can_extents_be_merged()
no longer XORs the states, it fails if *either* is uninit.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ext4: fix del_timer() misuse for ->s_err_report

That thing should be del_timer_sync(); consider what happens
if ext4_put_super() call of del_timer() happens to come just as it's
getting run on another CPU.  Since that timer reschedules itself
to run next day, you are pretty much guaranteed that you'll end up
with kfree'd scheduled timer, with usual fun consequences.  AFAICS,
that's -stable fodder all way back to 2010... [the second del_timer_sync()
is almost certainly not needed, but it doesn't hurt either]

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ext4: prevent kernel panic in case of uninitialized jinode

ext4: prevent kernel panic in case of uninitialized jinode

In some cases the kernel crash occurs during system suspend/resume:

[ 4095.041351] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 4095.050689] pgd = c0004000
[ 4095.053985] [00000000] *pgd=00000000
[ 4095.058807] Internal error: Oops: 5 [#1] PREEMPT SMP
[ 4095.064483] Modules linked in: wl12xx mac80211 pvrsrvkm_sgx540_120 cfg80211 compat [last unloaded: wl12xx_sdio]
[ 4095.064575] CPU: 1    Tainted: G    B        (3.0.31-01807-gfac16a0 #1)
[ 4095.064605] PC is at jbd2_journal_file_inode+0x38/0x118
[ 4095.064666] LR is at mpage_da_map_and_submit+0x48c/0x618
[ 4095.064697] pc : [<c01da5a8>]    lr : [<c01aeac0>]    psr: 60000013
[ 4095.064697] sp : c6e07c80  ip : c6e07ca0  fp : c6e07c9c
[ 4095.064727] r10: 00000001  r9 : c6e06000  r8 : 00000179
[ 4095.064758] r7 : c6e07ca0  r6 : c73b8400  r5 : 00000000  r4 : c59a7d80
[ 4095.064758] r3 : 00000038  r2 : 00000800  r1 : 00000000  r0 : c7754fc0
[ 4095.064788] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[ 4095.064819] Control: 10c5387d  Table: 86cc804a  DAC: 00000015
[ 4095.064849]
[ 4095.064849] PC: 0xc01da528:
[ 4095.064880] a528  0a000003 e3a05000 e1a00005 e24bd020 e89da9f0 e5951010 e3e06000 e14b22dc
.....
[ 4095.070373] 7fe0: c00a48ac 00000013 00000000 c6e07ff8 c00a48ac c00c0a94 84752f09 60772177
[ 4095.070404] Backtrace:
[ 4095.070465] [<c01da570>] (jbd2_journal_file_inode+0x0/0x118) from [<c01aeac0>] (mpage_da_map_and_submit+0x48c/0x618)
[ 4095.070495]  r7:c6e07ca0 r6:c6e07d00 r5:c6e07d90 r4:c7754fc0
[ 4095.070556] [<c01ae634>] (mpage_da_map_and_submit+0x0/0x618) from [<c01af40c>] (ext4_da_writepages+0x2a4/0x5c8)
[ 4095.070617] [<c01af168>] (ext4_da_writepages+0x0/0x5c8) from [<c0112af4>] (do_writepages+0x34/0x40)
[ 4095.070678] [<c0112ac0>] (do_writepages+0x0/0x40) from [<c01645a4>] (writeback_single_inode+0xd4/0x288)
[ 4095.070709] [<c01644d0>] (writeback_single_inode+0x0/0x288) from [<c0164ed4>] (writeback_sb_inodes+0xb4/0x184)
[ 4095.070770] [<c0164e20>] (writeback_sb_inodes+0x0/0x184) from [<c01655a0>] (writeback_inodes_wb+0xc4/0x13c)
[ 4095.070831] [<c01654dc>] (writeback_inodes_wb+0x0/0x13c) from [<c01658f0>] (wb_writeback+0x2d8/0x464)
[ 4095.070861] [<c0165618>] (wb_writeback+0x0/0x464) from [<c0165cb8>] (wb_do_writeback+0x23c/0x2c4)
[ 4095.070922] [<c0165a7c>] (wb_do_writeback+0x0/0x2c4) from [<c0165df4>] (bdi_writeback_thread+0xb4/0x2dc)
[ 4095.070953] [<c0165d40>] (bdi_writeback_thread+0x0/0x2dc) from [<c00c0b18>] (kthread+0x90/0x98)
[ 4095.071014] [<c00c0a88>] (kthread+0x0/0x98) from [<c00a48ac>] (do_exit+0x0/0x72c)
[ 4095.071044]  r7:00000013 r6:c00a48ac r5:c00c0a88 r4:c78c7ec4
[ 4095.071105] Code: e89da8f0 e5963000 e3130002 1afffffa (e5913000)
[ 4095.071166] ---[ end trace 7fe9f9b727e5cf78 ]---
[ 4095.071197] Kernel panic - not syncing: Fatal exception

The probably reason of such behaviour is an inode opened in READ mode
has been marked as 'dirty' somehow and written back by ext4_da_writepages.
Cause jinode == NULL it could lead to the kernel panic.

The patch prevents kernel panic and helps to investigate the problem
providing an inode number.

Change-Id: I1d77a011b580db682b8e2d122ef3d5e44e0ce5c7
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: acpuclock-krait: Program both high- and low-performance sources

The latest LDO/BHS switching sequence employed in the 8974
krait-regulator driver involves mandatory operations that cause
the CPUs to switch to the low-performance clock source when the
CPU is powered from the LDO, and to the high-performance clock
source when powered from the BHS.

This results in potential undervolting of the CPUs since the
acpuclock driver does not program the low-performance source,
and the clock source it selects be default is running at the
same speed as DDR (which can be very fast).

Fix this by programming both the high and low-performance clock
sources to be the same at all times.

CRs-Fixed: 538629
Change-Id: Iaa39cca9165b892e52acd8ec3aac5d0784112623
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: acpuclock-krait: Fix HFPLL regulator voting in regulator_init()

Simply incrementing l2_vreg_count is not enough to ensure the
regulators necessary for the L2 HFPLL are enabled. Instead,
enable_l2_regulators() must be called to place votes for the
regulators.

This problem will only result in incorrect behaviour (a missing
vote for the HFPLL regulators) if the L2 rate detected at boot is
not in the frequency table. In all other cases, the vote will be
applied as part of the hfpll_enable call when init_clock_sources()
is called for the L2.

Fix the code so that the voting works correctly even if the initial
L2 rate is not in the frequency table.

Change-Id: I8e84cd81de17a0efcc91281848180cf34ef9bb57
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/acpuclock-krait.c
msm: acpuclock-krait: Update 'unknown rate' debug prints to warnings

While not fatal, boot performance will be suboptimal if the L2 or
CPU frequencies at boot are not in the frequency tables. This is
because acpuclock 'plays it safe' by applying the lowest possible
clock rate in such situations to ensure clocks are not set higher
than boot-up voltages can support.

Change-Id: I07fcff70d742b2590fa996ea4ca7a1f1c560eee3
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/acpuclock-krait.c
lib: devres: Introduce devm_ioremap_resource()

The devm_request_and_ioremap() function is very useful and helps avoid a
whole lot of boilerplate. However, one issue that keeps popping up is
its lack of a specific error code to determine which of the steps that
it performs failed. Furthermore, while the function gives an example and
suggests what error code to return on failure, a wide variety of error
codes are used throughout the tree.

In an attempt to fix these problems, this patch adds a new function that
drivers can transition to. The devm_ioremap_resource() returns a pointer
to the remapped I/O memory on success or an ERR_PTR() encoded error code
on failure. Callers can check for failure using IS_ERR() and determine
its cause by extracting the error code using PTR_ERR().

devm_request_and_ioremap() is implemented as a wrapper around the new
API and return NULL on failure as before. This ensures that backwards
compatibility is maintained until all users have been converted to the
new API, at which point the old devm_request_and_ioremap() function
should be removed.

A semantic patch is included which can be used to convert from the old
devm_request_and_ioremap() API to the new devm_ioremap_resource() API.
Some non-trivial cases may require manual intervention, though.

Change-Id: I458afe18768979122c12e95bffe979a31f02f607
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: 75096579c3ac39ddc2f8b0d9a8924eba31f4d920
Git-repo: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
msm: pcie: fix PCIe RAM issue on APQ8064v1

PCIe packet corruption has been observed on APQ8064 CDP, where
bits are flipped when sending packets over a PCIe GigE interface.
The RAM used for transfers was determined to be the source of
the problem. A software solution here is to limit the TLP size from
the default 4KB to 2KB based on the PCIe core version.

Change-Id: Iafda58963643424f7c0d647c487ffe6316037e66
Signed-off-by: Yan He <yanhe@codeaurora.org>
msm: clock-8960: Add 1.8MHz rate to 8064's gfx3d_clk plan

This rate will be used by the 'footswitch-8x60' driver when
controlling GFX3D power.

Change-Id: Ib796114dc90b468f1c0aa014a9db699f3b854adf
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: footswitch-8x60: Allow specification of per-fs reset delays

Custom reset rates can be specified for clocks via fs_clk_data. If
these rates are very low, then the default reset delay of 1us may
not be sufficient. Address this by allowing custom reset delays to
be specified on a per-footswitch bases.

Change-Id: Id9b9377d79436a7fe5007a8f37216a456d66ce1a
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
adjust reset delay and lower clockspeed
tweak cpu_freqs a bit for battery
update version to 77u
mm: slub: Default slub_max_order to 0

To avoid locking and per-cpu overhead, SLUB optimisically uses
high-order allocations up to order-3 by default and falls back to
lower allocations if they fail. While care is taken that the caller
and kswapd take no unusual steps in response to this, there are
further consequences like shrinkers who have to free more objects to
release any memory. There is anecdotal evidence that significant time
is being spent looping in shrinkers with insufficient progress being
made (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.

SLUB is now the default allocator and some bug reports have been
pinned down to SLUB using high orders during operations like
copying large amounts of data. SLUBs use of high-orders benefits
applications that are sized to memory appropriately but this does not
necessarily apply to large file servers or desktops.  This patch
causes SLUB to use order-0 pages like SLAB does by default.
There is further evidence that this keeps kswapd's usage lower
(https://lkml.org/lkml/2011/5/10/383).

Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: flar2 <asegaert@gmail.com>