Implement get_mse_config() and get_mse_snapshot() for the DP83TD510E
to expose its Mean Square Error (MSE) register via the new PHY MSE
UAPI.
The DP83TD510E does not document any peak MSE values; it only exposes
a single average MSE register used internally to derive SQI. This
implementation therefore advertises only PHY_MSE_CAP_AVG, along with
LINK and channel-A selectors. Scaling is fixed to 0xFFFF, and the
refresh interval/number of symbols are estimated from 10BASE-T1L
symbol rate (7.5 MBd) and typical diagnostic intervals (~1 ms).
For 10BASE-T1L deployments, SQI is a reliable indicator of link
modulation quality once the link is established, but it does not
indicate whether autonegotiation pulses will be correctly received
in marginal conditions. MSE provides a direct measurement of slicer
error rate that can be used to evaluate if autonegotiation is likely
to succeed under a given cable length and condition. In practice,
testing such scenarios often requires forcing a fixed-link setup to
isolate MSE behaviour from the autonegotiation process.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/net/phy/dp83td510.c | 44 +++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/net/phy/dp83td510.c b/drivers/net/phy/dp83td510.c
index 23af1ac194fa..094c070f3f96 100644
--- a/drivers/net/phy/dp83td510.c
+++ b/drivers/net/phy/dp83td510.c
@@ -249,6 +249,47 @@ struct dp83td510_priv {
#define DP83TD510E_ALCD_COMPLETE BIT(15)
#define DP83TD510E_ALCD_CABLE_LENGTH GENMASK(10, 0)
+static int dp83td510_get_mse_config(struct phy_device *phydev,
+ struct phy_mse_config *config)
+{
+ /* The DP83TD510E datasheet does not specify peak MSE values.
+ * It only provides a single MSE value which is used to derive SQI.
+ * Therefore, we only support the average MSE capability.
+ */
+ config->supported_caps = PHY_MSE_CAP_AVG | PHY_MSE_CAP_LINK |
+ PHY_MSE_CAP_CHANNEL_A;
+ config->max_average_mse = 0xFFFF;
+
+ /* The datasheet does not specify the refresh rate or symbol count,
+ * but based on similar PHYs and standards, we can assume a common
+ * value. For 10BaseT1L, the symbol rate is 7.5 MBd. A common
+ * diagnostic interval is around 1ms.
+ * 7.5e6 symbols/sec * 0.001 sec = 7500 symbols.
+ */
+ config->refresh_rate_ps = 1000000000; /* 1 ms */
+ config->num_symbols = 7500;
+
+ return 0;
+}
+
+static int dp83td510_get_mse_snapshot(struct phy_device *phydev, u32 channel,
+ struct phy_mse_snapshot *snapshot)
+{
+ int ret;
+
+ if (channel != PHY_MSE_CHANNEL_LINK &&
+ channel != PHY_MSE_CHANNEL_A)
+ return -EOPNOTSUPP;
+
+ ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, DP83TD510E_MSE_DETECT);
+ if (ret < 0)
+ return ret;
+
+ snapshot->average_mse = ret;
+
+ return 0;
+}
+
static int dp83td510_led_brightness_set(struct phy_device *phydev, u8 index,
enum led_brightness brightness)
{
@@ -893,6 +934,9 @@ static struct phy_driver dp83td510_driver[] = {
.get_phy_stats = dp83td510_get_phy_stats,
.update_stats = dp83td510_update_stats,
+ .get_mse_config = dp83td510_get_mse_config,
+ .get_mse_snapshot = dp83td510_get_mse_snapshot,
+
.led_brightness_set = dp83td510_led_brightness_set,
.led_hw_is_supported = dp83td510_led_hw_is_supported,
.led_hw_control_set = dp83td510_led_hw_control_set,
--
2.39.5Hi Oleksij,
On Friday, August 15, 2025 08:35 CEST, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
> Implement get_mse_config() and get_mse_snapshot() for the DP83TD510E
> to expose its Mean Square Error (MSE) register via the new PHY MSE
> UAPI.
>
> The DP83TD510E does not document any peak MSE values; it only exposes
> a single average MSE register used internally to derive SQI. This
> implementation therefore advertises only PHY_MSE_CAP_AVG, along with
> LINK and channel-A selectors. Scaling is fixed to 0xFFFF, and the
> refresh interval/number of symbols are estimated from 10BASE-T1L
> symbol rate (7.5 MBd) and typical diagnostic intervals (~1 ms).
>
> For 10BASE-T1L deployments, SQI is a reliable indicator of link
> modulation quality once the link is established, but it does not
> indicate whether autonegotiation pulses will be correctly received
> in marginal conditions. MSE provides a direct measurement of slicer
> error rate that can be used to evaluate if autonegotiation is likely
> to succeed under a given cable length and condition. In practice,
> testing such scenarios often requires forcing a fixed-link setup to
> isolate MSE behaviour from the autonegotiation process.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
[...]
> +static int dp83td510_get_mse_snapshot(struct phy_device *phydev, u32 channel,
> + struct phy_mse_snapshot *snapshot)
> +{
> + int ret;
> +
> + if (channel != PHY_MSE_CHANNEL_LINK &&
> + channel != PHY_MSE_CHANNEL_A)
> + return -EOPNOTSUPP;
The doc in patch 1 says :
> + * Link-wide mode:
> + * - Some PHYs only expose a link-wide aggregate MSE, or cannot map their
> + * measurement to a specific channel/pair (e.g. 100BASE-TX when MDI/MDI-X
> + * resolution is unknown). In that case, callers must use the LINK selector.
The way I understand that is that PHYs will report either channel-specific values or
link-wide values. Is that correct or are both valid ? In BaseT1 this is the same thing,
but maybe for consistency, we should report either channel values or link-wide values ?
Maxime
Hi Maxime,
On Mon, Aug 18, 2025 at 10:15:56AM +0200, Maxime Chevallier wrote:
> Hi Oleksij,
>
> On Friday, August 15, 2025 08:35 CEST, Oleksij Rempel <o.rempel@pengutronix.de> wrote:
>
> > Implement get_mse_config() and get_mse_snapshot() for the DP83TD510E
> > to expose its Mean Square Error (MSE) register via the new PHY MSE
> > UAPI.
> >
> > The DP83TD510E does not document any peak MSE values; it only exposes
> > a single average MSE register used internally to derive SQI. This
> > implementation therefore advertises only PHY_MSE_CAP_AVG, along with
> > LINK and channel-A selectors. Scaling is fixed to 0xFFFF, and the
> > refresh interval/number of symbols are estimated from 10BASE-T1L
> > symbol rate (7.5 MBd) and typical diagnostic intervals (~1 ms).
> >
> > For 10BASE-T1L deployments, SQI is a reliable indicator of link
> > modulation quality once the link is established, but it does not
> > indicate whether autonegotiation pulses will be correctly received
> > in marginal conditions. MSE provides a direct measurement of slicer
> > error rate that can be used to evaluate if autonegotiation is likely
> > to succeed under a given cable length and condition. In practice,
> > testing such scenarios often requires forcing a fixed-link setup to
> > isolate MSE behaviour from the autonegotiation process.
> >
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>
> [...]
>
> > +static int dp83td510_get_mse_snapshot(struct phy_device *phydev, u32 channel,
> > + struct phy_mse_snapshot *snapshot)
> > +{
> > + int ret;
> > +
> > + if (channel != PHY_MSE_CHANNEL_LINK &&
> > + channel != PHY_MSE_CHANNEL_A)
> > + return -EOPNOTSUPP;
>
> The doc in patch 1 says :
>
> > + * Link-wide mode:
> > + * - Some PHYs only expose a link-wide aggregate MSE, or cannot map their
> > + * measurement to a specific channel/pair (e.g. 100BASE-TX when MDI/MDI-X
> > + * resolution is unknown). In that case, callers must use the LINK selector.
>
> The way I understand that is that PHYs will report either channel-specific values or
> link-wide values. Is that correct or are both valid ? In BaseT1 this is the same thing,
> but maybe for consistency, we should report either channel values or link-wide values ?
for 100Base-T1 the LINK and channel-A selectors are effectively the
same, since the PHY only has a single channel. In this case both are
valid, and the driver will return the same answer for either request.
I decided to expose both for consistency:
- on one side, the driver already reports pair_A information for the
cable test, so it makes sense to allow channel-A here as well;
- on the other side, if a caller such as a generic link-status/health
request asks for LINK, we can also provide that without special
casing.
So the driver just answers what it can. For this PHY, LINK and
channel-A map to the same hardware register, and all other selectors
return -EOPNOTSUPP.
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 |
> > The doc in patch 1 says : > > > > > + * Link-wide mode: > > > + * - Some PHYs only expose a link-wide aggregate MSE, or cannot map their > > > + * measurement to a specific channel/pair (e.g. 100BASE-TX when MDI/MDI-X > > > + * resolution is unknown). In that case, callers must use the LINK selector. > > > > The way I understand that is that PHYs will report either channel-specific values or > > link-wide values. Is that correct or are both valid ? In BaseT1 this is the same thing, > > but maybe for consistency, we should report either channel values or link-wide values ? > > for 100Base-T1 the LINK and channel-A selectors are effectively the > same, since the PHY only has a single channel. In this case both are > valid, and the driver will return the same answer for either request. > > I decided to expose both for consistency: > - on one side, the driver already reports pair_A information for the > cable test, so it makes sense to allow channel-A here as well; > - on the other side, if a caller such as a generic link-status/health > request asks for LINK, we can also provide that without special > casing. > > So the driver just answers what it can. For this PHY, LINK and > channel-A map to the same hardware register, and all other selectors > return -EOPNOTSUPP. The document you referenced explicitly says it is for 100BASE-T1. Are there other Open Alliance documents which extend the concept to -T2 and -T4 links? Do you have access to -T2 or -T4 PHYs which implement the concept for multiple pairs? I think it is good you are thinking about the API, how it could work with -T2 and -T4, but do we need this complexity now? Andrew
On Wed, Aug 20, 2025 at 02:11:57PM +0200, Andrew Lunn wrote: > > > The doc in patch 1 says : > > > > > > > + * Link-wide mode: > > > > + * - Some PHYs only expose a link-wide aggregate MSE, or cannot map their > > > > + * measurement to a specific channel/pair (e.g. 100BASE-TX when MDI/MDI-X > > > > + * resolution is unknown). In that case, callers must use the LINK selector. > > > > > > The way I understand that is that PHYs will report either channel-specific values or > > > link-wide values. Is that correct or are both valid ? In BaseT1 this is the same thing, > > > but maybe for consistency, we should report either channel values or link-wide values ? > > > > for 100Base-T1 the LINK and channel-A selectors are effectively the > > same, since the PHY only has a single channel. In this case both are > > valid, and the driver will return the same answer for either request. > > > > I decided to expose both for consistency: > > - on one side, the driver already reports pair_A information for the > > cable test, so it makes sense to allow channel-A here as well; > > - on the other side, if a caller such as a generic link-status/health > > request asks for LINK, we can also provide that without special > > casing. > > > > So the driver just answers what it can. For this PHY, LINK and > > channel-A map to the same hardware register, and all other selectors > > return -EOPNOTSUPP. > > The document you referenced explicitly says it is for 100BASE-T1. Are > there other Open Alliance documents which extend the concept to -T2 > and -T4 links? Do you have access to -T2 or -T4 PHYs which implement > the concept for multiple pairs? So far I know, following T2/T4 PHYs support MSE: LAN8830, KSZ9131, LAN8831, LAN8840, LAN8841 DP83826*, DP83640, DP83867*, DP83869HM I have access at least to LAN8841. > I think it is good you are thinking about the API, how it could work > with -T2 and -T4, but do we need this complexity now? Hm.. I just fear to make same mistake as I did with SQI. So, I analyzed as many datasheets as possible. -- 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 |
> So far I know, following T2/T4 PHYs support MSE: > LAN8830, KSZ9131, LAN8831, LAN8840, LAN8841 > DP83826*, DP83640, DP83867*, DP83869HM O.K, that is plenty of justification. Thanks Andrew
© 2016 - 2025 Red Hat, Inc.