linux-toradex.git/drivers/base, branch v3.0.16

drivers/base/node.c: fix compilation error with older versions of gcc

2011-11-26T17:09:59+00:00

commit 91a13c281d7d4648c0b32dede11a0144c4e7984c upstream.

Patch to fix the error message "directives may not be used inside a macro
argument" which appears when the kernel is compiled for the cris architecture.

Signed-off-by: Claudio Scordino 
Acked-by: David Rientjes 
Signed-off-by: Greg Kroah-Hartman

PM / driver core: disable device's runtime PM during shutdown

2011-11-26T17:09:56+00:00

commit af8db1508f2c9f3b6e633e2d2d906c6557c617f9 upstream.

There may be an issue when the user issue "reboot/shutdown" command, then
the device has shut down its hardware, after that, this runtime-pm featured
device's driver will probably be scheduled to do its suspend routine,
and at its suspend routine, it may access hardware, but the device has
already shutdown physically, then the system hang may be occurred.

I ran out this issue using an auto-suspend supported USB devices, like
3G modem, keyboard. The usb runtime suspend routine may be scheduled
after the usb controller has been shut down, and the usb runtime suspend
routine will try to suspend its roothub(controller), it will access
register, then the system hang occurs as the controller is shutdown.

Signed-off-by: Peter Chen 
Acked-by: Ming Lei 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / Runtime: Automatically retry failed autosuspends

2011-11-11T17:36:57+00:00

commit 886486b792e4f6f96d4fbe8ec5bf20811cab7d6a upstream.

Originally, the runtime PM core would send an idle notification
whenever a suspend attempt failed.  The idle callback routine could
then schedule a delayed suspend for some time later.

However this behavior was changed by commit
f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle
notification after failing suspend).  No notifications were sent, and
there was no clear mechanism to retry failed suspends.

This caused problems for the usbhid driver, because it fails
autosuspend attempts as long as a key is being held down.  Therefore
this patch (as1492) adds a mechanism for retrying failed
autosuspends.  If the callback routine updates the last_busy field so
that the next autosuspend expiration time is in the future, the
autosuspend will automatically be rescheduled.

Signed-off-by: Alan Stern 
Tested-by: Henrik Rydberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

firmware loader: allow builtin firmware load even if usermodehelper is disabled

2011-10-03T18:41:07+00:00

commit caca9510ff4e5d842c0589110243d60927836222 upstream.

In commit a144c6a6c924 ("PM: Print a warning if firmware is requested
when tasks are frozen") we not only printed a warning if somebody tried
to load the firmware when tasks are frozen - we also failed the load.

But that check was done before the check for built-in firmware, and then
when we disallowed usermode helpers during bootup (commit 288d5abec831:
"Boot up with usermodehelper disabled"), that actually means that
built-in modules can no longer load their firmware even if the firmware
is built in too.  Which used to work, and some people depended on it for
the R100 driver.

So move the test for usermodehelper_is_disabled() down, to after
checking the built-in firmware.

This should fix:

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

Reported-by: James Cloos 
Bisected-by: Elimar Riesebieter 
Cc: Michel Dänzer 
Cc: Rafael Wysocki 
Cc: Greg Kroah-Hartman 
Cc: Valdis Kletnieks 
Signed-off-by: Linus Torvalds 
Cc: Borislav Petkov 
Cc: Lucas Villa Real 
Signed-off-by: Greg Kroah-Hartman

mm: Move definition of MIN_MEMORY_BLOCK_SIZE to a header

2011-07-12T01:08:01+00:00

The macro MIN_MEMORY_BLOCK_SIZE is currently defined twice in two .c
files, and I need it in a third one to fix a powerpc bug, so let's
first move it into a header

Signed-off-by: Benjamin Herrenschmidt 
Acked-by: Ingo Molnar

PM: Reintroduce dropped call to check_wakeup_irqs

2011-07-11T08:51:49+00:00

Patch 2e711c04dbbf7a7732a3f7073b1fc285d12b369d
(PM: Remove sysdev suspend, resume and shutdown operations)
deleted sysdev_suspend(), which was being relied on to call
check_wakeup_irqs() in suspend.  If check_wakeup_irqs() is not
called, wake interrupts that are pending when suspend is
entered may be lost.  It also breaks IRQCHIP_MASK_ON_SUSPEND,
which is handled in check_wakeup_irqs().

This patch adds a call to check_wakeup_irqs() in syscore_suspend(),
similar to what was deleted in sysdev_suspend().

Signed-off-by: Colin Cross 
Signed-off-by: Rafael J. Wysocki

Merge branch 'driver-core-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6

2011-06-28T18:15:36+00:00

* 'driver-core-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6:
  Connector: Correctly set the error code in case of success when dispatching receive callbacks
  Connector: Set the CN_NETLINK_USERS correctly
  pti: PTI semantics fix in pti_tty_cleanup.
  pti: ENXIO error case memory leak PTI fix.
  pti: double-free security PTI fix
  drivers:misc: ti-st: fix skipping of change remote baud
  drivers/base/platform.c: don't mark platform_device_register_resndata() as __init_or_module
  st_kim: Handle case of no device found for ID 0
  firmware: fix GOOGLE_SMI kconfig dependency warning

PM / Runtime: Handle clocks correctly if CONFIG_PM_RUNTIME is unset

2011-06-21T21:24:33+00:00

Commit 85eb8c8d0b0900c073b0e6f89979ac9c439ade1a (PM / Runtime:
Generic clock manipulation rountines for runtime PM (v6)) converted
the shmobile platform to using generic code for runtime PM clock
management, but it changed the behavior for CONFIG_PM_RUNTIME unset
incorrectly.

Specifically, for CONFIG_PM_RUNTIME unset pm_runtime_clk_notify()
should enable clocks for action equal to BUS_NOTIFY_BIND_DRIVER and
it should disable them for action equal to BUS_NOTIFY_UNBOUND_DRIVER
(instead of BUS_NOTIFY_ADD_DEVICE and BUS_NOTIFY_DEL_DEVICE,
respectively).  Make this function behave as appropriate.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Magnus Damm

PM: Fix async resume following suspend failure

2011-06-21T21:20:20+00:00

The PM core doesn't handle suspend failures correctly when it comes to
asynchronously suspended devices.  These devices are moved onto the
dpm_suspended_list as soon as the corresponding async thread is
started up, and they remain on the list even if they fail to suspend
or the sleep transition is cancelled before they get suspended.  As a
result, when the PM core unwinds the transition, it tries to resume
the devices even though they were never suspended.

This patch (as1474) fixes the problem by adding a new "is_suspended"
flag to dev_pm_info.  Devices are resumed only if the flag is set.

[rjw:
 * Moved the dev->power.is_suspended check into device_resume(),
   because we need to complete dev->power.completion and clear
   dev->power.is_prepared too for devices whose
   dev->power.is_suspended flags are unset.
 * Fixed __device_suspend() to avoid setting dev->power.is_suspended
   if async_error is different from zero.]

Signed-off-by: Alan Stern 
Signed-off-by: Rafael J. Wysocki 
Cc: stable@kernel.org

PM: Rename dev_pm_info.in_suspend to is_prepared

2011-06-21T21:19:50+00:00

This patch (as1473) renames the "in_suspend" field in struct
dev_pm_info to "is_prepared", in preparation for an upcoming change.
The new name is more descriptive of what the field really means.

Signed-off-by: Alan Stern 
Signed-off-by: Rafael J. Wysocki 
Cc: stable@kernel.org