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 5E70FC63797 for ; Tue, 17 Jan 2023 14:02:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229755AbjAQOCL (ORCPT ); Tue, 17 Jan 2023 09:02:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230080AbjAQOCC (ORCPT ); Tue, 17 Jan 2023 09:02:02 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6B9538EAB; Tue, 17 Jan 2023 06:02:01 -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=iSq1n6fp+pgT1otyTi5I8F7lSDNIWrwaaMFHeTyn+qU=; b=1zA/3Nsyc+B66S/JfzShWC0dPM 6BYykR2G0bL45VrfcDV1kscfdJfvgFWxfLyN7eXcE6OYcNMUkF2z0DUugdVRQHEyuDAYo0mOLd4jI zBlm+H+W2e9gCJxoNge2ZPu1vavnmiUnpzSilCsal/AHGPEDNCrVqVhKc2ffZnphN0K0=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pHmX6-002KQU-Aa; Tue, 17 Jan 2023 15:01:48 +0100 Date: Tue, 17 Jan 2023 15:01:48 +0100 From: Andrew Lunn To: Pierluigi Passaro Cc: Pierluigi Passaro , 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 Matityahu , Nate Drude , Francesco Ferraro 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 On Mon, Jan 16, 2023 at 09:44:01AM +0000, Pierluigi Passaro wrote: > On Mon, Jan 16, 2023 at 1:11 AM Andrew Lunn wrote: > > > 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? > > > Interesting point of view: I was thinking about solving one of 4 problems ;) Lots of small incremental 'improvements' sometimes get you into a real mess because you loose track of the big picture. And i do think we are now in a mess. But i also think we have a better understanding of the problem space. We know there can be arbitrate number of resources which need to be enabled before you can enumerate the bus. We need a generic solution to that problem. And Linux is good at solving a problem once and reusing it other places. So the generic solution should be applicable to other bus types. We also have a well understood workaround, put the IDs in DT. So as far as i'm concerned we don't need to add more incremental 'improvements', we can wait for somebody to put in the effort to solve this properly with generic code. So i don't want to merge this change. Sorry. Andrew