From: Vladimir Oltean <olteanv@gmail.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mark parsed interface mode for legacy switch drivers
Date: Sun, 13 Aug 2023 13:50:31 +0300 [thread overview]
Message-ID: <20230813105031.zvagj264hiqvu3xb@skbuf> (raw)
In-Reply-To: <ZNd4AJlLLmszeOxg@shell.armlinux.org.uk> <ZNd4AJlLLmszeOxg@shell.armlinux.org.uk>
On Sat, Aug 12, 2023 at 01:16:00PM +0100, Russell King (Oracle) wrote:
> It's actually better - the vitesse driver uses .adjust_link, which
> means it's excluded from phylink for the DSA/CPU ports.
>
> So, I think for Vitesse, we just need to set INTERNAL and GMII
> for ports != CPU_PORT, speeds 10..1000Mbps at FD and HD, and also
> sym and asym pause.
Ok.
> That leaves the RTL836x driver, for which I've found:
>
> http://realtek.info/pdf/rtl8366_8369_datasheet_1-1.pdf
>
> and that indicates that the user ports use RSGMII which is SGMII with
> a clock in one direction. The only dts I can find is:
>
> arch/arm/boot/dts/gemini-dlink-dir-685.dts
>
> which doesn't specify phy-mode for these, so that'll be using the
> phylib default of GMII.
>
> Port 5 supports MII/GMII/RGMII by hardware strapping, which has three
> modes of operation:
>
> MII/GMII (mac mode): 1G (GMII) when linked at 1G, otherwise 100M (MII)
> RGMII: only 1G
> MII (phy mode): only 100M FD supported. Flow control by hardware
> strapping but is readable via a register, but omits to say where.
>
> There's also some suggestion that asym flow control is supported in 1G
> mode - but it doesn't say whether it's supported in 100M (and since
> IEEE 802.3 advertisements do not make this conditional on speed...
> yea, sounds like a slightly broken design to me.)
>
> So for realtek, I propose (completely untested):
>
> 8<====
> From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> Subject: [PATCH net-next] net: dsa: realtek: add phylink_get_caps
> implementation
>
> The user ports use RSGMII, but we don't have that, and DT doesn't
> specify a phy interface mode, so phylib defaults to GMII. These support
> 1G, 100M and 10M with flow control. It is unknown whether asymetric
> pause is supported at all speeds.
>
> The CPU port uses MII/GMII/RGMII/REVMII by hardware pin strapping,
> and support speeds specific to each, with full duplex only supported
> in some modes. Flow control may be supported again by hardware pin
> strapping, and theoretically is readable through a register but no
> information is given in the datasheet for that.
>
> So, we do a best efforts - and be lenient.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/dsa/realtek/rtl8366rb.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/net/dsa/realtek/rtl8366rb.c b/drivers/net/dsa/realtek/rtl8366rb.c
> index 25f88022b9e4..76b5c43e1430 100644
> --- a/drivers/net/dsa/realtek/rtl8366rb.c
> +++ b/drivers/net/dsa/realtek/rtl8366rb.c
> @@ -1049,6 +1049,32 @@ static enum dsa_tag_protocol rtl8366_get_tag_protocol(struct dsa_switch *ds,
> return DSA_TAG_PROTO_RTL4_A;
> }
>
> +static void rtl8366rb_phylink_get_caps(struct dsa_switch *ds, int port,
> + struct phylink_config *config)
> +{
> + unsigned long *interfaces = config->supported_interfaces;
> + struct realtek_priv *priv = ds->priv;
> +
> + if (port == priv->cpu_port) {
> + __set_bit(PHY_INTERFACE_MODE_MII, interfaces);
> + __set_bit(PHY_INTERFACE_MODE_GMII, interfaces);
> + /* Only supports 100M FD */
> + __set_bit(PHY_INTERFACE_MODE_REVMII, interfaces);
> + /* Only supports 1G FD */
> + __set_bit(PHY_INTERFACE_MODE_RGMII, interfaces);
> +
> + config->mac_capabilities = MAC_1000 | MAC_100 |
> + MAC_SYM_PAUSE;
Missing "return" statement here.
> + }
> +
> + /* RSGMII port, but we don't have that, and we don't
> + * specify in DT, so phylib uses the default of GMII
> + */
> + __set_bit(PHY_INTERFACE_MODE_GMII, interfaces);
> + config->mac_capabilities = MAC_1000 | MAC_100 | MAC_10 |
> + MAC_SYM_PAUSE | MAC_ASYM_PAUSE;
> +}
> +
> static void
> rtl8366rb_mac_link_up(struct dsa_switch *ds, int port, unsigned int mode,
> phy_interface_t interface, struct phy_device *phydev,
> @@ -1796,6 +1822,7 @@ static int rtl8366rb_detect(struct realtek_priv *priv)
> static const struct dsa_switch_ops rtl8366rb_switch_ops_smi = {
> .get_tag_protocol = rtl8366_get_tag_protocol,
> .setup = rtl8366rb_setup,
> + .phylink_get_caps = rtl8366rb_phylink_get_caps,
> .phylink_mac_link_up = rtl8366rb_mac_link_up,
> .phylink_mac_link_down = rtl8366rb_mac_link_down,
> .get_strings = rtl8366_get_strings,
> @@ -1821,6 +1848,7 @@ static const struct dsa_switch_ops rtl8366rb_switch_ops_mdio = {
> .setup = rtl8366rb_setup,
> .phy_read = rtl8366rb_dsa_phy_read,
> .phy_write = rtl8366rb_dsa_phy_write,
> + .phylink_get_caps = rtl8366rb_phylink_get_caps,
> .phylink_mac_link_up = rtl8366rb_mac_link_up,
> .phylink_mac_link_down = rtl8366rb_mac_link_down,
> .get_strings = rtl8366_get_strings,
> --
> 2.30.2
>
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2023-08-13 10:50 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 11:12 [PATCH net-next] net: dsa: mark parsed interface mode for legacy switch drivers Russell King (Oracle)
2023-08-08 12:06 ` Vladimir Oltean
2023-08-08 12:30 ` Russell King (Oracle)
2023-08-08 12:39 ` Vladimir Oltean
2023-08-08 12:57 ` Russell King (Oracle)
2023-08-08 13:52 ` Vladimir Oltean
2023-08-08 14:19 ` Russell King (Oracle)
2023-08-10 15:16 ` Vladimir Oltean
2023-08-12 12:16 ` Russell King (Oracle)
2023-08-13 10:50 ` Vladimir Oltean [this message]
2023-08-13 21:56 ` Linus Walleij
2023-08-13 22:17 ` Russell King (Oracle)
2023-08-15 6:41 ` Linus Walleij
2023-08-14 14:59 ` Vladimir Oltean
2023-08-14 15:12 ` Russell King (Oracle)
2023-08-14 15:46 ` Andrew Lunn
2023-08-14 16:27 ` Russell King (Oracle)
2023-08-14 17:05 ` Andrew Lunn
2023-08-14 22:03 ` Russell King (Oracle)
2023-08-14 23:33 ` Andrew Lunn
2023-08-15 10:13 ` Russell King (Oracle)
2023-08-17 18:01 ` Vladimir Oltean
2023-08-17 18:19 ` Vladimir Oltean
2023-08-17 18:27 ` Vladimir Oltean
2023-08-17 18:52 ` Andrew Lunn
2023-08-17 19:17 ` Vladimir Oltean
2023-08-18 11:11 ` Russell King (Oracle)
2023-08-18 11:40 ` Vladimir Oltean
2023-08-18 13:08 ` Linus Walleij
2023-08-18 13:29 ` Russell King (Oracle)
2023-08-18 16:06 ` Linus Walleij
2023-08-18 13:44 ` Vladimir Oltean
2023-08-18 13:10 ` Russell King (Oracle)
2023-08-18 14:21 ` Vladimir Oltean
2023-08-18 16:49 ` Vladimir Oltean
2023-08-14 22:21 ` Linus Walleij
2023-08-14 15:47 ` Vladimir Oltean
2023-08-08 16:35 ` Andrew Lunn
2023-08-08 12:39 ` Vladimir Oltean
2023-08-09 20:20 ` patchwork-bot+netdevbpf
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=20230813105031.zvagj264hiqvu3xb@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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