Hello

I realize this is possibly off topic but I think I'll get some reasonable 
feedback here.

I'm interfacing to a different phy (LXT972, yes I know it's old;-) and 
everything works perfectly with the genphy driver however, the led control 
registers aren't set the way I want them to be. I verified that I can set 
the registers through the uboot mdio interface but, of course, the phy is 
reset when linux loads the network driver.

I see plenty of references in the kernel phy driver code to setting board 
specific fixups and I've also seen references to mii fixups instituted 
through the device tree. After considering both solutions the board fixup 
path seems more straight forward as I couldn't determine that the dt mii 
fixup was implemented in the beaglebone branch.

Obligatory info:

buildroot
ti kernel 4.1.36
uclibc 0.9.30

Beaglebone black C version.

So;

I have two locations where I believe it is reasonable to apply a local 
patch for my build and I want someone to comment on them; either that one 
is more appropriate than the other or that there is a more elegant solution.

Fixup function: Defined in a header file.

static int myboard_phy_fixups 
<http://lxr.free-electrons.com/ident?v=4.1;i=mpc8568_mds_phy_fixups>(struct 
phy_device <http://lxr.free-electrons.com/ident?v=4.1;i=phy_device> *phydev)
{

*    /* Set LED function */*
    err <http://lxr.free-electrons.com/ident?v=4.1;i=err> = phy_write 
<http://lxr.free-electrons.com/ident?v=4.1;i=phy_write>(phydev,0x14, 0x341A);

    if (err <http://lxr.free-electrons.com/ident?v=4.1;i=err>)
            return err <http://lxr.free-electrons.com/ident?v=4.1;i=err>;

    temp <http://lxr.free-electrons.com/ident?v=4.1;i=temp> = phy_read 
<http://lxr.free-electrons.com/ident?v=4.1;i=phy_read>(phydev, 0x14);

  if (temp <http://lxr.free-electrons.com/ident?v=4.1;i=temp> <=0)

          return temp <http://lxr.free-electrons.com/ident?v=4.1;i=temp>;

    return err <http://lxr.free-electrons.com/ident?v=4.1;i=err>;

}

Function call to be added in the indicated location.

phy_register_fixup_for_id 
<http://lxr.free-electrons.com/ident?v=4.1;i=phy_register_fixup_for_id>(phy_id, 
myboard_phy_fixups 
<http://lxr.free-electrons.com/ident?v=4.1;i=mpc8568_mds_phy_fixups>);

The two locations for inserting the register_fixup call:

1: In "*Linux <http://lxr.free-electrons.com/source/?v=4.1>/arch 
<http://lxr.free-electrons.com/source/arch/?v=4.1>/arm 
<http://lxr.free-electrons.com/source/arch/arm/?v=4.1>/mach-davinci 
<http://lxr.free-electrons.com/source/arch/arm/mach-davinci/?v=4.1>/common.c 
<http://lxr.free-electrons.com/source/arch/arm/mach-davinci/common.c?v=4.1>/davinci_common/
 <http://lxr.free-electrons.com/ident?v=4.1;i=davinci_common_init> 
@*davinci_common_init 
<http://lxr.free-electrons.com/ident?v=4.1;i=davinci_common_init>" just prior 
to the function return.

2: In "*Linux <http://lxr.free-electrons.com/source/?v=4.1>/drivers 
<http://lxr.free-electrons.com/source/drivers/?v=4.1>/net 
<http://lxr.free-electrons.com/source/drivers/net/?v=4.1>/ethernet 
<http://lxr.free-electrons.com/source/drivers/net/ethernet/?v=4.1>/ti 
<http://lxr.free-electrons.com/source/drivers/net/ethernet/ti/?v=4.1>/cpsw.c 
<http://lxr.free-electrons.com/source/drivers/net/ethernet/ti/cpsw.c?v=4.1>/ 
@cpsw_init <http://lxr.free-electrons.com/ident?v=4.1;i=cpsw_init>*" just prior 
to "return platform_driver_register 
<http://lxr.free-electrons.com/ident?v=4.1;i=platform_driver_register>(&cpsw_driver
 <http://lxr.free-electrons.com/ident?v=4.1;i=cpsw_driver>);"

Thanks in advance for your advice, thoughts, and opinions.

Chris LaRocque 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/4ebc53ad-e6cc-4354-860e-f041ae864a27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to