We intend to include these in the OpenPAPR :-P
Heh have fun.
start-info is going away, which means we'll need to add more
to replace it... something like this:
name = "xen";
version = "Xen-3.0-unstable";
Call this property "xen-version" instead?
Isn't that redundant?
Just a bit.
Should we have a "compatible" that domain can compare against?
Yes, but you also should have a "device_type".
The is not a device node, I'd rather not add that here, but console
should have one, see below.
"device_type" identifies the (OF) programming interface of any
node, not just device nodes. I.e., WHat properties are there
and what do they mean, plus methods if you have them.
If you only ever have one "xen" node, you don't need the "reg".
I have no idea what these last three props describe; please
explain? (And perhaps make the names more specific).
They are domain flags, telling the it has priveldge to all of the
machine (trusted), and that it is dom0, respectively.
So, any ideas for better names?
All virtual irqs will have the same sense/value, so you can do
without that second cell in the interrupt specifiers completely.
These may be the only 2 that ever see a device trww since
everything else is "hot plugged" using Xen hcalls.
We are not sure if the we'll be dyamically adding hotplug virtual
devices to the devtree at runtime, we just ain't there yet. It
think I'd like to keep the encoding, just in case.
Fine with me -- you'll have to define the encoding of the sense flag
this could be a "reg"/"unit address" as well.
You need #address-cells and #size-cells in the parent node for
Do we need them? don't they get "ancestored in"? if not then yes
we should add them.
No way. These sizes should ***not*** be inherited. Instead, if the
are absent, there's default values (2 and 1 resp.) Linux does it
accident or maybe some broken devtrees require it, dunno.
Xen-ppc-devel mailing list