isa1200: move sysfs node for pwm level

Change-Id: I50b353531a1ee581217305b257d30317ce73b0c7
Touch Wake : disabled if incall (fix)

Credits googyanas

Change-Id: If09ac2b4dff311ac7b1e02893425d7c8860dc268
Touch to wake: Different infinite mode handling (AndiP71)

- if touch wake delay is set to 0 (infinite mode), the power button will
  now also disable touch to wake (like it is for normal delays)

Change-Id: I0239664cc2f2c0be75f6bd962b9747bd9c4805ad
Touch Wake : bump to v1.1  (Yank555.lu)

- fix git merge derp in drivers/sensor/cm36651.c
- fix random misbehaving related to powerkey / proxy
- slight code cleanup
- optimized using likely / unlikely
- added precise debugging prints (enabled by #define)

Change-Id: Ib97aae62000d44c51f7d58b0ea0c69fc1898f878
Touch Wake : bump to v1.1 (Yank555.lu)

- fix git merge derp in drivers/sensor/cm36651.c
- fix random misbehaving related to powerkey / proxy
- slight code cleanup
- optimized using likely / unlikely
- added precise debugging prints & sysfs file (enabled by #define)

NB: This second commit fixes a wrong understand due to the merge derp.

Change-Id: I5a39016f2ed525a02c650bb48fdf574a798f3172
Touch Wake : bump to v1.1a (Yank555.lu)

- fixed touch wake disbaled as soon as proxy sensor was enabled, no matter if proximity was detected or not (my derp, introduced in 1.1)
- fixed proximity state change detection (is in cm36651.c, not ssp_input.c, which is not compiled for i9300)
- removed "off hook" detection, it was relying on a constant (PSTN_ON_HOOK, defined in telephony.h), so made no sense to keep it

Change-Id: Ifea7432463e0c4cb2b53dbf05f782778a58037bf
smdk4412: Boeffla Sound 1.6.5

Change-Id: I05aed9e86a5ddc8eb917e253afa1768dda79f089
Merge "smdk4412: Boeffla Sound 1.6.5" into kk4.4
cypress-touchkey : add sysfs interface to enable/disable lighting hardwarekey backlight on screen touch (Yank555.lu)

Change-Id: Ie8810749d21ab94a76618864afe4832f1309f8b7
cypress-touchkey : add sysfs interface to enable/disable lighting hardwarekey backlight on screen touch (Yank555.lu)

- prevent h/w keys to light up on late_resume as well if disabled

Change-Id: If4b03cd3f5392c898a05bac92c8c830e532e6785
Merge branch 'kk4.4' of https://github.com/SlimRoms/kernel_samsung_smdk4412 into kk4.4
Revert "Set SELinux to permissive"

Lets default  SELinux to enforced
This reverts commit 3e5b1230a82b9131aed9b748da56aab085f0c65a.

Change-Id: I7da332d97964b748b39f81edfdb520a9c690cc7e
Signed-off-by: Josue Rivera <prbassplayer@gmail.com>
Merge branch 'kk4.4' of https://github.com/SlimRoms/kernel_samsung_smdk4412 into kk4.4
Revert "Adapted zzmoove to i9100"

This reverts commit ec3c9fa29e4808911ee1531f132533d7eb6c22f8.
Version 0.8 - cool down baby

Changelog:

- indroduced scaling block cycles (in normal and legacy mode) to reduce unwanted jumps to higher frequencies (how high depends on settings)
  when a load comes up just for a short peroid of time or is hitting the scaling up threshold more often because it is within some higher
  to mid load range. reducing these jumps lowers CPU temperature in general and may also save some juice. so with this function u can influence
  the little bit odd scaling behaving when you are running apps like for example games which are constantly 'holding' system load in
  some range and the freq is scaled up too high for that range. in fact it just looks like so, monitoring apps are mostly too slow to catch load in
  realtime so you are watching almost only 'the past'. so actually it's not really odd it's more like: an app is stressing the system and holding
  it on a higher load level, due to this load level scaling up threshold is more often reached (even if monitoring shows a lower load
  than up_threshold) the governor scales up very fast (usual zzmoove behaving) and almost never scales down again (even if monitoring shows
  a lower load than down_threshold). now in patricular these scaling block cycles are throttling up scaling by just skipping it
  for the amount of cycles that you have set up and after that are making a forced scale down in addition for the same amount of cycles. this
  should bring us down to a 'appropriate' frequency when load is hanging around near up threshold.
- indroduced (D)ynamic (S)ampling (R)ate - thx to hellsgod for having the same idea at the same time and pointing me to an example. even though
  at the end i did 'my way' :) DSR switches between two sampling rates depending on the given load threshold from an 'idle' to a 'normal' one.
- added read only tuneable 'sampling_rate_current' for DSR to show current SR and internally use this sampling rate instead of automatically
  changing 'sampling_rate' tuneable in DSR. this keeps things more compatible and avoids problems when governor tuneables are set with tuning
  apps which are saving actual shown values.
- changed setting of sampling rate in governor from 'sampling_rate' to 'sampling_rate_current' and the value at suspend to 'sampling_rate_idle'
  value instead of using current active sampling rate to avoid accidentally setting of 'normal operation' sampling rate in sampling rate idle mode
  which has usually a much lower value
- indroduced build-in profiles in seperate header file (credits to Yank555 for idea and prototype header file)
  you can switch between multible build in profiles by just piping a number into the tuneable 'profile_number'. all tuneable values of the set
  profile will be applied on-the-fly then. if a profile is active and you change any tuneable value from it to a custom one the profile will
  switch to '0' in 'profile_number' and 'custom' in 'profile' for information. with this profiles support developers can simplify their governor
  settings handling by adding all their desired and well proven governor settings into the governor itself instead of having to fiddle around with
  init.d scripts or tuning apps. NOTE: this is just an optional feature, you can still set all tuneables as usual just pay attention that the
  tuneable 'profile_number' is set to '0' then to avoid overwriting values by any build-in profile. for further details about profiles and
  adding own ones check provided 'cpufreq_zzmoove_profiles.h' file.
- added 'profiles_version' tuneable to be able to show seperate profiles header file version
- added enabling of offline cores on governor exit to avoid cores 'stucking' in offline state when switching to a non-hotplug-able governor
  and by the way reduced reduntant code by using an inline function for switching cores on and using the better 'sheduled_work_on-way'
  at all needed places in the code for that purpose
- moved some code parts to legacy mode macro which has only relevance when including the legacy mode in the governor and in addition
  excluded it during runtime if legacy mode is disabled.
- improved freq limit handling in tuneables and in dbs_check_cpu function
- changed value restriction from '11' to '1' in hotplug down threshold and grad up tuneables as this restriction is only nessesary in
  scaling down tuneable
- added missing fast scaling down/normal scaling up mode to fast scaling functionality (value range 9-12 and only available in non-legacy mode
  thx OldBoy.Gr for pointing me to that missing mode)
- added auto fast scaling aka 'insane' scaling mode to fast scaling functionality - lucky number 13 enables this mode in fast_scaling tuneable
  NOTE: a really funny mode, try it :) but keep in mind setting this in combination with a set freq limit (at sleep or awake)would not make much
  sense as there is not enough frequency range available to jump around then.
- back from the precautious 'mutex_try_lock' to normal 'mutex_lock' in governor 'LIMIT' case -> this should be save again,
  no deadlocks expected any more since hotplug logic has significantly changed in zzmoove version 0.6
- removed also the no longer required and precautious skipping of hotplugging and dbs_check_cpu on multiple places in code and removed
  the mutex locks at governor stop and early suspend/late resume
- added hotlug freq thresholds to legacy scaling mode (same usage as in normal scaling mode)
- seperated hotplug down and up block cycles to be more flexible. this replaces 'hotplug_block_cycles' with 'hotplug_block_up_cycles' tuneable
  and adds one new tunable 'hotplug_block_down_cycles'. functionality is the same as before but u can now differentiate the up and down value.
- added 'early demand sleep' combined with automatic fast scaling (fixed to scaling up mode 2) and if not set already automatic
  (depending on load) switching of sampling rate sleep multiplier to a fixed minimum possible multiplier of 2.
  this should avoid mostly audio or general device connection problems with 'resource hungrier' apps like some music players,
  skype, navigation apps etc. and/or in combination with using bluetooth equipment during screen is off.
  NOTE: this overwrites a possible fast 'scaling_sleep' setting so use either this or 'fast_scaling_sleep'
- added some missing governor tunebable default value definitions
- removed tuneable apply order exception and removed analog value checks in hotplug threshold and hotplug frequency tuneables to avoid
  tuneable values not changing issues. NOTE: keep in mind that all 'down' values should be lower then the analog 'up' values and vice versa.
- removed 200 mhz up hotplugging restriction, so up hotplugging starts at 200 mhz now
- removed some unnecessary macros in scaling logic
- added maximum fast scaling and frequency boost to late resume to react wakeup lags
- merged some improvements from ktoonservativeq governor version for the SGS4 (credits to ktoonsez)
  changes from here: https://github.com/ktoonsez/KT-SGS4/commits/aosp4.4/drivers/cpufreq/cpufreq_ktoonservativeq.c
  Use dedicated high-priority workqueues
  Use NEW high-priority workqueue for hotplugging
  Improved hotplugging in general by reducing calls to plugging functions if they are currently running,
  by reducing calls to external function in up plugging and by changing the down plug loop to an optimized one
- added hotplug boost switch to early demand functionality and up hotplugging function
- added 'hotplug_idle_freq' tuneable to be able to adjust at which frequency idle should begin
- transfered code for frequency table order detection and limit optimisation into a inline function
  and use this function in START,LIMIT case and early suspend/late resume instead of using redundant code
- execute table order detection and freq limit optimization calculations at 'START' and 'LIMIT' case to avoid possible wrong setting of freq
  max after governor start (currently set max frequency value was sometimes not applied) and a wrong soft limit optimization setting
  after undercutting the soft limit with a lower hard limit value
- minor optimisation in hotplug, hotplug block and in all freq search logic parts
- added debugging sysfs interface (can be included/excluded using #define ZZMOOVE_DEBUG) - credits to Yank555
- added some missing annotation as a prepareation and mainly to avoid some errors when compiling zzmoove in combination with 3.4+ kernel sources
- fixed hotplugging issues when cpufreq limit was set under one or more hotplugging frequency thresholds
  NOTE: now hotplugging frequency thresholds will be completely disabled and a fall back to normal load thresholds will happen
  if the maximal possible frequency will undercut any frequency thresholds
- fixed stopping of up scaling at 100% load when up threshold tuneable is set to the max value of 100
- fixed smooth up not active at 100% load when smooth up tuneable is set to the max value of 100
- fixed many code style and dokumentation issues and made a massive code re-arrangement

for this functions following new tuneables were indroduced:

early_demand_sleep -> same function as early demand on awake but in addition combined with fast scaling and sampling rate
switch and only active at sleep. (possible values 0 disable or 1 enable, default is 1)

grad_up_threshold_sleep -> 2 way functionality: early demand sleep grad up (load gradient) threshold and at the same time load threshold
for switching internally (tuneables are staying at set values) sampling_rate_sleep_multiplier to 2 and
fast_scaling to 2 (possible values from 1 to 100, default is 35)

hotplug_block_up_cycles -> (replaces hotplug_block_cycles) slow down up hotplugging by waiting a given amount of cycles before plugging.
possible values 0 disable, any values above 0 (default is 0)

hotplug_block_down_cycles -> (replaces hotplug_block_cycles) slow down down hotplugging by waiting a given amount of cycles before plugging.
possible values 0 disable, any values above 0 (default is 0)

hotplug_idle_freq -> freq at which the idle should be active (possible values 0 disable and any possible scaling freq, default is 0)

sampling_rate_current -> read only and shows currently active sampling rate

sampling_rate_idle -> sampling rate which should be used at 'idle times'
(possible values are any sampling rate > 'min_sampling_rate', 0 to disable whole function, default is 0)

sampling_rate_idle_delay -> delay in cycles for switching from idle to normal sampling rate and vice versa
(possible values are any value and 0 to disable delay, default is 0)

sampling_rate_idle_threshold -> threshold under which idle sampling rate should be active
(possible values 1 to 100, 0 to disable function, default is 0)

scaling_block_cycles -> amount of gradients which should be counted (if block threshold is set) and at the same time up scaling should be
blocked and after that a forced down scaling should happen (possible values are any value, 0 to disable that
function, default is 0)

scaling_bock_freq -> frequency at and above the blocking should be active
(possible values are any possible scaling freq, 0 to enable blocking permanently at every frequency, default is 0)

scaling_block_threshold -> gradient (min value) of load in both directions (up/down) to count-up cycles
(possible value are 1 to 100, 0 to disable gradient counting)

scaling_block_force_down -> multiplicator for the maximal amount of forced down scaling cycles (force down cycles = block_cycles * force_down)
therefore the forced down scaling duration (possible value are 2 to any value, 0 to disable forced down scaling
and use only scaling up blocks)

profile -> read only and shows name of currently active profile ('none' = no profile, 'custom' = a profile value has changed)

profile_number -> switches profile (possible value depends on amount of profiles in cpufreq_zzmoove_profiles.h file,

please check this file for futher details) 0 no profile set = tuneable mode, default 0)

version_profiles -> read only and shows version of profile header file

if ZZMOOVE_DEBUG is defined:
debug -> read only and shows various usefull debugging infos
zzmoove: Set number of core to 2

Change-Id: I0ab2b0662577fc79360600e307b0126c772814ae
logger: Add an enable toggle for entry storage; TNX AndreiLux and Dorimanx

You can disable logging by echo-ing 0 in /sys/module/logger/parameters/log_enabled
By default the logging is enabled.

Change-Id: I2d4c8d61f58c002454f6fc4b10a107e0ef389efa

Conflicts:
	drivers/staging/android/logger.c
n_tty: Fix n_tty_write crash when echoing in raw mode

The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST.  And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.

If we look into tty_insert_flip_string_fixed_flag, there is:
  int space = __tty_buffer_request_room(port, goal, flags);
  struct tty_buffer *tb = port->buf.tail;
  ...
  memcpy(char_buf_ptr(tb, tb->used), chars, space);
  ...
  tb->used += space;

so the race of the two can result in something like this:
              A                                B
__tty_buffer_request_room
                                  __tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
                                  memcpy(buf(tb->used), ...) ->BOOM

B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.

Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes.  This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.

Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.

js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call

References: CVE-2014-0196
Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.4: output_lock is a member of struct tty_struct]

Change-Id: I11d1685056e18f107c970fbe2cab5176ca3a91c4
Update slim_i777_defconfig
More descriptive kernel name