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
mali: GPU clock and voltage control including auto-applied full freq. range voltage table (Yank555.lu)

- Fixed a derp in mali_platform_dvfs.c that impeeded voltage being initialized for highest frequency (Yank555.lu)

    mali_dvfs_table_update gets called before the initialization of the ASV level, which
    at that stage is reported as ASV 0 when it is 6 once boot is completed on my device

- Included proper voltage table for all 20 freq. levels with automatic update when changing any GPU freq. (Yank555.lu)

SysFS interface :

 * clock control (old legacy interface) :
 *
 *    - set frequencies (5 steps) :
 *
 *          echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_control
 *
 *      available frequency steps :
 *
 *           54,  108,  160,  200*, 266,  275, 300,
 *          333,  350,  400*, 440,  500*, 533, 600*,
 *          640*, 666*, 700*, 733*, 750*, 800
 *          (* newly introduced steps)
 *
 *      NB: Any change will trigger a reset of all voltages !
 *
 *    - set frequency-step thresholds (up & down) :
 *
 *          echo "step0_up% step1_down% step1_up% step2_down% step2_up% step3_down% step3_up% step4_down%" > /sys/class/misc/gpu_clock_control/gpu_control
 *
 *      available thresholds :
 *
 *          0% - 100%
 *
 *    - set staycount for each step (default = 0) :
 *
 *          echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_staycount
 *
 *      available staycount values :
 *
 *          0 - 255
 *
 * clock control (new interface) :
 *
 *    - set frequencies (5 steps) :
 *
 *          echo "freq" > /sys/class/misc/gpu_clock_control/gpu_freq_0...4
 *
 *      available frequency steps :
 *
 *           54,  108,  160,  200*, 266,  275, 300,
 *          333,  350,  400*, 440,  500*, 533, 600*,
 *          640*, 666*, 700*, 733*, 750*, 800
 *          (* newly introduced steps)
 *
 *      NB: Only actually existing steps will be accepted (old legacy accepts anything between min and max !!)
 *          Any change will trigger a reset of all voltages !
 *
 *    - set frequency-step thresholds (up & down) :
 *
 *          echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_upthreshold_0...3
 *
 *          echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_downthreshold_1...4
 *
 *      available thresholds :
 *
 *          0 - 100
 *
 *    - set staycount for each step (default = 0) :
 *
 *          echo "staycount" > /sys/class/misc/gpu_clock_control/gpu_staycount_0...4
 *
 *      available staycount values :
 *
 *          0 - 255
 *
 *    - list all available frequencies (read-only) :
 *
 *          cat /sys/class/misc/gpu_clock_control/available_frequencies
 *
 * voltage control (old legacy interface) :
 *
 *    - set frequency-step voltage (5 steps) :
 *
 *          echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_voltage_control/gpu_control
 *
 *      available voltages :
 *
 *          600000 - 1400000
 *
 * voltage control (new interface) :
 *
 *    - set frequency-step voltage (5 steps) :
 *
 *          echo "voltage" > /sys/class/misc/gpu_voltage_control/gpu_voltage_0...4
 *
 *      available voltages :
 *
 *          600000 - 1400000
 *
 *    - display ASV level (read-only) :
 *
 *          cat /sys/class/misc/gpu_voltage_control/asv_level
 *
 *    - recalculate mali_dvfs_table (write-only) :
 *
 *          echo 1 > /sys/class/misc/gpu_voltage_control/mali_dvfs_table_update
mali: GPU clock and voltage control including auto-applied full freq. range voltage table (Yank555.lu)

- (new) voltage interface switchabled readonly/readwrite using a #define (mali_dvfs_table_update will be removed in readonly mode)

- Fixed a derp in mali_platform_dvfs.c that impeeded voltage being initialized for highest frequency (Yank555.lu)

mali_dvfs_table_update gets called before the initialization of the ASV level, which
at that stage is reported as ASV 0 when it is 6 once boot is completed on my device

- Included proper voltage table for all 20 freq. levels with automatic update when changing any GPU freq. (Yank555.lu)

SysFS interface :

* clock control (old legacy interface) :
*
* - set frequencies (5 steps) :
*
* echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_control
*
* available frequency steps :
*
* 54, 108, 160, 200*, 266, 275, 300,
* 333, 350, 400*, 440, 500*, 533, 600*,
* 640*, 666*, 700*, 733*, 750*, 800
* (* newly introduced steps)
*
* NB: Any change will trigger a reset of all voltages !
*
* - set frequency-step thresholds (up & down) :
*
* echo "step0_up% step1_down% step1_up% step2_down% step2_up% step3_down% step3_up% step4_down%" > /sys/class/misc/gpu_clock_control/gpu_control
*
* available thresholds :
*
* 0% - 100%
*
* - set staycount for each step (default = 0) :
*
* echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_staycount
*
* available staycount values :
*
* 0 - 255
*
* clock control (new interface) :
*
* - set frequencies (5 steps) :
*
* echo "freq" > /sys/class/misc/gpu_clock_control/gpu_freq_0...4
*
* available frequency steps :
*
* 54, 108, 160, 200*, 266, 275, 300,
* 333, 350, 400*, 440, 500*, 533, 600*,
* 640*, 666*, 700*, 733*, 750*, 800
* (* newly introduced steps)
*
* NB: Only actually existing steps will be accepted (old legacy accepts anything between min and max !!)
* Any change will trigger a reset of all voltages !
*
* - set frequency-step thresholds (up & down) :
*
* echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_upthreshold_0...3
*
* echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_downthreshold_1...4
*
* available thresholds :
*
* 0 - 100
*
* - set staycount for each step (default = 0) :
*
* echo "staycount" > /sys/class/misc/gpu_clock_control/gpu_staycount_0...4
*
* available staycount values :
*
* 0 - 255
*
* - list all available frequencies (read-only) :
*
* cat /sys/class/misc/gpu_clock_control/available_frequencies
*
* voltage control (old legacy interface) :
*
* - set frequency-step voltage (5 steps) :
*
* echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_voltage_control/gpu_control
*
* available voltages :
*
* 600000 - 1400000
*
* voltage control (new interface) :
*
* - set frequency-step voltage (5 steps) :
*
* echo "voltage" > /sys/class/misc/gpu_voltage_control/gpu_voltage_0...4
*
* available voltages :
*
* 600000 - 1400000
*
* - display ASV level (read-only) :
*
* cat /sys/class/misc/gpu_voltage_control/asv_level
*
* - recalculate mali_dvfs_table (write-only) :
*
* echo 1 > /sys/class/misc/gpu_voltage_control/mali_dvfs_table_update
mali: GPU clock and voltage control including auto-applied full freq. range voltage table (Yank555.lu)

- (new) voltage interface switchabled readonly/readwrite in menuconfig

- Fixed a derp in mali_platform_dvfs.c that impeeded voltage being initialized for highest frequency (Yank555.lu)

mali_dvfs_table_update gets called before the initialization of the ASV level, which
at that stage is reported as ASV 0 when it is 6 once boot is completed on my device

- Included proper voltage table for all 20 freq. levels with automatic update when changing any GPU freq. (Yank555.lu)

SysFS interface :

* clock control (old legacy interface) :
*
* - set frequencies (5 steps) :
*
* echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_control
*
* available frequency steps :
*
* 54, 108, 160, 200*, 266, 275, 300,
* 333, 350, 400*, 440, 500*, 533, 600*,
* 640*, 666*, 700*, 733*, 750*, 800
* (* newly introduced steps)
*
* NB: Any change will trigger a reset of all voltages !
*
* - set frequency-step thresholds (up & down) :
*
* echo "step0_up% step1_down% step1_up% step2_down% step2_up% step3_down% step3_up% step4_down%" > /sys/class/misc/gpu_clock_control/gpu_control
*
* available thresholds :
*
* 0% - 100%
*
* - set staycount for each step (default = 0) :
*
* echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_staycount
*
* available staycount values :
*
* 0 - 255
*
* clock control (new interface) :
*
* - set frequencies (5 steps) :
*
* echo "freq" > /sys/class/misc/gpu_clock_control/gpu_freq_0...4
*
* available frequency steps :
*
* 54, 108, 160, 200*, 266, 275, 300,
* 333, 350, 400*, 440, 500*, 533, 600*,
* 640*, 666*, 700*, 733*, 750*, 800
* (* newly introduced steps)
*
* NB: Only actually existing steps will be accepted (old legacy accepts anything between min and max !!)
* Any change will trigger a reset of all voltages !
*
* - set frequency-step thresholds (up & down) :
*
* echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_upthreshold_0...3
*
* echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_downthreshold_1...4
*
* available thresholds :
*
* 0 - 100
*
* - set staycount for each step (default = 0) :
*
* echo "staycount" > /sys/class/misc/gpu_clock_control/gpu_staycount_0...4
*
* available staycount values :
*
* 0 - 255
*
* - list all available frequencies (read-only) :
*
* cat /sys/class/misc/gpu_clock_control/available_frequencies
*
* voltage control (old legacy interface) :
*
* - set frequency-step voltage (5 steps) :
*
* echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_voltage_control/gpu_control
*
* available voltages :
*
* 600000 - 1400000
*
* voltage control (new interface) :
*
* - set frequency-step voltage (5 steps) :
*
* echo "voltage" > /sys/class/misc/gpu_voltage_control/gpu_voltage_0...4
*
* available voltages :
*
* 600000 - 1400000
*
* - display ASV level (read-only) :
*
* cat /sys/class/misc/gpu_voltage_control/asv_level
*
* - recalculate mali_dvfs_table (write-only) :
*
* echo 1 > /sys/class/misc/gpu_voltage_control/mali_dvfs_table_update
mali: GPU clock and voltage control including auto-applied full freq. range voltage table (Yank555.lu)

- (new) added global voltage delta to be applied on all steps whenever voltages are reset

- voltage interface switchabled readonly/readwrite in menuconfig

- Fixed a derp in mali_platform_dvfs.c that impeeded voltage being initialized for highest frequency (Yank555.lu)

    mali_dvfs_table_update gets called before the initialization of the ASV level, which
    at that stage is reported as ASV 0 when it is 6 once boot is completed on my device

- Included proper voltage table for all 20 freq. levels with automatic update when changing any GPU freq. (Yank555.lu)

SysFS interface :

* clock control (old legacy interface) :
*
*    - set frequencies (5 steps) :
*
*          echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_control
*
*       available frequency steps :
*
*           54 , 108 , 160 , 200*, 266 , 275, 300 ,
*          333 , 350 , 400*, 440 , 500*, 533, 600*,
*          640*, 666*, 700*, 733*, 750*, 800
*          (* newly introduced steps)
*
*       NB: Any change will trigger a reset of all voltages !
*
*    - set frequency-step thresholds (up & down) :
*
*          echo "step0_up% step1_down% step1_up% step2_down% step2_up% step3_down% step3_up% step4_down%" > /sys/class/misc/gpu_clock_control/gpu_control
*
*       available thresholds :
*
*          0% - 100%
*
*    - set staycount for each step (default = 0) :
*
*          echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_clock_control/gpu_staycount
*
*       available staycount values :
*
*          0 - 255
*
* clock control (new interface) :
*
*    - set frequencies (5 steps) :
*
*          echo "freq" > /sys/class/misc/gpu_clock_control/gpu_freq_0...4
*
*       available frequency steps :
*
*           54 , 108 , 160 , 200*, 266 , 275, 300 ,
*          333 , 350 , 400*, 440 , 500*, 533, 600*,
*          640*, 666*, 700*, 733*, 750*, 800
*          (* newly introduced steps)
*
*       NB: Only actually existing steps will be accepted (old legacy accepts anything between min and max !!)
*           Any change will trigger a reset of all voltages !
*
*    - set frequency-step thresholds (up & down) :
*
*          echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_upthreshold_0...3
*
*          echo "threshold" > /sys/class/misc/gpu_clock_control/gpu_downthreshold_1...4
*
*       available thresholds :
*
*          0 - 100
*
*    - set staycount for each step (default = 0) :
*
*          echo "staycount" > /sys/class/misc/gpu_clock_control/gpu_staycount_0...4
*
*       available staycount values :
*
*          0 - 255
*
*    - list all available frequencies (read-only) :
*
*          cat /sys/class/misc/gpu_clock_control/available_frequencies
*
* voltage control (old legacy interface) :
*
*    - set frequency-step voltage (5 steps) :
*
*          echo "step0 step1 step2 step3 step4" > /sys/class/misc/gpu_voltage_control/gpu_control
*
*       available voltages :
*
*          600000 - 1400000
*
* voltage control (new interface) :
*
*    - set frequency-step voltage (5 steps) :
*
*          echo "voltage" > /sys/class/misc/gpu_voltage_control/gpu_voltage_0...4
*
*       available voltages :
*
*          600000 - 1400000
*
*    - global over-/undervolt all steps (5 steps) :
*
*          echo "voltage" > /sys/class/misc/gpu_voltage_control/gpu_voltage_detla
*
*       available delta voltages :
*
*          -250000 - +250000 (applied voltages will never drop below 600000 nor cross 1400000)
*
*    - display ASV level (read-only) :
*
*          cat /sys/class/misc/gpu_voltage_control/asv_level
*
*    - recalculate mali_dvfs_table (write-only) :
*
*          echo 1 > /sys/class/misc/gpu_voltage_control/mali_dvfs_table_update
vfp: Use hard-float and neon libraries instead of vfp ones
Compiler CFLAGS
serial/mxs-auart: fix race condition in interrupt handler

commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream.

The handler needs to ack the pending events before actually handling them.
Otherwise a new event might come in after it it considered non-pending or
handled and is acked then without being handled. So this event is only
noticed when the next interrupt happens.

Without this patch an i.MX28 based machine running an rt-patched kernel
regularly hangs during boot.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial/mxs-auart: increase time to wait for transmitter to become idle

commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream.

Without this patch the driver waits ~1 ms for the UART to become idle. At
115200n8 this time is (theoretically) enough to transfer 11.5 characters
(= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size
of 16 characters the clock is gated too early. The problem is worse for
lower baud rates.

This only happens to really shut down the transmitter in the middle of a
transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but
was at least once (because the bootloader doesn't disable the transmitter).

So increase the timeout to 20 ms which should be enough for 9600n8, too.
Moreover skip gating the clock if the timeout is elapsed.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ath9k_htc: do some initial hardware configuration

commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream.

Currently we configure harwdare and clock, only after
interface start. In this case, if we reload module or
reboot PC without configuring adapter, firmware will freeze.
There is no software way to reset adpter.

This patch add initial configuration and set it in
disabled state, to avoid this freeze. Behaviour of this patch
should be similar to: ifconfig wlan0 up; ifconfig wlan0 down.

Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1
Tested-by: Bo Shi <cnshibo@gmail.com>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nl80211: fix mgmt tx status and testmode reporting for netns

commit a0ec570f4f69c4cb700d743a915096c2c8f56a99 upstream.

These two events were sent to the default network
namespace.

This caused AP mode in a non-default netns to not
work correctly. Mgmt tx status was multicasted to
a different (default) netns instead of the one the
AP was in.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mac80211: fix duplicate retransmission detection

commit 6b0f32745dcfba01d7be33acd1b40306c7a914c6 upstream.

The duplicate retransmission detection code in mac80211
erroneously attempts to do the check for every frame,
even frames that don't have a sequence control field or
that don't use it (QoS-Null frames.)

This is problematic because it causes the code to access
data beyond the end of the SKB and depending on the data
there will drop packets erroneously.

Correct the code to not do duplicate detection for such
frames.

I found this error while testing AP powersave, it lead
to retransmitted PS-Poll frames being dropped entirely
as the data beyond the end of the SKB was always zero.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rt2x00: fix stop queue

commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream.

Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
stop queue in mac80211.

To fix that introduce rt2x00queue_pause_queue_nocheck() function,
which will stop queue in mac80211 directly.

Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.

Note also that reordering operations i.e. first call to
rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
directly is the only available solution to fix the problem without
major rework.

Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mwifiex: Add missing endian conversion.

commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream.

Both type and pkt_len variables are in host endian and these should be in
Little Endian in the payload.

Signed-off-by: Tomasz Moń <desowin@gmail.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ACPI / battery: Fix parsing _BIX return value

commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream.

The _BIX method returns extended battery info as a package.
According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member
of that package should be "Revision".  However, the current ACPI
battery driver treats the first member as "Power Unit" which should
be the second member.  This causes the result of _BIX return data
parsing to be incorrect.

Fix this by adding a new member called 'revision' to struct
acpi_battery and adding the offsetof() information on it to
extended_info_offsets[] as the first row.

[rjw: Changelog]
Reported-and-tested-by: Jan Hoffmann <jan.christian.hoffmann@gmail.com>
References: http://bugzilla.kernel.org/show_bug.cgi?id=60519
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sched: Fix the broken sched_rr_get_interval()

commit a59f4e079d19464eebb9b06513a1d4f55fdae5ba upstream.

The caller of sched_sliced() should pass se.cfs_rq and se as the
arguments, however in sched_rr_get_interval() we gave it
rq.cfs_rq and se, which made the following computation obviously
wrong.

The change was introduced by commit:

  77034937dc45 sched: fix crash in sys_sched_rr_get_interval()

... 5 years ago, while it had been the correct 'cfs_rq_of' before
the commit. The change seems to be irrelevant to the commit
msg, which was to return a 0 timeslice for tasks that are on an
idle runqueue. So I believe that was just a plain typo.

Signed-off-by: Zhu Yanhai <gaoyang.zyh@taobao.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul Turner <pjt@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1357621012-15039-1-git-send-email-gaoyang.zyh@taobao.com
[ Since this is an ABI and an old bug, we'll test this via a
  slow upstream route, to hopefully discover any app breakage. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fanotify: info leak in copy_event_to_user()

commit de1e0c40aceb9d5bff09c3a3b97b2f1b178af53f upstream.

The ->reserved field isn't cleared so we leak one byte of stack
information to userspace.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Eric Paris <eparis@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MAINTAINERS: fix up stable_kernel_rules.txt location

There was a mismerge of 7b175c46720f8e6b92801bb634c93d1016f80c62 for the
3.0 kernel, so this fixes it up.

Also mark the stable stuff "Supported", as it is.

Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Fix event group context move

commit 0231bb5336758426b44ccd798ccd3c5419c95d58 upstream.

When we have group with mixed events (hw/sw) we want to end up
with group leader being in hw context. So if group leader is
initialy sw event, we move all the events under hw context.

The move is done for each event by removing it from its context
and adding it back into proper one. As a part of the removal the
event is automatically disabled, which is not what we want at
this stage of creating groups.

The fix is to initialize event state after removal from sw
context.

This fix resulted from the following discussion:

  http://thread.gmane.org/gmane.linux.kernel.perf.user/1144

Reported-by: Andreas Hollmann <hollmann@in.tum.de>
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: Vince Weaver <vince@deater.net>
Link: http://lkml.kernel.org/r/1359714225-4231-1-git-send-email-jolsa@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, fpu: correct the asm constraints for fxsave, unbreak mxcsr.daz

commit eaa5a990191d204ba0f9d35dbe5505ec2cdd1460 upstream.

GCC will optimize mxcsr_feature_mask_init in arch/x86/kernel/i387.c:

		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
		asm volatile("fxsave %0" : : "m" (fx_scratch));
		mask = fx_scratch.mxcsr_mask;
		if (mask == 0)
			mask = 0x0000ffbf;

to

		memset(&fx_scratch, 0, sizeof(struct i387_fxsave_struct));
		asm volatile("fxsave %0" : : "m" (fx_scratch));
		mask = 0x0000ffbf;

since asm statement doesn’t say it will update fx_scratch.  As the
result, the DAZ bit will be cleared.  This patch fixes it. This bug
dates back to at least kernel 2.6.12.

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>