From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Siddharth Vadapalli <s-vadapalli@ti.com>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, rogerq@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, srk@ti.com
Subject: Re: [PATCH net-next 2/2] net: ethernet: ti: am65-cpsw: Enable USXGMII mode for J784S4 CPSW9G
Date: Fri, 31 Mar 2023 08:57:17 +0100 [thread overview]
Message-ID: <ZCaSXQFZ/e/JIDEj@shell.armlinux.org.uk> (raw)
In-Reply-To: <20230331065110.604516-3-s-vadapalli@ti.com>
On Fri, Mar 31, 2023 at 12:21:10PM +0530, Siddharth Vadapalli wrote:
> TI's J784S4 SoC supports USXGMII mode. Add USXGMII mode to the
> extra_modes member of the J784S4 SoC data. Additionally, configure the
> MAC Control register for supporting USXGMII mode. Also, for USXGMII
> mode, include MAC_5000FD in the "mac_capabilities" member of struct
> "phylink_config".
I don't think TI "get" phylink at all...
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index 4b4d06199b45..ab33e6fe5b1a 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -1555,6 +1555,8 @@ static void am65_cpsw_nuss_mac_link_up(struct phylink_config *config, struct phy
> mac_control |= CPSW_SL_CTL_GIG;
> if (interface == PHY_INTERFACE_MODE_SGMII)
> mac_control |= CPSW_SL_CTL_EXT_EN;
> + if (interface == PHY_INTERFACE_MODE_USXGMII)
> + mac_control |= CPSW_SL_CTL_XGIG | CPSW_SL_CTL_XGMII_EN;
The configuration of the interface mode should *not* happen in
mac_link_up(), but should happen in e.g. mac_config().
> if (speed == SPEED_10 && phy_interface_mode_is_rgmii(interface))
> /* Can be used with in band mode only */
> mac_control |= CPSW_SL_CTL_EXT_EN;
> @@ -2175,6 +2177,7 @@ am65_cpsw_nuss_init_port_ndev(struct am65_cpsw_common *common, u32 port_idx)
>
> case PHY_INTERFACE_MODE_QSGMII:
> case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_USXGMII:
> if (common->pdata.extra_modes & BIT(port->slave.phy_if)) {
> __set_bit(port->slave.phy_if,
> port->slave.phylink_config.supported_interfaces);
> @@ -2182,6 +2185,9 @@ am65_cpsw_nuss_init_port_ndev(struct am65_cpsw_common *common, u32 port_idx)
> dev_err(dev, "selected phy-mode is not supported\n");
> return -EOPNOTSUPP;
> }
> + /* For USXGMII mode, enable MAC_5000FD */
> + if (port->slave.phy_if == PHY_INTERFACE_MODE_USXGMII)
> + port->slave.phylink_config.mac_capabilities |= MAC_5000FD;
MAC capabilities should not be conditional in the interface mode.
Phylink already knows the capabilities of each interface mode, and
will mask the mac_capabilities accordingly. Phylink wants to know
what speeds the MAC itself is capable of unbound by the interface
mode.
The interface modes that you already support (RGMII, RMII, QSGMII
and SGMII) do not support anything faster than 1G, so only
mac_capabilities up to and including 1G speeds will be permitted
for those interface modes internally by phylink.
So, making this conditional on USXGMII is just repeating logic that
is already present internally in phylink.
--
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:[~2023-03-31 7:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 6:51 [PATCH net-next 0/2] Add support for J784S4 CPSW9G Siddharth Vadapalli
2023-03-31 6:51 ` [PATCH net-next 1/2] net: ethernet: ti: am65-cpsw: Enable QSGMII " Siddharth Vadapalli
2023-03-31 6:51 ` [PATCH net-next 2/2] net: ethernet: ti: am65-cpsw: Enable USXGMII mode " Siddharth Vadapalli
2023-03-31 7:57 ` Russell King (Oracle) [this message]
2023-03-31 8:05 ` Siddharth Vadapalli
2023-03-31 8:24 ` Russell King (Oracle)
2023-03-31 9:25 ` Siddharth Vadapalli
2023-03-31 9:46 ` Russell King (Oracle)
2023-03-31 10:53 ` Siddharth Vadapalli
2023-03-31 11:12 ` Russell King (Oracle)
2023-03-31 13:46 ` Siddharth Vadapalli
2023-04-03 6:27 ` Siddharth Vadapalli
2023-04-03 8:32 ` Russell King (Oracle)
2023-04-03 8:41 ` Siddharth Vadapalli
2023-04-03 8:59 ` Russell King (Oracle)
2023-04-03 9:49 ` Siddharth Vadapalli
2023-04-03 9:57 ` Russell King (Oracle)
2023-04-03 10:00 ` Siddharth Vadapalli
2023-03-31 7:46 ` [PATCH net-next 0/2] Add support " Roger Quadros
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=ZCaSXQFZ/e/JIDEj@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rogerq@kernel.org \
--cc=s-vadapalli@ti.com \
--cc=srk@ti.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).