* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
[not found] ` <20131011131138.3bc5b2acf60df3a5d79d0d24@linux-foundation.org>
@ 2013-10-18 16:57 ` Kevin Hilman
2013-10-18 17:04 ` Kevin Hilman
2013-10-18 17:06 ` Joe Perches
0 siblings, 2 replies; 10+ messages in thread
From: Kevin Hilman @ 2013-10-18 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 11, 2013 at 1:11 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 08 Oct 2013 22:32:27 -0700 Joe Perches <joe@perches.com> wrote:
>
>> Currently, devm_ managed memory only supports kzalloc.
>>
>> Convert the devm_kzalloc implementation to devm_kmalloc
>> and remove the complete memset to 0 but still set the
>> initial struct devres header and whatever padding before
>> data to 0.
>>
>> Add the other normal alloc variants as static inlines with
>> __GFP_ZERO added to the gfp flag where appropriate:
>>
>> devm_kzalloc
>> devm_kcalloc
>> devm_kmalloc_array
>>
>> Add gfp.h to device.h for the newly added static inlines.
>>
>> ...
>>
>> --- a/drivers/base/devres.c
>> +++ b/drivers/base/devres.c
>> @@ -91,7 +91,8 @@ static __always_inline struct devres * alloc_dr(dr_release_t release,
>> if (unlikely(!dr))
>> return NULL;
>>
>> - memset(dr, 0, tot_size);
>> + memset(dr, 0, offsetof(struct devres, data));
>
> Well, this does make some assumptions about devres layout. It would
> have been cleaner to do
>
> memset(&dr.node, 0, sizeof(dr.node));
>
> but whatever.
>
> I made some changelog changes.
>
> I agree that including devm_kmalloc_array() might be going a bit far
> (it's the lack of devm_kmalloc which matters most). But
> devm_kmalloc_array() is inlined and is hence basically cost-free until
> someone actually uses it.
A handful of boot panics on ARM platforms were bisected to point at
the version of this commit that's in linux-next (commit
64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
makes things happy again.
Upon further digging, it seems that users of devres_alloc() are
relying on the previous behavior of having the memory zero'd which is
no longer the case after $SUBJECT patch. The change below on top of
-next makes these ARM boards happy again.
Kevin
[1]
>From 16489e16c8efdda791e96bd591e455e7c7739f98 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()
commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated
memory. However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO
which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong
assumptions
about memory being zero'd upon allocation.
To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
drivers/base/devres.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..e3fe8be 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
size, gfp_t gfp)
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
return dr->data;
--
1.8.3
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-18 16:57 ` [RFC PATCH] device: Add kernel standard devm_k.alloc functions Kevin Hilman
@ 2013-10-18 17:04 ` Kevin Hilman
2013-10-18 22:57 ` Greg KH
2013-10-18 17:06 ` Joe Perches
1 sibling, 1 reply; 10+ messages in thread
From: Kevin Hilman @ 2013-10-18 17:04 UTC (permalink / raw)
To: linux-arm-kernel
> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> makes things happy again.
>
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch. The change below on top of
> -next makes these ARM boards happy again.
Oops, it should've fixed __devres_alloc() also. Updated patch below.
Kevin
>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()
commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated
memory. However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO
which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong
assumptions
about memory being zero'd upon allocation.
To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
drivers/base/devres.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t
size, gfp_t gfp,
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
set_node_dbginfo(&dr->node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
size, gfp_t gfp)
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
return dr->data;
--
1.8.3
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-18 16:57 ` [RFC PATCH] device: Add kernel standard devm_k.alloc functions Kevin Hilman
2013-10-18 17:04 ` Kevin Hilman
@ 2013-10-18 17:06 ` Joe Perches
2013-10-18 17:11 ` Kevin Hilman
1 sibling, 1 reply; 10+ messages in thread
From: Joe Perches @ 2013-10-18 17:06 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
[]
> A handful of boot panics on ARM platforms were bisected to point at
> the version of this commit that's in linux-next (commit
> 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> makes things happy again.
>
> Upon further digging, it seems that users of devres_alloc() are
> relying on the previous behavior of having the memory zero'd which is
> no longer the case after $SUBJECT patch. The change below on top of
> -next makes these ARM boards happy again.
[]
> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
> the default behavior of alloc_dr() to no longer zero the allocated
> memory. However,
> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
> which leaves
> any users of devres_alloc() or __devres_alloc() with potentially wrong
> assumptions
> about memory being zero'd upon allocation.
>
> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
> behavior of zero'ing memory upon allocation.
[]
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
[]
> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
> size, gfp_t gfp)
> {
> struct devres *dr;
>
> - dr = alloc_dr(release, size, gfp);
> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
> if (unlikely(!dr))
> return NULL;
> return dr->data;
Wouldn't the __devres_alloc need that too?
#ifdef CONFIG_DEBUG_DEVRES
void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
const char *name)
{
struct devres *dr;
dr = alloc_dr(release, size, gfp);
if (unlikely(!dr))
return NULL;
set_node_dbginfo(&dr->node, name, size);
return dr->data;
}
EXPORT_SYMBOL_GPL(__devres_alloc);
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-18 17:06 ` Joe Perches
@ 2013-10-18 17:11 ` Kevin Hilman
0 siblings, 0 replies; 10+ messages in thread
From: Kevin Hilman @ 2013-10-18 17:11 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 18, 2013 at 10:06 AM, Joe Perches <joe@perches.com> wrote:
> On Fri, 2013-10-18 at 09:57 -0700, Kevin Hilman wrote:
> []
>> A handful of boot panics on ARM platforms were bisected to point at
>> the version of this commit that's in linux-next (commit
>> 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
>> makes things happy again.
>>
>> Upon further digging, it seems that users of devres_alloc() are
>> relying on the previous behavior of having the memory zero'd which is
>> no longer the case after $SUBJECT patch. The change below on top of
>> -next makes these ARM boards happy again.
> []
>> commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
>> the default behavior of alloc_dr() to no longer zero the allocated
>> memory. However,
>> only the devm.k.alloc() function were modified to pass in __GFP_ZERO
>> which leaves
>> any users of devres_alloc() or __devres_alloc() with potentially wrong
>> assumptions
>> about memory being zero'd upon allocation.
>>
>> To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
>> behavior of zero'ing memory upon allocation.
> []
>> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> []
>> @@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t
>> size, gfp_t gfp)
>> {
>> struct devres *dr;
>>
>> - dr = alloc_dr(release, size, gfp);
>> + dr = alloc_dr(release, size, gfp | __GFP_ZERO);
>> if (unlikely(!dr))
>> return NULL;
>> return dr->data;
>
> Wouldn't the __devres_alloc need that too?
Yeah, I had mentioned __devres_alloc() in the changelog, but missed
it in the actual patch. :(
Anyways, I had quickly sent an updated patch, but our mails must've
crossed paths.
Kevin
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-18 17:04 ` Kevin Hilman
@ 2013-10-18 22:57 ` Greg KH
2013-10-19 5:52 ` Kevin Hilman
0 siblings, 1 reply; 10+ messages in thread
From: Greg KH @ 2013-10-18 22:57 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> > A handful of boot panics on ARM platforms were bisected to point at
> > the version of this commit that's in linux-next (commit
> > 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> > makes things happy again.
> >
> > Upon further digging, it seems that users of devres_alloc() are
> > relying on the previous behavior of having the memory zero'd which is
> > no longer the case after $SUBJECT patch. The change below on top of
> > -next makes these ARM boards happy again.
>
> Oops, it should've fixed __devres_alloc() also. Updated patch below.
Can you send this in a format that I can apply it in? It was whitespace
damaged.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-18 22:57 ` Greg KH
@ 2013-10-19 5:52 ` Kevin Hilman
2013-10-20 2:57 ` Greg KH
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Hilman @ 2013-10-19 5:52 UTC (permalink / raw)
To: linux-arm-kernel
Greg KH <gregkh@linuxfoundation.org> writes:
> On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
>> > A handful of boot panics on ARM platforms were bisected to point at
>> > the version of this commit that's in linux-next (commit
>> > 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
>> > makes things happy again.
>> >
>> > Upon further digging, it seems that users of devres_alloc() are
>> > relying on the previous behavior of having the memory zero'd which is
>> > no longer the case after $SUBJECT patch. The change below on top of
>> > -next makes these ARM boards happy again.
>>
>> Oops, it should've fixed __devres_alloc() also. Updated patch below.
>
> Can you send this in a format that I can apply it in? It was whitespace
> damaged.
hmm, sorry about that. This one should work, though I wonder if Andrew
should pick this up since I think the patch that causes the breakage
came through his tree.
Kevin
---------------8<----------------------------------------------------
>From a1962ed4a999fb630a48f75a5ecaf84401d5dbfc Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@linaro.org>
Date: Fri, 18 Oct 2013 09:41:39 -0700
Subject: [PATCH] devres: restore zeroing behavior of devres_alloc()
commit 64c862a8 (devres: add kernel standard devm_k.alloc functions) changed
the default behavior of alloc_dr() to no longer zero the allocated memory. However,
only the devm.k.alloc() function were modified to pass in __GFP_ZERO which leaves
any users of devres_alloc() or __devres_alloc() with potentially wrong assumptions
about memory being zero'd upon allocation.
To fix, add __GFP_ZERO to devres_alloc() calls to preserve previous
behavior of zero'ing memory upon allocation.
Signed-off-by: Kevin Hilman <khilman@linaro.org>
---
drivers/base/devres.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index 37e67a2..545c4de 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -111,7 +111,7 @@ void * __devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
set_node_dbginfo(&dr->node, name, size);
@@ -136,7 +136,7 @@ void * devres_alloc(dr_release_t release, size_t size, gfp_t gfp)
{
struct devres *dr;
- dr = alloc_dr(release, size, gfp);
+ dr = alloc_dr(release, size, gfp | __GFP_ZERO);
if (unlikely(!dr))
return NULL;
return dr->data;
--
1.8.3
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-19 5:52 ` Kevin Hilman
@ 2013-10-20 2:57 ` Greg KH
2013-10-20 15:22 ` Joe Perches
0 siblings, 1 reply; 10+ messages in thread
From: Greg KH @ 2013-10-20 2:57 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
>
> > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> >> > A handful of boot panics on ARM platforms were bisected to point at
> >> > the version of this commit that's in linux-next (commit
> >> > 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> >> > makes things happy again.
> >> >
> >> > Upon further digging, it seems that users of devres_alloc() are
> >> > relying on the previous behavior of having the memory zero'd which is
> >> > no longer the case after $SUBJECT patch. The change below on top of
> >> > -next makes these ARM boards happy again.
> >>
> >> Oops, it should've fixed __devres_alloc() also. Updated patch below.
> >
> > Can you send this in a format that I can apply it in? It was whitespace
> > damaged.
>
> hmm, sorry about that. This one should work, though I wonder if Andrew
> should pick this up since I think the patch that causes the breakage
> came through his tree.
No, the patch is in my tree, not Andrew's.
Joe, can I get a signed-off-by for this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-20 2:57 ` Greg KH
@ 2013-10-20 15:22 ` Joe Perches
2013-10-25 12:59 ` Olof Johansson
0 siblings, 1 reply; 10+ messages in thread
From: Joe Perches @ 2013-10-20 15:22 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> > Greg KH <gregkh@linuxfoundation.org> writes:
> >
> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> > >> > A handful of boot panics on ARM platforms were bisected to point at
> > >> > the version of this commit that's in linux-next (commit
> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> > >> > makes things happy again.
> > >> >
> > >> > Upon further digging, it seems that users of devres_alloc() are
> > >> > relying on the previous behavior of having the memory zero'd which is
> > >> > no longer the case after $SUBJECT patch. The change below on top of
> > >> > -next makes these ARM boards happy again.
> > >>
> > >> Oops, it should've fixed __devres_alloc() also. Updated patch below.
> > >
> > > Can you send this in a format that I can apply it in? It was whitespace
> > > damaged.
> >
> > hmm, sorry about that. This one should work, though I wonder if Andrew
> > should pick this up since I think the patch that causes the breakage
> > came through his tree.
>
> No, the patch is in my tree, not Andrew's.
>
> Joe, can I get a signed-off-by for this?
If you want.
Signed-off-by: Joe Perches <joe@perches.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-20 15:22 ` Joe Perches
@ 2013-10-25 12:59 ` Olof Johansson
2013-10-25 15:23 ` Greg KH
0 siblings, 1 reply; 10+ messages in thread
From: Olof Johansson @ 2013-10-25 12:59 UTC (permalink / raw)
To: linux-arm-kernel
On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <joe@perches.com> wrote:
> On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
>> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
>> > Greg KH <gregkh@linuxfoundation.org> writes:
>> >
>> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
>> > >> > A handful of boot panics on ARM platforms were bisected to point at
>> > >> > the version of this commit that's in linux-next (commit
>> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
>> > >> > makes things happy again.
>> > >> >
>> > >> > Upon further digging, it seems that users of devres_alloc() are
>> > >> > relying on the previous behavior of having the memory zero'd which is
>> > >> > no longer the case after $SUBJECT patch. The change below on top of
>> > >> > -next makes these ARM boards happy again.
>> > >>
>> > >> Oops, it should've fixed __devres_alloc() also. Updated patch below.
>> > >
>> > > Can you send this in a format that I can apply it in? It was whitespace
>> > > damaged.
>> >
>> > hmm, sorry about that. This one should work, though I wonder if Andrew
>> > should pick this up since I think the patch that causes the breakage
>> > came through his tree.
>>
>> No, the patch is in my tree, not Andrew's.
>>
>> Joe, can I get a signed-off-by for this?
>
> If you want.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Olof Johansson <olof@lixom.net>
Greg, would you mind picking this up? It's still broken in -next and I
don't want it to mask other issues that might be introduced.
-Olof
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC PATCH] device: Add kernel standard devm_k.alloc functions
2013-10-25 12:59 ` Olof Johansson
@ 2013-10-25 15:23 ` Greg KH
0 siblings, 0 replies; 10+ messages in thread
From: Greg KH @ 2013-10-25 15:23 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 25, 2013 at 05:59:56AM -0700, Olof Johansson wrote:
> On Sun, Oct 20, 2013 at 8:22 AM, Joe Perches <joe@perches.com> wrote:
> > On Sat, 2013-10-19 at 19:57 -0700, Greg KH wrote:
> >> On Fri, Oct 18, 2013 at 10:52:46PM -0700, Kevin Hilman wrote:
> >> > Greg KH <gregkh@linuxfoundation.org> writes:
> >> >
> >> > > On Fri, Oct 18, 2013 at 10:04:11AM -0700, Kevin Hilman wrote:
> >> > >> > A handful of boot panics on ARM platforms were bisected to point at
> >> > >> > the version of this commit that's in linux-next (commit
> >> > >> > 64c862a839a8db2c02bbaa88b923d13e1208919d). Reverting this commit
> >> > >> > makes things happy again.
> >> > >> >
> >> > >> > Upon further digging, it seems that users of devres_alloc() are
> >> > >> > relying on the previous behavior of having the memory zero'd which is
> >> > >> > no longer the case after $SUBJECT patch. The change below on top of
> >> > >> > -next makes these ARM boards happy again.
> >> > >>
> >> > >> Oops, it should've fixed __devres_alloc() also. Updated patch below.
> >> > >
> >> > > Can you send this in a format that I can apply it in? It was whitespace
> >> > > damaged.
> >> >
> >> > hmm, sorry about that. This one should work, though I wonder if Andrew
> >> > should pick this up since I think the patch that causes the breakage
> >> > came through his tree.
> >>
> >> No, the patch is in my tree, not Andrew's.
> >>
> >> Joe, can I get a signed-off-by for this?
> >
> > If you want.
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
>
> Acked-by: Olof Johansson <olof@lixom.net>
>
>
> Greg, would you mind picking this up? It's still broken in -next and I
> don't want it to mask other issues that might be introduced.
I picked it up early this morning already, so it will be in the next
-next whenever it gets created...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-10-25 15:23 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1381296747.2040.17.camel@joe-AO722>
[not found] ` <20131011131138.3bc5b2acf60df3a5d79d0d24@linux-foundation.org>
2013-10-18 16:57 ` [RFC PATCH] device: Add kernel standard devm_k.alloc functions Kevin Hilman
2013-10-18 17:04 ` Kevin Hilman
2013-10-18 22:57 ` Greg KH
2013-10-19 5:52 ` Kevin Hilman
2013-10-20 2:57 ` Greg KH
2013-10-20 15:22 ` Joe Perches
2013-10-25 12:59 ` Olof Johansson
2013-10-25 15:23 ` Greg KH
2013-10-18 17:06 ` Joe Perches
2013-10-18 17:11 ` Kevin Hilman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox