Re: [Power.org:parch] devicetree: Musings on reserved regions

On Mon, Feb 7, 2011 at 2:53 PM, Yoder Stuart-B08248
[off-list ref] wrote:

quoted

-----Original Message-----
From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On Behalf Of Grant
Likely
Sent: Monday, February 07, 2011 3:45 PM
To: Benjamin Herrenschmidt
Cc: parch-QRwYI7m9GJLYtjvyW6yDsg@public.gmane.org; devicetree-discuss; David Gibson; Yoder Stuart-B08248;
McClintock Matthew-B29882; Wood Scott-B07421
Subject: Re: [Power.org:parch] devicetree: Musings on reserved regions

On Mon, Feb 7, 2011 at 2:39 PM, Benjamin Herrenschmidt
[off-list ref] wrote:

quoted

quoted

In addition to the reserved regions block in the header, define a set
of properties in the memory node that specify the reserved regions
with the name reflecting the usage.
For example:

      memory@0 {
              device_type = "memory";
              reg = <0 0x40000000>;
              reserved-ramdisk = <0xc00000 0x200000>; /* 2MB ramdisk
*/
              reserved-dtb = <0xbf0000 0x1000>; /* devicetree */
              reserved-fb0 = 0x1000000 0x400000>; /* framebuffer */
      };

Each reserved property would start with "reserved-" followed by a
name.  reserved-ramdisk and reserved-dtb would be reserved for
ramdisk and dtb images respectively.  Other names could also be
defined; for example, reserved-openfirmware.

I very much dislike the list of properties with magic names. I'd
rather have a pair of properties containing lists (reserved-names and
reserved-ranges).

Heh, I have very much the opposite opinion.  I'd rather have property names
that match the usage than have the names and values split into two
properties.  To me, keeping them together is more tasteful.  Queue the
debate...  :-)

Could we not do both? Use an enum to identify the region type:

   reserved = <0x1 0xc00000 0x200000>; /* 2MB ramdisk
   reserved = <0x2 0xbf0000 0x1000>; /* devicetree */
   reserved = <0x3 0x1000000 0x400000>; /* framebuffer */

I really dislike enums for this sort of thing.  I'd rather have a
string encoded somewhere, even if it is in a different property.

g.