diff mbox series

[net-next,3/3] net: dpaa2-mac: add backplane link mode support

Message ID E1l1t3B-0005Vn-2N@rmk-PC.armlinux.org.uk (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series dpaa2: add 1000base-X support | expand

Checks

Context Check Description
netdev/cover_letter success Link
netdev/fixes_present success Link
netdev/patch_count success Link
netdev/tree_selection success Clearly marked for net-next
netdev/subject_prefix success Link
netdev/cc_maintainers success CCed 5 of 5 maintainers
netdev/source_inline success Was 0 now: 0
netdev/verify_signedoff success Link
netdev/module_param success Was 0 now: 0
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/verify_fixes success Link
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 11 lines checked
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/header_inline success Link
netdev/stable success Stable not CCed

Commit Message

Russell King (Oracle) Jan. 19, 2021, 3:36 p.m. UTC
Add support for backplane link mode, which is, according to discussions
with NXP earlier in the year, is a mode where the OS (Linux) is able to
manage the PCS and Serdes itself.

This commit prepares the ground work for allowing 1G fiber connections
to be used with DPAA2 on the SolidRun CEX7 platforms.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
 drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Ioana Ciornei Jan. 20, 2021, 10:19 p.m. UTC | #1
On Tue, Jan 19, 2021 at 03:36:09PM +0000, Russell King wrote:
> Add support for backplane link mode, which is, according to discussions
> with NXP earlier in the year, is a mode where the OS (Linux) is able to
> manage the PCS and Serdes itself.

Indeed, DPMACs in TYPE_BACKPLANE can have both their PCS and SerDes managed
by Linux (since the firmware is not touching these).
That being said, DPMACs in TYPE_PHY (the type that is already supported
in dpaa2-mac) can also have their PCS managed by Linux (no interraction
from the firmware's part with the PCS, just the SerDes).

All in all, this patch is not needed for this particular usecase, where
the switch between 1000Base-X and SGMII is done by just a minor
reconfiguration in the PCS, without the need for SerDes changes.

Also, with just the changes from this patch, a interface connected to a
DPMAC in TYPE_BACKPLANE is not even creating a phylink instance. It's
mainly because of this check from dpaa2-eth:

	if (dpaa2_eth_is_type_phy(priv)) {
		err = dpaa2_mac_connect(mac);


I would suggest just dropping this patch.

Ioana

> 
> This commit prepares the ground work for allowing 1G fiber connections
> to be used with DPAA2 on the SolidRun CEX7 platforms.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
>  drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
> index 3ddfb40eb5e4..ccaf7e35abeb 100644
> --- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
> +++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
> @@ -315,8 +315,9 @@ int dpaa2_mac_connect(struct dpaa2_mac *mac)
>  		goto err_put_node;
>  	}
>  
> -	if (mac->attr.link_type == DPMAC_LINK_TYPE_PHY &&
> -	    mac->attr.eth_if != DPMAC_ETH_IF_RGMII) {
> +	if ((mac->attr.link_type == DPMAC_LINK_TYPE_PHY &&
> +	     mac->attr.eth_if != DPMAC_ETH_IF_RGMII) ||
> +	    mac->attr.link_type == DPMAC_LINK_TYPE_BACKPLANE) {
>  		err = dpaa2_pcs_create(mac, dpmac_node, mac->attr.id);
>  		if (err)
>  			goto err_put_node;
> -- 
> 2.20.1
>
Russell King (Oracle) Jan. 20, 2021, 10:35 p.m. UTC | #2
On Wed, Jan 20, 2021 at 10:19:01PM +0000, Ioana Ciornei wrote:
> On Tue, Jan 19, 2021 at 03:36:09PM +0000, Russell King wrote:
> > Add support for backplane link mode, which is, according to discussions
> > with NXP earlier in the year, is a mode where the OS (Linux) is able to
> > manage the PCS and Serdes itself.
> 
> Indeed, DPMACs in TYPE_BACKPLANE can have both their PCS and SerDes managed
> by Linux (since the firmware is not touching these).
> That being said, DPMACs in TYPE_PHY (the type that is already supported
> in dpaa2-mac) can also have their PCS managed by Linux (no interraction
> from the firmware's part with the PCS, just the SerDes).

This is not what was discussed last year. It clearly shows in the
slides that Bogdan sent in April 2020 "PCS Representation in Linux.pptx"
page 4 that the firmware manages the PCS in TYPE_PHY and TYPE_FIXED
mode.

It was explained during the call that Linux must not access the internal
MDIO nor touch the PCS _except_ when using TYPE_BACKPLANE mode. Touching
the internal MDIO was stated as unsupported in other modes as the MC
firmware will be performing MDIO accesses.

> Also, with just the changes from this patch, a interface connected to a
> DPMAC in TYPE_BACKPLANE is not even creating a phylink instance. It's
> mainly because of this check from dpaa2-eth:
> 
> 	if (dpaa2_eth_is_type_phy(priv)) {
> 		err = dpaa2_mac_connect(mac);
> 
> 
> I would suggest just dropping this patch.

That is a recent change in net-next, but is not in my tree...

In any case, if NXP have changed it such that, when in TYPE_PHY, the
MC firmware no longer accesses the PCS and it is now safe to perform
MDIO accesses, then we _still_ need this patch for older firmwares.

In short, what you've put in your email does not tie up with the
position that was discussed last year, and seems to me to be a total
U-turn over what was being said.
Russell King (Oracle) Feb. 4, 2021, 2:51 p.m. UTC | #3
On Wed, Jan 20, 2021 at 10:19:01PM +0000, Ioana Ciornei wrote:
> On Tue, Jan 19, 2021 at 03:36:09PM +0000, Russell King wrote:
> > Add support for backplane link mode, which is, according to discussions
> > with NXP earlier in the year, is a mode where the OS (Linux) is able to
> > manage the PCS and Serdes itself.
> 
> Indeed, DPMACs in TYPE_BACKPLANE can have both their PCS and SerDes managed
> by Linux (since the firmware is not touching these).
> That being said, DPMACs in TYPE_PHY (the type that is already supported
> in dpaa2-mac) can also have their PCS managed by Linux (no interraction
> from the firmware's part with the PCS, just the SerDes).
> 
> All in all, this patch is not needed for this particular usecase, where
> the switch between 1000Base-X and SGMII is done by just a minor
> reconfiguration in the PCS, without the need for SerDes changes.
> 
> Also, with just the changes from this patch, a interface connected to a
> DPMAC in TYPE_BACKPLANE is not even creating a phylink instance. It's
> mainly because of this check from dpaa2-eth:
> 
> 	if (dpaa2_eth_is_type_phy(priv)) {
> 		err = dpaa2_mac_connect(mac);
> 
> 
> I would suggest just dropping this patch.

Hi Ioana,

So what is happening with this series given our discussions off-list?

Do I resend it as-is?

Thanks.
Ioana Ciornei Feb. 4, 2021, 3:40 p.m. UTC | #4
On Thu, Feb 04, 2021 at 02:51:24PM +0000, Russell King - ARM Linux admin wrote:
> On Wed, Jan 20, 2021 at 10:19:01PM +0000, Ioana Ciornei wrote:
> > On Tue, Jan 19, 2021 at 03:36:09PM +0000, Russell King wrote:
> > > Add support for backplane link mode, which is, according to discussions
> > > with NXP earlier in the year, is a mode where the OS (Linux) is able to
> > > manage the PCS and Serdes itself.
> > 
> > Indeed, DPMACs in TYPE_BACKPLANE can have both their PCS and SerDes managed
> > by Linux (since the firmware is not touching these).
> > That being said, DPMACs in TYPE_PHY (the type that is already supported
> > in dpaa2-mac) can also have their PCS managed by Linux (no interraction
> > from the firmware's part with the PCS, just the SerDes).
> > 
> > All in all, this patch is not needed for this particular usecase, where
> > the switch between 1000Base-X and SGMII is done by just a minor
> > reconfiguration in the PCS, without the need for SerDes changes.
> > 
> > Also, with just the changes from this patch, a interface connected to a
> > DPMAC in TYPE_BACKPLANE is not even creating a phylink instance. It's
> > mainly because of this check from dpaa2-eth:
> > 
> > 	if (dpaa2_eth_is_type_phy(priv)) {
> > 		err = dpaa2_mac_connect(mac);
> > 
> > 
> > I would suggest just dropping this patch.
> 
> Hi Ioana,
> 
> So what is happening with this series given our discussions off-list?
> 

Let's also accept TYPE_BACKPLANE as you suggested.

> Do I resend it as-is?
> 

For the net-next, you would also need the following diff on top of your changes in patch 3/3:

--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h
@@ -695,7 +695,9 @@ static inline unsigned int dpaa2_eth_rx_head_room(struct dpaa2_eth_priv *priv)

 static inline bool dpaa2_eth_is_type_phy(struct dpaa2_eth_priv *priv)
 {
-       if (priv->mac && priv->mac->attr.link_type == DPMAC_LINK_TYPE_PHY)
+       if (priv->mac &&
+           (priv->mac->attr.link_type == DPMAC_LINK_TYPE_PHY ||
+            priv->mac->attr.link_type == DPMAC_LINK_TYPE_BACKPLANE))
                return true;

        return false;

Would you mind amending your commit with this and resending the series?

Thanks,
Ioana
diff mbox series

Patch

diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
index 3ddfb40eb5e4..ccaf7e35abeb 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
@@ -315,8 +315,9 @@  int dpaa2_mac_connect(struct dpaa2_mac *mac)
 		goto err_put_node;
 	}
 
-	if (mac->attr.link_type == DPMAC_LINK_TYPE_PHY &&
-	    mac->attr.eth_if != DPMAC_ETH_IF_RGMII) {
+	if ((mac->attr.link_type == DPMAC_LINK_TYPE_PHY &&
+	     mac->attr.eth_if != DPMAC_ETH_IF_RGMII) ||
+	    mac->attr.link_type == DPMAC_LINK_TYPE_BACKPLANE) {
 		err = dpaa2_pcs_create(mac, dpmac_node, mac->attr.id);
 		if (err)
 			goto err_put_node;