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  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:   Wed, 9 Dec 2020 15:44:13 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     Fugang Duan <fugang.duan@....com>,
        "David S. Miller" <davem@...emloft.net>, kernel@...gutronix.de,
        netdev@...r.kernel.org
Subject: Re: [PATCH] net: ethernet: fec: Clear stale flag in IEVENT register
 before MII transfers

On Wed, Dec 09, 2020 at 11:29:59AM +0100, Uwe Kleine-König wrote:
> For some mii transfers the MII bit in the event register is already set
> before a read or write transfer is started. This breaks evaluating the
> transfer's result because it is checked too early.
> 
> Before MII transfers were switched from irq to polling this was not an
> issue because then it just resulted in an irq which completed the
> mdio_done completion. This completion however was reset before each
> transfer and so the event didn't hurt.
> 
> This fixes NFS booting on an i.MX25 based machine.
> 
> Fixes: f166f890c8f0 ("net: ethernet: fec: Replace interrupt driven MDIO with polled IO")
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
> ---
> Hello,
> 
> I tried (shortly) to find out what actually results in this bit being
> set because looking at f166f890c8f0 I'd say it cares enough. It's just
> proven by the real world that it's not good enough :-)

Hi Uwe

Do you have

ommit 1e6114f51f9d4090390fcec2f5d67d8cc8dc4bfc
Author: Greg Ungerer <gerg@...ux-m68k.org>
Date:   Wed Oct 28 15:22:32 2020 +1000

    net: fec: fix MDIO probing for some FEC hardware blocks
    
    Some (apparently older) versions of the FEC hardware block do not like
    the MMFR register being cleared to avoid generation of MII events at
    initialization time. The action of clearing this register results in no
    future MII events being generated at all on the problem block. This means
    the probing of the MDIO bus will find no PHYs.
    
    Create a quirk that can be checked at the FECs MII init time so that
    the right thing is done. The quirk is set as appropriate for the FEC
    hardware blocks that are known to need this.

in your tree?

   Andrew

Powered by blists - more mailing lists