Revert "Boeffla-Sound: Engine 1.6.0"

This reverts commit 9b3f8138cc59b6c9b51750b54611c137709f26b2.
wm8994: voodoo sound support from project_voodoo
wm8994: fixes in old voodoo sound port

- disable digital gain temporarily
- fix headphone detection
- fix ifndef/ifdef problem to properly disable drc part. we will need to compute knee etc in drc part later.
wm8994-voodoo: change some defaults and disable some features for galaxy_s3
wm8994_voodoo: some fixes in the port

- fix headphone detection properly
- reenabled some options
- fix fm radio with dac direct
- enable drc adjustments only when on headphones and disable them otherwise
- change headphone amplification limit from 62 to 63
wm8994_voodoo: change voodoo_sound device name
wm8994_voodoo: some temporary fixes/workarounds until I clean up and make the whole implementation a module to make it run on stock kernels as well...
wm8994-voodoo: some fixes in the port

- clamp notification sound level when received during listening to music on headphones
- active mic detection
- more proper headphone detection
- some cleanups
- playback/capture mode detection
wm8994_voodoo: some more changes

-delay after writing to wm8994 register
-fix (some) fm problems with dac direct
-disable hardware equalizer if the headphone is detached.
-speaker tuning and tuning level
-fix eq problem with stock player (mic detection) and add proper call detection
-fix speaker tuning and notification clamp
-lots of code cleanups and removed custom code from some functions
-speaker offset
wm8994_voodoo: some tiny changes

- do not check for mic.
- call update_hp on hook
- a little silence in debugging
wm8994_voodoo: make some proper module preparations
wm8994_voodoo: make it a module (add missing code)

this is only one way of hijacking a function. There are several other ways but this one is the easiest and the GPL way...
wm8994_voodoo: replace some function references which have signature mismatch with pointers and change headphone detection method
wm8994_voodoo: enable debug for module version
wm8994_voodoo: remove delay on wm8994_write and reapply settings on WM8994_POWER_MANAGEMENT_1 change
wm8994_voodoo: an experimental addition to fix losing of audio boost of some users after receiving call
configs: updated lupus config
futex: Take hugepages into account when generating futex_key

commit 13d60f4b6ab5b702dc8d2ee20999f98a93728aec upstream.

The futex_keys of process shared futexes are generated from the page
offset, the mapping host and the mapping index of the futex user space
address. This should result in an unique identifier for each futex.

Though this is not true when futexes are located in different subpages
of an hugepage. The reason is, that the mapping index for all those
futexes evaluates to the index of the base page of the hugetlbfs
mapping. So a futex at offset 0 of the hugepage mapping and another
one at offset PAGE_SIZE of the same hugepage mapping have identical
futex_keys. This happens because the futex code blindly uses
page->index.

Steps to reproduce the bug:

1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0
   and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs
   mapping.

   The mutexes must be initialized as PTHREAD_PROCESS_SHARED because
   PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as
   their keys solely depend on the user space address.

2. Lock mutex1 and mutex2

3. Create thread1 and in the thread function lock mutex1, which
   results in thread1 blocking on the locked mutex1.

4. Create thread2 and in the thread function lock mutex2, which
   results in thread2 blocking on the locked mutex2.

5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2
   still blocks on mutex2 because the futex_key points to mutex1.

To solve this issue we need to take the normal page index of the page
which contains the futex into account, if the futex is in an hugetlbfs
mapping. In other words, we calculate the normal page mapping index of
the subpage in the hugetlbfs mapping.

Mappings which are not based on hugetlbfs are not affected and still
use page->index.

Thanks to Mel Gorman who provided a patch for adding proper evaluation
functions to the hugetlbfs code to avoid exposing hugetlbfs specific
details to the futex code.

[ tglx: Massaged changelog ]

Signed-off-by: Zhang Yi <zhang.yi20@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Tested-by: Ma Chenggong <ma.chenggong@zte.com.cn>
Reviewed-by: 'Mel Gorman' <mgorman@suse.de>
Acked-by: 'Darren Hart' <dvhart@linux.intel.com>
Cc: 'Peter Zijlstra' <peterz@infradead.org>
Link: http://lkml.kernel.org/r/000101ce71a6%24a83c5880%24f8b50980%24@com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Galbraith <mgalbraith@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
af_key: initialize satype in key_notify_policy_flush()

commit 85dfb745ee40232876663ae206cba35f24ab2a40 upstream.

This field was left uninitialized. Some user daemons perform check against this
field.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
genetlink: fix family dump race

commit 58ad436fcf49810aa006016107f494c9ac9013db upstream.

When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.

A similar bug was reported to me on an old kernel (3.4.47) but
the exact scenario that happened there is no longer possible,
on those kernels the first round wasn't locked either. Looking
at the current code I found the race described above, which had
also existed on the old kernel.

Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>