[PATCH V4] powerpc/prom: Export device tree physical address via proc

Grant Likely grant.likely at secretlab.ca
Fri Jul 16 05:18:21 EST 2010

On Thu, Jul 15, 2010 at 12:58 PM, Matthew McClintock <msm at freescale.com> wrote:
> On Thu, 2010-07-15 at 12:37 -0600, Grant Likely wrote:
>> On Thu, Jul 15, 2010 at 12:03 PM, Matthew McClintock <msm at freescale.com> wrote:
>> > Yes. Where would we get a list of memreserve sections?
>> I would say the list of reserves that are not under the control of
>> Linux should be explicitly described in the device tree proper.  For
>> instance, if you have a region that firmware depends on, then have a
>> node for describing the firmware and a property stating the memory
>> regions that it depends on.  The memreserve regions can be generated
>> from that.
> Ok, so we could traverse the tree node-by-bode for a
> persistent-memreserve property and add them to the /memreserve/ list in
> the kexec user space tools?

I *think* that is okay, but I'd like to hear from Segher, Ben, Mitch,
David Gibson, and other device tree experts on whether or not that
exact property naming is a good one.

Write up a proposed binding (you can use devicetree.org).  Post it for
review (make sure you cc: both devicetree-discuss and linuxppc-dev, as
well as cc'ing the people listed above.)

>> > Should we export
>> > the reserve sections instead of the device tree location?
>> It shouldn't really be something that the kernel is explicitly
>> exporting because it is a characteristic of the board design.  It is
>> something that belongs in the tree-proper.  ie. when you extract the
>> tree you have data telling what the region is, and why it is reserved.
> Agreed.
>> > We just need a
>> > way to preserve what was there at boot to pass to the new kernel.
>> Yet there is no differentiation between the board-dictated memory
>> reserves and the things that U-Boot/Linux made an arbitrary decision
>> on.  The solution should focus not on "can I throw this one away?" but
>> rather "Is this one I should keep?"  :-)  A subtle difference, I know,
>> but it changes the way you approach the solution.
> Fair enough. I think the above solution will work nicely, and I can
> start implementing something if you agree - if I interpreted your idea
> correctly. Although it should not require any changes to the kernel
> proper.



More information about the Linuxppc-dev mailing list