[PATCH v3] net: dsa: qca8k: fix led devicename when using external mdio bus

[PATCH v3] net: dsa: qca8k: fix led devicename when using external mdio bus

[George Moussalem via B4 Relay]

From: George Moussalem <george.moussalem@outlook.com>

The qca8k dsa switch can use either an external or internal mdio bus.
This depends on whether the mdio node is defined under the switch node
itself. Upon registering the internal mdio bus, the internal_mdio_bus
of the dsa switch is assigned to this bus. When an external mdio bus is
used, the driver still uses the internal_mdio_bus id which is used to
create the device names of the leds.
This leads to the leds being prefixed with '(efault)' as the
internal_mii_bus is null. So let's fix this by adding a null check and
use the devicename of the external bus instead when an external bus is
configured.

Fixes: 1e264f9d2918 ("net: dsa: qca8k: add LEDs basic support")
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
---
Resending this patch as v3 with an updated commit message. There was a
discussion on removing the notion of having an external and internal
bus which was never followed up on, yet the issue is still there.
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20250425151309.30493-1-kabel@kernel.org/

Changed in v3:
- Rebased on top of tree
- Updated commit message to reflect renaming of slave_mii_bus to
  internal_mdio_bus
- Link to v2: https://lore.kernel.org/r/20250425-qca8k-leds-v2-1-b638fd3885ca@outlook.com
Changes in v2:
- Fixed c/p error from older kernel version: slave_mii_bus was renamed
  to internal_mdio_bus
- Link to v1: https://lore.kernel.org/r/20250425-qca8k-leds-v1-1-6316ad36ad22@outlook.com
---
 drivers/net/dsa/qca/qca8k-leds.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/qca/qca8k-leds.c b/drivers/net/dsa/qca/qca8k-leds.c
index 43ac68052baf..ef496e345a4e 100644
--- a/drivers/net/dsa/qca/qca8k-leds.c
+++ b/drivers/net/dsa/qca/qca8k-leds.c
@@ -429,7 +429,8 @@ qca8k_parse_port_leds(struct qca8k_priv *priv, struct fwnode_handle *port, int p
 		init_data.fwnode = led;
 		init_data.devname_mandatory = true;
 		init_data.devicename = kasprintf(GFP_KERNEL, "%s:0%d",
-						 priv->internal_mdio_bus->id,
+						 priv->internal_mdio_bus ?
+						 priv->internal_mdio_bus->id : priv->bus->id,
 						 port_num);
 		if (!init_data.devicename) {
 			fwnode_handle_put(led);

---
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
change-id: 20260608-qca8k-leds-fix-e8b4d8feb47b

Best regards,
-- 
George Moussalem <george.moussalem@outlook.com>

Re: [PATCH v3] net: dsa: qca8k: fix led devicename when using external mdio bus

[Paolo Abeni]

On 6/8/26 9:22 AM, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
> 
> The qca8k dsa switch can use either an external or internal mdio bus.
> This depends on whether the mdio node is defined under the switch node
> itself. Upon registering the internal mdio bus, the internal_mdio_bus
> of the dsa switch is assigned to this bus. When an external mdio bus is
> used, the driver still uses the internal_mdio_bus id which is used to
> create the device names of the leds.
> This leads to the leds being prefixed with '(efault)' as the
> internal_mii_bus is null. So let's fix this by adding a null check and
> use the devicename of the external bus instead when an external bus is
> configured.
> 
> Fixes: 1e264f9d2918 ("net: dsa: qca8k: add LEDs basic support")
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
> Resending this patch as v3 with an updated commit message. There was a
> discussion on removing the notion of having an external and internal
> bus which was never followed up on, yet the issue is still there.
> Link: https://patchwork.kernel.org/project/netdevbpf/patch/20250425151309.30493-1-kabel@kernel.org/
> 
> Changed in v3:
> - Rebased on top of tree
> - Updated commit message to reflect renaming of slave_mii_bus to
>   internal_mdio_bus
> - Link to v2: https://lore.kernel.org/r/20250425-qca8k-leds-v2-1-b638fd3885ca@outlook.com
> Changes in v2:
> - Fixed c/p error from older kernel version: slave_mii_bus was renamed
>   to internal_mdio_bus
> - Link to v1: https://lore.kernel.org/r/20250425-qca8k-leds-v1-1-6316ad36ad22@outlook.com
> ---
>  drivers/net/dsa/qca/qca8k-leds.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/qca/qca8k-leds.c b/drivers/net/dsa/qca/qca8k-leds.c
> index 43ac68052baf..ef496e345a4e 100644
> --- a/drivers/net/dsa/qca/qca8k-leds.c
> +++ b/drivers/net/dsa/qca/qca8k-leds.c
> @@ -429,7 +429,8 @@ qca8k_parse_port_leds(struct qca8k_priv *priv, struct fwnode_handle *port, int p
>  		init_data.fwnode = led;
>  		init_data.devname_mandatory = true;
>  		init_data.devicename = kasprintf(GFP_KERNEL, "%s:0%d",
> -						 priv->internal_mdio_bus->id,
> +						 priv->internal_mdio_bus ?
> +						 priv->internal_mdio_bus->id : priv->bus->id,
>  						 port_num);
>  		if (!init_data.devicename) {
>  			fwnode_handle_put(led);
> 

@Andrew: are you ok with this? I *think* you may still have the same
concern WRT the previous iteration.

/P

Re: [PATCH v3] net: dsa: qca8k: fix led devicename when using external mdio bus

[Andrew Lunn]

On Mon, Jun 08, 2026 at 11:22:08AM +0400, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
> 
> The qca8k dsa switch can use either an external or internal mdio bus.
> This depends on whether the mdio node is defined under the switch node
> itself. Upon registering the internal mdio bus, the internal_mdio_bus
> of the dsa switch is assigned to this bus. When an external mdio bus is
> used, the driver still uses the internal_mdio_bus id which is used to
> create the device names of the leds.
> This leads to the leds being prefixed with '(efault)' as the
> internal_mii_bus is null. So let's fix this by adding a null check and
> use the devicename of the external bus instead when an external bus is
> configured.
> 
> Fixes: 1e264f9d2918 ("net: dsa: qca8k: add LEDs basic support")
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew