* micrel: ksz8051 badly detected as ksz8031
@ 2014-10-12 12:55 Angelo Dureghello
2014-10-13 11:23 ` Fwd: " Angelo Dureghello
0 siblings, 1 reply; 7+ messages in thread
From: Angelo Dureghello @ 2014-10-12 12:55 UTC (permalink / raw)
To: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Fwd: micrel: ksz8051 badly detected as ksz8031
2014-10-12 12:55 micrel: ksz8051 badly detected as ksz8031 Angelo Dureghello
@ 2014-10-13 11:23 ` Angelo Dureghello
2014-10-13 19:34 ` Angelo Dureghello
0 siblings, 1 reply; 7+ messages in thread
From: Angelo Dureghello @ 2014-10-13 11:23 UTC (permalink / raw)
To: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Fwd: micrel: ksz8051 badly detected as ksz8031
2014-10-13 11:23 ` Fwd: " Angelo Dureghello
@ 2014-10-13 19:34 ` Angelo Dureghello
2014-10-14 17:24 ` Angelo Dureghello
0 siblings, 1 reply; 7+ messages in thread
From: Angelo Dureghello @ 2014-10-13 19:34 UTC (permalink / raw)
To: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Fwd: micrel: ksz8051 badly detected as ksz8031
2014-10-13 19:34 ` Angelo Dureghello
@ 2014-10-14 17:24 ` Angelo Dureghello
2014-10-14 19:09 ` Florian Fainelli
0 siblings, 1 reply; 7+ messages in thread
From: Angelo Dureghello @ 2014-10-14 17:24 UTC (permalink / raw)
To: netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fwd: micrel: ksz8051 badly detected as ksz8031
2014-10-14 17:24 ` Angelo Dureghello
@ 2014-10-14 19:09 ` Florian Fainelli
2014-10-14 19:33 ` Angelo Dureghello
0 siblings, 1 reply; 7+ messages in thread
From: Florian Fainelli @ 2014-10-14 19:09 UTC (permalink / raw)
To: Angelo Dureghello, netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fwd: micrel: ksz8051 badly detected as ksz8031
2014-10-14 19:09 ` Florian Fainelli
@ 2014-10-14 19:33 ` Angelo Dureghello
2014-10-14 20:56 ` Florian Fainelli
0 siblings, 1 reply; 7+ messages in thread
From: Angelo Dureghello @ 2014-10-14 19:33 UTC (permalink / raw)
To: Florian Fainelli, netdev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fwd: micrel: ksz8051 badly detected as ksz8031
2014-10-14 19:33 ` Angelo Dureghello
@ 2014-10-14 20:56 ` Florian Fainelli
0 siblings, 0 replies; 7+ messages in thread
From: Florian Fainelli @ 2014-10-14 20:56 UTC (permalink / raw)
To: Angelo Dureghello, netdev
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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-10-14 20:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-12 12:55 micrel: ksz8051 badly detected as ksz8031 Angelo Dureghello
2014-10-13 11:23 ` Fwd: " Angelo Dureghello
2014-10-13 19:34 ` Angelo Dureghello
2014-10-14 17:24 ` Angelo Dureghello
2014-10-14 19:09 ` Florian Fainelli
2014-10-14 19:33 ` Angelo Dureghello
2014-10-14 20:56 ` Florian Fainelli
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.