Pull crypto fix from Herbert Xu:
 "This push fixes a potential panic in cryptd which may occur with
  crypto drivers such as aesni-intel."

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: cryptd - disable softirqs in cryptd_queue_worker to prevent data corruption

Pull sound fixes from Takashi Iwai:
 "Most of commits are for stable and regression fixes.  Except for one
  fix for a regression in 3.7-rc4, there are all driver local changes,
  so nothing too much to worry."

* tag 'sound-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: Fix card refcount unbalance
  ALSA: hda - Add new codec ALC668 and ALC900 (default name ALC1150)
  ALSA: hda - Improve HP depop when system enter to S3
  ALSA: usb-audio: Fix crash at re-preparing the PCM stream
  ALSA: hdspm - Fix sync check reporting on RME RayDAT
  ALSA: hda - Add pin fixups for ASUS G75
  ALSA: hda - Fix invalid connections in VT1802 codec
  ALSA: hda - Fix empty DAC filling in patch_via.c
  ALSA: hda - Force to reset IEC958 status bits for AD codecs
  ALSA: es1968: Add ESS vendor ID to pm_whitelist
  ALSA: HDA: Mark CS260x immutable structures const
  ALSA: HDA: Fix digital microphone on CS420x
  ALSA: hda: Cirrus: Fix coefficient index for beep configuration
  ALSA: hda - support Teradici 2200 host card audio
  ALSA: Fix typo in drivers sound

Merge tag 'pinctrl-for-v3.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

Pull pinctrl fixes from Linus Walleij:

 - A set of SPEAr pinctrl fixes that recently arrived

 - A fixup for the Samsung/Exynos Kconfig deps

* tag 'pinctrl-for-v3.7-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: samsung and exynos need to depend on OF && GPIOLIB
  pinctrl: SPEAr1340: Add clcd sleep mode pin configuration
  pinctrl: SPEAr1340: Make DDR reset & clock pads as gpio
  pinctrl: SPEAr1310: add register entries for enabling pad direction
  pinctrl: SPEAr1310: Separate out pci pins from pcie_sata pin group
  pinctrl: SPEAr1310: Fix value of PERIP_CFG reigster and MCIF_SEL_SHIFT
  pinctrl: SPEAr1310: fix clcd high resolution pin group name
  pinctrl: SPEAr320: Correct pad mux entries for rmii/smii
  pinctrl: SPEAr3xx: correct register space to configure pwm
  pinctrl: SPEAr: Don't update all non muxreg bits on pinctrl_disable

Pull s390 fixes from Martin Schwidefsky:
 "A couple of bug fixes.  I keep the fingers crossed that we now got
  transparent huge pages ready for prime time."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/cio: fix length calculation in idset.c
  s390/sclp: fix addressing mode clobber
  s390: Move css limits from drivers/s390/cio/ to include/asm/.
  s390/thp: respect page protection in pmd_none() and pmd_present()
  s390/mm: use pmd_large() instead of pmd_huge()
  s390/cio: suppress 2nd path verification during resume

Pull HID fix from Jiri Kosina:
 "This reverts a patch that causes regression in binding between HID
  devices and drivers during device unplug/replug cycle."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: hidraw: put old deallocation mechanism in place

Merge misc fixes from Andrew Morton:
 "Five fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (5 patches)
  h8300: add missing L1_CACHE_SHIFT
  mm: bugfix: set current->reclaim_state to NULL while returning from kswapd()
  fanotify: fix missing break
  revert "epoll: support for disabling items, and a self-test app"
  checkpatch: improve network block comment style checking

Pull drm fixes from Dave Airlie:
 "Just radeon and nouveau, mostly regressions fixers, and a couple of
  radeon register checker fixes."

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/nouveau: fix acpi edid retrieval
  drm/nvc0/disp: fix regression in vblank semaphore release
  drm/nv40/mpeg: fix context handling
  drm/nv40/graph: fix typo in type names
  drm/nv41/vm: fix typo in type name
  drm/radeon/si: add some missing regs to the VM reg checker
  drm/radeon/cayman: add some missing regs to the VM reg checker
  drm/radeon/dce3: switch back to old pll allocation order for discrete

Pull virtio and module fixes from Rusty Russell:
 "YA module signing build tweak, and two cc'd to stable."

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  virtio: Don't access index after unregister.
  modules: don't break modules_install on external modules with no key.
  module: fix out-by-one error in kallsyms

Pull xfs bugfixes from Ben Myers:

 - fix for large transactions spanning multiple iclog buffers

 - zero the allocation_args structure on the stack before using it to
   determine whether to use a worker for allocation
 - move allocation stack switch to xfs_bmapi_allocate in order to
   prevent deadlock on AGF buffers

 - growfs no longer reads in garbage for new secondary superblocks

 - silence a build warning

 - ensure that invalid buffers never get written to disk while on free
   list

 - don't vmap inode cluster buffers during free

 - fix buffer shutdown reference count mismatch

 - fix reading of wrapped log data

* tag 'for-linus-v3.7-rc5' of git://oss.sgi.com/xfs/xfs:
  xfs: fix reading of wrapped log data
  xfs: fix buffer shudown reference count mismatch
  xfs: don't vmap inode cluster buffers during free
  xfs: invalidate allocbt blocks moved to the free list
  xfs: silence uninitialised f.file warning.
  xfs: growfs: don't read garbage for new secondary superblocks
  xfs: move allocation stack switch up to xfs_bmapi_allocate
  xfs: introduce XFS_BMAPI_STACK_SWITCH
  xfs: zero allocation_args on the kernel stack
  xfs: only update the last_sync_lsn when a transaction completes

Fix the build error

  lib/atomic64.c: In function 'lock_addr':
  lib/atomic64.c:40:11: error: 'L1_CACHE_SHIFT' undeclared (first use in this function)
  lib/atomic64.c:40:11: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In kswapd(), set current->reclaim_state to NULL before returning, as
current->reclaim_state holds reference to variable on kswapd()'s stack.

In rare cases, while returning from kswapd() during memory offlining,
__free_slab() and freepages() can access the dangling pointer of
current->reclaim_state.
Signed-off-by: NTakamori Yamaguchi <takamori.yamaguchi@jp.sony.com>
Signed-off-by: NAaditya Kumar <aaditya.kumar@ap.sony.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Anders Blomdell noted in 2010 that Fanotify lost events and provided a
test case.  Eric Paris confirmed it was a bug and posted a fix to the
list

  https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/RrJfTfyW2BE

but never applied it.  Repeated attempts over time to actually get him
to apply it have never had a reply from anyone who has raised it

So apply it anyway
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Reported-by: NAnders Blomdell <anders.blomdell@control.lth.se>
Cc: Eric Paris <eparis@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Revert commit 03a7beb5 ("epoll: support for disabling items, and a
self-test app") pending resolution of the issues identified by Michael
Kerrisk, copied below.

We'll revisit this for 3.8.

: I've taken a look at this patch as it currently stands in 3.7-rc1, and
: done a bit of testing. (By the way, the test program
: tools/testing/selftests/epoll/test_epoll.c does not compile...)
:
: There are one or two places where the behavior seems a little strange,
: so I have a question or two at the end of this mail. But other than
: that, I want to check my understanding so that the interface can be
: correctly documented.
:
: Just to go though my understanding, the problem is the following
: scenario in a multithreaded application:
:
: 1. Multiple threads are performing epoll_wait() operations,
:    and maintaining a user-space cache that contains information
:    corresponding to each file descriptor being monitored by
:    epoll_wait().
:
: 2. At some point, a thread wants to delete (EPOLL_CTL_DEL)
:    a file descriptor from the epoll interest list, and
:    delete the corresponding record from the user-space cache.
:
: 3. The problem with (2) is that some other thread may have
:    previously done an epoll_wait() that retrieved information
:    about the fd in question, and may be in the middle of using
:    information in the cache that relates to that fd. Thus,
:    there is a potential race.
:
: 4. The race can't solved purely in user space, because doing
:    so would require applying a mutex across the epoll_wait()
:    call, which would of course blow thread concurrency.
:
: Right?
:
: Your solution is the EPOLL_CTL_DISABLE operation. I want to
: confirm my understanding about how to use this flag, since
: the description that has accompanied the patches so far
: has been a bit sparse
:
: 0. In the scenario you're concerned about, deleting a file
:    descriptor means (safely) doing the following:
:    (a) Deleting the file descriptor from the epoll interest list
:        using EPOLL_CTL_DEL
:    (b) Deleting the corresponding record in the user-space cache
:
: 1. It's only meaningful to use this EPOLL_CTL_DISABLE in
:    conjunction with EPOLLONESHOT.
:
: 2. Using EPOLL_CTL_DISABLE without using EPOLLONESHOT in
:    conjunction is a logical error.
:
: 3. The correct way to code multithreaded applications using
:    EPOLL_CTL_DISABLE and EPOLLONESHOT is as follows:
:
:    a. All EPOLL_CTL_ADD and EPOLL_CTL_MOD operations should
:       should EPOLLONESHOT.
:
:    b. When a thread wants to delete a file descriptor, it
:       should do the following:
:
:       [1] Call epoll_ctl(EPOLL_CTL_DISABLE)
:       [2] If the return status from epoll_ctl(EPOLL_CTL_DISABLE)
:           was zero, then the file descriptor can be safely
:           deleted by the thread that made this call.
:       [3] If the epoll_ctl(EPOLL_CTL_DISABLE) fails with EBUSY,
:           then the descriptor is in use. In this case, the calling
:           thread should set a flag in the user-space cache to
:           indicate that the thread that is using the descriptor
:           should perform the deletion operation.
:
: Is all of the above correct?
:
: The implementation depends on checking on whether
: (events & ~EP_PRIVATE_BITS) == 0
: This replies on the fact that EPOLL_CTL_AD and EPOLL_CTL_MOD always
: set EPOLLHUP and EPOLLERR in the 'events' mask, and EPOLLONESHOT
: causes those flags (as well as all others in ~EP_PRIVATE_BITS) to be
: cleared.
:
: A corollary to the previous paragraph is that using EPOLL_CTL_DISABLE
: is only useful in conjunction with EPOLLONESHOT. However, as things
: stand, one can use EPOLL_CTL_DISABLE on a file descriptor that does
: not have EPOLLONESHOT set in 'events' This results in the following
: (slightly surprising) behavior:
:
: (a) The first call to epoll_ctl(EPOLL_CTL_DISABLE) returns 0
:     (the indicator that the file descriptor can be safely deleted).
: (b) The next call to epoll_ctl(EPOLL_CTL_DISABLE) fails with EBUSY.
:
: This doesn't seem particularly useful, and in fact is probably an
: indication that the user made a logic error: they should only be using
: epoll_ctl(EPOLL_CTL_DISABLE) on a file descriptor for which
: EPOLLONESHOT was set in 'events'. If that is correct, then would it
: not make sense to return an error to user space for this case?

Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: "Paton J. Lewis" <palewis@adobe.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some comment styles in net and drivers/net are flagged inappropriately.

Avoid proclaiming inline comments like:
	int a = b;	/* some comment */
and block comments like:
	/*********************
	 * some comment
	 ********************/
are defective.

Tested with
$ cat drivers/net/t.c
/* foo */

/*
 * foo
 */

/* foo
 */

/* foo
 * bar */

/****************************
 * some long block comment
 ***************************/

struct foo {
	int bar;	/* another test */
};
$
Signed-off-by: NJoe Perches <joe@perches.com>
Reported-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: David Miller <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge branch 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

just some misc regression fixes and typo fixes.

* 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
  drm/nouveau: fix acpi edid retrieval
  drm/nvc0/disp: fix regression in vblank semaphore release
  drm/nv40/mpeg: fix context handling
  drm/nv40/graph: fix typo in type names
  drm/nv41/vm: fix typo in type name

Virtio wants to release used indices after the corresponding
virtio device has been unregistered. However, virtio does not
hold an extra reference, giving up its last reference with
device_unregister(), making accessing dev->index afterwards
invalid.

I actually saw problems when testing my (not-yet-merged)
virtio-ccw code:

- device_add virtio-net,id=xxx
-> creates device virtio<n> with n>0

- device_del xxx
-> deletes virtio<n>, but calls ida_simple_remove with an
   index of 0

- device_add virtio-net,id=xxx
-> tries to add virtio0, which is still in use...

So let's save the index we want to release before calling
device_unregister().
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Acked-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
Cc: stable@kernel.org
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Commit c0077061 accidentally inverted the logic for nouveau_acpi_edid,
causing it to only show a connector as connected when the edid could not
be retrieved with acpi.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NKelly Doran <kel.p.doran@gmail.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It slipped in thanks to typeless API.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nv04_graph_priv / nv04_graph_chan are not defined in this context...
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It's a miracle it compiles at all - nv04_vm_priv does not exist
anywhere in the tree.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Just some minor fixes for VM reg check and a regression fix for dce3 plls

* 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon/si: add some missing regs to the VM reg checker
  drm/radeon/cayman: add some missing regs to the VM reg checker
  drm/radeon/dce3: switch back to old pll allocation order for discrete

Commit 44396476 ("xfs: reset buffer pointers before freeing them") in
3.0-rc1 introduced a regression when recovering log buffers that
wrapped around the end of log. The second part of the log buffer at
the start of the physical log was being read into the header buffer
rather than the data buffer, and hence recovery was seeing garbage
in the data buffer when it got to the region of the log buffer that
was incorrectly read.

Cc: <stable@vger.kernel.org> # 3.0.x, 3.2.x, 3.4.x 3.6.x
Reported-by: NTorsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

When we shut down the filesystem, we have to unpin and free all the
buffers currently active in the CIL. To do this we unpin and remove
them in one operation as a result of a failed iclogbuf write. For
buffers, we do this removal via a simultated IO completion of after
marking the buffer stale.

At the time we do this, we have two references to the buffer - the
active LRU reference and the buf log item.  The LRU reference is
removed by marking the buffer stale, and the active CIL reference is
by the xfs_buf_iodone() callback that is run by
xfs_buf_do_callbacks() during ioend processing (via the bp->b_iodone
callback).

However, ioend processing requires one more reference - that of the
IO that it is completing. We don't have this reference, so we free
the buffer prematurely and use it after it is freed. For buffers
marked with XBF_ASYNC, this leads to assert failures in
xfs_buf_rele() on debug kernels because the b_hold count is zero.

Fix this by making sure we take the necessary IO reference before
starting IO completion processing on the stale buffer, and set the
XBF_ASYNC flag to ensure that IO completion processing removes all
the active references from the buffer to ensure it is fully torn
down.

Cc: <stable@vger.kernel.org>
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

Inode buffers do not need to be mapped as inodes are read or written
directly from/to the pages underlying the buffer. This fixes a
regression introduced by commit 611c9946 ("xfs: make XBF_MAPPED the
default behaviour").
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

When we free a block from the alloc btree tree, we move it to the
freelist held in the AGFL and mark it busy in the busy extent tree.
This typically happens when we merge btree blocks.

Once the transaction is committed and checkpointed, the block can
remain on the free list for an indefinite amount of time.  Now, this
isn't the end of the world at this point - if the free list is
shortened, the buffer is invalidated in the transaction that moves
it back to free space. If the buffer is allocated as metadata from
the free list, then all the modifications getted logged, and we have
no issues, either. And if it gets allocated as userdata direct from
the freelist, it gets invalidated and so will never get written.

However, during the time it sits on the free list, pressure on the
log can cause the AIL to be pushed and the buffer that covers the
block gets pushed for write. IOWs, we end up writing a freed
metadata block to disk. Again, this isn't the end of the world
because we know from the above we are only writing to free space.

The problem, however, is for validation callbacks. If the block was
on old btree root block, then the level of the block is going to be
higher than the current tree root, and so will fail validation.
There may be other inconsistencies in the block as well, and
currently we don't care because the block is in free space. Shutting
down the filesystem because a freed block doesn't pass write
validation, OTOH, is rather unfriendly.

So, make sure we always invalidate buffers as they move from the
free space trees to the free list so that we guarantee they never
get written to disk while on the free list.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NPhil White <pwhite@sgi.com>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

Uninitialised variable build warning introduced by 2903ff01 ("switch
simple cases of fget_light to fdget"), gcc is not smart enough to
work out that the variable is not used uninitialised, and the commit
removed the initialisation at declaration that the old variable had.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

When updating new secondary superblocks in a growfs operation, the
superblock buffer is read from the newly grown region of the
underlying device. This is not guaranteed to be zero, so violates
the underlying assumption that the unused parts of superblocks are
zero filled. Get a new buffer for these secondary superblocks to
ensure that the unused regions are zero filled correctly.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NCarlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

Switching stacks are xfs_alloc_vextent can cause deadlocks when we
run out of worker threads on the allocation workqueue. This can
occur because xfs_bmap_btalloc can make multiple calls to
xfs_alloc_vextent() and even if xfs_alloc_vextent() fails it can
return with the AGF locked in the current allocation transaction.

If we then need to make another allocation, and all the allocation
worker contexts are exhausted because the are blocked waiting for
the AGF lock, holder of the AGF cannot get it's xfs-alloc_vextent
work completed to release the AGF.  Hence allocation effectively
deadlocks.

To avoid this, move the stack switch one layer up to
xfs_bmapi_allocate() so that all of the allocation attempts in a
single switched stack transaction occur in a single worker context.
This avoids the problem of an allocation being blocked waiting for
a worker thread whilst holding the AGF.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

Certain allocation paths through xfs_bmapi_write() are in situations
where we have limited stack available. These are almost always in
the buffered IO writeback path when convertion delayed allocation
extents to real extents.

The current stack switch occurs for userdata allocations, which
means we also do stack switches for preallocation, direct IO and
unwritten extent conversion, even those these call chains have never
been implicated in a stack overrun.

Hence, let's target just the single stack overun offended for stack
switches. To do that, introduce a XFS_BMAPI_STACK_SWITCH flag that
the caller can pass xfs_bmapi_write() to indicate it should switch
stacks if it needs to do allocation.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

Zero the kernel stack space that makes up the xfs_alloc_arg structures.
Signed-off-by: NMark Tinguely <tinguely@sgi.com>
Reviewed-by: NBen Myers <bpm@sgi.com>
Signed-off-by: NBen Myers <bpm@sgi.com>

The log write code stamps each iclog with the current tail LSN in
the iclog header so that recovery knows where to find the tail of
thelog once it has found the head. Normally this is taken from the
first item on the AIL - the log item that corresponds to the oldest
active item in the log.

The problem is that when the AIL is empty, the tail lsn is dervied
from the the l_last_sync_lsn, which is the LSN of the last iclog to
be written to the log. In most cases this doesn't happen, because
the AIL is rarely empty on an active filesystem. However, when it
does, it opens up an interesting case when the transaction being
committed to the iclog spans multiple iclogs.

That is, the first iclog is stamped with the l_last_sync_lsn, and IO
is issued. Then the next iclog is setup, the changes copied into the
iclog (takes some time), and then the l_last_sync_lsn is stamped
into the header and IO is issued. This is still the same
transaction, so the tail lsn of both iclogs must be the same for log
recovery to find the entire transaction to be able to replay it.

The problem arises in that the iclog buffer IO completion updates
the l_last_sync_lsn with it's own LSN. Therefore, If the first iclog
completes it's IO before the second iclog is filled and has the tail
lsn stamped in it, it will stamp the LSN of the first iclog into
it's tail lsn field. If the system fails at this point, log recovery
will not see a complete transaction, so the transaction will no be
replayed.

The fix is simple - the l_last_sync_lsn is updated when a iclog
buffer IO completes, and this is incorrect. The l_last_sync_lsn
shoul dbe updated when a transaction is completed by a iclog buffer
IO. That is, only iclog buffers that have transaction commit
callbacks attached to them should update the l_last_sync_lsn. This
means that the last_sync_lsn will only move forward when a commit
record it written, not in the middle of a large transaction that is
rolling through multiple iclog buffers.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NMark Tinguely <tinguely@sgi.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NBen Myers <bpm@sgi.com>

This register is needed for streamout to work properly.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>

These regs were being wronly rejected leading to rendering
issues.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=56876Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>

There are uncovered cases whether the card refcount introduced by the
commit a0830dbd isn't properly increased or decreased:
- OSS PCM and mixer success paths
- When lookup function gets NULL

This patch fixes these places.

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

Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

alc269_toggle_power_output() was only use in ALC269VB.  I rename it to
alc269vb_toggle_power_output().
Signed-off-by: NKailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

There are bug reports of a crash with USB-audio devices when PCM
prepare is performed immediately after the stream is stopped via
trigger callback.  It turned out that the problem is that we don't
wait until all URBs are killed.

This patch adds a new function to synchronize the pending stop
operation on an endpoint, and calls in the prepare callback for
avoiding the crash above.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=49181Reported-and-tested-by: NArtem S. Tashkinov <t.artem@lycos.com>
Cc: <stable@vger.kernel.org> [v3.6]
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The RayDAT reports the sync status of its inputs in consecutive bit
positions, so all we do in hdspm_s1_sync_check is to iterate over idx:

    status = hdspm_read(hdspm, HDSPM_RD_STATUS_1);

    lock = (status & (0x1<<idx)) ? 1 : 0;
    sync = (status & (0x100<<idx)) ? 1 : 0;

The index is given in kcontrol->private_value:

    HDSPM_SYNC_CHECK("WC SyncCheck", 0),
    HDSPM_SYNC_CHECK("AES SyncCheck", 1),
    HDSPM_SYNC_CHECK("SPDIF SyncCheck", 2),
    HDSPM_SYNC_CHECK("ADAT1 SyncCheck", 3),
    HDSPM_SYNC_CHECK("ADAT2 SyncCheck", 4),
    HDSPM_SYNC_CHECK("ADAT3 SyncCheck", 5),
    HDSPM_SYNC_CHECK("ADAT4 SyncCheck", 6),
    HDSPM_SYNC_CHECK("TCO SyncCheck", 7),
    HDSPM_SYNC_CHECK("SYNC IN SyncCheck", 8),

The patch corrects the indicated sync flags by passing the proper index
value to hdspm_s1_sync_check().
Signed-off-by: NAdrian Knoth <adi@drcomp.erfurt.thur.de>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>

The order shouldn't matter, but this seems to cause regressions for
certain specific cases.  This should fix it for now.  We probably
need to investigate a proper fix in the next development cycle.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Andy Furniss <andyqos@ukfsn.org>