Devicetree
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
To: Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: Boot interface for device trees on ARM
Date: Wed, 09 Jun 2010 09:09:54 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1006090841310.30664@xanadu.home> (raw)
In-Reply-To: <201006091226.15438.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>

On Wed, 9 Jun 2010, Jeremy Kerr wrote:

> Hi Nicolas,
> 
> > > If we're planning to keep the machine IDs around (even if they are now
> > > per- SoC), I'd like to know what would be left using them. The only
> > > thing that I can see that we currently use is io_pg_offset for the
> > > DEBUG_LL builds, and that isn't a convincing case to keep them.
> > 
> > Why not?
> 
> Because it's something we can justifiably replace with a single compile-time 
> constant, since it's only for low-level debug. I don't see that as a reason 
> for keeping these machine numbers around if that's all they're used for.

it's not only for that.  As I said below:

> > Kernel infrastructure backward compatibility means that you need to keep
> > struct machine_desc instances around.  Granted, for the DT case, many of
> > the members could be NULL or initialized with dummy stubs.  But that is
> > very cheap to keep around, and that allows the same kernel binary to be
> > able to use both the DT boot and the legacy boot.
> 
> ... this is a good point; if it helps with the transition, then this is 
> probably a decent reason to keep it in the interface.
> 
> I'd like to keep my "only use the device tree" value (MACH_TYPE_DT = 
> 0xffffffff) though, so we don't needlessly allocate machine numbers where they 
> aren't actually used.

There isn't such thing as "only use the device tree".  To keep the low 
level code _unmodified_ and _useful_ you'll have to allocate a number 
per machine class otherwise you won't be able to support more than one 
machine class in the same kernel binary at the same time.  You can't 
just say that those machine IDs aren't used.

I don't see the point of crippling that existing support just for the 
sake of using 0xffffffff, if it is only to save you a few machine ID 
registrations.  Because let's be honest, we won't DT-ify old machine 
targets anytime soon.  So only the recent and future machine classes 
will require a number, and that's probably on the order of 2 or 3 new 
IDs per year (meaning less than 5 minutes on RMK's automatic 
registration website).  Certainly much much less than the current 2000+ 
IDs that have been already allocated to date.


Nicolas

  parent reply	other threads:[~2010-06-09 13:09 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18  2:54 Boot interface for device trees on ARM Jeremy Kerr
2010-05-18  4:34 ` Nicolas Pitre
     [not found]   ` <alpine.LFD.2.00.1005172341200.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-18  5:24     ` Jeremy Kerr
     [not found]       ` <201005181324.45701.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-05-18  8:49         ` David Gibson
2010-05-18 12:24           ` Nicolas Pitre
2010-05-18 14:06             ` Jason McMullan
     [not found]               ` <AANLkTikg4rQdnbFxBOUkGc_0DrKqRkp9raZ8Ck5xkLG4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-19  0:21                 ` David Gibson
2010-05-19  7:25             ` Mitch Bradley
     [not found]             ` <alpine.LFD.2.00.1005180802010.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19  0:28               ` David Gibson
2010-05-19  1:28                 ` Nicolas Pitre
     [not found]                   ` <alpine.LFD.2.00.1005182109180.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19  6:50                     ` David Gibson
2010-05-19 14:45                       ` Grant Likely
2010-05-19  1:41                 ` Jamie Lokier
     [not found]                   ` <20100519014118.GD2318-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-05-19  7:12                     ` David Gibson
2010-05-19 14:21                     ` Grant Likely
2010-05-19  8:50               ` Jeremy Kerr
2010-05-18 11:57         ` Nicolas Pitre
     [not found]           ` <alpine.LFD.2.00.1005180742500.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19 12:13             ` Grant Likely
     [not found]               ` <AANLkTinsOSI_TIc7Jyy4QFuFaS2d-fi0y3LMuITLyG3N-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-19 16:45                 ` Jamie Lokier
     [not found]                   ` <20100519164534.GE1693-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-05-19 17:10                     ` Grant Likely
2010-05-19 17:32                       ` M. Warner Losh
2010-05-19 11:57     ` Grant Likely
2010-05-19 12:08       ` Russell King - ARM Linux
     [not found]       ` <AANLkTilJl9_NHiT1LITG7UbA9S7OYsnGMcDAsFEEx5Ob-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-19 17:52         ` Nicolas Pitre
     [not found]           ` <alpine.LFD.2.00.1005191055180.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-19 20:08             ` Jamie Lokier
     [not found]               ` <20100519200819.GF1693-yetKDKU6eevNLxjTenLetw@public.gmane.org>
2010-05-19 20:22                 ` Nicolas Pitre
     [not found]                   ` <alpine.LFD.2.00.1005191614580.12758-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-05-21 16:24                     ` John Rigby
2010-05-21 16:27                       ` Jamie Bennett
     [not found]                       ` <AANLkTil3vDAN4QIJJImk8MnQklisqFJq_RBc7c9VEZxl-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-05-21 19:59                         ` Russell King - ARM Linux
2010-06-03 21:12                         ` Grant Likely
2010-06-04 20:01             ` Grant Likely
     [not found]               ` <AANLkTilhqg270l-_m9raalqAPPRhvLJD9omHe8ysgLjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-04 20:33                 ` John Rigby
2010-06-04 20:37                   ` Jon Loeliger
     [not found]                     ` <E1OKdeH-00053a-U2-CYoMK+44s/E@public.gmane.org>
2010-06-04 21:07                       ` Grant Likely
2010-06-05  1:33                 ` Jeremy Kerr
     [not found]                   ` <201006050933.06714.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-06-05  2:29                     ` Nicolas Pitre
     [not found]                       ` <alpine.LFD.2.00.1006042212400.30664-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-06-05  5:59                         ` Grant Likely
2010-06-09  4:26                         ` Jeremy Kerr
     [not found]                           ` <201006091226.15438.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-06-09 13:09                             ` Nicolas Pitre [this message]
     [not found] ` <201005181054.32325.jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2010-05-19 11:45   ` Grant Likely

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=alpine.LFD.2.00.1006090841310.30664@xanadu.home \
    --to=nico-vtqb6hgkxmzr7s880joybq@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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