All of lore.kernel.org
 help / color / mirror / Atom feed
From: david@gibson.dropbear.id.au (David Gibson)
To: linux-arm-kernel@lists.infradead.org
Subject: Boot interface for device trees on ARM
Date: Wed, 19 May 2010 10:21:41 +1000	[thread overview]
Message-ID: <20100519002141.GF25892@yookeroo> (raw)
In-Reply-To: <AANLkTikg4rQdnbFxBOUkGc_0DrKqRkp9raZ8Ck5xkLG4@mail.gmail.com>

On Tue, May 18, 2010 at 10:06:38AM -0400, Jason McMullan wrote:
> With respect to machine IDs, why not have our cake and eat it too?
> 
> (NOTE: This proposal assumes that the boot code has already
>        determined whether ATAGs or a DT has been passed to
>        the kernel, and that ATAG and DT machine IDs are in
>        the same namespace)
> 
> 1) We already have machine names in the mach-types file, and we
> can propose that those are used as the top-level 'compatible'
> tags for the DTs.
> 
> ...
>    compatible = "openrd\000kirkwood\000armv6\000arm"
> ...

That sounds like a good idea.  Except that you should probably prefix
the ARM machine name with something (e.g. "linux,arm-machine-XXXX"),
both to meet the normal OF "vendor,type" convention for compatible
values, and to make sure to avoid any conflicts wth things of other
architectures.

Oh, also, dtc supports nicer syntax for NULL separated stringlists
like that, you can go:
	compatible = "openrd", "kirkwood", "armv6", "arm";

> 2) We can trivially generate a name-to-machine ID hash table from
> the mach-types file (CRC32 of the name, or some other hash)

gperf...

The rest I'm not so sure about, I don't know arch/arm well enough.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: Jason McMullan <jason.mcmullan-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
Cc: nicolas.pitre-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org,
	Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
Subject: Re: Boot interface for device trees on ARM
Date: Wed, 19 May 2010 10:21:41 +1000	[thread overview]
Message-ID: <20100519002141.GF25892@yookeroo> (raw)
In-Reply-To: <AANLkTikg4rQdnbFxBOUkGc_0DrKqRkp9raZ8Ck5xkLG4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tue, May 18, 2010 at 10:06:38AM -0400, Jason McMullan wrote:
> With respect to machine IDs, why not have our cake and eat it too?
> 
> (NOTE: This proposal assumes that the boot code has already
>        determined whether ATAGs or a DT has been passed to
>        the kernel, and that ATAG and DT machine IDs are in
>        the same namespace)
> 
> 1) We already have machine names in the mach-types file, and we
> can propose that those are used as the top-level 'compatible'
> tags for the DTs.
> 
> ...
>    compatible = "openrd\000kirkwood\000armv6\000arm"
> ...

That sounds like a good idea.  Except that you should probably prefix
the ARM machine name with something (e.g. "linux,arm-machine-XXXX"),
both to meet the normal OF "vendor,type" convention for compatible
values, and to make sure to avoid any conflicts wth things of other
architectures.

Oh, also, dtc supports nicer syntax for NULL separated stringlists
like that, you can go:
	compatible = "openrd", "kirkwood", "armv6", "arm";

> 2) We can trivially generate a name-to-machine ID hash table from
> the mach-types file (CRC32 of the name, or some other hash)

gperf...

The rest I'm not so sure about, I don't know arch/arm well enough.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  reply	other threads:[~2010-05-19  0:21 UTC|newest]

Thread overview: 80+ 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  2:54 ` Jeremy Kerr
2010-05-18  4:34 ` Nicolas Pitre
2010-05-18  4:34   ` Nicolas Pitre
2010-05-18  5:24   ` Jeremy Kerr
2010-05-18  5:24     ` Jeremy Kerr
2010-05-18  8:49     ` David Gibson
2010-05-18  8:49       ` David Gibson
2010-05-18 12:24       ` Nicolas Pitre
2010-05-18 12:24         ` Nicolas Pitre
2010-05-18 14:06         ` Jason McMullan
2010-05-18 14:06           ` Jason McMullan
2010-05-19  0:21           ` David Gibson [this message]
2010-05-19  0:21             ` David Gibson
2010-05-19  0:28         ` David Gibson
2010-05-19  0:28           ` David Gibson
2010-05-19  1:28           ` Nicolas Pitre
2010-05-19  1:28             ` Nicolas Pitre
2010-05-19  6:50             ` David Gibson
2010-05-19  6:50               ` David Gibson
2010-05-19 14:45               ` Grant Likely
2010-05-19 14:45                 ` Grant Likely
2010-05-19  1:41           ` Jamie Lokier
2010-05-19  1:41             ` Jamie Lokier
2010-05-19  7:12             ` David Gibson
2010-05-19  7:12               ` David Gibson
2010-05-19 14:21             ` Grant Likely
2010-05-19 14:21               ` Grant Likely
2010-05-19  7:25         ` Mitch Bradley
2010-05-19  7:25           ` Mitch Bradley
2010-05-19  8:50         ` Jeremy Kerr
2010-05-19  8:50           ` Jeremy Kerr
2010-05-18 11:57     ` Nicolas Pitre
2010-05-18 11:57       ` Nicolas Pitre
2010-05-19 12:13       ` Grant Likely
2010-05-19 12:13         ` Grant Likely
2010-05-19 16:45         ` Jamie Lokier
2010-05-19 16:45           ` Jamie Lokier
2010-05-19 17:10           ` Grant Likely
2010-05-19 17:10             ` Grant Likely
2010-05-19 17:32             ` M. Warner Losh
2010-05-19 17:32               ` M. Warner Losh
2010-05-19 11:57   ` Grant Likely
2010-05-19 11:57     ` Grant Likely
2010-05-19 12:08     ` Russell King - ARM Linux
2010-05-19 12:08       ` Russell King - ARM Linux
2010-05-19 17:52     ` Nicolas Pitre
2010-05-19 17:52       ` Nicolas Pitre
2010-05-19 20:08       ` Jamie Lokier
2010-05-19 20:08         ` Jamie Lokier
2010-05-19 20:22         ` Nicolas Pitre
2010-05-19 20:22           ` Nicolas Pitre
2010-05-21 16:24           ` John Rigby
2010-05-21 16:24             ` John Rigby
2010-05-21 16:27             ` Jamie Bennett
2010-05-21 16:27               ` Jamie Bennett
2010-05-21 19:59             ` Russell King - ARM Linux
2010-05-21 19:59               ` Russell King - ARM Linux
2010-06-03 21:12             ` Grant Likely
2010-06-03 21:12               ` Grant Likely
2010-06-04 20:01       ` Grant Likely
2010-06-04 20:01         ` Grant Likely
2010-06-04 20:33         ` John Rigby
2010-06-04 20:33           ` John Rigby
2010-06-04 20:37           ` Jon Loeliger
2010-06-04 20:37             ` Jon Loeliger
2010-06-04 21:07             ` Grant Likely
2010-06-04 21:07               ` Grant Likely
2010-06-05  1:33         ` Jeremy Kerr
2010-06-05  1:33           ` Jeremy Kerr
2010-06-05  2:29           ` Nicolas Pitre
2010-06-05  2:29             ` Nicolas Pitre
2010-06-05  5:59             ` Grant Likely
2010-06-05  5:59               ` Grant Likely
2010-06-09  4:26             ` Jeremy Kerr
2010-06-09  4:26               ` Jeremy Kerr
2010-06-09 13:09               ` Nicolas Pitre
2010-06-09 13:09                 ` Nicolas Pitre
2010-05-19 11:45 ` Grant Likely
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=20100519002141.GF25892@yookeroo \
    --to=david@gibson.dropbear.id.au \
    --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.