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  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:   Sun, 6 Sep 2020 09:24:54 +0100
From:   Russell King - ARM Linux admin <>
To:     Florian Fainelli <>
Cc:     Linus Walleij <>,
        Andrew Lunn <>,
        Vivien Didelot <>,, "David S . Miller" <>
Subject: Re: [net-next PATCH] net: dsa: rtl8366rb: Switch to phylink

On Sat, Sep 05, 2020 at 06:56:45PM -0700, Florian Fainelli wrote:
> +Russell,
> On 9/5/2020 3:48 PM, Linus Walleij wrote:
> > This switches the RTL8366RB over to using phylink callbacks
> > instead of .adjust_link(). This is a pretty template
> > switchover. All we adjust is the CPU port so that is why
> > the code only inspects this port.
> > 
> > We enhance by adding proper error messages, also disabling
> > the CPU port on the way down and moving dev_info() to
> > dev_dbg().
> > 
> > Signed-off-by: Linus Walleij <>
> The part of the former adjust_link, especially the part that forces the link
> to 1Gbit/sec, full duplex and no-autonegotiation probably belongs to a
> phylink_mac_config() implementation.
> Assuming that someone connects such a switch to a 10/100 Ethernet MAC and
> provides a fixed-link property in Device Tree, we should at least attempt to
> configure the CPU port interface based on those link settings, that is not
> happening today.

The CPU port has been the subject of much discussion; I thought the
conclusion was that phylink would not be used for the CPU port anymore.

The problem is, DSA has this idea that if there's nothing specified for
the CPU port, that port will be configured to the highest speed and
duplex mode possible, but that isn't compatible with phylink.  When
there's no SFP or fixed-link specifier, phylink assumes that a PHY will
be present, which is the expectation for network drivers.  Consequently,
phylink will be in "PHY" mode, but there is no PHY for a CPU link, so
phylink will never see the link come up. Moreover, phylink has no idea
what the maximum speed of the port is, so it has no parameters to call
the link_up() methods with.

I did toy with adding yet another callback for DSA that would happen
late which gave an opportunity for DSA to report that and reconfigure
phylink for a fixed-link, but Andrew's conclusion was not to use phylink
for CPU ports.

RMK's Patch system:
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists