Since every device in a PM domain has its own need_restore
flag, which is set by __pm_genpd_save_device(), there's no need to
walk the domain's device list and restore all devices on an error
from one of the drivers' .runtime_suspend() callbacks.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

A deadlock may occur if one of the PM domains' .start_device() or
.stop_device() callbacks or a device driver's .runtime_suspend() or
.runtime_resume() callback executed by the core generic PM domain
code uses a "wrong" runtime PM helper function.  This happens, for
example, if .runtime_resume() from one device's driver calls
pm_runtime_resume() for another device in the same PM domain.
A similar situation may take place if a device's parent is in the
same PM domain, in which case the runtime PM framework may execute
pm_genpd_runtime_resume() automatically for the parent (if it is
suspended at the moment).  This, of course, is undesirable, so
the generic PM domains code should be modified to prevent it from
happening.

The runtime PM framework guarantees that pm_genpd_runtime_suspend()
and pm_genpd_runtime_resume() won't be executed in parallel for
the same device, so the generic PM domains code need not worry
about those cases.  Still, it needs to prevent the other possible
race conditions between pm_genpd_runtime_suspend(),
pm_genpd_runtime_resume(), pm_genpd_poweron() and pm_genpd_poweroff()
from happening and it needs to avoid deadlocks at the same time.
To this end, modify the generic PM domains code to relax
synchronization rules so that:

* pm_genpd_poweron() doesn't wait for the PM domain status to
  change from GPD_STATE_BUSY.  If it finds that the status is
  not GPD_STATE_POWER_OFF, it returns without powering the domain on
  (it may modify the status depending on the circumstances).

* pm_genpd_poweroff() returns as soon as it finds that the PM
  domain's status changed from GPD_STATE_BUSY after it's released
  the PM domain's lock.

* pm_genpd_runtime_suspend() doesn't wait for the PM domain status
  to change from GPD_STATE_BUSY after executing the domain's
  .stop_device() callback and executes pm_genpd_poweroff() only
  if pm_genpd_runtime_resume() is not executed in parallel.

* pm_genpd_runtime_resume() doesn't wait for the PM domain status
  to change from GPD_STATE_BUSY after executing pm_genpd_poweron()
  and sets the domain's status to GPD_STATE_BUSY and increments its
  counter of resuming devices (introduced by this change) immediately
  after acquiring the lock.  The counter of resuming devices is then
  decremented after executing __pm_genpd_runtime_resume() for the
  device and the domain's status is reset to GPD_STATE_ACTIVE (unless
  there are more resuming devices in the domain, in which case the
  status remains GPD_STATE_BUSY).

This way, for example, if a device driver's .runtime_resume()
callback executes pm_runtime_resume() for another device in the same
PM domain, pm_genpd_poweron() called by pm_genpd_runtime_resume()
invoked by the runtime PM framework will not block and it will see
that there's nothing to do for it.  Next, the PM domain's lock will
be acquired without waiting for its status to change from
GPD_STATE_BUSY and the device driver's .runtime_resume() callback
will be executed.  In turn, if pm_runtime_suspend() is executed by
one device driver's .runtime_resume() callback for another device in
the same PM domain, pm_genpd_poweroff() executed by
pm_genpd_runtime_suspend() invoked by the runtime PM framework as a
result will notice that one of the devices in the domain is being
resumed, so it will return immediately.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Currently, the .start_device() and .stop_device() callbacks from
struct generic_pm_domain() as well as the device drivers' runtime PM
callbacks used by the generic PM domains code are executed under
the generic PM domain lock.  This, unfortunately, is prone to
deadlocks, for example if a device and its parent are boths members
of the same PM domain.  For this reason, it would be better if the
PM domains code didn't execute device callbacks under the lock.

Rework the locking in the generic PM domains code so that the lock
is dropped for the execution of device callbacks.  To this end,
introduce PM domains states reflecting the current status of a PM
domain and such that the PM domain lock cannot be acquired if the
status is GPD_STATE_BUSY.  Make threads attempting to acquire a PM
domain's lock wait until the status changes to either
GPD_STATE_ACTIVE or GPD_STATE_POWER_OFF.

This change by itself doesn't fix the deadlock problem mentioned
above, but the mechanism introduced by it will be used for for this
purpose by a subsequent patch.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

If pm_generic_prepare() in pm_genpd_prepare() returns error code,
the PM domains counter of "prepared" devices should be decremented
and its suspend_power_off flag should be reset if this counter drops
down to zero.  Otherwise, the PM domain runtime PM code will not
handle the domain correctly (it will permanently think that system
suspend is in progress).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The runtime PM status of devices in a power domain that is not
powered off in pm_genpd_complete() should be set to "active", because
those devices are operational at this point.  Some of them may not be
in use, though, so make pm_genpd_complete() call pm_runtime_idle()
in addition to pm_runtime_set_active() for each of them.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Allow SoC-specific code to call pm_genpd_poweron().
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The common PM clock management functions may be used for system
suspend/resume as well as for runtime PM, so rename them
accordingly.  Modify kerneldoc comments describing these functions
and kernel messages printed by them, so that they refer to power
management in general rather that to runtime PM.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

The common clocks management code in drivers/base/power/clock_ops.c
is going to be used during system-wide power transitions as well as
for runtime PM, so it shouldn't depend on CONFIG_PM_RUNTIME.
However, the suspend/resume functions provided by it for
CONFIG_PM_RUNTIME unset, to be used during system-wide power
transitions, should not behave in the same way as their counterparts
defined for CONFIG_PM_RUNTIME set, because in that case the clocks
are managed differently at run time.

The names of the functions still contain the word "runtime" after
this change, but that is going to be modified by a separate patch
later.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

There is the problem how to handle devices set up to wake up the
system from sleep states during system-wide power transitions.
In some cases, those devices can be turned off entirely, because the
wakeup signals will be generated on their behalf anyway.  In some
other cases, they will generate wakeup signals if their clocks are
stopped, but only if power is not removed from them.  Finally, in
some cases, they can only generate wakeup signals if power is not
removed from them and their clocks are enabled.

To allow platform-specific code to decide whether or not to put
wakeup devices (and their PM domains) into low-power state during
system-wide transitions, such as system suspend, introduce a new
generic PM domain callback, .active_wakeup(), that will be used
during the "noirq" phase of system suspend and hibernation (after
image creation) to decide what to do with wakeup devices.
Specifically, if this callback is present and returns "true", the
generic PM domain code will not execute .stop_device() for the
given wakeup device and its PM domain won't be powered off.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NKevin Hilman <khilman@ti.com>

Make generic PM domains support system-wide power transitions
(system suspend and hibernation).  Add suspend, resume, freeze, thaw,
poweroff and restore callbacks to be associated with struct
generic_pm_domain objects and make pm_genpd_init() use them as
appropriate.

The new callbacks do nothing for devices belonging to power domains
that were powered down at run time (before the transition).  For the
other devices the action carried out depends on the type of the
transition.  During system suspend the power domain .suspend()
callback executes pm_generic_suspend() for the device, while the
PM domain .suspend_noirq() callback runs pm_generic_suspend_noirq()
for it, stops it and eventually removes power from the PM domain it
belongs to (after all devices in the domain have been stopped and its
subdomains have been powered off).

During system resume the PM domain .resume_noirq() callback
restores power to the PM domain (when executed for it first time),
starts the device and executes pm_generic_resume_noirq() for it,
while the .resume() callback executes pm_generic_resume() for the
device.  Finally, the .complete() callback executes pm_runtime_idle()
for the device which should put it back into the suspended state if
its runtime PM usage count is equal to zero at that time.

The actions carried out during hibernation and resume from it are
analogous to the ones described above.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

There is some code in drivers/base/power/domain.c that will be useful
for both runtime PM and system-wide power transitions, so make it
depend on CONFIG_PM instead of CONFIG_PM_RUNTIME.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Reviewed-by: NKevin Hilman <khilman@ti.com>

Introduce generic "noirq" power management callback routines for
subsystems in addition to the "regular" generic PM callback routines.

The new routines will be used, among other things, for implementing
system-wide PM transitions support for generic PM domains.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Introduce common headers, helper functions and callbacks allowing
platforms to use simple generic power domains for runtime power
management.

Introduce struct generic_pm_domain to be used for representing
power domains that each contain a number of devices and may be
parent domains or subdomains with respect to other power domains.
Among other things, this structure includes callbacks to be
provided by platforms for performing specific tasks related to
power management (i.e. ->stop_device() may disable a device's
clocks, while ->start_device() may enable them, ->power_off() is
supposed to remove power from the entire power domain
and ->power_on() is supposed to restore it).

Introduce functions that can be used as power domain runtime PM
callbacks, pm_genpd_runtime_suspend() and pm_genpd_runtime_resume(),
as well as helper functions for the initialization of a power
domain represented by a struct generic_power_domain object,
adding a device to or removing a device from it and adding or
removing subdomains.

Introduce configuration option CONFIG_PM_GENERIC_DOMAINS to be
selected by the platforms that want to use the new code.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Reviewed-by: NKevin Hilman <khilman@ti.com>

The naming convention used by commit 7538e3db6e015e890825fbd9f86599b
(PM: Add support for device power domains), which introduced the
struct dev_power_domain type for representing device power domains,
evidently confuses some developers who tend to think that objects
of this type must correspond to "power domains" as defined by
hardware, which is not the case.  Namely, at the kernel level, a
struct dev_power_domain object can represent arbitrary set of devices
that are mutually dependent power management-wise and need not belong
to one hardware power domain.  To avoid that confusion, rename struct
dev_power_domain to struct dev_pm_domain and rename the related
pointers in struct device and struct pm_clk_notifier_block from
pwr_domain to pm_domain.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NKevin Hilman <khilman@ti.com>

In an attempt to fix 38862 and 38863.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

CE variant requires a different chremap setup.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=35472Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This lets us make the various IRQ functions static and helps avoid
problems like the one fixed in "drm/i915: Use chipset-specific irq
installers" where one of the exported functions was called rather than
the chipset specific version.

This also fixes a UMS-mode bug -- the correct irq functions for IRL
and later chips were only getting loaded in the KMS path.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

As pointed out by Dan Carpenter, it was seemingly possible to hit an error
whilst mapping the buffer for the regs (except the only likely error
returns should not happen during init) and so leak a pin count on the
bo. To handle this we would need to reacquire the struct mutex, so for
simplicity rearrange for the lock to be held for the entire function.
For extra pedagogy, test that we only call init once.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The vbios rom is >64k on a lot of modern asics.  Increase
the fetch size for atrm to make sure we don't miss part
of a larger rom.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

setkey allocates 16 bytes (CAAM_CMD_SZ *
DESC_AEAD_SHARED_TEXT_LEN) shy of what is needed to
store the shared descriptor, resulting in memory
corruption.  Fix this.
Signed-off-by: NKim Phillips <kim.phillips@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Reported-by: NPavel Roskin <proski@gnu.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38777
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Lots of register access in these functions, some of which requires the
struct mutex.

These functions now hold the struct mutex across the calls to
i915_save_display and i915_restore_display, and so the internal mutex
calls in those functions have been removed. To ensure that no-one else
was calling them (and hence violating the new required locking
invarient), those functions have been made static.

gen6_enable_rps locks the struct mutex, and so i915_restore_state
unlocks the mutex around calls to that function.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

It's not so much an error as a warning about normal Marvell crazines.
So don't use KERN_ERR that ends up spamming the console even in quiet
mode, it's not _that_ critical.

Explained by Jeff:

 "Long explanation, it's a mess:

  Marvell took standard AHCI, and bastardized it to include a weird mode
  whereby PATA devices appear inside the AHCI DMA and interrupt
  infrastructure you're familiar with.

  So, PATA devices appear via pata_marvell driver, using basic legacy
  IDE programming interface.  But SATA devices, which might also be
  attached to this chip, either work in under-performing mode or
  simply don't work at all (e.g.  newer 6 Gbps devices or port
  multiplier attachments, NCQ, ...)

  On the other hand, 'ahci' driver loads and works with the chip's
  attached SATA devices quite beautifully, but is completely unable to
  drive any attached PATA devices, due to the Marvell-specific
  PATA-under-AHCI interface.

  The "masking port_map 0x7 -> 0x3" message is the ahci driver "hiding"
  the PATA port(s) from itself, making sure it will only drive the SATA
  ports it knows how to drive."
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This module and a bunch of dependancies are getting loaded on several
of laptops I have (probably picking up the mobile broadband device),
that have nothing to do with zaurus. Matching by class without
any vendor/device pair isn't the right thing to do here, as it
will prevent any other driver from correctly binding to it.
(Or in the absense of a driver, will just waste time & memory by
 unnecessarily loading modules)
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The two options "CAN bit-timing calculation" and
"Platform CAN drivers with Netlink support" have a "default Y". In order to
activate them by default, change to "default y".
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function rionet_remove initializes local variable 'ndev' to NULL
and do nothing changes before the call to unregister_netdev(ndev),
this could cause a NULL pointer dereference.
Reported-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NYinglin Luan <synmyth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They are 64K and result in order-4 allocations, even with SLUB.

Therefore, just like we always have for the deflate buffers, use
vmalloc.
Reported-by: NMartin Jackson <mjackson220.list@gmail.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

pca954x power-on default is channel 0 connected. If multiple pca954x
muxes are connected to the same physical I2C bus, the parent bus will
see channel 0 devices behind both muxes by default. This is bad.

Scenario:
            -- pca954x @ 0x70 -- ch 0 (I2C-bus-101) -- EEPROM @ 0x50
            |
I2C-bus-1 ---
            |
            -- pca954x @ 0x71 -- ch 0 (I2C-bus-111) -- EEPROM @ 0x50

1. Load I2C bus driver: creates I2C-bus-1
2. Load pca954x driver: creates virtual I2C-bus-101 and I2C-bus-111
3. Load eeprom driver
4. Try to read EEPROM @ 0x50 on I2C-bus-101. The transaction will also bleed
   onto I2C-bus-111 because pca954x @ 0x71 channel 0 is connected by default.

Fix: Initialize pca954x to disconnected state in pca954x_probe()
Signed-off-by: NPetri Gynther <pgynther@google.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org

* Print all error and information messages even when debugging is
  disabled.
* Don't use adapter device to log messages before it is ready.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org

This patch updates the email address of the at32ap700x_wdt driver supported by
me to an email account I will use on a more regular basis in the future.
Signed-off-by: NHans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Konstantin Belousov pointed out that 4697995b replaced the generic
i915_driver_irq_*install() functions with chipset specific routines
accessible only through driver->irq_*install(). So update the sanity
check in i915_request_wait() to match.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The failure is as follows:

1. Userspace gets forcewake lock, lock count >=1
2. GPU hang/reset occurs (forcewake bit is reset)
3. count is now incorrect

The failure can only occur when using the forcewake userspace lock.

This has the unfortunate consequence of messing up the driver as well as
userspace, unless userspace closes the debugfs file, the kernel will
never end up waking the GT since the refcount will be > 1.

The solution is to try to recover the correct forcewake state based on
the refcount. There is a period of time where userspace reads/writes may
occur after the reset, before the GT has been forcewaked. The interface
was never designed to be a perfect solution for userspace reads/writes,
and the kernel portion is fixed by this patch.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Remove the space between "platform:" prefix and the driver name.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NMartyn Welch <martyn.welch@ge.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Trying to build the Intel SCU Watchdog fails for me with gcc 4.6.0 -
$ gcc --version | head -n 1
gcc (GCC) 4.6.0 20110513 (prerelease)

like this :
  CC      drivers/watchdog/intel_scu_watchdog.o
In file included from drivers/watchdog/intel_scu_watchdog.c:49:0:
/home/jj/src/linux-2.6/arch/x86/include/asm/apb_timer.h: In function ‘apbt_time_init’:
/home/jj/src/linux-2.6/arch/x86/include/asm/apb_timer.h:65:42: warning: ‘return’ with a value, in function returning void [enabled by default]
drivers/watchdog/intel_scu_watchdog.c: In function ‘intel_scu_watchdog_init’:
drivers/watchdog/intel_scu_watchdog.c:468:2: error: implicit declaration of function ‘sfi_get_mtmr’ [-Werror=implicit-function-declaration]
drivers/watchdog/intel_scu_watchdog.c:468:32: warning: assignment makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors

make[1]: *** [drivers/watchdog/intel_scu_watchdog.o] Error 1
make: *** [drivers/watchdog/intel_scu_watchdog.o] Error 2

Additionally, linux/types.h is needlessly being included twice in 
drivers/watchdog/intel_scu_watchdog.c
Signed-off-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Fix section mismatch and remove unused variable 'tmp'.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Commit e391be76 (MIPS: Alchemy: Clean up GPIO registers and accessors)
changed the way the GPIO was toggled. Prior to this patch, we would
always actively drive the GPIO output to either 0 or 1, this patch
drove the GPIO active to 0, and put the GPIO in tristate to drive it
to 1, unfortunately this does not work, revert back to active driving.

Using a signed variable (gstate) to hold the gpio state and using a bit-
wise operation on it also resulted in toggling value from 1 to -2 since
the variable is signed. This value was then passed on to gpio_direction_
output, which always perform a if (value) ... to set the value to the
gpio, so we were always writing a 1 to this GPIO instead of 1 -> 0 -> 1 ...
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>

Otherwise, the gpiolib autorequest feature will produce a WARN_ON():

WARNING: at drivers/gpio/gpiolib.c:101 0x8020ec6c()
autorequest GPIO-215
[...]
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@kernel.org>

Due to the whole single instance based watchdog API we use static data
for the wm831x watchdog which means that if the system tries to register
a second one we end up trying to register the same miscdevice again,
corrupting the miscdevice list. Work around this by checking for duplicate
registrations until we get a watchdog core.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

If a device fails in a way that causes pending request to take a while
to complete, md will not be able to immediately remove it from the
array in remove_and_add_spares.
It will then incorrectly look like a spare device and md will try to
recover it even though it is failed.
This leads to a recovery process starting and instantly aborting over
and over again.

We should check if the device is faulty before considering it to be a
spare.  This will avoid trying to start a recovery that cannot
proceed.

This bug was introduced in 2.6.26 so that patch is suitable for any
kernel since then.

Cc: stable@kernel.org
Reported-by: NJim Paradis <james.paradis@stratus.com>
Signed-off-by: NNeilBrown <neilb@suse.de>

When auditing the locking in i915_gem.c (for a prospective change which
I then abandoned), I noticed two places where struct_mutex is not held
across GEM object manipulations that would usually require it.

Since one is in initial setup and the other in driver unload, I'm
guessing the mutex is not required for either; but post a patch in case
it is.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>