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=-14.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 24EBCC433DB for ; Tue, 9 Feb 2021 10:50:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B735E60202 for ; Tue, 9 Feb 2021 10:50:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230368AbhBIKts (ORCPT ); Tue, 9 Feb 2021 05:49:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232020AbhBIKiT (ORCPT ); Tue, 9 Feb 2021 05:38:19 -0500 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 82285C06178C; Tue, 9 Feb 2021 02:37:39 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id m1so2972558wml.2; Tue, 09 Feb 2021 02:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Fk8u5Dvk8nuGkAQ52LnN3av3QmJ7bHhCRbwcV5gS5rE=; b=M8aC9tUhXOtOUfgJ/3OZW5btQulO8EvksaSubxTsszpbjbrjQWEQ7L2kAZU2nOu73M z220G527nN7m7+X4HC5yroR8FQ07E1xlZSV9m6UcvivSUavHSstFeED4lVAk5INY3z0Y Vu1sDew583jcXI1GVAYBltF32YaHes3y2AxrCPJvNu37wLsQhD5NiAULcyDJjcyb8rAT bZVuB2eQh4ema9igNShP46ZGCXOnBoD4Hzq4vxioVhTZ0Z/BMrmXYH4k6fczG+EZ5esz n66mOI+URav1VJrYzYN3NoGZJ1+hbV43D2fXVi0K+mG1UuplqDGuXJI2DxMzYN6EsNZg /9Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Fk8u5Dvk8nuGkAQ52LnN3av3QmJ7bHhCRbwcV5gS5rE=; b=UvPxGiNl6HTZk0Dox456W/GyInh0WuG5n/SiDWrAxPu9c9Iex01yxJUSFulwcWadaA 54RWLJiLmbcZNnRasi9I6i1cgk1p6eCIgWqQo7793cQuMe0MQx0UpbNPdXkpXWclZqeF GlnWs1RY8dARfTz9JvzdzdIL8wSdkzTP5S8g9c4lJatnQory4cy8T/1fWlRsy6RYduvE dikw+LYxfEVYbkPdRs0Yfhe20pX+oxomBFpWkN9injg0VJ5fwPOwL2OjcufVIAQSUUNE UZpYfsTKPgOorq+qCIigLi0eZfH0/buPq6+5CCYeEp2ipGuE6r9rL55vrLwQypJviNro 4h3Q== X-Gm-Message-State: AOAM531hCyIkZKqRXMokghdng0c1a8uNuJZ4kBLdDA0W8hR55AsmnSAX EWtnq3LZ+EP++laonL1xPw2A7fio9YqAqQ== X-Google-Smtp-Source: ABdhPJzEHSP6byQu9bZegN9WsajgQQpAyaKW9/qEbDRoTwEvS1+9nrYC4mmXUvdec4ELnGPviqYzAg== X-Received: by 2002:a05:600c:20f:: with SMTP id 15mr2826077wmi.148.1612867057934; Tue, 09 Feb 2021 02:37:37 -0800 (PST) Received: from ?IPv6:2003:ea:8f1f:ad00:88d8:7242:b455:4959? (p200300ea8f1fad0088d87242b4554959.dip0.t-ipconnect.de. [2003:ea:8f1f:ad00:88d8:7242:b455:4959]) by smtp.googlemail.com with ESMTPSA id o13sm7681715wrs.45.2021.02.09.02.37.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Feb 2021 02:37:37 -0800 (PST) To: Serge Semin Cc: Serge Semin , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S. Miller" , Jakub Kicinski , Joao Pinto , Jose Abreu , Andrew Lunn , Russell King , Alexey Malahov , Pavel Parkhomenko , Vyacheslav Mitrofanov , Maxime Coquelin , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20210208140341.9271-1-Sergey.Semin@baikalelectronics.ru> <20210208140341.9271-2-Sergey.Semin@baikalelectronics.ru> <8300d9ca-b877-860f-a975-731d6d3a93a5@gmail.com> <20210209101528.3lf47ouaedfgq74n@mobilestation> From: Heiner Kallweit Subject: Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode Message-ID: Date: Tue, 9 Feb 2021 11:37:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210209101528.3lf47ouaedfgq74n@mobilestation> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09.02.2021 11:15, Serge Semin wrote: > On Mon, Feb 08, 2021 at 09:14:02PM +0100, Heiner Kallweit wrote: >> On 08.02.2021 15:03, 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. >>> >>> Signed-off-by: Serge Semin >>> --- >>> drivers/net/phy/realtek.c | 37 +++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> >>> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c >>> index 99ecd6c4c15a..cbb86c257aae 100644 >>> --- a/drivers/net/phy/realtek.c >>> +++ b/drivers/net/phy/realtek.c >>> @@ -559,6 +559,42 @@ static int rtl822x_write_mmd(struct phy_device *phydev, int devnum, u16 regnum, >>> return ret; >>> } >>> >>> +static int rtl8211e_write_mmd(struct phy_device *phydev, int devnum, u16 regnum, >>> + u16 val) >>> +{ >>> + int ret; >>> + >>> + /* Write to the MMD registers by using the standard control/data pair. >>> + * The only difference is that we need to perform a dummy read after >>> + * the PC1R.CLKSTOP_EN bit is set. It's required to workaround an issue >>> + * of a partial core freeze so LED2 stops blinking in EEE mode, PHY >>> + * stops detecting the link change and raising IRQs until any read from >>> + * its registers performed. That happens only if and right after the PHY >>> + * is enabled to stop RXC in LPI mode. >>> + */ >>> + ret = __phy_write(phydev, MII_MMD_CTRL, devnum); >>> + if (ret) >>> + return ret; >>> + >>> + ret = __phy_write(phydev, MII_MMD_DATA, regnum); >>> + if (ret) >>> + return ret; >>> + >>> + ret = __phy_write(phydev, MII_MMD_CTRL, devnum | MII_MMD_CTRL_NOINCR); >>> + if (ret) >>> + return ret; >>> + >> > >> Nice analysis. Alternatively to duplicating this code piece we could >> export mmd_phy_indirect(). But up to you. > > I also considered creating a generic method to access the MMD > registers of a generic PHY, something like phy_read()/phy_write(), but > for MMD (alas just exporting mmd_phy_indirect() would not be enough). > But as I see it such methods need to be created only after we get to > have at least several places with duplicating direct MMD-read/write > patterns. Doing that just for a single place seems redundant. Anyway it's > up to maintainers to decide whether they want to see a generic part > of the phy_read_mmd()/phy_write_mmd() methods being detached and > exported as something like genphy_{read,write}_mmd() methods. I can do > that in v2 if you ask me to. > Right, adding something like a genphy_{read,write}_mmd() doesn't make too much sense for now. What I meant is just exporting mmd_phy_indirect(). Then you don't have to open-code the first three steps of a mmd read/write. And it requires no additional code in phylib. But that's not at all a showstopper here. > -Sergey > >> >>> + ret = __phy_write(phydev, MII_MMD_DATA, val); >>> + if (ret) >>> + return ret; >>> + >>> + if (devnum == MDIO_MMD_PCS && regnum == MDIO_CTRL1 && >>> + val & MDIO_PCS_CTRL1_CLKSTOP_EN) >>> + ret = __phy_read(phydev, MII_MMD_DATA); >>> + >>> + return ret < 0 ? ret : 0; >>> +} >>> + >>> static int rtl822x_get_features(struct phy_device *phydev) >>> { >>> int val; >>> @@ -725,6 +761,7 @@ static struct phy_driver realtek_drvs[] = { >>> .resume = genphy_resume, >>> .read_page = rtl821x_read_page, >>> .write_page = rtl821x_write_page, >>> + .write_mmd = rtl8211e_write_mmd, >>> }, { >>> PHY_ID_MATCH_EXACT(0x001cc916), >>> .name = "RTL8211F Gigabit Ethernet", >>> >> 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=-12.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 E0879C433DB for ; Tue, 9 Feb 2021 10:38:51 +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 7601264E4B for ; Tue, 9 Feb 2021 10:38:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7601264E4B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:Date:Message-ID:Subject: From:References:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=6Y+l59/BYcDQ5QrxiwsYwmkmBb7NTwya0qnUt/kzgNg=; b=VeWl6ma50DR2BFJx7IzptB4Ua Svw9CAKho3242Wh5BTDua4aRFkzRzNkDpM2UOANw2I/+oewECh1qo5j+Tz/dwkqd5SiTEVNRqrfFy YuToBNPmlpaonjBvCDON56rP0l/WL9MGB6ldicZNkHWz/UDF9dsN8OWgws0phdEvyGkd3q4rz1OvC PdWIOedWXeFNZM+Ch0A6C6++dFQIBjVMnLuH4o6CKmTQkrbbG+AhJwLThRz3SvWiXAwdumD3oWhZS 2P4YH1i3rt1uDCUuezvF6T2K9SyLK7S2FS45VEdwP9YfobgTlUcoeFq9LIjfm6DKYg2UqWJiv/KDd /rUxg+zdA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9QOu-0000pS-Hq; Tue, 09 Feb 2021 10:37:45 +0000 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9QOp-0000n5-K8 for linux-arm-kernel@lists.infradead.org; Tue, 09 Feb 2021 10:37:41 +0000 Received: by mail-wm1-x330.google.com with SMTP id f16so2583081wmq.5 for ; Tue, 09 Feb 2021 02:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Fk8u5Dvk8nuGkAQ52LnN3av3QmJ7bHhCRbwcV5gS5rE=; b=M8aC9tUhXOtOUfgJ/3OZW5btQulO8EvksaSubxTsszpbjbrjQWEQ7L2kAZU2nOu73M z220G527nN7m7+X4HC5yroR8FQ07E1xlZSV9m6UcvivSUavHSstFeED4lVAk5INY3z0Y Vu1sDew583jcXI1GVAYBltF32YaHes3y2AxrCPJvNu37wLsQhD5NiAULcyDJjcyb8rAT bZVuB2eQh4ema9igNShP46ZGCXOnBoD4Hzq4vxioVhTZ0Z/BMrmXYH4k6fczG+EZ5esz n66mOI+URav1VJrYzYN3NoGZJ1+hbV43D2fXVi0K+mG1UuplqDGuXJI2DxMzYN6EsNZg /9Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Fk8u5Dvk8nuGkAQ52LnN3av3QmJ7bHhCRbwcV5gS5rE=; b=ozdozC5dEcS3MO0zarNj1rsr7s9mbvIvniMQAt5bwYKRrqjvFSijTBm1wwzxQo2ZtR 1k2Pqs8RK5oA8B0v+t5TtdSQJK+F7rU19MLM0EmWMkYTm8bYH5hK+T1L5QlB3synkuyh kbBa5RQ43+oLRHC/U68EuW6numjljVmWoEqUyA1XHIF3yQYUAHojMUtv8KgCfjvMi+TP ukdiJSQiRLLkCEs4pZFRbbmd0EXFqewgoJGVdXgMelTR6U9zPULiV7asjaE9UG0Ua6F3 +EWBSAjXNy5nU13YSVsa6tnsojCNdkR67AcT9gJmaTHvEyoNVs64MnWRxEJ/KBBrYPrf aNJQ== X-Gm-Message-State: AOAM531LEaAobbgD/AHlO2Ah6hs0wLd+S1xk47b0SvEt3xHWLXYpSIbF Qb3qEMduGkKo9RLnnJy+FdBJWoIs3nJ/1A== X-Google-Smtp-Source: ABdhPJzEHSP6byQu9bZegN9WsajgQQpAyaKW9/qEbDRoTwEvS1+9nrYC4mmXUvdec4ELnGPviqYzAg== X-Received: by 2002:a05:600c:20f:: with SMTP id 15mr2826077wmi.148.1612867057934; Tue, 09 Feb 2021 02:37:37 -0800 (PST) Received: from ?IPv6:2003:ea:8f1f:ad00:88d8:7242:b455:4959? (p200300ea8f1fad0088d87242b4554959.dip0.t-ipconnect.de. [2003:ea:8f1f:ad00:88d8:7242:b455:4959]) by smtp.googlemail.com with ESMTPSA id o13sm7681715wrs.45.2021.02.09.02.37.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Feb 2021 02:37:37 -0800 (PST) To: Serge Semin References: <20210208140341.9271-1-Sergey.Semin@baikalelectronics.ru> <20210208140341.9271-2-Sergey.Semin@baikalelectronics.ru> <8300d9ca-b877-860f-a975-731d6d3a93a5@gmail.com> <20210209101528.3lf47ouaedfgq74n@mobilestation> From: Heiner Kallweit Subject: Re: [PATCH 01/20] net: phy: realtek: Fix events detection failure in LPI mode Message-ID: Date: Tue, 9 Feb 2021 11:37:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210209101528.3lf47ouaedfgq74n@mobilestation> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210209_053739_915122_DC68E187 X-CRM114-Status: GOOD ( 26.98 ) 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 , Andrew Lunn , 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 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 09.02.2021 11:15, Serge Semin wrote: > On Mon, Feb 08, 2021 at 09:14:02PM +0100, Heiner Kallweit wrote: >> On 08.02.2021 15:03, 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. >>> >>> Signed-off-by: Serge Semin >>> --- >>> drivers/net/phy/realtek.c | 37 +++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> >>> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c >>> index 99ecd6c4c15a..cbb86c257aae 100644 >>> --- a/drivers/net/phy/realtek.c >>> +++ b/drivers/net/phy/realtek.c >>> @@ -559,6 +559,42 @@ static int rtl822x_write_mmd(struct phy_device *phydev, int devnum, u16 regnum, >>> return ret; >>> } >>> >>> +static int rtl8211e_write_mmd(struct phy_device *phydev, int devnum, u16 regnum, >>> + u16 val) >>> +{ >>> + int ret; >>> + >>> + /* Write to the MMD registers by using the standard control/data pair. >>> + * The only difference is that we need to perform a dummy read after >>> + * the PC1R.CLKSTOP_EN bit is set. It's required to workaround an issue >>> + * of a partial core freeze so LED2 stops blinking in EEE mode, PHY >>> + * stops detecting the link change and raising IRQs until any read from >>> + * its registers performed. That happens only if and right after the PHY >>> + * is enabled to stop RXC in LPI mode. >>> + */ >>> + ret = __phy_write(phydev, MII_MMD_CTRL, devnum); >>> + if (ret) >>> + return ret; >>> + >>> + ret = __phy_write(phydev, MII_MMD_DATA, regnum); >>> + if (ret) >>> + return ret; >>> + >>> + ret = __phy_write(phydev, MII_MMD_CTRL, devnum | MII_MMD_CTRL_NOINCR); >>> + if (ret) >>> + return ret; >>> + >> > >> Nice analysis. Alternatively to duplicating this code piece we could >> export mmd_phy_indirect(). But up to you. > > I also considered creating a generic method to access the MMD > registers of a generic PHY, something like phy_read()/phy_write(), but > for MMD (alas just exporting mmd_phy_indirect() would not be enough). > But as I see it such methods need to be created only after we get to > have at least several places with duplicating direct MMD-read/write > patterns. Doing that just for a single place seems redundant. Anyway it's > up to maintainers to decide whether they want to see a generic part > of the phy_read_mmd()/phy_write_mmd() methods being detached and > exported as something like genphy_{read,write}_mmd() methods. I can do > that in v2 if you ask me to. > Right, adding something like a genphy_{read,write}_mmd() doesn't make too much sense for now. What I meant is just exporting mmd_phy_indirect(). Then you don't have to open-code the first three steps of a mmd read/write. And it requires no additional code in phylib. But that's not at all a showstopper here. > -Sergey > >> >>> + ret = __phy_write(phydev, MII_MMD_DATA, val); >>> + if (ret) >>> + return ret; >>> + >>> + if (devnum == MDIO_MMD_PCS && regnum == MDIO_CTRL1 && >>> + val & MDIO_PCS_CTRL1_CLKSTOP_EN) >>> + ret = __phy_read(phydev, MII_MMD_DATA); >>> + >>> + return ret < 0 ? ret : 0; >>> +} >>> + >>> static int rtl822x_get_features(struct phy_device *phydev) >>> { >>> int val; >>> @@ -725,6 +761,7 @@ static struct phy_driver realtek_drvs[] = { >>> .resume = genphy_resume, >>> .read_page = rtl821x_read_page, >>> .write_page = rtl821x_write_page, >>> + .write_mmd = rtl8211e_write_mmd, >>> }, { >>> PHY_ID_MATCH_EXACT(0x001cc916), >>> .name = "RTL8211F Gigabit Ethernet", >>> >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel