Messages in this thread | | | Subject | Re: [PATCH net-next] phy: micrel: ksz8041nl: do not use power down mode | From | Christophe Leroy <> | Date | Mon, 18 Oct 2021 13:57:25 +0200 |
| |
+Sergei Shtylyov
Adding Sergei Shtylyov in the discussion, as he submitted the patch for the support of KSZ8041RNLI.
Le 18/10/2021 à 13:27, Francesco Dolcini a écrit : > 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@agner.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 >
| |