diff mbox

[PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt

Message ID 1358461134-13452-1-git-send-email-jacmet@sunsite.dk (mailing list archive)
State New, archived
Headers show

Commit Message

Peter Korsgaard Jan. 17, 2013, 10:18 p.m. UTC
When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
mode in U-Boot), nothing updates the ethernet hwaddr specified for the
CPSW slaves, causing the driver to use a random hwaddr, which is some times
troublesome.

The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
more sense to default to these rather than random ones. Add a fixup step
which adds mac-address dt properties using the efuse addresses if the DTB
didn't contain valid ones.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
Changes since v1:
- Use omap_arch_initcall as pointed out by Tony

 arch/arm/mach-omap2/Makefile      |    3 ++
 arch/arm/mach-omap2/am33xx-cpsw.c |   94 +++++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/control.h     |    4 ++
 3 files changed, 101 insertions(+)
 create mode 100644 arch/arm/mach-omap2/am33xx-cpsw.c

Comments

Mugunthan V N Jan. 18, 2013, 5:14 a.m. UTC | #1
On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
> When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
> U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
> mode in U-Boot), nothing updates the ethernet hwaddr specified for the
> CPSW slaves, causing the driver to use a random hwaddr, which is some times
> troublesome.
>
> The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
> more sense to default to these rather than random ones. Add a fixup step
> which adds mac-address dt properties using the efuse addresses if the DTB
> didn't contain valid ones.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>

This implementation looks fine.
Acked-by: Mugunthan V N <mugunthanvnm@ti.com>

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Jackson July 8, 2013, 12:42 p.m. UTC | #2
On 18/01/13 05:14, Mugunthan V N wrote:
> On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
>> When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
>> U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
>> mode in U-Boot), nothing updates the ethernet hwaddr specified for the
>> CPSW slaves, causing the driver to use a random hwaddr, which is some times
>> troublesome.
>>
>> The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
>> more sense to default to these rather than random ones. Add a fixup step
>> which adds mac-address dt properties using the efuse addresses if the DTB
>> didn't contain valid ones.
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>>
> 
> This implementation looks fine.
> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>

Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Jackson July 12, 2013, 2:33 p.m. UTC | #3
On 08/07/13 13:42, Mark Jackson wrote:
> On 18/01/13 05:14, Mugunthan V N wrote:
>> On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
>>> When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
>>> U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
>>> mode in U-Boot), nothing updates the ethernet hwaddr specified for the
>>> CPSW slaves, causing the driver to use a random hwaddr, which is some times
>>> troublesome.
>>>
>>> The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
>>> more sense to default to these rather than random ones. Add a fixup step
>>> which adds mac-address dt properties using the efuse addresses if the DTB
>>> didn't contain valid ones.
>>>
>>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>>>
>>
>> This implementation looks fine.
>> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
> 
> Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>

Is this ever going to be put into the mainline code ?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Korsgaard July 15, 2013, 5:31 a.m. UTC | #4
>>>>> "Mark" == Mark Jackson <mpfj-list@newflow.co.uk> writes:

Hi,

 Mark> On 08/07/13 13:42, Mark Jackson wrote:
 >> On 18/01/13 05:14, Mugunthan V N wrote:
 >>> On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
 >>>> When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
 >>>> U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
 >>>> mode in U-Boot), nothing updates the ethernet hwaddr specified for the
 >>>> CPSW slaves, causing the driver to use a random hwaddr, which is some times
 >>>> troublesome.
 >>>> 
 >>>> The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
 >>>> more sense to default to these rather than random ones. Add a fixup step
 >>>> which adds mac-address dt properties using the efuse addresses if the DTB
 >>>> didn't contain valid ones.
 >>>> 
 >>>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
 >>> 
 >>> This implementation looks fine.
 >>> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
 >> 
 >> Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>

 Mark> Is this ever going to be put into the mainline code ?

Good question. Tony, could you please pick this up? It has been pending
since January and has a number of acks.

Do you want me to resend?
Koen Kooi Sept. 5, 2013, 8:11 p.m. UTC | #5
Op 8 jul. 2013, om 14:42 heeft Mark Jackson <mpfj-list@newflow.co.uk> het volgende geschreven:

> On 18/01/13 05:14, Mugunthan V N wrote:
>> On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
>>> When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
>>> U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
>>> mode in U-Boot), nothing updates the ethernet hwaddr specified for the
>>> CPSW slaves, causing the driver to use a random hwaddr, which is some times
>>> troublesome.
>>> 
>>> The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
>>> more sense to default to these rather than random ones. Add a fixup step
>>> which adds mac-address dt properties using the efuse addresses if the DTB
>>> didn't contain valid ones.
>>> 
>>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>>> 
>> 
>> This implementation looks fine.
>> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
> 
> Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>

Tested-by: Koen Kooi <koen@dominion.thruhere.net>



--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Matt Porter Sept. 5, 2013, 8:16 p.m. UTC | #6
On Mon, Jul 15, 2013 at 07:31:18AM +0200, Peter Korsgaard wrote:
> >>>>> "Mark" == Mark Jackson <mpfj-list@newflow.co.uk> writes:
> 
> Hi,
> 
>  Mark> On 08/07/13 13:42, Mark Jackson wrote:
>  >> On 18/01/13 05:14, Mugunthan V N wrote:
>  >>> On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
>  >>>> When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
>  >>>> U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
>  >>>> mode in U-Boot), nothing updates the ethernet hwaddr specified for the
>  >>>> CPSW slaves, causing the driver to use a random hwaddr, which is some times
>  >>>> troublesome.
>  >>>> 
>  >>>> The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
>  >>>> more sense to default to these rather than random ones. Add a fixup step
>  >>>> which adds mac-address dt properties using the efuse addresses if the DTB
>  >>>> didn't contain valid ones.
>  >>>> 
>  >>>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>  >>> 
>  >>> This implementation looks fine.
>  >>> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
>  >> 
>  >> Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
> 
>  Mark> Is this ever going to be put into the mainline code ?
> 
> Good question. Tony, could you please pick this up? It has been pending
> since January and has a number of acks.
> 
> Do you want me to resend?

Also working nicely here on 3.11.

Tested-by: Matt Porter <matt.porter@linaro.org>

Kevin or Olof: can you apply? Seems to be continuing no response after
Ack back in January.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Olof Johansson Sept. 5, 2013, 8:22 p.m. UTC | #7
On Thu, Sep 5, 2013 at 1:16 PM, Matt Porter <matt.porter@linaro.org> wrote:
> On Mon, Jul 15, 2013 at 07:31:18AM +0200, Peter Korsgaard wrote:
>> >>>>> "Mark" == Mark Jackson <mpfj-list@newflow.co.uk> writes:
>>
>> Hi,
>>
>>  Mark> On 08/07/13 13:42, Mark Jackson wrote:
>>  >> On 18/01/13 05:14, Mugunthan V N wrote:
>>  >>> On 1/18/2013 3:48 AM, Peter Korsgaard wrote:
>>  >>>> When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
>>  >>>> U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
>>  >>>> mode in U-Boot), nothing updates the ethernet hwaddr specified for the
>>  >>>> CPSW slaves, causing the driver to use a random hwaddr, which is some times
>>  >>>> troublesome.
>>  >>>>
>>  >>>> The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
>>  >>>> more sense to default to these rather than random ones. Add a fixup step
>>  >>>> which adds mac-address dt properties using the efuse addresses if the DTB
>>  >>>> didn't contain valid ones.
>>  >>>>
>>  >>>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>>  >>>
>>  >>> This implementation looks fine.
>>  >>> Acked-by: Mugunthan V N <mugunthanvnm@ti.com>
>>  >>
>>  >> Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
>>
>>  Mark> Is this ever going to be put into the mainline code ?
>>
>> Good question. Tony, could you please pick this up? It has been pending
>> since January and has a number of acks.
>>
>> Do you want me to resend?
>
> Also working nicely here on 3.11.
>
> Tested-by: Matt Porter <matt.porter@linaro.org>
>
> Kevin or Olof: can you apply? Seems to be continuing no response after
> Ack back in January.

I have no idea what the patch is, it's no longer in the email. Can you
resend it, please?


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Korsgaard Sept. 5, 2013, 9:08 p.m. UTC | #8
>>>>> "Olof" == Olof Johansson <olof@lixom.net> writes:

 >> Tested-by: Matt Porter <matt.porter@linaro.org>
 >> 
 >> Kevin or Olof: can you apply? Seems to be continuing no response after
 >> Ack back in January.

 Olof> I have no idea what the patch is, it's no longer in the email. Can you
 Olof> resend it, please?

Sure, one moment.
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 65fb6fb..54fb2ee 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -298,4 +298,7 @@  endif
 emac-$(CONFIG_TI_DAVINCI_EMAC)		:= am35xx-emac.o
 obj-y					+= $(emac-m) $(emac-y)
 
+cpsw-$(CONFIG_TI_CPSW)			:= am33xx-cpsw.o
+obj-y					+= $(cpsw-m) $(cpsw-y)
+
 obj-y					+= common-board-devices.o twl-common.o dss-common.o
diff --git a/arch/arm/mach-omap2/am33xx-cpsw.c b/arch/arm/mach-omap2/am33xx-cpsw.c
new file mode 100644
index 0000000..eec29a4
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-cpsw.c
@@ -0,0 +1,94 @@ 
+/*
+ * am335x specific cpsw dt fixups
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/etherdevice.h>
+#include <linux/of.h>
+#include <linux/of_net.h>
+
+#include "soc.h"
+#include "control.h"
+
+/**
+ * am33xx_dt_cpsw_set_mac_from_efuse - Add mac-address property using
+ * ethernet hwaddr from efuse
+ * @np:		Pointer to the cpsw slave to set mac address of
+ * @idx:	Mac address index to use from efuse
+ */
+static void am33xx_dt_cpsw_set_mac_from_efuse(struct device_node *np, int idx)
+{
+	struct property *prop;
+	u32 lo, hi;
+	u8 *mac;
+
+	switch (idx) {
+	case 0:
+		lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_LOW);
+		hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_HIGH);
+		break;
+
+	case 1:
+		lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_LOW);
+		hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_HIGH);
+		break;
+
+	default:
+		pr_err("cpsw.%d: too many slaves found\n", idx);
+		return;
+	}
+
+	prop = kzalloc(sizeof(*prop) + ETH_ALEN, GFP_KERNEL);
+	if (!prop)
+		return;
+
+	prop->value = prop + 1;
+	prop->length = ETH_ALEN;
+	prop->name = kstrdup("mac-address", GFP_KERNEL);
+	if (!prop->name) {
+		kfree(prop);
+		return;
+	}
+
+	mac = prop->value;
+
+	mac[0] = hi;
+	mac[1] = hi >> 8;
+	mac[2] = hi >> 16;
+	mac[3] = hi >> 24;
+	mac[4] = lo;
+	mac[5] = lo >> 8;
+
+	of_update_property(np, prop);
+
+	pr_info("cpsw.%d: No hwaddr in dt. Using %pM from efuse\n", idx, mac);
+}
+
+static int __init am33xx_dt_cpsw_mac_fixup(void)
+{
+	struct device_node *np, *slave;
+	int idx = 0;
+
+	if (!soc_is_am33xx())
+		return -ENODEV;
+
+	for_each_compatible_node(np, NULL, "ti,cpsw")
+		for_each_node_by_name(slave, "slave") {
+			if (!of_get_mac_address(slave))
+				am33xx_dt_cpsw_set_mac_from_efuse(slave, idx);
+			idx++;
+		}
+
+	return 0;
+}
+omap_arch_initcall(am33xx_dt_cpsw_mac_fixup);
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..266d512 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -352,6 +352,10 @@ 
 /* AM33XX CONTROL_STATUS register */
 #define AM33XX_CONTROL_STATUS		0x040
 #define AM33XX_CONTROL_SEC_CLK_CTRL	0x1bc
+#define AM33XX_CONTROL_MAC_ID0_LOW	0x630
+#define AM33XX_CONTROL_MAC_ID0_HIGH	0x634
+#define AM33XX_CONTROL_MAC_ID1_LOW	0x638
+#define AM33XX_CONTROL_MAC_ID1_HIGH	0x63c
 
 /* AM33XX CONTROL_STATUS bitfields (partial) */
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT		22