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
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
<[email protected]> 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 [email protected]
> 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
On Tue, Sep 10, 2013 at 11:40 AM, Tim Bird <[email protected]> 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
On Tue, Sep 10, 2013 at 1:50 PM, Linus Torvalds
<[email protected]> wrote:
> On Tue, Sep 10, 2013 at 11:40 AM, Tim Bird <[email protected]> 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
On Tue, Sep 10, 2013 at 2:39 PM, Tim Bird <[email protected]> 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
On 09/10/2013 04:44 PM, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 2:39 PM, Tim Bird <[email protected]> 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
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
On Tue, Sep 10, 2013 at 1:50 PM, Linus Torvalds
<[email protected]> 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 <[email protected]>
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
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 <[email protected]> wrote:
> On Tue, Sep 10, 2013 at 1:50 PM, Linus Torvalds
> <[email protected]> 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 <[email protected]>
> 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
On Wed, Sep 11, 2013 at 1:21 PM, Tim Bird <[email protected]> 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
On Tue, Sep 10, 2013 at 11:19 PM, Theodore Ts'o <[email protected]> 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.
On Wed, Sep 11, 2013 at 9:52 PM, Olof Johansson <[email protected]> wrote:
> On Wed, Sep 11, 2013 at 1:21 PM, Tim Bird <[email protected]> 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.