netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 v2 1/3] net: ethernet: ti: am65-cpsw: Move mode specific config to mac_config()
Date: Mon, 3 Apr 2023 14:13:02 +0100	[thread overview]
Message-ID: <ZCrQ3lPjEmxXc9a2@shell.armlinux.org.uk> (raw)
In-Reply-To: <3a62f5cf-ebba-1603-50a0-7a873973534d@ti.com>

On Mon, Apr 03, 2023 at 06:31:52PM +0530, Siddharth Vadapalli wrote:
> 
> 
> On 03-04-2023 16:38, Russell King (Oracle) wrote:
> > On Mon, Apr 03, 2023 at 04:31:04PM +0530, Siddharth Vadapalli wrote:
> >> Move the interface mode specific configuration to the mac_config()
> >> callback am65_cpsw_nuss_mac_config().
> >>
> >> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> >> ---
> >>  drivers/net/ethernet/ti/am65-cpsw-nuss.c | 10 +++++++---
> >>  1 file changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> >> index d17757ecbf42..74e099828978 100644
> >> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> >> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> >> @@ -1504,12 +1504,17 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
> >>  							  phylink_config);
> >>  	struct am65_cpsw_port *port = container_of(slave, struct am65_cpsw_port, slave);
> >>  	struct am65_cpsw_common *common = port->common;
> >> +	u32 mac_control = 0;
> >>  
> >>  	if (common->pdata.extra_modes & BIT(state->interface)) {
> >> -		if (state->interface == PHY_INTERFACE_MODE_SGMII)
> >> +		if (state->interface == PHY_INTERFACE_MODE_SGMII) {
> >> +			mac_control |= CPSW_SL_CTL_EXT_EN;
> >>  			writel(ADVERTISE_SGMII,
> >>  			       port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
> >> +		}
> >>  
> >> +		if (mac_control)
> >> +			cpsw_sl_ctl_set(port->slave.mac_sl, mac_control);
> >>  		writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
> >>  		       port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
> >>  	}
> >> @@ -1553,8 +1558,7 @@ static void am65_cpsw_nuss_mac_link_up(struct phylink_config *config, struct phy
> >>  
> >>  	if (speed == SPEED_1000)
> >>  		mac_control |= CPSW_SL_CTL_GIG;
> >> -	if (interface == PHY_INTERFACE_MODE_SGMII)
> >> -		mac_control |= CPSW_SL_CTL_EXT_EN;
> >> +	/* TODO: Verify whether in-band is necessary for 10 Mbps RGMII */
> >>  	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;
> > 
> > I'm afraid I can see you haven't thought this patch through properly.
> > 
> > am65_cpsw_nuss_mac_link_down() will call
> > cpsw_sl_ctl_reset(port->slave.mac_sl); which has the effect of clearing
> > to zero the entire MAC control register. This will clear
> > CPSW_SL_CTL_EXT_EN that was set in am65_cpsw_nuss_mac_config() which is
> > not what you want to be doing.
> > 
> > Given that we have the 10Mbps issue with RGMII, I think what you want
> > to be doing is:
> > 
> > 1. Set CPSW_SL_CTL_EXT_EN in am65_cpsw_nuss_mac_config() if in SGMII
> >    mode, otherwise clear this bit.
> > 
> > 2. Clear the mac_control register in am65_cpsw_nuss_mac_link_down()
> >    if in RMGII mode, otherwise preserve the state of
> >    CPSW_SL_CTL_EXT_EN but clear all other bits.
> > 
> > 3. Set CPSW_SL_CTL_EXT_EN in am65_cpsw_nuss_mac_link_up() if in
> >    RGMII mode and 10Mbps.
> 
> I plan to implement it as follows:
> 1. Add a member "u32 mode_config" to "struct am65_cpsw_slave_data" in
> "am65-cpsw-nuss.h".
> 2. In am65_cpsw_nuss_mac_config(), store the value of mac_control in
> "port->slave.mode_config".
> 3. In am65_cpsw_nuss_mac_link_down(), after the reset via
> cpsw_sl_ctl_reset(), execute:
> cpsw_sl_ctl_set(port->slave.mac_sl, port->slave.mode_config) in order to
> restore the configuration performed in am65_cpsw_nuss_mac_config().
> 
> Please let me know in case of any suggestions to implement it in a
> better manner.

Do you think this complexity is really worth it?

Let's look at what's available:

cpsw_sl_ctl_set() - sets bits in the mac control register
cpsw_sl_ctl_clr() - clears bits in the mac control register
cpsw_sl_ctl_reset() - sets the mac control register to zero

So, in mac_config(), we can do:

	if (interface == SGMII)
		cpsw_sl_ctl_set(CPSW_SL_CTL_EXT_EN);
	else
		cpsw_sl_ctl_clr(CPSW_SL_CTL_EXT_EN);


in mac_link_down():

	u32 ctl;

	ctl = CPSW_SL_CTL_GMII_EN | CPSW_SL_CTL_GIG |
	      CPSW_SL_CTL_IFCTL_A | CPSW_SL_CTL_FULLDUPLEX |
	      CPSW_SL_CTL_RX_FLOW_EN | CPSW_SL_CTL_TX_FLOW_EN;
	if (phy_interface_mode_is_rgmii(interface))
		ctl |= CPSW_SL_CTL_EXT_EN;

	cpsw_sl_ctl_clr(ctl);

This ensures that we don't touch any bits in mac_link_down() which we
aren't modifying in the corresponding mac_link_up() implementation.

Q: do we really need to clear the mac control register on link down?
If we don't, then we can do better, but we need an additional helper
which allows read-modify-write of the mac control register using a
mask value and a value of bits to set. Then we can have mac_link_up()
setting and clearing the bits as necessary - but I would still keep
the clearing of CPSW_SL_CTL_EXT_EN for RGMII modes in mac_link_down()
for now.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2023-04-03 13:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03 11:01 [PATCH net-next v2 0/3] Add support for J784S4 CPSW9G Siddharth Vadapalli
2023-04-03 11:01 ` [PATCH net-next v2 1/3] net: ethernet: ti: am65-cpsw: Move mode specific config to mac_config() Siddharth Vadapalli
2023-04-03 11:08   ` Russell King (Oracle)
2023-04-03 11:17     ` Siddharth Vadapalli
2023-04-03 13:01     ` Siddharth Vadapalli
2023-04-03 13:13       ` Russell King (Oracle) [this message]
2023-04-03 13:50         ` Siddharth Vadapalli
2023-04-03 13:55           ` Russell King (Oracle)
2023-04-03 14:08             ` Siddharth Vadapalli
2023-04-03 11:01 ` [PATCH net-next v2 2/3] net: ethernet: ti: am65-cpsw: Enable QSGMII for J784S4 CPSW9G Siddharth Vadapalli
2023-04-03 11:01 ` [PATCH net-next v2 3/3] net: ethernet: ti: am65-cpsw: Enable USXGMII mode " Siddharth Vadapalli
2023-04-03 11:10   ` Russell King (Oracle)
2023-04-03 11:18     ` Siddharth Vadapalli

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=ZCrQ3lPjEmxXc9a2@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).