Re: EMAC OF binding....

[Benjamin Herrenschmidt <benh@au1.ibm.com>]

> Oh you misunderstand what I mean.  I'm just saying the
> registers that are shared are in some other node (having
> the same regs in two nodes can't happen).
> 
> Let's hope the hardware is sane enough that you can
> describe it in a sane way.
> 
> You would probably end up with properties in the SoC
> node like "emac-#0" containing the phandle of the first
> emac, or something like that -- the number of the emac
> on the SoC is not a property of the emac, but of the SoC
> itself.
> 
> I don't know the exact programming interface so I'm not
> completely sure of course, but please consider.

I'm not sure I follow you... for example, I may have some clock contro
register somewhere with one bit enabling EMAC 0 clock and one bit
enabling EMAC 1 clock...

Easier to call some platform clock management giving my device-node as
an argument and have that code extract the EMAC "index" from the DT from
my node.

> >> MTU is dynamic, max-frame-size isn't.  max-frame-size is just
> >> the maximum packet size you can tell the network controller to
> >> put on the wire, not counting protocol overhead etc.
> >
> > Ah ok.
> 
> It sounds like max-frame-size is exactly what you wanted
> this new max-mtu property for, right?  [Oh and btw, max-mtu
> is a really bad name -- "max-max-tu" heh].

Hehe, yes ok, I'll have a look at the spec to be sure.

Ben.