From: Heiner Kallweit <hkallweit1@gmail.com>
To: En-Wei Wu <en-wei.wu@canonical.com>,
nic_swsd@realtek.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: kuan-ying.lee@canonical.com, kai.heng.feng@canonical.com
Subject: Re: [PATCH net] r8169: correct the reset timing of RTL8125 for link-change event
Date: Fri, 6 Sep 2024 23:16:59 +0200 [thread overview]
Message-ID: <8707a2c6-644d-4ccd-989f-1fb66c48d34a@gmail.com> (raw)
In-Reply-To: <20240906083539.154019-1-en-wei.wu@canonical.com>
On 06.09.2024 10:35, En-Wei Wu wrote:
> The commit 621735f59064 ("r8169: fix rare issue with broken rx after
> link-down on RTL8125") set a reset work for RTL8125 in
> r8169_phylink_handler() to avoid the MAC from locking up, this
> makes the connection broken after unplugging then re-plugging the
> Ethernet cable.
>
> This is because the commit mistakenly put the reset work in the
> link-down path rather than the link-up path (The commit message says
> it should be put in the link-up path).
>
That's not what the commit message is saying. It says vendor driver
r8125 does it in the link-up path.
I moved it intentionally to the link-down path, because traffic may
be flowing already after link-up.
> Moving the reset work from the link-down path to the link-up path fixes
> the issue. Also, remove the unnecessary enum member.
>
The user who reported the issue at that time confirmed that the original
change fixed the issue for him.
Can you explain, from the NICs perspective, what exactly the difference
is when doing the reset after link-up?
Including an explanation how the original change suppresses the link-up
interrupt. And why that's not the case when doing the reset after link-up.
I simply want to be convinced enough that your change doesn't break
behavior for other users.
> Fixes: 621735f59064 ("r8169: fix rare issue with broken rx after link-down on RTL8125")
> Signed-off-by: En-Wei Wu <en-wei.wu@canonical.com>
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index 3507c2e28110..632e661fc74b 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -590,7 +590,6 @@ struct rtl8169_tc_offsets {
> enum rtl_flag {
> RTL_FLAG_TASK_ENABLED = 0,
> RTL_FLAG_TASK_RESET_PENDING,
> - RTL_FLAG_TASK_RESET_NO_QUEUE_WAKE,
> RTL_FLAG_TASK_TX_TIMEOUT,
> RTL_FLAG_MAX
> };
> @@ -4698,8 +4697,6 @@ static void rtl_task(struct work_struct *work)
> reset:
> rtl_reset_work(tp);
> netif_wake_queue(tp->dev);
> - } else if (test_and_clear_bit(RTL_FLAG_TASK_RESET_NO_QUEUE_WAKE, tp->wk.flags)) {
> - rtl_reset_work(tp);
> }
> out_unlock:
> rtnl_unlock();
> @@ -4729,11 +4726,13 @@ static void r8169_phylink_handler(struct net_device *ndev)
> if (netif_carrier_ok(ndev)) {
> rtl_link_chg_patch(tp);
> pm_request_resume(d);
> - netif_wake_queue(tp->dev);
> - } else {
> +
> /* In few cases rx is broken after link-down otherwise */
> if (rtl_is_8125(tp))
> - rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_NO_QUEUE_WAKE);
> + rtl_schedule_task(tp, RTL_FLAG_TASK_RESET_PENDING);
> + else
> + netif_wake_queue(tp->dev);
This call to netif_wake_queue() isn't needed any longer, it was introduced with
the original change only.
> + } else {
> pm_runtime_idle(d);
> }
>
next prev parent reply other threads:[~2024-09-06 21:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-06 8:35 En-Wei Wu
2024-09-06 21:16 ` Heiner Kallweit [this message]
2024-09-09 5:25 ` En-Wei WU
2024-09-10 17:06 ` Heiner Kallweit
2024-09-11 7:01 ` En-Wei WU
2024-09-11 9:14 ` Heiner Kallweit
2024-09-11 9:16 ` Heiner Kallweit
2024-09-11 10:38 ` En-Wei WU
2024-09-11 11:58 ` Heiner Kallweit
2024-09-11 14:07 ` En-Wei WU
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=8707a2c6-644d-4ccd-989f-1fb66c48d34a@gmail.com \
--to=hkallweit1@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=en-wei.wu@canonical.com \
--cc=kai.heng.feng@canonical.com \
--cc=kuan-ying.lee@canonical.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.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
all inboxes | Powered by JetHome®