netdev - Re: [PATCH 1/4] net: macb: Fix regression breaking non-MDIO fixed-link PHYs

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]

Date:   Tue, 21 Aug 2018 10:26:43 +0200
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        kernel@...gutronix.de, netdev@...r.kernel.org, mdf@...nel.org,
        Brad Mouring <brad.mouring@...com>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH 1/4] net: macb: Fix regression breaking non-MDIO
 fixed-link PHYs

On 08/20/2018 09:06 PM, Andrew Lunn wrote:
> I would actually say, this is your real issue here. The warnings are
> annoying, but i don't think they are fatal. This -EBUSY is what is
> stopping the driver from loading, causing the real regression.

My real issue is that a specific commit broke the driver and I would like
to partially revert that offending commit.

> I'm guessing, but i think you will find the driver is loading once,
> but hits a EPROBE_DEFFER condition, after getting the gpio. It does
> not release the gpio correctly. Sometime later, it gets loaded again,
> but the gpio is now in use, so you get the -EBUSY.
> 
> So check the error paths, and make sure cleanup is being done correct.
> It could also be a phylib core bug...

I've traced it some more: While mdiobus_register fails to find a PHY,
creation of the "MDIO" bus is still successful and it returns successfully,
having claimed the reset GPIO (These functions should really be called
miibus_register...).

of_phy_fixed_link_register tries to claim the same GPIO and fails.

A fix for that would be something along the lines of da47b45 
("phy: add support for a reset-gpio specification"), which caused a regression
and was unfortunately later reverted.

But regardless, there shouldn't have been an of_mdiobus_register and a MDIO bus probe
before registering the fixed-link in the first place and my patch remedies that.

Reintroducing da47b45 would be out-of-scope for this patch series.

Cheers
Ahmad