All of
 help / color / mirror / Atom feed
From: Russell King - ARM Linux admin <>
To: Ioana Ciornei <>
Cc: Ioana Ciocoi Radulescu <>,
	Andrew Lunn <>,
	Heiner Kallweit <>,
	"David S. Miller" <>,
	Jakub Kicinski <>,
	"" <>
Subject: Re: [PATCH net-next 3/3] net: dpaa2-mac: add backplane link mode support
Date: Wed, 20 Jan 2021 22:35:58 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210120221900.i6esmk6uadgqpdtu@skbuf>

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

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.

RMK's Patch system:
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2021-01-21  2:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 15:35 [PATCH net-next 0/3] dpaa2: add 1000base-X support Russell King - ARM Linux admin
2021-01-19 15:35 ` [PATCH net-next 1/3] net: pcs: add pcs-lynx 1000BASE-X support Russell King
2021-01-20 22:03   ` Ioana Ciornei
2021-01-19 15:36 ` [PATCH net-next 2/3] net: dpaa2-mac: add " Russell King
2021-01-20 22:23   ` Ioana Ciornei
2021-01-19 15:36 ` [PATCH net-next 3/3] net: dpaa2-mac: add backplane link mode support Russell King
2021-01-20 22:19   ` Ioana Ciornei
2021-01-20 22:35     ` Russell King - ARM Linux admin [this message]
2021-02-04 14:51     ` Russell King - ARM Linux admin
2021-02-04 15:40       ` Ioana Ciornei

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.