From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>
Subject: Re: [net-next PATCH] net: dsa: rtl8366rb: Switch to phylink
Date: Sun, 6 Sep 2020 09:24:54 +0100 [thread overview]
Message-ID: <20200906082454.GV1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <bd776604-0285-1dbc-1a97-51829d037a9a@gmail.com>
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 <linus.walleij@linaro.org>
>
> 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: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2020-09-06 8:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-05 22:48 [net-next PATCH] net: dsa: rtl8366rb: Switch to phylink Linus Walleij
2020-09-06 1:56 ` Florian Fainelli
2020-09-06 8:24 ` Russell King - ARM Linux admin [this message]
2020-09-06 17:51 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200906082454.GV1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).