netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Nicolò Veronese" <nicveronese@gmail.com>
To: netdev@vger.kernel.org
Cc: simonebortolin@hack-gpon.org, nanomad@hack-gpon.org,
	 Federico Cappon <dududede371@gmail.com>,
	daniel@makrotopia.org, lorenzo@kernel.org,  ftp21@ftp21.eu,
	pierto88@hack-gpon.org, hitech95@hack-gpon.org,
	 davem@davemloft.net, andrew@lunn.ch, edumazet@google.com,
	 hkallweit1@gmail.com, kuba@kernel.org, pabeni@redhat.com,
	 linux@armlinux.org.uk, nbd@nbd.name
Subject: [RFC] RJ45 to SFP auto-sensing and switching in mux-ed single-mac devices (XOR RJ/SFP)
Date: Tue, 29 Aug 2023 17:12:48 +0200	[thread overview]
Message-ID: <CAC8rN+AQUKH1pUHe=bZh+bw-Wxznx+Lvom9iTruGQktGb=FFyw@mail.gmail.com> (raw)

Hi,

I and some folks in CC are working to properly port all the
 functions of a Zyxel ex5601-t0 to OpenWrt.

The manufacturer decided to use a single SerDes connected
 to both an SPF cage and an RJ45 phy. A simple GPIO is
 used to control a 2 Channel 2:1 MUX to switch the two SGMII pairs
 between the RJ45 and the SFP.

  ┌─────┐  ┌──────┐   ┌─────────┐
  │     │  │      │   │         │
  │     │  │      ├───┤ SFP     │
  │     │  │      │   └─────────┘
  │     │  │      │
  │ MAC ├──┤ MUX  │   ┌─────────┐
  │     │  │      │   │         │
  │     │  │      │   │ RJ45    │
  │     │  │      ├───┤ 2.5G PHY│
  │     │  │      │   │         │
  └─────┘  └───▲──┘   └─────────┘
               │
  MUX-GPIO ────┘

Other vendors may implement this differently (e.g. Keenetic
 KN-1011 has a similar setup, although the PHY is doing all the work),
 but this seems a common enough approach to produce cheap CPEs
 with multiple interface types for fiber internet.

In this particular case, Zyxel implemented a user-land script[1] that is
 continuously polling GPIO 57 (Moddef0) of the SFP cage.

Once an SFP module is detected the process continues as follows:
- An MDIO command disables the RJ45 PHY
- A GPIO write to GPIO 10 that switches the MUX to the SFP interface
- The MAC is then re-configured by writing directly to the SoC registers
 using a mix of lookup tables and heuristics/try-catch.

This allows Zyxel to configure the MAC with the supposedly correct SFP
 interface speed, bypassing any well-established interface speed
 auto-detection and negotiation logic.

Zyxel also configures the GMAC at boot with a fixed speed of 2500M
 forcing the link status to be always up irrespective of the real
 physical interface status.

On SFP disconnect the process is simply applied in reverse.

We are looking for guidance on how to design changes that could achieve
 the following goals and could be accepted upstream in the future:

 - SFP and RJ45 speed auto-sensing and auto-negotiation working
 - Automatic SFP/RJ45 switching
 - Failsafe logic in case both media are connected.
 - Reduce overall potential power consumption and rate-adaption by not
   having the GMAC always switched to 2500M mode without reason.
 - (optional) default configurable logic for both failsafe and idle status

References:
[1]: https://github.com/pameruoso/zyxel-ex5601t0/blob/V5.70(ACDZ.0)C0/target/linux/mediatek/ex5601t0/base-files/bin/sfp_wan.sh

             reply	other threads:[~2023-08-29 15:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 15:12 Nicolò Veronese [this message]
2023-08-29 15:38 ` [RFC] RJ45 to SFP auto-sensing and switching in mux-ed single-mac devices (XOR RJ/SFP) Russell King (Oracle)
2023-08-29 17:37   ` Daniel Golle
2023-08-29 18:04     ` Russell King (Oracle)
2023-08-31  1:04   ` Jakub Kicinski
2023-09-03 22:51   ` Andrew Lunn
2023-09-04  6:06     ` 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='CAC8rN+AQUKH1pUHe=bZh+bw-Wxznx+Lvom9iTruGQktGb=FFyw@mail.gmail.com' \
    --to=nicveronese@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=dududede371@gmail.com \
    --cc=edumazet@google.com \
    --cc=ftp21@ftp21.eu \
    --cc=hitech95@hack-gpon.org \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo@kernel.org \
    --cc=nanomad@hack-gpon.org \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pierto88@hack-gpon.org \
    --cc=simonebortolin@hack-gpon.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).