Originally 'efi_enabled' indicated whether a kernel was booted from
EFI firmware. Over time its semantics have changed, and it now
indicates whether or not we are booted on an EFI machine with
bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.

The immediate motivation for this patch is the bug report at,

    https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557

which details how running a platform driver on an EFI machine that is
designed to run under BIOS can cause the machine to become
bricked. Also, the following report,

    https://bugzilla.kernel.org/show_bug.cgi?id=47121

details how running said driver can also cause Machine Check
Exceptions. Drivers need a new means of detecting whether they're
running on an EFI machine, as sadly the expression,

    if (!efi_enabled)

hasn't been a sufficient condition for quite some time.

Users actually want to query 'efi_enabled' for different reasons -
what they really want access to is the list of available EFI
facilities.

For instance, the x86 reboot code needs to know whether it can invoke
the ResetSystem() function provided by the EFI runtime services, while
the ACPI OSL code wants to know whether the EFI config tables were
mapped successfully. There are also checks in some of the platform
driver code to simply see if they're running on an EFI machine (which
would make it a bad idea to do BIOS-y things).

This patch is a prereq for the samsung-laptop fix patch.

Cc: David Airlie <airlied@linux.ie>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Peter Jones <pjones@redhat.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Steve Langasek <steve.langasek@canonical.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>

I get the following warning every day with v3.7, once or
twice a day:

  [ 2235.186027] WARNING: at /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109 default_send_IPI_mask_logical+0x2f/0xb8()

As explained by Linus as well:

 |
 | Once we've done the "list_add_rcu()" to add it to the
 | queue, we can have (another) IPI to the target CPU that can
 | now see it and clear the mask.
 |
 | So by the time we get to actually send the IPI, the mask might
 | have been cleared by another IPI.
 |

This patch also fixes a system hang problem, if the data->cpumask
gets cleared after passing this point:

        if (WARN_ONCE(!mask, "empty IPI mask"))
                return;

then the problem in commit 83d349f3 ("x86: don't send an IPI to
the empty set of CPU's") will happen again.
Signed-off-by: Wang YanQing <udknight@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: peterz@infradead.org
Cc: mina86@mina86.org
Cc: srivatsa.bhat@linux.vnet.ibm.com
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20130126075357.GA3205@udknight
[ Tidied up the changelog and the comment in the code. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>

At the moment the MSR driver only relies upon file system
checks. This means that anything as root with any capability set
can write to MSRs. Historically that wasn't very interesting but
on modern processors the MSRs are such that writing to them
provides several ways to execute arbitary code in kernel space.
Sample code and documentation on doing this is circulating and
MSR attacks are used on Windows 64bit rootkits already.

In the Linux case you still need to be able to open the device
file so the impact is fairly limited and reduces the security of
some capability and security model based systems down towards
that of a generic "root owns the box" setup.

Therefore they should require CAP_SYS_RAWIO to prevent an
elevation of capabilities. The impact of this is fairly minimal
on most setups because they don't have heavy use of
capabilities. Those using SELinux, SMACK or AppArmor rules might
want to consider if their rulesets on the MSR driver could be
tighter.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Horses <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

I ran out of free entries when I had CONFIG_DMA_API_DEBUG
enabled. Some other archs seem to default to 65536, so increase
this limit for x86 too.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/50A612AA.7040206@canonical.comSigned-off-by: Ingo Molnar <mingo@kernel.org>
----

Fix build errors when CONFIG_INPUT=m.  This is not pretty, but
all of the OLPC kconfig options are bool instead of tristate.

  arch/x86/built-in.o: In function `send_lid_state':
    olpc-xo1-sci.c:(.text+0x1d323): undefined reference to `input_event'
    olpc-xo1-sci.c:(.text+0x1d338): undefined reference to `input_event'
  ...

In the long run, fixing this driver kconfig to be tristate
instead of bool would be a very good change.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: Andres Salomon <dilinger@queued.net>
Cc: Chris Ball <cjb@laptop.org>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Daniel Drake <dsd@laptop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

The flush tlb optimization code has logical issue on UV
platform.  It doesn't flush the full range at all, since it
simply ignores its 'end' parameter (and hence also the "all"
indicator) in uv_flush_tlb_others() function.

Cliff's notes:

 | I tested the patch on a UV.  It has the effect of either
 | clearing 1 or all TLBs in a cpu.  I added some debugging to
 | test for the cases when clearing all TLBs is overkill, and in
 | practice it happens very seldom.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Tested-by: Cliff Wickman <cpw@sgi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>

While in one case a plain annotation is necessary, in the other
case the stack adjustment can simply be folded into the
immediately preceding RESTORE_ALL, thus getting the correct
annotation for free.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alexander van Heukelum <heukelum@mailshack.com>
Link: http://lkml.kernel.org/r/51010C9302000078000B9045@nat28.tlf.novell.comSigned-off-by: Ingo Molnar <mingo@kernel.org>

Patch

  5a5a51db x86-32: Start out eflags and cr4 clean

... made x86-32 match x86-64 in that we initialize %eflags and %cr4
from scratch.  This broke OLPC XO-1.5, because the XO enters the
kernel with paging enabled, which the kernel doesn't expect.

Since we no longer support 386 (the source of most of the variability
in %cr0 configuration), we can simply match further x86-64 and
initialize %cr0 to a fixed value -- the one variable part remaining in
%cr0 is for FPU control, but all that is handled later on in
initialization; in particular, configuring %cr0 as if the FPU is
present until proven otherwise is correct and necessary for the probe
to work.

To deal with the XO case sanely, explicitly disable paging in %cr0
before we muck with %cr3, %cr4 or EFER -- those operations are
inherently unsafe with paging enabled.

NOTE: There is still a lot of 386-related junk in head_32.S which we
can and should get rid of, however, this is intended as a minimal fix
whereas the cleanup can be deferred to the next merge window.
Reported-by: Andres Salomon <dilinger@queued.net>
Tested-by: Daniel Drake <dsd@laptop.org>
Link: http://lkml.kernel.org/r/50FA0661.2060400@linux.intel.comSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>

Pull more s390 patches from Martin Schwidefsky:
 "A couple of bug fixes: one of the transparent huge page primitives is
  broken, the sched_clock function overflows after 417 days, the XFS
  module has grown too large for -fpic and the new pci code has broken
  normal channel subsystem notifications."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/chsc: fix SEI usage
  s390/time: fix sched_clock() overflow
  s390: use -fPIC for module compile
  s390/mm: fix pmd_pfn() for thp

Pull xfs bugfixes from Ben Myers:

 - fix(es) for compound buffers

 - fix for dquot soft timer asserts due to overflow of d_blk_softlimit

 - fix for regression in dir v2 code introduced in commit 20f7e9f3
   ("xfs: factor dir2 block read operations")

* tag 'for-linus-v3.8-rc4' of git://oss.sgi.com/xfs/xfs:
  xfs: recalculate leaf entry pointer after compacting a dir2 block
  xfs: remove int casts from debug dquot soft limit timer asserts
  xfs: fix the multi-segment log buffer format
  xfs: fix segment in xfs_buf_item_format_segment
  xfs: rename bli_format to avoid confusion with bli_formats
  xfs: use b_maps[] for discontiguous buffers

Pull ACPI and power management fixes from Rafael Wysocki:

 - cpuidle regression fix related to the initialization of state
   kobjects from Krzysztof Mazur.

 - cpuidle fix removing some not very useful code and making some
   user-visible problems go away at the same time.  From Daniel Lezcano.

 - ACPI build fix from Yinghai Lu.

* tag 'pm+acpi-for-3.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpuidle: remove the power_specified field in the driver
  ACPI / glue: Fix build with ACPI_GLUE_DEBUG set
  cpuidle: fix number of initialized/destroyed states

Dave Jones hit this assert when doing a compile on recent git, with
CONFIG_XFS_DEBUG enabled:

XFS: Assertion failed: (char *)dup - (char *)hdr == be16_to_cpu(*xfs_dir2_data_unused_tag_p(dup)), file: fs/xfs/xfs_dir2_data.c, line: 828

Upon further digging, the tag found by xfs_dir2_data_unused_tag_p(dup)
contained "2" and not the proper offset, and I found that this value was
changed after the memmoves under "Use a stale leaf for our new entry."
in xfs_dir2_block_addname(), i.e.

                        memmove(&blp[mid + 1], &blp[mid],
                                (highstale - mid) * sizeof(*blp));

overwrote it.

What has happened is that the previous call to xfs_dir2_block_compact()
has rearranged things; it changes btp->count as well as the
blp array.  So after we make that call, we must recalculate the
proper pointer to the leaf entries by making another call to
xfs_dir2_block_leaf_p().

Dave provided a metadump image which led to a simple reproducer
(create a particular filename in the affected directory) and this
resolves the testcase as well as the bug on his live system.

Thanks also to dchinner for looking at this one with me.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Tested-by: Dave Jones <davej@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>

The int casts here make it easy to trigger an assert with a large
soft limit. For example, set a >4TB soft limit on an empty volume
to reproduce a (0 > -x) comparison due to an overflow of
d_blk_softlimit.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>

Per Dave Chinner suggestion, this patch:
 1) Corrects the detection of whether a multi-segment buffer is
    still tracking data.
 2) Clears all the buffer log formats for a multi-segment buffer.
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>

Not every segment in a multi-segment buffer is dirty in a
transaction and they will not be outputted. The assert in
xfs_buf_item_format_segment() that checks for the at least
one chunk of data in the segment to be used is not necessary
true for multi-segmented buffers.
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>

Rename the bli_format structure to __bli_format to avoid
accidently confusing them with the bli_formats pointer.
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Ben Myers <bpm@sgi.com>

Commits starting at 77c1a08f introduced a multiple segment support
to xfs_buf. xfs_trans_buf_item_match() could not find a multi-segment
buffer in the transaction because it was looking at the single segment
block number rather than the multi-segment b_maps[0].bm.bn. This
results on a recursive buffer lock that can never be satisfied.

This patch:
 1) Changed the remaining b_map accesses to be b_maps[0] accesses.
 2) Renames the single segment b_map structure to __b_map to avoid
    future confusion.
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>

In commit 281dc5c5 ("Give up on pushing CC_OPTIMIZE_FOR_SIZE") we
already changed the actual default value, but the help-text still
suggested 'y'. Fix the help text too, for all the same reasons.

Sadly, -Os keeps on generating some very suboptimal code for certain
cases, to the point where any I$ miss upside is swamped by the downside.
The main ones are:

 - using "rep movsb" for memcpy, even on CPU's where that is
   horrendously bad for performance.

 - not honoring branch prediction information, so any I$ footprint you
   win from smaller code, you lose from less code density in the I$.

 - using divide instructions when that is very expensive.
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Fix the build error:

  drivers/built-in.o: In function `twl_probe':
  drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c'
  make: *** [vmlinux] Error 1
Signed-off-by: liu chuansheng <chuansheng.liu@intel.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[ Samuel is busy, taking it directly  - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

[ We should make fun of people who can't speel too, but then we'd have
  no time for any real work at all  - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Commit 1b963c81 ("lockdep, rwsem: provide down_write_nest_lock()")
contains a bug in a codepath when CONFIG_DEBUG_LOCK_ALLOC is disabled,
which causes down_read() to be called instead of down_write() by mistake
on such configurations.  Fix that.
Reported-and-tested-by: Andrew Clayton <andrew@digital-domain.net>
Reported-and-tested-by: Zlatko Calusic <zlatko.calusic@iskon.hr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull second round of sound fixes from Takashi Iwai:
 "Yet a few more fixes popped up in this week.

  The biggest change here is the addition of pinctrl support for Atmel,
  which turned out to be almost mandatory to make things working.

  The rest are a few fixes for M-Audio usb-audio device and a fix for
  regression of HD-audio HDMI codecs with alsactl in the recent kernel."

* tag 'sound-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda/hdmi - Work around "alsactl restore" errors
  ALSA: usb-audio: selector map for M-Audio FT C400
  ALSA: usb-audio: M-Audio FT C400 skip packet quirk
  ALSA: usb-audio: correct M-Audio C400 clock source quirk
  ALSA: usb - fix race in creation of M-Audio Fast track pro driver
  ASoC: atmel-ssc: add pinctrl selection to driver
  ARM: at91/dts: add pinctrl support for SSC peripheral

Pull scsi target fixes from Nicholas Bellinger:
 "This includes an important >= v3.6 regression bugfix for active I/O
  shutdown (Roland), some TMR related failure / corner cases fixes for
  long outstanding I/O (Roland), two FCoE target mode fabric fabric role
  fixes (MDR), a fix for an incorrect sense code during LUN
  communication failure (Dr. Hannes), plus a handful of other minor
  fixes.

  There are still some outstanding zero-length control CDB regression
  fixes that need to be addressed for v3.8, that will be coming in a
  follow-up PULL request."

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  iscsi-target: Fix CmdSN comparison (use cmd->cmd_sn instead of cmd->stat_sn)
  target: Release se_cmd when LUN lookup fails for TMR
  target: Fix use-after-free in LUN RESET handling
  target: Fix missing CMD_T_ACTIVE bit regression for pending WRITEs
  tcm_fc: Do not report target role when target is not defined
  tcm_fc: Do not indicate retry capability to initiators
  target: Use TCM_NO_SENSE for initialisation
  target: Introduce TCM_NO_SENSE
  target: use correct sense code for LUN communication failure

Pull ext3 and udf fixes from Jan Kara:
 "One ext3 performance regression fix and one udf regression fix (oops
  on interrupted mount)."

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  UDF: Fix a null pointer dereference in udf_sb_free_partitions
  jbd: don't wake kjournald unnecessarily

Pull s390 KVM fix from Gleb Natapov.

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  s390/kvm: Fix BUG in include/linux/kvm_host.h:745

Pull SuperH fixes from Paul Mundt.

* tag 'sh-for-linus' of git://github.com/pmundt/linux-sh:
  sh: ecovec: add sample amixer settings
  sh: Fix up stack debugging build.
  sh: wire up finit_module syscall.
  sh: Fix FDPIC binary loader
  sh: clkfwk: bugfix: sh_clk_div_enable() care sh_clk_div_set_rate() if div6
  sh: define TASK_UNMAPPED_BASE as a page aligned constant

Pull arm64 fixes from Catalin Marinas:
 - Page protection fixes, including proper PAGE_NONE handling
 - Timezone vdso sequence counting fix
 - Additional compat syscall wiring

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
  arm64: compat: add syscall table entries for new syscalls
  arm64: mm: introduce present, faulting entries for PAGE_NONE
  arm64: mm: only wrprotect clean ptes if they are present
  arm64: vdso: remove broken, redundant sequence counting for timezones

Pull x86 fixes from Peter Anvin:
 "This is mainly a workaround for a bug in Sandy Bridge graphics which
  causes corruption of certain memory pages."

* 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/Sandy Bridge: Sandy Bridge workaround depends on CONFIG_PCI
  x86/Sandy Bridge: mark arrays in __init functions as __initconst
  x86/Sandy Bridge: reserve pages when integrated graphics is present
  x86, efi: correct precedence of operators in setup_efi_pci

Timur Tabi no longer works for Freescale, so update the email address
and status for all of his maintained projects.

Also mark the QE library as orphaned, for lack of interest in
maintaining it.

The CS4270 driver is marked as "Odd Fixes" because appropriate hardware
is no longer available.
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

If the requested firmware file size is 0 bytes in the filesytem, we
will try to vmalloc(0), which causes a warning:

  vmalloc: allocation failure: 0 bytes
  kworker/1:1: page allocation failure: order:0, mode:0xd2
    __vmalloc_node_range+0x164/0x208
    __vmalloc_node+0x4c/0x58
    vmalloc+0x38/0x44
    _request_firmware_load+0x220/0x6b0
    request_firmware+0x64/0xc8
    wl18xx_setup+0xb4/0x570 [wl18xx]
    wlcore_nvs_cb+0x64/0x9f8 [wlcore]
    request_firmware_work_func+0x94/0x100
    process_one_work+0x1d0/0x750
    worker_thread+0x184/0x4ac
    kthread+0xb4/0xc0

To fix this, check whether the file size is less than or equal to zero
in fw_read_file_contents().

Cc: stable <stable@vger.kernel.org> [3.7]
Signed-off-by: Luciano Coelho <coelho@ti.com>
Acked-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

If the default iosched is built as module, the kernel may deadlock
while trying to load the iosched module on device probe if the probing
was running off async.  This is because async_synchronize_full() at
the end of module init ends up waiting for the async job which
initiated the module loading.

 async A				modprobe

 1. finds a device
 2. registers the block device
 3. request_module(default iosched)
					4. modprobe in userland
					5. load and init module
					6. async_synchronize_full()

Async A waits for modprobe to finish in request_module() and modprobe
waits for async A to finish in async_synchronize_full().

Because there's no easy to track dependency once control goes out to
userland, implementing properly nested flushing is difficult.  For
now, make module init perform async_synchronize_full() iff module init
has queued async jobs as suggested by Linus.

This avoids the described deadlock because iosched module doesn't use
async and thus wouldn't invoke async_synchronize_full().  This is
hacky and incomplete.  It will deadlock if async module loading nests;
however, this works around the known problem case and seems to be the
best of bad options.

For more details, please refer to the following thread.

  http://thread.gmane.org/gmane.linux.kernel/1420814Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Alex Riesen <raa.lkml@gmail.com>
Tested-by: Ming Lei <ming.lei@canonical.com>
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

cbc0dd1f "s390/pci: CHSC PCI support for error and availability events"
introduced a new SEI notification type as part of pci support.
The way SEI was called with nt2 and nt0 consecutive broke the nt0
stuff used for channel subsystem notifications.

The reason why this was broken with the mentioned patch is that you
cannot selectively disable type 0 notifications (so even when asked
for type 2 only, type 0 could be presented).

The way to do it is to tell SEI which types of notification you can
process and -this is the important part- look at the SEI result which
notification type you actually received.
Reviewed-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Tested-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

Converting a 64 Bit TOD format value to nanoseconds means that the value
must be divided by 4.096. In order to achieve that we multiply with 125
and divide by 512.
When used within sched_clock() this triggers an overflow after appr.
417 days. Resulting in a sched_clock() return value that is much smaller
than previously and therefore may cause all sort of weird things in
subsystems that rely on a monotonic sched_clock() behaviour.

To fix this implement a tod_to_ns() helper function which converts TOD
values without overflow and call this function from both places that
open coded the conversion: sched_clock() and kvm_s390_handle_wait().

Cc: stable@kernel.org
Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

FSI - DA7210 needs amixer settings to use it.
This patch adds quick setting guide
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

There have been a number of new syscalls introduced to arch/arm/ since
the compat layer was implemented for arm64, so add pointers to the
relevant functions to the compat syscall table.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

When "alsactl restore" is performed on HDMI codecs, it tries to
restore the channel map value since the channel map controls are
writable.  But hdmi_chmap_ctl_put() returns -EBADFD when no PCM stream
is assigned yet, and this results in an error message from alsactl.
Although the error is harmless, it's certainly ugly and can be
regarded as a regression.

As a workaround, this patch changes the return code in such a case to
be zero for making others happy.  (A slight excuse is: when the chmap
is changed through the proper alsa-lib API, the PCM status is checked
there anyway, so we don't have to be too strict in the kernel side.)

Cc: <stable@vger.kernel.org> [v3.7+]
Signed-off-by: Takashi Iwai <tiwai@suse.de>

We realized that the power usage field is never filled and when it
is filled for tegra, the power_specified flag is not set causing all
of these values to be reset when the driver is initialized with
set_power_state().

However, the power_specified flag can be simply removed under the
assumption that the states are always backward sorted, which is the
case with the current code.

This change allows the menu governor select function and the
cpuidle_play_dead() to be simplified.  Moreover, the
set_power_states() function can removed as it does not make sense
any more.

Drop the power_specified flag from struct cpuidle_driver and make
the related changes as described above.

As a consequence, this also fixes the bug where on the dynamic
C-states system, the power fields are not initialized.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=42870
References: https://bugzilla.kernel.org/show_bug.cgi?id=43349
References: https://lkml.org/lkml/2012/10/16/518Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge tag 'asoc-atmel-pinctrl' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: atmel: Fixes for pinctrl

Due to a series of problems with the handling of Atmel, a combination of
making changes that make other branches instantly buggy and a general
failure to deal with the resulting issues effectively, v3.8 Atmel audio
currently won't work at all for DT boards without adding pinctrl
definitions and a request for those.

Merge tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull tracing regression fixes from Steven Rostedt:
 "The clean up patch commit 0fb9656d "tracing: Make tracing_enabled
  be equal to tracing_on" caused two regressions.

   1) The irqs off latency tracer no longer starts if tracing_on is off
      when the tracer is set, and then tracing_on is enabled.  The
      tracing_on file needs the hook that tracing_enabled had to enable
      tracers if they request it (call the tracer's start() method).

   2) That commit had a separate change that really should have been a
      separate patch, but it must have been added accidently with the -a
      option of git commit.  But as the change is still related to the
      commit it wasn't noticed in review.  That change, changed the way
      blocking is done by the trace_pipe file with respect to the
      tracing_on settings.  I've been told that this change breaks
      current userspace, and this specific change is being reverted."

* tag 'trace-3.8-rc3-regression-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Fix regression of trace_pipe
  tracing: Fix regression with irqsoff tracer and tracing_on file