All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: nommu build failures on ARM in linux-next
Date: Thu, 29 May 2014 20:05:42 -0400	[thread overview]
Message-ID: <20140530000542.GB2999@windriver.com> (raw)
In-Reply-To: <20140529234012.GL3693@n2100.arm.linux.org.uk>

[Re: nommu build failures on ARM in linux-next] On 30/05/2014 (Fri 00:40) Russell King - ARM Linux wrote:

> On Thu, May 29, 2014 at 07:55:34PM +0100, Russell King - ARM Linux wrote:
> > On Thu, May 29, 2014 at 12:53:51PM -0400, Paul Gortmaker wrote:
> > > Hi Russell,
> > > 
> > > The allnoconfig builds in linux-next fail because __clear_cr
> > > lives in mmu.c without any stub or similar in nommu.c
> > > 
> > > Introduced by:
> > > 
> > > commit 247e4fff3aa927ad069447e6da05bb966b70dece
> > > Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > > Date:   Sun Apr 13 18:57:29 2014 +0100
> > > 
> > >     ARM: provide common method to clear bits in CPU control register
> > >     
> > > Sample failure:
> > >   http://kisskb.ellerman.id.au/kisskb/buildresult/11264405/
> > 
> > ALIGNMENT_TRAP depends on CPU_CP15_MMU, so it's quite reasonable that
> > __clear_cr should exist in this case - but it doesn't because it's in
> > mmu.c.  I guess we need __clear_cr moved to arch/arm/kernel/setup.c.
> 
> I've been looking at doing this, and while it can be done by applying
> a patch on top, that's not my preferred solution.
> 
> However, my preferred solution (which is to fix the commit) needs a bit
> of rework of the patch series, and given the number of patches I'm
> carrying right now, I'm just going to drop the branch out of linux-next
> and hold it off until the following merge window instead.
> 
> Even so, I suspect even with this build problem solved, that's not going
> to be the end of the story for noMMU breakage... it's certainly something
> that gets very little testing by anyone.  I suspect it should be removed
> from the mainline kernel tree rather than being a constant source of these
> kinds of problems.

One doesn't have to look very far to see that I'm in favour of pushing
obsolete options/drivers/subsystems off a cliff if I can get away with
it, so that we don't get crushed under our own weight/complexity.

So if you really think it is time for ARM noMMU to go, I'll volunteer to
craft up a removal series for you for 3.17 -- just say the word.

Paul.
--

> 
> -- 
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

WARNING: multiple messages have this Message-ID (diff)
From: paul.gortmaker@windriver.com (Paul Gortmaker)
To: linux-arm-kernel@lists.infradead.org
Subject: nommu build failures on ARM in linux-next
Date: Thu, 29 May 2014 20:05:42 -0400	[thread overview]
Message-ID: <20140530000542.GB2999@windriver.com> (raw)
In-Reply-To: <20140529234012.GL3693@n2100.arm.linux.org.uk>

[Re: nommu build failures on ARM in linux-next] On 30/05/2014 (Fri 00:40) Russell King - ARM Linux wrote:

> On Thu, May 29, 2014 at 07:55:34PM +0100, Russell King - ARM Linux wrote:
> > On Thu, May 29, 2014 at 12:53:51PM -0400, Paul Gortmaker wrote:
> > > Hi Russell,
> > > 
> > > The allnoconfig builds in linux-next fail because __clear_cr
> > > lives in mmu.c without any stub or similar in nommu.c
> > > 
> > > Introduced by:
> > > 
> > > commit 247e4fff3aa927ad069447e6da05bb966b70dece
> > > Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > > Date:   Sun Apr 13 18:57:29 2014 +0100
> > > 
> > >     ARM: provide common method to clear bits in CPU control register
> > >     
> > > Sample failure:
> > >   http://kisskb.ellerman.id.au/kisskb/buildresult/11264405/
> > 
> > ALIGNMENT_TRAP depends on CPU_CP15_MMU, so it's quite reasonable that
> > __clear_cr should exist in this case - but it doesn't because it's in
> > mmu.c.  I guess we need __clear_cr moved to arch/arm/kernel/setup.c.
> 
> I've been looking at doing this, and while it can be done by applying
> a patch on top, that's not my preferred solution.
> 
> However, my preferred solution (which is to fix the commit) needs a bit
> of rework of the patch series, and given the number of patches I'm
> carrying right now, I'm just going to drop the branch out of linux-next
> and hold it off until the following merge window instead.
> 
> Even so, I suspect even with this build problem solved, that's not going
> to be the end of the story for noMMU breakage... it's certainly something
> that gets very little testing by anyone.  I suspect it should be removed
> from the mainline kernel tree rather than being a constant source of these
> kinds of problems.

One doesn't have to look very far to see that I'm in favour of pushing
obsolete options/drivers/subsystems off a cliff if I can get away with
it, so that we don't get crushed under our own weight/complexity.

So if you really think it is time for ARM noMMU to go, I'll volunteer to
craft up a removal series for you for 3.17 -- just say the word.

Paul.
--

> 
> -- 
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.

  reply	other threads:[~2014-05-30  0:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-29 16:53 nommu build failures on ARM in linux-next Paul Gortmaker
2014-05-29 16:53 ` Paul Gortmaker
2014-05-29 18:55 ` Russell King - ARM Linux
2014-05-29 18:55   ` Russell King - ARM Linux
2014-05-29 23:40   ` Russell King - ARM Linux
2014-05-29 23:40     ` Russell King - ARM Linux
2014-05-30  0:05     ` Paul Gortmaker [this message]
2014-05-30  0:05       ` Paul Gortmaker
2014-05-30  7:58     ` Robert Schwebel
2014-05-30  7:58       ` Robert Schwebel
2014-05-30  8:02     ` Uwe Kleine-König
2014-05-30  8:02       ` Uwe Kleine-König
2014-06-02  7:19       ` Uwe Kleine-König
2014-06-02  7:19         ` Uwe Kleine-König

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=20140530000542.GB2999@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /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.