lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0d3d343d-83af-8657-2430-27e188f53b37@nxp.com>
Date:   Thu, 13 Apr 2017 05:45:08 +0000
From:   Andy Duan <fugang.duan@....com>
To:     Tim Harvey <tharvey@...eworks.com>,
        Fabio Estevam <festevam@...il.com>
CC:     Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>,
        "Fabio Estevam" <fabio.estevam@....com>,
        Lucas Stach <l.stach@...gutronix.de>,
        "Koen Vandeputte" <koen.vandeputte@...ntric.com>
Subject: Re: IMX6 FEC connection drops occasionally with 'MDIO read timeout'


On 2017年04月13日 00:54, Tim Harvey wrote:
> On Wed, Apr 12, 2017 at 9:26 AM, Fabio Estevam <festevam@...il.com> wrote:
>> Hi Tim,
>>
>> On Wed, Apr 12, 2017 at 1:15 PM, Tim Harvey <tharvey@...eworks.com> wrote:
>>> Andrew,
>>>
>>> Thanks for the reply. Your talking about suspend/resume power
>>> management right? The users reporting this were not using
>>> suspend/resume.
>>>
>>> With regards to clock are you talking about the IPG clock? Is there
>>> any other way that would get turned off other than fec suspend/resume?
>> Yes, through pm_runtime.
>>
>> Can you check if this quick debug change help?
>>
>> --- a/drivers/net/ethernet/freescale/fec_main.c
>> +++ b/drivers/net/ethernet/freescale/fec_main.c
>> @@ -3606,8 +3606,6 @@ static int __maybe_unused
>> fec_runtime_suspend(struct device *dev)
>>          struct net_device *ndev = dev_get_drvdata(dev);
>>          struct fec_enet_private *fep = netdev_priv(ndev);
>>
>> -       clk_disable_unprepare(fep->clk_ipg);
>> -
>>          return 0;
>>   }
>>
>>
>> If you don't see the problem with it, then it means we need to fix the
>> pm runtime support in this driver.
>>
>> Most likely pm runtime is turning off the clocks when it should not.
> Fabio,
>
> Ok, I understand now. We will disable the IPG clock disable and see if
> that makes a difference.
>
> Tim
Firstly, pls try the change suggested by Andrew.
I guess system enter to wait mode, and enet irq cannot wakeup system in 
real time that causes mii irq much latency. then mii bus access timeout.
If so, can you add below change to your dts file and try it ?

iomux pinctrl:
                 pinctrl_enet_irq: enetirqgrp {
                         fsl,pins = <
MX6QDL_PAD_GPIO_6__ENET_IRQ             0x000b1
                         >;
                 };


&fec {
         ...
         pinctrl-0 = <&pinctrl_enet &pinctrl_enet_irq>;
         interrupts-extended = <&gpio1 6 0x04>, <&gpc 0 119 0x04>;
         ...
};

&i2c3 {
         ...
         status = "disabled";
};


Regards,
Andy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ