linux-kernel - Re: [PATCH] firmware: Add device tree binding for coreboot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Jun 2014 14:43:56 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Rob Herring <robherring2@...il.com>,
	Julius Werner <jwerner@...omium.org>
CC:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Stephen Warren <stephen.r.warren@...il.com>,
	Doug Anderson <dianders@...omium.org>,
	Olof Johansson <olofj@...omium.org>,
	Stefan Reinauer <stefan.reinauer@...eboot.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH] firmware: Add device tree binding for coreboot

On 06/16/2014 07:30 AM, Rob Herring wrote:
> On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner <jwerner@...omium.org> wrote:
...
>> Rob Herring wrote:
>>> 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).
> 
> Understand there are 3 different memory reservation bindings. The
> original "/memreserve/" method is indeed limited. What I think you
> should use is the binding documented in
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
> So you could do something like this:
> 
>         reserved-memory {
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 ranges;
> 
>                 /* global autoconfigured region for contiguous allocations */
>                 linux,cma {
>                         compatible = "shared-dma-pool";
>                         reusable;
>                         size = <0x4000000>;
>                         alignment = <0x2000>;
>                         linux,cma-default;
>                 };
> 
>                 coreboot_reserved: coreboot@...ea000 {
>                       compatible = "coreboot";
>                       reg = <0xfdfea000 0x264>,
>                           <0xfdfea000 0x16000>;
>                 };
> 

I thought that the /reserved-memory node was more so that the
(preferred?) location of firmware images or data buffers used by HW
accelerators could be communicated to the kernel. This feels like pure data.

The coreboot binding seems to be more about defining an interface to a
particular firmware (this feels like semantics), which as a side-effect
needs to communicate the location of certain data.

If /reserved-memory is used to communicate the address of the memory
regions, I think we still need a /firmware/coreboot node to indicate the
semantics of the reserved memory region, and point at the phandle of the
region. As such, it seems simpler just to put the addresses in the
coreboot node's reg property. The only exception I see to that argument
is if putting the region in /reserved-memory automatically carves that
region out of the memory the kernel will allocate from. That would
simplify the bootloader, since it wouldn't have to fiddle with the
/memory node and do the carveout itself.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/