[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200810212139.39470.rjw@sisk.pl>
Date: Tue, 21 Oct 2008 21:39:38 +0200
From: "Rafael J. Wysocki" <rjw@...k.pl>
To: Andi Kleen <andi@...stfloor.org>
Cc: Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
David Howells <dhowells@...hat.com>
Subject: Re: [announce] new tree: "fix all build warnings, on all configs"
On Tuesday, 21 of October 2008, Andi Kleen wrote:
> On Tue, Oct 21, 2008 at 01:17:16PM +0200, Ingo Molnar wrote:
> >
> > * Andi Kleen <andi@...stfloor.org> wrote:
> >
> > > > * acpi_pm_disable_gpes - Disable the GPEs.
> > > > */
> > > > -static int acpi_pm_disable_gpes(void)
> > > > +static inline int acpi_pm_disable_gpes(void)
> > >
> > > Just to satisfy my curiosity, what compiler warning does marking
> > > functions inline fix?
> >
> > the commit log below explains the situation. The warning exposed a maze
> > of #ifdefs in drivers/acpi/sleep/main.c. It's not the warning we need to
> > "fix" but that maze, obviously.
>
> Thanks. That makes sense,
>
> I also agree with you that the better alternative would be
> to just always force SUSPEND together with ACPI.
>
> I suspect the code delta wouldn't be very large compared to the rest
> of the ACPI code.
Is that _really_ necessary?
I mean, do the warnings appear in any case that's not theoretically impossible?
Rafael
--
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