EMAC OF binding....
Segher Boessenkool
segher at kernel.crashing.org
Tue Jan 9 09:40:24 EST 2007
>>> For axon, thus, we have: "emac-axon","emac4"
>>
>> "ibm,emac-axon" etc. please.
>
> Why ?
To avoid name collisions.
> In the -content- of a compatible property ?
Yes.
> haven't seen that much before.
Didn't you read the OF spec? All examples are like that.
I know that in "real life" (and esp. in Apple OF) this
isn't often done, sure -- but is there any reason for you
*not* to do the proper thing?
>>> - local-mac-address : 6 bytes, MAC address
>>
>> Don't forget "mac-address", if the device is opened
>> in OF; and "max-frame-size" please.
>
> Yeah well, doesn't need to specify that, it's already specified :-) I'm
> talking about what the driver wants.
Oh okay, what the driver wants. Please don't forget that
nuance when putting this stuff into the binding doc -- it
doesn't belong there ;-)
>>> - cell-index : 1 cell, hardware index of the EMAC cell on a
>>> given ASIC (typically
>>> 0x00000000 and 0x00000001 for EMAC-0 and
>>> EMAC-1
>>> on each Axon chip)
>>
>> Can you find a better name? What is this used for, anyway?
>
> Propose one :-) There are various bits here or there where you have to
> know which EMAC in a chip you are talking about (clock control bits,
> that sort of thing).
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).
>>> - max-mtu : 1 cell, maximum MTU supported in bytes
>>
>> See "max-frame-size", MTU is on a higher level than device
>> level and as such shouldn't be here; the OF networking layer
>> can set something like this if it wants.
>
> Except that I don't want OF to set anything dynamically here. This is a
> way to prevent EMAC to do jumbo frames in fact.
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.
Segher
More information about the Linuxppc-dev
mailing list