+Greg H
On Tue, Jan 5, 2016 at 7:06 PM, Kees Cook wrote:
> [fixing devicetree mailing list]
>
> On Tue, Jan 5, 2016 at 5:04 PM, Kees Cook wrote:
>> [thread necromancy, if you don't have the thread locally, it's here:
>> https://patchwork.kernel.org/patch/1426261/]
>>
>> We still need to solve
[fixing devicetree mailing list]
On Tue, Jan 5, 2016 at 5:04 PM, Kees Cook wrote:
> [thread necromancy, if you don't have the thread locally, it's here:
> https://patchwork.kernel.org/patch/1426261/]
>
> We still need to solve this, and John pinged me about it today. Where
> does this stand?
>
>
[thread necromancy, if you don't have the thread locally, it's here:
https://patchwork.kernel.org/patch/1426261/]
We still need to solve this, and John pinged me about it today. Where
does this stand?
-Kees
On Sun, Apr 14, 2013 at 7:24 AM, Anton Vorontsov wrote:
> On Mon, Apr 08, 2013 at
[fixing devicetree mailing list]
On Tue, Jan 5, 2016 at 5:04 PM, Kees Cook wrote:
> [thread necromancy, if you don't have the thread locally, it's here:
> https://patchwork.kernel.org/patch/1426261/]
>
> We still need to solve this, and John pinged me about it today. Where
[thread necromancy, if you don't have the thread locally, it's here:
https://patchwork.kernel.org/patch/1426261/]
We still need to solve this, and John pinged me about it today. Where
does this stand?
-Kees
On Sun, Apr 14, 2013 at 7:24 AM, Anton Vorontsov wrote:
> On Mon,
+Greg H
On Tue, Jan 5, 2016 at 7:06 PM, Kees Cook wrote:
> [fixing devicetree mailing list]
>
> On Tue, Jan 5, 2016 at 5:04 PM, Kees Cook wrote:
>> [thread necromancy, if you don't have the thread locally, it's here:
>>
On Mon, Apr 08, 2013 at 12:54:01PM -0700, Bryan Freed wrote:
[...]
> And as a more general question, why should we try not to put
> configuration in the device tree? It seems like a great (and
> portable) place to put this stuff.
> It certainly seems better to have it there than hardwired in the
On Mon, Apr 08, 2013 at 12:54:01PM -0700, Bryan Freed wrote:
[...]
And as a more general question, why should we try not to put
configuration in the device tree? It seems like a great (and
portable) place to put this stuff.
It certainly seems better to have it there than hardwired in the
On 04/08/2013 02:54 PM, Bryan Freed wrote:
> Sorry for dropping the ball on this one, Anton.
>
> Thank you for your feedback and modifications in the code.
> I gotta ask, however, why do you completely remove key ramoops fields
> like record_size and ftrace_size?
>
> From your 9/7/2012 comments
Sorry for dropping the ball on this one, Anton.
Thank you for your feedback and modifications in the code.
I gotta ask, however, why do you completely remove key ramoops fields
like record_size and ftrace_size?
>From your 9/7/2012 comments (again, sorry for the delay in getting back to
>you):
>
Sorry for dropping the ball on this one, Anton.
Thank you for your feedback and modifications in the code.
I gotta ask, however, why do you completely remove key ramoops fields
like record_size and ftrace_size?
From your 9/7/2012 comments (again, sorry for the delay in getting back to
you):
On 04/08/2013 02:54 PM, Bryan Freed wrote:
Sorry for dropping the ball on this one, Anton.
Thank you for your feedback and modifications in the code.
I gotta ask, however, why do you completely remove key ramoops fields
like record_size and ftrace_size?
From your 9/7/2012 comments (again,
On Thu, Apr 04, 2013 at 09:03:47PM -0500, Rob Herring wrote:
> On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov
> wrote:
> > On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote:
> >> On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
> >> > When called with a non-zero
On Thu, Apr 04, 2013 at 09:03:47PM -0500, Rob Herring wrote:
On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov cbouatmai...@gmail.com
wrote:
On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote:
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
When called with a
On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov wrote:
> On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote:
>> On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
>> > When called with a non-zero of_node, fill out a new ramoops_platform_data
>> > with data from the
On Mon, Sep 17, 2012 at 1:23 AM, Anton Vorontsov cbouatmai...@gmail.com wrote:
On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote:
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
When called with a non-zero of_node, fill out a new ramoops_platform_data
with data
On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote:
> On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
> > When called with a non-zero of_node, fill out a new ramoops_platform_data
> > with data from the specified Flattened Device Tree node.
> > Update ramoops
On Fri, Sep 07, 2012 at 10:29:10PM -0700, Anton Vorontsov wrote:
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
When called with a non-zero of_node, fill out a new ramoops_platform_data
with data from the specified Flattened Device Tree node.
Update ramoops documentation with
Il 08/09/2012 10:06, Anton Vorontsov ha scritto:
On Sat, Sep 08, 2012 at 09:23:40AM +0200, Marco Stornelli wrote: [...]
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (pdata == NULL)
I wonder why people prefer to not write !pdata, which is more natural
when reading the
On Sat, Sep 08, 2012 at 09:23:40AM +0200, Marco Stornelli wrote: [...]
> >>+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> >>+ if (pdata == NULL)
> >
> >I wonder why people prefer to not write !pdata, which is more natural
> >when reading the code.. :-)
>
> I think it's the same
Il 08/09/2012 07:29, Anton Vorontsov ha scritto:
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
When called with a non-zero of_node, fill out a new ramoops_platform_data
with data from the specified Flattened Device Tree node.
Update ramoops documentation with the new FDT
Il 08/09/2012 07:29, Anton Vorontsov ha scritto:
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
When called with a non-zero of_node, fill out a new ramoops_platform_data
with data from the specified Flattened Device Tree node.
Update ramoops documentation with the new FDT
On Sat, Sep 08, 2012 at 09:23:40AM +0200, Marco Stornelli wrote: [...]
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (pdata == NULL)
I wonder why people prefer to not write !pdata, which is more natural
when reading the code.. :-)
I think it's the same for sizeof, it's
Il 08/09/2012 10:06, Anton Vorontsov ha scritto:
On Sat, Sep 08, 2012 at 09:23:40AM +0200, Marco Stornelli wrote: [...]
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (pdata == NULL)
I wonder why people prefer to not write !pdata, which is more natural
when reading the
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
> When called with a non-zero of_node, fill out a new ramoops_platform_data
> with data from the specified Flattened Device Tree node.
> Update ramoops documentation with the new FDT interface.
> Update devicetree/binding documentation
When called with a non-zero of_node, fill out a new ramoops_platform_data
with data from the specified Flattened Device Tree node.
Update ramoops documentation with the new FDT interface.
Update devicetree/binding documentation with pstore/ramoops.txt.
---
I did not see any tree activity since I
When called with a non-zero of_node, fill out a new ramoops_platform_data
with data from the specified Flattened Device Tree node.
Update ramoops documentation with the new FDT interface.
Update devicetree/binding documentation with pstore/ramoops.txt.
---
I did not see any tree activity since I
On Fri, Sep 07, 2012 at 11:29:36AM -0700, Bryan Freed wrote:
When called with a non-zero of_node, fill out a new ramoops_platform_data
with data from the specified Flattened Device Tree node.
Update ramoops documentation with the new FDT interface.
Update devicetree/binding documentation with
28 matches
Mail list logo