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 89336C4361B for ; Wed, 16 Dec 2020 02:06: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 3D9EC230FC for ; Wed, 16 Dec 2020 02:06:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D9EC230FC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lunn.ch 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=keB1qhkP049gH3+adjNhV19kCeT5uoSjxGwGOr2Fndg=; b=LkX4M1XXdXzIYK55sK7cpqvBG 7f2tqDSSIjhY2OSORCxD+MIG2hSsAaLcAF+EWIp0n3Wei42ueztpmFGms9h4aPRYiasfjdvOofYTL SqN1FcphDPpfFoz1yaZSSoVInI39c/2dfk/+ttfT3F0UJoslLu5Jfzg94W98TwF+kq4k8v/x2owRT tr/TwnvZSNkMcs74bXHjx3kaL/wS1K4EXvLXYKFceqWbksPDaNzjRDvPMfS276jmSt7j+k2Z8RHUp HWPQbdGN77igq6rKlPBFnfGU86LHrbWiiqYn5Zby5QnL2HQe6ZkK5TPKy0lq2kAFp+cI3VGmjHW0+ YNMsGScnw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpMB5-0002Bc-H8; Wed, 16 Dec 2020 02:04:31 +0000 Received: from vps0.lunn.ch ([185.16.172.187]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpMB1-0002Az-Ez for linux-arm-kernel@lists.infradead.org; Wed, 16 Dec 2020 02:04:29 +0000 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kpMAV-00CD9O-GZ; Wed, 16 Dec 2020 03:03:55 +0100 Date: Wed, 16 Dec 2020 03:03:55 +0100 From: Andrew Lunn To: Serge Semin Subject: Re: [RFC] net: stmmac: Problem with adding the native GPIOs support Message-ID: <20201216020355.GA2893264@lunn.ch> References: <20201214092516.lmbezb6hrbda6hzo@mobilestation> <20201214153143.GB2841266@lunn.ch> <20201215082527.lqipjzastdlhzkqv@mobilestation> <20201215135837.GB2822543@lunn.ch> <20201215145253.sc6cmqetjktxn4xb@mobilestation> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201215145253.sc6cmqetjktxn4xb@mobilestation> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201215_210427_518923_60C8E91C X-CRM114-Status: UNSURE ( 9.54 ) X-CRM114-Notice: Please train this message. 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 , "David S. Miller" , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Serge Semin , Alexey Malahov , Jose Abreu , Pavel Parkhomenko , Maxime Coquelin , Giuseppe Cavallaro , Jakub Kicinski , Vyacheslav Mitrofanov , linux-stm32@st-md-mailman.stormreply.com, 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 > > 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. Is there pinmux support for these pins? Can you disconnect them from the MAC? Often pins can be connected to different internal IP blocks. Maybe you can flip the pin mux, perform the MAC reset, and then put the pinmux back to connect the pins to the MAC IP again? Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 92490C2BBCA for ; Wed, 16 Dec 2020 02:04:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 65C0A230FC for ; Wed, 16 Dec 2020 02:04:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725786AbgLPCEm (ORCPT ); Tue, 15 Dec 2020 21:04:42 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:56562 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725765AbgLPCEm (ORCPT ); Tue, 15 Dec 2020 21:04:42 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kpMAV-00CD9O-GZ; Wed, 16 Dec 2020 03:03:55 +0100 Date: Wed, 16 Dec 2020 03:03:55 +0100 From: Andrew Lunn To: Serge Semin 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 Subject: Re: [RFC] net: stmmac: Problem with adding the native GPIOs support Message-ID: <20201216020355.GA2893264@lunn.ch> References: <20201214092516.lmbezb6hrbda6hzo@mobilestation> <20201214153143.GB2841266@lunn.ch> <20201215082527.lqipjzastdlhzkqv@mobilestation> <20201215135837.GB2822543@lunn.ch> <20201215145253.sc6cmqetjktxn4xb@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201215145253.sc6cmqetjktxn4xb@mobilestation> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > 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. Is there pinmux support for these pins? Can you disconnect them from the MAC? Often pins can be connected to different internal IP blocks. Maybe you can flip the pin mux, perform the MAC reset, and then put the pinmux back to connect the pins to the MAC IP again? Andrew