All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Mark A. Greer" <mgreer@mvista.com>
Cc: linuxppc-dev <Linuxppc-dev@ozlabs.org>,
	David Gibson <david@gibson.dropbear.id.au>,
	Dale Farnsworth <dfarnsworth@mvista.com>,
	Yoder Stuart-B08248 <stuart.yoder@freescale.com>
Subject: Re: [RFC 3/3] powerpc: Add DTS file for the Motorola PrPMC2800 platform
Date: Wed, 4 Apr 2007 13:28:08 +0200	[thread overview]
Message-ID: <2feac74905bf1d4fd11725f430cb4078@kernel.crashing.org> (raw)
In-Reply-To: <20070402182632.GI2132@mag.az.mvista.com>

>> Even then, you can just query the MMU structures to
>> find out the currently set up translations for that
>> physical address.  Way more robust.
>
> Yes, that is the most robust but its also more complicated.

Sure.  But if what you want to do is more complicated *anyway*
(e.g., doing a bunch of device initialisations/configurations),
misusing the quick evil hack that was meant to get debug output
out originally isn't really warranted.

>> The only valid reason to use "virtual-reg" is as a
>> hack to map some device to get some debug output out.
>
> Not true, its for more than just output.
> See my response to David's email.

I said only _valid_ reason.  I know you're using it for more
things, that's what I'm complaining about :-)

>> If for normal usage you can't be bothered to parse
>> the current translations, you probably shouldn't be
>> doing anything as "advanced" as device I/O either --
>> just boot the kernel and let it handle it ;-)
>
> Well, the overall idea is that we remove boot/init related code from 
> the
> kernel and leave it to the firmware or the bootwrapper (if the firmware
> doesn't provide the required functionality).

Some init belongs in the kernel, and some belongs in
the firmware; if the latter doesn't provide it, it's
a good idea to do it in the bootwrapper, yes.

> For example, the VPD code
> in .../boot/prpmc2800.c in my patches.

I cannot find those patches right now, but in general,
that kind of code belongs in the kernel (or in a run-time
firmware).

> Also, at one time there was code
> to get the MAC addr from i2c prom and stick it in the dt.  I can see
> that being fairly common for non-OF/uboot platforms.

That's useful, yes, if that I2C PROM sits somewhere away
from the enet itself (so its access cannot be put in the
driver for the enet itself).

>> That said, I sure hope the kernel isn't using this
>> property as well...
>
> It certainly shouldn't be.  Its a bootwrapper-only hack.

Good, that makes all this less severe :-)


Segher

  reply	other threads:[~2007-04-04 11:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-28  1:19 [RFC 0/3] powerpc: Add Motorola PrPMC2800 platform support Mark A. Greer
2007-03-28  1:20 ` [RFC 1/3] powerpc: Add bootwrapper support for Motorola PrPMC2800 platform Mark A. Greer
2007-03-28  1:21 ` [RFC 2/3] powerpc: Add arch/powerpc support for the " Mark A. Greer
2007-03-28  1:22 ` [RFC 3/3] powerpc: Add DTS file " Mark A. Greer
2007-03-28 16:43   ` Yoder Stuart-B08248
2007-03-28 18:11     ` Josh Boyer
2007-03-28 19:49       ` [RFC 3/3] powerpc: Add DTS file for the Motorola PrPMC2800platform Yoder Stuart-B08248
2007-03-29  0:35     ` [RFC 3/3] powerpc: Add DTS file for the Motorola PrPMC2800 platform David Gibson
2007-03-29  0:48       ` Segher Boessenkool
2007-03-29  1:56         ` David Gibson
2007-03-29 22:21         ` Dale Farnsworth
2007-04-02 18:26         ` Mark A. Greer
2007-04-04 11:28           ` Segher Boessenkool [this message]
2007-04-04 16:27             ` Mark A. Greer
2007-04-04 17:44               ` Segher Boessenkool
2007-04-02 18:15       ` Mark A. Greer
2007-04-03  0:55         ` David Gibson
2007-04-03 18:50           ` Mark A. Greer
2007-04-04 11:18         ` Segher Boessenkool
2007-04-04 16:29           ` Mark A. Greer
2007-04-04 17:51             ` Yoder Stuart-B08248
2007-04-05 17:48               ` Segher Boessenkool
2007-03-29 22:18     ` Dale Farnsworth
2007-04-02 18:06     ` Mark A. Greer

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=2feac74905bf1d4fd11725f430cb4078@kernel.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=Linuxppc-dev@ozlabs.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=dfarnsworth@mvista.com \
    --cc=mgreer@mvista.com \
    --cc=stuart.yoder@freescale.com \
    /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.