netdev - Re: [PATCH] net: phy: marvell10g: allow PHY to probe without 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]

Date:   Thu, 6 Jun 2019 22:37:37 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        David Miller <davem@...emloft.net>, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH] net: phy: marvell10g: allow PHY to probe without firmware

On Thu, Jun 06, 2019 at 08:36:11PM +0200, Andrew Lunn wrote:
> 65;5402;1c> I don't like too much state changes outside control of the state machine,
> > like in phy_start / phy_stop / phy_error. I think it would be better
> > if a state change request is sent to the state machine, and the state
> > machine decides whether the requested transition is allowed.
> 
> Hi Heiner
> 
> I initially though that phy_error() would be a good way to do what
> Russell wants. But the locks get in the way. Maybe add an unlocked
> version which PHY drivers can use to indicate something fatal has
> happened?

I think a way better solution would be if the phy_start() and
phy_stop() calls were forwarded to the PHY driver so that it has
an opportunity to:

(1) refuse a phy_start() if the PHY is not able to operate correctly,
    which would mean ip link set dev X up fails.

(2) for fiber capable PHYs, pass on to the SFP layer whether the
    network device is up or not.

I seem to remember from the original report that the problem with
the PHY without firmware is that the link apparently comes up
(despite the MMDs reporting that they are in reset) but the
negotiation results are incorrect and no data is able to pass -
but don't quote me on that, and we've now lost a reporter to test
this.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up