With this patch series we provide EEE support for KSZ9477 family of switches.
According to my tests, on a system with KSZ8563 switch and 100Mbit idle link,
we consume 0,192W less power per port if EEE is enabled.
Oleksij Rempel (4):
net: phy: add driver specific get/set_eee support
net: phy: micrel: add EEE configuration support for KSZ9477 variants
of PHYs
net: phy: micrel: disable 1000Mbit EEE support if 1000Mbit is not
supported
net: dsa: microchip: enable EEE support
drivers/net/dsa/microchip/ksz_common.c | 35 ++++++++
drivers/net/phy/micrel.c | 115 ++++++++++++++++++++++++-
drivers/net/phy/phy.c | 6 ++
include/linux/phy.h | 5 ++
4 files changed, 160 insertions(+), 1 deletion(-)
--
2.30.2
Some of KSZ9477 family switches provides EEE support. To enable it, we
just need to register set_mac_eee/set_mac_eee handlers and validate
supported chip version and port.
Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/dsa/microchip/ksz_common.c | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 5e1e5bd555d2..2f1f71b3be86 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -2645,6 +2645,39 @@ static int ksz_max_mtu(struct dsa_switch *ds, int port)
return -EOPNOTSUPP;
}
+static int ksz_validate_eee(struct dsa_switch *ds, int port)
+{
+ struct ksz_device *dev = ds->priv;
+
+ if (!dev->info->internal_phy[port])
+ return -EOPNOTSUPP;
+
+ switch (dev->chip_id) {
+ case KSZ8563_CHIP_ID:
+ case KSZ9477_CHIP_ID:
+ case KSZ9563_CHIP_ID:
+ case KSZ9567_CHIP_ID:
+ case KSZ9893_CHIP_ID:
+ case KSZ9896_CHIP_ID:
+ case KSZ9897_CHIP_ID:
+ return 0;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static int ksz_get_mac_eee(struct dsa_switch *ds, int port,
+ struct ethtool_eee *e)
+{
+ return ksz_validate_eee(ds, port);
+}
+
+static int ksz_set_mac_eee(struct dsa_switch *ds, int port,
+ struct ethtool_eee *e)
+{
+ return ksz_validate_eee(ds, port);
+}
+
static void ksz_set_xmii(struct ksz_device *dev, int port,
phy_interface_t interface)
{
@@ -3006,6 +3039,8 @@ static const struct dsa_switch_ops ksz_switch_ops = {
.port_hwtstamp_set = ksz_hwtstamp_set,
.port_txtstamp = ksz_port_txtstamp,
.port_rxtstamp = ksz_port_rxtstamp,
+ .get_mac_eee = ksz_get_mac_eee,
+ .set_mac_eee = ksz_set_mac_eee,
};
struct ksz_device *ksz_switch_alloc(struct device *base, void *priv)
--
2.30.2
KSZ9477 variants of PHYs are not completely compatible with generic
phy_ethtool_get/set_eee() handlers. For example MDIO_PCS_EEE_ABLE acts
like a mirror of MDIO_AN_EEE_ADV register. If MDIO_AN_EEE_ADV set to 0,
MDIO_PCS_EEE_ABLE will be 0 too. It means, if we do
"ethtool --set-eee lan2 eee off", we won't be able to enable it again.
With this patch, instead of reading MDIO_PCS_EEE_ABLE register, the
driver will provide proper abilities.
Signed-off-by: Oleksij Rempel <[email protected]>
---
drivers/net/phy/micrel.c | 92 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index d5b80c31ab91..099f1e83c08c 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -1370,6 +1370,96 @@ static int ksz9131_config_aneg(struct phy_device *phydev)
return genphy_config_aneg(phydev);
}
+static int ksz9477_get_eee_caps(struct phy_device *phydev,
+ struct ethtool_eee *data)
+{
+ int val;
+
+ /* At least on KSZ8563 (which has same PHY_ID as KSZ9477), the
+ * MDIO_PCS_EEE_ABLE register is a mirror of MDIO_AN_EEE_ADV register.
+ * So, we need to provide this information by driver.
+ */
+ data->supported = SUPPORTED_100baseT_Full;
+
+ /* KSZ8563 is able to advertise not supported MDIO_EEE_1000T.
+ * We need to test if the PHY is 1Gbit capable.
+ */
+ val = phy_read(phydev, MII_BMSR);
+ if (val < 0)
+ return val;
+
+ if (val & BMSR_ERCAP)
+ data->supported |= SUPPORTED_1000baseT_Full;
+
+ return 0;
+}
+
+static int ksz9477_get_eee(struct phy_device *phydev, struct ethtool_eee *data)
+{
+ int val;
+
+ val = ksz9477_get_eee_caps(phydev, data);
+ if (val)
+ return val;
+
+ /* Get advertisement EEE */
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV);
+ if (val < 0)
+ return val;
+ data->advertised = mmd_eee_adv_to_ethtool_adv_t(val);
+ data->eee_enabled = !!data->advertised;
+
+ /* Get LP advertisement EEE */
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
+ if (val < 0)
+ return val;
+ data->lp_advertised = mmd_eee_adv_to_ethtool_adv_t(val);
+
+ data->eee_active = !!(data->advertised & data->lp_advertised);
+
+ return 0;
+}
+
+static int ksz9477_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
+{
+ int old_adv, adv = 0, ret;
+
+ ret = ksz9477_get_eee_caps(phydev, data);
+ if (ret)
+ return ret;
+
+ old_adv = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV);
+ if (old_adv < 0)
+ return old_adv;
+
+ if (data->eee_enabled) {
+ if (!data->advertised)
+ adv = ethtool_adv_to_mmd_eee_adv_t(data->supported);
+ else
+ adv = ethtool_adv_to_mmd_eee_adv_t(data->advertised &
+ data->supported);
+ /* Mask prohibited EEE modes */
+ adv &= ~phydev->eee_broken_modes;
+ }
+
+ if (old_adv != adv) {
+ ret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, adv);
+ if (ret < 0)
+ return ret;
+
+ /* Restart autonegotiation so the new modes get sent to the
+ * link partner.
+ */
+ if (phydev->autoneg == AUTONEG_ENABLE) {
+ ret = phy_restart_aneg(phydev);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
#define KSZ8873MLL_GLOBAL_CONTROL_4 0x06
#define KSZ8873MLL_GLOBAL_CONTROL_4_DUPLEX BIT(6)
#define KSZ8873MLL_GLOBAL_CONTROL_4_SPEED BIT(4)
@@ -3422,6 +3512,8 @@ static struct phy_driver ksphy_driver[] = {
.handle_interrupt = kszphy_handle_interrupt,
.suspend = genphy_suspend,
.resume = genphy_resume,
+ .get_eee = ksz9477_get_eee,
+ .set_eee = ksz9477_set_eee,
} };
module_phy_driver(ksphy_driver);
--
2.30.2
On 1/19/23 05:18, Oleksij Rempel wrote:
> KSZ9477 variants of PHYs are not completely compatible with generic
> phy_ethtool_get/set_eee() handlers. For example MDIO_PCS_EEE_ABLE acts
> like a mirror of MDIO_AN_EEE_ADV register. If MDIO_AN_EEE_ADV set to 0,
> MDIO_PCS_EEE_ABLE will be 0 too. It means, if we do
> "ethtool --set-eee lan2 eee off", we won't be able to enable it again.
>
> With this patch, instead of reading MDIO_PCS_EEE_ABLE register, the
> driver will provide proper abilities.
We have hooks in place already for PHY drivers with the form of the
read_mmd and write_mmd callbacks, did this somehow not work for you?
Below is an example:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb
(here the register location is non-standard but the bit definitions
within that register are following the standard).
--
Florian
On Thu, Jan 19, 2023 at 11:25:42AM -0800, Florian Fainelli wrote:
> On 1/19/23 05:18, Oleksij Rempel wrote:
> > KSZ9477 variants of PHYs are not completely compatible with generic
> > phy_ethtool_get/set_eee() handlers. For example MDIO_PCS_EEE_ABLE acts
> > like a mirror of MDIO_AN_EEE_ADV register. If MDIO_AN_EEE_ADV set to 0,
> > MDIO_PCS_EEE_ABLE will be 0 too. It means, if we do
> > "ethtool --set-eee lan2 eee off", we won't be able to enable it again.
> >
> > With this patch, instead of reading MDIO_PCS_EEE_ABLE register, the
> > driver will provide proper abilities.
>
> We have hooks in place already for PHY drivers with the form of the read_mmd
> and write_mmd callbacks, did this somehow not work for you?
>
> Below is an example:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb
>
> (here the register location is non-standard but the bit definitions within
> that register are following the standard).
It will work for this PHY, but not allow to complete support for AR8035.
AR8035 provides support for "SmartEEE" where tx_lpi_enabled and
tx_lpi_timer are optionally handled by the PHY, not by MAC.
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On 1/19/2023 9:55 PM, Oleksij Rempel wrote:
> On Thu, Jan 19, 2023 at 11:25:42AM -0800, Florian Fainelli wrote:
>> On 1/19/23 05:18, Oleksij Rempel wrote:
>>> KSZ9477 variants of PHYs are not completely compatible with generic
>>> phy_ethtool_get/set_eee() handlers. For example MDIO_PCS_EEE_ABLE acts
>>> like a mirror of MDIO_AN_EEE_ADV register. If MDIO_AN_EEE_ADV set to 0,
>>> MDIO_PCS_EEE_ABLE will be 0 too. It means, if we do
>>> "ethtool --set-eee lan2 eee off", we won't be able to enable it again.
>>>
>>> With this patch, instead of reading MDIO_PCS_EEE_ABLE register, the
>>> driver will provide proper abilities.
>>
>> We have hooks in place already for PHY drivers with the form of the read_mmd
>> and write_mmd callbacks, did this somehow not work for you?
>>
>> Below is an example:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb
>>
>> (here the register location is non-standard but the bit definitions within
>> that register are following the standard).
>
> It will work for this PHY, but not allow to complete support for AR8035.
> AR8035 provides support for "SmartEEE" where tx_lpi_enabled and
> tx_lpi_timer are optionally handled by the PHY, not by MAC.
Not sure I understand your reply here, this would appear to be a
limitation that exists regardless of the current API defined, does that
mean that you can make use of the phy_driver::{read,write}_mmd function
calls and you will make a v2 that uses them, or something else entirely?
--
Florian
On Fri, Jan 20, 2023 at 09:58:05AM -0800, Florian Fainelli wrote:
>
>
> On 1/19/2023 9:55 PM, Oleksij Rempel wrote:
> > On Thu, Jan 19, 2023 at 11:25:42AM -0800, Florian Fainelli wrote:
> > > On 1/19/23 05:18, Oleksij Rempel wrote:
> > > > KSZ9477 variants of PHYs are not completely compatible with generic
> > > > phy_ethtool_get/set_eee() handlers. For example MDIO_PCS_EEE_ABLE acts
> > > > like a mirror of MDIO_AN_EEE_ADV register. If MDIO_AN_EEE_ADV set to 0,
> > > > MDIO_PCS_EEE_ABLE will be 0 too. It means, if we do
> > > > "ethtool --set-eee lan2 eee off", we won't be able to enable it again.
> > > >
> > > > With this patch, instead of reading MDIO_PCS_EEE_ABLE register, the
> > > > driver will provide proper abilities.
> > >
> > > We have hooks in place already for PHY drivers with the form of the read_mmd
> > > and write_mmd callbacks, did this somehow not work for you?
> > >
> > > Below is an example:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d88fd1b546ff19c8040cfaea76bf16aed1c5a0bb
> > >
> > > (here the register location is non-standard but the bit definitions within
> > > that register are following the standard).
> >
> > It will work for this PHY, but not allow to complete support for AR8035.
> > AR8035 provides support for "SmartEEE" where tx_lpi_enabled and
> > tx_lpi_timer are optionally handled by the PHY, not by MAC.
>
> Not sure I understand your reply here, this would appear to be a limitation
> that exists regardless of the current API defined, does that mean that you
> can make use of the phy_driver::{read,write}_mmd function calls and you will
> make a v2 that uses them, or something else entirely?
There are two ways to solve this problem:
- indirect way. Add read/write_mdd filter to catch requests and patch
them as needed.
- direct way. Introduce PHY specific EEE API and allow drivers to use
it.
What's with indirect way?
1. Hard to find common pattern within other drivers.
2. It is not obvious for some one, what is going on, without deep diving
in to documentation.
3. We provide different levels of abstractions not really compatible with
each other. One part of code thinks we are doing right thing other
part is trying to fake the answers. It looks and feels wrong.
4. I already tried to mainline driver with for a HW not 100% compatible
with 802.3 specification, which was faking read/write_mdd answers to
not supported or broken registers. It was not accepted and it was
good decision to not doing this.
Direct way:
- clean understandable API.
- It is possible to find common patterns.
- It is possible to support more exotic variants not reflected in the
802.3 spec.
Now we have a direct way. Yes, it is possible to implement in exact this
driver a read/write_mdd filter, but it is also possible to implement
get/set_eee as well. Why should I implement in this driver the filter
if I already know that next driver will need get/set_eee any way?
Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |