Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3803947pxb; Tue, 26 Jan 2021 05:21:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJy0Jyl8Tr6C+/j5rAcylsxWTN+japSc1AIeOADWaI15S223DyRWU8fJHSY3qdRKVvGMzHUs X-Received: by 2002:a17:906:a00e:: with SMTP id p14mr3410844ejy.532.1611667289597; Tue, 26 Jan 2021 05:21:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611667289; cv=none; d=google.com; s=arc-20160816; b=PbZ6K8lKu+mSyQ8evfi/2BEnCZgXfML8CW0+Vk5BySRzulm+WX77mIAXhgyg0uWZpx NtMhN6FrWJjtTmDdDhNXPHUy/GQ7tcmdj9sP93X6xTiGr0UOX58pXECj7Zopg2TccJzj G2ptepMOo4+AUbu19OEN4+z9WIiZVhAjnGe+UvNw8cJ8u2ToLsb9uClh682+ejCokPtl PT4zpC2yeSQHAUbb0Kc7kD2tOEPIFiN9a+utMgRBKKlPu3XIJbntESJ0JBnO7MRmr3Xi QAgriTCJ4gqtdUqbLttf0xuxcOUxnHjq+6JyOkjFciljDa0yJKCKEufPsWxGE3FPys6b WVgA== 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=084vfGtSo+pKC3W0j3Z0cjVXvpdpdIrLZBaFg6yBGOE=; b=xKoiWBlx3vTCtg+d9AZIXbEWKkzLf3iMxsIUHdeXDij8DTVYNCoESZuAgz3DdkorXC Zq6C0ObXcLuwYG5hUC5uNiHsP0HVr8Q0Yl/Q5m49OHWNnZ2l0hQF9vUSunV7EhtgSBvw r7jBiWJkbfzRp4PIXRGmTBZcJ+t4BrCkKlkEFy9DGj2V37/yPoC26idQBnoyJAsokrQS 7xZkhfqm9r31Ltkpy49LDzRa0HicJxaacLC6PrE/li8eQuffe01JKFG7WFxwtcTc1O8u nN3jstnrdx+7HxFb6ush3zwxFjkWCUwNKWU1dMuhlYp6dIlaXe6Ssz6Lgco6FcUWneW2 K5Ug== 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 v26si6997789ejx.316.2021.01.26.05.21.05; Tue, 26 Jan 2021 05:21:29 -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 S2404329AbhAZNS6 (ORCPT + 99 others); Tue, 26 Jan 2021 08:18:58 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:60076 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391830AbhAZNPc (ORCPT ); Tue, 26 Jan 2021 08:15:32 -0500 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1l4OB6-002hfZ-42; Tue, 26 Jan 2021 14:14:40 +0100 Date: Tue, 26 Jan 2021 14:14:40 +0100 From: Andrew Lunn To: Mike Looijmans Cc: netdev@vger.kernel.org, "David S. Miller" , Heiner Kallweit , Jakub Kicinski , Russell King , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210126073337.20393-1-mike.looijmans@topic.nl> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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