[PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
David Gibson
david at gibson.dropbear.id.au
Fri Jun 12 09:29:02 EST 2009
On Thu, Jun 11, 2009 at 11:04:59AM -0500, Nate Case wrote:
> Hi David,
>
> Thanks for the comments.
>
> On Thu, 2009-06-11 at 11:32 +1000, David Gibson wrote:
> > These last two aren't standard properties, so should probably be
> > "xes,form-factor" and "xes,boot-bank".
>
> I'll just delete them for now since they're not critical.
>
> > > + pmcslots {
> >
> > What does this structure model? Without any reg properties it's kind
> > of hard to see what you could do with it.
>
> This would be a bit more obvious to those familiar with CompactPCI and
> PMC modules. It aims to describe how many PMC slots are in the system,
> and gives information on whether or not a module is installed and if
> it's monarch of the bus or not. So it's really just a description of
> the hardware. The properties themselves are useful because you may have
> to read from GPIO lines to get this information (which may be accessible
> only via I2C, which can't be done too early in the kernel). A reg
> property could be used just for indexing the slots, but there are no
> real memory-mapped resources involved for the slot itself (that
> information would go in the PCI nodes).
Ok. I guess it would be a bit more normal to associate this sort of
passive information more closely with the bus information it relates
to. But I don't know whether that makes sense in this particular
instance.
> It'd be nice if we could get a device tree standard for this type of
> information in the future, but for now I can just delete it since we
> don't yet rely on it in the kernel.
Ok, that's probably reasonable for now. I think it would be wise to
write up a draft binding for it.
> > > +
> > > + tbi2: tbi-phy at 11 {
> > > + reg = <0x11>;
> > > + device_type = "tbi-phy";
> >
> > And this one, too. Although this node should probably have a
> > compatible property instead.
>
> I don't think I can drop that device_type yet. All the other device
> trees for Freescale boards use it, and the Freescale MDIO driver appears
> to rely on it. A future patch I suppose?
Ick, ok. Fair enough.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
More information about the Linuxppc-dev
mailing list