Thread (123 messages) 123 messages, 7 authors, 2022-07-26

Re: [PATCH net-next v3 07/47] net: phy: Add support for rate adaptation

From: Andrew Lunn <andrew@lunn.ch>
Date: 2022-07-16 19:39:58
Also in: lkml, netdev

quoted hunk ↗ jump to hunk
 drivers/net/phy/phy.c | 21 +++++++++++++++++++++
 include/linux/phy.h   | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 59 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 8d3ee3a6495b..cf4a8b055a42 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -114,6 +114,27 @@ void phy_print_status(struct phy_device *phydev)
 }
 EXPORT_SYMBOL(phy_print_status);
 
+/**
+ * phy_get_rate_adaptation - determine if rate adaptation is supported
+ * @phydev: The phy device to return rate adaptation for
+ * @iface: The interface mode to use
+ *
+ * This determines the type of rate adaptation (if any) that @phy supports
+ * using @iface. @iface may be %PHY_INTERFACE_MODE_NA to determine if any
+ * interface supports rate adaptation.
+ *
+ * Return: The type of rate adaptation @phy supports for @iface, or
+ *         %RATE_ADAPT_NONE.
+ */
+enum rate_adaptation phy_get_rate_adaptation(struct phy_device *phydev,
+					     phy_interface_t iface)
+{
+	if (phydev->drv->get_rate_adaptation)
+		return phydev->drv->get_rate_adaptation(phydev, iface);
It is normal that any call into the driver is performed with the
phydev->lock held.
quoted hunk ↗ jump to hunk
 #define PHY_INIT_TIMEOUT	100000
 #define PHY_FORCE_TIMEOUT	10
@@ -570,6 +588,7 @@ struct macsec_ops;
  * @lp_advertising: Current link partner advertised linkmodes
  * @eee_broken_modes: Energy efficient ethernet modes which should be prohibited
  * @autoneg: Flag autoneg being used
+ * @rate_adaptation: Current rate adaptation mode
  * @link: Current link state
  * @autoneg_complete: Flag auto negotiation of the link has completed
  * @mdix: Current crossover
@@ -637,6 +656,8 @@ struct phy_device {
 	unsigned irq_suspended:1;
 	unsigned irq_rerun:1;
 
+	enum rate_adaptation rate_adaptation;
It is not clear what the locking is on this member. Is it only safe to
access it during the adjust_link callback, when it is guaranteed that
the phydev->lock is held, so the value is consistent? Or is the MAC
allowed to access this at other times?

	Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help