Merge "Revert "Revert "msm: cache_erp: Handle recoverable L1 errors"""
arm: Move the secondary_startup to __CPUINIT section.

Because of addition 1MB alignment after head.txt section,
the secondary_startup needs to move to 1MB aligned section.

CRs-Fixed: 513919
Change-Id: I332d1e4ec95c877406c6ad3318e5f9a3c85cc10f
Signed-off-by: Venkatesh Yadav Abbarapu <quicvenkat@codeaurora.org>
msm: Make CONFIG_STRICT_MEMORY_RWX even stricter

If CONFIG_STRICT_MEMORY_RWX was set, the first section (containing
the kernel page table and the initial code) and the section
containing the init code were both given RWX permission, which is
a potential security hole.

Pad the first section after the initial code (which will never
be executed when the MMU is on) to make the rest of the kernel
text start in the second section and make the first section RW.

Move some data which had ended up in the "init text"
section into the "init data" one, as this is RW, not RX.
Make the "init text" RX.

We will not free the section containing the "init text",
because if we do, the kernel will allocate memory for RW data there.

Change-Id: I6ca5f4e07342c374246f04a3fee18042fd47c33b
CRs-fixed: 513919
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>
sync: signal pt before sync_timeline object gets destroyed

There is a race condition

Assume we have *one* sync_fence object, with *one* sync_pt
which belongs to *one* sync_timeline, given this condition,
sync_timeline->kref will have two counts, one for sync_timeline
(implicit) and another for sync_pt.

Assume following is the situation on CPU

Theead-1 : (Thread which calls sync_timeline_destroy())
  -> (some function calls)
   -> sync_timeline_destory()
    -> sync_timeline_signal() (CPU is inside this
function after putting reference to sync_timeline)

At this time Thread-2 comes and does following

Thread-2 : (fclose on fence fd)
> sync_fence_release() -> because of fclose() on fence object
 -> sync_fence_free()
  -> sync_pt_free()
   -> kref_put(&pt->parent->kref, sync_timeline_free);
    -> sync_timeline_free() (CPU is inside this because
this time kref will be zero after _put)

Thread-2 will free sync_timeline object before Thread-1
has finished its work inside sync_timeline_signal.

With this change we signals all sync_pt before putting
reference to sync_timeline object.

Change-Id: I66d7359cc5dca0352fda49f81953028e98b95993
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
init: Move stack canary initialization after setup_arch

Stack canary intialization involves getting a random number.
Getting this random number may involve accessing caches or other
architectural specific features which are not available until
after the architecture is setup. Move the stack canary initialization
later to accomodate this.

Change-Id: I00b564a2c3172229a44339c061fa380c17fe7d8e
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: implement ARCH_RANDOM

Currently, the software random number generator is not intialized
until relatively late in the boot process. Software that relies on
random numbers early will not be reliable. Entropy sources are
available early but not early enough for some use cases which means
that moving the software random number generation earlier is not an
option. As an alternate solution, implement the functions associated
with CONFIG_ARCH_RANDOM. These functions currently make a call into
trustzone to get reliable random numbers. The functions are disabled
once the regular random number generator is sufficiently reliable.

Change-Id: If40cfcb96b091fa26a28047c10a902287b26f6c1
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
arm: Add ARCH_RANDOM Kconfig

Some boards may support architecture generated random numbers. Add
the appropriate Kconfig.

Change-Id: I0077a982c9bb6d3a35435cc27fe40b7e0596ca84
CRs-Fixed: 498392
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
ARM: 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS

The {get,put}_user macros don't perform range checking on the provided
__user address when !CPU_HAS_DOMAINS.

This patch reworks the out-of-line assembly accessors to check the user
address against a specified limit, returning -EFAULT if is is out of
range.

[will: changed get_user register allocation to match put_user]
[rmk: fixed building on older ARM architectures]

CRs-Fixed: 504011
Change-Id: I3818045a136fcdf72deb1371b132e090fd7ed643
Reported-by: Catalin Marinas <catalin.marinas@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>
Git-commit: 8404663f81d212918ff85f493649a7991209fa04
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
usb: u_bam: Fix spinlock leak followed by lockup from workqueue

Driver has missing code to release spinlock while returning from
workqueue in case of memory allocation failures.
Returning from workqueue without releasing spinlock messes up
with worker thread and kernel keeps throwing up warnings like:
"BUG: workqueue leaked lock or atomic: kworker/u" for any
sleeping function called from worker thread afterwards. Later
when driver again tries to acquire same (unreleased) spinlock
it results in spinlock lockup.

CRs-Fixed: 497158
Change-Id: I4eaa7aaa42ed95a9b78a8939e80f4c0694e574b2
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
EHCI: HSIC: Disable CPU Idle states before resuming the port

The CPU idle states are disabled to reduce the USB GPT interrupt
latency during bus resume.  The pm_qos_update_request() is blocked
until all the online cores are brought out of idle states. If this
call is blocked for longer time than resume signaling, the resume
sequence is repeated again.  Fix it by calling pm_qos_update_request()
before resuming the port.

CRs-Fixed: 515547
Change-Id: I651910bf3ac296914af3642718bca3aa07d0d407
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
sync: Limit logging to particular fence on timeout and error

Change-Id: I5bd7d62260666cdd2a32212f0e828d2d5d7d7bba
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Ananta Kishore K <akollipa@codeaurora.org>
net: rmnet_usb: silence URB submission errors during disconnect

URB submissions will fail with -ENODEV while the device is being
disconnected.  The current code prints error message for an URB
submission failure.  If too many URBs are submitted during the
disconnect window, then target is crashing due to excessive
console logging.

CRs-Fixed: 507556
Change-Id: I287c5021bacb2238b62bf78a8ddf887f588b6f16
Signed-off-by: Pavankumar Kondeti <pkondeti@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: dcvs: fail gracefully if TZ does not support dcvs

If dcvs attempts to initialize on a system where TZ does not support
dcvs, it will eventually cause a crash. Prevent this by disabling
dcvs if TZ does not successfully initialize its part of dcvs.

Change-Id: Ic9cd361243c03c3832133614c4847a2815b0bbb4
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
msm: ipc: Serialize SMD XPRT CLOSE and OPEN events

When a remote subsystem resets, IPC Router's SMD XPRT Layer queues a CLOSE
event. When the concerned subsytem powers up and the channel is reopened,
SMD XPRT Layer queues a OPEN event. When the remote subsytem resets and
powers up quickly, the following race condition exists:
a) IPC Router is scheduled out while handling the CLOSE event, leaving a
   stale XPRT
b) IPC Router's SMD XPRT Layer queues a OPEN event
c) IPC Router's SMD XPRT Layer reads a HELLO message, finds a stale
   XPRT and queues a DATA event on the stale XPRT
This race condition causes a kernel panic.

Fix this race condition by not handling any other SMD XPRT event until
the CLOSE event is complete.

CRs-Fixed: 488331
Change-Id: I2283e163413d1896bd6842530b8a6a2b537e22de
Signed-off-by: Zaheerulla Meer <zmeer@codeaurora.org>