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 3EAE4C2BB40 for ; Mon, 14 Dec 2020 15:32:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C6DE22B4B for ; Mon, 14 Dec 2020 15:32:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408141AbgLNPct (ORCPT ); Mon, 14 Dec 2020 10:32:49 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:53818 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731429AbgLNPck (ORCPT ); Mon, 14 Dec 2020 10:32:40 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kopp9-00Bw1U-Qv; Mon, 14 Dec 2020 16:31:43 +0100 Date: Mon, 14 Dec 2020 16:31:43 +0100 From: Andrew Lunn To: Serge Semin Cc: Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Serge Semin , Alexey Malahov , Vyacheslav Mitrofanov , Pavel Parkhomenko , Maxime Coquelin , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC] net: stmmac: Problem with adding the native GPIOs support Message-ID: <20201214153143.GB2841266@lunn.ch> References: <20201214092516.lmbezb6hrbda6hzo@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201214092516.lmbezb6hrbda6hzo@mobilestation> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 14, 2020 at 12:25:16PM +0300, Serge Semin wrote: > Hello folks, > > I've got a problem, which has been blowing by head up for more than three > weeks now, and I'm desperately need your help in that matter. See our > Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core > has been synthesized with two GPIOs: one as GPI and another as GPO. There > are multiple Baikal-T1-based devices have been created so far with active > GMAC interface usage and each of them has been designed like this: > > +------------------------+ > | Baikal-T1 +------------+ +------------+ > | SoC | DW GMAC | | Some PHY | > | | Rx-clk+<------+Rx-clk | > | | | | | > | | GPI+<------+#IRQ | > | | | | | > | | RGMII+<----->+RGMII | > | | MDIO+<----->+MDIO | > | | | | | > | | GPO+------>+#RST | > | | | | | > | | Tx-clk+------>+Tx-clk | > | | | | | > | +------------+ +------------+ > +------------------------+ > > Each of such devices has got en external RGMII-PHY attached configured via the > MDIO bus with Rx-clock supplied by the PHY and Tx-clock consumed by it. The > main peculiarity of such configuration is that the DW GMAC GPIOs have been used > to catch the PHY IRQs and to reset the PHY. Seeing the GPIOs support hasn't > been added to the STMMAC driver it's the very first setup for now, which has > been using them. It sounds like you need to cleanly implement a GPIO controller within the stmmac driver. But you probably want to make it conditional on a DT property. For example, look to see if there is the 'gpio-controller;' > Anyway the hardware setup depicted above doesn't seem > problematic at the first glance, but in fact it is. See, the DW *MAC driver > (STMMAC ethernet driver) is doing the MAC reset each time it performs the > device open or resume by means of the call-chain: > > stmmac_open()---+ > +->stmmac_hw_setup()->stmmac_init_dma_engine()->stmmac_reset(). > stmmac_resume()-+ > > Such reset causes the whole interface reset: MAC, DMA and, what is more > important, GPIOs as being exposed as part of the MAC registers. That > in our case automatically causes the external PHY reset, what neither > the STTMAC driver nor the PHY subsystem expect at all. Is the reset of the GPIO sub block under software control? When you have a GPIO controller implemented, you would want to disable this. Once you have a GPIO controller, you can make use of the standard PHY DT properties to allow the PHY driver to make use of the interrupt, and to control the reset of the PHY. Andrew