> > > + * The driver of the device won't receive interrupts while this function is
> > > + * being executed.
> > > */
> > > @@ -696,13 +746,19 @@ int dpm_suspend_noirq(pm_message_t state
> > > suspend_device_irqs();
> > > mutex_lock(&dpm_list_mtx);
> > > list_for_each_entry_reverse(dev, &dpm_list, power.entry) {
> > > + dev->power.status = DPM_OFF_IRQ;
> > > error = device_suspend_noirq(dev, state);
> > > if (error) {
> > > pm_dev_err(dev, state, " late", error);
> > > + dev->power.status = DPM_OFF;
> > > + break;
> > > + }
> > > + if (async_error) {
> > > + error = async_error;
> > > break;
> >
> > async_error is 'interesting'. How does locking work in noirq case?
>
> It's racy, a little bit. :-)
>
> If two async drivers return errors exactly at the same time, one of them will
> win the race, but it doesn't really matter which one wins as long as
> async_error is different from zero as a result. And it will be, since it's
> an 'int' and the integrity of these is guaranteed.
Rather than relying on atomicity of 'int' (where half of kernel
hackers says it is and second half says it is not), can we just use
atomic_t? It compiles to same code on sane architectures, and serves
as documentation/warning...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
