All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Kerr <jeremy.kerr-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org>
Subject: Re: ARM machine specific DT probing
Date: Mon, 13 Sep 2010 13:30:02 +0800	[thread overview]
Message-ID: <1284355802.2877.56.camel@pororo> (raw)
In-Reply-To: <20100913022036.GD5505@yookeroo>

Hi David,

> Hrm.  The trouble with this idea is that it needs some measure of
> "specificness of match",

I was originally thinking an enum, something to indicate that the match
is for a machine or SoC or SoC-family, but that may not be flexible
enough.

Essentially, all we really need to indicate is that "this match is more
specific than that other match", which the match-table-ordering would
work fine for.

With the present infrastructure, we'd need to enforce this by
controlling the link order. However, I don't have any good ideas about
how we could do this neatly.

Maybe we could get make to work out the dependencies (this mdesc needs
to go before that one) for us :D

Cheers,


Jeremy

  reply	other threads:[~2010-09-13  5:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-08 19:43 ARM machine specific DT probing Nicolas Pitre
     [not found] ` <alpine.LFD.2.00.1009081523500.19366-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
2010-09-09  1:07   ` Jeremy Kerr
2010-09-13  2:20     ` David Gibson
2010-09-13  5:30       ` Jeremy Kerr [this message]
2010-09-13  6:03         ` David Gibson
2010-09-16 17:40           ` Grant Likely
     [not found]             ` <20100916174020.GA7550-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2010-09-16 22:56               ` Scott Wood
     [not found]                 ` <20100916175617.7e36ed0e-1MYqz8GpK7RekFaExTCHk1jVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-09-20  1:35                   ` David Gibson

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=1284355802.2877.56.camel@pororo \
    --to=jeremy.kerr-z7wlfzj8ewms+fvcfc7uqw@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=nico-vtqb6HGKxmzR7s880joybQ@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 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.