linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Koba Ko <koba.ko@canonical.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] r8169: introduce polling method for link change
Date: Fri, 4 Jun 2021 15:22:41 +0800	[thread overview]
Message-ID: <CAJB-X+V4vpLoNt2C_i=3mS4UtFnDdro5+hgaFXHWxcvobO=pzg@mail.gmail.com> (raw)
In-Reply-To: <3d2e7a11-92ad-db06-177b-c6602ef1acd4@gmail.com>

On Thu, Jun 3, 2021 at 6:00 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 03.06.2021 04:54, Koba Ko wrote:
> > For RTL8106E, it's a Fast-ethernet chip.
> > If ASPM is enabled, the link chang interrupt wouldn't be triggered
> > immediately and must wait a very long time to get link change interrupt.
> > Even the link change interrupt isn't triggered, the phy link is already
> > established.
> >
> At first please provide a full dmesg log and output of lspci -vv.
> Do you have the firmware for the NIC loaded? Please provide "ethtool -i <if>"
> output.

please get the logs from here,
https://bugzilla.kernel.org/show_bug.cgi?id=213165

> Does the issue affect link-down and/or link-up detection?
> Do you have runtime pm enabled? Then, after 10s of link-down NIC goes to
> D3hot and link-up detection triggers a PME.

Issue affect link-up.
yes, pm runtime is enabled, but rtl8106e always stays D0 even if the
cable isn't present.

>
> > Introduce a polling method to watch the status of phy link and disable
> > the link change interrupt.
> > Also add a quirk for those realtek devices have the same issue.
> >
> Which are the affected chip versions? Did you check with Realtek?
> Your patch switches to polling for all Fast Ethernet versions,
> and that's not what we want.

I don't know the exact version, only the chip name 806e(pci device id 0x8165).
ok, Im asking Realtek to help how to identify the chip issue is observed.

>
> My suspicion would be that something is system-dependent. Else I think
> we would have seen such a report before.
On the mainline, the aspm is disable, so you may not observe this.
If you enable ASPM and must wait CHIP go to power-saving mode, then
you can observe the issue.
>
> > Signed-off-by: Koba Ko <koba.ko@canonical.com>
> > ---
> >  drivers/net/ethernet/realtek/r8169.h      |   2 +
> >  drivers/net/ethernet/realtek/r8169_main.c | 112 ++++++++++++++++++----
> >  2 files changed, 98 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/realtek/r8169.h b/drivers/net/ethernet/realtek/r8169.h
> > index 2728df46ec41..a8c71adb1b57 100644
> > --- a/drivers/net/ethernet/realtek/r8169.h
> > +++ b/drivers/net/ethernet/realtek/r8169.h
> > @@ -11,6 +11,8 @@
> >  #include <linux/types.h>
> >  #include <linux/phy.h>
> >
> > +#define RTL8169_LINK_TIMEOUT (1 * HZ)
> > +
> >  enum mac_version {
> >       /* support for ancient RTL_GIGA_MAC_VER_01 has been removed */
> >       RTL_GIGA_MAC_VER_02,
> > diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> > index 2c89cde7da1e..70aacc83d641 100644
> > --- a/drivers/net/ethernet/realtek/r8169_main.c
> > +++ b/drivers/net/ethernet/realtek/r8169_main.c
> > @@ -178,6 +178,11 @@ static const struct pci_device_id rtl8169_pci_tbl[] = {
> >
> >  MODULE_DEVICE_TABLE(pci, rtl8169_pci_tbl);
> >
> > +static const struct pci_device_id rtl8169_linkChg_polling_enabled[] = {
> > +     { PCI_VDEVICE(REALTEK, 0x8136), RTL_CFG_NO_GBIT },
> > +     { 0 }
> > +};
> > +
>
> This doesn't seem to be used.
>
> >  enum rtl_registers {
> >       MAC0            = 0,    /* Ethernet hardware address. */
> >       MAC4            = 4,
> > @@ -618,6 +623,7 @@ struct rtl8169_private {
> >       u16 cp_cmd;
> >       u32 irq_mask;
> >       struct clk *clk;
> > +     struct timer_list link_timer;
> >
> >       struct {
> >               DECLARE_BITMAP(flags, RTL_FLAG_MAX);
> > @@ -1179,6 +1185,16 @@ static void rtl8168ep_stop_cmac(struct rtl8169_private *tp)
> >       RTL_W8(tp, IBCR0, RTL_R8(tp, IBCR0) & ~0x01);
> >  }
> >
> > +static int rtl_link_chng_polling_quirk(struct rtl8169_private *tp)
> > +{
> > +     struct pci_dev *pdev = tp->pci_dev;
> > +
> > +     if (pdev->vendor == 0x10ec && pdev->device == 0x8136 && !tp->supports_gmii)
> > +             return 1;
> > +
> > +     return 0;
> > +}
> > +
> >  static void rtl8168dp_driver_start(struct rtl8169_private *tp)
> >  {
> >       r8168dp_oob_notify(tp, OOB_CMD_DRIVER_START);
> > @@ -4608,6 +4624,75 @@ static void rtl_task(struct work_struct *work)
> >       rtnl_unlock();
> >  }
> >
> > +static void r8169_phylink_handler(struct net_device *ndev)
> > +{
> > +     struct rtl8169_private *tp = netdev_priv(ndev);
> > +
> > +     if (netif_carrier_ok(ndev)) {
> > +             rtl_link_chg_patch(tp);
> > +             pm_request_resume(&tp->pci_dev->dev);
> > +     } else {
> > +             pm_runtime_idle(&tp->pci_dev->dev);
> > +     }
> > +
> > +     if (net_ratelimit())
> > +             phy_print_status(tp->phydev);
> > +}
> > +
> > +static unsigned int
> > +rtl8169_xmii_link_ok(struct net_device *dev)
> > +{
> > +     struct rtl8169_private *tp = netdev_priv(dev);
> > +     unsigned int retval;
> > +
> > +     retval = (RTL_R8(tp, PHYstatus) & LinkStatus) ? 1 : 0;
> > +
> > +     return retval;
> > +}
> > +
> > +static void
> > +rtl8169_check_link_status(struct net_device *dev)
> > +{
> > +     struct rtl8169_private *tp = netdev_priv(dev);
> > +     int link_status_on;
> > +
> > +     link_status_on = rtl8169_xmii_link_ok(dev);
> > +
> > +     if (netif_carrier_ok(dev) == link_status_on)
> > +             return;
> > +
> > +     phy_mac_interrupt(tp->phydev);
> > +
> > +     r8169_phylink_handler (dev);
> > +}
> > +
> > +static void rtl8169_link_timer(struct timer_list *t)
> > +{
> > +     struct rtl8169_private *tp = from_timer(tp, t, link_timer);
> > +     struct net_device *dev = tp->dev;
> > +     struct timer_list *timer = t;
> > +     unsigned long flags;
>
> flags isn't used and triggers a compiler warning. Did you even
> compile-test your patch?
>
> > +
> > +     rtl8169_check_link_status(dev);
> > +
> > +     if (timer_pending(&tp->link_timer))
> > +             return;
> > +
> > +     mod_timer(timer, jiffies + RTL8169_LINK_TIMEOUT);
> > +}
> > +
> > +static inline void rtl8169_delete_link_timer(struct net_device *dev, struct timer_list *timer)
> > +{
> > +     del_timer_sync(timer);
> > +}
> > +
> > +static inline void rtl8169_request_link_timer(struct net_device *dev)
> > +{
> > +     struct rtl8169_private *tp = netdev_priv(dev);
> > +
> > +     timer_setup(&tp->link_timer, rtl8169_link_timer, TIMER_INIT_FLAGS);
> > +}
> > +
> >  static int rtl8169_poll(struct napi_struct *napi, int budget)
> >  {
> >       struct rtl8169_private *tp = container_of(napi, struct rtl8169_private, napi);
> > @@ -4624,21 +4709,6 @@ static int rtl8169_poll(struct napi_struct *napi, int budget)
> >       return work_done;
> >  }
> >
> > -static void r8169_phylink_handler(struct net_device *ndev)
> > -{
> > -     struct rtl8169_private *tp = netdev_priv(ndev);
> > -
> > -     if (netif_carrier_ok(ndev)) {
> > -             rtl_link_chg_patch(tp);
> > -             pm_request_resume(&tp->pci_dev->dev);
> > -     } else {
> > -             pm_runtime_idle(&tp->pci_dev->dev);
> > -     }
> > -
> > -     if (net_ratelimit())
> > -             phy_print_status(tp->phydev);
> > -}
> > -
> >  static int r8169_phy_connect(struct rtl8169_private *tp)
> >  {
> >       struct phy_device *phydev = tp->phydev;
> > @@ -4769,6 +4839,10 @@ static int rtl_open(struct net_device *dev)
> >               goto err_free_irq;
> >
> >       rtl8169_up(tp);
> > +
> > +     if (rtl_link_chng_polling_quirk(tp))
> > +             mod_timer(&tp->link_timer, jiffies + RTL8169_LINK_TIMEOUT);
> > +
> >       rtl8169_init_counter_offsets(tp);
> >       netif_start_queue(dev);
> >  out:
> > @@ -4991,7 +5065,10 @@ static const struct net_device_ops rtl_netdev_ops = {
> >
> >  static void rtl_set_irq_mask(struct rtl8169_private *tp)
> >  {
> > -     tp->irq_mask = RxOK | RxErr | TxOK | TxErr | LinkChg;
> > +     tp->irq_mask = RxOK | RxErr | TxOK | TxErr;
> > +
> > +     if (!rtl_link_chng_polling_quirk(tp))
> > +             tp->irq_mask |= LinkChg;
> >
> >       if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
> >               tp->irq_mask |= SYSErr | RxOverflow | RxFIFOOver;
> > @@ -5436,6 +5513,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> >       if (pci_dev_run_wake(pdev))
> >               pm_runtime_put_sync(&pdev->dev);
> >
> > +     if (rtl_link_chng_polling_quirk(tp))
> > +             rtl8169_request_link_timer(dev);
> > +
> >       return 0;
> >  }
> >
> >
>
> All this isn't needed. If you want to switch to link status polling,
> why don't you simply let phylib do it? PHY_MAC_INTERRUPT -> PHY_POLL

Thanks for suggestions, I tried to use PHY_POLL, it could do the same
thing that I did.

> Your timer-based code most likely would have problems if runtime pm
> is enabled. Then you try to read the link status whilst NIC is in
> D3hot.

  reply	other threads:[~2021-06-04  7:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03  2:54 [PATCH] r8169: introduce polling method for link change Koba Ko
2021-06-03  9:59 ` Heiner Kallweit
2021-06-04  7:22   ` Koba Ko [this message]
2021-06-04  8:23     ` Heiner Kallweit
2021-06-04  9:08       ` Koba Ko
2021-06-04 11:59         ` Heiner Kallweit
2021-06-07  4:34           ` Koba Ko
2021-06-07 10:43             ` Heiner Kallweit
2021-06-07 11:09               ` Koba Ko
2021-06-07 12:32             ` David Laight
2021-06-07 12:49               ` Andrew Lunn
2021-06-07 13:17                 ` David Laight
2021-06-03 21:33 ` kernel test robot

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='CAJB-X+V4vpLoNt2C_i=3mS4UtFnDdro5+hgaFXHWxcvobO=pzg@mail.gmail.com' \
    --to=koba.ko@canonical.com \
    --cc=davem@davemloft.net \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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).