This updates the bit sliced AES module to the latest version in the
upstream OpenSSL repository (e620e5ae37bc). This is needed to fix a
bug in the XTS decryption path, where data chunked in a certain way
could trigger the ciphertext stealing code, which is not supposed to
be active in the kernel build (The kernel implementation of XTS only
supports round multiples of the AES block size of 16 bytes, whereas
the conformant OpenSSL implementation of XTS supports inputs of
arbitrary size by applying ciphertext stealing). This is fixed in
the upstream version by adding the missing #ifndef XTS_CHAIN_TWEAK
around the offending instructions.

The upstream code also contains the change applied by Russell to
build the code unconditionally, i.e., even if __LINUX_ARM_ARCH__ < 7,
but implemented slightly differently.

Cc: stable@vger.kernel.org
Fixes: e4e7f10 ("ARM: add support for bit sliced AES using NEON instructions")
Reported-by: Adrian Kotelba <adrian.kotelba@gmail.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

If pen comes in proximity while touch is down, we force touch up
before sending pen events. Otherwise, there can be unfinished
touch events compete with pen events. This idea has been fully
implemented for Tablet PCs. But other tablets that support both
pen and touch are not fully considered.

Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

touch_down is a flag to indicate if there are touches on tablet
or not. Since one set of touch events may be posted over more
than one data packet/touch frame, and pen may come in proximity
while touch events are partially sent, counting all touch events
for the set reflects the actual status of touch_down.

Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

Routes without a control must use NULL for the control name. The ak4671
driver uses "NULL" instead in a few places. Previous to commit 5fe5b76
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the ak4671 driver in the process.

This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.

Fixes: 5fe5b76 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Routes without a control must use NULL for the control name. The da732x
driver uses "NULL" instead in a few places. Previous to commit 5fe5b76
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the da732x driver in the process.

This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.

Fixes: 5fe5b76 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Routes without a control must use NULL for the control name. The sn95031
driver uses "NULL" instead in a few places. Previous to commit 5fe5b76
("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
the DAPM core silently ignored non-NULL controls on non-mixer and non-mux
routes. But starting with that commit it will complain and not add the
route breaking the sn95031 driver in the process.

This patch replaces the incorrect "NULL" control name with NULL to fix the
issue.

Fixes: 5fe5b76 ("ASoC: dapm: Do not pretend to support controls for non mixer/mux widgets")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

of_property_read_u32_array returns 0 on success,
so the return value shouldn't be inverted twice,
first on assignment then in condition expression.

Signed-off-by: Maciej Szmigiero <mail@maciej.szmigiero.name>
Signed-off-by: Mark Brown <broonie@kernel.org>

According to i.MX6 Series Reference Manual, the formula to calculate
the sys clock is

sysclk rate = bclk rate * (div2 + 1) * (7 * psr + 1) * (pm + 1) * 2

Commit aafa85e ("ASoC: fsl_ssi: Add DAI master mode support for
SSI on i.MX series") added the divisor calculation which relies on
the clk_round_rate(). However, at that time, clk_round_rate() didn't
provide closest clock rates for some cases because it might not use
a correct rounding policy. So using the original formula (pm + 1) for
PM divisor was not able to give us a desired clock rate. And then we
used (pm + 2) to do the trick.

However, the clk-divider driver has been refined a lot since commit
b11d282 ("clk: divider: fix rate calculation for fractional rates")
Now using (pm + 2) trick would result an incorrect clock rate.

So this patch fixes the problem by removing the useless trick.

Reported-by: Stephane Cerveau <scerveau@voxtok.com>
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

The initialisation of the efm32 clocksource first sets up the irq and only
after that initialises the data needed for irq handling. In case this
initialisation is delayed the irq handler would dereference a NULL pointer.

I'm not aware of anything that could delay the process in such a way, but it's
better to be safe than sorry, so setup the irq only when the clock event device
is ready.

Cc: stable@vger.kernel.org
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Yongbae Park <yongbae2@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>

The interrupt is enabled before the handler is set. Even this bug
did not appear, it is potentially dangerous as it can lead to a
NULL pointer dereference.

Fix the error by enabling the interrupt after
clockevents_config_and_register() is called.

Cc: stable@vger.kernel.org
Signed-off-by: Yongbae Park <yongbae2@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>

…niel.lezcano/linux into timers/urgent

Pull clockevents fixes from Daniel Lezcano:

 " These two patches fix a potential crash at boot time.

   - Fix setup_irq / clockevents_config_and_register init ordering in order to
     prevent to have an interrupt to be fired before the handler is set for sun5i
     and efm32. (Yongbae Park)"

Signed-off-by: Ingo Molnar <mingo@kernel.org>

When annotating source/disasm lines the perf tools parse the output of
objdump, trying to provide augmented output that allows navigating
jumps, calls, etc.

But when a line output by objdump can't be parsed the annotation code
falls back to just presenting the unparsed line.

When fixing a leak in the 0fb9f2a commit ("perf annotate: Fix
memory leaks in LOCK handling") we failed to take that into account and
instead tried to free one of the data structures that should be freed
only when successfully allocated, oops, segfault.

There was a change in the way the objdump output for lock prefixed
instructions is formatted that lead the relevant parser to fail to grok
it.

At least RHEL7 works ok, but Fedora 20 segfaults.

Fix it by making the ins__delete() destructor work like the most basic
destructor: free().

Namely make it accept a NULL pointer and when handling it just do
nothing.

Further investigation is needed to figure out the nature of the objdump
output change so as to make the parser grok it.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rabin Vincent <rabin@rab.in>
Link: http://lkml.kernel.org/n/tip-7wsy0zo292pif0yjoqpfryrz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

…ux/kernel/git/acme/linux into perf/urgent

Pull perf/urgent fix from Arnaldo Carvalho de Melo:

 " - Fix SEGFAULT when freeing unparsed lock prefixed instructions in 'perf
     annotate' (Arnaldo Carvalho de Melo)"

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

On gcc5 the kernel does not link:

  ld: .eh_frame_hdr table[4] FDE at 0000000000000648 overlaps table[5] FDE at 0000000000000670.

Because prior GCC versions always emitted NOPs on ALIGN directives, but
gcc5 started omitting them.

.LSTARTFDEDLSI1 says:

        /* HACK: The dwarf2 unwind routines will subtract 1 from the
           return address to get an address in the middle of the
           presumed call instruction.  Since we didn't get here via
           a call, we need to include the nop before the real start
           to make up for it.  */
        .long .LSTART_sigreturn-1-.     /* PC-relative start address */

But commit 69d0627 ("x86 vDSO: reorder vdso32 code") from 2.6.25
replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before
__kernel_sigreturn.

Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses
vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN".

So fix this by adding to that point at least a single NOP and make the
function ALIGN possibly with more NOPs then.

Kudos for reporting and diagnosing should go to Richard.

Reported-by: Richard Biener <rguenther@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1425543211-12542-1-git-send-email-jslaby@suse.cz
Signed-off-by: Ingo Molnar <mingo@kernel.org>

The SGTL5000_CHIP_ANA_POWER register is cached. Update the cached
value instead of writing it directly.

Patch inspired by Russell King's more colorful remarks in this
patch:
	rabeeh/linux-linaro-stable-mx6-unmaintained-will-be-deleted@dd4bf6a

Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

The board ID will be changed between revisions. So, it is better
to map it by project name.

Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Details:
  1. Unload all modules on fw_list of dsp when suspend, and reload all
modules on fw_list when resume.
  2. A DSP expects only one scratch, but hsw_parse_fw_image() allocates
scratch blocks for each firmware image it parses. Move the allocate function
sst_block_alloc_scratch() out of hsw_parse_fw_image() to make sure a scratch
be allocated only after all firmware images be parsed.

Signed-off-by: Lu, Han <han.lu@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

Any access to the component_list, codec_list and platform_list needs to be
properly locked by the client_mutex. Otherwise undefined behavior can occur
if the list is modified in one thread and concurrently accessed from another
thread.

This patch adds the missing locking to the debugfs file handlers that
display the registered components, as well as the various components
unregister functions.

Furthermore the client_lock is now held for the whole
snd_soc_instantiate_card() sequence to make sure that component removal does
not race against the card registration.

Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>

The one in do_debug() is probably harmless, but better safe than sorry.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/d67deaa9df5458363623001f252d1aee3215d014.1425948056.git.luto@amacapital.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Paul Handrigan <Paul.Handrigan@cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

The correct values referred by a boolean control are
value.integer.value[], not value.enumerated.item[].
The former is long while the latter is int, so it's even incompatible
on 64bit architectures.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>

This device disconnects every 60s without X

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

…d mode

On a platform in ACPI Hardware-reduced mode, the legacy PIC and
PIT may not be initialized even though they may be present in
silicon. Touching these legacy components causes unexpected
results on the system.

On the Bay Trail-T(ASUS-T100) platform, touching these legacy
components blocks platform hardware low idle power state(S0ix)
during system suspend. So we should bypass them in ACPI hardware
reduced mode.

Suggested-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Li Aubrey <aubrey.li@linux.intel.com>
Cc: <alan@linux.intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Link: http://lkml.kernel.org/r/54FFF81C.20703@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

On NumaChip systems, the physical processor ID assignment wasn't
accounting for the number of nodes in AMD multi-module
processors, giving an incorrect sibling map:

  $ cd /sys/devices/system/cpu/cpu29/topology
  $ grep . *
  core_id:5
  core_siblings:00000000,ff000000
  core_siblings_list:24-31
  physical_package_id:3
  thread_siblings:00000000,30000000
  thread_siblings_list:28-29

This fixes it:

  $ cd /sys/devices/system/cpu/cpu29/topology
  $ grep . *
  core_id:5
  core_siblings:00000000,ffff0000
  core_siblings_list:16-31
  physical_package_id:1
  thread_siblings:00000000,30000000
  thread_siblings_list:28-29

Signed-off-by: Daniel J Blueman <daniel@numascale.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Steffen Persvold <sp@numascale.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1426135950-10110-1-git-send-email-daniel@numascale.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Commit:

  a83fe28 ("perf: Fix put_event() ctx lock")

changed the locking logic in put_event() by replacing mutex_lock_nested()
with perf_event_ctx_lock_nested(), but didn't fix the subsequent
mutex_unlock() with a correct counterpart, perf_event_ctx_unlock().

Contexts are thus leaked as a result of incremented refcount
in perf_event_ctx_lock_nested().

Signed-off-by: Leon Yu <chianglungyu@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Fixes: a83fe28 ("perf: Fix put_event() ctx lock")
Link: http://lkml.kernel.org/r/1424954613-5034-1-git-send-email-chianglungyu@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
calculate the size of the plaintext output itself and cannot simply use
cryptlen.

The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
in req->dst. As the destination buffer for decryption only needs to hold
the plaintext memory but cryptlen references the input buffer holding
(ciphertext || authentication tag), the assumption of the destination
buffer length in RFC4106 GCM operation leads to a too large size. This
patch simply uses the already calculated plaintext size.

In addition, this patch fixes the offset calculation of the AAD buffer
pointer: as mentioned before, cryptlen already includes the size of the
tag. Thus, the tag does not need to be added. With the addition, the AAD
will be written beyond the already allocated buffer.

Note, this fixes a kernel crash that can be triggered from user space
via AF_ALG(aead) -- simply use the libkcapi test application
from [1] and update it to use rfc4106-gcm-aes.

Using [1], the changes were tested using CAVS vectors to demonstrate
that the crypto operation still delivers the right results.

[1] http://www.chronox.de/libkcapi.html

CC: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

…xstate_sig()

math_state_restore() assumes it is called with irqs disabled,
but this is not true if the caller is __restore_xstate_sig().

This means that if ia32_fxstate == T and __copy_from_user()
fails, __restore_xstate_sig() returns with irqs disabled too.

This triggers:

  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
   dump_stack
   ___might_sleep
   ? _raw_spin_unlock_irqrestore
   __might_sleep
   down_read
   ? _raw_spin_unlock_irqrestore
   print_vma_addr
   signal_fault
   sys32_rt_sigreturn

Change __restore_xstate_sig() to call set_used_math()
unconditionally. This avoids enabling and disabling interrupts
in math_state_restore(). If copy_from_user() fails, we can
simply do fpu_finit() by hand.

[ Note: this is only the first step. math_state_restore() should
        not check used_math(), it should set this flag. While
	init_fpu() should simply die. ]

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150307153844.GB25954@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

drop_fpu() does clear_used_math() and usually this is correct
because tsk == current.

However switch_fpu_finish()->restore_fpu_checking() is called before
__switch_to() updates the "current_task" variable. If it fails,
we will wrongly clear the PF_USED_MATH flag of the previous task.

So use clear_stopped_child_used_math() instead.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150309171041.GB11388@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

The linux kernel has supported the TiVo Slide remote control for some time, but
does not recognize the USB ID of the newer Slide Pro. This patch adds the
missing data structures so the newer remote will be recognized by the driver,
thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be
mapped with a hwdb file.

Signed-off-by: Forest Wilkinson <web11.forest@tibit.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

This reverts commit:

  f47233c ("x86/mm/ASLR: Propagate base load address calculation")

The main reason for the revert is that the new boot flag does not work
at all currently, and in order to make this work, we need non-trivial
changes to the x86 boot code which we didn't manage to get done in
time for merging.

And even if we did, they would've been too risky so instead of
rushing things and break booting 4.1 on boxes left and right, we
will be very strict and conservative and will take our time with
this to fix and test it properly.

Reported-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: H. Peter Anvin <hpa@linux.intel.com
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Junjie Mao <eternal.n08@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt.fleming@intel.com>
Link: http://lkml.kernel.org/r/20150316100628.GD22995@pd.tnic
Signed-off-by: Ingo Molnar <mingo@kernel.org>

… 'asoc/fix/da732x', 'asoc/fix/fsl-ssi', 'asoc/fix/lock' and 'asoc/fix/rt286' into asoc-linus

…031' into asoc-linus

The commit [ef403ed: ALSA: hda - Don't access stereo amps for
mono channel widgets] fixed the handling of mono widgets in general,
but it still misses an exceptional case: namely, a mono mixer widget
taking a single stereo input.  In this case, it has stereo volumes
although it's a mono widget, and thus we have to take care of both
left and right input channels, as stated in HD-audio spec ("7.1.3
Widget Interconnection Rules").

This patch covers this missing piece by adding proper checks of stereo
amps in both the generic parser and the proc output codes.

Reported-by: Raymond Yau <superquad.vortex2@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

There is a notifier that handles live patches for coming and going modules.
It takes klp_mutex lock to avoid races with coming and going patches but
it does not keep the lock all the time. Therefore the following races are
possible:

  1. The notifier is called sometime in STATE_MODULE_COMING. The module
     is visible by find_module() in this state all the time. It means that
     new patch can be registered and enabled even before the notifier is
     called. It might create wrong order of stacked patches, see below
     for an example.

   2. New patch could still see the module in the GOING state even after
      the notifier has been called. It will try to initialize the related
      object structures but the module could disappear at any time. There
      will stay mess in the structures. It might even cause an invalid
      memory access.

This patch solves the problem by adding a boolean variable into struct module.
The value is true after the coming and before the going handler is called.
New patches need to be applied when the value is true and they need to ignore
the module when the value is false.

Note that we need to know state of all modules on the system. The races are
related to new patches. Therefore we do not know what modules will get
patched.

Also note that we could not simply ignore going modules. The code from the
module could be called even in the GOING state until mod->exit() finishes.
If we start supporting patches with semantic changes between function
calls, we need to apply new patches to any still usable code.
See below for an example.

Finally note that the patch solves only the situation when a new patch is
registered. There are no such problems when the patch is being removed.
It does not matter who disable the patch first, whether the normal
disable_patch() or the module notifier. There is nothing to do
once the patch is disabled.

Alternative solutions:
======================

+ reject new patches when a patched module is coming or going; this is ugly

+ wait with adding new patch until the module leaves the COMING and GOING
  states; this might be dangerous and complicated; we would need to release
  kgr_lock in the middle of the patch registration to avoid a deadlock
  with the coming and going handlers; also we might need a waitqueue for
  each module which seems to be even bigger overhead than the boolean

+ stop modules from entering COMING and GOING states; wait until modules
  leave these states when they are already there; looks complicated; we would
  need to ignore the module that asked to stop the others to avoid a deadlock;
  also it is unclear what to do when two modules asked to stop others and
  both are in COMING state (situation when two new patches are applied)

+ always register/enable new patches and fix up the potential mess (registered
  patches order) in klp_module_init(); this is nasty and prone to regressions
  in the future development

+ add another MODULE_STATE where the kallsyms are visible but the module is not
  used yet; this looks too complex; the module states are checked on "many"
  locations

Example of patch stacking breakage:
===================================

The notifier could _not_ _simply_ ignore already initialized module objects.
For example, let's have three patches (P1, P2, P3) for functions a() and b()
where a() is from vmcore and b() is from a module M. Something like:

	a()	b()
P1	a1()	b1()
P2	a2()	b2()
P3	a3()	b3(3)

If you load the module M after all patches are registered and enabled.
The ftrace ops for function a() and b() has listed the functions in this
order:

	ops_a->func_stack -> list(a3,a2,a1)
	ops_b->func_stack -> list(b3,b2,b1)

, so the pointer to b3() is the first and will be used.

Then you might have the following scenario. Let's start with state when patches
P1 and P2 are registered and enabled but the module M is not loaded. Then ftrace
ops for b() does not exist. Then we get into the following race:

CPU0					CPU1

load_module(M)

  complete_formation()

  mod->state = MODULE_STATE_COMING;
  mutex_unlock(&module_mutex);

					klp_register_patch(P3);
					klp_enable_patch(P3);

					# STATE 1

  klp_module_notify(M)
    klp_module_notify_coming(P1);
    klp_module_notify_coming(P2);
    klp_module_notify_coming(P3);

					# STATE 2

The ftrace ops for a() and b() then looks:

  STATE1:

	ops_a->func_stack -> list(a3,a2,a1);
	ops_b->func_stack -> list(b3);

  STATE2:
	ops_a->func_stack -> list(a3,a2,a1);
	ops_b->func_stack -> list(b2,b1,b3);

therefore, b2() is used for the module but a3() is used for vmcore
because they were the last added.

Example of the race with going modules:
=======================================

CPU0					CPU1

delete_module()  #SYSCALL

   try_stop_module()
     mod->state = MODULE_STATE_GOING;

   mutex_unlock(&module_mutex);

					klp_register_patch()
					klp_enable_patch()

					#save place to switch universe

					b()     # from module that is going
					  a()   # from core (patched)

   mod->exit();

Note that the function b() can be called until we call mod->exit().

If we do not apply patch against b() because it is in MODULE_STATE_GOING,
it will call patched a() with modified semantic and things might get wrong.

[jpoimboe@redhat.com: use one boolean instead of two]
Signed-off-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

…ernel/git/broonie/sound into for-linus

ASoC: Fixes for v4.0

As well as the usual collection of driver specific fixes there's a few
more generic things:

 - Lots of fixes from Takashi for drivers using the wrong field in the
   control union to communicate with userspace, leading to potential
   errors on 64 bit systems.
 - A fix from Lars for locking of the lists of devices we maintain,
   mostly only likely to trigger during device probe and removal.

486b908 (HID: wacom: do not send pen events before touch is up/forced out)
introduces a kernel oops when plugging a tablet without touch.

wacom->shared is null for these devices so this leads to a null pointer
exception.

Change the condition to make it clear that what we need is wacom->shared
not NULL.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

…of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull perf and timer fixes from Ingo Molnar:
 "Two small perf fixes:
   - kernel side context leak fix
   - tooling crash fix

  And two clocksource driver fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf: Fix context leak in put_event()
  perf annotate: Fix fallback to unparsed disassembler line

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clockevents: sun5i: Fix setup_irq init sequence
  clocksource: efm32: Fix a NULL pointer dereference

…inux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Misc fixes from all around the place:

   - a KASLR related revert where we ran out of time to get a fix - this
     represents a substantial portion of the diffstat,

   - two FPU fixes,

   - two x86 platform fixes: an ACPI reduced-hw fix and a NumaChip fix,

   - an entry code fix,

   - and a VDSO build fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  Revert "x86/mm/ASLR: Propagate base load address calculation"
  x86/fpu: Drop_fpu() should not assume that tsk equals current
  x86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig()
  x86/apic/numachip: Fix sibling map with NumaChip
  x86/platform, acpi: Bypass legacy PIC and PIT in ACPI hardware reduced mode
  x86/asm/entry/32: Fix user_mode() misuses
  x86/vdso: Fix the build on GCC5

…/git/jikos/hid

Pull HID fixes from Jiri Kosina:

 - fixes for pen pen proximity / touch events in wacom driver, from Ping
   Cheng and Benjamin Tissoires

 - two new device-specific quirks from Oliver Neukum and Forest
   Wilkinson

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: wacom: check for wacom->shared before following the pointer
  HID: tivo: enable all buttons on the TiVo Slide Pro remote
  HID: add ALWAYS_POLL quirk for a Logitech 0xc007
  HID: wacom: rely on actual touch down count to decide touch_down
  HID: wacom: do not send pen events before touch is up/forced out

…/git/jikos/livepatching

Pull livepatching fix from Jiri Kosina:

 - fix for potential race with module loading, from Petr Mladek.

   The race is very unlikely to be seen in real world and has been found
   by code inspection, but should be fixed for 4.0 anyway.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching:
  livepatch: Fix subtle race with coming and going modules

Pull crypto fixes from Herbert Xu:
 "Fix a bug in the ARM XTS implementation that can cause failures in
  decrypting encrypted disks, and fix is a memory overwrite bug that can
  cause a crash which can be triggered from userspace"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: aesni - fix memory usage in GCM decryption
  crypto: arm/aes update NEON AES module to latest OpenSSL version

…l/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "This is a collection of many small fixes.  Most of fixes are for ASoC
  drivers, including the fixes of wrong field usages for boolean kctls.

  In addition, there is a fix in ASoC core for adding proper locks for
  component lists, and a fix for a HD-audio regression by the previous
  mono channel fix"

* tag 'sound-4.0-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (24 commits)
  ALSA: hda - Treat stereo-to-mono mix properly
  ASoC: wm9713: Fix wrong value references for boolean kctl
  ASoC: wm9712: Fix wrong value references for boolean kctl
  ASoC: wm8960: Fix wrong value references for boolean kctl
  ASoC: wm8955: Fix wrong value references for boolean kctl
  ASoC: wm8904: Fix wrong value references for boolean kctl
  ASoC: wm8903: Fix wrong value references for boolean kctl
  ASoC: wm8731: Fix wrong value references for boolean kctl
  ASoC: wm2000: Fix wrong value references for boolean kctl
  ASoC: tas5086: Fix wrong value references for boolean kctl
  ASoC: pcm1681: Fix wrong value references for boolean kctl
  ASoC: es8238: Fix wrong value references for boolean kctl
  ASoC: cs4271: Fix wrong value references for boolean kctl
  ASoC: ak4641: Fix wrong value references for boolean kctl
  ASoC: adav80x: Fix wrong value references for boolean kctl
  ASoC: Fix component lists locking
  ASoC: Intel: remove conflicts when load/unload multiple firmware images
  ASoC: rt286: Change the DMI mapping for Dino
  ASoC: sgtl5000: remove useless register write clearing CHRGPUMP_POWERUP
  ASoC: fsl_ssi: Don't try to round-up for PM divisor calculation
  ...