From: Paul Mundt <lethal@linux-sh.org>
To: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Russell King <rmk@arm.linux.org.uk>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Michael Neuling <mikey@neuling.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org,
Grant Likely <grant.likely@secretlab.ca>,
linux-sh@vger.kernel.org
Subject: Re: linux-next: manual merge of the powerpc tree with the arm tree
Date: Mon, 12 Mar 2012 10:12:25 +0900 [thread overview]
Message-ID: <20120312011224.GA9503@linux-sh.org> (raw)
In-Reply-To: <4F5A350F.3090905@calxeda.com>
On Fri, Mar 09, 2012 at 10:51:27AM -0600, Rob Herring wrote:
> On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> >> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> >>> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> >>> I remove it, then I get Kconfig warnings:
> >>>
> >>> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> >>> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
> >>
> >> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
> >
> > Nope, Grant patch didn't mention a dependency.
>
> My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
> simple solution was to just make it hidden. It wasn't clear if this was
> desired or not for other arches at the time. There is a mixture of
> settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
> it user selectable for 64-bit.
>
> I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
> a hidden option. It really just needs the okay from SuperH folks.
>
We basically want it always-enabled for 32-bit and it doesn't matter much
about 64-bit. In the future I'll probably fix up the 64-bit stuff to use
it too and then we'll just leave it on all the time, but it's not such a
big deal if it's not visible for enabling on 64-bit at the moment given
that it's probably broken there at the moment.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Mundt <lethal@linux-sh.org>
To: Rob Herring <rob.herring@calxeda.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Russell King <rmk@arm.linux.org.uk>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Michael Neuling <mikey@neuling.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org,
Grant Likely <grant.likely@secretlab.ca>,
linux-sh@vger.kernel.org
Subject: Re: linux-next: manual merge of the powerpc tree with the arm tree
Date: Mon, 12 Mar 2012 01:12:25 +0000 [thread overview]
Message-ID: <20120312011224.GA9503@linux-sh.org> (raw)
In-Reply-To: <4F5A350F.3090905@calxeda.com>
On Fri, Mar 09, 2012 at 10:51:27AM -0600, Rob Herring wrote:
> On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> >> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> >>> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> >>> I remove it, then I get Kconfig warnings:
> >>>
> >>> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> >>> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
> >>
> >> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
> >
> > Nope, Grant patch didn't mention a dependency.
>
> My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
> simple solution was to just make it hidden. It wasn't clear if this was
> desired or not for other arches at the time. There is a mixture of
> settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
> it user selectable for 64-bit.
>
> I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
> a hidden option. It really just needs the okay from SuperH folks.
>
We basically want it always-enabled for 32-bit and it doesn't matter much
about 64-bit. In the future I'll probably fix up the 64-bit stuff to use
it too and then we'll just leave it on all the time, but it's not such a
big deal if it's not visible for enabling on 64-bit at the moment given
that it's probably broken there at the moment.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Mundt <lethal@linux-sh.org>
To: Rob Herring <rob.herring@calxeda.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Michael Neuling <mikey@neuling.org>,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-next@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org,
Russell King <rmk@arm.linux.org.uk>
Subject: Re: linux-next: manual merge of the powerpc tree with the arm tree
Date: Mon, 12 Mar 2012 10:12:25 +0900 [thread overview]
Message-ID: <20120312011224.GA9503@linux-sh.org> (raw)
In-Reply-To: <4F5A350F.3090905@calxeda.com>
On Fri, Mar 09, 2012 at 10:51:27AM -0600, Rob Herring wrote:
> On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> >> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> >>> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> >>> I remove it, then I get Kconfig warnings:
> >>>
> >>> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> >>> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
> >>
> >> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
> >
> > Nope, Grant patch didn't mention a dependency.
>
> My opinion is that SPARSE_IRQ shouldn't be user visible option, and the
> simple solution was to just make it hidden. It wasn't clear if this was
> desired or not for other arches at the time. There is a mixture of
> settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves
> it user selectable for 64-bit.
>
> I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ
> a hidden option. It really just needs the okay from SuperH folks.
>
We basically want it always-enabled for 32-bit and it doesn't matter much
about 64-bit. In the future I'll probably fix up the 64-bit stuff to use
it too and then we'll just leave it on all the time, but it's not such a
big deal if it's not visible for enabling on 64-bit at the moment given
that it's probably broken there at the moment.
next prev parent reply other threads:[~2012-03-12 1:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 1:04 linux-next: manual merge of the powerpc tree with the arm tree Stephen Rothwell
2012-03-08 1:04 ` Stephen Rothwell
2012-03-08 1:04 ` Stephen Rothwell
2012-03-08 2:33 ` Michael Neuling
2012-03-08 2:33 ` Michael Neuling
2012-03-08 3:51 ` Stephen Rothwell
2012-03-08 3:51 ` Stephen Rothwell
2012-03-08 5:52 ` Benjamin Herrenschmidt
2012-03-08 5:52 ` Benjamin Herrenschmidt
2012-03-08 23:35 ` Benjamin Herrenschmidt
2012-03-08 23:35 ` Benjamin Herrenschmidt
2012-03-09 0:39 ` Russell King
2012-03-09 0:39 ` Russell King
2012-03-09 3:13 ` Benjamin Herrenschmidt
2012-03-09 3:13 ` Benjamin Herrenschmidt
2012-03-09 16:51 ` Rob Herring
2012-03-09 16:51 ` Rob Herring
2012-03-09 16:51 ` Rob Herring
2012-03-12 1:12 ` Paul Mundt [this message]
2012-03-12 1:12 ` Paul Mundt
2012-03-12 1:12 ` Paul Mundt
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=20120312011224.GA9503@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=benh@kernel.crashing.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
--cc=paulus@samba.org \
--cc=rmk@arm.linux.org.uk \
--cc=rob.herring@calxeda.com \
--cc=sfr@canb.auug.org.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.