The registration of a new parentless device during system suspend
will not lead to any complications affecting the PM core (the device
will be effectively seen after the subsequent resume has completed),
so remove the code used for detection of such events.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The device power.status field is too complicated for its purpose
(storing the information about whether or not the device is in the
"active" state from the PM core's point of view), so replace it with
a bit field and modify all of its users accordingly.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Since a separate list of devices is used to link devices that have
completed each stage of suspend (or resume), it is not necessary to
check dev->power.status in the core device resume routines any more.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Instead of keeping all devices in the same list during system suspend
and resume, regardless of what suspend-resume callbacks have been
executed for them already, use separate lists of devices that have
had their ->prepare(), ->suspend() and ->suspend_noirq() callbacks
executed.  This will allow us to simplify the core device suspend and
resume routines.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The compiler complains that calltime may be uninitialized in
pm_noirq_op(), so add extra initialization for that variable to
avoid the warning.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Before starting to suspend a device in __device_suspend() check if
there's a request to abort the power transition and return -EBUSY
in that case.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

To avoid confusion with the meaning and return value of
pm_check_wakeup_events() replace it with pm_wakeup_pending() that
will work the other way around (ie. return true when system-wide
power transition should be aborted).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Currently dpm_prepare() returns error code if it finds that a device
being suspended has a pending runtime resume request.  However, it
should not do that if the checking for wakeup events is not enabled.
On the other hand, if the checking for wakeup events is enabled, it
can return error when a wakeup event is detected, regardless of its
source.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This patch (as1431c) makes the synchronous runtime-PM interface
suitable for use in interrupt handlers.  Subsystems can call the new
pm_runtime_irq_safe() function to tell the PM core that a device's
runtime_suspend and runtime_resume callbacks should be invoked with
interrupts disabled and the spinlock held.  This permits the
pm_runtime_get_sync() and the new pm_runtime_put_sync_suspend()
routines to be called from within interrupt handlers.

When a device is declared irq-safe in this way, the PM core increments
the parent's usage count, so the parent will never be runtime
suspended.  This prevents difficult situations in which an irq-safe
device can't resume because it is forced to wait for its non-irq-safe
parent.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Commit 05aa55dd changed routines to
succeed if the driver handler is not defined. Comments were not updated.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The default for non-READ_BACK GPIO regs is to have the clear bits set;
this means that our original errata fix was too simplistic.  This
changes it to the following behavior:

 - when setting GPIOs, ignore the higher order bits (they're for
   clearing, we don't need to care about them).

 - when clearing GPIOs, keep all the bits, but unset (via XOR) the
   lower order bit that negates the clear bit that we care about.  That
   is, if we're clearing GPIO 26 (val = 0x04000000), we first XOR what's
   currently in the register with 0x0400 (GPIO 26's SET bit), and then
   OR that with the GPIO 26's CLEAR bit.
Tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The edge detect status GPIOs function differently from the other atomic
model CS5536 GPIO registers; writing 1 to the high bits clears the GPIO,
but writing 1 to the lower bits also clears the bit.

This means that read-modify-write doesn't actually work for it, so don't
apply the errata here.  If a negative edge status gets lost after
resume..  well, we tried our best!
Tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This was fixed by David Lamparter in v2.6.36-rc5 34860089 ("spi: free
children in spi_unregister_master, not siblings") and broken again in
v2.6.37-rc1~2^2~4 during the merge of 2b9603a0 ("spi: enable
spi_board_info to be registered after spi_master").
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NDavid Lamparter <equinox@diac24.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When I added led_blink_set I had a typo: the return value of the hw
offload is a regular error code that is zero when succesful, and in that
case software emulation should not be used, rather than the other way
around.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Cc: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Cc: Thomas Hellstrom <thomas@tungstengraphics.com>
Cc: Alan Hourihane <alanh@tungstengraphics.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Match the buffer size to the amount of initialized values.  Before, it was
one too big and thus destroyed the neighbouring register causing the clock
to run at false speeds.
Reported-by: NAndre van Rooyen <a.v.rooyen@sercom.nl>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If GPIO request succeeds, but configuration fails, it should be released.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: NEric Miao <eric.miao@canonical.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some newer device revisions add a second parent ID. Support this in
the device validity checks done at startup.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

We want to find the first set bit on value, not status.
Signed-off-by: NMattias Wallin <mattias.wallin@stericsson.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Without this the IRQ base will not be correctly configured for the
subdevices.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

rdc321x-wdt currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
CC: stable@kernel.org
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

rdc321x-gpio currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
CC: stable@kernel.org
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Always useful to know just which connector was polled and had its
status updated.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We were using the lockup struct from the wrong union.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

.. caused by a missing semi-colon, introduced in commit 0fc13c89
("cciss: fix cciss_revalidate panic").
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: NThiago Farina <tfransosi@gmail.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed.  Re-program
the mode first, then reset the dpms state.

This fixes the infamous atombios timeouts on resume.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit 541cc966.

Wei Yonjun reported this caused a regression against Intel VGA hotplug
on his G33 hw.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
[danvet: add cc: stable, forward ported and compile-fixed for X86]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[airlied: move to even earlier in module load.]
Signed-off-by: NDave Airlie <airlied@redhat.com>

Its possible for the call to read rx timeout from the hardware to fail,
in which case we end up with a bogus rx timeout value. Set a default one
when filling in the rc struct, and we'll just overwrite it later w/the
value from hardware, but if that read fails, we've at least got a sane
rx timeout value to work with (1000ms is the default value I've seen
returned on most if not all mceusb hardware).
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As it turns out, somewhere along the way, we managed to invert the
meaning of the tx_mask_inverted flag. Looking back over the old lirc
driver, tx_mask_inverted was set to 0 if the device was in tx_mask_list.
Now we have a tx_mask_inverted flag set to 1 for all the devices that
were in the list, and set tx_mask_inverted to that flag value, which is
actually the opposite of what we used to set, causing set_tx_mask to use
the wrong mask setting option. Since there seem to be more devices with
inverted masks than not (using the original device as the baseline for
inverted vs. normal), lets just call the ones currently marked as
inverted normal instead, and flip the if/else actions that key off of
the inverted flag.

Note: the problem only cropped up if a call to set_tx_mask was made, if
no mask was set, the device would work just fine, which is why this
managed to slip though w/o getting noticed until now.

Tested successfully by myself and Dennis Gilmore.
Reported-by: NDennis Gilmore <dgilmore@redhat.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This makes several changes but they're in one function and sort of
related:

"buf" was leaked on error.  The leak if we try to read an invalid
length is the main concern because it could be triggered over and
over.

If the copy_to_user() failed, then the original code returned the
number of bytes remaining.  read() is supposed to be the opposite way,
where we return the number of bytes copied.  I changed it to just return
-EFAULT on errors.

Also I changed the debug output from "-EFAULT" to just "<fail>" because
it isn't -EFAULT necessarily.  And since we go though that path if the
length is invalid now, there was another debug print that I removed.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Reviewed-by: NJarod Wilson <jarod@redhat.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We shouldn't unlock here.  I think this was a cut and paste error.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

When trying to create persistent device names for mceusb and streamzap
devices, I noticed that their respective drivers are not creating the rc
device as a child of the USB device. Rather it creates it as virtual
device. As a result, udev cannot use the USB device information to
create persistent device names for event and lirc devices associated
with the rc device. Not having persistent device names makes it more
difficult to make use of the devices in userspace as their names can
change.
Signed-off-by: NPaul Bender <pebender@gmail.com>
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There are cases where we get an ending space, and our trailing timeout
space then gets sent right after it, which breaks repeat, at least for
lirc userspace decoding. Merge the two spaces by way of using
ir_raw_event_store_filter, set a timeout value, and we're back to good.

Successfully tested with streamzap and windows mce remotes.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Something I failed to notice while testing the mceusb RLE buffer
decoding simplification patches was that we were getting an extra event
from the previously pressed key.

As was pointed out to me on irc by Maxim, this is actually due to using
ir_raw_event_store_with_filter without having set up a timeout value.
The hardware has a timeout value we're now reading and storing, which
properly enables the transition to idle in the raw event storage
process, and makes IR decode behave correctly w/o keybounce.

Also remove no-longer-used ir_raw_event struct from mceusb_dev struct
and add as-yet-unused enable flags for carrier reports and learning
mode, which I'll hopefully start wiring up sooner than later. While
looking into that, found evidence that 0x9f 0x15 responses are only
non-zero when the short-range learning sensor is used, so correct the
debug spew message, and then suppress it when using the standard
long-range sensor.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

And clean up some stray spaces.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If we pass in an offset, we shouldn't skip 2 bytes. And the first-gen
hardware generates a constant stream of interrupts, always with two
header bytes, and if there's been no IR, with nothing else. Bail from
ir processing without calling ir_handle_raw_event when we get such a
buffer delivered to us.
Signed-off-by: NJarod Wilson <jarod@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>