On Mon, Jun 16, 2014 at 3:43 PM, Stephen Warren wrote:
> On 06/16/2014 07:30 AM, Rob Herring wrote:
>> On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner wrote:
> ...
>>> Rob Herring wrote:
Don't you need need to keep the kernel from allocating this memory by
using one of the reserved
On Mon, Jun 16, 2014 at 3:43 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 06/16/2014 07:30 AM, Rob Herring wrote:
On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner jwer...@chromium.org wrote:
...
Rob Herring wrote:
Don't you need need to keep the kernel from allocating this memory by
On 06/16/2014 07:30 AM, Rob Herring wrote:
> On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner 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
On Mon, Jun 16, 2014 at 6:30 AM, Rob Herring wrote:
> On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner wrote:
>>> 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.
>>
2014-06-13 14:58 GMT-07:00 Julius Werner :
>> 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
>
On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner wrote:
>> 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
On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner jwer...@chromium.org wrote:
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
2014-06-13 14:58 GMT-07:00 Julius Werner jwer...@chromium.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
On Mon, Jun 16, 2014 at 6:30 AM, Rob Herring robherri...@gmail.com wrote:
On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner jwer...@chromium.org wrote:
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
On 06/16/2014 07:30 AM, Rob Herring wrote:
On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner jwer...@chromium.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
> 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
On Fri, Jun 13, 2014 at 3:06 PM, Julius Werner wrote:
> This patch adds documentation describing a device tree binding for the
> coreboot firmware project (www.coreboot.org). It is meant to be
> dynamically added during boot and contains address definitions for the
> coreboot table (a list of
This patch adds documentation describing a device tree binding for the
coreboot firmware project (www.coreboot.org). It is meant to be
dynamically added during boot and contains address definitions for the
coreboot table (a list of variable-sized descriptors providing
information about various
This patch adds documentation describing a device tree binding for the
coreboot firmware project (www.coreboot.org). It is meant to be
dynamically added during boot and contains address definitions for the
coreboot table (a list of variable-sized descriptors providing
information about various
On Fri, Jun 13, 2014 at 3:06 PM, Julius Werner jwer...@chromium.org wrote:
This patch adds documentation describing a device tree binding for the
coreboot firmware project (www.coreboot.org). It is meant to be
dynamically added during boot and contains address definitions for the
coreboot
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
16 matches
Mail list logo