linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	linux-arm-kernel@lists.infradead.org,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Herve Codina" <herve.codina@bootlin.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Vladimir Oltean" <vladimir.oltean@nxp.com>,
	"Marek Behún" <kabel@kernel.org>,
	"Köry Maincent" <kory.maincent@bootlin.com>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>
Subject: Re: [PATCH net-next v2 0/9] Allow isolating PHY devices
Date: Mon, 7 Oct 2024 12:25:13 +0200	[thread overview]
Message-ID: <20241007122513.4ab8e77b@device-21.home> (raw)
In-Reply-To: <ZwAfoeHUGOnDz1Y1@shell.armlinux.org.uk>

Hello Russell

On Fri, 4 Oct 2024 18:02:25 +0100
"Russell King (Oracle)" <linux@armlinux.org.uk> wrote:

> I'm going to ask a very basic question concerning this.
> 
> Isolation was present in PHYs early on when speeds were low, and thus
> electrical reflections weren't too much of a problem, and thus star
> topologies didn't have too much of an effect. A star topology is
> multi-drop. Even if the PCB tracks go from MAC to PHY1 and then onto
> PHY2, if PHY2 is isolated, there are two paths that the signal will
> take, one to MAC and the other to PHY2. If there's no impediance match
> at PHY2 (e.g. because it's in high-impedance mode) then that
> transmission line is unterminated, and thus will reflect back towards
> the MAC.
> 
> As speeds get faster, then reflections from unterminated ends become
> more of an issue.
> 
> I suspect the reason why e.g. 88x3310, 88E1111 etc do not support
> isolate mode is because of this - especially when being used in
> serdes mode, the topology is essentially point-to-point and any
> side branches can end up causing data corruption.

I suspect indeed that this won't work on serdes interfaces. I didn't
find any reliable information on that, but so far the few PHYs I've
seen seem to work that way.

The 88e1512 supports that, but I was testing in RGMII.

> 
> So my questions would be, is adding support for isolation mode in
> PHYs given todays network speeds something that is realistic, and
> do we have actual hardware out there where there is more than one
> PHY in the bus. If there is, it may be useful to include details
> of that (such as PHY interface type) in the patch series description.

I do have some hardware with this configuration (I'd like to support
that upstream, the topology work was preliminary work for that, and the
next move would be to send an RFC for these topolopgies exactly).

I am working with 3 different HW platforms with this layout :

      /--- PHY
      |
MAC  -|  phy_interface_mode == MII so, 100Mbps Max.
      |
      \--- PHY

and another that is similar but with RMII. I finally have one last case
with MII interface, same layout, but the PHYs can't isolate so we need
to make sure all but one PHYs are powered-down at any given time.

I will include that in the cover.

Could we consider limiting the isolation to non-serdes interfaces ?
that would be :

 - MII
 - RMII
 - GMII
 - RGMII and its -[TX|RX] ID flavours
 - TBI and RTBI ?? (I'm not sure about these)

Trying to isolate a PHY that doesn't have any of the interfaces above
would result in -EOPNOTSUPP ?

Thanks,

Maxime



  reply	other threads:[~2024-10-07  8:28 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04 16:15 [PATCH net-next v2 0/9] Allow isolating PHY devices Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 1/9] net: phy: allow " Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 2/9] net: phy: Introduce phy_shutdown for device quiescence Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 3/9] net: phy: Allow PHY drivers to report isolation support Maxime Chevallier
2024-10-04 16:46   ` Oleksij Rempel
2024-10-07  9:52     ` Maxime Chevallier
2024-10-04 18:20   ` Andrew Lunn
2024-10-07 10:27     ` Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 4/9] net: phy: lxt: Mark LXT973 PHYs as having a broken isolate mode Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 5/9] net: phy: marvell10g: 88x3310 and 88x3340 don't support " Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 6/9] net: phy: marvell: mv88e1111 doesn't support isolate in SGMII mode Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 7/9] net: phy: introduce ethtool_phy_ops to get and set phy configuration Maxime Chevallier
2024-10-04 18:42   ` Andrew Lunn
2024-10-04 19:02     ` Russell King (Oracle)
2024-10-07 10:37       ` Maxime Chevallier
2024-10-07 13:01         ` Andrew Lunn
2024-10-07 13:48           ` Maxime Chevallier
2024-10-07 16:10             ` Russell King (Oracle)
2024-10-08  7:07               ` Maxime Chevallier
2024-10-07 16:37             ` Andrew Lunn
2024-10-08  7:25               ` Maxime Chevallier
2024-10-08 13:00                 ` Andrew Lunn
2024-10-08 13:22                   ` Russell King (Oracle)
2024-10-08 14:57                   ` Maxime Chevallier
2024-10-08 15:27                     ` Russell King (Oracle)
2024-10-08 16:41                       ` Maxime Chevallier
2024-10-08 17:05                         ` Russell King (Oracle)
2024-10-08 17:19                           ` Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 8/9] net: ethtool: phy: allow reporting and setting the phy isolate status Maxime Chevallier
2024-10-04 16:15 ` [PATCH net-next v2 9/9] netlink: specs: introduce phy-set command along with configurable attributes Maxime Chevallier
2024-10-04 17:02 ` [PATCH net-next v2 0/9] Allow isolating PHY devices Russell King (Oracle)
2024-10-07 10:25   ` Maxime Chevallier [this message]
2024-10-07 15:53     ` Russell King (Oracle)
2024-10-07 16:43       ` Andrew Lunn
2024-10-08  6:28       ` Maxime Chevallier

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=20241007122513.4ab8e77b@device-21.home \
    --to=maxime.chevallier@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=christophe.leroy@csgroup.eu \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=herve.codina@bootlin.com \
    --cc=hkallweit1@gmail.com \
    --cc=kabel@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vladimir.oltean@nxp.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).