From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: Device tree bindings for linux ramoops use Date: Fri, 6 Jan 2012 15:30:45 -0700 Message-ID: References: <20120106220908.GJ7457@ponder.secretlab.ca> <4F07749B.6070703@firmworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4F07749B.6070703-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Mitch Bradley Cc: Marco Stornelli , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Rob Herring List-Id: devicetree@vger.kernel.org On Fri, Jan 6, 2012 at 3:24 PM, Mitch Bradley 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 =3D "linux,ramoops" >>> linux,ramoops-start =3D >>> linux,ramoops-size =3D ... >> >> >> I'm not a fan of using separate start& =A0size properties. =A0I'd rather >> >> see a 'reg' type property like "linux,ramoops-mem =3D;", >> but doing it in separate properties does may early boot code easier to >> write. =A0I 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. =A0I prefer atomicity. =A0It'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.