From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967406AbdCXTef (ORCPT ); Fri, 24 Mar 2017 15:34:35 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:35858 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967314AbdCXTdr (ORCPT ); Fri, 24 Mar 2017 15:33:47 -0400 MIME-Version: 1.0 In-Reply-To: References: <1490303069-13230-1-git-send-email-thierry.escande@collabora.com> <1490303069-13230-5-git-send-email-thierry.escande@collabora.com> <20170324122146.GE22771@leverpostej> <20170324175727.GB119093@google.com> From: Julius Werner Date: Fri, 24 Mar 2017 12:33:34 -0700 X-Google-Sender-Auth: Le-rQVy4pN1qzioJuNLNi9CtZyo Message-ID: Subject: Re: [PATCH 4/5] firmware: Add coreboot device tree binding documentation To: Julius Werner Cc: Brian Norris , Mark Rutland , Thierry Escande , Rob Herring , Greg Kroah-Hartman , Olof Johansson , Stephen Warren , LKML , "devicetree@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ...and again in plaintext, sorry about that. On Fri, Mar 24, 2017 at 12:32 PM, Julius Werner wrote: >> > Devicetree bindings should be in vendor,prefix format. This doesn't >> > represent every aspect of coreboot, so it needs a more descriptive >> > string. >> >> Any particular suggestion? I suppose this is Google's interpretation of >> coreboot tables, so "google,coreboot"? > > > No. This binding is for the coreboot project in general and has nothing to > do with Google. coreboot is both the vendor and the product, so I think > "coreboot" would look better than "coreboot,coreboot". And yes, it is > supposed to represent every aspect of coreboot (right now the "coreboot > tables" are already sort of a catch-all data structure used by coreboot to > pass on any sort of info it wants later stages to know... and if we ever > have any additional things we'd like to pass on, we'd probably want to add > them to this binding as well). > >> >> > > + - reg: Address and length of the following two memory regions, in >> > > order: >> > > + 1.) The coreboot table. This is a list of variable-sized >> > > descriptors >> > > + that contain various compile- and run-time generated firmware >> > > + parameters. It is identified by the magic string "LBIO" in its >> > > first >> > > + four bytes. >> > > + See coreboot's src/commonlib/include/commonlib/coreboot_tables.h >> > > for >> > > + details. >> > >> > Given this is a memory region, it should be described under the >> > reserved-memory node. >> >> We've painted this bikeshed before. I guess the result was either to use >> /reserved-memory or /memreserve/. I believe we've been using >> /memreserve/. I suppose we could document a method to use either, but >> the main "agreement" was to use the /firmware/coreboot path instead of >> /reserved-memory/coreboot. > > > See the old thread Brian linked for some arguments for and against this. I > think particularly because we want this node to represent every aspect of > coreboot (which I think makes more sense than spreading stuff all over the > place), treating it as reserved memory would not work well if we might later > add other fields. > > Also, since we didn't get any more responses the last time we tried to > upstream this and had schedules to keep, we had to go ahead with what we > had. So right now there are already millions of devices shipped with this > binding in firmware, and the only question we still have left to decide is > whether Linux wants to support them upstream or not. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julius Werner Subject: Re: [PATCH 4/5] firmware: Add coreboot device tree binding documentation Date: Fri, 24 Mar 2017 12:33:34 -0700 Message-ID: References: <1490303069-13230-1-git-send-email-thierry.escande@collabora.com> <1490303069-13230-5-git-send-email-thierry.escande@collabora.com> <20170324122146.GE22771@leverpostej> <20170324175727.GB119093@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Julius Werner Cc: Brian Norris , Mark Rutland , Thierry Escande , Rob Herring , Greg Kroah-Hartman , Olof Johansson , Stephen Warren , LKML , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org ...and again in plaintext, sorry about that. On Fri, Mar 24, 2017 at 12:32 PM, Julius Werner wrote: >> > Devicetree bindings should be in vendor,prefix format. This doesn't >> > represent every aspect of coreboot, so it needs a more descriptive >> > string. >> >> Any particular suggestion? I suppose this is Google's interpretation of >> coreboot tables, so "google,coreboot"? > > > No. This binding is for the coreboot project in general and has nothing to > do with Google. coreboot is both the vendor and the product, so I think > "coreboot" would look better than "coreboot,coreboot". And yes, it is > supposed to represent every aspect of coreboot (right now the "coreboot > tables" are already sort of a catch-all data structure used by coreboot to > pass on any sort of info it wants later stages to know... and if we ever > have any additional things we'd like to pass on, we'd probably want to add > them to this binding as well). > >> >> > > + - reg: Address and length of the following two memory regions, in >> > > order: >> > > + 1.) The coreboot table. This is a list of variable-sized >> > > descriptors >> > > + that contain various compile- and run-time generated firmware >> > > + parameters. It is identified by the magic string "LBIO" in its >> > > first >> > > + four bytes. >> > > + See coreboot's src/commonlib/include/commonlib/coreboot_tables.h >> > > for >> > > + details. >> > >> > Given this is a memory region, it should be described under the >> > reserved-memory node. >> >> We've painted this bikeshed before. I guess the result was either to use >> /reserved-memory or /memreserve/. I believe we've been using >> /memreserve/. I suppose we could document a method to use either, but >> the main "agreement" was to use the /firmware/coreboot path instead of >> /reserved-memory/coreboot. > > > See the old thread Brian linked for some arguments for and against this. I > think particularly because we want this node to represent every aspect of > coreboot (which I think makes more sense than spreading stuff all over the > place), treating it as reserved memory would not work well if we might later > add other fields. > > Also, since we didn't get any more responses the last time we tried to > upstream this and had schedules to keep, we had to go ahead with what we > had. So right now there are already millions of devices shipped with this > binding in firmware, and the only question we still have left to decide is > whether Linux wants to support them upstream or not. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html