From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: Proposal: mach-dt
Date: Wed, 3 Jul 2013 16:51:04 +0200 [thread overview]
Message-ID: <201307031651.05181.arnd@arndb.de> (raw)
In-Reply-To: <51D437C6.9000909@arm.com>
On Wednesday 03 July 2013, Marc Zyngier wrote:
> On 03/07/13 15:11, Christopher Covington wrote:
> > On 07/03/2013 10:10 AM, Marc Zyngier wrote:
> >> On 03/07/13 15:03, Christopher Covington wrote:
> >>> On 07/03/2013 05:20 AM, Marc Zyngier wrote:
> >>>> On 03/07/13 09:18, Alexander Shiyan wrote:
> >>>>
> >>>> Hi Alexander,
> >>>>
> >>>>> More and more platforms are now using devicetree.
> >>>>> Ideally the platform code contains only one function "of_platform_populate".
> >>>>> My idea is to make a generic architecture (mach-dt) with the call then add support
> >>>>> for compatible subarchitectures as they become available in "compatible"-property.
> >>>>> Your opinion?
> >>>>
> >>>> Well, my (admittedly partial) opinion is that mach-virt is an incredibly
> >>>> nicer sounding name, 'specially as you can mistype it as mach-triv.
> >>>
> >>> As mentioned before, I disagree and would love to see the the
> >>> virtualization-specific name replaced by something more suitably generic.
> >>
> >> I think you're missing the point. The right fix would to remove it
> >> entirely and make it the basic default. There are patches for that already.
> >
> > Where?
>
> There were patches from Arnd (CC-ed) a while ago, moving some of the
> mach-virt SMP stuff to smp.c. Don't have the pointers handy, but surely
> Arnd knows where they are.
>
> Once SMP is done, the rest should be pretty trivial.
In 3.11, mach-virt is basically empty. The SMP functions were moved out
already and everything is optional, so you should not need to even build
arch/arm/mach-virt/virt.c any more, except to get a particular platform
name in /proc/cpuinfo.
We have a couple of real (as opposed to virtual) platforms that are
almost at the same point and only have one or two functions left in them.
I'm definitely open for suggestions what to do about them. Putting all
the trivial files into a shared directory would be one possibility,
as would removing the files entirely by making the code more generic.
Note that arm64 platforms by definition have no such machine specific
code, and they should be able to boot a 32 bit kernel as well without
needing it.
Arnd
prev parent reply other threads:[~2013-07-03 14:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 8:18 Proposal: mach-dt Alexander Shiyan
2013-07-03 9:20 ` Marc Zyngier
2013-07-03 14:03 ` Christopher Covington
2013-07-03 14:10 ` Marc Zyngier
2013-07-03 14:11 ` Christopher Covington
2013-07-03 14:40 ` Marc Zyngier
2013-07-03 14:51 ` Arnd Bergmann [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=201307031651.05181.arnd@arndb.de \
--to=arnd@arndb.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).