EMAC OF binding....

EMAC OF binding....

[Benjamin Herrenschmidt]

Ok, so now that I have a new EMAC driver that seems to work reasonably
well on Axon using OF devices, I can give you guys a proper list of the
properties it expects in the device-tree to be discussed here. We need
to finalize a firmware soon so I would appreciate feedback if any ASAP. 

The definitions below aren't 100% matching the driver I posted earlier,
I'll post a new driver soon.

* The OPB node needs a "clock-frequency" property

* In the EMAC node itself (plb5/plb4/opb/ethernet)

 - name              : "ethernet"
 - device_type       : "network"
 - compatible        : compatible list, contains 2 entries, first is "emac-CHIP" where
                       CHIP is the host ASIC (440gx, 405gp, axon) and second is either
                       "emac" or "emac4".
                       For axon, thus, we have: "emac-axon","emac4"
 - model             : optional model string
 - interrupts	     : <interrupt mapping for EMAC IRQ and WOL IRQ>
 - interrupt-parent  : optional, if needed for interrupt mapping
 - reg               : <registers mapping>
 - local-mac-address : 6 bytes, MAC address
 - mal-device        : 1 cell, phandle of the associated McMAL node
 - mal-tx-channel    : 1 cell, index of the tx channel on McMAL associated with this EMAC
 - mal-rx-channel    : 1 cell, index of the rx channel on McMAL associated with this EMAC
 - 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)
 - max-mtu           : 1 cell, maximum MTU supported in bytes
 - rx-fifo-size      : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec operations.
                       For axon, 2048
 - rx-fifo-size-gige : 1 cell, optional, Rx fifo size in bytes for 1000 Mb/sec operations
                       (if absent the value is the same as rx-fifo-size).
                       For axon, either absent or 2048.
 - tx-fifo-size      : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec operations. For axon
 - tx-fifo-size-gige : 1 cell, optional, Tx fifo size in bytes for 1000 Mb/sec operations
                       (if absent the value is the same as tx-fifo-size)
                       For axon, either absent or 2048.
 - fifo-entry-size   : 1 cell, size of a fifo entry (used to calculate thresholds)
                       For axon, 0x00000010
 - mal-burst-size    : 1 cell, MAL burst size (used to calculate thresholds) 
 - phy-mode          : 1 cell, Mode of operations of the PHY interface:
                         #define PHY_MODE_NA    0
                         #define PHY_MODE_MII   1
                         #define PHY_MODE_RMII  2
                         #define PHY_MODE_SMII  3
                         #define PHY_MODE_RGMII 4
                         #define PHY_MODE_TBI   5
                         #define PHY_MODE_GMII  6
                         #define PHY_MODE_RTBI  7
                         #define PHY_MODE_SGMII 8
                       For axon, it is PHY_MODE_RGMII
 - phy-address       : 1 cell, optional, MDIO address of the PHY. If absent, a search
                       is performed
                       For axon: please fill with approriate value, I don't have it at
                       hand, it depends on the board and the EMAC of course.
 - phy-map           : 1 cell, optional, bitmap of addresses to probe the PHY for, used
                       if phy-address is absent. bit 0x00000001 is MDIO address 0. For axon
                       it can be absent, thouugh my current driver doesn't handle phy-address
                       yet so for now, keep 0x00ffffff in it.
 - mdio-device       : 1 cell, optional. If shared MDIO registers (440EP), phandle of the EMAC
                       to use to drive the MDIO lines for the PHY used by this EMAC.
                       For axon: absent
 - zmii-device       : 1 cell, optional. If connected to a ZMII, phandle of the ZMII device node
                       For axon: absent
 - zmii-channel      : 1 cell, optional. If connected to a ZMII, which channel or 0xffffffff if
                       ZMII is only used for MDIO
 - rgmii-device      : 1 cell, optional. If connected to a RGMII, phandle of the RGMII device node
                       For axon: phandle of plb5/plb4/opb/rgmii
 - rgmii-channel     : 1 cell, optional. If connected to a RGMII, which channel
                       Fox axon: present, whatever value is appropriate for each EMAC, that is
                       the content of the current (bogus) "phy-port" property
 - tah-device        : 1 cell, optional. If connected to a TAH engine for offload, phandle of
                       the TAH device node
 - tah-channel       : 1 cell, optional. If appropriate, channel used on the TAH engine

* In the McMAL node

 - name               : "mcmal"
 - device_type        : "mcmal-dma"
 - compatible         : compatible list, containing 2 entries, first is "mcmal-CHIP" where
                        CHIP is the hose ASIC (like emac) and the second is either "mcmal"
                        or "mcmal2".
                      : For axon, "mcmal-axon","mcmal2"
 - model              : optional model string
 - interrupts         : <interrupt mapping for the MAL interrupts sources:
                         5 sources: tx_eob, rx_eob, serr, txde, rxde>.
                        For axon: This is _different_ from the current firmware. We use
                        the "delayed" interrupts for txeob and rxeob. Thus we end up with
                        mapping those 5 MPIC interrupts, all level positive sensitive:
                        10, 11, 32, 33, 34 (in decimal)
 - dcr-reg            : < DCR registers range >
 - dcr-parent         : if needed for dcr-reg
 - num-tx-chans       : 1 cell, number of Tx channels
 - num-rx-chans       : 1 cell, number of Rx channels

* In the ZMII node

 - name               : "zmii"
 - device_type        : "zmii"
 - compatible         : compatible list, containing 2 entries, first is "zmii-CHIP" where
                        CHIP is the hose ASIC (like emac) and the second is "zmii"
                      : For axon, "zmii-axon","zmii"
 - model              : optional model string
 - reg                : <registers mapping>

* In the RGMII node

 - name               : "rgmii"
 - device_type        : "rgmii"
 - compatible         : compatible list, containing 2 entries, first is "rgmii-CHIP" where
                        CHIP is the hose ASIC (like emac) and the second is "rgmii"
                      : For axon, "rgmii-axon","rgmii"
 - model              : optional model string
 - reg                : <registers mapping>
 - revision           : as provided by the RGMII new version register if available
                        For axon: 0x0000012a


Ben.

Re: EMAC OF binding....

[Segher Boessenkool]

>  - compatible        : compatible list, contains 2 entries, first is 
> "emac-CHIP" where
>                        CHIP is the host ASIC (440gx, 405gp, axon) and 
> second is either
>                        "emac" or "emac4".
>                        For axon, thus, we have: "emac-axon","emac4"

"ibm,emac-axon" etc. please.

>  - local-mac-address : 6 bytes, MAC address

Don't forget "mac-address", if the device is opened
in OF; and "max-frame-size" please.

>  - 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?

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

>  - mal-burst-size    : 1 cell, MAL burst size (used to calculate 
> thresholds)

In bytes?


Segher

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

On Mon, 2007-01-08 at 07:38 +0100, Segher Boessenkool wrote:
> >  - compatible        : compatible list, contains 2 entries, first is 
> > "emac-CHIP" where
> >                        CHIP is the host ASIC (440gx, 405gp, axon) and 
> > second is either
> >                        "emac" or "emac4".
> >                        For axon, thus, we have: "emac-axon","emac4"
> 
> "ibm,emac-axon" etc. please.

Why ? In the -content- of a compatible property ? haven't seen that much
before.

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

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

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

> >  - mal-burst-size    : 1 cell, MAL burst size (used to calculate 
> > thresholds)
> 
> In bytes?

Yup.

Ben.

Re: EMAC OF binding....

[David Gibson]

On Tue, Jan 09, 2007 at 07:32:32AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2007-01-08 at 07:38 +0100, Segher Boessenkool wrote:
> > >  - compatible        : compatible list, contains 2 entries, first is 
> > > "emac-CHIP" where
> > >                        CHIP is the host ASIC (440gx, 405gp, axon) and 
> > > second is either
> > >                        "emac" or "emac4".
> > >                        For axon, thus, we have: "emac-axon","emac4"
> > 
> > "ibm,emac-axon" etc. please.
> 
> Why ? In the -content- of a compatible property ? haven't seen that much
> before.

I tend to agree with Segher.  "emac" is a bit too generic - no doubt
some company either already has, or will later decide that "emac" is
an obvious name for their Ethernet MAC.  We want something to specify
that we're talking about IBM Microelectronics notion of "emac".

> > >  - 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.
> 
> > >  - 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).
> 
> > >  - 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.
> 
> > >  - mal-burst-size    : 1 cell, MAL burst size (used to calculate 
> > > thresholds)
> > 
> > In bytes?
> 
> Yup.

We should really set up a central place to record all these device
tree nodes and properties we're defining.

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

Re: EMAC OF binding....

[Segher Boessenkool]

> We should really set up a central place to record all these device
> tree nodes and properties we're defining.

I'm in the process of setting up a Wiki to collect
all kinds of OF stuff -- one big goal is to serve
as a 21st century (and more informal) version of
the old OF working group wrt creating bindings, etc.

No idea how it will work out, and it's not there yet,
but we'll see where this goes.  In the meantime, it's
probably easiest for you to put the proposed device
bindings in a text file in your Linux kernel driver
directory.


Segher

Re: EMAC OF binding....

[Segher Boessenkool]

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

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

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

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

Ah ok.

Ben.

Re: EMAC OF binding....

[Segher Boessenkool]

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

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

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

Re: EMAC OF binding....

[Segher Boessenkool]

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

You give the phandle of your emac node as argument, that
works just fine with what I proposed too (the SoC PM node
knows the phandles of the emac's).  I think your way isn't
all that clean architecturally and can easily lead to
problems later on; the emac shouldn't have to know *anything*
about the structure of the SoC.

But feel free to do what you want, it's certainly not
a *huge* problem ;-)


Segher

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

> You give the phandle of your emac node as argument, that
> works just fine with what I proposed too (the SoC PM node
> knows the phandles of the emac's).  I think your way isn't
> all that clean architecturally and can easily lead to
> problems later on; the emac shouldn't have to know *anything*
> about the structure of the SoC.
> 
> But feel free to do what you want, it's certainly not
> a *huge* problem ;-)

Well, we use that method for most things,for example, the emac has
phandles to the zmii/rgmii/etc... for that specific case however, I
still prefer a cell index.

Ben.

Re: EMAC OF binding....

[Segher Boessenkool]

> Well, we use that method for most things,for example, the emac has
> phandles to the zmii/rgmii/etc... for that specific case however, I
> still prefer a cell index.

How about you put both in the device tree, and the kernel
can use whatever it wants -- best of both worlds :-)


Segher

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

On Tue, 2007-01-09 at 22:57 +0100, Segher Boessenkool wrote:
> > Well, we use that method for most things,for example, the emac has
> > phandles to the zmii/rgmii/etc... for that specific case however, I
> > still prefer a cell index.
> 
> How about you put both in the device tree, and the kernel
> can use whatever it wants -- best of both worlds :-)

I don't see the need of having some weird "soc" node that doesn't quite
mean anything (especially on axon) that has phandles to every sub device
in there :-)

I really don't see the interest in your approach but I may have missed
something.

On those ASICs, every device almost needs to know what is it's "cell
index" because of little details here or there. I really see that as an
attribute of the device and thus should be a property of the node.
 
Ben.

Re: EMAC OF binding....

[Segher Boessenkool]

> I don't see the need of having some weird "soc" node that doesn't quite
> mean anything (especially on axon) that has phandles to every sub 
> device
> in there :-)

Well simply, if I understood you correctly, you have some
register where some bits control emac #0 and some control
emac #1.  This register can't belong to either of those
devices because it can't belong to both, so it has to
belong to some "control" / "power management" / whatever
device.

> On those ASICs, every device almost needs to know what is it's "cell
> index" because of little details here or there.

Yes.

> I really see that as an
> attribute of the device and thus should be a property of the node.

You still need to describe that register somewhere in the
device tree.


Segher

Re: EMAC OF binding....

[David Gibson]

On Tue, Jan 09, 2007 at 11:17:07PM +0100, Segher Boessenkool wrote:
> > I don't see the need of having some weird "soc" node that doesn't quite
> > mean anything (especially on axon) that has phandles to every sub 
> > device
> > in there :-)
> 
> Well simply, if I understood you correctly, you have some
> register where some bits control emac #0 and some control
> emac #1.  This register can't belong to either of those
> devices because it can't belong to both, so it has to
> belong to some "control" / "power management" / whatever
> device.

I believe there are also some cases where you need to put the index
value itself into a field of some global control register.

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

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

On Tue, 2007-01-09 at 23:17 +0100, Segher Boessenkool wrote:
> > I don't see the need of having some weird "soc" node that doesn't quite
> > mean anything (especially on axon) that has phandles to every sub 
> > device
> > in there :-)
> 
> Well simply, if I understood you correctly, you have some
> register where some bits control emac #0 and some control
> emac #1.  This register can't belong to either of those
> devices because it can't belong to both, so it has to
> belong to some "control" / "power management" / whatever
> device.
> 
> > On those ASICs, every device almost needs to know what is it's "cell
> > index" because of little details here or there.
> 
> Yes.
> 
> > I really see that as an
> > attribute of the device and thus should be a property of the node.
> 
> You still need to describe that register somewhere in the
> device tree.

I will not describe every single weird clock control or other magic DCRs
in the device-tree. That is simply over-bloat. We don't describe the U3
clock control or PM registers on js2x's for example, nor do we describe
the various individual registers controlling the HT link...

Ben.

Re: EMAC OF binding....

[Segher Boessenkool]

> I will not describe every single weird clock control or other magic 
> DCRs
> in the device-tree. That is simply over-bloat.

Sure, I know what you mean.

> We don't describe the U3
> clock control or PM registers on js2x's for example,

"reg" = f8000000 01000000

yes we do.  Not the individual regs sure, but we don't
do that for anything else either.

> nor do we describe
> the various individual registers controlling the HT link...

I never said you should describe the individual regs.
I'm saying the regs should be described somewhere, and
they can't be in the enet devices, so they'll have to
be elsewhere.

Oh well, I'm sure you'll figure it out,


Segher

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

On Mon, 2007-01-08 at 07:38 +0100, Segher Boessenkool wrote:
> >  - compatible        : compatible list, contains 2 entries, first is 
> > "emac-CHIP" where
> >                        CHIP is the host ASIC (440gx, 405gp, axon) and 
> > second is either
> >                        "emac" or "emac4".
> >                        For axon, thus, we have: "emac-axon","emac4"
> 
> "ibm,emac-axon" etc. please.

What would you do for things like 440gx ? ibm,440gx or amcc,440gx ?

Ben.

Re: EMAC OF binding....

[Kumar Gala]

On Jan 29, 2007, at 6:25 PM, Benjamin Herrenschmidt wrote:

> On Mon, 2007-01-08 at 07:38 +0100, Segher Boessenkool wrote:
>>>  - compatible        : compatible list, contains 2 entries, first is
>>> "emac-CHIP" where
>>>                        CHIP is the host ASIC (440gx, 405gp, axon)  
>>> and
>>> second is either
>>>                        "emac" or "emac4".
>>>                        For axon, thus, we have: "emac-axon","emac4"
>>
>> "ibm,emac-axon" etc. please.
>
> What would you do for things like 440gx ? ibm,440gx or amcc,440gx ?

Does emac really vary that much between the chips its in?  I know  
chatting with Ben that axon did some evil things, but how much  
difference exists on 4xx implementations?

- k

Re: EMAC OF binding....

[David Gibson]

On Mon, Jan 29, 2007 at 06:45:30PM -0600, Kumar Gala wrote:
> 
> On Jan 29, 2007, at 6:25 PM, Benjamin Herrenschmidt wrote:
> 
> > On Mon, 2007-01-08 at 07:38 +0100, Segher Boessenkool wrote:
> >>>  - compatible        : compatible list, contains 2 entries, first is
> >>> "emac-CHIP" where
> >>>                        CHIP is the host ASIC (440gx, 405gp, axon)  
> >>> and
> >>> second is either
> >>>                        "emac" or "emac4".
> >>>                        For axon, thus, we have: "emac-axon","emac4"
> >>
> >> "ibm,emac-axon" etc. please.
> >
> > What would you do for things like 440gx ? ibm,440gx or amcc,440gx ?
> 
> Does emac really vary that much between the chips its in?  I know  
> chatting with Ben that axon did some evil things, but how much  
> difference exists on 4xx implementations?

Very little, I think, but I believe the idea is to include the
detailed information, just in case in future we discover some errata
or other peculiarities in one chip's version of emac.

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

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

> Does emac really vary that much between the chips its in?  I know  
> chatting with Ben that axon did some evil things, but how much  
> difference exists on 4xx implementations?

They all seem to have subtle differences, which is why I want the actual
chip to be the first entry in the compatible property.

Ben.

Re: EMAC OF binding....

[Benjamin Herrenschmidt]

On Tue, 2007-01-30 at 12:50 +1100, Benjamin Herrenschmidt wrote:
> > Does emac really vary that much between the chips its in?  I know  
> > chatting with Ben that axon did some evil things, but how much  
> > difference exists on 4xx implementations?
> 
> They all seem to have subtle differences, which is why I want the actual
> chip to be the first entry in the compatible property.

Note that the goal here is not to have different drivers bind on it, but
more to allow to use device_is_compatible() and/or use the void * data
of the probe list as a feature bits field.

Ben.