linux-kernel - Re: [PATCH] net: mdiobus: Prevent spike on MDIO bus 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]

Message-ID: <YBRuxtP3CTiATzDa@lunn.ch>
Date:   Fri, 29 Jan 2021 21:23:34 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Mike Looijmans <mike.looijmans@...ic.nl>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: mdiobus: Prevent spike on MDIO bus reset signal

On Thu, Jan 28, 2021 at 09:45:41AM +0100, Mike Looijmans wrote:
> Hi Andrew,
> 
> Response below...

Hi Mike

Everybody here knows that top posting is evil, we don't do it. We
expect the replay to be inline.

> > Hi Mike
> > 
> > Did you look at the per PHY reset? mdiobus_register_gpiod() gets the
> > GPIO with GPIOD_OUT_LOW. mdiobus_register_device() then immediately
> > sets it high.
> > 
> > So it looks like it suffers from the same problem.
> 
> Well, now that I have your attention...
> 
> The per PHY reset was more broken

It has history. It was designed to be used for PHYs which needed a
reset after the clock was changed. It assumed the PHY would probe,
which some do when held in reset.

But the GPIO is not the only problem. Some PHYs need a regulator
enabled, some need a clock enabled. The core has no idea what order to
do this in. It should be the PHY driver that does this, since it
should have knowledge of the PHY, and can do things in the correct
order. But if the PHY does not respond, it is not discovered, and so
the driver does not load. If that case, you can put the PHY ID into
the compatible string, and the core will load the correct driver and
probe it, allow it to turn on whatever it needs.

This has been discussed a few times and this is what we decided on.
Maybe we need to improve the documentation.

      Andrew