Re: [XenPPC] XenPPC IEEE1275 binding?

[Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>]

> 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!
Great.

> > > >                 privileged;
> > > >                 init-domain;
> > 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.


Segher


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel