public inbox for linux-sh@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: HOTPLUG_CPU is not defined
Date: Wed, 01 Oct 2008 10:45:56 +0000	[thread overview]
Message-ID: <20081001104556.GA23048@linux-sh.org> (raw)
In-Reply-To: <6iabdp61h3.fsf@mars.wyplay.int>

On Wed, Oct 01, 2008 at 10:27:14AM +0200, Francis Moreau wrote:
> On Tue, Sep 30, 2008 at 8:55 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> > On Tue, Sep 30, 2008 at 08:51:08PM +0200, Francis Moreau wrote:
> >> On Tue, Sep 30, 2008 at 8:24 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> >> > On Tue, Sep 30, 2008 at 06:30:00PM +0200, Francis Moreau wrote:
> >> >> Any reasons why this macro is not defined for SH ?
> >> >>
> >> > Yes, it's not implemented.
> >> >
> >>
> >> Well, it doesn't really matter and it avoids some warnings emitted
> >> by Kconfig because of this in kernel/power/Kconfig:
> >>
> >>
> >> config PM_SLEEP_SMP
> >>         bool
> >>         ....
> >>         select HOTPLUG_CPU
> >>         default y
> >>
> > We don't provide symbols for stuff we don't support. The fact people
> > screw up select usage is nothing new, which is part of the reason it
> > should generally be avoided.
> >
> 
> Still we could define it with a default value to 'n', in that case the symbol
> is not provided for the code and kconfig doesn't generate the warning
> anymore.
> 
Except that 'select' negates that entirely if the symbol is defined,
regardless of whether we give it a value or not.  Presently we don't
define any of the symbols that PM_SLEEP_SMP depends on:

	config PM_SLEEP_SMP
		bool
		depends on SMP
		depends on ARCH_SUSPEND_POSSIBLE || ARCH_HIBERNATION_POSSIBLE
		depends on PM_SLEEP
		select HOTPLUG_CPU

If any of those dependencies change, the select will automatically enable
HOTPLUG_CPU for us if we provide the symbol, regardless of whether it's
just a bool or default n or whatever else.

If you want this warning to go away, either have the select dropped or get the
Kconfig people to fix the dependency tracking. Again, we will not be papering
around this in the architecture code. We do not make a habit of "fixing" things
to make warnings go away when the warnings themselves are bogus. While the
kernel janitors are fond of this sort of mindless work, it is actively harmful
and doesn't help anything in the least.

      parent reply	other threads:[~2008-10-01 10:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-30 16:30 HOTPLUG_CPU is not defined Francis Moreau
2008-09-30 18:24 ` Paul Mundt
2008-09-30 18:51 ` Francis Moreau
2008-09-30 18:55 ` Paul Mundt
2008-10-01  8:27 ` Francis Moreau
2008-10-01 10:45 ` Paul Mundt [this message]

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=20081001104556.GA23048@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=linux-sh@vger.kernel.org \
    /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