From: Grant Erickson <hidden> Date: 2008-07-07 23:32:01
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = "mii";'
are recognized and handled appropriately.
While logically, in software, "gmii" and "mii" modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson <redacted>
---
drivers/net/ibm_newemac/rgmii.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
Hrm... the setting of the register is exactly the same right ?
Do we -really- need that ?
Would you prefer?
+#define RGMII_FER_MII(idx) RGMII_FER_GMII(idx)
Having the "extra" mnemonic makes the code end up looking less like a typo
and more like a conscious decision: "Yes, we know MII and GMII are the same
setting, but we're being explicit about it."
-Grant
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-08 00:46:17
On Mon, 2008-07-07 at 16:47 -0700, Grant Erickson wrote:
Would you prefer?
+#define RGMII_FER_MII(idx) RGMII_FER_GMII(idx)
Having the "extra" mnemonic makes the code end up looking less like a typo
and more like a conscious decision: "Yes, we know MII and GMII are the same
setting, but we're being explicit about it."
Yeah, that looks better. Either that or a comment.
Cheers,
Ben.
From: Grant Erickson <hidden> Date: 2008-07-08 15:03:15
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = "mii";'
are recognized and handled appropriately.
While logically, in software, "gmii" and "mii" modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson <redacted>
---
drivers/net/ibm_newemac/rgmii.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
From: Stefan Roese <sr@denx.de> Date: 2008-07-08 15:36:50
On Tuesday 08 July 2008, Grant Erickson wrote:
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode =
"mii";' are recognized and handled appropriately.
While logically, in software, "gmii" and "mii" modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson <redacted>
Acked-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-09 03:23:39
On Tue, 2008-07-08 at 08:03 -0700, Grant Erickson wrote:
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = "mii";'
are recognized and handled appropriately.
While logically, in software, "gmii" and "mii" modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson <redacted>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Jeff, I'd like to apply that (and other EMAC patches for 2.6.27, do you
have anything else pending ?) via my tree provided you give me your ack.
The reason is that the multicast fix one is going that way as it touches
other arch files, and subsequent ones are now likely to conflict.
Let me know if that's ok with you in which case I'll stick your ack in
there.
Cheers,
Ben.
From: Jeff Garzik <hidden> Date: 2008-07-11 05:19:53
Benjamin Herrenschmidt wrote:
On Tue, 2008-07-08 at 08:03 -0700, Grant Erickson wrote:
quoted
This patch adds support to the RGMII handler in the EMAC driver for
the MII PHY mode such that device tree entries of the form `phy-mode = "mii";'
are recognized and handled appropriately.
While logically, in software, "gmii" and "mii" modes are the same,
they are wired differently, so it makes sense to allow DTS authors to
specify each explicitly.
Signed-off-by: Grant Erickson <redacted>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
ACK
Jeff, I'd like to apply that (and other EMAC patches for 2.6.27, do you
have anything else pending ?) via my tree provided you give me your ack.
The reason is that the multicast fix one is going that way as it touches
other arch files, and subsequent ones are now likely to conflict.
Let me know if that's ok with you in which case I'll stick your ack in
there.