devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Marek Behún" <kabel@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>, Peter Rosin <peda@axentia.se>,
	netdev@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH RFC net-next] dt-bindings: ethernet-controller: document signal multiplexer
Date: Wed, 7 Jul 2021 18:14:32 +0100	[thread overview]
Message-ID: <20210707171432.GT22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210707012224.14df9eab@thinkpad>

On Wed, Jul 07, 2021 at 01:22:24AM +0200, Marek Behún wrote:
> On Fri, 2 Jul 2021 02:55:54 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
> > On Thu, Jul 01, 2021 at 02:53:47AM +0200, Marek Behún wrote:
> > > There are devices where the MAC signals from the ethernet controller are
> > > not directly connected to an ethernet PHY or a SFP cage, but to a
> > > multiplexer, so that the device can switch between the endpoints.
> > > 
> > > For example on Turris Omnia the WAN controller is connected to a SerDes
> > > switch, which multiplexes the SerDes lanes between SFP cage and ethernet
> > > PHY, depending on whether a SFP module is present (MOD_DEF0 GPIO from
> > > the SFP cage).  
> > 
> > At the moment, i don't think phylink supports this. It does not have a
> > way to dynamically switch PHY. If the SFP disappears, you probably
> > want to configure the PHY, so that it is up, autoneg started,
> > etc. When the SFP reappears, the PHY needs to be configured down, the
> > SFP probably needs its TX GPIO line set active, etc. None of this
> > currently exists.
> 
> Of course this is not supported by phylink: it can't be, since we don't
> even have a binding description :) I am figuring out how to do correct
> binding while working on implementing this into phylink.

I have been thinking that we need phylink to separate the PHY pointer
that was probed by the network adapter and the PHY pointer for the SFP.
The reason being that currently, a network adapter can remove the SFP
PHY when it didn't create it - which is obviously not a good idea as it
doesn't own it.

The other reason is to do with this situation where we have separate
PHY and SFP paths. I'm not intending at this point to add support for
this, only to separate the two PHYs and have something like:

static struct phy_device *phylink_phy(struct phylink *pl)
{
	if (pl->sfp_phy)
		return pl->sfp_phydev;
	return pl->phydev;
}

and use that everywhere we want to get at pl->phydev in the independent
parts of the code. Those which want to get at a specific PHY will
continue using their appropriate pointers directly.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

      reply	other threads:[~2021-07-07 17:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  0:53 [PATCH RFC net-next] dt-bindings: ethernet-controller: document signal multiplexer Marek Behún
2021-07-01 14:02 ` Rob Herring
2021-07-01 18:04 ` Rob Herring
2021-07-02  0:55 ` Andrew Lunn
2021-07-06 23:22   ` Marek Behún
2021-07-07 17:14     ` Russell King (Oracle) [this message]

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=20210707171432.GT22278@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=kabel@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peda@axentia.se \
    --cc=robh+dt@kernel.org \
    /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).