[PATCH net-next v3 0/3] net: dsa: realtek: enable RTL8365MB power supplies

[PATCH net-next v3 0/3] net: dsa: realtek: enable RTL8365MB power supplies

[Oleksij Rempel]

The RTL8365MB family has several external power rails (analog, digital I/O
and PLL supplies) that on some boards are gated by regulators. Until now the
driver assumed they were always on, so it could not be used on designs that
keep these rails software-controlled.

This series adds a device-tree description for those supplies and enables
them in the driver before the chip is accessed:

The supplies are optional: boards that hard-wire the rails work unchanged

Ahmad Fatoum (1):
  net: dsa: realtek: rtl83xx: add support for enabling supplies

Oleksij Rempel (2):
  dt-bindings: net: dsa: realtek: add RTL8365MB power supplies
  net: dsa: realtek: rtl83xx: use dev_err_cast_probe() for reset GPIO

 .../devicetree/bindings/net/dsa/realtek.yaml  | 33 +++++++++++++++++++
 drivers/net/dsa/realtek/realtek.h             |  3 ++
 drivers/net/dsa/realtek/rtl8365mb_main.c      |  6 ++++
 drivers/net/dsa/realtek/rtl83xx.c             | 23 ++++++++++---
 4 files changed, 60 insertions(+), 5 deletions(-)

--
2.47.3

[PATCH net-next v3 1/3] dt-bindings: net: dsa: realtek: add RTL8365MB power supplies

[Oleksij Rempel]

Document the RTL8365MB power rails as optional supplies. They are optional
because the rails are often always-on; some designs break them out for
granular hwmon monitoring and regulator control.

They are scoped to realtek,rtl8365mb: different Realtek switch families use
different power-rail naming schemes, so these rails do not apply to other
families such as realtek,rtl8366rb (VDDA/VDD_CORE/VDDIO/...).

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
Changes since v2:
- Move the *-supply properties to the top level; if:/then: now only forbids
  them on non-rtl8365mb compatibles (Krzysztof Kozlowski).
---
 .../devicetree/bindings/net/dsa/realtek.yaml  | 33 +++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
index 473facd87a62..b7bb60af623c 100644
--- a/Documentation/devicetree/bindings/net/dsa/realtek.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
@@ -8,6 +8,20 @@ title: Realtek switches for unmanaged switches
 
 allOf:
   - $ref: dsa.yaml#/$defs/ethernet-ports
+  - if:
+      not:
+        properties:
+          compatible:
+            contains:
+              const: realtek,rtl8365mb
+    then:
+      properties:
+        avddh-supply: false
+        avddl-supply: false
+        dvddio-supply: false
+        dvddio1-supply: false
+        dvddl-supply: false
+        pllvddl-supply: false
 
 maintainers:
   - Linus Walleij <linusw@kernel.org>
@@ -62,6 +76,24 @@ properties:
   resets:
     maxItems: 1
 
+  avddh-supply:
+    description: AVDDH high-voltage analog supply.
+
+  avddl-supply:
+    description: AVDDL low-voltage analog supply.
+
+  dvddio-supply:
+    description: DVDDIO digital I/O supply.
+
+  dvddio1-supply:
+    description: DVDDIO_1 secondary digital I/O supply for the RGMII bank.
+
+  dvddl-supply:
+    description: DVDDL digital core supply.
+
+  pllvddl-supply:
+    description: PLLVDDL PLL analog supply.
+
   realtek,disable-leds:
     type: boolean
     description: |
@@ -243,6 +275,7 @@ examples:
     platform {
             ethernet-switch {
                     compatible = "realtek,rtl8365mb";
+                    avddh-supply = <&avddh>;
                     mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
                     mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
                     reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
-- 
2.47.3

[PATCH net-next v3 2/3] net: dsa: realtek: rtl83xx: add support for enabling supplies

[Oleksij Rempel]

From: Ahmad Fatoum <a.fatoum@pengutronix.de>

The power supplies powering the IC may not necessarily be enabled by the
time the driver probes.  The binding describes the power rails, so enable
them at probe with devm_regulator_bulk_get_enable(), before the reset line
is requested and driven, so the chip is powered before its pins are driven.

Boards that do not describe these supplies fall back to dummy regulators
(with a "supply not found" warning) and keep working as before.

A board that describes supplies but no reset line still needs to wait for
the chip to boot before the first register access, so apply the existing
start delay in that case too.

Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
Anticipated reviewer questions:

Q: Why devm_regulator_bulk_get_enable() rather than a per-supply loop over
   devm_regulator_get_enable_optional()?
A: regulator_get_optional() must only be used for supplies that may be
   physically absent; these rails are always physically present, so the
   normal (non-optional) get is the correct API.  Boards that do not
   describe the rails fall back to dummy regulators - a dummy-supply
   message, not a functional change or a regression; many systems boot
   with such messages.  Hiding the message with a per-supply _optional
   loop would be a buggy use of the API.

Q: On unbind or probe failure the devres unwind disables the rails after
   the reset GPIO/control have been released, leaving the chip unpowered
   with its reset pin still driven by the SoC - back-powering.  Should a
   devm_add_action_or_reset() assert reset before the rails drop?
A: Not in this patch.  Asserting reset on teardown reopens the decision of
   commit 4f580e9aced1 ("net: dsa: realtek: do not assert reset on
   remove"), which intentionally stopped doing it, and would have to be
   gated so rtl8366rb - the chip that commit was about - is not changed.
   It is also only a partial mitigation: the SoC keeps driving the
   MDIO/RGMII pins regardless of the reset state.  And these rails are
   usually fixed/always-on, so disabling them is a no-op; the window only
   exists on a design that genuinely gates them, where power-down
   sequencing is a board-level concern.  Teardown sequencing is out of
   scope here and, if needed, belongs in a separate, dedicated change.

Q: var->num_supplies is a per-variant constant (6 for every rtl8365mb), so
   the start delay also fires on boards that describe no rails and fall
   back to dummy regulators, where nothing was really powered.
A: Intentional.  After enabling the rails - real or dummy - the driver has
   no way to know the chip is ready, so it waits REALTEK_HW_START_DELAY
   before the first register access.  The delay is harmless and only
   closes a race; a variant that declares no supplies (num_supplies == 0)
   is unaffected.

Q: Why only rtl8365mb_variant, not rtl8366rb?
A: The rail list is taken from the RTL8365MB datasheet.  rtl8366rb has a
   different set and no in-tree board describes them, so it declares none
   (num_supplies stays 0) and its probe/teardown are unchanged.  The
   companion dt-bindings patch likewise restricts the *-supply properties
   to the realtek,rtl8365mb compatible.

Changes since v2:
- No change

Changes since v1:
- Enable the rails with devm_regulator_bulk_get_enable() instead of a
  per-supply loop over devm_regulator_get_enable_optional(); the optional
  API is only for physically-absent supplies (Mark Brown), and undescribed
  rails fall back to dummy regulators, which is expected rather than a
  regression.
- Describe the rails as a counted array (num_supplies) rather than a
  NULL-terminated list, matching the bulk API.
---
 drivers/net/dsa/realtek/realtek.h        |  3 +++
 drivers/net/dsa/realtek/rtl8365mb_main.c |  6 ++++++
 drivers/net/dsa/realtek/rtl83xx.c        | 17 ++++++++++++++++-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/realtek/realtek.h b/drivers/net/dsa/realtek/realtek.h
index 6e0148cee8d8..75a127545e5d 100644
--- a/drivers/net/dsa/realtek/realtek.h
+++ b/drivers/net/dsa/realtek/realtek.h
@@ -166,6 +166,9 @@ struct realtek_variant {
 	u8 cmd_read;
 	u8 cmd_write;
 	size_t chip_data_sz;
+	/* Regulator supplies to enable at probe, or NULL */
+	const char *const *supplies;
+	int num_supplies;
 };
 
 /* RTL8366 library helpers */
diff --git a/drivers/net/dsa/realtek/rtl8365mb_main.c b/drivers/net/dsa/realtek/rtl8365mb_main.c
index 728231d8f94c..4c305756116c 100644
--- a/drivers/net/dsa/realtek/rtl8365mb_main.c
+++ b/drivers/net/dsa/realtek/rtl8365mb_main.c
@@ -3334,6 +3334,10 @@ static const struct realtek_ops rtl8365mb_ops = {
 	.phy_write = rtl8365mb_phy_write,
 };
 
+static const char *const rtl8365mb_supplies[] = {
+	"avddh", "avddl", "dvddio", "dvddio1", "dvddl", "pllvddl",
+};
+
 const struct realtek_variant rtl8365mb_variant = {
 	.ds_ops = &rtl8365mb_switch_ops,
 	.ops = &rtl8365mb_ops,
@@ -3342,6 +3346,8 @@ const struct realtek_variant rtl8365mb_variant = {
 	.cmd_read = 0xb9,
 	.cmd_write = 0xb8,
 	.chip_data_sz = sizeof(struct rtl8365mb),
+	.supplies = rtl8365mb_supplies,
+	.num_supplies = ARRAY_SIZE(rtl8365mb_supplies),
 };
 
 static const struct of_device_id rtl8365mb_of_match[] = {
diff --git a/drivers/net/dsa/realtek/rtl83xx.c b/drivers/net/dsa/realtek/rtl83xx.c
index a96beea72ef5..d6d243131fd2 100644
--- a/drivers/net/dsa/realtek/rtl83xx.c
+++ b/drivers/net/dsa/realtek/rtl83xx.c
@@ -2,6 +2,7 @@
 
 #include <linux/module.h>
 #include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
 #include <linux/of_mdio.h>
 #include <linux/if_bridge.h>
 #include <linux/etherdevice.h>
@@ -195,7 +196,16 @@ rtl83xx_probe(struct device *dev,
 	priv->leds_disabled = of_property_read_bool(dev->of_node,
 						    "realtek,disable-leds");
 
-	/* TODO: if power is software controlled, set up any regulators here */
+	/* Enable the supplies before the reset line is requested and driven,
+	 * so the chip is powered before its pins are driven.
+	 */
+	if (var->num_supplies) {
+		ret = devm_regulator_bulk_get_enable(dev, var->num_supplies,
+						     var->supplies);
+		if (ret)
+			return dev_err_ptr_probe(dev, ret, "failed to enable supplies\n");
+	}
+
 	priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
 	if (IS_ERR(priv->reset_ctl))
 		return dev_err_cast_probe(dev, priv->reset_ctl,
@@ -216,6 +226,11 @@ rtl83xx_probe(struct device *dev,
 		rtl83xx_reset_deassert(priv);
 		msleep(REALTEK_HW_START_DELAY);
 		dev_dbg(dev, "deasserted RESET\n");
+	} else if (var->num_supplies) {
+		/* Powered but no reset line: still wait for the chip to boot
+		 * before the first register access.
+		 */
+		msleep(REALTEK_HW_START_DELAY);
 	}
 
 	return priv;
-- 
2.47.3

[PATCH net-next v3 3/3] net: dsa: realtek: rtl83xx: use dev_err_cast_probe() for reset GPIO

[Oleksij Rempel]

Replace the open-coded dev_err() + ERR_CAST() on the reset GPIO error
path with dev_err_cast_probe(), matching the reset controller above and
staying quiet on -EPROBE_DEFER.

Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
Changes since v2:
- Added this patch
---
 drivers/net/dsa/realtek/rtl83xx.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/dsa/realtek/rtl83xx.c b/drivers/net/dsa/realtek/rtl83xx.c
index d6d243131fd2..8121ec12fd8b 100644
--- a/drivers/net/dsa/realtek/rtl83xx.c
+++ b/drivers/net/dsa/realtek/rtl83xx.c
@@ -212,10 +212,8 @@ rtl83xx_probe(struct device *dev,
 					  "failed to get reset control\n");
 
 	priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
-	if (IS_ERR(priv->reset)) {
-		dev_err(dev, "failed to get RESET GPIO\n");
-		return ERR_CAST(priv->reset);
-	}
+	if (IS_ERR(priv->reset))
+		return dev_err_cast_probe(dev, priv->reset, "failed to get RESET GPIO\n");
 
 	dev_set_drvdata(dev, priv);
 
-- 
2.47.3

Re: [PATCH net-next v3 3/3] net: dsa: realtek: rtl83xx: use dev_err_cast_probe() for reset GPIO

[Luiz Angelo Daros de Luca]

> Replace the open-coded dev_err() + ERR_CAST() on the reset GPIO error
> path with dev_err_cast_probe(), matching the reset controller above and
> staying quiet on -EPROBE_DEFER.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> Changes since v2:
> - Added this patch
> ---
>  drivers/net/dsa/realtek/rtl83xx.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/dsa/realtek/rtl83xx.c b/drivers/net/dsa/realtek/rtl83xx.c
> index d6d243131fd2..8121ec12fd8b 100644
> --- a/drivers/net/dsa/realtek/rtl83xx.c
> +++ b/drivers/net/dsa/realtek/rtl83xx.c
> @@ -212,10 +212,8 @@ rtl83xx_probe(struct device *dev,
>                                           "failed to get reset control\n");
>
>         priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> -       if (IS_ERR(priv->reset)) {
> -               dev_err(dev, "failed to get RESET GPIO\n");
> -               return ERR_CAST(priv->reset);
> -       }
> +       if (IS_ERR(priv->reset))
> +               return dev_err_cast_probe(dev, priv->reset, "failed to get RESET GPIO\n");
>
>         dev_set_drvdata(dev, priv);
>
> --
> 2.47.3
>

Nice!

Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>

Re: [PATCH net-next v3 1/3] dt-bindings: net: dsa: realtek: add RTL8365MB power supplies

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]

On Mon, Aug 31, 2026 at 02:36:35PM +0200, Oleksij Rempel wrote:
> Document the RTL8365MB power rails as optional supplies. They are optional
> because the rails are often always-on; some designs break them out for
> granular hwmon monitoring and regulator control.
> 
> They are scoped to realtek,rtl8365mb: different Realtek switch families use
> different power-rail naming schemes, so these rails do not apply to other
> families such as realtek,rtl8366rb (VDDA/VDD_CORE/VDDIO/...).
> 
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

> ---
> Changes since v2:
> - Move the *-supply properties to the top level; if:/then: now only forbids
>   them on non-rtl8365mb compatibles (Krzysztof Kozlowski).
> ---
>  .../devicetree/bindings/net/dsa/realtek.yaml  | 33 +++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
> index 473facd87a62..b7bb60af623c 100644
> --- a/Documentation/devicetree/bindings/net/dsa/realtek.yaml
> +++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml
> @@ -8,6 +8,20 @@ title: Realtek switches for unmanaged switches
>  
>  allOf:
>    - $ref: dsa.yaml#/$defs/ethernet-ports
> +  - if:
> +      not:
> +        properties:
> +          compatible:
> +            contains:
> +              const: realtek,rtl8365mb
> +    then:
> +      properties:
> +        avddh-supply: false
> +        avddl-supply: false
> +        dvddio-supply: false
> +        dvddio1-supply: false
> +        dvddl-supply: false
> +        pllvddl-supply: false
>  
>  maintainers:
>    - Linus Walleij <linusw@kernel.org>
> @@ -62,6 +76,24 @@ properties:
>    resets:
>      maxItems: 1
>  
> +  avddh-supply:
> +    description: AVDDH high-voltage analog supply.
> +
> +  avddl-supply:
> +    description: AVDDL low-voltage analog supply.
> +
> +  dvddio-supply:
> +    description: DVDDIO digital I/O supply.
> +
> +  dvddio1-supply:
> +    description: DVDDIO_1 secondary digital I/O supply for the RGMII bank.
> +
> +  dvddl-supply:
> +    description: DVDDL digital core supply.
> +
> +  pllvddl-supply:
> +    description: PLLVDDL PLL analog supply.
> +
>    realtek,disable-leds:
>      type: boolean
>      description: |
> @@ -243,6 +275,7 @@ examples:
>      platform {
>              ethernet-switch {
>                      compatible = "realtek,rtl8365mb";
> +                    avddh-supply = <&avddh>;
>                      mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
>                      mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
>                      reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> -- 
> 2.47.3
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH net-next v3 0/3] net: dsa: realtek: enable RTL8365MB power supplies

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 31 Aug 2026 14:36:34 +0200 you wrote:
> The RTL8365MB family has several external power rails (analog, digital I/O
> and PLL supplies) that on some boards are gated by regulators. Until now the
> driver assumed they were always on, so it could not be used on designs that
> keep these rails software-controlled.
> 
> This series adds a device-tree description for those supplies and enables
> them in the driver before the chip is accessed:
> 
> [...]

Here is the summary with links:
  - [net-next,v3,1/3] dt-bindings: net: dsa: realtek: add RTL8365MB power supplies
    https://git.kernel.org/netdev/net-next/c/f4d025418721
  - [net-next,v3,2/3] net: dsa: realtek: rtl83xx: add support for enabling supplies
    https://git.kernel.org/netdev/net-next/c/f82364499682
  - [net-next,v3,3/3] net: dsa: realtek: rtl83xx: use dev_err_cast_probe() for reset GPIO
    https://git.kernel.org/netdev/net-next/c/bd6b764f08de

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html