Message ID | 1358461134-13452-1-git-send-email-jacmet@sunsite.dk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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
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
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
>>>>> "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?
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
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
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
>>>>> "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 --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
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