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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67A30C3DA78 for ; Mon, 16 Jan 2023 00:12:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231652AbjAPAMA (ORCPT ); Sun, 15 Jan 2023 19:12:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41454 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231667AbjAPAL4 (ORCPT ); Sun, 15 Jan 2023 19:11:56 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41A5114489; Sun, 15 Jan 2023 16:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=lmkdEcOMa22/cNfyH6E4d0tkT2Pw8Zs3e69B0uPLP6g=; b=A8ci/1LDB9If56FC+FFbCnDmqe MszSvig0jtgkT0SVe37Xael1VlKS4KL0Y/lb0Ut87B040OVRgNmYFtdcYBsdTsZGj0v9cVfc2opIg 2MX4IkfvDtrROiLO8UA97w0Ni8sph38Rd6nkwpzihONEmZ2XREfyZKKAD1e3Hmnt7Zr0=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pHD6F-002AA7-Ri; Mon, 16 Jan 2023 01:11:43 +0100 Date: Mon, 16 Jan 2023 01:11:43 +0100 From: Andrew Lunn To: Pierluigi Passaro Cc: Lars-Peter Clausen , hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, eran.m@variscite.com, nate.d@variscite.com, francesco.f@variscite.com, pierluigi.p@variscite.com Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal Message-ID: References: <20230115161006.16431-1-pierluigi.p@variscite.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > IMHO, since the framework allows defining the reset GPIO, it does not sound > reasonable to manage it only after checking if the PHY can communicate: > if the reset is asserted, the PHY cannot communicate at all. > This patch just ensures that, if the reset GPIO is defined, it's not asserted > while checking the communication. The problem is, you are only solving 1/4 of the problem. What about the clock the PHY needs? And the regulator, and the linux reset controller? And what order to do enable these, and how long do you wait between each one? And why are you solving this purely for Ethernet PHYs when the same problem probably affects other sorts of devices which have reset GPIOs, regulators and clocks? It looks like MMC/SDIO devices have a similar problem. https://lwn.net/Articles/867740/ As i said, i've not been following this work. Has it got anywhere? Can ethernet PHYs use it? Andrew