Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp2499879rwb; Sun, 15 Jan 2023 16:53:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXsHJNI+8S8/a5t1YeLwNfvRwl+oVcWOgTYhkJt2IE/zbnPsOkf/tGictDdHDPEmWO+rfEIM X-Received: by 2002:a05:6a20:7883:b0:ad:ee09:f433 with SMTP id d3-20020a056a20788300b000adee09f433mr18450898pzg.54.1673830435381; Sun, 15 Jan 2023 16:53:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673830435; cv=none; d=google.com; s=arc-20160816; b=NGtm637ffmczEXPODExJApkDWglqitrRfdlKaLdtdD+p5AszycQ7gi9GvmWXFfm1F4 woSBjCoDiUjimUOrpjNCMKGVS/fFeFz0nKsuWlQLkTMwZ8Qoc2CP+2KhFdp8Um0l797U swfsi881rC/3nErX5boWNljdScTCDR4Vw8+TNX+QVek76PPoRaFhrGEmyQ6Egk8QMIGP XffwOg2g2xpvC2LGEtwhTHXCRrcXhJH/imcGcd4jwgFHWbAHN6mjS7JNfm00Nn13gFae ETKvstT1Kt9hluldmA2n9fKVAWNw+avC3C9nv8qt2Zioa9HRL9U5TOegQxgvxdVd1rqD LVMQ== 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:dkim-signature; bh=lmkdEcOMa22/cNfyH6E4d0tkT2Pw8Zs3e69B0uPLP6g=; b=Dhy1OZQ4yiiu4LsPel3HMQ5WPs7dO6WmfedhJShibvcuy1nKTPkp6djMCgWNvpMAev xDdHXPYzjWK9Qkepd47iESJYFwIK/ZCSfFrDdLC8INKT5zzzVa6HXQqvMgZuq51U39lq yIm7AzJsb3A50EP/s9Ygw7X5kxkojy62DucjqDaTNyaIpskBaahrkfUPLzRdqgeQwSGj 7W//jLXRsobSotHgmqr3LpiXq1O92SKCCk2w7htrZf3TnhQxyvrfiuJWhTemR1T2N09S +rJhk9RFEO0iLA8pzcVkbUewts99PseCTkJvw+dboh5VxxrI4rrPKWeOxhB0OvDgiWbZ 1NuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="A8ci/1LD"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f187-20020a636ac4000000b004a8371132f9si28272562pgc.450.2023.01.15.16.53.49; Sun, 15 Jan 2023 16:53:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="A8ci/1LD"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231700AbjAPAL6 (ORCPT + 52 others); Sun, 15 Jan 2023 19:11:58 -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: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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