Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp614940pxb; Wed, 27 Jan 2021 16:51:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJy8VARgKnq5nbrHzwzC4FYsWRk37zoa+cPNglr6FtRrlDWCGNh6ohx/zgZn2vmiFRYWtJlA X-Received: by 2002:a17:906:1288:: with SMTP id k8mr8639121ejb.206.1611795101904; Wed, 27 Jan 2021 16:51:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611795101; cv=none; d=google.com; s=arc-20160816; b=ZvdtFyLCTcuGDio6h4MeSzD5mynS0yBghVJeZsefwzIjEt7WUx1axyLwKa8WfZ+KXu NaPdAy///L2tNs3X4NzyHbDLUXTogeEY1Ucztf2vYsORrLLzXK0DcHAjOmLO9ZyBk3II WM63tBcLS1WTwSQl4nRXb6DbIA4oUl6PLzyI8iPGPSmuzgUBPqbve/KwqdUujYx4AaDo lBoBTY2heNMksBleiT19tk0t4f5Fuv5WZrykBo+FKYBNqADcCnGTAEf33pHi90rXXuI/ Wnwge4rVF68Y/Lwx/1b108OfyKwvNckeFINrp50Fyeeww7XZ3kFwubuS36Sb1D+ROKmI +3Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=wyBBCLDSGfKoc8wbcA9LiaoEgTmle65SBa08tZsw7l8=; b=CavrdawPp9BsId6ExjZts0VpTka7l3gToGc59VFajW0jXdBJRvH2zoLgE8Beuzu6dg gzM2emZPYK0/iBun2jdH3ZFgiuyjJ9l+aJeZ26oWThnzEi2CivMUU6qjFupvd7+siGx0 89gr9Y5VLoVZZFx1Lhx/uu2jJgyJhzEKLBJuiryj3xoi6n+yPBvmeWKoJHh8fS/zPOiY lPAuXZgQL/5ebFQWbR6krXoIllcVLfmDtqXFtztK363n5QU8OaJ1owrMQ8MwZvTK+22h FCT0HHzU1qgi110tKs+wdH4g9O13mMXTU0L7xnkf3ap2vdlOKYM240TpASI1A5E5O+Yr V5gA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s25si1605551ejz.751.2021.01.27.16.51.17; Wed, 27 Jan 2021 16:51:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231160AbhA1ABw (ORCPT + 99 others); Wed, 27 Jan 2021 19:01:52 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:35188 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229716AbhA1ABs (ORCPT ); Wed, 27 Jan 2021 19:01:48 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1l4uk5-002wYP-7G; Thu, 28 Jan 2021 01:00:57 +0100 Date: Thu, 28 Jan 2021 01:00:57 +0100 From: Andrew Lunn To: Russell King - ARM Linux admin Cc: Mike Looijmans , netdev@vger.kernel.org, "David S. Miller" , Heiner Kallweit , Jakub Kicinski , linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: mdiobus: Prevent spike on MDIO bus reset signal Message-ID: References: <20210126073337.20393-1-mike.looijmans@topic.nl> <20210126134937.GI1551@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210126134937.GI1551@shell.armlinux.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2021 at 01:49:38PM +0000, Russell King - ARM Linux admin wrote: > On Tue, Jan 26, 2021 at 02:14:40PM +0100, Andrew Lunn wrote: > > On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijmans wrote: > > > The mdio_bus reset code first de-asserted the reset by allocating with > > > GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if > > > the reset signal defaulted to asserted, there'd be a short "spike" > > > before the reset. > > > > > > Instead, directly assert the reset signal using GPIOD_OUT_HIGH, this > > > removes the spike and also removes a line of code since the signal > > > is already high. > > > > Hi Mike > > > > This however appears to remove the reset pulse, if the reset line was > > already low to start with. Notice you left > > > > fsleep(bus->reset_delay_us); > > > > without any action before it? What are we now waiting for? Most data > > sheets talk of a reset pulse. Take the reset line high, wait for some > > time, take the reset low, wait for some time, and then start talking > > to the PHY. I think with this patch, we have lost the guarantee of a > > low to high transition. > > > > Is this spike, followed by a pulse actually causing you problems? If > > so, i would actually suggest adding another delay, to stretch the > > spike. We have no control over the initial state of the reset line, it > > is how the bootloader left it, we have to handle both states. > > Andrew, I don't get what you're saying. > > Here is what happens depending on the pre-existing state of the > reset signal: > > Reset (previously asserted): ~~~|_|~~~~|_______ > Reset (previously deasserted): _____|~~~~|_______ > ^ ^ ^ > A B C > > At point A, the low going transition is because the reset line is > requested using GPIOD_OUT_LOW. If the line is successfully requested, > the first thing we do is set it high _without_ any delay. This is > point B. So, a glitch occurs between A and B. > > We then fsleep() and finally set the GPIO low at point C. > > Requesting the line using GPIOD_OUT_HIGH eliminates the A and B > transitions. Instead we get: > > Reset (previously asserted) : ~~~~~~~~~~|______ > Reset (previously deasserted): ____|~~~~~|______ > ^ ^ > A C > > Where A and C are the points described above in the code. Point B > has been eliminated. > > Therefore, to me the patch looks entirely reasonable and correct. I wonder if there are any PHYs which actually need a pulse? Would it be better to have: Reset (previously asserted): ~~~|____|~~~~|_______ Reset (previously deasserted): ________|~~~~|_______ ^ ^ ^ ^ A B C D Point D is where we actually start talking to the PHY. C-D is reset-post-delay-us, and defaults to 0, but can be set via DT. B-C is reset-delay-us, and defaults to 10us, but can be set via DT. Currently A-B is '0', so we get the glitch. But should we make A-B the same as B-C, so we get a real pulse? Andrew