This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [XenPPC] XenPPC IEEE1275 binding?

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 properties
to replace it... something like this:
        xen {
                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".
reg, begone!



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 then.

this could be a "reg"/"unit address" as well.

You need #address-cells and #size-cells in the parent node for
that, btw.

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 properties are absent, there's default values (2 and 1 resp.) Linux does it wrong, historical
accident or maybe some broken devtrees require it, dunno.


Xen-ppc-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>