From: Simon Horman <horms@kernel.org>
To: Hui Wang <hui.wang@canonical.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
kuba@kernel.org, anthony.l.nguyen@intel.com,
vitaly.lifshits@intel.com, dima.ruinskiy@intel.com,
davem@davemloft.net, pabeni@redhat.com, edumazet@google.com,
sasha.neftin@intel.com, naamax.meir@linux.intel.com
Subject: Re: [PATCH v2] e1000e: move force SMBUS near the end of enable_ulp function
Date: Fri, 10 May 2024 12:02:51 +0100 [thread overview]
Message-ID: <20240510110251.GB2347895@kernel.org> (raw)
In-Reply-To: <20240508120604.233166-1-hui.wang@canonical.com>
On Wed, May 08, 2024 at 08:06:04PM +0800, Hui Wang wrote:
> The commit 861e8086029e ("e1000e: move force SMBUS from enable ulp
> function to avoid PHY loss issue") introduces a regression on
> CH_MTP_I219_LM18 (PCIID: 0x8086550A). Without the referred commit, the
> ethernet works well after suspend and resume, but after applying the
> commit, the ethernet couldn't work anymore after the resume and the
> dmesg shows that the NIC Link changes to 10Mbps (1000Mbps originally):
> [ 43.305084] e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 10 Mbps Full Duplex, Flow Control: Rx/Tx
>
> Without the commit, the force SMBUS code will not be executed if
> "return 0" or "goto out" is executed in the enable_ulp(), and in my
> case, the "goto out" is executed since FWSM_FW_VALID is set. But after
> applying the commit, the force SMBUS code will be ran unconditionally.
>
> Here move the force SMBUS code back to enable_ulp() and put it
> immediate ahead of hw->phy.ops.release(hw), this could allow the
> longest settling time as possible for interface in this function and
> doesn't change the original code logic.
>
> Fixes: 861e8086029e ("e1000e: move force SMBUS from enable ulp function to avoid PHY loss issue")
> Signed-off-by: Hui Wang <hui.wang@canonical.com>
> Acked-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
> Tested-by: Naama Meir <naamax.meir@linux.intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> In the v2:
> Change "this commit" to "the referred commit" in the commit header
> Fix a potential infinite loop if ret_val is not zero
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2024-05-10 11:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-08 12:06 [PATCH v2] e1000e: move force SMBUS near the end of enable_ulp function Hui Wang
2024-05-10 11:02 ` Simon Horman [this message]
2024-05-16 17:29 ` Jacob Keller
2024-05-17 5:45 ` [Intel-wired-lan] " Paul Menzel
[not found] ` <7b0a36a5-4265-41e7-b66a-2cd1f01aed42@canonical.com>
2024-05-17 10:07 ` Paul Menzel
2024-05-17 13:00 ` Hui Wang
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=20240510110251.GB2347895@kernel.org \
--to=horms@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=dima.ruinskiy@intel.com \
--cc=edumazet@google.com \
--cc=hui.wang@canonical.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=kuba@kernel.org \
--cc=naamax.meir@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sasha.neftin@intel.com \
--cc=vitaly.lifshits@intel.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 read-only IMAP folder(s) and NNTP newsgroup(s).