[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240204-unify-c22-c45-scan-error-handling-v2-0-0273623f9c57@lunn.ch>
Date: Sun, 04 Feb 2024 17:14:13 -0600
From: Andrew Lunn <andrew@...n.ch>
To: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>
Cc: netdev@...r.kernel.org, Tim Menninger <tmenninger@...estorage.com>,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <florian.fainelli@...adcom.com>
Subject: [PATCH net-next v2 0/2] Unify C22 and C45 error handling during
bus enumeration
When enumerating an MDIO bus, an MDIO bus driver can return -ENODEV to
a C22 read transaction to indicate there is no device at that address
on the bus. Enumeration will then continue with the next address on
the bus.
Modify C45 enumeration so that it also accepts -ENODEV and moves to
the next address on the bus, rather than consider -ENODEV as a fatal
error.
Convert the mv88e6xxx driver to return -ENODEV rather than 0xffff on
read for families which do not support C45 bus transactions. This is
more efficient, since enumeration will scan multiple devices at one
address when 0xffff is returned, where as -EONDEV immediately jumps to
the next address on the bus.
Signed-off-by: Andrew Lunn <andrew@...n.ch>
---
Changes in v2:
- C44 -> C45 Typo
- Only return -ENODEV for unimplemented C45 read.
- Link to v1: https://lore.kernel.org/r/20240203-unify-c22-c45-scan-error-handling-v1-0-8aa9fa3c4fca@lunn.ch
---
Andrew Lunn (2):
net: phy: c45 scanning: Don't consider -ENODEV fatal
net: dsa: mv88e6xxx: Return -ENODEV when C45 not supported
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
drivers/net/phy/phy_device.c | 8 ++++++--
2 files changed, 7 insertions(+), 3 deletions(-)
---
base-commit: d6aa8e0aa605a6baba08220e4a83fa2619a4c4d7
change-id: 20240203-unify-c22-c45-scan-error-handling-8012bb69bbf9
Best regards,
--
Andrew Lunn <andrew@...n.ch>
Powered by blists - more mailing lists