Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754108AbaFMV6x (ORCPT ); Fri, 13 Jun 2014 17:58:53 -0400 Received: from mail-oa0-f52.google.com ([209.85.219.52]:35900 "EHLO mail-oa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754078AbaFMV6w (ORCPT ); Fri, 13 Jun 2014 17:58:52 -0400 MIME-Version: 1.0 In-Reply-To: References: <1402689965-19397-1-git-send-email-jwerner@chromium.org> Date: Fri, 13 Jun 2014 14:58:51 -0700 X-Google-Sender-Auth: UzK63jjOyefdhrldQOC7XOsCT1A Message-ID: Subject: Re: [PATCH] firmware: Add device tree binding for coreboot From: Julius Werner To: Rob Herring Cc: Julius Werner , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Stephen Warren , Doug Anderson , Olof Johansson , Stefan Reinauer , "devicetree@vger.kernel.org" , "linux-kernel@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 > This is just to export a fixed log to userspace (like a DMI table) or > the kernel will actually use the data in some way? Based on the link, > it looks like the former to me. I could imagine both. The link is an in-kernel driver that exposes a log through a sysfs node (in a way that has already been established on x86 systems, which find the location through EBDA or ACPI entries instead). We are also using a user-space tool that reads the address from /proc/device-tree and accesses it through /dev/mem. The areas can contain many interesting entries (like the location of an early framebuffer set up by the firmware), so I could also imagine use cases where the kernel makes use of it directly. > Don't you need need to keep the kernel from allocating this memory by > using one of the reserved memory mechanisms? The recently added one > should be able to specific what the memory is reserved for IIRC. Our bootloader is carving the location out of the /memory node and adding it to the device tree reserve map. As far as I know, that only contains a list of raw start and size entries. At any rate, I think it's useful (and in line with other bindings) to add a more explicit node like this (if only to make it easier accessible through /proc/device-tree). > /firmware is already used IIRC. What if you have other firmware such > as Trustzone? I'm not quite sure how Trusted Foundations works and whether it would even make sense to use it in parallel to coreboot, but it seems to be using the /firmware/trusted-foundations subnode so that should be fine. "firmware" seems to be used by other firmware implementations (like "samsung,secure-firmware") which are similar in nature to and mutually exclusive with coreboot, so I thought the node makes sense. (The kernel should use the compatible string to find it anyway, so a future name clash would not be world-ending.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/