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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 8 Feb 2021 20:03:36 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc:     Serge Semin <fancer.lancer@...il.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Jose Abreu <joabreu@...opsys.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Jose Abreu <Jose.Abreu@...opsys.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Vyacheslav Mitrofanov 
        <Vyacheslav.Mitrofanov@...kalelectronics.ru>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in
 LPI mode

> Hi Andrew,
> 
> I honestly tried to find any doc with a glimpse of errata for RTL8211E
> PHY, but with no luck. Official datasheet didn't have any info regarding
> possible hw bugs too. Thus I had no choice but to find a fix of the
> problem myself.
> 
> It took me some time to figure out why the events weren't reported after
> the very first link setup (turned out only a full HW reset clears the
> PC1R.10 bit state). I thought it could have been connected with some
> sleep/idle/power-safe mode. So I disabled the EEE initialization in the
> STMMAC driver. It worked. Then I left the EEE mode enabled, but called the
> phy_init_eee(phy, 0) method with "clk_stop_enable==0", so PHY wouldn't
> stop RXC in LPI mode. And it wonderfully worked. Then I started to dig in
> from another side. I left "RXC disable in LPI" mode enabled and tried to
> figure out what was going on with the PHY when it stopped reporting events
> just by reading from its CSR using phytool utility. It was curious to
> discover that any attempt to read from any PHY register caused the problem
> disappearance (LED2 started blinking, events got to be reported). Since I
> did nothing but a mere reading from a random even EEE-unrelated register I
> inferred that the problem must be in some HW/PHY bug. That's how I've got
> to the patch introduced here. If you have any better idea what could be a
> reason of that weird behavior I'd be glad to test it out on my device.

It is a reasonable explanation, and a read should not do any harm.

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew
   

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ