lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8aqTHyoFfzMILjl@lunn.ch>
Date:   Tue, 17 Jan 2023 15:01:48 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Pierluigi Passaro <pierluigi.p@...iscite.com>
Cc:     Pierluigi Passaro <pierluigi.passaro@...il.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Eran Matityahu <eran.m@...iscite.com>,
        Nate Drude <Nate.D@...iscite.com>,
        Francesco Ferraro <francesco.f@...iscite.com>
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal

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@...n.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ