netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev <netdev@vger.kernel.org>,
	 Oliver Neukum <oneukum@suse.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	 "David S. Miller" <davem@davemloft.net>,
	 Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	 Paolo Abeni <pabeni@redhat.com>,
	linux-usb@vger.kernel.org,  linux-kernel@vger.kernel.org,
	 Jose Ignacio Tornos Martinez <jtornosm@redhat.com>,
	 Ming Lei <ming.lei@redhat.com>
Subject: Re: [PATCH] PHY: Fix no autoneg corner case
Date: Fri, 29 Nov 2024 07:17:34 +0100	[thread overview]
Message-ID: <m3serah8ch.fsf@t19.piap.pl> (raw)
In-Reply-To: <2428ec56-f2db-4769-aaca-ca09e57b8162@lunn.ch> (Andrew Lunn's message of "Thu, 28 Nov 2024 15:54:52 +0100")

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

  parent reply	other threads:[~2024-11-29  6:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-27  8:56 [PATCH] PHY: Fix no autoneg corner case Krzysztof Hałasa
2024-11-27 17:37 ` Andrew Lunn
2024-11-28  6:31   ` Krzysztof Hałasa
2024-11-28 14:54     ` Andrew Lunn
2024-11-28 19:35       ` Heiner Kallweit
2024-11-29  6:17       ` Krzysztof Hałasa [this message]
2024-11-29  6:49         ` Heiner Kallweit
2024-12-02  7:57           ` Krzysztof Hałasa
2025-03-19 21:00             ` Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3serah8ch.fsf@t19.piap.pl \
    --to=khalasa@piap.pl \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jtornosm@redhat.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).