micrel: ksz8051 badly detected as ksz8031

Dear,

still having trouble debugging why, moving from kernel 3.5.1 to 3.17 i don't have any phy link. This must be an issue of my platform that have to set something additional from my board.c than as in kernel 3.5.1.

Anyway, my hardware has Micrel KSZ8051, but phy probing seems to get erroneously the id KSZ8031 while older kernel 3.5.1 was getting correctly KSZ8051. This is The first thing that make me think that phy link miss due to a bad setup.

The whole mii / mdio / mdio_bus / phy / dacinvi-emac group of drivers is really complex for me to be debugged. Who reads the PHY ID ? Is the wrong PHY ID a sign that mdio is not working properly ?

Kernel 3.5.1
net eth0: attached PHY driver [Micrel KS8051] (mii_bus:phy_addr=davinci_mdio-0:00, id=221556)

Kernel 3.17.0
net eth0: attached PHY driver [Micrel KSZ8031] (mii_bus:phy_addr=davinci_mdio-0:00, id=221556)

I see phy leds up (both lights up) until the first "Sending discover..." message.

UTC
Time zone set
Starting network...
davinci_mdio davinci_mdio.0: resetting idled controller
ipam390_phy_fixup: applying ipam390_phy_fixup
micrel.c: ksz8021_config_init: val=00000202
micrel.c: ksz8021_config_init: val=00000202
micrel.c: enabling 50MHZ input
micrel.c: enabled 50MHZ input
net eth0: attached PHY driver [Micrel KSZ8031] (mii_bus:phy_addr=davinci_mdio-0:00, id=221556) udhcpc (v1.20.2) started
Sending discover...
davinci_emac.c: emac_adjust_link: entering, phydev->link=0
Sending discover...
Sending discover...
No lease, failing

My system have: ARM AM1808 (OMAP-L138),
- davinci-emac.c
- RMII and MDIO to interface to Micrel KSZ8051
- sourcinf 50MHZ clock from emac RMII

Every help is appreciated.

Regards,
Angelo

I confirm this seems to be an issue of recent versions of kernel driver "micrel.c".

I just compiled kernel 3.17.0 with micrel.c driver 3.5.1, link is up and running.

If you need debug info, or to test a patch, let me know.

Regards
angelo

Hi,

i confirm, moving from kernel 3.5.1 to 3.17.0 the network Micrel phy link is non functional.

The non working detection of KSZ8051 (taken default, ksz8031, from mdio driver) breaks the functionality.

But this is probably due to the fact i am not using DT population, but just using a minimal DT just to boot (to avoidto change the bootloader setup that's already into production).

What change from 3.5.1 and 3.17.0 is mainly that DT support has been added.

If i copy the old 3.5.1 micrel.c i can have the link, but network was not working properly.

So i brute-fixed the issue into 3.17.0 with this small patchfor my need, Imiss the complete understanding still for a proper fix.Hope you can elucidate.

diff -crB drivers/net/ethernet/ti/davinci_mdio.c ../linux-3.17/drivers/net/ethernet/ti/davinci_mdio.c
*** drivers/net/ethernet/ti/davinci_mdio.c 2014-10-13 21:02:25.522022750 +0200
--- ../linux-3.17/drivers/net/ethernet/ti/davinci_mdio.c 2014-10-05 21:23:04.000000000 +0200
***************
*** 320,327 ****
}
#endif

- extern struct phy_driver *micrel_pdrv;
-
static int davinci_mdio_probe(struct platform_device *pdev)

  {
        struct mdio_platform_data *pdata = dev_get_platdata(&pdev->dev);
--- 320,325 ----
***************
*** 397,408 ****
        for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
                phy = data->bus->phy_map[addr];
                if (phy) {
-                       /*
-                        * Angelo : micrel broken the link adding OF support.
-                        * waiting for the patch, i force the link to out phy.
-                        */
-                       phy->drv = micrel_pdrv;
-                       data->bus->phy_map[addr] = phy;
                        dev_info(dev, "phy[%d]: device %s, driver %s\n",
                                 phy->addr, dev_name(&phy->dev),
                                 phy->drv ? phy->drv->name : "unknown");

--- 395,400 ----

diff -crB drivers/net/phy/micrel.c ../linux-3.17/drivers/net/phy/micrel.c
*** drivers/net/phy/micrel.c 2014-10-13 21:00:03.273616086 +0200
--- ../linux-3.17/drivers/net/phy/micrel.c 2014-10-05 21:23:04.000000000 +0200
***************
*** 640,650 ****

                ARRAY_SIZE(ksphy_driver));

}

- /*
- * angelo, temporary patch
- */
- struct phy_driver *micrel_pdrv = &ksphy_driver[5]; -
module_init(ksphy_init); module_exit(ksphy_exit);

Regards, angelo

Dear,

have to apologize for the confusion, previous patch is not the proper fix, since it is not solving completely the issue.

And also, i mainly misunderstood the issue.

The issue i am experiencing is :

https://lkml.org/lkml/2013/9/18/259

Mainly, i have Micrel chip marked KSZ8051(RNL), but the product Id in the silicon is KSZ8031 and linux detects it as KSZ8031.
The attmept to mdio boot override register kill the Micrel functionality.

So i just replaced the phy_id code (hardcoded) in the code mdio detecion routine.

Also, i am not giving to the Micrel any external 50Mhz clock, but as per default, the Micrel is giving the clock out to the davinci-emac. So no fixups are needed for my case.

But i still have a last issue now: i see link is up 100Mbit, but no packets are really sent, and nothing is received.
Led links are up.

Time zone set
Starting network...
davinci_mdio davinci_mdio.0: resetting idled controller
net eth0: attached PHY driver [Micrel KSZ8051] (mii_bus:phy_addr=davinci_mdio-0:00, id=221550) udhcpc (v1.20.2) started
Sending discover...
davinci_emac davinci_emac.1 eth0: Link is Up - 100Mbps/Full - flow control off Sending discover...
Sending discover...
No lease, failing
....

[root@barix ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:08:E1:03:2A:C5
inet6 addr: fe80::208:e1ff:fe03:2ac5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:13 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:2258 (2.2 KiB) Interrupt:33

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Packets seems sent but they are not sent at all (checking from WS) and no packets are received at the same time.

Reagrds,
Angelo

Ok, so basically your bootloader does something that Linux does, and once Linux boots, it will reset the PHY to put it in a known state. If you can snoop the MDIO read/writes done in your bootloader environment, that might help narrow down the issue.

According to the link you posted above, the problem is that two different PHY chips have the PHY ID, so why would you need to hardcode the detection here?

Do you have access to the Ethernet MAC counters using 'ethtool -S'? That might tell you whether the problem is between the MAC and PHY, or at the PHY level. If the PHY maintain its own set of counters (fairly unlikely) can you try reading those and see if that works?

What about pinmux settings, Ethernet MAC settings etc... are they all correct? Is there any Ethernet MAC back-pressure mechanism that can be read to know whether the DMA engine is stuck transmitting?

Thanks

Hi Florian,

Bootloader is u-boot and seems it uses generic PHY setup, and so it works.

Linux at boot detects the phy and does a soft_reset. If the detection sets the driver as for KSZ8031, ethernet/link will not work, becouse micrel.c uses the incorrect config_init function, attempts to write to the bootstrap override register, that can't be written for KSZ8051, and so puts the micrel chip in a broken state.

The guy in this link (https://lkml.org/lkml/2013/9/18/259) seems are discussing a better solution.

I patched my linux as below, but this is a fast fixup for me:

diff -rupN drivers/net/phy/phy_device.c ../linux-3.17/drivers/net/phy/phy_device.c
@@ -310,19 +310,6 @@ static int get_phy_id(struct mii_bus *bu
 
        *phy_id |= (phy_reg & 0xffff);
 
-       /*
-        * Angelo - Barix
-        * Micrel produced chips marked KSZ8051 but with KSZ8031 id code
-        * in the silicon. After getting crazy to understand why in recent kernel
-        * the ethenret was not workeing, i find it out.
-        *
-        * From the schematic, we assume to use KSZ8051
-        * I hardcode the fix here for ipam390.
-        */
-#if CONFIG_MACH_BARIX_IPAM390
-       if (*phy_id == 0x00221556) *phy_id = 0x00221550;
-#endif
-
        return 0;
 }
 

Regards
angelo

You could register a PHY fixup in your board code that does exactly what you are you doing here, except that you would match 0x00221556, something along those lines:

static int micrel_ipam390_phy_fixup(struct phy_device *dev)

{
       if (dev->phy_id == 0x00221556)
		dev->phy_id = 0x00221550;

        return 0;
}

int __init micrel_ipam390_phy_fixup_register(void)

{
        return phy_register_fixup_for_id(PHY_ANY_ID, micrel_ipam390);
}