linux-kernel - Re: [PATCH net-next] phy: micrel: ksz8041nl: do not use power down mode

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, 18 Oct 2021 13:27:35 +0200
From:   Francesco Dolcini <francesco.dolcini@...adex.com>
To:     Christophe Leroy <christophe.leroy@...roup.eu>,
        f.fainelli@...il.com, Andrew Lunn <andrew@...n.ch>
Cc:     Francesco Dolcini <francesco.dolcini@...adex.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Stefan Agner <stefan@...er.ch>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] phy: micrel: ksz8041nl: do not use power down
 mode

On Mon, Oct 18, 2021 at 12:46:14PM +0200, Christophe Leroy wrote:
> 
> 
> Le 18/10/2021 à 12:18, Francesco Dolcini a écrit :
> > Hello Christophe,
> > 
> > On Mon, Oct 18, 2021 at 11:53:03AM +0200, Christophe Leroy wrote:
> > > 
> > > 
> > > Le 18/10/2021 à 11:42, Francesco Dolcini a écrit :
> > > > From: Stefan Agner <stefan@...er.ch>
> > > > 
> > > > Some Micrel KSZ8041NL PHY chips exhibit continous RX errors after using
> > > > the power down mode bit (0.11). If the PHY is taken out of power down
> > > > mode in a certain temperature range, the PHY enters a weird state which
> > > > leads to continously reporting RX errors. In that state, the MAC is not
> > > > able to receive or send any Ethernet frames and the activity LED is
> > > > constantly blinking. Since Linux is using the suspend callback when the
> > > > interface is taken down, ending up in that state can easily happen
> > > > during a normal startup.
> > > > 
> > > > Micrel confirmed the issue in errata DS80000700A [*], caused by abnormal
> > > > clock recovery when using power down mode. Even the latest revision (A4,
> > > > Revision ID 0x1513) seems to suffer that problem, and according to the
> > > > errata is not going to be fixed.
> > > > 
> > > > Remove the suspend/resume callback to avoid using the power down mode
> > > > completely.
> > > 
> > > As far as I can see in the ERRATA, KSZ8041 RNLI also has the bug.
> > > Shoudn't you also remove the suspend/resume on that one (which follows in
> > > ksphy_driver[])
> > 
> > Yes, I could, however this patch is coming out of a real issue we had with
> > KSZ8041NL with this specific phy id (and we have such a patch in our linux
> > branch since years).
> > 
> > On the other hand the entry for KSZ8041RNLI in the driver is somehow weird,
> > since the phy id according to the original commit does not even exists on
> > the datasheet. Would you be confident applying such errata for that phyid
> > without having a way of testing it?
> 
> 
> If your patch was to add the suspend/resume capability I would agree with
> you, but here we are talking about removing it, so what risk are we taking ?
yes, you are right.

> In addition, commit 4bd7b5127bd0 ("micrel: add support for KSZ8041RNLI")
> clearly tells that the only thing it did was to copy KSZ8041NL entry, so for
> me updating both entries would really make sense.
> 
> It looks odd to me that you refer in your commit log to an ERRATA that tells
> you that the bug also exists on the KSZ8041RNLI and you apply it only
> partly.

I think I was not clear enough, the entry I changed should already cover
KSZ8041RNLI, the phyid is supposed to be just the same according to the
datasheet. This entry for KSZ8041RNLI seems really special with this
un-documented phyid.
But I'm just speculating, I do not have access to these hardware.

Said that if there are no concern from anybody else, to be on the safe/cautious
side, I can just update also this entry.

Francesco