From: Sascha Hauer <s.hauer@pengutronix.de>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev Development <linuxppc-dev@ozlabs.org>,
Sylvain Munaut <tnt@246tNt.com>
Subject: Re: [PATCH] add restart function for mpc52xx
Date: Fri, 12 Jan 2007 09:46:12 +0100 [thread overview]
Message-ID: <20070112084612.GJ11226@localhost.localdomain> (raw)
In-Reply-To: <17831.627.162751.166002@cargo.ozlabs.ibm.com>
On Fri, Jan 12, 2007 at 02:37:23PM +1100, Paul Mackerras wrote:
> Sascha Hauer writes:
>
> > > This suffers from the same bug mpc83xx_restart has. We can NOT do an
> > > ioremap inside the restart function. We may get called from
> > > interrupt context on a panic and will not be able to do the ioremap
> > > (). The simplest thing is to do the mapping earlier in an init call
> > > and save the pointer, its not perfect, but better.
> > >
> >
> > I'm beginning to hate this whole pseudo OF thing for embedded systems.
>
> Not being able to ioremap at interrupt time has absolutely _nothing_
> to do with the device tree.
No, not directly..
>
> > All we need to know is that we have a mpc52xx processor.
>
> ... until we get a system with a mpc52xx and some extra stuff. Then
> you say "OK, we just need a boardinfo_t" and then we get 57 different
> variants of boardinfo_t and then we're back in the mess that arch/ppc
> got into.
OK, nobody wants that. I can only compare to arm where we have one
single number per board (not per SoC, I misrepresented that). This
number is perfectly enough to know what SoC we are on (to map the
register space and select timing/irq code and the like). The rest of a
particular board is described in one single board file.
On system with real open firmware it's surely the way to go to use it,
but on systems without OF it's just painful. Not being able to implement
a restart function without changing the device tree shows that.
Sascha
--
Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
next prev parent reply other threads:[~2007-01-12 8:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-11 12:28 [PATCH] add restart function for mpc52xx Sascha Hauer
2007-01-11 13:15 ` Sylvain Munaut
2007-01-11 13:59 ` Kumar Gala
2007-01-11 15:21 ` Sascha Hauer
2007-01-11 15:50 ` Grant Likely
2007-01-11 16:20 ` Grant Likely
2007-01-11 16:57 ` Segher Boessenkool
2007-01-12 3:37 ` Paul Mackerras
2007-01-12 8:46 ` Sascha Hauer [this message]
2007-01-12 9:00 ` Sylvain Munaut
2007-01-12 10:42 ` Sascha Hauer
2007-01-12 10:43 ` Sylvain Munaut
2007-01-12 16:05 ` Kumar Gala
2007-01-12 12:27 ` Segher Boessenkool
2007-01-28 18:09 ` Robert Schwebel
2007-01-28 21:48 ` Benjamin Herrenschmidt
2007-01-28 23:56 ` David Gibson
2007-01-12 12:23 ` Segher Boessenkool
2007-01-12 12:39 ` Sylvain Munaut
2007-01-12 12:19 ` Segher Boessenkool
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=20070112084612.GJ11226@localhost.localdomain \
--to=s.hauer@pengutronix.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=tnt@246tNt.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 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).