From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "Kory Maincent" <kory.maincent@bootlin.com>,
"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
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>,
"Nicolò Veronese" <nicveronese@gmail.com>,
"Simon Horman" <horms@kernel.org>,
mwojtas@chromium.org, "Antoine Tenart" <atenart@kernel.org>
Subject: Re: [PATCH net-next RFC 0/5] net: phy: Introduce a port representation
Date: Tue, 7 Jan 2025 15:14:43 +0000 [thread overview]
Message-ID: <Z31E4_oWPmFgvfxl@shell.armlinux.org.uk> (raw)
In-Reply-To: <Z300BuATJoVDc_4S@pengutronix.de>
On Tue, Jan 07, 2025 at 03:02:46PM +0100, Oleksij Rempel wrote:
> On Tue, Jan 07, 2025 at 02:26:05PM +0100, Kory Maincent wrote:
> > On Thu, 2 Jan 2025 18:03:52 +0100
> > Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> >
> > > On Thu, Jan 02, 2025 at 10:48:05AM +0000, Russell King (Oracle) wrote:
> > > > On Sun, Dec 22, 2024 at 07:54:37PM +0100, Oleksij Rempel wrote:
> > > > > Here is updated version:
> > > > >
> > > > > ports {
> > > > > /* 1000BaseT Port with Ethernet and simple PoE */
> > > > > port0: ethernet-port@0 {
> > > > > reg = <0>; /* Port index */
> > > > > label = "ETH0"; /* Physical label on the device */
> > > > > connector = "RJ45"; /* Connector type */
> > > > > supported-modes = <10BaseT 100BaseTX 1000BaseT>; /* Supported
> > > > > modes */
> > > > >
> > > > > transformer {
> > > > > model = "ABC123"; /* Transformer model number */
> > > > > manufacturer = "TransformerCo"; /* Manufacturer name */
> > > > >
> > > > > pairs {
> > > > > pair@0 {
> > > > > name = "A"; /* Pair A */
> > > > > pins = <1 2>; /* Connector pins */
> > > > > phy-mapping = <PHY_TX0_P PHY_TX0_N>; /* PHY pin
> > > > > mapping */ center-tap = "CT0"; /* Central tap identifier */
> > > > > pse-negative = <PSE_GND>; /* CT0 connected to GND */
> > > > > };
> > > > > pair@1 {
> > > > > name = "B"; /* Pair B */
> > > > > pins = <3 6>; /* Connector pins */
> > > > > phy-mapping = <PHY_RX0_P PHY_RX0_N>;
> > > > > center-tap = "CT1"; /* Central tap identifier */
> > > > > pse-positive = <PSE_OUT0>; /* CT1 connected to
> > > > > PSE_OUT0 */ };
> > > > > pair@2 {
> > > > > name = "C"; /* Pair C */
> > > > > pins = <4 5>; /* Connector pins */
> > > > > phy-mapping = <PHY_TXRX1_P PHY_TXRX1_N>; /* PHY
> > > > > connection only */ center-tap = "CT2"; /* Central tap identifier */
> > > > > /* No power connection to CT2 */
> > > > > };
> > > > > pair@3 {
> > > > > name = "D"; /* Pair D */
> > > > > pins = <7 8>; /* Connector pins */
> > > > > phy-mapping = <PHY_TXRX2_P PHY_TXRX2_N>; /* PHY
> > > > > connection only */ center-tap = "CT3"; /* Central tap identifier */
> > > > > /* No power connection to CT3 */
> > > > > };
> > > > > };
> > > > > };
> >
> > Couldn't we begin with something simple like the following and add all the
> > transformers and pairs information as you described later if the community feels
> > we need it?
> >
> > mdis {
> >
> > /* 1000BaseT Port with Ethernet and PoE */
> > mdi0: ethernet-mdi@0 {
> > reg = <0>; /* Port index */
> > label = "ETH0"; /* Physical label on the device */
> > connector = "RJ45"; /* Connector type */
> > supported-modes = <10BaseT 100BaseTX 1000BaseT>; /* Supported modes */
> > lanes = <2>;
> > variant = "MDI-X"; /* MDI or MDI-X */
> > pse = <&pse1>;
> > };
> > };
>
> The problematic properties are lanes and variants.
>
> Lanes seems to not provide any additional information which is not
> provided by the supported-modes.
>
> We have at least following working variants, which are supported by (some?)
> microchip PHYs:
> https://microchip.my.site.com/s/article/1000Base-T-Differential-Pair-Swapping
> For swapping A and B pairs, we may use MDI/MDI-X. What is about swapped
> C and D pairs?
>
> The IEEE 802.3 - 2022 has following variants:
> 14.5.2 Crossover function - only A<>B swap is supported
> 40.4.4 Automatic MDI/MDI-X Configuration - only A<>B swap is supported?
> 55.4.4 Automatic MDI/MDI-X configuration - 4 swap variants are supported
> 113.4.4 Automatic MDI/MDI-X configuration - 4 swap variants are supported
> 126.4.4 Automatic MDI/MDI-X configuration - 4 swap variants are supported
>
> This was only the pair swap. How to reflect the polarity swap withing
> the pairs?
802.3 supports this because of the problems caused by miswired cables,
which are typically a user thing. It's not really there to give freedom
to designers to wire their sockets incorrectly.
Do we have any real cases where a socket has been wired incorrectly?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2025-01-07 15:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 20:14 [PATCH net-next RFC 0/5] net: phy: Introduce a port representation Maxime Chevallier
2024-12-20 20:15 ` [PATCH net-next RFC 1/5] net: ethtool: common: Make BaseT a 4-lanes mode Maxime Chevallier
2024-12-20 20:15 ` [PATCH net-next RFC 2/5] net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values Maxime Chevallier
2024-12-20 20:15 ` [PATCH net-next RFC 3/5] net: ethtool: Export the link_mode_params definitions Maxime Chevallier
2024-12-20 20:15 ` [PATCH net-next RFC 4/5] net: phy: Introduce PHY ports representation Maxime Chevallier
2024-12-21 13:59 ` kernel test robot
2024-12-20 20:15 ` [PATCH net-next RFC 5/5] net: phy: dp83822: Add support for phy_port representation Maxime Chevallier
2024-12-21 15:55 ` kernel test robot
2024-12-22 15:59 ` [PATCH net-next RFC 0/5] net: phy: Introduce a port representation Oleksij Rempel
2024-12-22 18:54 ` Oleksij Rempel
2025-01-02 10:48 ` Russell King (Oracle)
2025-01-02 17:03 ` Oleksij Rempel
2025-01-07 13:26 ` Kory Maincent
2025-01-07 14:02 ` Oleksij Rempel
2025-01-07 14:43 ` Kory Maincent
2025-01-07 14:53 ` Oleksij Rempel
2025-01-07 15:14 ` Russell King (Oracle) [this message]
2025-01-07 15:54 ` Oleksij Rempel
2025-01-07 15:12 ` Russell King (Oracle)
2025-01-07 16:13 ` Andrew Lunn
2025-01-07 16:15 ` Maxime Chevallier
2025-01-07 16:22 ` Andrew Lunn
2025-01-07 16:41 ` Oleksij Rempel
2025-01-07 16:49 ` Oleksij Rempel
2025-01-08 7:25 ` Maxime Chevallier
2025-01-08 8:12 ` Oleksij Rempel
2025-01-04 22:23 ` Kory Maincent
2025-01-06 18:17 ` Oleksij Rempel
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=Z31E4_oWPmFgvfxl@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=atenart@kernel.org \
--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=horms@kernel.org \
--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=maxime.chevallier@bootlin.com \
--cc=mwojtas@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=nicveronese@gmail.com \
--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 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.