Allowing a lock to be asynchronously released while a handle
was still active turned out to be too dangerous to use in a
multi-threaded environment and it served no pratical
purpose anyway. Handles now hold an attached lock until they
are destroyed.
CRs-fixed: 333141
Change-Id: Ic0dedbad8050ff01927ddb165c65a939bf297c10
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Check for the possibility of NULL handles passed into the
in-kernel API functions and return error where appropriate.
There is a non-zero chance that the private_data will be
cleared while the FD is still active, so check in the ioctl()
function as well.
CRs-fixed: 332835
Change-Id: Ic0dedbada2713080fef79ca188a87c578bec6d2f
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Avoid a race condition if a lock gets released by all owners
but a process fails to close a lock file descriptor and tries
to reuse it. Clearing the pointers to the data will ensure
that attaching a dead lock will return an error.
Change-Id: Ic0dedbadd693c7a22b027052cdd247370b28a7c5
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Create a new iommu api to return the base address of the domain's
pagetable.
Change-Id: Ibf5425fa7ae253b16bfe795614bd7943efd7e3e3
Signed-off-by: Shubhraprakash Das <sadas@codeaurora.org>
The resources allocated for a handle were not being freed on device
release. This included releasing the lock. Unfortunately, the
lock release had a fput() too many which was screwing up the
reference counting on the file descriptors. When attaching a lock,
we only need the file pointer for a short time so fput() it back
immediately. That way, only there will only be one reference to
the lock per process, and the process will be responsible for
closing the fd directly and the fput() in genlock_release_lock
is no longer needed.
CRs-fixed: 322645
Change-Id: Ic0dedbad55300a2f8463c800cf8361719583b0b8
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Add a generic locking API for situations where multiple user-space
processes and/or kernel drivers need to cooordinate access to a
shared resource such as a graphics buffer.
Change-Id: Ic0dedbad74b970d7bd1a6624a845b5b1b9847443
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
* common/android-3.0: (570 commits)
misc: remove kernel debugger core
ARM: common: fiq_debugger: dump sysrq directly to console if enabled
ARM: common: fiq_debugger: add irq context debug functions
net: wireless: bcmdhd: Call init_ioctl() only if was started properly for WEXT
net: wireless: bcmdhd: Call init_ioctl() only if was started properly
net: wireless: bcmdhd: Fix possible memory leak in escan/iscan
cpufreq: interactive governor: default 20ms timer
cpufreq: interactive governor: go to intermediate hi speed before max
cpufreq: interactive governor: scale to max only if at min speed
cpufreq: interactive governor: apply intermediate load on current speed
ARM: idle: update idle ticks before call idle end notifier
input: gpio_input: don't print debounce message unless flag is set
net: wireless: bcm4329: Skip dhd_bus_stop() if bus is already down
net: wireless: bcmdhd: Skip dhd_bus_stop() if bus is already down
net: wireless: bcmdhd: Improve suspend/resume processing
net: wireless: bcmdhd: Check if FW is Ok for internal FW call
tcp: Don't nuke connections for the wrong protocol
ARM: common: fiq_debugger: make uart irq be no_suspend
net: wireless: Skip connect warning for CONFIG_CFG80211_ALLOW_RECONNECT
mm: avoid livelock on !__GFP_FS allocations
...
Conflicts:
arch/arm/mm/cache-l2x0.c
arch/arm/vfp/vfpmodule.c
drivers/mmc/core/host.c
kernel/power/wakelock.c
net/bluetooth/hci_event.c
Signed-off-by: Bryan Huntsman <bryanh@codeaurora.org>
Check that a set of IOMMU ops has been registered before
using them, as this may result in dereferencing a NULL
pointer.
Change-Id: I11f81a236c9bfd2e1a1899c7fee1f43125fdb004
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Add the ability to pass flags into the iommu_domain_alloc
function to specify domain attributes.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
Add IOMMU ops functions to allow mapping and unmapping
whole ranges of address space based on a scatterlist.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
commit caca9510ff4e5d842c0589110243d60927836222 upstream.
In commit a144c6a6c9 ("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 <cloos@hjcloos.com>
Bisected-by: Elimar Riesebieter <riesebie@lxtec.de>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Rafael Wysocki <rjw@sisk.pl>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Lucas Villa Real <lucasvr@gobolinux.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The list of functions that can be called in atomic context is
non-intuitive (pm_runtime_put_sync can not, but
pm_runtime_put_sync_suspend can, if pm_runtime_irq_safe has
been called?). The code is actively misleading - the entry
points all start with spin_lock_irqsave, suggesting they
are safe to call in atomic context, but may later
enable interrupts.
Add might_sleep_if to all the __pm_runtime_* entry points
to enforce correct usage.
Also add pm_runtime_put_sync_autosuspend to the list of
functions that can be called in atomic context.
Change-Id: Icac17a10d77c64d44bd2761a91a588dfd1d0c6f0
Signed-off-by: Colin Cross <ccross@android.com>
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 <benh@kernel.crashing.org>
Acked-by: Ingo Molnar <mingo@elte.hu>
Patch 2e711c04db
(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 <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* '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
Commit 85eb8c8d0b (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 <rjw@sisk.pl>
Acked-by: Magnus Damm <damm@opensource.se>
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 <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
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 <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org
usbhid devices have a 10s timeout waiting for the out queue to clear.
Increased the watchdog to 12s.
Change-Id: I96368fca6dff98e4eba8aedb09c23be964c8f4b4
Signed-off-by: Benoit Goby <benoit@android.com>
Exclude from the watchdog the time spent waiting for children that
are resumed asynchronously and time every devices, whether or not they
resumed synchronously.
Change-Id: I84209dfd5df72842e045096c906fd61e20e6d183
Signed-off-by: Benoit Goby <benoit@android.com>
When a driver takes more than 3 seconds to suspend, dump the suspend
thread stack since BUG() might only dump the idle thread stack.
Change-Id: If854db355fdcf3b773ea20b1b5e031def6d4b114
Signed-off-by: Benoit Goby <benoit@android.com>
If the parent device is in the DPM_RESUMING state, resume might get called
before the parent's resume has completed, because dpm_wait won't get
called. This issue was introduced by:
3d46a3c PM: Prevent waiting forever on asynchronous resume after abort
Wait for completion of the parent resume if the parent state is >= DPM_OFF
or == DPM_RESUMING
Signed-off-by: Benoit Goby <benoit@android.com>
[dima: fixed to work on 2.6.38, use .in_suspend instead of .state]
Signed-off-by: Dima Zavin <dima@android.com>
Only wait on a parent device during resume if the parent device is
suspended.
Consider three drivers, A, B, and C. The parent of A is C, and C
has async_suspend set. On boot, C->power.completion is initialized
to 0.
During the first suspend:
suspend_devices_and_enter(...)
dpm_resume(...)
device_suspend(A)
device_suspend(B) returns error, aborts suspend
dpm_resume_end(...)
dpm_resume(...)
device_resume(A)
dpm_wait(A->parent == C)
wait_for_completion(C->power.completion)
The wait_for_completion will never complete, because
complete_all(C->power.completion) will only be called from
device_suspend(C) or device_resume(C), neither of which is called
if suspend is aborted before C.
After a successful suspend->resume cycle, where B doesn't abort
suspend, C->power.completion is left in the completed state by the
call to device_resume(C), and the same call path will work if B
aborts suspend.
Signed-off-by: Colin Cross <ccross@android.com>
Rather than hard-lock the kernel, we now BUG() when a driver takes
> 3 seconds to suspend. If the underlying platform supports panic dumps,
then the data can be collected for debug.
Signed-off-by: San Mehat <san@google.com>
The loops over connection ID strings in pm_runtime_clk_notify()
should actually iterate over the strings and not over the elements
of the first of them, so make them behave as appropriate.
This fixes a regression introduced by commit 600b776eb3
(OMAP1 / PM: Use generic clock manipulation routines for runtime PM).
Reported-and-tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
b43: fix comment typo reqest -> request
Haavard Skinnemoen has left Atmel
cris: typo in mach-fs Makefile
Kconfig: fix copy/paste-ism for dell-wmi-aio driver
doc: timers-howto: fix a typo ("unsgined")
perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c
md, raid5: Fix spelling error in comment ('Ofcourse' --> 'Of course').
treewide: fix a few typos in comments
regulator: change debug statement be consistent with the style of the rest
Revert "arm: mach-u300/gpio: Fix mem_region resource size miscalculations"
audit: acquire creds selectively to reduce atomic op overhead
rtlwifi: don't touch with treewide double semicolon removal
treewide: cleanup continuations and remove logging message whitespace
ath9k_hw: don't touch with treewide double semicolon removal
include/linux/leds-regulator.h: fix syntax in example code
tty: fix typo in descripton of tty_termios_encode_baud_rate
xtensa: remove obsolete BKL kernel option from defconfig
m68k: fix comment typo 'occcured'
arch:Kconfig.locks Remove unused config option.
treewide: remove extra semicolons
...
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (44 commits)
debugfs: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
sysfs: remove "last sysfs file:" line from the oops messages
drivers/base/memory.c: fix warning due to "memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION"
memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION
SYSFS: Fix erroneous comments for sysfs_update_group().
driver core: remove the driver-model structures from the documentation
driver core: Add the device driver-model structures to kerneldoc
Translated Documentation/email-clients.txt
RAW driver: Remove call to kobject_put().
reboot: disable usermodehelper to prevent fs access
efivars: prevent oops on unload when efi is not enabled
Allow setting of number of raw devices as a module parameter
Introduce CONFIG_GOOGLE_FIRMWARE
driver: Google Memory Console
driver: Google EFI SMI
x86: Better comments for get_bios_ebda()
x86: get_bios_ebda_length()
misc: fix ti-st build issues
params.c: Use new strtobool function to process boolean inputs
debugfs: move to new strtobool
...
Fix up trivial conflicts in fs/debugfs/file.c due to the same patch
being applied twice, and an unrelated cleanup nearby.
Introduce generic .prepare() and .complete() power management
callbacks, currently missing, that can be used by subsystems and
power domains and export them. Provide NULL definitions of all
the generic system sleep callbacks for CONFIG_PM_SLEEP unset.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
If device drivers allocate substantial amounts of memory (above 1 MB)
in their hibernate .freeze() callbacks (or in their legacy suspend
callbcks during hibernation), the subsequent creation of hibernate
image may fail due to the lack of memory. This is the case, because
the drivers' .freeze() callbacks are executed after the hibernate
memory preallocation has been carried out and the preallocated amount
of memory may be too small to cover the new driver allocations.
Unfortunately, the drivers' .prepare() callbacks also are executed
after the hibernate memory preallocation has completed, so they are
not suitable for allocating additional memory either. Thus the only
way a driver can safely allocate memory during hibernation is to use
a hibernate/suspend notifier. However, the notifiers are called
before the freezing of user space and the drivers wanting to use them
for allocating additional memory may not know how much memory needs
to be allocated at that point.
To let device drivers overcome this difficulty rework the hibernation
sequence so that the memory preallocation is carried out after the
drivers' .prepare() callbacks have been executed, so that the
.prepare() callbacks can be used for allocating additional memory
to be used by the drivers' .freeze() callbacks. Update documentation
to match the new behavior of the code.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Now that we have CONFIG_DYNAMIC_DEBUG there is no need for yet
another flag causing dev_dbg() and pr_debug() statements in the
core PM code to produce output. Moreover, CONFIG_PM_VERBOSE
causes so much output to be generated that it's not really useful
and almost no one sets it.
References: https://bugzilla.kernel.org/show_bug.cgi?id=23182
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* power-domains:
PM: Fix build issue in clock_ops.c for CONFIG_PM_RUNTIME unset
PM: Revert "driver core: platform_bus: allow runtime override of dev_pm_ops"
OMAP1 / PM: Use generic clock manipulation routines for runtime PM
PM / Runtime: Generic clock manipulation rountines for runtime PM (v6)
PM / Runtime: Add subsystem data field to struct dev_pm_info
OMAP2+ / PM: move runtime PM implementation to use device power domains
PM / Platform: Use generic runtime PM callbacks directly
shmobile: Use power domains for platform runtime PM
PM: Export platform bus type's default PM callbacks
PM: Make power domain callbacks take precedence over subsystem ones
* syscore:
PM: Remove sysdev suspend, resume and shutdown operations
PM / PowerPC: Use struct syscore_ops instead of sysdevs for PM
PM / UNICORE32: Use struct syscore_ops instead of sysdevs for PM
PM / AVR32: Use struct syscore_ops instead of sysdevs for PM
PM / Blackfin: Use struct syscore_ops instead of sysdevs for PM
ARM / Samsung: Use struct syscore_ops for "core" power management
ARM / PXA: Use struct syscore_ops for "core" power management
ARM / SA1100: Use struct syscore_ops for "core" power management
ARM / Integrator: Use struct syscore_ops for core PM
ARM / OMAP: Use struct syscore_ops for "core" power management
ARM: Use struct syscore_ops instead of sysdevs for PM in common code
wakeup_source_add() adds an item into wakeup_sources list.
There is no need to call synchronize_rcu() at this point.
Its only needed in wakeup_source_remove()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The "wakeup" device sysfs file is only created if CONFIG_PM_SLEEP
is set, so put it under CONFIG_PM_SLEEP and make a build warning
related to it go away.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Some drivers erroneously use request_firmware() from their ->resume()
(or ->thaw(), or ->restore()) callbacks, which is not going to work
unless the firmware has been built in. This causes system resume to
stall until the firmware-loading timeout expires, which makes users
think that the resume has failed and reboot their machines
unnecessarily. For this reason, make _request_firmware() print a
warning and return immediately with error code if it has been called
when tasks are frozen and it's impossible to start any new usermode
helpers.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Reviewed-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
The driver core tries to prevent race conditions between runtime PM
and driver removal from happening by incrementing the runtime PM
usage counter of the device and executing pm_runtime_barrier() before
running the bus notifier and the ->remove() callbacks provided by the
device's subsystem or driver. This guarantees that, if a future
runtime suspend of the device has been scheduled or a runtime resume
or idle request has been queued up right before the driver removal,
it will be canceled or waited for to complete and no other
asynchronous runtime suspend or idle requests for the device will be
put into the PM workqueue until the ->remove() callback returns.
However, it doesn't prevent resume requests from being queued up
after pm_runtime_barrier() has been called and it doesn't prevent
pm_runtime_resume() from executing the device subsystem's runtime
resume callback. Morever, it prevents the device's subsystem or
driver from putting the device into the suspended state by calling
pm_runtime_suspend() from its ->remove() routine. This turns out to
be a major inconvenience for some subsystems and drivers that want to
leave the devices they handle in the suspended state.
To really prevent runtime PM callbacks from racing with the bus
notifier callback in __device_release_driver(), which is necessary,
because the notifier is used by some subsystems to carry out
operations affecting the runtime PM functionality, use
pm_runtime_get_sync() instead of the combination of
pm_runtime_get_noresume() and pm_runtime_barrier(). This will resume
the device if it's in the suspended state and will prevent it from
being suspended again until pm_runtime_put_*() is called.
To allow subsystems and drivers to put devices into the suspended
state by calling pm_runtime_suspend() from their ->remove() routines,
execute pm_runtime_put_sync() after running the bus notifier in
__device_release_driver(). This will require subsystems and drivers
to make their ->remove() callbacks avoid races with runtime PM
directly, but it will allow of more flexibility in the handling of
devices during the removal of their drivers.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The platform_bus_set_pm_ops() operation is deprecated in favor of the
new device power domain infrastructre implemented in commit
7538e3db6e (PM: add support for device
power domains)
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
