Re: Device tree bindings for linux ramoops use

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Fri, Jan 6, 2012 at 3:24 PM, Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> wrote:
> On 1/6/2012 12:09 PM, Grant Likely wrote:
>>
>> On Thu, Jan 05, 2012 at 08:39:50PM -0800, Olof Johansson wrote:
>>>
>>> Hi,
>>>
>>> I'm considering how to best describe the data that ramoops needs in
>>> the device tree.
>>>
>>> The idea is really about describing a memory area that is (likely to
>>> be) nonvolatile across reboots. Said area is not to be included in the
>>> regular memory map of the system (i.e. not covered by /memory).
>>>
>>> I have a few options on where to do it. It's not really a hardware
>>> device per se, so it's a gray area for the device tree alltogether.
>>>
>>> How about something like?
>>>
>>> compatible = "linux,ramoops"
>>> linux,ramoops-start =<start address of preserved ram>
>>> linux,ramoops-size = ...
>>
>>
>> I'm not a fan of using separate start&  size properties.  I'd rather
>>
>> see a 'reg' type property like "linux,ramoops-mem =<start size>;",
>> but doing it in separate properties does may early boot code easier to
>> write.  I assume that is why the initrd start and size values are
>> passed separately.
>
>
> Separate properties admit the possibility of errors where one is present but
> not the other.  I prefer atomicity.  It's either there, with all the
> information, or it isn't.

.... I was /going/ to argue that having a single property requires
parsing #{address,size}-cells whereas passing separately does not...
but thinking about it more that isn't actually true (although the
cells size could be inferred when using separate properties).  So,
yes, I agree with Mitch.  A single property is better.

g.