All of lore.kernel.org
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: nommu: re-enable use of vexpress without ARCH_MULTIPLATFORM
Date: Wed, 09 Jan 2013 21:51:54 -0600	[thread overview]
Message-ID: <50EE3ADA.2070100@gmail.com> (raw)
In-Reply-To: <20130109204804.GS3931@n2100.arm.linux.org.uk>

On 01/09/2013 02:48 PM, Russell King - ARM Linux wrote:
> On Wed, Jan 09, 2013 at 02:39:36PM -0600, Rob Herring wrote:
>> On 01/09/2013 02:22 PM, Arnd Bergmann wrote:
>>> On Wednesday 09 January 2013, Nicolas Pitre wrote:
>>>> On Wed, 9 Jan 2013, Arnd Bergmann wrote:
>>>>
>>>>> On a related topic, I still think we should fix ARCH_MULTI_V7 not
>>>>> to select ARCH_VEXPRESS unconditionally and come up with a better
>>>>> way to avoid having an empty platform list to make 'allnoconfig'
>>>>> still work.
>>>>
>>>> The virtual guest platform support that Will and Marc did is small 
>>>> enough that it could always be selected in place of vexpress.
>>>
>>> But that only helps when ARMv7 is selected, unless we want to build
>>> it only for ARMv4, v5 or v6 kernels.
>>>
>>> Besides, the only reason we can't have a kernel without any platform
>>> selected is that the linker script has code in it to intentionally
>>> barf on that because it's guaranteed not to boot on any hardware.
>>>
>>> If we decide that building an allnoconfig without any platform
>>> is actually ok, we could just as well rip out that error statement.
>>>
>>
>> That patch is already posted, but Russell doesn't like it as you can
>> have a kernel that doesn't boot. You don't like the allno and randconfig
>> failures, so we're stuck. I think there are dozens of config options
>> that will make you not boot on any given platform, so failing to boot
>> because you did not select your machine is a non-issue.
> 
> What I actually suggested is that we should be aiming for the DT side
> of things to get to the point where DT is just another _single_ platform
> as far as that code goes, and that DT should describe the hardware
> sufficiently well that we don't have multiple machine_desc things to
> select via DT - so a DT kernel would have exactly one machine_desc (or
> maybe even zero! - with the linker script check conditional on !CONFIG_OF)
> 
> That then gets rid of the issue entirely.

I agree completely. I look at mach-highbank (and mach-virt) as what else
needs to be done in terms of refactoring or moving to DT. That's
certainly a long term goal, but what is the short term solution?

Rob

  reply	other threads:[~2013-01-10  3:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09 18:15 [PATCH] ARM: nommu: re-enable use of vexpress without ARCH_MULTIPLATFORM Jonathan Austin
2013-01-09 18:30 ` Nicolas Pitre
2013-01-09 18:41   ` Will Deacon
2013-01-09 19:17     ` [PATCH v2] " Jonathan Austin
2013-01-09 18:43 ` [PATCH] " Arnd Bergmann
2013-01-09 18:54   ` Nicolas Pitre
2013-01-09 20:22     ` Arnd Bergmann
2013-01-09 20:39       ` Rob Herring
2013-01-09 20:48         ` Russell King - ARM Linux
2013-01-10  3:51           ` Rob Herring [this message]
2013-01-10 10:16             ` Arnd Bergmann
2013-01-10 13:20               ` Christopher Covington
2013-01-10 13:45                 ` Marc Zyngier
2013-01-09 21:09         ` Nicolas Pitre
2013-01-09 21:00       ` Nicolas Pitre
2013-01-09 21:15         ` Arnd Bergmann
2013-01-09 21:37           ` Nicolas Pitre
2013-01-09 22:14             ` Arnd Bergmann

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=50EE3ADA.2070100@gmail.com \
    --to=robherring2@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.