drivers/net/phy/Makefile | 2 +- drivers/net/phy/dp83822.c | 60 +++++++---- drivers/net/phy/phy_device.c | 167 +++++++++++++++++++++++++++++ drivers/net/phy/phy_port.c | 159 ++++++++++++++++++++++++++++ include/linux/ethtool.h | 62 +++++++++++ include/linux/phy.h | 31 ++++++ include/linux/phy_port.h | 69 ++++++++++++ net/ethtool/common.c | 197 +++++++++++++++++++---------------- net/ethtool/common.h | 7 -- 9 files changed, 633 insertions(+), 121 deletions(-) create mode 100644 drivers/net/phy/phy_port.c create mode 100644 include/linux/phy_port.h
Hello everyone,
This is a long overdue series to kick-off the introduction of a better representation
of front-facing ports for ethernet interfaces.
First, a short disclaimer. This series is RFC, and there are quite a lot of
shortcomings :
- There's no DT binding although this series adds a generic representation of
ports
- The port representation is in a minimal form
- No SFP support is included, but it will be required for that series to come
out of RFC as we can't gracefully handle multi-port interfaces without it.
These shortcomigs come from timing constraints, but also because I'd like to
start discussing that topic with some code as a basis.
For now, the only representation we have about the physical ports of an interface
come from the 'port' field (PORT_FIBRE, PORT_TP, PORT_MII, etc.), the presence or
not of an SFP module and the linkmodes reported by the ethtol ksettings ops. This
isn't enough to get a good idea of what the actual interface with the outside world
looks like.
The end-goal of the work this series is a part of is to get support for multi-port
interfaces. My end use-case has 2 ports, each driven by a dedicated PHY, but this
also applies to dual-port PHYs.
The current series introduces the object "struct phy_port". The naming may be
improved, as I think we could consider supporting port representation without
depending on phylib (not the case in this RFC). For now, not only do we integrate
that work in phylib, but only PHY-driven ports are supported.
In some situations, having a good representation of the physical port in devicetree
proves to be quite useful. We're seeing vendor properties to address the lack of
port representation such as micrel,fiber-mode or ti,fiber-mode, but there are needs
for more (glitchy straps that detect fiber mode on a PHY connected to copper,
RJ45 ports connected with 2 lanes only, ...).
As I said this RFC has no binding, sorry about that, but let's take a look at
the proposed DT syntax :
Example 1 : PHY with RJ45 connected with 2 lanes only
&mdio {
ge_phy: ethernet-phy@0 {
reg = <0>;
mdi {
port@0 {
media = "BaseT",
lanes = <2>;
};
};
};
};
Example 2 : PHY with a 100BaseFX port, without SFP
&mdio {
fiber-phy: ethernet-phy@0 {
reg = <0>;
mdi {
port@0 {
media = "BaseF",
lanes = <1>;
};
};
};
};
These ports may even be used to specify PSE-PD information for PoE ports that
are drivern by a dedicated PoE controller sitting in-between the PHY and the
connector :
&mdio {
ge_phy: ethernet-phy@0 {
reg = <0>;
mdi {
port@0 {
media = "BaseT",
lanes = <4>;
pse = <&pse1>;
};
};
};
};
The ports are initialized using the following sequence :
1: The PHY driver's probe() function indicated the max number of ports the device
can control
2: We parse the devicetree to find generic port representations
3: If we don't have at least one port from DT, we create one
4: We call the phy's .attach_port() for each port created so far. This allows
the phy driver either to take action based on the generic port devicetree
indications, or to populate the port information based on straps and
vendor-specific DT properties (think micrel,fiber-mode and similar)
5: If the ports are still not initialized (no .attach_port, no generic DT), then
we use snesible default value from what the PHY's supported modes.
6: We reconstruct the PHY's supported field in case there are limitations from the
port (2 lanes on BaseT for example). This last step will need to be changed
when SFP gets added.
So, the current work is only about init. The next steps for that work are :
- Introduce phy_port_ops, including a .configure() and a .read_status() to get
proper support for multi-port PHYs. This also means maintaining a list of
advertising/lp_advertising modes for each port.
- Add SFP support. It's a tricky part, the way I see that and have prototyped is
by representing the SFP cage itself as a port, as well as the SFP module's port.
ports therefore become chainable.
- Add the ability to list the ports in userspace.
Prototype work for the above parts exist, but due to lack of time I couldn't get
them polished enough for inclusion in that RFC.
Let me know if you see this going in the right direction, I'm really all ears
for suggestions on this, it's quite difficult to make sure no current use-case
breaks and no heavy rework is needed in PHY drivers.
Patches 1, 2 and 3 are preparatory work for the mediums representation. Patch 4
introduces the phy_port and patch 5 shows an example of usage in the dp83822 phy.
Thanks,
Maxime
Maxime Chevallier (5):
net: ethtool: common: Make BaseT a 4-lanes mode
net: ethtool: Introduce ETHTOOL_LINK_MEDIUM_* values
net: ethtool: Export the link_mode_params definitions
net: phy: Introduce PHY ports representation
net: phy: dp83822: Add support for phy_port representation
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/dp83822.c | 60 +++++++----
drivers/net/phy/phy_device.c | 167 +++++++++++++++++++++++++++++
drivers/net/phy/phy_port.c | 159 ++++++++++++++++++++++++++++
include/linux/ethtool.h | 62 +++++++++++
include/linux/phy.h | 31 ++++++
include/linux/phy_port.h | 69 ++++++++++++
net/ethtool/common.c | 197 +++++++++++++++++++----------------
net/ethtool/common.h | 7 --
9 files changed, 633 insertions(+), 121 deletions(-)
create mode 100644 drivers/net/phy/phy_port.c
create mode 100644 include/linux/phy_port.h
--
2.47.1
Hi Maxime,
On Fri, Dec 20, 2024 at 09:14:59PM +0100, Maxime Chevallier wrote:
> Hello everyone,
>
> This is a long overdue series to kick-off the introduction of a better representation
> of front-facing ports for ethernet interfaces.
>
> First, a short disclaimer. This series is RFC, and there are quite a lot of
> shortcomings :
>
> - There's no DT binding although this series adds a generic representation of
> ports
> - The port representation is in a minimal form
> - No SFP support is included, but it will be required for that series to come
> out of RFC as we can't gracefully handle multi-port interfaces without it.
>
> These shortcomigs come from timing constraints, but also because I'd like to
> start discussing that topic with some code as a basis.
>
> For now, the only representation we have about the physical ports of an interface
> come from the 'port' field (PORT_FIBRE, PORT_TP, PORT_MII, etc.), the presence or
> not of an SFP module and the linkmodes reported by the ethtol ksettings ops. This
> isn't enough to get a good idea of what the actual interface with the outside world
> looks like.
>
> The end-goal of the work this series is a part of is to get support for multi-port
> interfaces. My end use-case has 2 ports, each driven by a dedicated PHY, but this
> also applies to dual-port PHYs.
>
> The current series introduces the object "struct phy_port". The naming may be
> improved, as I think we could consider supporting port representation without
> depending on phylib (not the case in this RFC). For now, not only do we integrate
> that work in phylib, but only PHY-driven ports are supported.
>
> In some situations, having a good representation of the physical port in devicetree
> proves to be quite useful. We're seeing vendor properties to address the lack of
> port representation such as micrel,fiber-mode or ti,fiber-mode, but there are needs
> for more (glitchy straps that detect fiber mode on a PHY connected to copper,
> RJ45 ports connected with 2 lanes only, ...).
>
> As I said this RFC has no binding, sorry about that, but let's take a look at
> the proposed DT syntax :
>
> Example 1 : PHY with RJ45 connected with 2 lanes only
>
> &mdio {
>
> ge_phy: ethernet-phy@0 {
> reg = <0>;
>
> mdi {
> port@0 {
> media = "BaseT",
> lanes = <2>;
> };
> };
>
> };
> };
>
> Example 2 : PHY with a 100BaseFX port, without SFP
>
> &mdio {
>
> fiber-phy: ethernet-phy@0 {
> reg = <0>;
>
> mdi {
> port@0 {
> media = "BaseF",
> lanes = <1>;
> };
> };
>
> };
> };
>
> These ports may even be used to specify PSE-PD information for PoE ports that
> are drivern by a dedicated PoE controller sitting in-between the PHY and the
> connector :
>
> &mdio {
>
> ge_phy: ethernet-phy@0 {
> reg = <0>;
>
> mdi {
> port@0 {
> media = "BaseT",
> lanes = <4>;
> pse = <&pse1>;
> };
> };
>
> };
> };
>
> The ports are initialized using the following sequence :
>
> 1: The PHY driver's probe() function indicated the max number of ports the device
> can control
>
> 2: We parse the devicetree to find generic port representations
>
> 3: If we don't have at least one port from DT, we create one
>
> 4: We call the phy's .attach_port() for each port created so far. This allows
> the phy driver either to take action based on the generic port devicetree
> indications, or to populate the port information based on straps and
> vendor-specific DT properties (think micrel,fiber-mode and similar)
>
> 5: If the ports are still not initialized (no .attach_port, no generic DT), then
> we use snesible default value from what the PHY's supported modes.
>
> 6: We reconstruct the PHY's supported field in case there are limitations from the
> port (2 lanes on BaseT for example). This last step will need to be changed
> when SFP gets added.
>
> So, the current work is only about init. The next steps for that work are :
>
> - Introduce phy_port_ops, including a .configure() and a .read_status() to get
> proper support for multi-port PHYs. This also means maintaining a list of
> advertising/lp_advertising modes for each port.
>
> - Add SFP support. It's a tricky part, the way I see that and have prototyped is
> by representing the SFP cage itself as a port, as well as the SFP module's port.
> ports therefore become chainable.
>
> - Add the ability to list the ports in userspace.
>
> Prototype work for the above parts exist, but due to lack of time I couldn't get
> them polished enough for inclusion in that RFC.
>
> Let me know if you see this going in the right direction, I'm really all ears
> for suggestions on this, it's quite difficult to make sure no current use-case
> breaks and no heavy rework is needed in PHY drivers.
>
> Patches 1, 2 and 3 are preparatory work for the mediums representation. Patch 4
> introduces the phy_port and patch 5 shows an example of usage in the dp83822 phy.
I love the idea of introducing a port description. It’s a step in the right.
However, in the proposed schema, I see some weak points that could be improved
for better flexibility and usability.
### Weak Points Identified
1. **`lanes` Do Not Provide Enough Information**
The concept of "lanes" can be ambiguous, as it is context-dependent. For
differential connections, a lane typically refers to a differential pair, but
the schema doesn't clearly define how the lanes map to physical wires or pins.
By describing explicit pin mappings and supported modes, the `lanes` property
becomes obsolete.
2. **`media` Lacks Sufficient Detail**
The `media` property currently doesn’t add meaningful information for
describing the physical characteristics of a port. By defining the connector
type (e.g., RJ45, BNC, LC) and supported modes explicitly, the need for the
`media` property is removed.
### Proposed Port Description Schema
Here’s how I imagine the port description could look to address these issues:
#### **Device Tree Example**
/* Ports should be in the root of DT */
ports {
/* Twisted-Pair Example */
port0: ethernet-port@0 {
reg = <0>; /* Port index */
label = "ETH0"; /* Physical label on the device */
connector = "RJ45"; /* Connector type */
supported-modes = <10BaseT 100BaseTX>; /* Supported modes */
pairs {
pair@0 {
name = "A"; /* Pair A */
pins = <1 2>; /* Connector pins */
phy-mapping = <PHY_TX0_P PHY_TX0_N>; /* PHY pin mapping */
pse-mapping = <PSE_OUT0_P PSE_OUT0_N>; /* PSE pin mapping */
};
pair@1 {
name = "B"; /* Pair B */
pins = <3 6>;
phy-mapping = <PHY_RX0_P PHY_RX0_N>;
pse-mapping = <PSE_OUT1_P PSE_OUT1_N>;
};
};
pse = <&pse1>; /* Reference to attached PSE controller */
leds {
link = <&led0>; /* Link status LED */
activity = <&led1>; /* Activity LED */
};
};
/* Single-Pair Ethernet (SPE) Example */
port1: ethernet-port@1 {
reg = <1>;
label = "SPE1";
connector = "H-MTD"; /* Single-pair connector */
supported-modes = <1000BaseT1>; /* Supported SPE modes */
pairs {
pair@0 {
name = "A"; /* Single pair for SPE */
pins = <1 2>;
phy-mapping = <PHY_TXRX0_P PHY_TXRX0_N>;
pse-mapping = <PSE_OUT0_P PSE_OUT0_N>;
};
};
pse = <&pse2>; /* Reference to a different PSE controller */
leds {
link = <&led3>;
activity = <&led4>;
};
};
/* Coaxial Example */
port2: ethernet-port@2 {
reg = <2>;
label = "COAX0"; /* Physical label for coaxial port */
connector = "BNC"; /* Connector type for coaxial */
supported-modes = <10Base2>; /* Supported coaxial modes */
coaxial {
pins = <1>; /* Signal pin for coaxial port */
phy-mapping = <PHY_SIG>; /* Single-ended PHY signal mapping */
pse-mapping = <PSE_OUT>; /* PSE mapping (if applicable) */
};
};
/* Fiber Example */
port3: ethernet-port@3 {
reg = <3>;
label = "FIBER0"; /* Physical label for fiber port */
connector = "LC"; /* Connector type for fiber */
supported-modes = <100BaseFX>; /* Supported fiber modes */
fiber {
tx-pins = <1 2>; /* TX signal pins for fiber */
rx-pins = <3 4>; /* RX signal pins for fiber */
phy-mapping = <PHY_TX_P PHY_TX_N PHY_RX_P PHY_RX_N>; /* TX/RX PHY mappings */
};
};
/* SFP Port Example */
port4: ethernet-port@4 {
reg = <4>; /* Port index */
label = "SFP0"; /* Physical label for the SFP port */
connector = "SFP"; /* Connector type for SFP */
supported-modes = <1000BaseX 10GBaseSR>; /* Supported SFP modes */
sfp {
tx-pins = <1 2>; /* TX differential pair for SFP module */
rx-pins = <3 4>; /* RX differential pair for SFP module */
phy-mapping = <PHY_TX_P PHY_TX_N PHY_RX_P PHY_RX_N>; /* TX/RX PHY mappings */
i2c = <&i2c0>; /* Reference to the I2C bus for SFP module management */
mod-def0 = <&gpio1 5 GPIO_ACTIVE_HIGH>; /* GPIO for MOD-DEF0 */
tx-disable = <&gpio1 6 GPIO_ACTIVE_HIGH>; /* GPIO for TX_DISABLE */
los = <&gpio1 7 GPIO_ACTIVE_HIGH>; /* GPIO for Loss of Signal (LOS) */
presence = <&gpio1 8 GPIO_ACTIVE_HIGH>; /* GPIO for module presence */
};
leds {
link = <&led5>; /* Link status LED */
activity = <&led6>; /* Activity LED */
};
};
};
### How This Schema Addresses the Problems
1. **Precise Pair and Pin Mapping**
Each pair is explicitly described with its physical connector pins and
corresponding mappings to PHY and PSE pins. This eliminates ambiguity around
lane definitions and allows the PHY to handle pair-specific configurations like
polarity inversion or swapped pairs.
2. **Simplified Media Representation**
By specifying `connector` (e.g., RJ45, LC, BNC), the schema provides
practical information about the physical interface without requiring an
abstract `media` property.
3. **Support for LEDs and Power Delivery**
The schema integrates additional hardware elements like LED assignments and
PSE references, making it easier to configure ports for diagnostics and power
delivery (PoE/PoDL).
I hope this feedback helps refine the port description schema. Let me know what
you think, and I’m happy to discuss this further!
Best regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Sun, Dec 22, 2024 at 04:59:43PM +0100, Oleksij Rempel wrote:
> ### Proposed Port Description Schema
>
> Here’s how I imagine the port description could look to address these issues:
>
> #### **Device Tree Example**
> /* Ports should be in the root of DT */
> ports {
> /* Twisted-Pair Example */
> port0: ethernet-port@0 {
> reg = <0>; /* Port index */
> label = "ETH0"; /* Physical label on the device */
> connector = "RJ45"; /* Connector type */
> supported-modes = <10BaseT 100BaseTX>; /* Supported modes */
>
> pairs {
> pair@0 {
> name = "A"; /* Pair A */
> pins = <1 2>; /* Connector pins */
> phy-mapping = <PHY_TX0_P PHY_TX0_N>; /* PHY pin mapping */
> pse-mapping = <PSE_OUT0_P PSE_OUT0_N>; /* PSE pin mapping */
> };
> pair@1 {
> name = "B"; /* Pair B */
> pins = <3 6>;
> phy-mapping = <PHY_RX0_P PHY_RX0_N>;
> pse-mapping = <PSE_OUT1_P PSE_OUT1_N>;
> };
> };
>
> pse = <&pse1>; /* Reference to attached PSE controller */
>
> leds {
> link = <&led0>; /* Link status LED */
> activity = <&led1>; /* Activity LED */
> };
> };
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 */
};
};
};
pse = <&pse1>; /* Reference to the attached PSE controller */
leds {
ethernet-leds {
link = <ð_led0>; /* Link status LED */
activity = <ð_led1>; /* Activity LED */
speed = <ð_led2>; /* Speed indication LED */
};
poe-leds {
power = <&poe_led0>; /* PoE power status LED */
fault = <&poe_led1>; /* PoE fault indication LED */
budget = <&poe_led2>; /* PoE budget usage LED */
};
};
};
};
A port with fully configurable PoE support:
ports {
/* 1000BaseT Port with Fully Configurable 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 */
shielding = "grounded"; /* Indicates the connector is shielded */
/*
grounded: Shield is connected to chassis or earth ground.
floating: Shield is not electrically connected.
capacitive: Shield is connected to ground via a capacitor.
signal: Shield is connected to the signal ground.
*/
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 */
/* if pse-positive and pse-negative are present - polarity is configurable */
pse-positive = <PSE_OUT0_0>; /* PSE-controlled positive pin -> CT0 */
pse-negative = <PSE_OUT0_1>; /* PSE-controlled negative pin -> CT0 */
};
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_OUT1_0>;
pse-negative = <PSE_OUT1_1>;
};
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 */
pse-positive = <PSE_OUT2_0>;
pse-negative = <PSE_OUT2_1>;
};
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 */
pse-positive = <PSE_OUT3_0>;
pse-negative = <PSE_OUT3_1>;
};
};
};
pse = <&pse1>; /* Reference to the attached PSE controller */
thermal {
temp-sensor = <&tsensor0>; /* Reference to temperature sensor */
/* or */
thermal-zone = <&thermal_zone0>; /* Reference to thermal zone */
}
fuses {
overcurrent-fuse {
type = "resettable"; /* Resettable polyfuse */
max-current = <1000>; /* Maximum current in milliamps */
location = "data-pairs"; /* Fuse protects data pairs */
};
overvoltage-fuse {
type = "tvs-diode"; /* TVS diode for surge protection */
clamp-voltage = <60>; /* Clamping voltage in volts */
location = "poe-pairs"; /* Fuse protects PoE pairs */
};
};
leds {
ethernet-leds {
link = <ð_led0>; /* Link status LED */
activity = <ð_led1>; /* Activity LED */
speed = <ð_led2>; /* Speed indication LED */
};
poe-leds {
power = <&poe_led0>; /* PoE power status LED */
fault = <&poe_led1>; /* PoE fault indication LED */
budget = <&poe_led2>; /* PoE budget usage LED */
};
};
};
};
In case of PoDL, we will have something like this:
pair@0 {
name = "A"; /* Single pair for 10BaseT1L */
pins = <1 2>; /* Connector pins */
phy-mapping = <PHY_TXRX0_P PHY_TXRX0_N>; /* PHY pin mapping */
podl-mapping = <PODL_OUT0_P PODL_OUT0_N>; /* PoDL mapping: Positive and negative outputs */
};
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Sun, 22 Dec 2024 19:54:37 +0100
Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> 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 */
> /* if pse-positive and pse-negative are present -
> polarity is configurable */ pse-positive = <PSE_OUT0_0>; /* PSE-controlled
> positive pin -> CT0 */ pse-negative = <PSE_OUT0_1>; /* PSE-controlled
> negative pin -> CT0 */ };
> 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_OUT1_0>;
> pse-negative = <PSE_OUT1_1>;
> };
> 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 */
> pse-positive = <PSE_OUT2_0>;
> pse-negative = <PSE_OUT2_1>;
> };
> 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 */
> pse-positive = <PSE_OUT3_0>;
> pse-negative = <PSE_OUT3_1>;
> };
> };
> };
>
> pse = <&pse1>; /* Reference to the attached PSE controller */
The PSE pairset and polarity are already described in the PSE bindings.
https://elixir.bootlin.com/linux/v6.12.6/source/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
I am not sure it is a good idea to have PSE information at two different places.
> leds {
> ethernet-leds {
> link = <ð_led0>; /* Link status LED */
> activity = <ð_led1>; /* Activity LED */
> speed = <ð_led2>; /* Speed indication LED */
> };
>
> poe-leds {
> power = <&poe_led0>; /* PoE power status LED */
> fault = <&poe_led1>; /* PoE fault indication LED */
> budget = <&poe_led2>; /* PoE budget usage LED */
> };
> };
Maybe the PoE leds should also land in our pse-pis binding.
> In case of PoDL, we will have something like this:
>
> pair@0 {
> name = "A"; /* Single pair for 10BaseT1L */
> pins = <1 2>; /* Connector pins */
> phy-mapping = <PHY_TXRX0_P PHY_TXRX0_N>; /* PHY pin mapping */
> podl-mapping = <PODL_OUT0_P PODL_OUT0_N>; /* PoDL mapping: Positive and
> negative outputs */ };
We should do the same for PoDL. Put all information in the same place, the PSE
bindings.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
On Sat, Jan 04, 2025 at 11:23:59PM +0100, Kory Maincent wrote:
> On Sun, 22 Dec 2024 19:54:37 +0100
> Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> > pse = <&pse1>; /* Reference to the attached PSE controller */
>
> The PSE pairset and polarity are already described in the PSE bindings.
> https://elixir.bootlin.com/linux/v6.12.6/source/Documentation/devicetree/bindings/net/pse-pd/pse-controller.yaml
>
> I am not sure it is a good idea to have PSE information at two different places.
You are right, the PSE PI node already covers the IEEE specifications. But
there are still some missing pieces. These are not directly tied to the PSE but
are important for port functionality, like LEDs, thermal sensors, and
transformer characteristics.
### Why Link to the Port Node
While LEDs, thermal zones, and other components can be described in the Device
Tree, there’s currently no clear way to indicate which ones belong to a
specific port. For single-port devices, this isn’t a big issue, but for devices
like switches with multiple ports, it gets messy very quickly.
For example:
- LEDs: Each port may have multiple LEDs for link, activity, and PoE
status. Without linking them to specific ports, the software cannot correctly
map these LEDs to their respective functionalities.
- Thermal Sensors: Sensors located near specific ports or magnetics are crucial
for thermal management. If they aren’t linked to a port, it’s unclear which
sensor data applies to which port.
### Why Transformer Characteristics Matter
Transformers (magnetics) are critical for Ethernet and affect software in these
ways:
1. Signal Integrity:
- Transformers influence noise and insertion loss.
- Some PHYs allow analog tuning for the connected transformer. Software
needs this information to configure PHY registers for optimal performance.
2. Power Delivery:
- Transformers have power and current limits.
- Software must ensure the power budget stays within these limits and detect
overcurrent conditions.
3. Thermal Management:
- Transformers can overheat under load.
- Software should monitor nearby sensors and reduce power if temperatures
exceed safe levels.
This functionality does not need to be added right now. However, I’ve
encountered some of these issues and believe they may impact others sooner or
later. It would be good if newly added specifications avoid conflicting with or
blocking potential solutions to these known issues.
> > In case of PoDL, we will have something like this:
> >
> > pair@0 {
> > name = "A"; /* Single pair for 10BaseT1L */
> > pins = <1 2>; /* Connector pins */
> > phy-mapping = <PHY_TXRX0_P PHY_TXRX0_N>; /* PHY pin mapping */
> > podl-mapping = <PODL_OUT0_P PODL_OUT0_N>; /* PoDL mapping: Positive and
> > negative outputs */ };
>
> We should do the same for PoDL. Put all information in the same place, the PSE
> bindings.
Ack.
Since IEEE does not provide anything beyond pinout and polarity description for
PSE PI specifications (at least for PoE variants), let's keep those details
there. Magnetics, being a shared component, should be described as part of the
port. Thermal sensors located near magnetics or physical ports are port-related
and should also be linked to the port. LEDs, however, fall into different
groups: some are connected to PHYs, others to PSE, and they may be controlled
by PHYs, PSE, or external controllers with software. These LEDs need a clear
linkage to their corresponding port functionality. What would be the best way
to establish this linkage without introducing unnecessary complexity?
Best regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
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 */
> };
> };
> };
I'm sorry, but... what is the point of giving this much detail in the DT
description. How much of this actually would get used by *any* code?
Why does it matter what transformer is used - surely 802.3 defines the
characteristics of the signal at the RJ45 connector and it's up to the
hardware designer to ensure that those characteristics are met. That
will depend on the transformer, connector and board layout.
What does it matter what connector pins are used? This is standardised.
You also at one point had a description for a SFP cage (I'm sorry, I
can't be bothered to find it in the 3000+ emails that I've missed over
the Christmas period), using pin numbers 1, 2, 3, and 4. That's
nonsense, those aren't the pin numbers for the data pairs. You also
are effectively redefining what already exists for SFP cages - we
already have a DT description for that, and it's based around the
standardised connector. Why do we need a new description for SFP
cages?
Are we going to start converting schematics into DT representations,
including any resistors and capacitors that may be present in the
data path?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
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 */
> > };
> > };
> > };
>
> I'm sorry, but... what is the point of giving this much detail in the DT
> description. How much of this actually would get used by *any* code?
>
> Why does it matter what transformer is used - surely 802.3 defines the
> characteristics of the signal at the RJ45 connector and it's up to the
> hardware designer to ensure that those characteristics are met. That
> will depend on the transformer, connector and board layout.
>
> What does it matter what connector pins are used? This is standardised.
>
> You also at one point had a description for a SFP cage (I'm sorry, I
> can't be bothered to find it in the 3000+ emails that I've missed over
> the Christmas period), using pin numbers 1, 2, 3, and 4. That's
> nonsense, those aren't the pin numbers for the data pairs. You also
> are effectively redefining what already exists for SFP cages - we
> already have a DT description for that, and it's based around the
> standardised connector. Why do we need a new description for SFP
> cages?
>
> Are we going to start converting schematics into DT representations,
> including any resistors and capacitors that may be present in the
> data path?
First of all, Happy New Year! :)
I also apologize for the SFP example provided earlier - it was vague, unclear,
and wasted your time. The purpose was not to redefine existing standards but to
demonstrate that even SFP might require separate consideration if we ever move
towards more detailed descriptions. My current focus, however, is on twisted
pair-based Ethernet**, and I’d like to discuss that further if you’re open to
it.
### Why Describe Pair Layouts?
While Ethernet ports often work seamlessly even with misaligned pair layouts
due to PHY auto-correction mechanisms like **MDI-X** or **CD pair swap
correction**, these misalignments can affect diagnostics.
If pairs are misaligned but still functional in automatic mode, the diagnostic
interface may fail to provide meaningful or accurate data. For example:
- MDI/MDI-X Detection: Misaligned pairs can lead to unexpected results,
such as both sides reporting the same status when using a non-crossover cable.
- Debugging Pair Issues: Without proper correction data in the DT, it
becomes challenging to identify and validate pair swaps (e.g., A<>B or C<>D)
during diagnostics.
Including pair layout information in the DT ensures that the diagnostic
interface can apply necessary corrections, making diagnostics usable.
### Why Address Polarity?
Polarity detection and correction are mandatory, and all modern PHYs handle it
seamlessly. However, Open Alliance standards require polarity indication
and the ability for manual correction, particularly for automotive-grade
PHYs (e.g., 1000BaseT1, 100BaseT1).
(See: 6.4 Polarity Detection and Correction (POL))
https://opensig.org/wp-content/uploads/2024/01/Advanced_PHY_features_for_automotive_Ethernet_V1.0.pdf
(Example of non-automotive PHYs supporting polarity indication and disabling of
auto correction)
https://ww1.microchip.com/downloads/en/DeviceDoc/VMDS-10242.pdf
When polarity within the pair becomes relevant for diagnostics, proper PCB
layout becomes crucial. It’s not uncommon for the PCB connection to differ from
the expected polarity at the physical port. Including polarity details in the
DT allows for better alignment between hardware and software diagnostics,
ensuring issues can be detected and corrected efficiently.
### Why Mention Shielding?
Shielding impacts EMI performance and compatibility, and knowing the shielding
type (e.g., grounded, floating, capacitive) helps in:
- Cable Selection: Ensures compatibility between shielded/unshielded cables
and port design.
- EMI Troubleshooting: Identifies issues in noisy environments or mismatched
configurations.
- System Design: Prevents ground loops and ensures compliance with EMC
standards.
Even though this information should ideally be part of the product
documentation, having it accessible through the interface makes
software-supported diagnostics much more convenient. For example, software
could guide users by stating: "This controller has floating shielding. Ensure
the cable is unshielded, or if shielded, it must be properly terminated at
least on one side."
### Why Mention Magnetics (Transformers)?
We have to deal with different types of connections: with or without magnetics.
Magnetics themselves come in various types and can be classified by their
common-mode rejection elements, number of cores, and other
characteristics.
From a software or user perspective, knowing the type and model of the
magnetics is useful for several reasons. For example:
- The transformer model do affect Time Domain Reflectometry offsets, sometimes
resulting in discrepancies of several meters.
(See: TDR Offset Calibration)
https://www.analog.com/en/resources/app-notes/an-2553.html
https://ww1.microchip.com/downloads/en/Appnotes/VPPD-01740.pdf
- Transformers influence insertion loss and exhibit varying noise
characteristics, both of which impact the analog properties of signals.
- Some PHYs support tuning their analog characteristics (e.g., VoD swing,
impedance matching) based on the attached magnetics. Advanced PHYs with such
capabilities are often found in industrial-grade PHYs.
(See: How to Tune DP83825 VoD Swing)
https://www.ti.com/lit/an/snla266a/snla266a.pdf
Best regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
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>;
};
};
We can also add led, thermal and fuse subnodes later.
Let's begin with something simple for the initial support, considering
that it has places for additional details in the future.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
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?
+1.
> 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>;
> };
> };
We already manage well enough without anything like this level of
detail of a RJ45 socket, so why don't we start off with something
very simple. I'm thinking that even giving the supported-modes
argument is too much here - have we *ever* had the case where an
ethernet port can't support all the speeds that it's associated
PHY supports?
> We can also add led, thermal and fuse subnodes later.
> Let's begin with something simple for the initial support, considering
> that it has places for additional details in the future.
What I think we both fear is having a complex DT description of a
port that the kernel mostly ignores. While we can come out with the
"but DT describes the hardware" claptrap, it's no good trying to
describe the hardware in a firmware description unless there is some
way to validate that the firmware description is correct - which
means there must be something that depends on it in order to work.
If we describe stuff that doesn't get used, there's no way to know
if it is actually correct. We then end up with a lot of buggy DT
descriptions with properties that can't be relied upon to be
correct, and that makes those properties utterly useless.
I'm sure DT maintainers will disagree due to the "DT describes the
hardware" but... I've said it here, and if we end up with stuff
over-described wrongly creating a mess, I'll be able to point back
at this!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Oleksij, Köry, Russell,
Sorry for the silence so far, i'm now back from a restful holiday
break, and I'm catching-up on this discussion.
I'm replying here, but I've read the discussion so far, and thanks a
lot Oleksji for all the suggestions, it's nice to see that this is
interesting for you !
On Tue, 7 Jan 2025 15:12:20 +0000
"Russell King (Oracle)" <linux@armlinux.org.uk> 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 */
So for these supported modes, this is something I've tried to avoid
actually, and for 2 reasons :
- With the usual argument that DT is a HW description, supported-modes
doesn't work here. What matters is :
- The medium used (is it twisted copper pairs ? backplane ? One of
the may flavors of fiber through a dedicated connector ?) and as a
complement, the number of lanes. This in itself isn't strictly
necessary. A BaseT1 PHY will obviously have only one lane on its MDI
for example. The reason I have included the lanes is mainly for BaseT,
where BaseT1 has one lane while the typical gigabit port has 4.
I have however seen devices that have a 1G PHY connected to a RJ45
port with 2 lanes only, thus limiting the max achievable speed to 100M.
Here, we would explicietly describe the port has having 2 lanes.
- The supported modes that can be achieved on a port is a bit
redundant considering that we already have a great deal of capability
discovery implemented in phylib, phylink, the SFP stack, etc.
> > > > >
> > > > > 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?
>
> +1.
+1 as well. One thing is that I'd like to make so that describing the
port is some last-resort solution and make it really not mandatory.
That means, the internal port representation that the kernel maintains
should be able to be populated with sane defaults based on whatever
drives the port can do. As Russell says, things are working pretty well
so far, especially for single-port PHYs that can already indicated
pretty precisely what they can output.
Having a port representation in DT is useful for corner cases such as :
- For a single-port PHY, when the PHY can't figure-out by itself what
the MDI is. For example, PHYs that can drive either copper or fiber and
that can't reliably derive the mode to use from its straps
- For weirdnesses in the way the PHY port is wired in HW. As I
mentionned, the only case I encountered was 2 lanes on a 1G PHY, thus
limiting the speed to 100M max.
- As an "attachment point" for things like PSE, that are really about
ports and not the PHY.
One could argue that this description isn't even needed, but OTHO with
the recent addition of vendor properties like "micrel,fiber-mode" or
"ti,fiber-mode", it appears that there's a gap to fill.
I do think that there's value in Oleksij's ideas, but this discussion
doesn't even include DT people who could help draw a line somewhere.
All that being said, if the status-quo from this discussion is "let's
keep it simple", I have some things I'd still like to discuss.
First, should we keep the lanes ?
And second, I'm confused about the way we deal with BaseX right now, as
we treat it both as a medium and as an MII mode.
If we look at 10G in comparison, we have a clear difference between the
phy_interface_mode "10GBaseR" and the linkmodes "10000BaseKR",
"10000BaseSR", etc.
We don't really have that for baseX, and it may already be too late,
but should we introduce the "1000BaseXS / 1000BaseLX / 1000BaseCX"
modes ?
Thanks everyone,
Maxime
> I have however seen devices that have a 1G PHY connected to a RJ45
> port with 2 lanes only, thus limiting the max achievable speed to 100M.
> Here, we would explicietly describe the port has having 2 lanes.
Some PHYs would handle this via downshift, detecting that some pairs
are broken, and then dropping down to 100M on their own. So it is not
always necessary to have a board property, at least not for data.
I've no idea how this affects power transfer. Can the link partners
detect which pairs are actually wired?
Andrew
On Tue, Jan 07, 2025 at 05:22:51PM +0100, Andrew Lunn wrote: > > I have however seen devices that have a 1G PHY connected to a RJ45 > > port with 2 lanes only, thus limiting the max achievable speed to 100M. > > Here, we would explicietly describe the port has having 2 lanes. I can confirm existence of this kind of designs. One industrial real life example: a SoC connected to 3 port Gigabit KSZ switch. One port is typical RJ45 connector. Other port is RJ11 connector. The speed can be reduced by using max-speed property. But i can't provide any user usable diagnostic information just by saying pair A or B is broken. This is one of the reasons why i propose detailed description. > Some PHYs would handle this via downshift, detecting that some pairs > are broken, and then dropping down to 100M on their own. So it is not > always necessary to have a board property, at least not for data. Ack, but it will work not for all setups. > I've no idea how this affects power transfer. Can the link partners > detect which pairs are actually wired? Not is usual simple implementation. The PSE PI devicetree properties provide enough information for a _standard_ use case. -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Tue, 7 Jan 2025 17:41:30 +0100 Oleksij Rempel <o.rempel@pengutronix.de> wrote: > On Tue, Jan 07, 2025 at 05:22:51PM +0100, Andrew Lunn wrote: > > > I have however seen devices that have a 1G PHY connected to a RJ45 > > > port with 2 lanes only, thus limiting the max achievable speed to 100M. > > > Here, we would explicietly describe the port has having 2 lanes. > > I can confirm existence of this kind of designs. One industrial real life > example: a SoC connected to 3 port Gigabit KSZ switch. One port is > typical RJ45 connector. Other port is RJ11 connector. > > The speed can be reduced by using max-speed property. But i can't > provide any user usable diagnostic information just by saying pair A or > B is broken. > > This is one of the reasons why i propose detailed description. While I get the point, I'm wondering if it's relevant to expose this diag information for the user. As this is a HW design feature we're representing, and it's described in devicetree, the information that the HW design is wrong or uncommon is already known. So, exposing this to the user ends-up being a pretty way to display plain devicetree data, without much added value from the PHY stack ? Or am I missing the point ? I would see some value if we could detect that pairs are miswired or disconnected at runtime, then report this to user. Here the information is useful. The minimal information needed by software is in that case "how many working pairs are connected between the PHY and the connector", and possibly "are they swapped ?" but I think we already have a DT property for that ? Maxime
On Wed, Jan 08, 2025 at 08:25:07AM +0100, Maxime Chevallier wrote:
> On Tue, 7 Jan 2025 17:41:30 +0100
> Oleksij Rempel <o.rempel@pengutronix.de> wrote:
>
> > On Tue, Jan 07, 2025 at 05:22:51PM +0100, Andrew Lunn wrote:
> > > > I have however seen devices that have a 1G PHY connected to a RJ45
> > > > port with 2 lanes only, thus limiting the max achievable speed to 100M.
> > > > Here, we would explicietly describe the port has having 2 lanes.
> >
> > I can confirm existence of this kind of designs. One industrial real life
> > example: a SoC connected to 3 port Gigabit KSZ switch. One port is
> > typical RJ45 connector. Other port is RJ11 connector.
> >
> > The speed can be reduced by using max-speed property. But i can't
> > provide any user usable diagnostic information just by saying pair A or
> > B is broken.
> >
> > This is one of the reasons why i propose detailed description.
>
> While I get the point, I'm wondering if it's relevant to expose this
> diag information for the user. As this is a HW design feature we're
> representing, and it's described in devicetree, the information that the
> HW design is wrong or uncommon is already known. So, exposing this to
> the user ends-up being a pretty way to display plain devicetree data,
> without much added value from the PHY stack ? Or am I missing the point
> ?
Correct. The same kind of information, such as whether the connector is RJ45 or
an industrial one with a proprietary layout, or what label this port will have
on the box, is essential. This information helps the user to manage, repair, or
connect devices in the field - even after 30 years of operation, when no paper
manual has survived being eaten by animals and the vendor's websites no longer
exist.
Here is one example of an industrial switch with PoE support:
https://www.westermo.com/-/media/Files/User-guides/westermo_ug_6641-22501_viper-x12a-poe_revo.pdf?rev=083148a9e565416a9044e9a4e379635f
Please pay attention to the difference for Gbit and 100Mbit ports and signal
layout within this ports.
> I would see some value if we could detect that pairs are miswired or
> disconnected at runtime, then report this to user. Here the information
> is useful.
Ack.
> The minimal information needed by software is in that case "how many
> working pairs are connected between the PHY and the connector", and
> possibly "are they swapped ?"
In case of home and enterprise type of devices - yes.
In case of industrial - the devices can be certified to operate in some
specific link mode.
For example device certified for explosive environments. These device should
operate in 10BaseT1L-Vpp1 mode only, and discard any link attempts to
devices which advertise 10BaseT1L-Vpp2 support in addition to 10BaseT1L-Vpp1:
https://www.pepperl-fuchs.com/germany/de/classid_260.htm?view=productdetails&prodid=118298
My point is, if we will need to set limit for the link modes, soon or later,
we will need a supported linkmodes property and this property will partially
duplicated the lanes property. At same time, if we use supported linkmodes
instead of lanes, we solve the problem with multimode PHYs which support
twisted pair and fiber modes.
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Tue, Jan 07, 2025 at 05:41:30PM +0100, Oleksij Rempel wrote: > On Tue, Jan 07, 2025 at 05:22:51PM +0100, Andrew Lunn wrote: > > > I have however seen devices that have a 1G PHY connected to a RJ45 > > > port with 2 lanes only, thus limiting the max achievable speed to 100M. > > > Here, we would explicietly describe the port has having 2 lanes. > > I can confirm existence of this kind of designs. One industrial real life > example: a SoC connected to 3 port Gigabit KSZ switch. One port is > typical RJ45 connector. Other port is RJ11 connector. > > The speed can be reduced by using max-speed property. But i can't > provide any user usable diagnostic information just by saying pair A or > B is broken. > > This is one of the reasons why i propose detailed description. Here is one example: https://www.balluff.com/de-de/products/BNI004F?gad_source=1&gclid=Cj0KCQiAvvO7BhC-ARIsAGFyToUmOy6VpSZUszHQ9X4tuUlyLdtAZqkk3tKxggF5z7D1pk3CgH5IOvwaAhhUEALw_wcB -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> What I think we both fear is having a complex DT description of a
> port that the kernel mostly ignores. While we can come out with the
> "but DT describes the hardware" claptrap, it's no good trying to
> describe the hardware in a firmware description unless there is some
> way to validate that the firmware description is correct - which
> means there must be something that depends on it in order to work.
>
> If we describe stuff that doesn't get used, there's no way to know
> if it is actually correct. We then end up with a lot of buggy DT
> descriptions with properties that can't be relied upon to be
> correct, and that makes those properties utterly useless.
This is a real issue we have had in the past. A property which was
ignored, until it was not ignored, and then lots of boards broke
because they had the property wrong.
I would strongly recommend than any property you define is always
used, validated, and ideally will not work when wrong.
Andrew
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?
> We can also add led, thermal and fuse subnodes later.
> Let's begin with something simple for the initial support, considering
> that it has places for additional details in the future.
Yes :)
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
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!
On Tue, Jan 07, 2025 at 03:14:43PM +0000, Russell King (Oracle) wrote: > 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: > > 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? Yes. I tested some low cost adapter using same driver but reporting incorrect results, depending on board. I can explain it only by incorrect PCB design. -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Tue, 7 Jan 2025 15:02:46 +0100
Oleksij Rempel <o.rempel@pengutronix.de> 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:
> [...]
> [...]
> >
> > 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?
Indeed I see what you mean. Maybe we could add it later as optional binding and
only focus for now on the current needs.
According to Maxime proposition he wants the connector types and the
supported modes (or number of lanes). On my side I am interested in the PSE
phandle.
We could begin with this:
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 */
pse = <&pse1>;
};
};
Your proposition will stay in our mind for future development on the subject.
I think we currently don't have enough time available to develop the full
package.
What do you think?
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
On Tue, Jan 07, 2025 at 03:43:02PM +0100, Kory Maincent wrote:
> On Tue, 7 Jan 2025 15:02:46 +0100
> Oleksij Rempel <o.rempel@pengutronix.de> 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:
> > [...]
> > [...]
> > >
> > > 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>;
> > > };
> > > };
> > This was only the pair swap. How to reflect the polarity swap withing
> > the pairs?
>
> Indeed I see what you mean. Maybe we could add it later as optional binding and
> only focus for now on the current needs.
> According to Maxime proposition he wants the connector types and the
> supported modes (or number of lanes). On my side I am interested in the PSE
> phandle.
>
> We could begin with this:
> 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 */
> pse = <&pse1>;
> };
> };
>
> Your proposition will stay in our mind for future development on the subject.
Perfect :)
> I think we currently don't have enough time available to develop the full
> package.
Yes, no one do.
> What do you think?
Sounds good!
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
© 2016 - 2026 Red Hat, Inc.