Re: EMAC OF binding....

[Segher Boessenkool <segher@kernel.crashing.org>]

>> So this is for accessing some shared SoC registers?  The emac
>> node has no business with that, you should have a separate
>> node for that (and you probably do already, you can use the
>> parent bus node in most such cases).
>
> If I needed a separate node for every shared SoC bit, I would have a
>> 2MB device-tree :-)
>
> There are just a few places where I need to call some platform code and
> tell it what EMAC in the chip it is so it can go tweak the right magic
> bits, best is a property for that.

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.

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


Segher