netdev - Re: [RFT/RFC net-next 0/2] net: dsa: Plug in PHYLINK support

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:   Fri, 15 Dec 2017 12:08:31 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, sean.wang@...iatek.com, john@...ozen.org,
        kernel@...gutronix.de, privat@...l-hjelmeland.no,
        Woojung.Huh@...rochip.com, vivien.didelot@...oirfairelinux.com,
        andrew@...n.ch
Subject: Re: [RFT/RFC net-next 0/2] net: dsa: Plug in PHYLINK support

On Thu, Dec 14, 2017 at 04:28:48PM -0800, Florian Fainelli wrote:
> Hi all,
> 
> This patch series replaces the existing PHYLIB integration with PHYLINK which
> is a superior solution since we need to support a collection of fixed links,
> integrated PHYs, SFP, non-pluggable SFPs etc.
> 
> I am expecting quite a lot of breakage, for a number of reasons:
> 
> - PHYLINK does not create a PHY device for fixed links (MLO_AN_FIXED), which
>   means that user-facing port (not DSA, not CPU) need to be explicitly handled
>   with phylink_mac_ops now
> 
> - only been able to test this on a limited number of platforms, and not the
>   ZII devel B/C boards yet
> 
> Please test and report!

The good news is that it almost works on the ZII Rev C with the SFF
modules, but there's a few issues that need solving:

1. s/WARN_ON(!lockdep_rtnl_is_held())/ASSERT_RTNL()/ in phylink.c -
   probably wouldn't have been noticed if it wasn't for the lockdep
   splat with DSA's interrupt handling during boot that's been there
   since -rc1.  (Andrew mentioned that it's known, so I haven't
   reported that.)

2. ports without a phy but with sfp cause the "no phy at" and
   "failed to connect to port" message - I think we need a way for
   DSA to know whether it should be attempting to attach a PHY.

3. We need mv88e6xxx to implement at least phylink_mac_link_state()
   so that SFPs report sane ethtool information.  It also needs to
   implement phylink_mac_config() so that the link can be appropriately
   configured to the module's capabilities, and phylink_validate() to
   do the jiggery for choosing between 1000base-X vs 2500base-X mode
   if the DSA switches can't automatically select the appropriate one.

With a few hacks for the above, I can get TX_DISABLE on the SFF2 module
to follow the interface up/down status, but as I say more work is needed
so that mv88e6xxx works with the phylink callbacks for the SFF modules
to be properly supported.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up