netdev - Re: [PATCH] net: mdio: force deassert MDIO reset signal

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Jan 2023 15:20:44 +0000
From:   Pierluigi Passaro <pierluigi.p@...iscite.com>
To:     Andrew Lunn <andrew@...n.ch>
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 Tue, Jan 17, 2023 at 3:01 PM Andrew Lunn <andrew@...n.ch> wrote:
> 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
Hi Andrew,
I can understand your position and I apologize for the mess.
Thanks
Pier