msm: fix in-tree compilation for perf_trace_counters

In-tree compilation for arch/arm/mach-msm/perf_trace_counters.c was
hitting this error:

    In file included from arch/arm/mach-msm/perf_trace_counters.h:127:0,
                     from arch/arm/mach-msm/perf_trace_counters.c:14:
    include/trace/define_trace.h:79:43: fatal error: ./perf_trace_counters.h: No such file or directory

Instructions for TRACE_INCLUDE_FILE in include/trace/define_trace.h say
"the path is relative to define_trace.h, not the file including it".
Fix in-tree compilation by making the path relative to define_trace.h.

Signed-off-by: Bryan Huntsman <bryanh@codeaurora.org>
msm: kgsl: Protect against a potential overflow in kgsl_sg_alloc

Avoid allocating a scatterlist so large that it overflows the size
passed to the memory allocators.

CRs-fixed: 564448
Change-Id: Ic0dedbad2ab421ddec8f3be38d61c9bdf9ae5bd4
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
diag: dci: Check for request pkt length being lesser than minimum length

Added checks for DCI request packets to be greater than the minimum
packet length. We would drop the request and print an error otherwise.

CRs-Fixed: 483310
Change-Id: I0d89ded58ee97a08ebe6b06b411ac17d2fcb11df
Signed-off-by: Ravi Aravamudhan <aravamud@codeaurora.org>
diag: Fix diag crash due to memory corruption

Diag allocates memory based on the count received from userspace.
Add check to validate the memory pointer before derefencing it.

CRs-Fixed: 487981
Change-Id: Ibfee22d02bb2312192de7c811d9917ecab728269
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
diag: Fix race condition in diagchar driver

diag driver maintains socket logging process in global driver
structure which is manipulated in switch_logging and in close
file_operation.
There is a possibility of race while clearing the socket logging
process in close operation and sending signal in switch_logging
operation. Adding lock to serialize the two operations.

CRs-Fixed: 495063
Change-Id: I0064509c9ace18a8ff40c5a744363546a9021612
Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org>
diag: Fix incorrect handling of buffers

In diag driver, processing dci transaction takes place even if the
incoming buffer is invalid. Also, we are handling the memory pools
incorrectly. This patch fixes these two issues

Change-Id: Ibdcc9759e3e1030f34f82c4e6b0315a8e5c79ab7
Signed-off-by: Ravi Aravamudhan <aravamud@codeaurora.org>
mms: rng: Add bus bandwidth support to PRNG

PRNG has to use pnoc clock, but pnoc is a bus clock & clients cannot
directly call pnoc apis, so prng calls bus bandwidth api to get the
clock cycles.

Change-Id: Ib3cd075097b4b70f82ec6325535e6e39808c6408
Signed-off-by: Hariprasad Dhalinarasimha <hnamgund@codeaurora.org>
diag: Skip checking diag bridge for SMUX when it is not enabled

Diag driver using SMUX over diag_bridge. When SMUX is not enabled,
it checks the other channels during initialization. This patch
skips checking other channels when SMUX is not enabled.

Change-Id: Ia155bc91d0332eae0a1341ce450ffe49aa7b9e1a
Signed-off-by: Ravi Aravamudhan <aravamud@codeaurora.org>
diag: Change maximum size of error response

Diag currently allows error responses of length 490 bytes. This is
outdated as we support 4K responses on the Apps. This patch changes
the Apps buffer size to 4K and also the limit on the error response
length.

Change-Id: I8212bf000a7493b756b5ac0e428c3b2e4be9e9c6

CRs-Fixed: 512035
Signed-off-by: Ravi Aravamudhan <aravamud@codeaurora.org>
random: add new get_random_bytes_arch() function

commit c2557a303ab6712bb6e09447df828c557c710ac9 upstream.

Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present.  Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.

The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door.  (For example, an
increasing counter encrypted by an AES key known to the NSA.)

It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
  --- especially since Bull Mountain is documented to use AES as a
whitener.  Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel.  Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.

Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.

This way we get almost of the benefits of the HW RNG without any
potential liabilities.  The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.

For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Patrick Tjin <pattjin@google.com>
panic: force console_unlock() in panic()

If panic() is called when console is locked,
oops message can't be printed in console.
Especially, android ram_console doesn't have any information in this case.
Thus, console_unlock() in panic() if console is locked.

Change-Id: Ifbac48875ac189c35ed380b67734d0411bed2c08
Signed-off-by: Bongkyu Kim <bongkyu.kim@lge.com>
panic: resume console if panic after console suspend.

Device rebooted by kernel panic but no panic message.
This helps to get the panic messages in this case.

Bug: 10184128
Change-Id: I24545b1ce2f9e3e239795089d8564c2cc5f89fe7
Signed-off-by: shihhao.feng <shihhao.feng@lge.com>
Signed-off-by: Devin Kim <dojip.kim@lge.com>
coresight: use trigin 2 for cti reset trigger for tmc-etr

Flush ETR is mapped to TRIGIN[2] and so switch to using it in
order to cause a CTI trigger for TMC-ETR flush during wdog reset.

This avoids any race between TMC-ETR flush to memory and DDR
being put into self-refresh.

CRs-Fixed: 491986
Change-Id: Ia5e643121e040bd9c57c89a4b762b794bc8ddf62
Signed-off-by: Pratik Patel <pratikp@codeaurora.org>
coresight: remove hotplug locking from etm probe

Calling register_hotcpu_notifier inside of get/put_online_cpus
i.e. after taking the cpu_hotplug lock results in a deadlock
since register_hotcpu_notifier takes the cpu_add_remove_lock
which has already been acquired by the hotplug code before
requesting the cpu_hotplug lock.

Remove the get/put_online_cpus calls since they are not required.

CRs-Fixed: 501374
Change-Id: I3fb58265f6fedeb696d035d281af0d7904e28b79
Signed-off-by: Pratik Patel <pratikp@codeaurora.org>
coresight: add coresight fuse driver

Add support for CoreSight Fuse driver which can be used by other
CoreSight drivers to query the state of the CoreSight fuses to
determine if the Hardware they manage is functionally disabled or
not.

Drivers can then take necessary actions like failing the probe if
the Hardware they manage is functionally disabled.

Change-Id: I2c2a2af064db750539b0ffa33870ddb7a2832e68
Signed-off-by: Pratik Patel <pratikp@codeaurora.org>
coresight: add coresight fuse state query

Add support to query CoreSight fuse state and fail the probe
if any of the required fuse(s) are disabled. This enables
a single image with CoreSight drivers compiled in to be run on
both Hardware that has CoreSight functionality disabled via fuse
or left enabled for use.

Change-Id: Ib770cc7f76e2b0644bda9600c92fc3a26823452d
Signed-off-by: Pratik Patel <pratikp@codeaurora.org>
crypto: msm: Add support for setting ctx flags

Currently there is no way of instructing the crypto driver
to use HW specific capabilities. The kernel crypto framework
does not expose any API to set any specific HW feature flags:
ex: use of HW key,  use of PIPE keys, setting XTS data unit
size.

The driver currently uses a specific key pattern to decide
when to instruct HW to use HW_KEY (uses key pattern of all
zeros) and when to use PIPE_KEY (uses key pattern of all 0xF's).
This limits the use of the specific key pattern from ever being
used for any crypto operation.

Adding support for crypto client to set flags to indicate when
to use HW KEY, PIPE KEY, size removes the limitation on the key
patterns that can be used by the driver.

Adding XTS data unit size flags allows the client to take
advantage of the hardware capability to set data unit size
for XTS operations.

Change-Id: I0d1417a6d3c990e0750dbd90e3816f45fec8d693
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
crypto: msm: Process keydata for HW/PIPE key use case

When client sets HW_KEY flag, driver should ignore key data
and length when client issues set_key request.
When client sets PIPE_KEY flag, driver should ignore key data.

Change-Id: I550d1d2a217e6b9c9de50064bfafe72f9f32e6e1
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
crypto: msm: Designate memory chunk for ignore_buffer

Memory was not assigned to ignore_buffer pointer and uninitialized
pointer was being used.

Change-Id: Ie7c372aeafdfe17b9bb70d38666fa81c3df1e043
Signed-off-by: Mona Hossain <mhossain@codeaurora.org>
crypto: msm: set ce_shared flag as zero when using BAM HW

CE HW sharing is not supported when BAM hardware is used, so
we need to set the corresponding ce_shared flag as zero in
qcedev_probe().

Change-Id: I28f0cb9c453a473970742f80fc16379ec7183771
Signed-off-by: Zhen Kong <zkong@codeaurora.org>