From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>, devicetree-discuss@ozlabs.org
Subject: Re: Board level compatibility matching
Date: Sat, 02 Aug 2008 08:48:23 +1000 [thread overview]
Message-ID: <1217630903.11188.537.camel@pasglop> (raw)
In-Reply-To: <20080801080632.35edcb04@zod.rchland.ibm.com>
> This is sort of the part that sucks. Look at 44x. There are 10
> board.c files there. There really only needs to be 3 or 4 (sam440ep,
> warp, virtex, and "generic") because the board files are identical in
> everything except name. By doing the library code approach, one still
> has to create a board.c file for a new board and plug in the library
> functions to ppc_md.
And ? How is that a big deal ? Real products (ie not eval boards, and
even those ...) will probably end up needing that due to subtle
differences anyway.
> Alternatively, you could do the:
>
> compatible = "specific-board", "similar-board"
>
> approach that has been done for e.g. Bamboo and Yosemite. Again, the
> issue is that is that OK? Is it OK for a board to claim compatibility
> with another board when it might not have all the devices of that
> board, or might have additional devices, etc. I was of the opinion
> it is, and the device tree handles this just fine, as does the platform
> code. But it can be confusing, hence the discussion here.
Well, as I said. If it stops being ok, just create your own board
and it will take over provided you put it before the other one in
the link order.
If we generalize that approach, we might want to change the board
probing code a bit to first do a full pass based on the first
entry in compatible, then another full pass based on the second, etc...
Ben.
next prev parent reply other threads:[~2008-08-01 22:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-31 20:19 Board level compatibility matching Grant Likely
2008-07-31 20:39 ` Chris Friesen
2008-07-31 20:49 ` Jon Smirl
2008-07-31 20:52 ` Grant Likely
2008-07-31 20:58 ` Jon Smirl
2008-08-01 2:47 ` David Gibson
2008-08-01 3:06 ` Jon Smirl
2008-08-01 3:30 ` David Gibson
2008-08-01 4:00 ` Jon Smirl
2008-08-01 4:25 ` David Gibson
2008-08-01 4:37 ` Jon Smirl
2008-08-01 6:22 ` David Gibson
2008-07-31 20:59 ` Scott Wood
2008-07-31 21:09 ` Grant Likely
2008-08-01 2:54 ` David Gibson
2008-08-01 3:25 ` Grant Likely
2008-08-01 3:38 ` David Gibson
2008-08-01 4:25 ` Benjamin Herrenschmidt
2008-08-01 12:06 ` Josh Boyer
2008-08-01 12:28 ` Josh Boyer
2008-08-01 14:30 ` Grant Likely
2008-08-01 22:48 ` Benjamin Herrenschmidt [this message]
2008-08-02 0:07 ` Josh Boyer
2008-08-01 14:27 ` Grant Likely
2008-08-01 15:11 ` Josh Boyer
2008-08-01 16:01 ` M. Warner Losh
2008-08-01 16:24 ` Grant Likely
2008-08-01 22:54 ` Benjamin Herrenschmidt
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=1217630903.11188.537.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=devicetree-discuss@ozlabs.org \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.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).