[uClinux-dev] [PATCH] m68knommu: Add quirk and force fec to use RMII mode for m5441x.

[Steven King]

The m5441x enet-fec aren't quite the same as the fec found on other Coldfire
parts, so we need a quirk to help the fec do the right thing and on the
twr-mcf5441x atleast, we need to force the phy into RMII mode.


Signed-off-by: Steven King <sfking at fdwdc.com>
---
arch/m68k/platform/coldfire/device.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/m68k/platform/coldfire/device.c b/arch/m68k/platform/coldfire/device.c
index 11ecd23..ab88b69 100644
--- a/arch/m68k/platform/coldfire/device.c
+++ b/arch/m68k/platform/coldfire/device.c
@@ -13,6 +13,7 @@
#include <linux/io.h>
#include <linux/spi/spi.h>
#include <linux/gpio.h>
+#include <linux/fec.h>
#include <asm/traps.h>
#include <asm/coldfire.h>
#include <asm/mcfsim.h>
@@ -89,6 +90,18 @@ static struct platform_device mcf_uart = {
};

#ifdef CONFIG_FEC
+
+#ifdef CONFIG_M5441x
+#define FEC_NAME "enet-fec"
+static struct fec_platform_data fec_pdata = {
+ .phy = PHY_INTERFACE_MODE_RMII,
+};
+#define FEC_PDATA (&fec_pdata)
+#else
+#define FEC_NAME "fec"
+#define FEC_PDATA NULL
+#endif
+
/*
* Some ColdFire cores contain the Fast Ethernet Controller (FEC)
* block. It is Freescale's own hardware block. Some ColdFires
@@ -118,10 +131,11 @@ static struct resource mcf_fec0_resources[] = {
};

static struct platform_device mcf_fec0 = {
- .name = "fec",
+ .name = FEC_NAME,
.id = 0,
.num_resources = ARRAY_SIZE(mcf_fec0_resources),
.resource = mcf_fec0_resources,
+ .dev.platform_data = FEC_PDATA,
};

#ifdef MCFFEC_BASE1
@@ -149,10 +163,11 @@ static struct resource mcf_fec1_resources[] = {
};

static struct platform_device mcf_fec1 = {
- .name = "fec",
+ .name = FEC_NAME,
.id = 1,
.num_resources = ARRAY_SIZE(mcf_fec1_resources),
.resource = mcf_fec1_resources,
+ .dev.platform_data = FEC_PDATA,
};
#endif /* MCFFEC_BASE1 */
#endif /* CONFIG_FEC */

[Greg Ungerer]

Hi Steven,

Post by Steven King
The m5441x enet-fec aren't quite the same as the fec found on other Coldfire
parts, so we need a quirk to help the fec do the right thing and on the
twr-mcf5441x atleast, we need to force the phy into RMII mode.
Signed-off-by: Steven King<sfking at fdwdc.com>
---
arch/m68k/platform/coldfire/device.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/platform/coldfire/device.c b/arch/m68k/platform/coldfire/device.c
index 11ecd23..ab88b69 100644
--- a/arch/m68k/platform/coldfire/device.c
+++ b/arch/m68k/platform/coldfire/device.c
@@ -13,6 +13,7 @@
#include<linux/io.h>
#include<linux/spi/spi.h>
#include<linux/gpio.h>
+#include<linux/fec.h>
#include<asm/traps.h>
#include<asm/coldfire.h>
#include<asm/mcfsim.h>
@@ -89,6 +90,18 @@ static struct platform_device mcf_uart = {
};
#ifdef CONFIG_FEC
+
+#ifdef CONFIG_M5441x
+#define FEC_NAME "enet-fec"

So I see that the iMX guys have used a device type prefix here for
the fec name. Does it make any sense to use something like that
for the 5441x as well? So "5441x-fec"? Or will we just not
need to distinguish it this way?

Otherwise the patch looks good.

Regards
Greg

Post by Steven King
+static struct fec_platform_data fec_pdata = {
+ .phy = PHY_INTERFACE_MODE_RMII,
+};
+#define FEC_PDATA (&fec_pdata)
+#else
+#define FEC_NAME "fec"
+#define FEC_PDATA NULL
+#endif
+
/*
* Some ColdFire cores contain the Fast Ethernet Controller (FEC)
* block. It is Freescale's own hardware block. Some ColdFires
@@ -118,10 +131,11 @@ static struct resource mcf_fec0_resources[] = {
};
static struct platform_device mcf_fec0 = {
- .name = "fec",
+ .name = FEC_NAME,
.id = 0,
.num_resources = ARRAY_SIZE(mcf_fec0_resources),
.resource = mcf_fec0_resources,
+ .dev.platform_data = FEC_PDATA,
};
#ifdef MCFFEC_BASE1
@@ -149,10 +163,11 @@ static struct resource mcf_fec1_resources[] = {
};
static struct platform_device mcf_fec1 = {
- .name = "fec",
+ .name = FEC_NAME,
.id = 1,
.num_resources = ARRAY_SIZE(mcf_fec1_resources),
.resource = mcf_fec1_resources,
+ .dev.platform_data = FEC_PDATA,
};
#endif /* MCFFEC_BASE1 */
#endif /* CONFIG_FEC */

[Steven King]

Post by Greg Ungerer

Post by Steven King
+#ifdef CONFIG_M5441x
+#define FEC_NAME "enet-fec"

So I see that the iMX guys have used a device type prefix here for
the fec name. Does it make any sense to use something like that
for the 5441x as well? So "5441x-fec"? Or will we just not
need to distinguish it this way?

My thinking was that if tomorrow Freescale released a 'm5442x' with 4
enet-fecs then the same quirk would apply, but if it instead had a gigabit
enet-fec we'd still need a new quirk anyway; what I want to avoid was given
Freescale's fondness of producing varients, either using the wrong name for a
chip - 'my m5442x says it has 5441x-fec?' or having a half dozen quirk
entries that all selected the same feature. But I dont have strong feelings
about this, I just want the ethernet on my twr-mcf54418 to work.

[Greg Ungerer]

Hi Steven,

Post by Steven King

Post by Greg Ungerer

Post by Steven King
+#ifdef CONFIG_M5441x
+#define FEC_NAME "enet-fec"

So I see that the iMX guys have used a device type prefix here for
the fec name. Does it make any sense to use something like that
for the 5441x as well? So "5441x-fec"? Or will we just not
need to distinguish it this way?

My thinking was that if tomorrow Freescale released a 'm5442x' with 4
enet-fecs then the same quirk would apply, but if it instead had a gigabit
enet-fec we'd still need a new quirk anyway; what I want to avoid was given
Freescale's fondness of producing varients, either using the wrong name for a
chip - 'my m5442x says it has 5441x-fec?' or having a half dozen quirk
entries that all selected the same feature. But I dont have strong feelings
about this, I just want the ethernet on my twr-mcf54418 to work.

That is certainly true, Freescale don't have a good track record when
it comes to consistency of naming and use.

I don't feel that strongly about it, feel free to use whatever you
think is best.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg at snapgear.com
SnapGear Group, McAfee PHONE: [phone]
8 Gardner Close FAX: [phone]
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com