From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
linux-next@vger.kernel.org, sfr@canb.auug.org.au,
linux-kernel@vger.kernel.org, apw@shadowen.org,
Alan Stern <stern@rowland.harvard.edu>,
Len Brown <lenb@kernel.org>, Greg KH <greg@kroah.com>
Subject: Re: linux-next20080314 build fails with !CONFIG_PM
Date: Fri, 14 Mar 2008 23:37:11 +0100 [thread overview]
Message-ID: <200803142337.12605.rjw@sisk.pl> (raw)
In-Reply-To: <20080314150554.1b79a6ed.akpm@linux-foundation.org>
On Friday, 14 of March 2008, Andrew Morton wrote:
> On Fri, 14 Mar 2008 13:27:10 +0530
> Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> > The next-20080314 tree build fails
> >
> > drivers/serial/serial_core.c: In function `uart_add_one_port':
> > drivers/serial/serial_core.c:2359: error: invalid lvalue in assignment
> > make[2]: *** [drivers/serial/serial_core.o] Error 1
> >
> > The config # CONFIG_PM was not set.The code which is causing the
> > build failure is
> >
> > device_can_wakeup(tty_dev) = 1;
> >
> > when the CONFIG_PM is set the macro is preprocessed as
> >
> > #define device_can_wakeup(dev) \
> > ((dev)->power.can_wakeup)
> >
> > and when not set, it becomes 0 = 1
> >
> > #define device_can_wakeup(dev) 0
Kamalesh, thanks for reporting the problem.
> Caused by Alan's "PM: make wakeup flags available whenever CONFIG_PM is
> set" which I assume Len merged.
It's in the Greg's tree actually.
> Sorry, but that code should be dragged out and shot. Doing this:
>
> > device_can_wakeup(tty_dev) = 1;
>
> is just gross and stupid. It looks daft, it isn't C and it *requires* that
> device_can_wakeup() be implemented as a macro, which totally busts any
> concept of abstraction.
>
>
> The code previously had quite reasonable accessors:
>
> #define device_set_wakeup_enable(dev,val) \
> ((dev)->power.should_wakeup = !!(val))
> #define device_may_wakeup(dev) \
> (device_can_wakeup(dev) && (dev)->power.should_wakeup)
>
> can we please go back to that scheme? Please also convert all these
> magical macros into inlined C functions. One reason is that this:
>
> +#define device_init_wakeup(dev,val) \
> + do { \
> + device_can_wakeup(dev) = !!(val); \
> + device_set_wakeup_enable(dev,val); \
> + } while(0)
>
> is buggy. It evaluates its arguments multiple times and will cause
> failures when passed expressions which have side-effects.
>
> Alan, please also pass all future patches through checkpatch - there is no
> need to be adding trivial coding-style errors in this day and age.
>
> Thanks.
Well, Greg please drop the "PM: make wakeup flags available whenever CONFIG_PM
is set" and Alan please resubmit the patch with the problems pointed out by
Andrew fixed.
In fact I'd even prefer it to be two patches, one that moves should_wakeup and
the related macros out of the CONFIG_PM_SLEEP #ifdef, because that's what fixes
the problem described in the changelog, and one that makes the remaining
changes with a separate changelog.
Thanks,
Rafael
next prev parent reply other threads:[~2008-03-14 22:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-14 7:57 linux-next20080314 build fails with !CONFIG_PM Kamalesh Babulal
2008-03-14 22:05 ` Andrew Morton
2008-03-14 22:37 ` Rafael J. Wysocki [this message]
2008-03-15 21:53 ` [PATCH 0/3] PM wakeup flags revisited Alan Stern
2008-03-15 21:53 ` [PATCH 1/3] Fix misuse of wakeup flag accessors in serial core Alan Stern
2008-03-15 21:53 ` [PATCH 2/3] PM: make wakeup flags available whenever CONFIG_PM is set (ver 2) Alan Stern
2008-03-15 21:54 ` [PATCH 3/3] PM: convert wakeup flag accessors to inline functions Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200803142337.12605.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=greg@kroah.com \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox