micrel: ksz8051 badly detected as ksz8031

micrel: ksz8051 badly detected as ksz8031

[Angelo Dureghello]

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

Fwd: micrel: ksz8051 badly detected as ksz8031

[Angelo Dureghello]

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

Fwd: micrel: ksz8051 badly detected as ksz8031

[Angelo Dureghello]

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

Fwd: micrel: ksz8051 badly detected as ksz8031

[Angelo Dureghello]

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

Re: Fwd: micrel: ksz8051 badly detected as ksz8031

[Florian Fainelli]

On 10/14/2014 10:24 AM, Angelo Dureghello wrote:
> 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.

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.

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

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?

> 
> 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.

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

> 
> 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
> 
> 
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: micrel: ksz8051 badly detected as ksz8031

[Angelo Dureghello]

Hi Florian,

> On 10/14/2014 10:24 AM, Angelo Dureghello wrote:
>> 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.
> 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.
>
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
--- drivers/net/phy/phy_device.c        2014-10-14 21:05:56.191117190 +0200
+++ ../linux-3.17/drivers/net/phy/phy_device.c  2014-10-05 
21:23:04.000000000 +0200
@@ -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

Re: Fwd: micrel: ksz8051 badly detected as ksz8031

[Florian Fainelli]

On 10/14/2014 12:33 PM, Angelo Dureghello wrote:
> Hi Florian,
> 
>> On 10/14/2014 10:24 AM, Angelo Dureghello wrote:
>>> 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.
>> 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.
>>
> 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:

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);
}

> 
> diff -rupN drivers/net/phy/phy_device.c
> ../linux-3.17/drivers/net/phy/phy_device.c
> --- drivers/net/phy/phy_device.c        2014-10-14 21:05:56.191117190 +0200
> +++ ../linux-3.17/drivers/net/phy/phy_device.c  2014-10-05
> 21:23:04.000000000 +0200
> @@ -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
>