FEC driver about dual LAN port

[jrtigerlee]

My question is when there are two LAN ports(eth0 & eth1) which connected to internet, I attempted to plug in and plug out eth0 and then eth1 status showed up “disconnect” and reconnected again.

From my past experience, this is not hardware issue. Due to there is the same situation on iMX28EVK board(Freescale dev Kit).

Our design team also tested mainline kernel from 2.6.35-3 to 3.5.0(Linux) which were provided by Freesacle. All of them have same issue.

We have done a lot of tests and found out when eth0 “plug in and plug out” that MAC and UDMA of eth0 will be reset by driver and eth1 will be influenced by eth0 which is not make sense. Therefore, we tried to use memory tools to write CPU register value directly and realized that when we wrote MAC0 HW_ENET_MAC_ECR reset bit or disabled HW_ENET_MAC_RCR RMII_MODE bit that will cause MAC of eth1 a reset situation and then reconnect to eth1.

Due to the conduct of iMX28 driver, our design team think it is related to iMX28 SoC.

Does anyone found this issue or have a solution

Best Regards,  

[jamesbone]

Please check the following :

Re: L2-Switch ARP reply.  Please be aware that that there is a patch for FEC0  you can download it from the following link

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX287&nodeId=018rH3ZrDRA24A&fpsp=1&...

L2.6.35 10.12 FEC0 PATCH : Linux patch for i.MX28 SDK 2010.12 to fix the ethernet FEC0 conection problem on i.MX28 EVK

[jrtigerlee]

Hi jamesbone :

This patches already in fec.c source , so it's helpless

[jamesbone]

On IMX28 EVK board, PHY 0 and PHY 1 share the same gpio as their reset pin, in software the function is mx28evk_enet_gpio_init. So any call to pdata->init() in fec.c will reset both PHY at the same time. In order to avoid such problem, you have to use 2 individual gpio for the PHY reset.

[jrtigerlee]

Hi Jamesbone :

We already know that gpio reset pin limitation, so we test without call pdata->init() in fec_restart() also have two lan reset issue .

As mentioned above

We have done a lot of tests and found out when eth0 “plug in and plug out” that MAC and UDMA of eth0 will be reset by driver and eth1 will be influenced by eth0 which is not make sense. Therefore, we tried to use memory tools to write CPU register value directly and realized that when we wrote MAC0 HW_ENET_MAC_ECR reset bit or disabled HW_ENET_MAC_RCR RMII_MODE bit that will cause MAC of eth1 a reset situation and then reconnect to eth1.

[DuanFugang]

hi,

Pls use the attachments enet driver, i think you need to align the ethernet driver with our release.

For your issue:

1.  Plug in-out on eth0 will reset eth1 and vice versa: if you use the attachment driver, you don't meet it.

2. Write MAC0 register FEC_ECNTRL  (HW_ENET_MAC_ECR) reset bit, both eth0 and eth1 will also be reset and the communication will be interrupted: =>The reason is MAC0 and MAC1 share one MDIO bus, when you

reset the MAC0, MDIO bus cannot work, trigger MAC1 MDIO read timeout, and then software to reset MAC1. The reset MAC1 is caused by software action, not hardware itself.

Anyway, use the attachment driver instead of yours, the issue can be fixed.

[jrtigerlee]

Hi Fugang :

Thanks for your patch , but this patch i got from Freescale FAE Jacky yesterday .

And also patched to try still have the same issue , when driver call writel(1, fep->hwp + FEC_ECNTRL); ,

This patch not fixed this

[DuanFugang]

Can you try this patch as attached file, which fix one customer special switch issue.

And pls check your fec driver with attached files, to find the diff. Or use the attached driver instead of yours.

Thanks,

Andy

[jrtigerlee]

Hi Fugang :

Sorry for reply you later, my Freescale account can't logged in for two months from my chrome browser, but i fixed it through my Safari and can logged in again.

I already got this patches at January, and also fix my problem .

Thanks for your assistance