Commit Graph

391996 Commits

Author SHA1 Message Date
Laurent Pinchart
9344dade4f pwm: Add PWM polarity flag macro for DT
Define a PWM_POLARITY_INVERTED macro in include/dt-bindings/pwm/pwm.h to
be used by device tree sources.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2013-09-03 13:08:09 +02:00
Fabio Estevam
cfb9e4c40e pwm: mxs: Check the return value from stmp_reset_block()
stmp_reset_block() may fail, so let's check its return value and
propagate it in the case of error.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2013-09-03 13:07:51 +02:00
Linus Torvalds
6e4664525b Linux 3.11 2013-09-02 13:46:10 -07:00
Linus Torvalds
bc08b449ee lockref: implement lockless reference count updates using cmpxchg()
Instead of taking the spinlock, the lockless versions atomically check
that the lock is not taken, and do the reference count update using a
cmpxchg() loop.  This is semantically identical to doing the reference
count update protected by the lock, but avoids the "wait for lock"
contention that you get when accesses to the reference count are
contended.

Note that a "lockref" is absolutely _not_ equivalent to an atomic_t.
Even when the lockref reference counts are updated atomically with
cmpxchg, the fact that they also verify the state of the spinlock means
that the lockless updates can never happen while somebody else holds the
spinlock.

So while "lockref_put_or_lock()" looks a lot like just another name for
"atomic_dec_and_lock()", and both optimize to lockless updates, they are
fundamentally different: the decrement done by atomic_dec_and_lock() is
truly independent of any lock (as long as it doesn't decrement to zero),
so a locked region can still see the count change.

The lockref structure, in contrast, really is a *locked* reference
count.  If you hold the spinlock, the reference count will be stable and
you can modify the reference count without using atomics, because even
the lockless updates will see and respect the state of the lock.

In order to enable the cmpxchg lockless code, the architecture needs to
do three things:

 (1) Make sure that the "arch_spinlock_t" and an "unsigned int" can fit
     in an aligned u64, and have a "cmpxchg()" implementation that works
     on such a u64 data type.

 (2) define a helper function to test for a spinlock being unlocked
     ("arch_spin_value_unlocked()")

 (3) select the "ARCH_USE_CMPXCHG_LOCKREF" config variable in its
     Kconfig file.

This enables it for x86-64 (but not 32-bit, we'd need to make sure
cmpxchg() turns into the proper cmpxchg8b in order to enable it for
32-bit mode).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-02 12:12:15 -07:00
Linus Torvalds
2f4f12e571 lockref: uninline lockref helper functions
They aren't very good to inline, since they already call external
functions (the spinlock code), and we're going to create rather more
complicated versions of them that can do the reference count updates
locklessly.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-02 11:58:20 -07:00
Linus Torvalds
15570086b5 vfs: reimplement d_rcu_to_refcount() using lockref_get_or_lock()
This moves __d_rcu_to_refcount() from <linux/dcache.h> into fs/namei.c
and re-implements it using the lockref infrastructure instead.  It also
adds a lot of comments about what is actually going on, because turning
a dentry that was looked up using RCU into a long-lived reference
counted entry is one of the more subtle parts of the rcu walk.

We also used to be _particularly_ subtle in unlazy_walk() where we
re-validate both the dentry and its parent using the same sequence
count.  We used to do it by nesting the locks and then verifying the
sequence count just once.

That was silly, because nested locking is expensive, but the sequence
count check is not.  So this just re-validates the dentry and the parent
separately, avoiding the nested locking, and making the lockref lookup
possible.

Acked-by: Waiman Long <waiman.long@hp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-02 11:38:06 -07:00
Waiman Long
df3d0bbcdb vfs: use lockref_get_not_zero() for optimistic lockless dget_parent()
A valid parent pointer is always going to have a non-zero reference
count, but if we look up the parent optimistically without locking, we
have to protect against the (very unlikely) race against renaming
changing the parent from under us.

We do that by using lockref_get_not_zero(), and then re-checking the
parent pointer after getting a valid reference.

[ This is a re-implementation of a chunk from the original patch by
  Waiman Long: "dcache: Enable lockless update of dentry's refcount".
  I've completely rewritten the patch-series and split it up, but I'm
  attributing this part to Waiman as it's close enough to his earlier
  patch  - Linus ]

Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-02 11:29:22 -07:00
Linus Torvalds
b3abd80250 lockref: add 'lockref_get_or_lock() helper
This behaves like "lockref_get_not_zero()", but instead of doing nothing
if the count was zero, it returns with the lock held.

This allows callers to revalidate the lockref-protected data structure
if required even if the count was zero to begin with, and possibly
increment the count if it passes muster.

In particular, the dentry code wants this when it wants to turn an
RCU-protected dentry into a stable refcounted one: if the dentry count
it zero, but the sequence number still validates the dentry, we can take
a reference to it.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-02 11:14:19 -07:00
Linus Torvalds
248d296d6d SCSI fixes on 20130831
This is a bug fix for the pm80xx driver.  It turns out that when the new
 hardware support was added in 3.10 the IO command size was kept at the old
 hard coded value.  This means that the driver attaches to some new cards and
 then simply hangs the system.
 
 Signed-off-by: James Bottomley <JBottomley@Parallels.com>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQEcBAABAgAGBQJSIh8wAAoJEDeqqVYsXL0MCOIH/3Ii/4xKN7BK/G7UYVj7QuIu
 lxmshuc6FUJJkg4fZiV3oHQgkYiUoOOYTVWg+rEKycE1XZS8b3E5BVTlM2+NHezo
 OcjFmctDb5HrElbBL7BrsJwNwSeSL+ATZEqPuOoXQ+CIJ9pkFwm3u1ernDLsM0bB
 PuDRn1duAbyUscHNqYsInpg2a21F1cuoLIzz/ziHgXtjRre30An2wZjmNVwDKeaY
 UhnCvjUy37LFFWL3mLVaS0fhkCS484uKRyloX0FJdLgtfzGvOFGF01f02gmcziti
 o0+PqIhV2wPvGpiNea761JN5opxc/IhhhPapR0kaj9Qig79TP9wjEZ8ynnQvvG4=
 =i73i
 -----END PGP SIGNATURE-----

Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

Pull SCSI fix from James Bottomley:
 "This is a bug fix for the pm80xx driver.  It turns out that when the
  new hardware support was added in 3.10 the IO command size was kept at
  the old hard coded value.  This means that the driver attaches to some
  new cards and then simply hangs the system"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  [SCSI] pm80xx: fix Adaptec 71605H hang
2013-09-02 10:43:13 -07:00
Linus Torvalds
e09a1fa9be Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 boot fix from Peter Anvin:
 "A single very small boot fix for very large memory systems (> 0.5T)"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm: Fix boot crash with DEBUG_PAGE_ALLOC=y and more than 512G RAM
2013-09-02 09:55:14 -07:00
Linus Torvalds
ac0bc7899a Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma
Pull slave-dma fix from Vinod Koul:
 "A fix for resolving TI_EDMA driver's build error in allmodconfig to
  have filter function built in""

* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
  dma/Kconfig: TI_EDMA needs to be boolean
2013-09-02 09:54:06 -07:00
Mark Brown
a584862221 Merge remote-tracking branch 'regulator/topic/tps65912' into regulator-next 2013-09-01 13:50:23 +01:00
Mark Brown
2d31b15b86 Merge remote-tracking branch 'regulator/topic/ti-abb' into regulator-next 2013-09-01 13:50:22 +01:00
Mark Brown
04fcec88cd Merge remote-tracking branch 'regulator/topic/sec' into regulator-next 2013-09-01 13:50:21 +01:00
Mark Brown
a89f5c7598 Merge remote-tracking branch 'regulator/topic/ramp' into regulator-next 2013-09-01 13:50:20 +01:00
Mark Brown
09f2dd88ff Merge remote-tracking branch 'regulator/topic/pfuze100' into regulator-next 2013-09-01 13:50:18 +01:00
Mark Brown
39fe3b45d3 Merge remote-tracking branch 'regulator/topic/palmas' into regulator-next 2013-09-01 13:50:17 +01:00
Mark Brown
f27a5fb424 Merge remote-tracking branch 'regulator/topic/optional' into regulator-next 2013-09-01 13:50:17 +01:00
Mark Brown
6979380d85 Merge remote-tracking branch 'regulator/topic/max8660' into regulator-next 2013-09-01 13:50:16 +01:00
Mark Brown
3aba952706 Merge remote-tracking branch 'regulator/topic/lp8755' into regulator-next 2013-09-01 13:50:14 +01:00
Mark Brown
882e3dba4c Merge remote-tracking branch 'regulator/topic/lp872x' into regulator-next 2013-09-01 13:50:13 +01:00
Mark Brown
bca3523b22 Merge remote-tracking branch 'regulator/topic/linear-range' into regulator-next 2013-09-01 13:50:12 +01:00
Mark Brown
099c606224 Merge remote-tracking branch 'regulator/topic/kconfig' into regulator-next 2013-09-01 13:50:11 +01:00
Mark Brown
724d054490 Merge remote-tracking branch 'regulator/topic/helpers' into regulator-next 2013-09-01 13:50:09 +01:00
Mark Brown
446b4665e3 Merge remote-tracking branch 'regulator/topic/fan53555' into regulator-next 2013-09-01 13:50:08 +01:00
Mark Brown
62696579a0 Merge remote-tracking branch 'regulator/topic/da9063' into regulator-next 2013-09-01 13:50:07 +01:00
Mark Brown
1ad13028e5 Merge remote-tracking branch 'regulator/topic/core' into regulator-next 2013-09-01 13:50:06 +01:00
Mark Brown
5288be36cd Merge remote-tracking branch 'regulator/topic/as3711' into regulator-next 2013-09-01 13:50:05 +01:00
Mark Brown
28c37c9ce8 Merge remote-tracking branch 'regulator/topic/88pm800' into regulator-next 2013-09-01 13:50:04 +01:00
Mark Brown
5787392598 Merge remote-tracking branch 'spi/topic/txx9' into spi-next 2013-09-01 13:49:18 +01:00
Mark Brown
961722f57c Merge remote-tracking branch 'spi/topic/topcliff' into spi-next 2013-09-01 13:49:17 +01:00
Mark Brown
989e694647 Merge remote-tracking branch 'spi/topic/tle62x0' into spi-next 2013-09-01 13:49:15 +01:00
Mark Brown
58737f127a Merge remote-tracking branch 'spi/topic/tel62x0' into spi-next 2013-09-01 13:49:14 +01:00
Mark Brown
e7c57cc124 Merge remote-tracking branch 'spi/topic/tegra' into spi-next 2013-09-01 13:49:13 +01:00
Mark Brown
a3e412dcf5 Merge remote-tracking branch 'spi/topic/sirf' into spi-next 2013-09-01 13:49:12 +01:00
Mark Brown
368ce0bca4 Merge remote-tracking branch 'spi/topic/sh-msiof' into spi-next 2013-09-01 13:49:11 +01:00
Mark Brown
874915ed4b Merge remote-tracking branch 'spi/topic/sh-hspi' into spi-next 2013-09-01 13:49:10 +01:00
Mark Brown
2dc745b6ef Merge remote-tracking branch 'spi/topic/s3c64xx' into spi-next 2013-09-01 13:49:09 +01:00
Mark Brown
121a39661b Merge remote-tracking branch 'spi/topic/rspi' into spi-next 2013-09-01 13:49:08 +01:00
Mark Brown
278ac33bbd Merge remote-tracking branch 'spi/topic/quad' into spi-next 2013-09-01 13:49:07 +01:00
Mark Brown
85cac43132 Merge remote-tracking branch 'spi/topic/qspi' into spi-next 2013-09-01 13:49:06 +01:00
Mark Brown
793b3cb6ac Merge remote-tracking branch 'spi/topic/pxa' into spi-next 2013-09-01 13:49:05 +01:00
Mark Brown
720ed2d130 Merge remote-tracking branch 'spi/topic/pl022' into spi-next 2013-09-01 13:49:04 +01:00
Mark Brown
68aa4cb337 Merge remote-tracking branch 'spi/topic/pdata' into spi-next 2013-09-01 13:49:03 +01:00
Mark Brown
11c28cfc1e Merge remote-tracking branch 'spi/topic/orion' into spi-next 2013-09-01 13:49:02 +01:00
Mark Brown
4374f332d9 Merge remote-tracking branch 'spi/topic/omap-100k' into spi-next 2013-09-01 13:49:01 +01:00
Mark Brown
45bb5065e1 Merge remote-tracking branch 'spi/topic/octeon' into spi-next 2013-09-01 13:49:00 +01:00
Mark Brown
455765f02e Merge remote-tracking branch 'spi/topic/nuc900' into spi-next 2013-09-01 13:48:59 +01:00
Mark Brown
7c2fde9b1a Merge remote-tracking branch 'spi/topic/mxs' into spi-next 2013-09-01 13:48:59 +01:00
Mark Brown
9020b75467 Merge remote-tracking branch 'spi/topic/msglen' into spi-next 2013-09-01 13:48:58 +01:00