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;
Date:   Tue, 17 Jan 2023 15:01:48 +0100
From:   Andrew Lunn <andrew@lunn.ch>
To:     Pierluigi Passaro <pierluigi.p@variscite.com>
Cc:     Pierluigi Passaro <pierluigi.passaro@gmail.com>,
        Lars-Peter Clausen <lars@metafoo.de>,
        "hkallweit1@gmail.com" <hkallweit1@gmail.com>,
        "linux@armlinux.org.uk" <linux@armlinux.org.uk>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "edumazet@google.com" <edumazet@google.com>,
        "kuba@kernel.org" <kuba@kernel.org>,
        "pabeni@redhat.com" <pabeni@redhat.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Eran Matityahu <eran.m@variscite.com>,
        Nate Drude <Nate.D@variscite.com>,
        Francesco Ferraro <francesco.f@variscite.com>
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal
Message-ID: <Y8aqTHyoFfzMILjl@lunn.ch>
References: <20230115161006.16431-1-pierluigi.p@variscite.com>
 <Y8QzI2VUY6//uBa/@lunn.ch>
 <f691f339-9e50-b968-01e1-1821a2f696e7@metafoo.de>
 <CAJ=UCjUo3t+D9S=J_yEhxCOo5OMj3d-UW6Z6HdwY+O+Q6JO0+A@mail.gmail.com>
 <Y8SWPwM7V8yj9s+v@lunn.ch>
 <AM6PR08MB437630CD49B50D66543EC3BDFFC19@AM6PR08MB4376.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AM6PR08MB437630CD49B50D66543EC3BDFFC19@AM6PR08MB4376.eurprd08.prod.outlook.com>
Precedence: bulk

On Mon, Jan 16, 2023 at 09:44:01AM +0000, Pierluigi Passaro wrote:
> On Mon, Jan 16, 2023 at 1:11 AM Andrew Lunn <andrew@lunn.ch> 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