Change audio_policy.conf as users report noice with AC3 decoded files.
On boot, my thermal control hold cpu 3 in OFF state... READ MORE.

So on boot only kernel/cpu.c scream that CPU 3 cant be enabled!

well that is OK! :)

4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed
4>_cpu_up: attempt to bring up CPU 3 failed

reduce this panic to 1 in 5 * HZ interval.

so i will see maybe 5 alerts during boot! not 50 :)
THERMAL CONTROL: Prevent too high CPU temp on boot.
THERMAL CONTROL: Use sensor 0 (GLOBAL CPU TEMP) and tune boot values.
MSM HOTPLUG: Set fastlane min freq higher, but reduce min load check.
random: convert use of typedef ctl_table to struct ctl_table

This typedef is unnecessary and should just be removed.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
random: fix typos / spelling errors in comments

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: fix comment on proc_do_uuid

There's only one function here now, as uuid_strategy is long gone.
Also make the bit about "If accesses via ..." clearer.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: fix description of get_random_bytes

After this remark was written, commit d2e7c96af added a use of
arch_get_random_long() inside the get_random_bytes codepath.
The main point stands, but it needs to be reworded.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
RANDOM: Clean old hack before updating the code.
random: simplify loop in random_read

The loop condition never changes until just before a break, so we
might as well write it as a constant.  Also since a996996dd75a
("random: drop weird m_time/a_time manipulation") we don't do anything
after the loop finishes, so the 'break's might as well return
directly.  Some other simplifications.

There should be no change in behavior introduced by this commit.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: fix comment on "account"

This comment didn't quite keep up as extract_entropy() was split into
four functions.  Put each bit by the function it describes.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: simplify accounting logic

This logic is exactly equivalent to the old logic, but it should
be easier to see what it's doing.

The equivalence depends on one fact from outside this function:
when 'r->limit' is false, 'reserved' is zero.  (Well, two facts;
the other is that 'reserved' is never negative.)

Cc: Jiri Kosina <jkosina@suse.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: forget lock in lockless accounting

The only mutable data accessed here is ->entropy_count, but since
10b3a32d2 ("random: fix accounting race condition") we use cmpxchg to
protect our accesses to ->entropy_count here.  Drop the use of the
lock.

Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: tighten bound on random_read_wakeup_thresh

We use this value in a few places other than its literal meaning,
in particular in _xfer_secondary_pool() as a minimum number of
bits to pull from the input pool at a time into either output
pool.  It doesn't make sense to pull more bits than the whole size
of an output pool.

We could and possibly should separate the quantities "how much
should the input pool have to have to wake up /dev/random readers"
and "how much should we transfer from the input to an output pool
at a time", but nobody is likely to be sad they can't set the first
quantity to more than 1024 bits, so for now just limit them both.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: simplify accounting code

With this we handle "reserved" in just one place.  As a bonus the
code becomes less nested, and the "wakeup_write" flag variable
becomes unnecessary.  The variable "flags" was already unused.

This code behaves identically to the previous version except in
two pathological cases that don't occur.  If the argument "nbytes"
is already less than "min", then we didn't previously enforce
"min".  If r->limit is false while "reserved" is nonzero, then we
previously applied "reserved" in checking whether we had enough
bits, even though we don't apply it to actually limit how many we
take.  The callers of account() never exercise either of these cases.

Before the previous commit, it was possible for "nbytes" to be less
than "min" if userspace chose a pathological configuration, but no
longer.

Cc: Jiri Kosina <jkosina@suse.cz>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: entropy_bytes is actually bits

The variable 'entropy_bytes' is set from an expression that actually
counts bits.  Fortunately it's also only compared to values that also
count bits.  Rename it accordingly.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: clarify bits/bytes in wakeup thresholds

These are a recurring cause of confusion, so rename them to
hopefully be clearer.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: use the architectural HWRNG for the SHA's IV in extract_buf()

To help assuage the fears of those who think the NSA can introduce a
massive hack into the instruction decode and out of order execution
engine in the CPU without hundreds of Intel engineers knowing about
it (only one of which woud need to have the conscience and courage of
Edward Snowden to spill the beans to the public), use the HWRNG to
initialize the SHA starting value, instead of xor'ing it in
afterwards.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: Use arch_get_random_seed*() at init time and once a second

Use arch_get_random_seed*() in two places in the Linux random
driver (drivers/char/random.c):

1. During entropy pool initialization, use RDSEED in favor of RDRAND,
   with a fallback to the latter.  Entropy exhaustion is unlikely to
   happen there on physical hardware as the machine is single-threaded
   at that point, but could happen in a virtual machine.  In that
   case, the fallback to RDRAND will still provide more than adequate
   entropy pool initialization.

2. Once a second, issue RDSEED and, if successful, feed it to the
   entropy pool.  To ensure an extra layer of security, only credit
   half the entropy just in case.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>