[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090223122832.GB31427@elte.hu>
Date: Mon, 23 Feb 2009 13:28:32 +0100
From: Ingo Molnar <mingo@...e.hu>
To: "Rafael J. Wysocki" <rjw@...k.pl>
Cc: Johannes Berg <johannes@...solutions.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Jeremy Fitzhardinge <jeremy@...p.org>,
pm list <linux-pm@...ts.linux-foundation.org>,
Len Brown <lenb@...nel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts during
suspend-resume
* Rafael J. Wysocki <rjw@...k.pl> wrote:
> > > Index: linux-2.6/arch/x86/kernel/apm_32.c
> > > ===================================================================
> > > --- linux-2.6.orig/arch/x86/kernel/apm_32.c
> > > +++ linux-2.6/arch/x86/kernel/apm_32.c
> >
> > > +
> > > + suspend_device_irqs();
> > > device_power_down(PMSG_SUSPEND);
> > > +
> > > + local_irq_disable();
> >
> > hm, this is a very repetitive pattern, all around the various
> > suspend/resume variants. Might make sense to make:
> >
> > device_power_down(PMSG_SUSPEND);
> >
> > do the irq line disabling plus the local irq disabling
> > automatically. That also means it cannot be forgotten. The
> > symmetric action should happen for PMSG_RESUME.
> >
> > Is there ever a case where we want a different pattern?
>
> Even if there's no such case, I prefer to call
> local_irq_disable() explicitly in here, so that it's clearly
> known where it happens to anyone reading this code.
That property can be implied in the function name:
device_power_down_irq_disable(PMSG_SUSPEND);
Open-coding it, if it looks the same in all the cases just
increases the chances that someone somewhere copies them
incorrectly.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists