Message-ID: <20241008082857.115a2272@device-21.home>
Date: Tue, 8 Oct 2024 08:28:57 +0200
From: Maxime Chevallier <maxime.chevallier@...tlin.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com, Andrew Lunn
 <andrew@...n.ch>, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 linux-arm-kernel@...ts.infradead.org, Christophe Leroy
 <christophe.leroy@...roup.eu>, Herve Codina <herve.codina@...tlin.com>,
 Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit
 <hkallweit1@...il.com>, Vladimir Oltean <vladimir.oltean@....com>, Marek
 Behún <kabel@...nel.org>, Köry Maincent
 <kory.maincent@...tlin.com>, Oleksij Rempel <o.rempel@...gutronix.de>
Subject: Re: [PATCH net-next v2 0/9] Allow isolating PHY devices

Hi Russell,

On Mon, 7 Oct 2024 16:53:32 +0100
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

> On Mon, Oct 07, 2024 at 12:25:13PM +0200, Maxime Chevallier wrote:
> > Hello Russell
> > 
> > On Fri, 4 Oct 2024 18:02:25 +0100
> > "Russell King (Oracle)" <linux@...linux.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.  
> 
> Looking at 802.3, there is no support for isolation in the clause 45
> register set - the isolate bit only appears in the clause 22 BMCR.
> Clause 22 registers are optional for clause 45 PHYs.
> 
> My reading of this is that 802.3 has phased out isolation support on
> the MII side of the PHY on more modern PHYs, so this seems to be a
> legacy feature.
> 
> Andrew has already suggested that we should default to isolate not
> being supported - given that it's legacy, I agree with that.
> 
> > > 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.  
> 
> You have given further details in other response to Andrew. I'll
> comment further there.
> 
> > I will include that in the cover.  
> 
> Yes, it would be good to include all these details in the cover message
> so that it isn't spread out over numerous replies.
> 
> > 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 ?  
> 
> I think the question should be: which MII interfaces can electrically
> support multi-drop setups.
> 
> 22.2.4.1.6 describes the Clause 22 Isolate bit, which only suggests
> at one use case - for a PHY connected via an 802.3 defined connector
> which shall power up in isolated state "to avoid the possibility of
> having multiple MII output drivers actively driving the same signal
> path simultaneously". This connector only supports four data signals
> in each direction, which precludes GMII over this defined connector.
> 
> However, it talks about isolating the MII and GMII signals in this
> section.
> 
> Putting that all together, 802.3 suggests that it is possible to
> have multiple PHYs on a MII or GMII (which in an explanatory note
> elsewhere, MII means 100Mb/s, GMII for 1Gb/s.) However, it is
> vague.

Yes it's vague, as as testing showed, vendors are pretty liberal with
how/if they implement this feature :(

> Now... I want to say more, but this thread is fragmented and the
> next bit of the reply needs to go elsewhere in this thread,
> which is going to make reviewing this discussion later on rather
> difficult... but we're being drip-fed the technical details.

TBH I wasn't expecting this series on isolation to be the place to
discuss the multiplexing use-cases, hence why I didn't include a full
descriptin of every setup I have in the cover.

Given what Andrew replied, this whole series on controling isolation
from userspace isn't relevant.

Let me start a proper discussion thread and summarize what has been
said so far.

Maxime

Powered by blists - more mailing lists