get_pteptr prototype

David Gibson david at
Fri Jan 10 11:42:43 EST 2003

On Thu, Jan 09, 2003 at 09:55:40AM -0600, Hollis Blanchard wrote:
> On Wed, 2003-01-08 at 20:33, David Gibson wrote:
> >
> > Hmm... what's the reason that wakeup_info needs to be reserved in
> > head_4xx.S, rather than just being a normal variable in the data area
> > (which should be writable anyway)?  Its not obvious to me from the
> > patch.
> Sorry, I was hoping the Documentation file explained it well enough. On
> wake the firmware needs to transfer control back to Linux, so the
> firmware needs to know where to jump to. The only way I could think of
> communicating that information was with a fixed memory location known to
> both the firmware and to Linux. In future processors there will be a
> scratch register (whose contents are saved during sleep) to solve this
> problem.

Ah, ok - I only skimmed the patch I'm afraid, so I didn't notice that.

> > Actually, skimming through the patch I noticed a minor nit: you only
> > have one .long in head_4xx.S reserving space for the wakeup_info
> > struct which is 3 words long.  In practice the . = in the exception
> > handlers will give you plenty of space, but I think it would be good
> > form to explicitly reserve the right amount of space.
> It's just a (physical) pointer to the structure which is elsewhere in
> memory (actually on the stack).

Hmm... in that case, why does the pointer need to be updated at
runtime: could you just statically allocate the real structure (in the
data segment), and have the value at 0xc00000fc filled in constant at
link time.

David Gibson			| For every complex problem there is a
david at	| solution which is simple, neat and
				| wrong.

** Sent via the linuxppc-dev mail list. See

More information about the Linuxppc-dev mailing list