[PATCH 1/4 v2] powerpc: document max-speed and interface-type properties
kim.phillips at freescale.com
Wed Apr 18 11:13:50 EST 2007
On Wed, 18 Apr 2007 01:18:24 +0200
Segher Boessenkool <segher at kernel.crashing.org> wrote:
> >> "compatible" means "what kind of device is this", for the
> >> purposes of a client program (i.e., Linux) matching a
> >> driver to it (i.e., it should say what kind of PHY it
> >> is, and phylib should use that info -- in most cases,
> >> it won't need more than the least specific entry in
> >> "compatible", i.e. "rgmii" or whatever.
> > sorry, I disagree; for me, a compatible entry in the PHY node would
> > look
> > something like "marvell"
> which would be completely wrong
that depends on what degree the manufacturer's PHYs are compatible.
> > or "m88e11x1".
> It should be something like "m88e11x1\0m88e1xxx\0rgmii" instead.
m88e11x1 implies rgmii, including all the other interfaces the PHY
supports (gmii, mii, tbi, etc.).
..but I'm not interested in specifying what interfaces the PHY supports.
> A "compatible" property can contain many values, ordered from
> most exact to least exact.
> > "rgmii" might indeed be
> > something that PHY supports, but it tells the driver nothing about how
> > to enable it (whereas "m88e11x1" would). The rgmii designation in
> > question in this thread is not a property of the PHY, but of the board.
> It certainly is a property of the PHY as well.
> >> So those UCCs should have a different "compatible" entry.
> >> It's not rocket science.
> > It's referring to the name of the driver,
> No, not at all. No device tree entry name/value has any
> direct correspondence with Linux device driver names
> (in principle; things can "accidentally" have the same
> name, of course).
well that may be the case here then.
> >> max-speed of connection = min(max-speed of enet, max-speed
> >> of PHY) -- and both of those are implied by their respective
> >> "compatible" properties.
> > Again, max-speed is exclusively for configuring the UCC itself,
> > regardless of the connection speed.
> If that is really true, and the value of that property
> has nothing to do with the MAC<->PHY data channel, it should
> have a different (not that generic) name.
can you elaborate on why, including an example of what you'd think would
be a better one?
More information about the Linuxppc-dev