So, you may hate me for this, but another thought occurred to me:

	Really, really, really, these things _do_ need to have types.

	As far as I'm concerned, the largest reason to try to go with
	properties is so that 'random things' can get at them and meaningfully
	use them, e.g. sysctl an extension of kernfs.

	Unless you know what the actual types of the values are, though,
	that's impossible.


	In particular, i'm thinking of at minimum:

	* 32-bit (or wider, but only guaranteed to be 32-bit) integer (unsigned?)
	? 64-bit (or wider, but only guaranteed to be 64-bit) integer (unsigned?)
	* string
	* paddr_t
	? vaddr_t
	* bus_addr_t
	* bus_size_t
	* bus_space_tag_t
	* bus_space_handle_t
	* bus_dma_tag_t
	? ofw node (or something like that)
	* 'unknown'

	things with ? next to them are for things that i don't know are
	needed, yet.  8-)

I don't think that this buys you much.  Most of the time the 
name of the property will imply its type.   The width of the types
is recorded in the property and can be queried 
(dev_getprop(dev, "name", NULL, 0 /*len*/, 0) will return it.
Typing properties is only useful when they are not single integral
values of variable width, but aggregates of multiple values.
Specifying that sort of thing results in having to marshall and
unmarshall properties.  I think that sort of thing really is too
much kernel growth.

The only distinction I see as useful would be to differentiate
string properties from binary ones, so you could print out
a device tree and know that the property "powered-up" was "yes"
rather than 0x79657300.

And if you really want to provide some readable way to describe
and aggregate type, you could always provide a string property
"foo-type" which describes the individual fields in property "foo".

Eduardo