mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chih Kai Hsu <hsu.chih.kai@realtek.com>
To: "netdev-bot+sashiko@kernel.org" <netdev-bot+sashiko@kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	nic_swsd <nic_swsd@realtek.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"edumazet@google.com" <edumazet@google.com>,
	"bjorn@mork.no" <bjorn@mork.no>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>
Subject: RE: [PATCH net-next v3 8/8] r8152: support UPS for RTL8157 and RTL8159
Date: Tue, 15 Sep 2026 11:45:55 +0000	[thread overview]
Message-ID: <876ed636726542b396dda5a36cbb3242@realtek.com> (raw)
In-Reply-To: <178924439640.3125.13644220695109747344@kernel.org>

> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
> 
> - [Medium] Incomplete version dispatch: the four new switch statements
>   added by this patch enumerate only RTL_VER_16 and RTL_VER_17_QFN68
> and…
> 
> --
> 
> r8152: support UPS for RTL8157 and RTL8159
> 
> This adds r8157_ups_en() for the RTL8157/RTL8159 UPS enable sequence,
> extends r8156_ups_flags() with per-speed EEE flags and 5G/10G speed
> encodings, and switches r8157_init()/r8159_init() over to the new enable
> helper.
> 
> > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index
> > 2b0972b967385..cc18b1c5a17c3 100644
> > --- a/drivers/net/usb/r8152.c
> > +++ b/drivers/net/usb/r8152.c
> 
> [ ... ]
> 
> > @@ -4178,8 +4184,27 @@ static void r8156_ups_flags(struct r8152 *tp)
> >       if (tp->ups_info.aldps)
> >               ups_flags |= UPS_FLAGS_EN_ALDPS;
> >
> > -     if (tp->ups_info.eee)
> > -             ups_flags |= UPS_FLAGS_EN_EEE;
> > +     if (tp->ups_info.eee) {
> > +             switch (tp->version) {
> > +             case RTL_VER_17_QFN68:
> > +                     if (tp->eee_adv & MDIO_EEE_10GT)
> > +                             ups_flags |= UPS_FLAGS_EN_10G_EEE;
> > +                     fallthrough;
> > +             case RTL_VER_16:
> 
> [Severity: Medium]
> 
> Should RTL_VER_17_QFN100 be listed here as well?

No, VER_17_QFN100 doesn't support UPS.

> 
> In rtl_ops_init() the two RTL8159 packages share one identical block:
> 
>         case RTL_VER_17_QFN68:
>         case RTL_VER_17_QFN100:
>                 tp->eee_en              = true;
>                 tp->eee_adv             = MDIO_EEE_100TX |
> MDIO_EEE_1000T | MDIO_EEE_10GT;
>                 tp->eee_adv2            = MDIO_EEE_2_5GT |
> MDIO_EEE_5GT;
>                 ops->init               = r8159_init;
>                 ...
>                 ops->hw_phy_cfg         = r8159_hw_phy_cfg;
>                 ops->autosuspend_en     = rtl8157_runtime_enable;
> 
> So QFN100 advertises the same 100M through 10G EEE capabilities, but with
> only RTL_VER_17_QFN68 matched above it takes the default arm and gets the
> old UPS_FLAGS_EN_EEE encoding that this patch replaces for this chip
> generation.
> 
> > +                     if (tp->eee_adv & MDIO_EEE_100TX)
> > +                             ups_flags |= UPS_FLAGS_EN_100M_EEE;
> > +                     if (tp->eee_adv & MDIO_EEE_1000T)
> > +                             ups_flags |=
> UPS_FLAGS_EN_1000M_EEE;
> > +                     if (tp->eee_adv2 & MDIO_EEE_2_5GT)
> > +                             ups_flags |=
> UPS_FLAGS_EN_2500M_EEE;
> > +                     if (tp->eee_adv2 & MDIO_EEE_5GT)
> > +                             ups_flags |=
> UPS_FLAGS_EN_5000M_EEE;
> > +                     break;
> > +             default:
> > +                     ups_flags |= UPS_FLAGS_EN_EEE;
> > +                     break;
> > +             }
> > +     }
> >
> >       if (tp->ups_info.flow_control)
> >               ups_flags |= UPS_FLAGS_EN_FLOW_CTR; @@ -4230,20
> +4255,33
> > @@ static void r8156_ups_flags(struct r8152 *tp)
> >       case NWAY_2500M_FULL:
> >               ups_flags |= ups_flags_speed(9);
> >               break;
> > +     case NWAY_5000M_FULL:
> > +             ups_flags |= ups_flags_speed(10);
> > +             break;
> > +     case NWAY_10000M_FULL:
> > +             ups_flags |= ups_flags_speed(11);
> > +             break;
> >       default:
> >               break;
> >       }
> >
> > -     switch (tp->ups_info.lite_mode) {
> > -     case 1:
> > -             ups_flags |= 0 << 5;
> > -             break;
> > -     case 2:
> > -             ups_flags |= 2 << 5;
> > +     switch (tp->version) {
> > +     case RTL_VER_16:
> > +     case RTL_VER_17_QFN68:
> >               break;
> > -     case 0:
> >       default:
> > -             ups_flags |= 1 << 5;
> 
> [Severity: Medium]
> 
> Same question for the lite_mode suppression: RTL_VER_17_QFN100 is not
> listed, so it still gets the bit 5/6 lite_mode field that this hunk treats as not
> applicable to this generation.
> 
> > +             switch (tp->ups_info.lite_mode) {
> > +             case 1:
> > +                     ups_flags |= 0 << 5;
> > +                     break;
> > +             case 2:
> > +                     ups_flags |= 2 << 5;
> > +                     break;
> > +             case 0:
> > +             default:
> > +                     ups_flags |= 1 << 5;
> > +                     break;
> > +             }
> >               break;
> >       }
> >
> 
> [ ... ]
> 
> > @@ -4573,9 +4640,28 @@ static void rtl8157_runtime_enable(struct r8152
> *tp, bool enable)
> >               r8153b_u1u2en(tp, false);
> >               r8157_u2p3en(tp, false);
> >               rtl_runtime_suspend_enable(tp, true);
> > +
> > +             switch (tp->version) {
> > +             case RTL_VER_16:
> > +             case RTL_VER_17_QFN68:
> > +                     r8157_ups_en(tp, true);
> > +                     break;
> > +             default:
> > +                     break;
> > +             }
> 
> [Severity: Medium]
> 
> Does this leave RTL_VER_17_QFN100 without UPS entirely?
> 
> rtl_ops_init() assigns ops->autosuspend_en = rtl8157_runtime_enable for both
> RTL_VER_17_QFN68 and RTL_VER_17_QFN100, and __rtl_get_pkg_det()
> results of 0x18/0x1a select RTL_VER_17_QFN100. On runtime suspend the
> chain is:
> 
>         rtl8152_runtime_suspend()
>           -> tp->rtl_ops.autosuspend_en(tp, true)
>              == rtl8157_runtime_enable(tp, true)
>                 -> switch (tp->version) ... default: break;
> 
> so r8157_ups_en() is never reached for that package, while the commit
> message says "support UPS for RTL8157 and RTL8159".
> 
> >       } else {
> >               r8153_queue_wake(tp, false);
> >               rtl_runtime_suspend_enable(tp, false);
> > +
> > +             switch (tp->version) {
> > +             case RTL_VER_16:
> > +             case RTL_VER_17_QFN68:
> > +                     r8157_ups_en(tp, false);
> > +                     break;
> > +             default:
> > +                     break;
> > +             }
> 
> [Severity: Medium]
> 
> Mirror of the above on the resume path.
> 
> Note that r8159_init(), shared by both RTL8159 packages, was converted in this
> same patch:
> 
>         r8157_power_cut_en(tp, false);
>         r8157_ups_en(tp, false);
> 
> so the QFN100 path does get the new disable call at probe/init time, but never
> the enable/disable dispatch during runtime suspend and resume.
> 
> There is a QFN68-only quirk elsewhere in r8159_init() ("Enable u2phy backup
> restore patch"), so a package-specific restriction is plausible.
> Should case RTL_VER_17_QFN100 be added to all four new switches, or
> should the commit message be scoped to the QFN68 package with a note on
> the hardware difference?
> 
> >               r8157_u2p3en(tp, true);
> >               if (tp->udev->speed >= USB_SPEED_SUPER)
> >                       r8153b_u1u2en(tp, true);
> 
> [ ... ]
> 
> > @@ -9130,7 +9216,7 @@ static void r8159_init(struct r8152 *tp)
> >       ocp_write_word(tp, MCU_TYPE_USB, USB_U1U2_TIMER, 500);
> >
> >       r8157_power_cut_en(tp, false);
> > -     r8156_ups_en(tp, false);
> > +     r8157_ups_en(tp, false);
> >       r8153_queue_wake(tp, false);
> >       rtl_runtime_suspend_enable(tp, false);
> >
> 
> --
> Sashiko AI review ·
> https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260908075634.23740-1
> -nic_swsd%40realtek.com

Best,
Chih-Kai

      reply	other threads:[~2026-09-15 11:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08  7:56 [PATCH net-next v3 0/8] r8152: refactor and extend RTL8157/8159 support Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 1/8] r8152: refactor r8156_init Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15  9:48     ` Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 2/8] r8152: support RTL8159 for different packages Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15 11:03     ` Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 3/8] r8152: refactor rtl8156_enable, rtl8156_up, and rtl8156_down Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15 11:24     ` Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 4/8] r8152: refactor r8157_hw_phy_cfg Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15 11:30     ` Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 5/8] r8152: support rtl8157_unload and rtl8157_change_mtu Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15 11:37     ` Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 6/8] r8152: add TGPHY access support Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15 11:52     ` Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 7/8] r8152: support rtl_fc_pause_pkt_en() Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15 11:44     ` Chih Kai Hsu
2026-09-08  7:56 ` [PATCH net-next v3 8/8] r8152: support UPS for RTL8157 and RTL8159 Chih Kai Hsu
2026-09-12 20:19   ` netdev-bot+sashiko
2026-09-15 11:45     ` Chih Kai Hsu [this message]

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=876ed636726542b396dda5a36cbb3242@realtek.com \
    --to=hsu.chih.kai@realtek.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev-bot+sashiko@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®