netdev - [PATCH net-next 0/5] mvpp2 phylink fixes

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-next>] [day] [month] [year] [list]

Message-ID: <20190208153432.igh26ubphiljsswa@shell.armlinux.org.uk>
Date:   Fri, 8 Feb 2019 15:34:32 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Antoine Tenart <antoine.tenart@...tlin.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc:     Baruch Siach <baruch@...s.co.il>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Sven Auhagen <sven.auhagen@...eatech.de>
Subject: [PATCH net-next 0/5] mvpp2 phylink fixes

Hi,

Having spent a while debugging issues with Sven Auhagen, it appears
that the mvpp2 network driver's phylink support isn't quite correct.

This series fixes that up, but, despite being tested locally, by
Sven, and by Antoine, I would prefer it to be applied to net-next
so that there is time for more people to test before it hits -rc or
stable backports.

The symptoms were that although PHYs would come up, the GMAC never
reported that the link was up, or in some cases it did report link
up but packets would not flow.  Various approaches were tried to
work around that, such as switching to in-band negotiation from
PHY mode, but ultimately the problem was in the way mvpp2 was being
programmed.

This series addresses that by, essentially, making mvpp2 follow the
same implementation pattern as mvneta: we configure the GMAC in three
stages:

1) the PHY interface mode
2) the negotiation advert
3) the negotiation style

Another issue is that mvpp2 was always taking the link down each time
its mac_config method was called: this is disruptive when the link is
already up, and we're just updating settings such as flow control.
There are some circumstances where we make the call despite there
being no changes (eg, when phylink is polling a GPIO or using a custom
link state function.)

This series depends on two previous patches already sent for net-next:
  net: marvell: mvpp2: fix lack of link interrupts
  net: marvell: mvpp2: use phy_interface_mode_is_8023z() helper

There is one last patch which deals with link status interrupts, which
I'll send separately because I think there's other considerations, but
that should not hold up this series of patches.

 drivers/net/ethernet/marvell/mvpp2/mvpp2.h      |   4 +-
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 175 ++++++++++++++----------
 2 files changed, 108 insertions(+), 71 deletions(-)

-- 
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