netdev - Re: [PATCH] net: phy: marvell10g: report if the PHY fails to boot firmware

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: <20190528161139.GQ18059@lunn.ch>
Date:   Tue, 28 May 2019 18:11:39 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] net: phy: marvell10g: report if the PHY fails to boot
 firmware

> One question: are we happy with failing the probe like this, or would it
> be better to allow the probe to suceed?
> 
> As has been pointed out in the C45 MII access patch, we need the PHY
> to bind to the network driver for the MII bus to be accessible to
> userspace, so if we're going to have userspace tools to upload the
> firmware, rather than using u-boot, we need the PHY to be present and
> bound to the network interface.

Hi Russell

It is an interesting question. Failing the probe is the simple
solution. If we don't fail the probe, we then need to allow the
attach, but fail all normal operations, with a noisy kernel log.  That
probably means adding a new state to the state machine, PHY_BROKEN.
Enter that state if phy_start_aneg() returns an error?

      Andrew