On Sat, Oct 12, 2013 at 05:35:03PM +0800, Peter Chen wrote: > This commit adds runtime and system power management support for > chipidea core. The runtime pm support is controlled by glue > layer, it can be enabled by flag CI_HDRC_SUPPORTS_RUNTIME_PM. Let's look at the locking. 1. Runtime PM. These callbacks are locked with a spinlock, which holds dev->power.lock. This lock is taken either with or without disabling IRQs depending on whether runtime PM is IRQ safe or not. 2. Normal PM. These callbacks are locked by holding dev->mutex. Now, there's a little bit of protection between these two operations - when normal PM places a device into a low power state, it 'gets' a reference on the runtime PM to ensure no runtime PM transitions occur while normal PM is active. (See pm_runtime_get_noresume() in device_prepare().) This is only dropped when the normal PM resumes the device. Moreover, all runtime PM events are flushed before the suspend callback occurs (see the pm_runtime_barrier() in __device_suspend()). What that means is that you can't receive any runtime PM events while you are in your suspend/resume callbacks. So, each call is mutually exclusive. So, runtime PM callbacks vs normal PM callbacks for any single device are all called with mutual exclusion - you won't have two running at any time. Hence, for the reasons stated previously about the non-atomic nature of atomic_read()/atomic_set(), there's even more reasons that their use here is just mere obfuscation: the accesses to this state tracking variable is already guaranteed to be single-threaded by core code, so the use of atomic_read()/atomic_set() just adds additional needless confusion to this code. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
