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,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 36AA9C2BBCA for ; Tue, 15 Dec 2020 14:54:18 +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 EF83822518 for ; Tue, 15 Dec 2020 14:54:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF83822518 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=N1Cvq1my8iGNXdMORyVCjqrAwo2AbM0C7zBo0yE4gOg=; b=MUGDOsyBZyh7yfKAu5cpguVfX nYZBNrjLNOoytvqKZbZeFRI7KnJE2skyegrZaHJZgEh8rlngp3q8yIBZ+u4TfDx4t2q+nUnMn+fhI bSuzzzTRAOB59uwpd2BBiK6qpCzhzb/snXhW5JcJtamypLAUn9AwhxwUYOUI6G/97CzPlutZ60MSw BSYnCiW+maxrBwPKAKZz0zaVColA8XtwovzT45QPsvCcPrRqwzivnjd/jUCs8ow8qYCd/GfFcSAPP cpiT3h3Xm7fRvXOksb4Zrby0f2OZrTZo6pvEgTOijxd1SZJxEKaXZKLfUYTRvIwXohbPLfoUulltE 4FzKt5apg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpBhH-0002PH-CG; Tue, 15 Dec 2020 14:53:03 +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 1kpBhF-0002OU-26 for linux-arm-kernel@lists.infradead.org; Tue, 15 Dec 2020 14:53:02 +0000 Date: Tue, 15 Dec 2020 17:52:53 +0300 From: Serge Semin To: Andrew Lunn Subject: Re: [RFC] net: stmmac: Problem with adding the native GPIOs support Message-ID: <20201215145253.sc6cmqetjktxn4xb@mobilestation> References: <20201214092516.lmbezb6hrbda6hzo@mobilestation> <20201214153143.GB2841266@lunn.ch> <20201215082527.lqipjzastdlhzkqv@mobilestation> <20201215135837.GB2822543@lunn.ch> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201215135837.GB2822543@lunn.ch> 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-20201215_095301_235676_230006FF X-CRM114-Status: GOOD ( 22.50 ) 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: Alexandre Torgue , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-kernel@vger.kernel.org, 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 Tue, Dec 15, 2020 at 02:58:37PM +0100, Andrew Lunn wrote: > > > > 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. > > > > Not sure I've fully understood your question. The GPIO sub-block of > > the MAC is getting reset together with the MAC. > > And my question is, is that under software control, or is the hardware > synthesised so that the GPIO controller is reset as part of the MAC > reset? Alas the SoC has already been synthesized and multiple devices have already been produced as I described in the initial message. So we can't change the way the MAC reset works. > > From what you are saying, it sounds like from software you cannot > independently control the GPIO controller reset? No. The hardware implements the default MAC reset behavior. So the GPIO controller gets reset synchronously with the MAC reset and that can't be changed. > > This is something i would be asking the hardware people. Look at the > VHDL, etc. Alas it's too late. I have to fix it in software somehow. As I see it the only possible ways to bypass the problem are either to re-init the PHY each time the reset happens or somehow to get rid of the MAC reset. That's why I have sent this RFC to ask the driver maintainers whether my suggestions are correct or of a better idea to work around the problem. -Sergey > > Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel