[PATCH] PHY: Fix no autoneg corner case

[PATCH] PHY: Fix no autoneg corner case

[Krzysztof Hałasa]

phydev->autoneg appears to indicate if autonegotiation is enabled or
not. Unfortunately it's initially set based on the supported capability
rather than the actual hw setting. While in most cases there is no
difference (i.e., autoneg is supported and on by default), certain
adapters (e.g. fiber optics) use fixed settings, configured in hardware.

Now autoneg flag is set only when it's supported and actually used.

Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl>

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 366cf3b2cbb0..6858f512558b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -3453,7 +3453,7 @@ static int phy_probe(struct device *dev)
 	struct phy_device *phydev = to_phy_device(dev);
 	struct device_driver *drv = phydev->mdio.dev.driver;
 	struct phy_driver *phydrv = to_phy_driver(drv);
-	int err = 0;
+	int err = 0, bmcr;
 
 	phydev->drv = phydrv;
 
@@ -3495,8 +3495,12 @@ static int phy_probe(struct device *dev)
 	if (err)
 		goto out;
 
+	err = bmcr = phy_read(phydev, MII_BMCR);
+	if (err < 0)
+		goto out;
+
 	if (!linkmode_test_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
-			       phydev->supported))
+			       phydev->supported) || !(bmcr & BMCR_ANENABLE))
 		phydev->autoneg = 0;
 
 	if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT,

-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: [PATCH] PHY: Fix no autoneg corner case

[Andrew Lunn]

On Wed, Nov 27, 2024 at 09:56:42AM +0100, Krzysztof Hałasa wrote:
> phydev->autoneg appears to indicate if autonegotiation is enabled or
> not.

Correct.

> Unfortunately it's initially set based on the supported capability
> rather than the actual hw setting.

We need a clear definition of 'initially', and when does it actually
matter.

Initially, things like speed, duplex and set to UNKNOWN. They don't
make any sense until the link is up. phydev->advertise is set to
phydev->supported, so that we advertise all the capabilities of the
PHY. However, at probe, this does not really matter, it is only when
phy_start() is called is the hardware actually configured with what it
should advertise, or even if it should do auto-neg or not.

In the end, this might not matter.

> While in most cases there is no
> difference (i.e., autoneg is supported and on by default), certain
> adapters (e.g. fiber optics) use fixed settings, configured in hardware.

If the hardware is not capable of supporting autoneg, why is autoneg
in phydev->supported? To me, that is the real issue here.

	Andrew

Re: [PATCH] PHY: Fix no autoneg corner case

[Krzysztof Hałasa]

Andrew,

Andrew Lunn <andrew@lunn.ch> writes:

>> Unfortunately it's initially set based on the supported capability
>> rather than the actual hw setting.
>
> We need a clear definition of 'initially', and when does it actually
> matter.
>
> Initially, things like speed, duplex and set to UNKNOWN. They don't
> make any sense until the link is up. phydev->advertise is set to
> phydev->supported, so that we advertise all the capabilities of the
> PHY. However, at probe, this does not really matter, it is only when
> phy_start() is called is the hardware actually configured with what it
> should advertise, or even if it should do auto-neg or not.
>
> In the end, this might not matter.

Nevertheless, it seems it does matter.

>> While in most cases there is no
>> difference (i.e., autoneg is supported and on by default), certain
>> adapters (e.g. fiber optics) use fixed settings, configured in hardware.
>
> If the hardware is not capable of supporting autoneg, why is autoneg
> in phydev->supported? To me, that is the real issue here.

Well, autoneg *IS* supported by the PHY in this case.
No autoneg in phydev->supported would mean I can't enable it if needed,
wouldn't it?

It is supported but initially disabled.

With current code, PHY correctly connects to the other side, all the
registers are valid etc., the PHY indicates, for example, a valid link
with 100BASE-FX full duplex etc.

Yet the Linux netdev, ethtool etc. indicate no valid link, autoneg on,
and speed/duplex unknown. It's just completely inconsistent with the
real hardware state.

It seems the phy/phylink code assumes the PHY starts with autoneg
enabled (if supported). This is simply an incorrect assumption.

BTW if the code meant to enable autoneg, it would do exactly that -
enable it by writing to PHY command register. Then the hw and sw state
would be consistent again (though initial configuration would be
ignored, not very nice). Now the code doesn't enable autoneg, it only
*indicates* it's enabled and in reality it's not.
-- 
Krzysiek
PAMIĘTAJ: WRÓG TEŻ TO CZYTA

Re: [PATCH] PHY: Fix no autoneg corner case

[Andrew Lunn]

On Thu, Nov 28, 2024 at 07:31:48AM +0100, Krzysztof Hałasa wrote:
> Andrew,
> 
> Andrew Lunn <andrew@lunn.ch> writes:
> 
> >> Unfortunately it's initially set based on the supported capability
> >> rather than the actual hw setting.
> >
> > We need a clear definition of 'initially', and when does it actually
> > matter.
> >
> > Initially, things like speed, duplex and set to UNKNOWN. They don't
> > make any sense until the link is up. phydev->advertise is set to
> > phydev->supported, so that we advertise all the capabilities of the
> > PHY. However, at probe, this does not really matter, it is only when
> > phy_start() is called is the hardware actually configured with what it
> > should advertise, or even if it should do auto-neg or not.
> >
> > In the end, this might not matter.
> 
> Nevertheless, it seems it does matter.
> 
> >> While in most cases there is no
> >> difference (i.e., autoneg is supported and on by default), certain
> >> adapters (e.g. fiber optics) use fixed settings, configured in hardware.
> >
> > If the hardware is not capable of supporting autoneg, why is autoneg
> > in phydev->supported? To me, that is the real issue here.
> 
> Well, autoneg *IS* supported by the PHY in this case.
> No autoneg in phydev->supported would mean I can't enable it if needed,
> wouldn't it?
> 
> It is supported but initially disabled.
> 
> With current code, PHY correctly connects to the other side, all the
> registers are valid etc., the PHY indicates, for example, a valid link
> with 100BASE-FX full duplex etc.
> 
> Yet the Linux netdev, ethtool etc. indicate no valid link, autoneg on,
> and speed/duplex unknown. It's just completely inconsistent with the
> real hardware state.
> 
> It seems the phy/phylink code assumes the PHY starts with autoneg
> enabled (if supported). This is simply an incorrect assumption.

This is sounding like a driver bug. When phy_start() is called it
kicks off the PHY state machine. That should result in
phy_config_aneg() being called. That function is badly named, since it
is used both for autoneg and forced setting. The purpose of that call
is to configure the PHY to the configuration stored in
phydev->advertise, etc. So if the PHY by hardware defaults has autoneg
disabled, but the configuration in phydev says it should be enabled,
calling phy_config_aneg() should actually enabled autoneg. It is
possible there is a phylib bug here, because we try to not to kick off
autoneg if it is not needed, because it is slow. I've not looked at
the code, but it could be we see there is link, and skip calling
phy_config_aneg()? Maybe try booting with the cable disconnected so
there is no link?

> BTW if the code meant to enable autoneg, it would do exactly that -
> enable it by writing to PHY command register.

Assuming bug free code.

> Then the hw and sw state
> would be consistent again (though initial configuration would be
> ignored, not very nice). Now the code doesn't enable autoneg, it only
> *indicates* it's enabled and in reality it's not.

I would say there are two different issues here.

1) It seems like we are not configuring the hardware to match phydev.
2) We are overwriting how the bootloader etc configured the hardware.

2) is always hard, because how do we know the PHY is not messed up
from a previous boot/crash cycle etc. In general, a driver should try
to put the hardware into a well known state. If we have a clear use
case for this, we can consider how to implement it.

	Andrew

Re: [PATCH] PHY: Fix no autoneg corner case

[Heiner Kallweit]

On 28.11.2024 15:54, Andrew Lunn wrote:
> On Thu, Nov 28, 2024 at 07:31:48AM +0100, Krzysztof Hałasa wrote:
>> Andrew,
>>
>> Andrew Lunn <andrew@lunn.ch> writes:
>>
>>>> Unfortunately it's initially set based on the supported capability
>>>> rather than the actual hw setting.
>>>
>>> We need a clear definition of 'initially', and when does it actually
>>> matter.
>>>
>>> Initially, things like speed, duplex and set to UNKNOWN. They don't
>>> make any sense until the link is up. phydev->advertise is set to
>>> phydev->supported, so that we advertise all the capabilities of the
>>> PHY. However, at probe, this does not really matter, it is only when
>>> phy_start() is called is the hardware actually configured with what it
>>> should advertise, or even if it should do auto-neg or not.
>>>
>>> In the end, this might not matter.
>>
>> Nevertheless, it seems it does matter.
>>
>>>> While in most cases there is no
>>>> difference (i.e., autoneg is supported and on by default), certain
>>>> adapters (e.g. fiber optics) use fixed settings, configured in hardware.
>>>
>>> If the hardware is not capable of supporting autoneg, why is autoneg
>>> in phydev->supported? To me, that is the real issue here.
>>
>> Well, autoneg *IS* supported by the PHY in this case.
>> No autoneg in phydev->supported would mean I can't enable it if needed,
>> wouldn't it?
>>
>> It is supported but initially disabled.
>>
>> With current code, PHY correctly connects to the other side, all the
>> registers are valid etc., the PHY indicates, for example, a valid link
>> with 100BASE-FX full duplex etc.
>>
>> Yet the Linux netdev, ethtool etc. indicate no valid link, autoneg on,
>> and speed/duplex unknown. It's just completely inconsistent with the
>> real hardware state.
>>
>> It seems the phy/phylink code assumes the PHY starts with autoneg
>> enabled (if supported). This is simply an incorrect assumption.
> 
> This is sounding like a driver bug. When phy_start() is called it
> kicks off the PHY state machine. That should result in
> phy_config_aneg() being called. That function is badly named, since it
> is used both for autoneg and forced setting. The purpose of that call
> is to configure the PHY to the configuration stored in
> phydev->advertise, etc. So if the PHY by hardware defaults has autoneg
> disabled, but the configuration in phydev says it should be enabled,
> calling phy_config_aneg() should actually enabled autoneg. It is
> possible there is a phylib bug here, because we try to not to kick off
> autoneg if it is not needed, because it is slow. I've not looked at
> the code, but it could be we see there is link, and skip calling
> phy_config_aneg()? Maybe try booting with the cable disconnected so
> there is no link?
> 
If the PHY driver has no config_aneg() callback, then genphy_config_aneg()
-> genphy_check_and_restart_aneg() would set BMCR_ANENABLE.
Not sure about which PHY driver we're talking here, but if it has a
custom config_aneg(), then setting BMCR_ANENABLE may be missing there.

>> BTW if the code meant to enable autoneg, it would do exactly that -
>> enable it by writing to PHY command register.
> 
> Assuming bug free code.
> 
>> Then the hw and sw state
>> would be consistent again (though initial configuration would be
>> ignored, not very nice). Now the code doesn't enable autoneg, it only
>> *indicates* it's enabled and in reality it's not.
> 
> I would say there are two different issues here.
> 
> 1) It seems like we are not configuring the hardware to match phydev.
> 2) We are overwriting how the bootloader etc configured the hardware.
> 
> 2) is always hard, because how do we know the PHY is not messed up
> from a previous boot/crash cycle etc. In general, a driver should try
> to put the hardware into a well known state. If we have a clear use
> case for this, we can consider how to implement it.
> 
> 	Andrew
> 

Re: [PATCH] PHY: Fix no autoneg corner case

[Krzysztof Hałasa]

Andrew,

thanks for your response.

Andrew Lunn <andrew@lunn.ch> writes:

>> It seems the phy/phylink code assumes the PHY starts with autoneg
>> enabled (if supported). This is simply an incorrect assumption.
>
> This is sounding like a driver bug. When phy_start() is called it
> kicks off the PHY state machine. That should result in
> phy_config_aneg() being called. That function is badly named, since it
> is used both for autoneg and forced setting. The purpose of that call
> is to configure the PHY to the configuration stored in
> phydev->advertise, etc. So if the PHY by hardware defaults has autoneg
> disabled, but the configuration in phydev says it should be enabled,
> calling phy_config_aneg() should actually enabled autoneg.

But... how would the driver know if autoneg is to be enabled or not?

In the USB ASIX case, the Ethernet driver could dig this info up from
the chip EEPROM. Not sure if I like this way, though. Complicated, and
it's not needed in this case I think.

> I would say there are two different issues here.
>
> 1) It seems like we are not configuring the hardware to match phydev.
> 2) We are overwriting how the bootloader etc configured the hardware.
>
> 2) is always hard, because how do we know the PHY is not messed up
> from a previous boot/crash cycle etc. In general, a driver should try
> to put the hardware into a well known state. If we have a clear use
> case for this, we can consider how to implement it.

Well, I think if someone set the PHY previously, and then the machine
rebooted (without actually changing PHY config), then perhaps the
settings are better than any defaults anyway. Though I guess it will be
configured in the init scripts again soon.

It's not something easily messed up by a crash. But yes, there is a risk
the config was wrong, set by mistake or something.

BTW USB adapters will almost always reconfig PHY on boot, because they
are powered from USB bus.

In this case, with ASIX USB adapter (internal PHY ax88796b /
ax88796b_rust), the MAC + PHY will be configured by hardware on USB
power up. So we _know_ the settings are better than any hardcoded
defaults.

Maybe the specific ASIX PHY code should handle this.

Nevertheless, the inconsistency between phy/phylink/etc. and the actual
hardware PHY is there.
I guess I will have a look at this again shortly.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: [PATCH] PHY: Fix no autoneg corner case

[Heiner Kallweit]

On 29.11.2024 07:17, Krzysztof Hałasa wrote:
> Andrew,
> 
> thanks for your response.
> 
> Andrew Lunn <andrew@lunn.ch> writes:
> 
>>> It seems the phy/phylink code assumes the PHY starts with autoneg
>>> enabled (if supported). This is simply an incorrect assumption.
>>
>> This is sounding like a driver bug. When phy_start() is called it
>> kicks off the PHY state machine. That should result in
>> phy_config_aneg() being called. That function is badly named, since it
>> is used both for autoneg and forced setting. The purpose of that call
>> is to configure the PHY to the configuration stored in
>> phydev->advertise, etc. So if the PHY by hardware defaults has autoneg
>> disabled, but the configuration in phydev says it should be enabled,
>> calling phy_config_aneg() should actually enabled autoneg.
> 
> But... how would the driver know if autoneg is to be enabled or not?
> 
If autoneg is supported, then phylib defaults to enable it. I don't see
anything wrong with this. BaseT modes from 1000Mbps on require autoneg.
Your original commit message seems to refer to a use case where a certain
operation mode of the PHY doesn't support autoneg. Then the PHY driver
should detect this operation mode and clear the autoneg-supported bit.

> In the USB ASIX case, the Ethernet driver could dig this info up from
> the chip EEPROM. Not sure if I like this way, though. Complicated, and
> it's not needed in this case I think.
> 
>> I would say there are two different issues here.
>>
>> 1) It seems like we are not configuring the hardware to match phydev.
>> 2) We are overwriting how the bootloader etc configured the hardware.
>>
>> 2) is always hard, because how do we know the PHY is not messed up
>> from a previous boot/crash cycle etc. In general, a driver should try
>> to put the hardware into a well known state. If we have a clear use
>> case for this, we can consider how to implement it.
> 
> Well, I think if someone set the PHY previously, and then the machine
> rebooted (without actually changing PHY config), then perhaps the
> settings are better than any defaults anyway. Though I guess it will be
> configured in the init scripts again soon.
> 
> It's not something easily messed up by a crash. But yes, there is a risk
> the config was wrong, set by mistake or something.
> 
> BTW USB adapters will almost always reconfig PHY on boot, because they
> are powered from USB bus.
> 
> In this case, with ASIX USB adapter (internal PHY ax88796b /
> ax88796b_rust), the MAC + PHY will be configured by hardware on USB
> power up. So we _know_ the settings are better than any hardcoded
> defaults.
> 
> Maybe the specific ASIX PHY code should handle this.
> 
> Nevertheless, the inconsistency between phy/phylink/etc. and the actual
> hardware PHY is there.
> I guess I will have a look at this again shortly.

Re: [PATCH] PHY: Fix no autoneg corner case

[Krzysztof Hałasa]

Heiner,

Heiner Kallweit <hkallweit1@gmail.com> writes:

> If autoneg is supported, then phylib defaults to enable it. I don't see
> anything wrong with this. BaseT modes from 1000Mbps on require autoneg.
> Your original commit message seems to refer to a use case where a certain
> operation mode of the PHY doesn't support autoneg. Then the PHY driver
> should detect this operation mode and clear the autoneg-supported bit.

I'm not sure about it, but if there is consensus it should stay this
way, no problem.

WRT specific case, It seems the SFP port doesn't support autoneg on
AX88772BL (I don't have any SFP copper 10/100 module).

The PHY registers (100BASE-FX, no link currently):
          x0   x1   x2   x3   x4   x5   x6   x7   x8
  0000: 2100 7809   3B 1881  501
  0010:  250  80C 8620   20 2314  3C8 4716 724F 8024

BMCR: fixed speed 100 Mb/s
      The datasheet says "autoneg is fixed to 1 and speed to 100", but
      it's apparently the case only with 100BASE-TX, not FX.

      It seems autoneg, speed and duplex bits are read only
      (bits 13, 12, 9, 8). So, basically, you can't enable autoneg at
      all and this is maybe the source of the "bug".

BMSR: 10 and 100 Mb/s FD/HD autoneg support indicated. Hmm. R/O.

ANAR: quite standard, but doesn't matter since autoneg is disabled.

I will think about it a bit more.
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

Re: [PATCH] PHY: Fix no autoneg corner case

[Heiner Kallweit]

On 02.12.2024 08:57, Krzysztof Hałasa wrote:
> Heiner,
> 
> Heiner Kallweit <hkallweit1@gmail.com> writes:
> 
>> If autoneg is supported, then phylib defaults to enable it. I don't see
>> anything wrong with this. BaseT modes from 1000Mbps on require autoneg.
>> Your original commit message seems to refer to a use case where a certain
>> operation mode of the PHY doesn't support autoneg. Then the PHY driver
>> should detect this operation mode and clear the autoneg-supported bit.
> 
> I'm not sure about it, but if there is consensus it should stay this
> way, no problem.
> 
> WRT specific case, It seems the SFP port doesn't support autoneg on
> AX88772BL (I don't have any SFP copper 10/100 module).
> 
> The PHY registers (100BASE-FX, no link currently):
>           x0   x1   x2   x3   x4   x5   x6   x7   x8
>   0000: 2100 7809   3B 1881  501
>   0010:  250  80C 8620   20 2314  3C8 4716 724F 8024
> 
> BMCR: fixed speed 100 Mb/s
>       The datasheet says "autoneg is fixed to 1 and speed to 100", but
>       it's apparently the case only with 100BASE-TX, not FX.
> 
>       It seems autoneg, speed and duplex bits are read only
>       (bits 13, 12, 9, 8). So, basically, you can't enable autoneg at
>       all and this is maybe the source of the "bug".
> 
> BMSR: 10 and 100 Mb/s FD/HD autoneg support indicated. Hmm. R/O.
> 
> ANAR: quite standard, but doesn't matter since autoneg is disabled.
> 
> I will think about it a bit more.

The PHY in your case should be handled by the ax88796b driver, based on PHY ID
in your register dump being PHY_ID_ASIX_AX88772C. Maybe the PHY driver needs
an extension for handling fiber mode properly. That's something you should check
based on the datasheet. There are examples like the Marvell PHY driver which
has quite some fiber-specific handling.