From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FEE7C433E0 for ; Mon, 8 Feb 2021 19:14:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6674C64EA1 for ; Mon, 8 Feb 2021 19:14:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233461AbhBHTOt (ORCPT ); Mon, 8 Feb 2021 14:14:49 -0500 Received: from mail.baikalelectronics.com ([87.245.175.226]:58176 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234985AbhBHR4h (ORCPT ); Mon, 8 Feb 2021 12:56:37 -0500 Date: Mon, 8 Feb 2021 20:44:41 +0300 From: Serge Semin To: Andrew Lunn CC: Serge Semin , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S. Miller" , Jakub Kicinski , Joao Pinto , Jose Abreu , Heiner Kallweit , Russell King , Alexey Malahov , Pavel Parkhomenko , Vyacheslav Mitrofanov , Maxime Coquelin , , , , Subject: Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode Message-ID: <20210208174441.z4nnugkaadhmgnum@mobilestation> References: <20210208140341.9271-1-Sergey.Semin@baikalelectronics.ru> <20210208140341.9271-2-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 08, 2021 at 04:27:36PM +0100, Andrew Lunn wrote: > On Mon, Feb 08, 2021 at 05:03:22PM +0300, Serge Semin wrote: > > It has been noticed that RTL8211E PHY stops detecting and reporting events > > when EEE is successfully advertised and RXC stopping in LPI is enabled. > > The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable" > > register) is set. At the same time LED2 stops blinking as if EEE mode has > > been disabled. Notably the network traffic still flows through the PHY > > with no obvious problem. Anyway if any MDIO read procedure is performed > > after the "RXC stop in LPI" mode is enabled PHY gets to be unfrozen, LED2 > > starts blinking and PHY interrupts happens again. The problem has been > > noticed on RTL8211E PHY working together with DW GMAC 3.73a MAC and > > reporting its event via a dedicated IRQ signal. (Obviously the problem has > > been unnoticed in the polling mode, since it gets naturally fixed by the > > periodic MDIO read procedure from the PHY status register - BMSR.) > > > > In order to fix that problem we suggest to locally re-implement the MMD > > write method for RTL8211E PHY and perform a dummy read right after the > > PC1R register is accessed to enable the RXC stopping in LPI mode. > > Hi Serge > > Is this listed in an Errata from Realtek? 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. -Sergey > > Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23E39C433E0 for ; Mon, 8 Feb 2021 17:46:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BAD0764D9F for ; Mon, 8 Feb 2021 17:46:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BAD0764D9F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=baikalelectronics.ru Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Qd9U0mrR3QzVgsSHWZVRP0BtE47DFt7oign/DS4dA5s=; b=Q40mFHpnIUaOzRwCgWec7OcPx NLQv7UvShfmYDdZjmsPdBe9oN2HMfYi9owaAwruLkXU99CdVpIeniYxV6TCPgO5QG9ozWj+SIiHYV OnUQwDOTyKwPbXk2w/m3YyIE+1acn8EJIqeWOp9HAwN8DUUUNMzJu/dSALEWYCwN//XSA40dUy4v5 c4XBkZ7SMOwCMsOqO7QEyu5F2700zX8NTsKZffGJzD8tbZ/B8Pk7jP1g0JFik/mBW5WsyrbkFpkRe FTO0EgIt4AOUVDQQvOZ1S34YnQsych4r2g+LYDiueE1p53Kynxb18fnthVSyjAv+RUekmTrQqQoxs dYb/ZI73w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9Aaj-0004Ue-1J; Mon, 08 Feb 2021 17:44:53 +0000 Received: from mail.baikalelectronics.com ([87.245.175.226] helo=mail.baikalelectronics.ru) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9Aad-0004Qw-KS for linux-arm-kernel@lists.infradead.org; Mon, 08 Feb 2021 17:44:50 +0000 Date: Mon, 8 Feb 2021 20:44:41 +0300 From: Serge Semin To: Andrew Lunn Subject: Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode Message-ID: <20210208174441.z4nnugkaadhmgnum@mobilestation> References: <20210208140341.9271-1-Sergey.Semin@baikalelectronics.ru> <20210208140341.9271-2-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210208_124447_986731_BE131C01 X-CRM114-Status: GOOD ( 22.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jose Abreu , Joao Pinto , linux-kernel@vger.kernel.org, Alexandre Torgue , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, Russell King , Serge Semin , Alexey Malahov , Jose Abreu , Pavel Parkhomenko , Maxime Coquelin , Jakub Kicinski , Giuseppe Cavallaro , Vyacheslav Mitrofanov , "David S. Miller" , linux-arm-kernel@lists.infradead.org, Heiner Kallweit Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 08, 2021 at 04:27:36PM +0100, Andrew Lunn wrote: > On Mon, Feb 08, 2021 at 05:03:22PM +0300, Serge Semin wrote: > > It has been noticed that RTL8211E PHY stops detecting and reporting events > > when EEE is successfully advertised and RXC stopping in LPI is enabled. > > The freeze happens right after 3.0.10 bit (PC1R "Clock Stop Enable" > > register) is set. At the same time LED2 stops blinking as if EEE mode has > > been disabled. Notably the network traffic still flows through the PHY > > with no obvious problem. Anyway if any MDIO read procedure is performed > > after the "RXC stop in LPI" mode is enabled PHY gets to be unfrozen, LED2 > > starts blinking and PHY interrupts happens again. The problem has been > > noticed on RTL8211E PHY working together with DW GMAC 3.73a MAC and > > reporting its event via a dedicated IRQ signal. (Obviously the problem has > > been unnoticed in the polling mode, since it gets naturally fixed by the > > periodic MDIO read procedure from the PHY status register - BMSR.) > > > > In order to fix that problem we suggest to locally re-implement the MMD > > write method for RTL8211E PHY and perform a dummy read right after the > > PC1R register is accessed to enable the RXC stopping in LPI mode. > > Hi Serge > > Is this listed in an Errata from Realtek? 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. -Sergey > > Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel