random: make it possible to enable debugging without rebuild

The module parameter that turns debugging mode (which basically means
printing a few extra lines during runtime) is in '#if 0' block. Forcing
everyone who would like to see how entropy is behaving on his system to
rebuild seems to be a little bit too harsh.

If we were concerned about speed, we could potentially turn 'debug' into a
static key, but I don't think it's necessary.

Drop the '#if 0' block to allow using the 'debug' parameter without rebuilding.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
random: speed up the fast_mix function by a factor of four

By mixing the entropy in chunks of 32-bit words instead of byte by
byte, we can speed up the fast_mix function significantly.  Since it
is called on every single interrupt, on systems with a very heavy
interrupt load, this can make a noticeable difference.

Also fix a compilation warning in add_interrupt_randomness() and avoid
xor'ing cycles and jiffies together just in case we have an
architecture which tries to define random_get_entropy() by returning
jiffies.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Jörn Engel <joern@logfs.org>
random: adjust the generator polynomials in the mixing function slightly

Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and
Videau in their paper, "The Linux Pseudorandom Number Generator
Revisited" (see: http://eprint.iacr.org/2012/251.pdf).

They suggested a slight change to improve our mixing functions
slightly.  I also adjusted the comments to better explain what is
going on, and to document why the polynomials were changed.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
random: make add_timer_randomness() fill the nonblocking pool first

Change add_timer_randomness() so that it directs incoming entropy to
the nonblocking pool first if it hasn't been fully initialized yet.
This matches the strategy we use in add_interrupt_randomness(), which
allows us to push the randomness where we need it the most during when
the system is first booting up, so that get_random_bytes() and
/dev/urandom become safe to use as soon as possible.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
cfg80211: Fix memory leak

When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.

Change-Id: Id28fc9861b9c911a97bd242439eabca097d76258
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-commit: b7566fc363e23f0efd3fa1e1460f9421cdc0d77e
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mattw@codeaurora.org: trivially backport to the msm-3.4 kernel]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Decrease Swappiness

* From 60 to 10 since Nexus 5 has plenty of Ram.  I'm only running maybe 600 mb and I have quite a few programs.

Signed-off-by: Chester Kener <Cl3Kener@gmail.com>
msm: remove perf_debug
msm: pm: Add API to enable/disable retention mode
On 8974 targets, retention mode voltage is controlled by the LDO
regulator, which in turn is powered through a ganged PMIC regulators. At
certain low voltage levels, the ganged PMIC will not be able to power
the LDO retention voltage. The regulator framework would invoke this
API to enable/disable retention mode in these scenarios.

When disabling retention modes, send a IPI to wakeup all online cores
out of idle, to ensure that no core is in a retention low power mode.
Also, disabled support for retention during suspend/hotplug operations
to ensure that a CPU isn't already in retention when the voltage is
lowered. This shouldn't have an effect on suspend, as the driver always
chooses the deepest sleep mode for suspend/hotplug.

Change-Id: I0af18168968c2aaf05ca99188d30762612c87de6
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm-8x60: Disable premption in msm_pm_enable_retention

msm_pm_retention_enable() makes smp_call_function_many to ensure that
when a retention is disabled, the cores come out of its low power mode.
Per the smp_call_function_many documentations, preemption should be
disabled before invoking the API.

CRs-fixed: 463188
Change-Id: I4ae9137e8f8e821af729becd0e2d6e6886d5e787
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm-8x60: Add early return to msm_pm_enable_retention()

If retention is already disabled, it is not necessary to send IPIs to
the running CPUs to wake them up. Insert an early return for this
scenario to reduce overhead during Krait rail voltage scaling, which
calls this API on every voltage change.

Change-Id: I5db0bafae187ff8a68488e86d4787df9c45787e4
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: pm: support retention on CPU0 at suspend
gpu: ion: Add null-pointer check after allocation

Check for failed allocation and return appropritate
return code if memory allocation fails.

Change-Id: Iefb83b5e30c3cc581ccecaf6e59eae621be98083
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: Align va address to biggest buffer size

Align the virtual address to the max buffer size to
allow IOMMU mappings at the biggest buffer size.

Change-Id: I74ba665c1782e2f0631274766c5caeeb192224e0
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: enable the kmalloc heap

There are some Ion clients who would like to use the kmalloc
heap. Enable it.

Change-Id: Ie818be9e1211d52d489ad2cb63d94e2fddfc0f01
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
msm: Add support for ION Flushing without virtual address

Video has very large buffers to be flushed. Due to lack of
vmalloc space, ion_map_kernel cannot be called on each of
the video buffers. With this change the ion handle can be
flushed without the need of the kernel mapping.

Change-Id: If026f21e44a2cce6c2b8c232fc80a69d0dabcd14
Signed-off-by: Neeti Desai <neetid@codeaurora.org>

Conflicts:

	drivers/gpu/ion/ion_cp_heap.c
	drivers/gpu/ion/msm/msm_ion.c

Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
gpu: ion: Use correct type for variables

Use correct type for variables to prevent overflow of signed
type when assiging from an unsigned type.

Change-Id: I0055d35c7310d111de590db3798950fd98f1b298
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
gpu: ion: Do fallback when allocating large sizes

The preferred allocation of memory for kernel data structures in
ION is to use kmalloc. This is mainly for performance reasons. However,
we are not guaranteed to be able to allocate large sizes. So to keep
the code performing well and at the same time allow for larger allocations,
implement a fallback mechanism for allocation of memory for ION kernel data
structures.

CRs-Fixed: 488521
Change-Id: I8c6a13ad74cce69f590920d28c01a58f7a540fd2
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[Resolved merge conflict]
Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>

Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>
gpu: ion: Free the sgtable for CMA based heaps

When an sgtable is allocated with sg_alloc_table, the table needs
to be destroyed in addition to being freed. Destroy the sgtable
when freeing the associated memory.

Change-Id: Iedba81146ba453070790f071848f86826f7eec9c
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
msm: iommu: re-use existing buffers for `extra' mappings
There is a bug on some hardware that requires us to overmap Iommu
mappings by 2x. Currently, we set aside a dummy buffer onto which we
map all of these dummy mappings. In general, for large mappings it's
nice to use the more efficient iommu_map_range instead of calling
iommu_map repeatedly. However, with our current approach in
msm_iommu_map_extra we can't use iommu_map_range for page_sizes larger
than the dummy buffer. To avoid wasting memory by increasing the size
of the dummy buffer, we can simply remap on top of the the buffer
being mapped in the first place. Since the second mapping should never
be used (besides by the buggy hardware) this should not be a problem.

Re-use existing buffers for all `extra' mappings. Essentially, map the
same physical address range twice. To be extra safe, make the second
mapping read-only.

Change-Id: I35462ad50de8da1f2befa3e3f0895925535cdc98
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
gpu: ion: remove stale variable

Tracking the number of user mappings should be done in the Ion
heaps. Remove the variable that was used to track this in core Ion.

Change-Id: I715280515e3010bd002314aefe0ec8cdb37c143d
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>