* [GIT PULL] Device tree updates for v3.12
@ 2013-09-10 18:00 Grant Likely
2013-09-10 18:40 ` Tim Bird
0 siblings, 1 reply; 12+ messages in thread
From: Grant Likely @ 2013-09-10 18:00 UTC (permalink / raw)
To: Linus Torvalds, Rob Herring, Linux Kernel Mailing List,
devicetree@vger.kernel.org
Hi Linus,
Pretty minor stuff here. Please pull.
g.
The following changes since commit d8dfad3876e4386666b759da3c833d62fb8b2267:
Linux 3.11-rc7 (2013-08-25 17:43:22 -0700)
are available in the git repository at:
git://git.secretlab.ca/git/linux tags/devicetree-for-linus
for you to fetch changes up to 2bc552df76d83cf1455ac8cf4c87615bfd15df74:
of/platform: add error reporting to of_amba_device_create()
(2013-09-09 17:04:52 +0100)
----------------------------------------------------------------
Device tree core updates for v3.12
Generally minor changes. A bunch of bug fixes, particularly for
initialization and some refactoring. Most notable change if feeding the
entire flattened tree into the random pool at boot. May not be
significant, but shouldn't hurt either.
----------------------------------------------------------------
Alexander Shiyan (1):
dt: Typo fix
Anton Blanchard (1):
of: Feed entire flattened device tree into the random pool
Bartlomiej Zolnierkiewicz (1):
of/platform: add error reporting to of_amba_device_create()
Geert Uytterhoeven (1):
of: Make of_get_phy_mode() return int i.s.o. const int
Grant Likely (5):
Merge tag 'v3.11-rc7' into devicetree/next
of: consolidate definition of early_init_dt_alloc_memory_arch()
of: Fix missing memory initialization on FDT unflattening
of/fdt: Remove duplicate memory clearing on FDT unflattening
of/fdt: Clean up casting in unflattening path
Laxman Dewangan (1):
include: dt-binding: input: create a DT header defining key codes.
Mark Brown (1):
of/platform: Staticize of_platform_device_create_pdata()
Santosh Shilimkar (1):
of: Specify initrd location using 64-bit
Sebastian Andrzej Siewior (1):
OF: make of_property_for_each_{u32|string}() use parameters if
OF is not enabled
Stephen Warren (5):
of: move documentation of of_parse_phandle_with_args
of: move of_parse_phandle()
of: introduce of_parse_phandle_with_fixed_args
of: call __of_parse_phandle_with_args from of_parse_phandle
gpio: implement gpio-ranges binding document fix
Yijing Wang (1):
irq/of: Fix comment typo for irq_of_parse_and_map
.../devicetree/bindings/net/can/sja1000.txt | 2 +-
arch/arc/kernel/devtree.c | 6 -
arch/arc/mm/init.c | 5 +-
arch/arm/mm/init.c | 2 +-
arch/arm64/kernel/setup.c | 5 -
arch/arm64/mm/init.c | 3 +-
arch/c6x/kernel/devicetree.c | 8 +-
arch/metag/mm/init.c | 5 +-
arch/microblaze/kernel/prom.c | 8 +-
arch/mips/kernel/prom.c | 3 +-
arch/openrisc/kernel/prom.c | 8 +-
arch/powerpc/kernel/prom.c | 8 +-
arch/x86/kernel/devicetree.c | 3 +-
arch/xtensa/kernel/setup.c | 3 +-
drivers/gpio/gpiolib-of.c | 4 +-
drivers/of/base.c | 200 +++++---
drivers/of/fdt.c | 98 ++--
drivers/of/irq.c | 2 +-
drivers/of/of_net.c | 2 +-
drivers/of/platform.c | 21 +-
include/dt-bindings/input/input.h | 525 +++++++++++++++++++++
include/linux/of.h | 49 +-
include/linux/of_fdt.h | 3 +-
include/linux/of_net.h | 4 +-
24 files changed, 787 insertions(+), 190 deletions(-)
create mode 100644 include/dt-bindings/input/input.h
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 18:00 [GIT PULL] Device tree updates for v3.12 Grant Likely
@ 2013-09-10 18:40 ` Tim Bird
2013-09-10 20:50 ` Linus Torvalds
0 siblings, 1 reply; 12+ messages in thread
From: Tim Bird @ 2013-09-10 18:40 UTC (permalink / raw)
To: Grant Likely
Cc: Linus Torvalds, Rob Herring, Linux Kernel Mailing List,
devicetree@vger.kernel.org
How much time does it add to boot to feed the device tree into the
random number pool.
Some of the device trees are expected to get pretty big. If it's over
a millisecond,
IMHO, it should be configurable (but this is not).
-- Tim
On Tue, Sep 10, 2013 at 11:00 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> Hi Linus,
>
> Pretty minor stuff here. Please pull.
>
> g.
>
> The following changes since commit d8dfad3876e4386666b759da3c833d62fb8b2267:
>
> Linux 3.11-rc7 (2013-08-25 17:43:22 -0700)
>
> are available in the git repository at:
>
> git://git.secretlab.ca/git/linux tags/devicetree-for-linus
>
> for you to fetch changes up to 2bc552df76d83cf1455ac8cf4c87615bfd15df74:
>
> of/platform: add error reporting to of_amba_device_create()
> (2013-09-09 17:04:52 +0100)
>
> ----------------------------------------------------------------
> Device tree core updates for v3.12
>
> Generally minor changes. A bunch of bug fixes, particularly for
> initialization and some refactoring. Most notable change if feeding the
> entire flattened tree into the random pool at boot. May not be
> significant, but shouldn't hurt either.
>
> ----------------------------------------------------------------
> Alexander Shiyan (1):
> dt: Typo fix
>
> Anton Blanchard (1):
> of: Feed entire flattened device tree into the random pool
>
> Bartlomiej Zolnierkiewicz (1):
> of/platform: add error reporting to of_amba_device_create()
>
> Geert Uytterhoeven (1):
> of: Make of_get_phy_mode() return int i.s.o. const int
>
> Grant Likely (5):
> Merge tag 'v3.11-rc7' into devicetree/next
> of: consolidate definition of early_init_dt_alloc_memory_arch()
> of: Fix missing memory initialization on FDT unflattening
> of/fdt: Remove duplicate memory clearing on FDT unflattening
> of/fdt: Clean up casting in unflattening path
>
> Laxman Dewangan (1):
> include: dt-binding: input: create a DT header defining key codes.
>
> Mark Brown (1):
> of/platform: Staticize of_platform_device_create_pdata()
>
> Santosh Shilimkar (1):
> of: Specify initrd location using 64-bit
>
> Sebastian Andrzej Siewior (1):
> OF: make of_property_for_each_{u32|string}() use parameters if
> OF is not enabled
>
> Stephen Warren (5):
> of: move documentation of of_parse_phandle_with_args
> of: move of_parse_phandle()
> of: introduce of_parse_phandle_with_fixed_args
> of: call __of_parse_phandle_with_args from of_parse_phandle
> gpio: implement gpio-ranges binding document fix
>
> Yijing Wang (1):
> irq/of: Fix comment typo for irq_of_parse_and_map
>
> .../devicetree/bindings/net/can/sja1000.txt | 2 +-
> arch/arc/kernel/devtree.c | 6 -
> arch/arc/mm/init.c | 5 +-
> arch/arm/mm/init.c | 2 +-
> arch/arm64/kernel/setup.c | 5 -
> arch/arm64/mm/init.c | 3 +-
> arch/c6x/kernel/devicetree.c | 8 +-
> arch/metag/mm/init.c | 5 +-
> arch/microblaze/kernel/prom.c | 8 +-
> arch/mips/kernel/prom.c | 3 +-
> arch/openrisc/kernel/prom.c | 8 +-
> arch/powerpc/kernel/prom.c | 8 +-
> arch/x86/kernel/devicetree.c | 3 +-
> arch/xtensa/kernel/setup.c | 3 +-
> drivers/gpio/gpiolib-of.c | 4 +-
> drivers/of/base.c | 200 +++++---
> drivers/of/fdt.c | 98 ++--
> drivers/of/irq.c | 2 +-
> drivers/of/of_net.c | 2 +-
> drivers/of/platform.c | 21 +-
> include/dt-bindings/input/input.h | 525 +++++++++++++++++++++
> include/linux/of.h | 49 +-
> include/linux/of_fdt.h | 3 +-
> include/linux/of_net.h | 4 +-
> 24 files changed, 787 insertions(+), 190 deletions(-)
> create mode 100644 include/dt-bindings/input/input.h
> --
> 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/
--
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 18:40 ` Tim Bird
@ 2013-09-10 20:50 ` Linus Torvalds
2013-09-10 21:39 ` Tim Bird
2013-09-11 17:02 ` Tony Luck
0 siblings, 2 replies; 12+ messages in thread
From: Linus Torvalds @ 2013-09-10 20:50 UTC (permalink / raw)
To: Tim Bird
Cc: Grant Likely, Rob Herring, Linux Kernel Mailing List,
devicetree@vger.kernel.org
On Tue, Sep 10, 2013 at 11:40 AM, Tim Bird <tbird20d@gmail.com> wrote:
> How much time does it add to boot to feed the device tree into the
> random number pool.
>
> Some of the device trees are expected to get pretty big. If it's over
> a millisecond, IMHO, it should be configurable (but this is not).
It's detinitely not a very fast operation. "add_device_randomness()"
does four full "mix_pool_bytes()" operations, and those each iterate
over the input set one byte at a time.
It was kind of designed for things like mixing in ethernet MAC
addresses etc, so at the time that was written, the thinking was that
it would be just a few bytes, maybe tens of bytes.
I don't know how big flattened device trees can be, but I guess we're
talking a couple of kB?
So it might even be a better idea to feed the device tree to a hashing
function (eg SHA1 or even just MD5), and then just mix in the hash. At
least most block hash functions do things a word at a time. It does
*not* need to be cryptographically secure, so MD5 would be plenty good
enough - the only point of the hash would be to give a meaningful
number of result bits from the source array.
Of course, maybe even the stupid add_device_randomness() is fast
enough. I just wanted to point out that it definitely isn't some
optimized thing.
Linus
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 20:50 ` Linus Torvalds
@ 2013-09-10 21:39 ` Tim Bird
2013-09-10 21:44 ` Linus Torvalds
2013-09-11 17:02 ` Tony Luck
1 sibling, 1 reply; 12+ messages in thread
From: Tim Bird @ 2013-09-10 21:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Grant Likely, Rob Herring, Linux Kernel Mailing List,
devicetree@vger.kernel.org, anton
On Tue, Sep 10, 2013 at 1:50 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Sep 10, 2013 at 11:40 AM, Tim Bird <tbird20d@gmail.com> wrote:
>> How much time does it add to boot to feed the device tree into the
>> random number pool.
>>
>> Some of the device trees are expected to get pretty big. If it's over
>> a millisecond, IMHO, it should be configurable (but this is not).
>
> It's detinitely not a very fast operation.
...
> So it might even be a better idea to feed the device tree to a hashing
> function (eg SHA1 or even just MD5), and then just mix in the hash. At
> least most block hash functions do things a word at a time. It does
> *not* need to be cryptographically secure, so MD5 would be plenty good
> enough - the only point of the hash would be to give a meaningful
> number of result bits from the source array.
Well, I'm not sure how many bits of randomness this will add anyway.
The way we're using device tree, we get the same values every boot, on
all instances of the same phone model. So this seems of little value.
Anton,
Are there presumably some random fields in device tree? Is this being used
to pass randomness from the bootloader? Or are you trying to mix in some
"randomness" about the hardware configuration? I'm trying to understand the
rationale for this.
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 21:39 ` Tim Bird
@ 2013-09-10 21:44 ` Linus Torvalds
2013-09-10 22:06 ` Rob Herring
0 siblings, 1 reply; 12+ messages in thread
From: Linus Torvalds @ 2013-09-10 21:44 UTC (permalink / raw)
To: Tim Bird
Cc: Grant Likely, Rob Herring, Linux Kernel Mailing List,
devicetree@vger.kernel.org, Anton Blanchard
On Tue, Sep 10, 2013 at 2:39 PM, Tim Bird <tbird20d@gmail.com> wrote:
>
> Well, I'm not sure how many bits of randomness this will add anyway.
> The way we're using device tree, we get the same values every boot, on
> all instances of the same phone model. So this seems of little value.
If I recall correctly, somebody said that things like ethernet MAC
addresses etc sometimes come from DT. Is my memory going, or is that
true but very rare?
Linus
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 21:44 ` Linus Torvalds
@ 2013-09-10 22:06 ` Rob Herring
2013-09-10 22:19 ` Theodore Ts'o
0 siblings, 1 reply; 12+ messages in thread
From: Rob Herring @ 2013-09-10 22:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tim Bird, Grant Likely, Linux Kernel Mailing List,
devicetree@vger.kernel.org, Anton Blanchard
On 09/10/2013 04:44 PM, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 2:39 PM, Tim Bird <tbird20d@gmail.com> wrote:
>>
>> Well, I'm not sure how many bits of randomness this will add anyway.
>> The way we're using device tree, we get the same values every boot, on
>> all instances of the same phone model. So this seems of little value.
>
> If I recall correctly, somebody said that things like ethernet MAC
> addresses etc sometimes come from DT. Is my memory going, or is that
> true but very rare?
It is true and fairly common. You can also have serial numbers in the
DT, but that is more rare. The bootloader will also add the kernel
command line, initrd start and end addresses.
Rob
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 22:06 ` Rob Herring
@ 2013-09-10 22:19 ` Theodore Ts'o
2013-09-11 21:49 ` Grant Likely
0 siblings, 1 reply; 12+ messages in thread
From: Theodore Ts'o @ 2013-09-10 22:19 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Torvalds, Tim Bird, Grant Likely, Linux Kernel Mailing List,
devicetree@vger.kernel.org, Anton Blanchard
On Tue, Sep 10, 2013 at 05:06:39PM -0500, Rob Herring wrote:
> > If I recall correctly, somebody said that things like ethernet MAC
> > addresses etc sometimes come from DT. Is my memory going, or is that
> > true but very rare?
>
> It is true and fairly common. You can also have serial numbers in the
> DT, but that is more rare. The bootloader will also add the kernel
> command line, initrd start and end addresses.
Stuff which is common across a large number of devices is rather less
useful to merge in. Is there some fixed way that things like serial
numbers and MAC addresses are tagged as such in the device tree?
Those are really the interesting bits to pass to
add_device_randomness(). What we want is stuff which is unique to the
device --- SP 800-90 (the NIST SPEC on Secure Random Number
Generators) refers to this as "personalization strings".
- Ted
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 22:19 ` Theodore Ts'o
@ 2013-09-11 21:49 ` Grant Likely
0 siblings, 0 replies; 12+ messages in thread
From: Grant Likely @ 2013-09-11 21:49 UTC (permalink / raw)
To: Theodore Ts'o, Rob Herring, Linus Torvalds, Tim Bird,
Grant Likely, Linux Kernel Mailing List,
devicetree@vger.kernel.org, Anton Blanchard
On Tue, Sep 10, 2013 at 11:19 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Sep 10, 2013 at 05:06:39PM -0500, Rob Herring wrote:
>> > If I recall correctly, somebody said that things like ethernet MAC
>> > addresses etc sometimes come from DT. Is my memory going, or is that
>> > true but very rare?
>>
>> It is true and fairly common. You can also have serial numbers in the
>> DT, but that is more rare. The bootloader will also add the kernel
>> command line, initrd start and end addresses.
>
> Stuff which is common across a large number of devices is rather less
> useful to merge in. Is there some fixed way that things like serial
> numbers and MAC addresses are tagged as such in the device tree?
Unfortunately not. There is no indication about which are the dynamic
properties.
g.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [GIT PULL] Device tree updates for v3.12
2013-09-10 20:50 ` Linus Torvalds
2013-09-10 21:39 ` Tim Bird
@ 2013-09-11 17:02 ` Tony Luck
2013-09-11 20:21 ` Tim Bird
1 sibling, 1 reply; 12+ messages in thread
From: Tony Luck @ 2013-09-11 17:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tim Bird, Grant Likely, Rob Herring, Linux Kernel Mailing List,
devicetree@vger.kernel.org
On Tue, Sep 10, 2013 at 1:50 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> Of course, maybe even the stupid add_device_randomness() is fast
> enough. I just wanted to point out that it definitely isn't some
> optimized thing.
When I posted the patch that mixes in the whole SMBIOS table:
commit d114a33387472555188f142ed8e98acdb8181c6d
Author: Tony Luck <tony.luck@intel.com>
Date: Fri Jul 20 13:15:20 2012 -0700
dmi: Feed DMI table to /dev/random driver
I asked whether there was any size issue - as it tends to be a few
kilobytes on laptops and desktops, and tens of kilobytes on servers.
The answer I got back then was not to worry - digesting a few kilobytes
wouldn't be a problem. I just threw in a debug message to check and saw:
dmi_walk_early: added 10342 bytes in 339968 cycles
So a couple of hundred microseconds for me.
There are plenty of machine specific values buried in there (e.g. serial
numbers for all the DIMMs) ... so this looks like a good use of this
much boot time.
-Tony
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [GIT PULL] Device tree updates for v3.12
2013-09-11 17:02 ` Tony Luck
@ 2013-09-11 20:21 ` Tim Bird
2013-09-11 20:52 ` Olof Johansson
0 siblings, 1 reply; 12+ messages in thread
From: Tim Bird @ 2013-09-11 20:21 UTC (permalink / raw)
To: Tony Luck
Cc: Linus Torvalds, Grant Likely, Rob Herring,
Linux Kernel Mailing List, devicetree@vger.kernel.org
Thanks. This gives me an order-of-magnitude measurement for this sort of thing.
I'll measure it directly myself on our hardware as soon as I can.
I've heard an ugly rumor that the device tree from our silicon vendor
may grow to be
as big as 130K in the near future. I'm still following up to see if
there's any truth
to this (so don't quote me on it), but if it does get that big it
might be an issue. As
stated previously, the vast majority of our device tree files consists
of values that
are not device-specific.
I'll keep an eye on it and propose something if it turns out to be a real issue.
On Wed, Sep 11, 2013 at 10:02 AM, Tony Luck <tony.luck@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 1:50 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> Of course, maybe even the stupid add_device_randomness() is fast
>> enough. I just wanted to point out that it definitely isn't some
>> optimized thing.
>
> When I posted the patch that mixes in the whole SMBIOS table:
>
> commit d114a33387472555188f142ed8e98acdb8181c6d
> Author: Tony Luck <tony.luck@intel.com>
> Date: Fri Jul 20 13:15:20 2012 -0700
>
> dmi: Feed DMI table to /dev/random driver
>
> I asked whether there was any size issue - as it tends to be a few
> kilobytes on laptops and desktops, and tens of kilobytes on servers.
> The answer I got back then was not to worry - digesting a few kilobytes
> wouldn't be a problem. I just threw in a debug message to check and saw:
>
> dmi_walk_early: added 10342 bytes in 339968 cycles
>
> So a couple of hundred microseconds for me.
>
> There are plenty of machine specific values buried in there (e.g. serial
> numbers for all the DIMMs) ... so this looks like a good use of this
> much boot time.
>
> -Tony
--
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [GIT PULL] Device tree updates for v3.12
2013-09-11 20:21 ` Tim Bird
@ 2013-09-11 20:52 ` Olof Johansson
2013-09-11 21:49 ` Grant Likely
0 siblings, 1 reply; 12+ messages in thread
From: Olof Johansson @ 2013-09-11 20:52 UTC (permalink / raw)
To: Tim Bird
Cc: Tony Luck, Linus Torvalds, Grant Likely, Rob Herring,
Linux Kernel Mailing List, devicetree@vger.kernel.org
On Wed, Sep 11, 2013 at 1:21 PM, Tim Bird <tbird20d@gmail.com> wrote:
> Thanks. This gives me an order-of-magnitude measurement for this sort of thing.
> I'll measure it directly myself on our hardware as soon as I can.
>
> I've heard an ugly rumor that the device tree from our silicon vendor
> may grow to be
> as big as 130K in the near future. I'm still following up to see if
> there's any truth
> to this (so don't quote me on it), but if it does get that big it
> might be an issue. As
> stated previously, the vast majority of our device tree files consists
> of values that
> are not device-specific.
The biggest ones in mainline today compile to a ~30K binary. Not sure
a vendor expects to add in there to gain another 100KB.
-Olof
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [GIT PULL] Device tree updates for v3.12
2013-09-11 20:52 ` Olof Johansson
@ 2013-09-11 21:49 ` Grant Likely
0 siblings, 0 replies; 12+ messages in thread
From: Grant Likely @ 2013-09-11 21:49 UTC (permalink / raw)
To: Olof Johansson
Cc: Tim Bird, Tony Luck, Linus Torvalds, Rob Herring,
Linux Kernel Mailing List, devicetree@vger.kernel.org,
Theodore Tso
On Wed, Sep 11, 2013 at 9:52 PM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Sep 11, 2013 at 1:21 PM, Tim Bird <tbird20d@gmail.com> wrote:
>> Thanks. This gives me an order-of-magnitude measurement for this sort of thing.
>> I'll measure it directly myself on our hardware as soon as I can.
>>
>> I've heard an ugly rumor that the device tree from our silicon vendor
>> may grow to be
>> as big as 130K in the near future. I'm still following up to see if
>> there's any truth
>> to this (so don't quote me on it), but if it does get that big it
>> might be an issue. As
>> stated previously, the vast majority of our device tree files consists
>> of values that
>> are not device-specific.
>
> The biggest ones in mainline today compile to a ~30K binary. Not sure
> a vendor expects to add in there to gain another 100KB.
I'll keep an eye on it too. If anyone reports a problem then I'll
revert the patch.
g.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-09-11 21:49 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-10 18:00 [GIT PULL] Device tree updates for v3.12 Grant Likely
2013-09-10 18:40 ` Tim Bird
2013-09-10 20:50 ` Linus Torvalds
2013-09-10 21:39 ` Tim Bird
2013-09-10 21:44 ` Linus Torvalds
2013-09-10 22:06 ` Rob Herring
2013-09-10 22:19 ` Theodore Ts'o
2013-09-11 21:49 ` Grant Likely
2013-09-11 17:02 ` Tony Luck
2013-09-11 20:21 ` Tim Bird
2013-09-11 20:52 ` Olof Johansson
2013-09-11 21:49 ` Grant Likely
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).