lp8788-charger: Fix kconfig dependency

Fix build errors in lp8788-charger by making it depend on IIO.
Fixes errors when CONFIG_IIO=m and CHARGER_LP8788=y.

lp8788-charger.c:(.text+0x2146b5): undefined reference to `iio_channel_get'
lp8788-charger.c:(.text+0x2146ce): undefined reference to `iio_channel_get'
lp8788-charger.c:(.text+0x214a86): undefined reference to `iio_read_channel_processed'
lp8788-charger.c:(.text+0x214b51): undefined reference to `iio_read_channel_processed'
lp8788-charger.c:(.text+0x214c30): undefined reference to `iio_read_channel_processed'
lp8788-charger.c:(.text+0x214d93): undefined reference to `iio_channel_release'
lp8788-charger.c:(.text+0x214dac): undefined reference to `iio_channel_release'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
bq27x00: Fix I2C dependency in KConfig

This patch fixes build failure(randconfig) of next-20130501. When config
I2C as m, BATTERY_BQ27x00 as y, here comes the failure. The driver depends
on I2C only if I2C is not disabled, as Lars commented. Last version of
this patch make the driver depend on I2C unconditionally.

Failure message:
drivers/built-in.o: In function `bq27x00_read_i2c':
bq27x00_battery.c:(.text+0x1082a7): undefined reference to `i2c_transfer'
drivers/built-in.o: In function `bq27x00_battery_init':
bq27x00_battery.c:(.init.text+0x6085): undefined reference to `i2c_register_driver'
bq27x00_battery.c:(.init.text+0x60c7): undefined reference to `i2c_del_driver'
drivers/built-in.o: In function `bq27x00_battery_exit':
bq27x00_battery.c:(.exit.text+0xbf0): undefined reference to `i2c_del_driver'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou <jencce.kernel@gmail.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
wm831x_backup: Fix wrong kfree call for devdata->backup.name

devdata->backup.name points to devdata->name, the memory for devdata->name
is part of struct wm831x_backup. Thus remove kfree call for
devdata->backup.name.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
pm2301_charger: Fix module alias prefix

This driver is a i2c driver, use "i2c" rather than "platform" prefix for
module alias.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Anton Vorontsov <anton@enomsg.org>
crypto: caam - fix inconsistent assoc dma mapping direction

req->assoc is dma mapped BIDIRECTIONAL and unmapped TO_DEVICE.
Since it is read-only for the device, use TO_DEVICE both for mapping
and unmapping.

Cc: <stable@vger.kernel.org> # 3.9, 3.8
Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
dma: acpi-dma: parse CSRT to extract additional resources

Since we have CSRT only to get additional DMA controller resources, let's get
rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
ACPI / LPSS: register clock device for Lynxpoint DMA properly

The DMA controller in Lynxpoint is enumerated as a regular ACPI device now. To
work properly it is using the LPSS root clock as a functional clock. That's why
we have to register the clock device accordingly to the ACPI ID of the DMA
controller. The acpi_lpss.c module is responsible to do the job.

This patch also removes hardcoded name of the DMA device in clk-lpt.c and the
name of the root clock in acpi_lpss.c.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
microblaze: Initialize temp variable to remove compilation warning

Compilation warning:
arch/microblaze/kernel/cpu/cache.c:148:2: warning:
 'temp' is used uninitialized in this function [-Wuninitialized]

Signed-off-by: Michal Simek <michal.simek@xilinx.com>
SUNRPC: Fix a bug in gss_create_upcall

If wait_event_interruptible_timeout() is successful, it returns
the number of seconds remaining until the timeout. In that
case, we should be retrying the upcall.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: Faster detection if gssd is actually running

Recent changes to the NFS security flavour negotiation mean that
we have a stronger dependency on rpc.gssd. If the latter is not
running, because the user failed to start it, then we time out
and mark the container as not having an instance. We then
use that information to time out faster the next time.

If, on the other hand, the rpc.gssd successfully binds to an rpc_pipe,
then we mark the container as having an rpc.gssd instance.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
SUNRPC: Convert auth_gss pipe detection to work in namespaces

This seems to have been overlooked when we did the namespace
conversion. If a container is running a legacy version of rpc.gssd
then it will be disrupted if the global 'pipe_version' is set by a
container running the new version of rpc.gssd.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
NFSv4.1 Fix a pNFS session draining deadlock

On a CB_RECALL the callback service thread flushes the inode using
filemap_flush prior to scheduling the state manager thread to return the
delegation. When pNFS is used and I/O has not yet gone to the data server
servicing the inode, a LAYOUTGET can preceed the I/O. Unlike the async
filemap_flush call, the LAYOUTGET must proceed to completion.

If the state manager starts to recover data while the inode flush is sending
the LAYOUTGET, a deadlock occurs as the callback service thread holds the
single callback session slot until the flushing is done which blocks the state
manager thread, and the state manager thread has set the session draining bit
which puts the inode flush LAYOUTGET RPC to sleep on the forechannel slot
table waitq.

Separate the draining of the back channel from the draining of the fore channel
by moving the NFS4_SESSION_DRAINING bit from session scope into the fore
and back slot tables.  Drain the back channel first allowing the LAYOUTGET
call to proceed (and fail) so the callback service thread frees the callback
slot. Then proceed with draining the forechannel.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
amd64_edac: Fix bogus sysfs file permissions

Fix yet another issue caught by 8f46baaa7ec6c ("base: core: WARN() about
bogus permissions on device attributes").

Signed-off-by: Borislav Petkov <bp@suse.de>
drm/i915: Adding more reserved PCI IDs for Haswell.

At DDX commit Chris mentioned the tendency we have of finding out more
PCI IDs only when users report. So Let's add all new reserved Haswell IDs.

This patch also fix GT3 names. I'no not sending in separated patche because
names are only in few comments and not in variable names.

v2: Fix some mobile ids (by Paulo)

References: http://bugs.freedesktop.org/show_bug.cgi?id=63701
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Propagate errors back from fb set-base

Along the modesetting short cut where we skip trying to do a full
modeset and instead simply update the framebuffer base registers, we
failed to handle any errors reported.

This regression has been introduced in

commit 94352cf9a5328bb1a44288e6c2c1276695f8a356
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 5 22:51:56 2012 +0200

    drm/i915: push crtc->fb update into pipe_set_base

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
m68k: implement futex.h to support userspace robust futexes and PI mutexes

Linux/M68K currently doesn't support robust futexes or PI mutexes.
The problem is that the futex code needs to perform certain ops
(cmpxchg, set, add, or, andn, xor) atomically on user-space
addresses, and M68K's lack of a futex.h causes those operations
to be unsupported and disabled.

This patch adds that support, but only for uniprocessor machines,
which is adequate for M68K.  For UP it's enough to disable preemption
to ensure mutual exclusion (futexes don't need to care about other
hardware agents), and the mandatory pagefault_disable() does just that.

This patch is closely based on the one I co-wrote for UP ARM back
in August 2008.  The main change is that this patch uses the C
get_user/put_user accessors instead of inline assembly code with
exception table fixups.

For non-MMU machines the new futex.h simply redirects to the generic
futex.h, so there is no functional change for them.

Tested on aranym with the glibc-2.17 test suite: no regressions, and
a number of mutex/condvar test cases went from failing to succeeding
(tst-mutexpi{5,5a,6,9}, tst-cond2[45], tst-robust[1-9], tst-robustpi[1-8]).
Also tested with glibc-2.18 HEAD and a local glibc patch to enable PI
mutexes: no regressions.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Acked-by: Andreas Schwab <schwab@linux-m68k.org>
[geert: Added removal of ""generic-y += futex.h"]
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
ACPI / PM: Allow device power states to be used for CONFIG_PM unset

Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of
the functions defined in there are replaced with static inline stubs
if that option is unset.  However, CONFIG_PM means, roughly, "runtime
PM or suspend/hibernation support" and some of those functions are
useful regardless of that.  For example, they are used by the ACPI
fan driver for controlling fans and acpi_device_set_power() is called
during device removal.  Moreover, device initialization may depend on
setting device power states properly.

For these reasons, make the routines manipulating ACPI device power
states defined in drivers/acpi/device_pm.c available for CONFIG_PM
unset too.

Reported-by: Zhang Rui <rui.zhang@intel.com>
Reported-and-tested-by: Michel Lespinasse <walken@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.9+ <stable@vger.kernel.org>
cpufreq: Drop rwsem lock around CPUFREQ_GOV_POLICY_EXIT

With the rwsem lock around
__cpufreq_governor(policy, CPUFREQ_GOV_POLICY_EXIT), we
get circular dependency when we call sysfs_remove_group().

 ======================================================
 [ INFO: possible circular locking dependency detected ]
 3.9.0-rc7+ #15 Not tainted
 -------------------------------------------------------
 cat/2387 is trying to acquire lock:
  (&per_cpu(cpu_policy_rwsem, cpu)){+++++.}, at: [<c02f6179>] lock_policy_rwsem_read+0x25/0x34

 but task is already holding lock:
  (s_active#41){++++.+}, at: [<c00f9bf7>] sysfs_read_file+0x4f/0xcc

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

-> #1 (s_active#41){++++.+}:
        [<c0055a79>] lock_acquire+0x61/0xbc
        [<c00fabf1>] sysfs_addrm_finish+0xc1/0x128
        [<c00f9819>] sysfs_hash_and_remove+0x35/0x64
        [<c00fbe6f>] remove_files.isra.0+0x1b/0x24
        [<c00fbea5>] sysfs_remove_group+0x2d/0xa8
        [<c02f9a0b>] cpufreq_governor_interactive+0x13b/0x35c
        [<c02f61df>] __cpufreq_governor+0x2b/0x8c
        [<c02f6579>] __cpufreq_set_policy+0xa9/0xf8
        [<c02f6b75>] store_scaling_governor+0x61/0x100
        [<c02f6f4d>] store+0x39/0x60
        [<c00f9b81>] sysfs_write_file+0xed/0x114
        [<c00b3fd1>] vfs_write+0x65/0xd8
        [<c00b424b>] sys_write+0x2f/0x50
        [<c000cdc1>] ret_fast_syscall+0x1/0x52

-> #0 (&per_cpu(cpu_policy_rwsem, cpu)){+++++.}:
        [<c0055253>] __lock_acquire+0xef3/0x13dc
        [<c0055a79>] lock_acquire+0x61/0xbc
        [<c03ee1f5>] down_read+0x25/0x30
        [<c02f6179>] lock_policy_rwsem_read+0x25/0x34
        [<c02f6edd>] show+0x21/0x58
        [<c00f9c0f>] sysfs_read_file+0x67/0xcc
        [<c00b40a7>] vfs_read+0x63/0xd8
        [<c00b41fb>] sys_read+0x2f/0x50
        [<c000cdc1>] ret_fast_syscall+0x1/0x52

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(s_active#41);
                                lock(&per_cpu(cpu_policy_rwsem, cpu));
                                lock(s_active#41);
   lock(&per_cpu(cpu_policy_rwsem, cpu));

  *** DEADLOCK ***

 2 locks held by cat/2387:
  #0:  (&buffer->mutex){+.+.+.}, at: [<c00f9bcd>] sysfs_read_file+0x25/0xcc
  #1:  (s_active#41){++++.+}, at: [<c00f9bf7>] sysfs_read_file+0x4f/0xcc

 stack backtrace:
 [<c0011d55>] (unwind_backtrace+0x1/0x9c) from [<c03e9a09>] (print_circular_bug+0x19d/0x1e8)
 [<c03e9a09>] (print_circular_bug+0x19d/0x1e8) from [<c0055253>] (__lock_acquire+0xef3/0x13dc)
 [<c0055253>] (__lock_acquire+0xef3/0x13dc) from [<c0055a79>] (lock_acquire+0x61/0xbc)
 [<c0055a79>] (lock_acquire+0x61/0xbc) from [<c03ee1f5>] (down_read+0x25/0x30)
 [<c03ee1f5>] (down_read+0x25/0x30) from [<c02f6179>] (lock_policy_rwsem_read+0x25/0x34)
 [<c02f6179>] (lock_policy_rwsem_read+0x25/0x34) from [<c02f6edd>] (show+0x21/0x58)
 [<c02f6edd>] (show+0x21/0x58) from [<c00f9c0f>] (sysfs_read_file+0x67/0xcc)
 [<c00f9c0f>] (sysfs_read_file+0x67/0xcc) from [<c00b40a7>] (vfs_read+0x63/0xd8)
 [<c00b40a7>] (vfs_read+0x63/0xd8) from [<c00b41fb>] (sys_read+0x2f/0x50)
 [<c00b41fb>] (sys_read+0x2f/0x50) from [<c000cdc1>] (ret_fast_syscall+0x1/0x52)

This lock isn't required while calling __cpufreq_governor(policy,
CPUFREQ_GOV_POLICY_EXIT). Remove it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
cpufreq / intel_pstate: Add additional supported CPU ID

Add CPU ID for Ivybrigde processor.

Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
drm/nouveau: use drm_send_vblank_event() helper

Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>