[PATCH net-next v2 0/3] net: phy: realtek: register hwmon thermal zones

[PATCH net-next v2 0/3] net: phy: realtek: register hwmon thermal zones

[Hleb Shauchenka via B4 Relay]

Let device-tree thermal zones use the temperature sensor of Realtek
PHYs. Patch 1 allows #thermal-sensor-cells in PHY nodes, patch 2 stops
failed MDIO reads from being reported as temperatures, and patch 3
registers the sensor with the thermal framework.

This series was prepared with AI assistance; each patch says how.

---
Changes in v2:
- Add #thermal-sensor-cells to the ethernet-phy binding (patch 1).
- Return MDIO read errors from the hwmon read (patch 2).
- Patch 3: name the mainline PHYs it affects and say that the RTL8261N
  test relied on OpenWrt's out-of-tree support. Code unchanged, so I
  kept Andrew's Reviewed-by.
- Link to v1: https://patch.msgid.link/20261103-realtek-hwmon-tz-v1-1-e672723c58cb@marleb.org

---
Hleb Shauchenka (3):
      dt-bindings: net: ethernet-phy: add property #thermal-sensor-cells
      net: phy: realtek: return MDIO read errors from hwmon
      net: phy: realtek: register hwmon thermal zones

 Documentation/devicetree/bindings/net/ethernet-phy.yaml |  6 ++++++
 drivers/net/phy/realtek/realtek_hwmon.c                 | 13 +++++++++----
 2 files changed, 15 insertions(+), 4 deletions(-)
---
base-commit: fa5196392691051963726787944db872420dfa75
change-id: 20261103-realtek-hwmon-tz-95237a921bf9

Best regards,
--  
Hleb Shauchenka <me@marleb.org>

[PATCH net-next v2 1/3] dt-bindings: net: ethernet-phy: add property #thermal-sensor-cells

[Hleb Shauchenka via B4 Relay]

From: Hleb Shauchenka <me@marleb.org>

The Aquantia and Marvell PHY drivers register their hwmon temperature
sensor with the thermal framework, and a following patch does the same
for Realtek PHYs, so a thermal zone can reference the PHY node through
thermal-sensors. That requires #thermal-sensor-cells in the PHY node,
which no PHY binding allows: dtbs_check rejects it under MDIO buses
whose PHY children use unevaluatedProperties: false, such as
realtek,rtl9301-mdio.

Allow it in the common PHY binding.

This patch was prepared with AI assistance (Claude Opus 5.5), after an
AI review of the previous posting pointed out the missing property.

Signed-off-by: Hleb Shauchenka <me@marleb.org>
---
 Documentation/devicetree/bindings/net/ethernet-phy.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index df50c4c33..e2e9e615f 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -269,6 +269,12 @@ properties:
       have to be placed on board. When omitted, the PHYs default will be left as
       is.
 
+  '#thermal-sensor-cells':
+    const: 0
+    description:
+      Present when the PHY has a temperature sensor that thermal zones can
+      reference.
+
   marvell,reg-init:
     $ref: /schemas/types.yaml#/definitions/uint32-matrix
     deprecated: true

-- 
2.56.0

Re: [PATCH net-next v2 1/3] dt-bindings: net: ethernet-phy: add property #thermal-sensor-cells

[Andrew Lunn]

On Sat, Nov 07, 2026 at 06:00:45PM +0100, Hleb Shauchenka via B4 Relay wrote:
> From: Hleb Shauchenka <me@marleb.org>
> 
> The Aquantia and Marvell PHY drivers register their hwmon temperature
> sensor with the thermal framework, and a following patch does the same
> for Realtek PHYs, so a thermal zone can reference the PHY node through
> thermal-sensors. That requires #thermal-sensor-cells in the PHY node,
> which no PHY binding allows: dtbs_check rejects it under MDIO buses
> whose PHY children use unevaluatedProperties: false, such as
> realtek,rtl9301-mdio.
> 
> Allow it in the common PHY binding.
> 
> This patch was prepared with AI assistance (Claude Opus 5.5), after an
> AI review of the previous posting pointed out the missing property.
> 

I would put that under the ---. We don't need it in the history. We
just want to know it to aid review.


    Andrew

---
pw-bot: cr

[PATCH net-next v2 2/3] net: phy: realtek: return MDIO read errors from hwmon

[Hleb Shauchenka via B4 Relay]

From: Hleb Shauchenka <me@marleb.org>

rtl822x_hwmon_read() masks or shifts the value returned by
phy_read_mmd() without checking it and returns success, so a failed
MDIO read is reported as a temperature: -EIO reads as -2.5 C and
-ETIMEDOUT as -55 C.

Return the error instead. Once the sensor feeds a thermal zone, the
thermal core then keeps its previous state rather than acting on a
bogus reading.

The problem was found by an AI review of the previous posting, and
this patch was prepared with AI assistance (Claude Opus 5.5). It is
build-tested only: I could not provoke a failed MDIO read on hardware.

Fixes: 33700ca45b7d ("net: phy: realtek: add hwmon support for temp sensor on RTL822x")
Signed-off-by: Hleb Shauchenka <me@marleb.org>
---
 drivers/net/phy/realtek/realtek_hwmon.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/realtek/realtek_hwmon.c b/drivers/net/phy/realtek/realtek_hwmon.c
index ac96e2d1e..b6b2806e2 100644
--- a/drivers/net/phy/realtek/realtek_hwmon.c
+++ b/drivers/net/phy/realtek/realtek_hwmon.c
@@ -30,13 +30,17 @@ static int rtl822x_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
 
 	switch (attr) {
 	case hwmon_temp_input:
-		raw = phy_read_mmd(phydev, MDIO_MMD_VEND2, RTL822X_VND2_TSRR) & 0x3ff;
-		*val = rtl822x_hwmon_get_temp(raw);
+		raw = phy_read_mmd(phydev, MDIO_MMD_VEND2, RTL822X_VND2_TSRR);
+		if (raw < 0)
+			return raw;
+		*val = rtl822x_hwmon_get_temp(raw & 0x3ff);
 		break;
 	case hwmon_temp_max:
 		/* Chip reduces speed to 1G if threshold is exceeded */
-		raw = phy_read_mmd(phydev, MDIO_MMD_VEND2, RTL822X_VND2_TSSR) >> 6;
-		*val = rtl822x_hwmon_get_temp(raw);
+		raw = phy_read_mmd(phydev, MDIO_MMD_VEND2, RTL822X_VND2_TSSR);
+		if (raw < 0)
+			return raw;
+		*val = rtl822x_hwmon_get_temp(raw >> 6);
 		break;
 	default:
 		return -EINVAL;

-- 
2.56.0

Re: [PATCH net-next v2 2/3] net: phy: realtek: return MDIO read errors from hwmon

[Andrew Lunn]

On Sat, Nov 07, 2026 at 06:00:46PM +0100, Hleb Shauchenka via B4 Relay wrote:
> From: Hleb Shauchenka <me@marleb.org>
> 
> rtl822x_hwmon_read() masks or shifts the value returned by
> phy_read_mmd() without checking it and returns success, so a failed
> MDIO read is reported as a temperature: -EIO reads as -2.5 C and
> -ETIMEDOUT as -55 C.
> 
> Return the error instead. Once the sensor feeds a thermal zone, the
> thermal core then keeps its previous state rather than acting on a
> bogus reading.
> 
> The problem was found by an AI review of the previous posting, and
> this patch was prepared with AI assistance (Claude Opus 5.5). It is
> build-tested only: I could not provoke a failed MDIO read on hardware.
> 
> Fixes: 33700ca45b7d ("net: phy: realtek: add hwmon support for temp sensor on RTL822x")

Fixes are not wanted when targeting net-next.

You need to decide, is this a bug which bothers people, so should be
for net, have a Fixes, tag and Cc: stable. Or it is a problem which
nobody cares about, so can be in net-next as just normal development
work.


    Andrew

---
pw-bot: cr

[PATCH net-next v2 3/3] net: phy: realtek: register hwmon thermal zones

[Hleb Shauchenka via B4 Relay]

From: Hleb Shauchenka <me@marleb.org>

The Realtek PHY hwmon device exposes the PHY temperature, but its
channel info lacks HWMON_C_REGISTER_TZ, so the hwmon core does not
register the sensor with the thermal framework and device-tree
thermal zones that reference the PHY cannot bind.

Set the flag, as the Aquantia PHY driver does. In mainline this
affects the PHYs whose hwmon device rtl822x_probe() registers, the
RTL8221B-VB-CG, RTL8221B-VM-CG and RTL8251B, when the device tree
describes them. The internal NBASE-T PHYs normally have no device
tree node, so the hwmon core registers no thermal zone for them.

I tested this on a Zyxel XGS1250-12 B1 with OpenWrt's Linux 6.18.55,
where OpenWrt's out-of-tree RTL8261N support calls
rtl822x_hwmon_init(): the three PHY thermal zones register, and an
emulated 85 C reading on one of them (CONFIG_THERMAL_EMULATION)
switches the fan on through an 80 C trip and off again once cleared.

This patch was prepared with AI assistance (Claude Opus 5.5 and Sol
6.1), which also helped investigate the problem and run the tests on
my switch.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Hleb Shauchenka <me@marleb.org>
---
 drivers/net/phy/realtek/realtek_hwmon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/realtek/realtek_hwmon.c b/drivers/net/phy/realtek/realtek_hwmon.c
index b6b2806e2..021064edd 100644
--- a/drivers/net/phy/realtek/realtek_hwmon.c
+++ b/drivers/net/phy/realtek/realtek_hwmon.c
@@ -55,6 +55,7 @@ static const struct hwmon_ops rtl822x_hwmon_ops = {
 };
 
 static const struct hwmon_channel_info * const rtl822x_hwmon_info[] = {
+	HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ),
 	HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_MAX),
 	NULL
 };

-- 
2.56.0

Re: [PATCH net-next v2 3/3] net: phy: realtek: register hwmon thermal zones

[Andrew Lunn]

> I tested this on a Zyxel XGS1250-12 B1 with OpenWrt's Linux 6.18.55,
> where OpenWrt's out-of-tree RTL8261N support calls
> rtl822x_hwmon_init():

Mainline does not care about out of tree code.

Does this have any value for Mainline?

If not, drop it.

Or bring the out of tree code into Mainline.

	Andrew

Re: [PATCH net-next v2 3/3] net: phy: realtek: register hwmon thermal zones

[Hleb Shauchenka]

On Sat, Nov 07, 2026 at 06:22:36PM +0100, Andrew Lunn wrote:
 > Does this have any value for Mainline?

No. Its only user is OpenWrt's out-of-tree RTL8261N support. I will drop 
it and patch 1.

v3 will be patch 2 alone without the Fixes tag and with the AI note 
below the ---.

Hleb

On 07/11/2026 18:22, Andrew Lunn wrote:
>> I tested this on a Zyxel XGS1250-12 B1 with OpenWrt's Linux 6.18.55,
>> where OpenWrt's out-of-tree RTL8261N support calls
>> rtl822x_hwmon_init():
> Mainline does not care about out of tree code.
>
> Does this have any value for Mainline?
>
> If not, drop it.
>
> Or bring the out of tree code into Mainline.
>
> 	Andrew