All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: phy: Avoid WARN_ON for PHY_NOLINK during resuming
Date: Fri, 21 Oct 2022 13:12:34 +0200	[thread overview]
Message-ID: <125eddc1-8791-e8c4-39ac-fb5b864d91ba@gmail.com> (raw)
In-Reply-To: <86262217-a620-dc5b-cf5a-3a23ea869834@socionext.com>

On 21.10.2022 11:35, Kunihiko Hayashi wrote:
> Hi Heiner,
> 
> Thank you for your comment.
> 
> On 2022/10/21 17:38, Heiner Kallweit wrote:
>> On 21.10.2022 09:41, Kunihiko Hayashi wrote:
>>> When resuming from sleep, if there is a time lag from link-down to link-up
>>> due to auto-negotiation, the phy status has been still PHY_NOLINK, so
>>> WARN_ON dump occurs in mdio_bus_phy_resume(). For example, UniPhier AVE
>>> ethernet takes about a few seconds to link up after resuming.
>>>
>> That autoneg takes some time is normal. If this would actually the root
>> cause then basically every driver should be affected. But it's not.
> 
> Although the auto-neg should happen normally, I'm not sure about other
> platforms.
> 
>>> To avoid this issue, should remove PHY_NOLINK the WARN_ON conditions.
>>>
>>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>>> ---
>>>   drivers/net/phy/phy_device.c | 8 ++++----
>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>> index 57849ac0384e..c647d027bb5d 100644
>>> --- a/drivers/net/phy/phy_device.c
>>> +++ b/drivers/net/phy/phy_device.c
>>> @@ -318,12 +318,12 @@ static __maybe_unused int mdio_bus_phy_resume(struct
>>> device *dev)
>>>       phydev->suspended_by_mdio_bus = 0;
>>>
>>>       /* If we managed to get here with the PHY state machine in a state
>>> -     * neither PHY_HALTED, PHY_READY nor PHY_UP, this is an indication
>>> -     * that something went wrong and we should most likely be using
>>> -     * MAC managed PM, but we are not.
>>> +     * neither PHY_HALTED, PHY_READY, PHY_UP nor PHY_NOLINK, this is an
>>> +     * indication that something went wrong and we should most likely
>>> +     * be using MAC managed PM, but we are not.
>>>        */
>>
>> Did you read the comment you're changing? ave_resume() calls phy_resume(),
>> so you should follow the advice in the comment.
> 
> I understand something is wrong with "PHY_NOLINK" here, and need to investigate
> the root cause of the phy state issue.
> 
Best look at how phydev->mac_managed_pm is used in phylib and by MAC drivers.

> Thank you,
> 
> ---
> Best Regards
> Kunihiko Hayashi


  reply	other threads:[~2022-10-21 11:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  7:41 [PATCH net] net: phy: Avoid WARN_ON for PHY_NOLINK during resuming Kunihiko Hayashi
2022-10-21  8:38 ` Heiner Kallweit
2022-10-21  9:35   ` Kunihiko Hayashi
2022-10-21 11:12     ` Heiner Kallweit [this message]
2022-10-21 11:27       ` Kunihiko Hayashi

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=125eddc1-8791-e8c4-39ac-fb5b864d91ba@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.