[PATCH 01/11] usb: chipidea: Add power management support

Russell King - ARM Linux linux at arm.linux.org.uk
Mon Oct 14 06:44:39 EDT 2013


On Mon, Oct 14, 2013 at 03:55:48PM +0800, Peter Chen wrote:
> On Mon, Oct 14, 2013 at 10:04:58AM +0200, Lothar Waßmann wrote:
> > Hi,
> > 
> > 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.
> > > 
> > [...]
> > > +#ifdef CONFIG_PM
> > > +static int ci_controller_suspend(struct device *dev)
> > > +{
> > > +	struct ci_hdrc *ci = dev_get_drvdata(dev);
> > > +
> > > +	dev_dbg(dev, "at %s\n", __func__);
> > > +
> > > +	if (atomic_read(&ci->in_lpm))
> > > +		return 0;
> > > +
> > What does this 'atomic_read()' buy you over just testing/assinging a
> > simple integer. Note that just because the function has 'atomic' in
> > its name the sequence:
> > 	atomic_read();
> > ...
> > 	atomic_set();
> > does not magically become an atomic operation.
> 
> I just want the read and set are atomic, not the operations
> between atomic_read and atomic_set.

There is nothing magical about atomic_read() or atomic_set():

#define atomic_read(v)  (*(volatile int *)&(v)->counter)
#define atomic_set(v,i) (((v)->counter) = (i))

You might as well just read and write the variable directly if you're
going to do this.  The atomicity of atomic_t comes from the *other*
operations which can be done on an atomic_t, not from some magical
macro which starts with the name "atomic_".

Lesson 1: whenever you see atomic_read() and atomic_set() in a patch
be very very very suspicious; it's 99% of times plainly wrong and a
sign of something being totally broken.



More information about the linux-arm-kernel mailing list