From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Parshuram Raju Thombare <pthombar@cadence.com>
Cc: "andrew@lunn.ch" <andrew@lunn.ch>,
"nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rafal Ciepiela <rafalc@cadence.com>,
Anil Joy Varughese <aniljoy@cadence.com>,
Piotr Sroka <piotrs@cadence.com>
Subject: Re: [PATCH v4 2/5] net: macb: add support for sgmii MAC-PHY interface
Date: Mon, 24 Jun 2019 10:35:33 +0100 [thread overview]
Message-ID: <20190624093533.4vhvjmqqrucq2ixf@shell.armlinux.org.uk> (raw)
In-Reply-To: <CO2PR07MB246931C79F736F39D0523D3BC1E00@CO2PR07MB2469.namprd07.prod.outlook.com>
On Mon, Jun 24, 2019 at 06:35:44AM +0000, Parshuram Raju Thombare wrote:
>
> >> + if (change_interface) {
> >> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
> >> + gem_writel(bp, NCFGR, ~GEM_BIT(SGMIIEN) &
> >> + ~GEM_BIT(PCSSEL) &
> >> + gem_readl(bp, NCFGR));
> >> + gem_writel(bp, NCR, ~GEM_BIT(TWO_PT_FIVE_GIG) &
> >> + gem_readl(bp, NCR));
> >> + gem_writel(bp, PCS_CTRL, gem_readl(bp, PCS_CTRL) |
> >> + GEM_BIT(PCS_CTRL_RST));
> >> + }
> >I still don't think this makes much sense, splitting the interface
> >configuration between here and below.
> Do you mean splitting mac_config in two *_configure functions ?
> This was done as per Andrew's suggestion to make code mode readable
> and easy to manage by splitting MAC configuration for different interfaces.
No, I mean here you disable SGMII if we're switching away from SGMII
mode.... (note, this means there is more to come for this sentence)
>
> >> + bp->phy_interface = state->interface;
> >> + }
> >> +
> >> if (!phylink_autoneg_inband(mode) &&
> >> (bp->speed != state->speed ||
> >> - bp->duplex != state->duplex)) {
> >> + bp->duplex != state->duplex ||
> >> + change_interface)) {
> >> u32 reg;
> >>
> >> reg = macb_readl(bp, NCFGR);
> >> reg &= ~(MACB_BIT(SPD) | MACB_BIT(FD));
> >> if (macb_is_gem(bp))
> >> reg &= ~GEM_BIT(GBE);
> >> + macb_or_gem_writel(bp, NCFGR, reg);
> >> +
> >> + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII)
> >> + gem_writel(bp, NCFGR, GEM_BIT(SGMIIEN) |
> >> + GEM_BIT(PCSSEL) |
> >> + gem_readl(bp, NCFGR));
> >This will only be executed when we are not using inband mode, which
> >basically means it's not possible to switch to SGMII in-band mode.
> SGMII is used in default PHY mode. And above code is to program MAC to
> select PCS and SGMII interface.
... and here you enable it for SGMII mode, but only for non-inband
modes.
For inband modes, you do not have any code that enables SGMII mode.
Since the only inband mode you support is SGMII, this is not very
good behaviour.
Why not:
if (change_interface) {
u32 ncfgr;
bp->phy_interface = state->interface;
// We don't support 2.5G modes
gem_writel(bp, NCR, ~GEM_BIT(TWO_PT_FIVE_GIG) &
gem_readl(bp, NCR));
ncfgr = gem_readl(bp, NCFGR);
if (state->interface == PHY_INTERFACE_MODE_SGMII) {
// Enable SGMII mode and PCS
gem_writel(bp, NCFGR, ncfgr | GEM_BIT(SGMIIEN) |
GEM_BIT(PCSSEL));
} else {
// Disable SGMII mode and PCS
gem_writel(bp, NCFGR, ncfgr & ~(GEM_BIT(SGMIIEN) |
GEM_BIT(PCSSEL)));
// Reset PCS
gem_writel(bp, PCS_CTRL, gem_readl(bp, PCS_CTRL) |
GEM_BIT(PCS_CTRL_RST));
}
}
if (!phylink_autoneg_inband(mode) &&
(bp->speed != state->speed || bp->duplex != state->duplex)) {
?
>
> >> +
> >> + if (!interface_supported) {
> >> + netdev_err(dev, "Phy mode %s not supported",
> >> + phy_modes(phy_mode));
> >> + goto err_out_free_netdev;
> >> + }
> >> +
> >> bp->phy_interface = phy_mode;
> >> + } else {
> >> + bp->phy_interface = phy_mode;
> >> + }
> >If bp->phy_interface is PHY_INTERFACE_MODE_SGMII here, and mac_config()
> >is called with state->interface = PHY_INTERFACE_MODE_SGMII, then
> >mac_config() won't configure the MAC for the interface type - is that
> >intentional?
>
> In mac_config configure MAC for non in-band mode, there is also check for speed, duplex
> changes. bp->speed and bp->duplex are initialized to SPEED_UNKNOWN and DUPLEX_UNKNOWN
> values so it is expected that for non in band mode state contains valid speed and duplex mode
> which are different from *_UNKNOWN values.
Sorry, this reply doesn't answer my question. I'm not asking about
bp->speed and bp->duplex. I'm asking:
1) why you are initialising bp->phy_interface here
2) you to consider the impact that has on the mac_config() implementation
you are proposing
because I think it's buggy.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2019-06-24 9:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-23 9:16 [PATCH v4 0/5] net: macb: cover letter Parshuram Thombare
2019-06-23 9:17 ` [PATCH v4 1/5] net: macb: add phylink support Parshuram Thombare
2019-06-23 10:08 ` Russell King - ARM Linux admin
2019-06-24 6:20 ` Parshuram Raju Thombare
2019-06-23 9:23 ` [PATCH v4 2/5] net: macb: add support for sgmii MAC-PHY interface Parshuram Thombare
2019-06-23 10:12 ` Russell King - ARM Linux admin
2019-06-24 6:35 ` Parshuram Raju Thombare
2019-06-24 9:35 ` Russell King - ARM Linux admin [this message]
2019-06-24 10:14 ` Parshuram Raju Thombare
2019-06-24 10:22 ` Russell King - ARM Linux admin
2019-06-24 10:32 ` Parshuram Raju Thombare
2019-06-23 9:23 ` [PATCH v4 3/5] net: macb: add support for c45 PHY Parshuram Thombare
2019-06-23 10:12 ` Russell King - ARM Linux admin
2019-06-24 6:47 ` Parshuram Raju Thombare
2019-06-24 9:42 ` Russell King - ARM Linux admin
2019-06-24 10:19 ` Parshuram Raju Thombare
2019-06-23 9:23 ` [PATCH v4 4/5] net: macb: add support for high speed interface Parshuram Thombare
2019-06-23 15:09 ` Andrew Lunn
2019-06-24 6:52 ` Parshuram Raju Thombare
2019-06-24 13:13 ` Andrew Lunn
2019-06-25 8:26 ` Parshuram Raju Thombare
2019-06-25 10:51 ` Russell King - ARM Linux admin
2019-06-25 11:23 ` Parshuram Raju Thombare
2019-06-23 9:24 ` [PATCH v4 5/5] net: macb: parameter added to cadence ethernet controller DT binding Parshuram Thombare
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=20190624093533.4vhvjmqqrucq2ixf@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=aniljoy@cadence.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=piotrs@cadence.com \
--cc=pthombar@cadence.com \
--cc=rafalc@cadence.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
Powered by JetHome