Merge tag 'char-misc-4.0-rc3' of git://git./linux/kernel/git/gregkh/char-misc

Pull char/misc driver fixes from Greg KH:
 "Here are two char/misc fixes for 4.0-rc3.

  One is a reported binder driver fix needed due to a change in the mm
  core that happened in 4.0-rc1.  Another is a mei driver fix that
  resolves a reported issue in that driver.

  Both have been in linux-next for a while"

* tag 'char-misc-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  mei: make device disabled on stop unconditionally
  android: binder: fix binder mmap failures

Merge tag 'cc-4.0-rc2' of git://git./linux/kernel/git/gregkh/char-misc

Pull "code of conflict" from Greg KH:
 "This file tries to set the rational basis for our code reviews, gives
  some advice on how to conduct them, and provides an excalation channel
  for any kernel developers if they so desire it"

[ Let's see how this works ]

* tag 'cc-4.0-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  Code of Conflict

Merge branch 'i2c/for-current' of git://git./linux/kernel/git/wsa/linux

Pull i2c fixes from Wolfram Sang:
 "A set of updates and bugfixes for the new designware-baytrail driver.

  And a documentation bugfix"

* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: imx: add required clocks property to binding
  i2c: designware-baytrail: baytrail_i2c_acquire() might sleep
  i2c: designware-baytrail: cross-check lock functions
  i2c: designware-baytrail: fix sparse warnings
  i2c: designware-baytrail: fix typo in error path
  i2c: designware-baytrail: describe magic numbers

Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma

Pull slave-dmaengine fixes from Vinod Koul:
 "This contains small fixes spread across the drivers"

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dmaengine: mmp_pdma: fix warning about slave caps
  dmaengine: qcom_bam_dma: fix wrong register offsets
  dmaengine: bam-dma: fix a warning about missing capabilities
  dmaengine: ioatdma: workaround for incorrect DMACAP register
  dmaengine: at_xdmac: fix for chan conf simplification
  dmaengine: dw: don't handle interrupt when dmaengine is not used
  dma: mmp-tdma: refine dma disable and dma-pos update
  dmaengine: shdma: Move DMA stop to (runtime) suspend callbacks
  dmaenegine: mmp-pdma: fix irq handler overwrite physical chan issue

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull arm64 fixes from Catalin Marinas:
 "arm64 and generic kernel/module.c (acked by Rusty) fixes for
  CONFIG_DEBUG_SET_MODULE_RONX"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  kernel/module.c: Update debug alignment after symtable generation
  arm64: Don't use is_module_addr in setting page attributes

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "Radeon, imx, msm, and i915 fixes.

  The msm, imx and i915 ones are fairly run of the mill.

  Radeon had some DP audio and posting reads for irq fixes, along with a
  fix for 32-bit kernels with new cards, we were using unsigned long to
  represent GPU side memory space, but since that changed size on 32 vs
  64 cards with lots of VRAM failed, so the change has no effect on
  x86-64, just moves to using uint64_t instead"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (35 commits)
  drm/msm: kexec fixes
  drm/msm/mdp5: fix cursor blending
  drm/msm/mdp5: fix cursor ROI
  drm/msm/atomic: Don't leak atomic commit object when commit fails
  drm/msm/mdp5: Avoid flushing registers when CRTC is disabled
  drm/msm: update generated headers (add 6th lm.base entry)
  drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
  drm/ttm: device address space != CPU address space
  drm/mm: Support 4 GiB and larger ranges
  drm/i915: gen4: work around hang during hibernation
  drm/i915: Check for driver readyness before handling an underrun interrupt
  drm/radeon: fix interlaced modes on DCE8
  drm/radeon: fix DRM_IOCTL_RADEON_CS oops
  drm/radeon: do a posting read in cik_set_irq
  drm/radeon: do a posting read in si_set_irq
  drm/radeon: do a posting read in evergreen_set_irq
  drm/radeon: do a posting read in r600_set_irq
  drm/radeon: do a posting read in rs600_set_irq
  drm/radeon: do a posting read in r100_set_irq
  radeon/audio: fix DP audio on DCE6
  ...

i2c: imx: add required clocks property to binding

A clock specifier is required for i.MX I2C and is
provided in all DTS implementations. Add this to the
list of required properties in the binding.

Signed-off-by: Matt Porter <mporter@konsulko.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: designware-baytrail: baytrail_i2c_acquire() might sleep

This patch marks baytrail_i2c_acquire() that it might sleep. Also it chages
while-loop to do-while and, though it is matter of taste, gives a chance to
check one more time before report a timeout.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: designware-baytrail: cross-check lock functions

It seems the idea behind the cross-check is to prevent acquire semaphore when
there is no release callback and vice versa. Thus, patch fixes a typo.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: designware-baytrail: fix sparse warnings

There is no need to export functions that are used as the callbacks in the
struct dw_i2c_dev. Otherwise we get the following warnings:

drivers/i2c/busses/i2c-designware-baytrail.c:63:5: warning: symbol 'baytrail_i2c_acquire' was not declared. Should it be static?
drivers/i2c/busses/i2c-designware-baytrail.c:114:6: warning: symbol 'baytrail_i2c_release' was not declared. Should it be static?

While here, do few indentation fixes, remove i2c_dw_eval_lock_support() from
functions exported to the modules and redundant assignment of local sem
variable.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: designware-baytrail: fix typo in error path

It seems we have same message for different return values in get_sem() and
baytrail_i2c_acquire(). I suspect this is just a typo, so this patch fixes it.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: designware-baytrail: describe magic numbers

The patch converts hardcoded numerical constants to a named ones.

While here, align the variable name in get_sem() and reset_semaphore().

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Merge branch 'for-linus' of git://git./linux/kernel/git/mason/linux-btrfs

Pull btrfs fixes from Chris Mason:
 "Outside of misc fixes, Filipe has a few fsync corners and we're
  pulling in one more of Josef's fixes from production use here"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref.
  Btrfs: fix data loss in the fast fsync path
  Btrfs: remove extra run_delayed_refs in update_cowonly_root
  Btrfs: incremental send, don't rename a directory too soon
  btrfs: fix lost return value due to variable shadowing
  Btrfs: do not ignore errors from btrfs_lookup_xattr in do_setxattr
  Btrfs: fix off-by-one logic error in btrfs_realloc_node
  Btrfs: add missing inode update when punching hole
  Btrfs: abort the transaction if we fail to update the free space cache inode
  Btrfs: fix fsync race leading to ordered extent memory leaks

Merge branch 'for-linus' of git://git./linux/kernel/git/jikos/livepatching

Pull livepatching fix from Jiri Kosina:
 "Fix an RCU unlock misplacement in live patching infrastructure, from
  Peter Zijlstra"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching:
  livepatch: fix RCU usage in klp_find_external_symbol()

Merge branch 'fixes' of git://git./linux/kernel/git/evalenti/linux-soc-thermal

Pull thermal management fixes from Eduardo Valentin:
 "Specifics:

   - adding Lukasz as maintainer of samsung thermal driver.
   - driver fixes: exynos and int430x.
   - one fix in the exynos cpufreq driver related to cpu cooling (acked
     by cpufreq maintainer).
   - fix default sysfs attributes of cooling devices

  Note: I am sending this pull on Rui's behalf while he fixes issues in his Linux box"

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal:
  thermal: Make sysfs attributes of cooling devices default attributes
  Thermal/int340x: Fix memleak for aux trip
  MAINTAINERS: Add entry for SAMSUNG THERMAL DRIVER
  cpufreq: exynos: Use simple approach to asses if cpu cooling can be used
  thermal: exynos: Fix wrong control of power down detection mode for Exynos7

Merge tag 'drm-intel-fixes-2015-03-05' of git://anongit.freedesktop.org/drm-intel into drm-fixes

two fixes, both cc'd stable.

* tag 'drm-intel-fixes-2015-03-05' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: gen4: work around hang during hibernation
  drm/i915: Check for driver readyness before handling an underrun interrupt

Merge tag 'v4.0-rc2' into drm-fixes

Linux 4.0-rc2

Merging this manually as the i915 change is in it,
and intel fixes are on top of this

Merge tag 'sound-4.0-rc3' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Here are a few more ASoC changes that have been gathered since rc1,
  but it's still fairly calm over all.  The only largish LOC is found in
  atmel driver, and it's just a removal of broken non-DT stuff.  The
  rest are all small driver-specific fixes, nothing to worry much"

* tag 'sound-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits)
  ALSA: hda - One more Dell macine needs DELL1_MIC_NO_PRESENCE quirk
  ALSA: opl3: small array underflow
  ALSA: line6: Clamp values correctly
  ALSA: msnd: add some missing curly braces
  ASoC: omap-pcm: Correct dma mask
  ASoC: simple-card: Add a NULL pointer check in asoc_simple_card_dai_link_of
  ASoC: sam9g20_wm8731: drop machine_is_xxx
  ALSA: dice: fix wrong offsets for Dice interface
  ALSA: oxfw: fix a condition and return code in start_stream()
  ASoC: OMAP: mcbsp: Fix CLKX and CLKR pinmux when used as inputs
  ASoC: rt5677: Correct the routing paths of that after IF1/2 DACx Mux
  ASoC: sta32x: fix register range in regmap.
  ASoC: rt5670: Set RT5670_IRQ_CTRL1 non volatile
  ASoC: Intel: reset the DSP while suspending
  ASoC: Intel: save and restore the CSR register
  ASoC: Intel: update MMX ID to 3
  ASoC: max98357a: Add missing header files
  ASoC: cirrus: tlv320aic23 needs I2C
  ASoC: Samsung: add missing I2C/SPI dependencies
  ASoC: rt5670: Fix the speaker mono output issue
  ...

Merge tag 'pm+acpi-4.0-rc3' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management and ACPI fixes from Rafael Wysocki:
 "These are fixes for recent regressions (ACPI resources management,
  suspend-to-idle), stable-candidate fixes (ACPI backlight), fixes
  related to the wakeup IRQ management changes made in v3.18, other
  fixes (suspend-to-idle, cpufreq ppc driver) and a couple of cleanups
  (suspend-to-idle, generic power domains, ACPI backlight).

  Specifics:

   - Fix ACPI resources management problems introduced by the recent
     rework of the code in question (Jiang Liu) and a build issue
     introduced by those changes (Joachim Nilsson).

   - Fix a recent suspend-to-idle regression on systems where entering
     idle states causes local timers to stop, prevent suspend-to-idle
     from crashing in restricted configurations (no cpuidle driver,
     cpuidle disabled etc.) and clean up the idle loop somewhat while at
     it (Rafael J Wysocki).

   - Fix build problem in the cpufreq ppc driver (Geert Uytterhoeven).

   - Allow the ACPI backlight driver module to be loaded if ACPI is
     disabled which helps the i915 driver in those configurations
     (stable-candidate) and change the code to help debug unusual use
     cases (Chris Wilson).

   - Wakeup IRQ management changes in v3.18 caused some drivers on the
     at91 platform to trigger a warning from the IRQ core related to an
     unexpected combination of interrupt action handler flags.  However,
     on at91 a timer IRQ is shared with some other devices (including
     system wakeup ones) and that leads to the unusual combination of
     flags in question.

     To make it possible to avoid the warning introduce a new interrupt
     action handler flag (which can be used by drivers to indicate the
     special case to the core) and rework the problematic at91 drivers
     to use it and work as expected during system suspend/resume.  From
     Boris Brezillon, Rafael J Wysocki and Mark Rutland.

   - Clean up the generic power domains subsystem's debugfs interface
     (Kevin Hilman)"

* tag 'pm+acpi-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  genirq / PM: describe IRQF_COND_SUSPEND
  tty: serial: atmel: rework interrupt and wakeup handling
  watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
  cpuidle / sleep: Use broadcast timer for states that stop local timer
  clk: at91: implement suspend/resume for the PMC irqchip
  rtc: at91rm9200: rework wakeup and interrupt handling
  rtc: at91sam9: rework wakeup and interrupt handling
  PM / wakeup: export pm_system_wakeup symbol
  genirq / PM: Add flag for shared NO_SUSPEND interrupt lines
  ACPI / video: Propagate the error code for acpi_video_register
  ACPI / video: Load the module even if ACPI is disabled
  PM / Domains: cleanup: rename gpd -> genpd in debugfs interface
  cpufreq: ppc: Add missing #include <asm/smp.h>
  x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs
  x86/PCI/ACPI: Ignore resources consumed by host bridge itself
  cpuidle: Clean up fallback handling in cpuidle_idle_call()
  cpuidle / sleep: Do sanity checks in cpuidle_enter_freeze() too
  idle / sleep: Avoid excessive disabling and enabling interrupts
  PCI: versatile: Update for list_for_each_entry() API change
  genirq / PM: better describe IRQF_NO_SUSPEND semantics

Merge tag 'locks-v4.0-3' of git://git.samba.org/jlayton/linux

Pull file locking fix from Jeff Layton:
 "Just a single patch to fix a memory leak that Daniel Wagner discovered
  while doing some testing with leases"

* tag 'locks-v4.0-3' of git://git.samba.org/jlayton/linux:
  locks: fix fasync_struct memory leak in lease upgrade/downgrade handling

Merge tag 'nfs-for-4.0-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs

Pull NFS client bugfixes from Trond Myklebust:
 "Highlights include:

   - Fix a regression in the NFSv4 open state recovery code
   - Fix a regression in the NFSv4 close code
   - Fix regressions and side-effects of the loop-back mounted NFS fixes
     in 3.18, that cause the NFS read() syscall to return EBUSY.
   - Fix regressions around the readdirplus code and how it interacts
     with the VFS lazy unmount changes that went into v3.18.
   - Fix issues with out-of-order RPC call replies replacing updated
     attributes with stale ones (particularly after a truncate()).
   - Fix an underflow checking issue with RPC/RDMA credits
   - Fix a number of issues with the NFSv4 delegation return/free code.
   - Fix issues around stale NFSv4.1 leases when doing a mount"

* tag 'nfs-for-4.0-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: (24 commits)
  NFSv4.1: Clear the old state by our client id before establishing a new lease
  NFSv4: Fix a race in NFSv4.1 server trunking discovery
  NFS: Don't write enable new pages while an invalidation is proceeding
  NFS: Fix a regression in the read() syscall
  NFSv4: Ensure we skip delegations that are already being returned
  NFSv4: Pin the superblock while we're returning the delegation
  NFSv4: Ensure we honour NFS_DELEGATION_RETURNING in nfs_inode_set_delegation()
  NFSv4: Ensure that we don't reap a delegation that is being returned
  NFS: Fix stateid used for NFS v4 closes
  NFSv4: Don't call put_rpccred() under the rcu_read_lock()
  NFS: Don't require a filehandle to refresh the inode in nfs_prime_dcache()
  NFSv3: Use the readdir fileid as the mounted-on-fileid
  NFS: Don't invalidate a submounted dentry in nfs_prime_dcache()
  NFSv4: Set a barrier in the update_changeattr() helper
  NFS: Fix nfs_post_op_update_inode() to set an attribute barrier
  NFS: Remove size hack in nfs_inode_attrs_need_update()
  NFSv4: Add attribute update barriers to delegreturn and pNFS layoutcommit
  NFS: Add attribute update barriers to NFS writebacks
  NFS: Set an attribute barrier on all updates
  NFS: Add attribute update barriers to nfs_setattr_update_inode()
  ...

Merge tag 'asoc-fix-v4.0-rc2' of git://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v4.0

A few driver specific fixes here, none of them earth shattering in
themselves, that have accumliated since the opening of the merge window.

ALSA: hda - One more Dell macine needs DELL1_MIC_NO_PRESENCE quirk

Cc: <stable@vger.kernel.org>
BugLink: https://bugs.launchpad.net/bugs/1428947
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: opl3: small array underflow

There is a missing lower bound check on "pitchbend" so it means we can
read up to 6 elements before the start of the opl3_note_table[] array.

Thanks to Clemens Ladisch for his help with this patch.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

kernel/module.c: Update debug alignment after symtable generation

When CONFIG_DEBUG_SET_MODULE_RONX is enabled, the sizes of
module sections are aligned up so appropriate permissions can
be applied. Adjusting for the symbol table may cause them to
become unaligned. Make sure to re-align the sizes afterward.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

arm64: Don't use is_module_addr in setting page attributes

The set_memory_* functions currently only support module
addresses. The addresses are validated using is_module_addr.
That function is special though and relies on internal state
in the module subsystem to work properly. At the time of
module initialization and calling set_memory_*, it's too early
for is_module_addr to work properly so it always returns
false. Rather than be subject to the whims of the module state,
just bounds check against the module virtual address range.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>

Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref.

Improper arithmetics when calculting the address of the extended ref could
lead to an out of bounds memory read and kernel panic.

Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
cc: stable@vger.kernel.org # v3.7+
Signed-off-by: Chris Mason <clm@fb.com>

Btrfs: fix data loss in the fast fsync path

When using the fast file fsync code path we can miss the fact that new
writes happened since the last file fsync and therefore return without
waiting for the IO to finish and write the new extents to the fsync log.

Here's an example scenario where the fsync will miss the fact that new
file data exists that wasn't yet durably persisted:

1. fs_info->last_trans_committed == N - 1 and current transaction is
   transaction N (fs_info->generation == N);

2. do a buffered write;

3. fsync our inode, this clears our inode's full sync flag, starts
   an ordered extent and waits for it to complete - when it completes
   at btrfs_finish_ordered_io(), the inode's last_trans is set to the
   value N (via btrfs_update_inode_fallback -> btrfs_update_inode ->
   btrfs_set_inode_last_trans);

4. transaction N is committed, so fs_info->last_trans_committed is now
   set to the value N and fs_info->generation remains with the value N;

5. do another buffered write, when this happens btrfs_file_write_iter
   sets our inode's last_trans to the value N + 1 (that is
   fs_info->generation + 1 == N + 1);

6. transaction N + 1 is started and fs_info->generation now has the
   value N + 1;

7. transaction N + 1 is committed, so fs_info->last_trans_committed
   is set to the value N + 1;

8. fsync our inode - because it doesn't have the full sync flag set,
   we only start the ordered extent, we don't wait for it to complete
   (only in a later phase) therefore its last_trans field has the
   value N + 1 set previously by btrfs_file_write_iter(), and so we
   have:

       inode->last_trans <= fs_info->last_trans_committed
           (N + 1)              (N + 1)

   Which made us not log the last buffered write and exit the fsync
   handler immediately, returning success (0) to user space and resulting
   in data loss after a crash.

This can actually be triggered deterministically and the following excerpt
from a testcase I made for xfstests triggers the issue. It moves a dummy
file across directories and then fsyncs the old parent directory - this
is just to trigger a transaction commit, so moving files around isn't
directly related to the issue but it was chosen because running 'sync' for
example does more than just committing the current transaction, as it
flushes/waits for all file data to be persisted. The issue can also happen
at random periods, since the transaction kthread periodicaly commits the
current transaction (about every 30 seconds by default).
The body of the test is:

  _scratch_mkfs >> $seqres.full 2>&1
  _init_flakey
  _mount_flakey

  # Create our main test file 'foo', the one we check for data loss.
  # By doing an fsync against our file, it makes btrfs clear the 'needs_full_sync'
  # bit from its flags (btrfs inode specific flags).
  $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 8K" \
                  -c "fsync" $SCRATCH_MNT/foo | _filter_xfs_io

  # Now create one other file and 2 directories. We will move this second file
  # from one directory to the other later because it forces btrfs to commit its
  # currently open transaction if we fsync the old parent directory. This is
  # necessary to trigger the data loss bug that affected btrfs.
  mkdir $SCRATCH_MNT/testdir_1
  touch $SCRATCH_MNT/testdir_1/bar
  mkdir $SCRATCH_MNT/testdir_2

  # Make sure everything is durably persisted.
  sync

  # Write more 8Kb of data to our file.
  $XFS_IO_PROG -c "pwrite -S 0xbb 8K 8K" $SCRATCH_MNT/foo | _filter_xfs_io

  # Move our 'bar' file into a new directory.
  mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar

  # Fsync our first directory. Because it had a file moved into some other
  # directory, this made btrfs commit the currently open transaction. This is
  # a condition necessary to trigger the data loss bug.
  $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1

  # Now fsync our main test file. If the fsync succeeds, we expect the 8Kb of
  # data we wrote previously to be persisted and available if a crash happens.
  # This did not happen with btrfs, because of the transaction commit that
  # happened when we fsynced the parent directory.
  $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo

  # Simulate a crash/power loss.
  _load_flakey_table $FLAKEY_DROP_WRITES
  _unmount_flakey

  _load_flakey_table $FLAKEY_ALLOW_WRITES
  _mount_flakey

  # Now check that all data we wrote before are available.
  echo "File content after log replay:"
  od -t x1 $SCRATCH_MNT/foo

  status=0
  exit

The expected golden output for the test, which is what we get with this
fix applied (or when running against ext3/4 and xfs), is:

  wrote 8192/8192 bytes at offset 0
  XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
  wrote 8192/8192 bytes at offset 8192
  XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
  File content after log replay:
  0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
  *
  0020000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
  *
  0040000

Without this fix applied, the output shows the test file does not have
the second 8Kb extent that we successfully fsynced:

  wrote 8192/8192 bytes at offset 0
  XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
  wrote 8192/8192 bytes at offset 8192
  XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
  File content after log replay:
  0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
  *
  0020000

So fix this by skipping the fsync only if we're doing a full sync and
if the inode's last_trans is <= fs_info->last_trans_committed, or if
the inode is already in the log. Also remove setting the inode's
last_trans in btrfs_file_write_iter since it's useless/unreliable.

Also because btrfs_file_write_iter no longer sets inode->last_trans to
fs_info->generation + 1, don't set last_trans to 0 if we bail out and don't
bail out if last_trans is 0, otherwise something as simple as the following
example wouldn't log the second write on the last fsync:

  1. write to file

  2. fsync file

  3. fsync file
       |--> btrfs_inode_in_log() returns true and it set last_trans to 0

  4. write to file
       |--> btrfs_file_write_iter() no longers sets last_trans, so it
            remained with a value of 0
  5. fsync
       |--> inode->last_trans == 0, so it bails out without logging the
            second write

A test case for xfstests will be sent soon.

CC: <stable@vger.kernel.org>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>

Btrfs: remove extra run_delayed_refs in update_cowonly_root

This got added with my dirty_bgs patch, it's not needed.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>

Merge branches 'pm-domains' and 'pm-cpufreq'

* pm-domains:
  PM / Domains: cleanup: rename gpd -> genpd in debugfs interface

* pm-cpufreq:
  cpufreq: ppc: Add missing #include <asm/smp.h>

Merge branch 'acpi-video'

* acpi-video:
  ACPI / video: Propagate the error code for acpi_video_register
  ACPI / video: Load the module even if ACPI is disabled

Merge branch 'irq-pm'

* irq-pm:
  genirq / PM: describe IRQF_COND_SUSPEND
  tty: serial: atmel: rework interrupt and wakeup handling
  watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND
  clk: at91: implement suspend/resume for the PMC irqchip
  rtc: at91rm9200: rework wakeup and interrupt handling
  rtc: at91sam9: rework wakeup and interrupt handling
  PM / wakeup: export pm_system_wakeup symbol
  genirq / PM: Add flag for shared NO_SUSPEND interrupt lines
  genirq / PM: better describe IRQF_NO_SUSPEND semantics

genirq / PM: describe IRQF_COND_SUSPEND

With certain restrictions it is possible for a wakeup device to share
an IRQ with an IRQF_NO_SUSPEND user, and the warnings introduced by
commit cab303be91dc47942bc25de33dc1140123540800 are spurious. The new
IRQF_COND_SUSPEND flag allows drivers to tell the core when these
restrictions are met, allowing spurious warnings to be silenced.

This patch documents how IRQF_COND_SUSPEND is expected to be used,
updating some of the text now made invalid by its addition.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

tty: serial: atmel: rework interrupt and wakeup handling

The IRQ line connected to the DBGU UART is often shared with a timer device
which request the IRQ with IRQF_NO_SUSPEND.

Since the UART driver is correctly disabling IRQs when entering suspend
we can safely request the IRQ with IRQF_COND_SUSPEND so that irq core
will not complain about mixing IRQF_NO_SUSPEND and !IRQF_NO_SUSPEND.

Rework the interrupt handler to wake the system up when an interrupt
happens on the DEBUG_UART while the system is suspended.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND

The watchdog interrupt (only used when activating software watchdog)
shouldn't be suspended when entering suspend mode, because it is shared
with a timer device (which request the line with IRQF_NO_SUSPEND) and once
the watchdog "Mode Register" has been written, it cannot be changed (which
means we cannot disable the watchdog interrupt when entering suspend).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge branch 'suspend-to-idle'

* suspend-to-idle:
  cpuidle / sleep: Use broadcast timer for states that stop local timer
  cpuidle: Clean up fallback handling in cpuidle_idle_call()
  cpuidle / sleep: Do sanity checks in cpuidle_enter_freeze() too
  idle / sleep: Avoid excessive disabling and enabling interrupts

Merge branch 'acpi-resources'

* acpi-resources:
  x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs
  x86/PCI/ACPI: Ignore resources consumed by host bridge itself
  PCI: versatile: Update for list_for_each_entry() API change

cpuidle / sleep: Use broadcast timer for states that stop local timer

Commit 381063133246 (PM / sleep: Re-implement suspend-to-idle handling)
overlooked the fact that entering some sufficiently deep idle states
by CPUs may cause their local timers to stop and in those cases it
is necessary to switch over to a broadcast timer prior to entering
the idle state.  If the cpuidle driver in use does not provide
the new ->enter_freeze callback for any of the idle states, that
problem affects suspend-to-idle too, but it is not taken into account
after the changes made by commit 381063133246.

Fix that by changing the definition of cpuidle_enter_freeze() and
re-arranging of the code in cpuidle_idle_call(), so the former does
not call cpuidle_enter() any more and the fallback case is handled
by cpuidle_idle_call() directly.

Fixes: 381063133246 (PM / sleep: Re-implement suspend-to-idle handling)
Reported-and-tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Misc fixes: EFI fixes, an Intel Quark fix, an asm fix and an FPU
  handling fix"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/fpu/xsaves: Fix improper uses of __ex_table
  x86/intel/quark: Select COMMON_CLK
  x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization
  firmware: dmi_scan: Fix dmi_len type
  efi/libstub: Fix boundary checking in efi_high_alloc()
  firmware: dmi_scan: Fix dmi scan to handle "End of Table" structure

x86/fpu/xsaves: Fix improper uses of __ex_table

Commit:

  f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area")

introduced alternative instructions for XSAVES/XRSTORS and commit:

  adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time")

added support for the XSAVES/XRSTORS instructions at boot time.

Unfortunately both failed to properly protect them against faulting:

The 'xstate_fault' macro will use the closest label named '1'
backward and that ends up in the .altinstr_replacement section
rather than in .text. This means that the kernel will never find
in the __ex_table the .text address where this instruction might
fault, leading to serious problems if userspace manages to
trigger the fault.

Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Jamie Iles <jamie.iles@oracle.com>
[ Improved the changelog, fixed some whitespace noise. ]
Acked-by: Borislav Petkov <bp@alien8.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Cc: Allan Xavier <mr.a.xavier@gmail.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time")
Fixes: f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area")
Signed-off-by: Ingo Molnar <mingo@kernel.org>

dmaengine: mmp_pdma: fix warning about slave caps

Fix the dmaengine complaint about missing slave caps :
 - declare the available bus widths
 - declare the available transfer types
 - declare the residue calculation type

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

x86/intel/quark: Select COMMON_CLK

The commit 8bbc2a135b63 ("x86/intel/quark: Add Intel Quark
platform support") introduced a minimal support of Intel Quark
SoC. That allows to use core parts of the SoC. However, the SPI,
I2C, and GPIO drivers can't be selected by kernel configuration
because they depend on COMMON_CLK. The patch adds a COMMON_CLK
selection to the platfrom definition to allow user choose the drivers.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Ong, Boon Leong <boon.leong.ong@intel.com>
Cc: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Cc: Darren Hart <dvhart@linux.intel.com>
Fixes: 8bbc2a135b63 ("x86/intel/quark: Add Intel Quark platform support")
Link: http://lkml.kernel.org/r/1425569044-2867-1-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

dmaengine: qcom_bam_dma: fix wrong register offsets

The commit fb93f520e (dmaengine: qcom_bam_dma: Generalize BAM
register offset calculations) wrongly populated base offsets
for event registers for bam v1.4.

Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Reviewed-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

dmaengine: bam-dma: fix a warning about missing capabilities

Avoid the warning below triggered during dmaengine async device
registration.

WARNING: CPU: 1 PID: 1 at linux/drivers/dma/dmaengine.c:863
dma_async_device_register+0x2a8/0x4b8()
this driver doesn't support generic slave capabilities reporting

To do that fill mandatory .directions bit mask,
.src/dst_addr_widths and .residue_granularity dma_device fields
with appropriate values.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

ALSA: line6: Clamp values correctly

The usages of clamp() macro in sound/usb/line6/playback.c are just
wrong, the low and high values are swapped.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

ALSA: msnd: add some missing curly braces

There were some curly braces intended here.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

dmaengine: ioatdma: workaround for incorrect DMACAP register

BDX-DE IOATDMA reports incorrect DMACAP register for PQ related
ops. Ignoring those bits.

Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

dmaengine: at_xdmac: fix for chan conf simplification

When simplificating the channel configuration, the cyclic case has been
forgotten. It leads to use bad configuration causing many bugs.

Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

dmaengine: dw: don't handle interrupt when dmaengine is not used

When dma controller is not used by any user and set off,
we should disble interrupt handler, at least the interrupt
reset part, for some subsystem, e.g. ADSP, may use the
dma in its own logic, here reset the interrupt may make
this subsystem work abnormally.

Signed-off-by: Jie Yang <yang.jie@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

thermal: Make sysfs attributes of cooling devices default attributes

Default attributes are created when the device is registered. Attributes
created after device registration can lead to race conditions, where user space
(e.g. udev) sees the device but not the attributes.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>

Thermal/int340x: Fix memleak for aux trip

When thermal zone device register fails or on module exit, the memory
for aux_trip is not freed. This change fixes this issue.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>

x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization

'ret_from_fork' checks TIF_IA32 to determine whether 'pt_regs' and
the related state make sense for 'ret_from_sys_call'.  This is
entirely the wrong check.  TS_COMPAT would make a little more
sense, but there's really no point in keeping this optimization
at all.

This fixes a return to the wrong user CS if we came from int
0x80 in a 64-bit task.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/4710be56d76ef994ddf59087aad98c000fbab9a4.1424989793.git.luto@amacapital.net
[ Backported from tip:x86/asm. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge branch 'msm-fixes-4.0' of git://people.freedesktop.org/~robclark/linux into drm-fixes

Fixup some fallout of the fallout of atomic dpms, few mdp5 cursor
fixes, fix a leak in error path, and some fixes for kexec

* 'msm-fixes-4.0' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: kexec fixes
  drm/msm/mdp5: fix cursor blending
  drm/msm/mdp5: fix cursor ROI
  drm/msm/atomic: Don't leak atomic commit object when commit fails
  drm/msm/mdp5: Avoid flushing registers when CRTC is disabled
  drm/msm: update generated headers (add 6th lm.base entry)
  drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"

drm/msm: kexec fixes

In kexec environment, we are more likely to encounter irq's already
enabled from previous environment.  At which point we find that writes
to disable/clear pending irq's are slightly less than useless without
first enabling clocks.

TODO: full blown state read-in so kexec'd kernel can inherit the mode
already setup.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: fix cursor blending

Seems like we just want BLEND_EN and not BLEND_TRANSP_EN (setting the
latter results in black pixels in the cursor image treated as
transparent).

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: fix cursor ROI

If cursor is set near the edge of the screen, it is not valid to use the
new cursor width/height as the ROI dimensions.  Split out the ROI calc
and use it both cursor_set and cursor_move.

Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/atomic: Don't leak atomic commit object when commit fails

If the atomic commit fails due to completion wait interruption the
atomic commit object is not freed and is thus leaked. Free it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: Avoid flushing registers when CRTC is disabled

When a CRTC is disabled, no CTL is allocated to it (CRTC->ctl == NULL);
in that case we should not try to FLUSH registers and do nothing instead.

This can happen when we try to move a cursor but the CRTC's CTL
(CONTROL) has not been allocated yet (inactive CRTC).
It can also happens when we .atomic_check()/.atomic_flush() on a
disabled CRTC.

A CTL needs to be kept as long as the CRTC is alive. Releasing it
after the last VBlank is safer than in .atomic_flush().

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm: update generated headers (add 6th lm.base entry)

Some target have up to 6 layer mixers (LM).
Let the header file access the last LM's base address.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"

Commit 0b776d457b94 ("drm/msm: fix fallout of atomic dpms
changes") has a typo in both mdp5_encoder_helper_funcs and
mdp5_crtc_helper_funcs definitions:

.dpms entry should be replaced by .disable and .enable

Also fixed a typo in mdp5_encoder_enable().

Note that these typos are only present for MDP5. MDP4 is fine.

Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

Radeon fixes for 4.0:
- Fix some fallout from the audio rework
- Fix a possible oops in the CS ioctl
- Fix interlaced modes on DCE8
- Do a posting read in irq_set callbacks to make sure
  interrupts are properly flushed through the pci bridge

* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: fix interlaced modes on DCE8
  drm/radeon: fix DRM_IOCTL_RADEON_CS oops
  drm/radeon: do a posting read in cik_set_irq
  drm/radeon: do a posting read in si_set_irq
  drm/radeon: do a posting read in evergreen_set_irq
  drm/radeon: do a posting read in r600_set_irq
  drm/radeon: do a posting read in rs600_set_irq
  drm/radeon: do a posting read in r100_set_irq
  radeon/audio: fix DP audio on DCE6
  radeon/audio: fix whitespace
  drm/radeon: adjust audio callback order
  drm/radeon: properly set dto for dp on DCE4/5
  drm/radeon/audio: update EDID derived fields in modeset
  drm/radeon: don't toggle audio state in modeset
  drm/radeon/audio: set mute around state setup
  drm/radeon: assign pin in detect
  drm/radeon: fix the audio dpms callbacks

drm/ttm: device address space != CPU address space

We need to store device offsets in 64 bit as the device
address space may be larger than the CPU's.

Fixes GPU init failures on radeons with 4GB or more of
vram on 32 bit kernels.  We put vram at the start of the
GPU's address space so the gart aperture starts at 4 GB
causing all GPU addresses in the gart aperture to get
truncated.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=89072

[airlied: fix warning on nouveau build]

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: thellstrom@vmware.com
Acked-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/mm: Support 4 GiB and larger ranges

The current implementation is limited by the number of addresses that
fit into an unsigned long. This causes problems on 32-bit Tegra where
unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
(or 4 GiB - 4 KiB for page granularity).

This commit changes the start and size of the range to be an unsigned
64-bit integer, thus allowing much larger ranges to be supported.

[airlied: fix i915 warnings and coloring callback]

Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
fixupo

locks: fix fasync_struct memory leak in lease upgrade/downgrade handling

Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
introduced a regression in the handling of lease upgrade/downgrades.

In the event that we already have a lease on a file and are going to
either upgrade or downgrade it, we skip doing any list insertion or
deletion and simply re-call lm_setup on the existing lease.

As of commit 8634b51f6ca2 however, we end up calling lm_setup on the
lease that was passed in, instead of on the existing lease. This causes
us to leak the fasync_struct that was allocated in the event that there
was not already an existing one (as it always appeared that there
wasn't one).

Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
Reported-and-Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>

Merge tag 'ecryptfs-4.0-rc3-fixes' of git://git./linux/kernel/git/tyhicks/ecryptfs

Pull eCryptfs fixes from Tyler Hicks:
 "Fixes for proper ioctl handling and an untriggerable buffer overflow

   - The eCryptfs ioctl handling functions should only pass known-good
     ioctl commands to the lower filesystem

   - A static checker found a potential buffer overflow.  Upon
     inspection, it is not triggerable due to input validation performed
     on the mount parameters"

* tag 'ecryptfs-4.0-rc3-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs:
  eCryptfs: don't pass fs-specific ioctl commands through
  eCryptfs: ensure copy to crypt_stat->cipher does not overrun

clk: at91: implement suspend/resume for the PMC irqchip

The irq line used by the PMC block is shared with several peripherals
including the init timer which is registering its handler with
IRQF_NO_SUSPEND.

Implement the appropriate suspend/resume callback for the PMC irqchip,
and inform irq core that PMC irq handler can be safely called while
the system is suspended by setting IRQF_COND_SUSPEND.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

rtc: at91rm9200: rework wakeup and interrupt handling

The IRQ line used by the RTC device is usually shared with the system
timer (PIT) on at91 platforms.

Since timers are registering their handlers with IRQF_NO_SUSPEND, we
should expect being called in suspended state, and properly wake the
system up when this is the case.

Set IRQF_COND_SUSPEND flag when registering the IRQ handler to inform
irq core that it can safely be called while the system is suspended.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

rtc: at91sam9: rework wakeup and interrupt handling

The IRQ line used by the RTC device is usually shared with the system timer
(PIT) on at91 platforms.

Since timers are registering their handlers with IRQF_NO_SUSPEND, we should
expect being called in suspended state, and properly wake the system up
when this is the case.

Set IRQF_COND_SUSPEND flag when registering the IRQ handler to inform
irq core that it can safely be called while the system is suspended.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

PM / wakeup: export pm_system_wakeup symbol

Export pm_system_wakeup function to allow irq handlers to deal with system
wakeup.

This is needed for shared IRQ lines where one of the handler is registered
with IRQF_NO_SUSPEND, while the other ones want to configure it as a wakeup
source.

In this specific case, irq core does not handle the wakeup process and
leave the decision to each irq handler.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge remote-tracking branch 'asoc/fix/sta32x' into asoc-linus

Merge remote-tracking branch 'asoc/fix/simple' into asoc-linus

Merge remote-tracking branch 'asoc/fix/samsung' into asoc-linus

Merge remote-tracking branch 'asoc/fix/rt5677' into asoc-linus

Merge remote-tracking branch 'asoc/fix/rt5670' into asoc-linus

Merge remote-tracking branch 'asoc/fix/rsnd' into asoc-linus

Merge remote-tracking branch 'asoc/fix/omap' into asoc-linus

Merge remote-tracking branch 'asoc/fix/max98357a' into asoc-linus

Merge remote-tracking branch 'asoc/fix/intel' into asoc-linus

Merge remote-tracking branch 'asoc/fix/fsl-ssi' into asoc-linus

Merge remote-tracking branch 'asoc/fix/cirrus' into asoc-linus

Merge remote-tracking branch 'asoc/fix/atmel-build' into asoc-linus

genirq / PM: Add flag for shared NO_SUSPEND interrupt lines

It currently is required that all users of NO_SUSPEND interrupt
lines pass the IRQF_NO_SUSPEND flag when requesting the IRQ or the
WARN_ON_ONCE() in irq_pm_install_action() will trigger.  That is
done to warn about situations in which unprepared interrupt handlers
may be run unnecessarily for suspended devices and may attempt to
access those devices by mistake.  However, it may cause drivers
that have no technical reasons for using IRQF_NO_SUSPEND to set
that flag just because they happen to share the interrupt line
with something like a timer.

Moreover, the generic handling of wakeup interrupts introduced by
commit 9ce7a25849e8 (genirq: Simplify wakeup mechanism) only works
for IRQs without any NO_SUSPEND users, so the drivers of wakeup
devices needing to use shared NO_SUSPEND interrupt lines for
signaling system wakeup generally have to detect wakeup in their
interrupt handlers.  Thus if they happen to share an interrupt line
with a NO_SUSPEND user, they also need to request that their
interrupt handlers be run after suspend_device_irqs().

In both cases the reason for using IRQF_NO_SUSPEND is not because
the driver in question has a genuine need to run its interrupt
handler after suspend_device_irqs(), but because it happens to
share the line with some other NO_SUSPEND user.  Otherwise, the
driver would do without IRQF_NO_SUSPEND just fine.

To make it possible to specify that condition explicitly, introduce
a new IRQ action handler flag for shared IRQs, IRQF_COND_SUSPEND,
that, when set, will indicate to the IRQ core that the interrupt
user is generally fine with suspending the IRQ, but it also can
tolerate handler invocations after suspend_device_irqs() and, in
particular, it is capable of detecting system wakeup and triggering
it as appropriate from its interrupt handler.

That will allow us to work around a problem with a shared timer
interrupt line on at91 platforms.

Link: http://marc.info/?l=linux-kernel&m=142252777602084&w=2
Link: http://marc.info/?t=142252775300011&r=1&w=2
Link: https://lkml.org/lkml/2014/12/15/552
Reported-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>

Merge tag 'dma-buf-for-4.0-rc3' of git://git./linux/kernel/git/sumits/dma-buf

Pull dma-buf fixes from Sumit Semwal:
 "Minor timeout & other fixes on reservation/fence"

* tag 'dma-buf-for-4.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf:
  reservation: Remove shadowing local variable 'ret'
  dma-buf/fence: don't wait when specified timeout is zero
  reservation: wait only with non-zero timeout specified (v3)

Merge git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull KVM fixes from Marcelo Tosatti:
 "KVM bug fixes, including a SVM interrupt injection regression fix,
  MIPS and ARM bug fixes"

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: MIPS: Enable after disabling interrupt
  KVM: MIPS: Fix trace event to save PC directly
  KVM: SVM: fix interrupt injection (apic->isr_count always 0)
  KVM: emulate: fix CMPXCHG8B on 32-bit hosts
  KVM: VMX: fix build without CONFIG_SMP
  arm/arm64: KVM: Add exit reaons to kvm_exit event tracing
  ARM: KVM: Fix size check in __coherent_cache_guest_page

Merge tag 'arc-4.0-fixes-1' of git://git./linux/kernel/git/vgupta/arc

Pull ARC fixes from Vineet Gupta:
 - Fix for /proc/<pid>/maps "stack" vma annotation
 - sched stats not printing correct sleeping task PC
 - perf not reporting page faults

* tag 'arc-4.0-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARC: Fix thread_saved_pc()
  ARC: Fix KSTK_ESP()
  ARC: perf: Enable generic software events
  ARC: Make arc_unwind_core accessible externally

ASoC: omap-pcm: Correct dma mask

DMA_BIT_MASK of 64 is not valid dma address mask for OMAPs, it should be
set to 32.
The 64 was introduced by commit (in 2009):
a152ff24b978 ASoC: OMAP: Make DMA 64 aligned

But the dma_mask and coherent_dma_mask can not be used to specify alignment.

Fixes: a152ff24b978 (ASoC: OMAP: Make DMA 64 aligned)
Reported-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Merge tag 'powerpc-4.0-2' of git://git./linux/kernel/git/mpe/linux

Pull powerpc fixes from Michael Ellerman:
 - Fix for dynticks.
 - Fix for smpboot bug.
 - Fix for IOMMU group refcounting.

* tag 'powerpc-4.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux:
  powerpc/iommu: Remove IOMMU device references via bus notifier
  powerpc/smp: Wait until secondaries are active & online
  powerpc: Re-enable dynticks

ACPI / video: Propagate the error code for acpi_video_register

Report the actual error code from acpi_bus_register_driver(), it may
help future debugging (typically ENODEV as previously reported, but the
unusual cases are where it may help most).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI / video: Load the module even if ACPI is disabled

i915.ko depends upon the acpi/video.ko module and so refuses to load if
ACPI is disabled at runtime if for example the BIOS is broken beyond
repair. acpi/video provides an optional service for i915.ko and so we
should just allow the modules to load, but do no nothing in order to let
the machines boot correctly.

Reported-by: Bill Augur <bill-auger@programmer.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Acked-by: Aaron Lu <aaron.lu@intel.com>
[ rjw: Fixed up the new comment in acpi_video_init() ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

PM / Domains: cleanup: rename gpd -> genpd in debugfs interface

To keep consisitency with the rest of the file, use 'genpd' as the
name of the 'struct generic_pm_domain' pointer instead of 'gpd'.

This is just a rename, no functional changes.

Signed-off-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: ppc: Add missing #include <asm/smp.h>

If CONFIG_SMP=n, <linux/smp.h> does not include <asm/smp.h>, causing:

drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugs

Some BIOSes report incorrect length for ACPI address space descriptors,
so relax the checks to avoid regressions. This issue has appeared several
times as:
 3162b6f0c5e1 ("PNPACPI: truncate _CRS windows with _LEN > _MAX - _MIN + 1")
 d558b483d5a7 ("x86/PCI: truncate _CRS windows with _LEN > _MAX - _MIN + 1")
 f238b414a74a ("PNPACPI: compute Address Space length rather than using _LEN")
 48728e077480 ("x86/PCI: compute Address Space length rather than using _LEN")

Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221
for more details and example malformed ACPI resource descriptors.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=94221
Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces ...)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Dave Airlie <airlied@redhat.com>
Tested-by: Prakash Punnoor <prakash@punnoor.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

x86/PCI/ACPI: Ignore resources consumed by host bridge itself

When parsing resources for PCI host bridge, we should ignore resources
consumed by host bridge itself and only report window resources available
to child PCI busses.

Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces ...)
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

dma: mmp-tdma: refine dma disable and dma-pos update

Below are the refinements.
1. Set DMA abort bit when disabling dma channel. This will clear
the remaining data in dma FIFO, to fix channel-swap issue.
2. Read DMA HW pointer when updating DMA status. Previously dma
position is calculated by adding one period size in dma interrupt.
This is inaccurate/insufficient for some high-quality audio APP.
Since interrupt bottom half handler has variable schedule delay,
it causes big error when calculating sample delay. Read the actual
HW pointer and feedback can improve the accuracy.
3. Do some minor code clean.

Signed-off-by: Qiao Zhou <zhouqiao@marvell.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>

drm/i915: gen4: work around hang during hibernation

Bjørn reported that his machine hang during hibernation and eventually
bisected the problem to the following commit:

commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak <imre.deak@intel.com>
Date:   Thu Oct 23 19:23:26 2014 +0300

    drm/i915: add poweroff_late handler

The problem seems to be that after the kernel puts the device into D3
the BIOS still tries to access it, or otherwise assumes that it's in D0.
This is clearly bogus, since ACPI mandates that devices are put into D3
by the OSPM if they are not wake-up sources. In the future we want to
unify more of the driver's runtime and system suspend paths, for example
by skipping all the system suspend/hibernation hooks if the device is
runtime suspended already. Accordingly for all other platforms the goal
is still to properly power down the device during hibernation.

v2:
- Another GEN4 Lenovo laptop had the same issue, while platforms from
  other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
  to work fine. Based on this apply the workaround on all GEN4 Lenovo
  platforms.
- add code comment about failing platforms (Ville)

Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
Reported-and-bisected-by: Bjørn Mork <bjorn@mork.no>
Cc: stable@vger.kernel.org # v3.19
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Check for driver readyness before handling an underrun interrupt

When we takeover from the BIOS and install our interrupt handler, the
BIOS may have left us a few surprises in the form of spontaneous
interrupts. (This is especially likely on hardware like 965gm where
display fifo underruns are continuous and the GMCH cannot filter that
interrupt souce.) As we enable our IRQ early so that we can use it
during hardware probing, our interrupt handler must be prepared to
handle a few sources prior to being fully configured. As such, we need
to add a simple is-ready check prior to dereferencing our KMS state for
reporting underruns.

Reported-by: Rob Clark <rclark@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
[Jani: dropped the extra !]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

NFSv4.1: Clear the old state by our client id before establishing a new lease

If the call to exchange-id returns with the EXCHGID4_FLAG_CONFIRMED_R flag
set, then that means our lease was established by a previous mount instance.
Ensure that we detect this situation, and that we clear the state held by
that mount.

Reported-by: Jorge Mora <Jorge.Mora@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>

powerpc/iommu: Remove IOMMU device references via bus notifier

After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
refcnt on the kobject backing the IOMMU group for a PCI device is
elevated by each call to pci_dma_dev_setup_pSeriesLP() (via
set_iommu_table_base_and_group). When we go to dlpar a multi-function
PCI device out:

        iommu_reconfig_notifier ->
                iommu_free_table ->
                        iommu_group_put
                        BUG_ON(tbl->it_group)

We trip this BUG_ON, because there are still references on the table, so
it is not freed. Fix this by moving the powernv bus notifier to common
code and calling it for both powernv and pseries.

Fixes: d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier")
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Tested-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

powerpc/smp: Wait until secondaries are active & online

Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
"kernel BUG at kernel/smpboot.c:134!" issue during boot:

  BUG_ON(td->cpu != smp_processor_id());

Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output confirms it:

  CPU: 0
  Comm: watchdog/130

The problem is that we aren't ensuring the CPU active bit is set for the
secondary before allowing the master to continue on. The master unparks
the secondary CPU's kthreads and the scheduler looks for a CPU to run
on. It calls select_task_rq() and realises the suggested CPU is not in
the cpus_allowed mask. It then ends up in select_fallback_rq(), and
since the active bit isnt't set we choose some other CPU to run on.

This seems to have been introduced by 6acbfb96976f "sched: Fix hotplug
vs. set_cpus_allowed_ptr()", which changed from setting active before
online to setting active after online. However that was in turn fixing a
bug where other code assumed an active CPU was also online, so we can't
just revert that fix.

The simplest fix is just to spin waiting for both active & online to be
set. We already have a barrier prior to set_cpu_online() (which also
sets active), to ensure all other setup is completed before online &
active are set.

Fixes: 6acbfb96976f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

NFSv4: Fix a race in NFSv4.1 server trunking discovery

We do not want to allow a race with another NFS mount to cause
nfs41_walk_client_list() to establish a lease on our nfs_client before
we're done checking for trunking.

Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>