From: Chih Kai Hsu <hsu.chih.kai@realtek.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
"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>,
"mail@birger-koblitz.de" <mail@birger-koblitz.de>
Subject: RE: [PATCH net-next v7 05/10] r8152: fix up and down register settings for RTL8156/8156B/8157/8159
Date: Thu, 22 Oct 2026 08:08:26 +0000 [thread overview]
Message-ID: <0595476b3b8f4aefa6f9eb990b17c7d0@realtek.com> (raw)
In-Reply-To: <20261021005212.1254979-1-kuba@kernel.org>
On Wednesday, October 21, 2026 8:52 AM, Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this email has
> considered the AI review valid, or at least plausible.
> ---
> r8152: fix up and down register settings for RTL8156/8156B/8157/8159
>
> This commit corrects several up/down and OOB register settings for the
> RTL8156, RTL8156B, RTL8157 and RTL8159 chips, following the earlier
> per-generation split of the up/down callbacks. It changes the PLA_RCR1,
> USB_SPEED_OPTION, Clear_SDR, PLA_BDC_CR/PLA_OOB_CTRL and OOB
> PLA_RMS/PLA_MTPS settings, and drops PLA_MCU_SPDWN_EN handling from
> rtl8157_up()/rtl8157_down().
>
> > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index
> > b245b63fb6aaf..045460a35f383 100644
> > --- a/drivers/net/usb/r8152.c
> > +++ b/drivers/net/usb/r8152.c
>
> [ ... ]
>
> > @@ -6938,8 +6937,18 @@ static void r8156_enter_oob(struct r8152 *tp)
> > rtl_disable(tp);
> > rtl_reset_bmu(tp);
> >
> > - ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, 1522);
> > - ocp_write_byte(tp, MCU_TYPE_PLA, PLA_MTPS, MTPS_DEFAULT);
> > + switch (tp->version) {
> > + case RTL_VER_16:
> > + case RTL_VER_17_QFN68:
> > + case RTL_VER_17_QFN100:
>
> [Severity: Medium]
> This patch has three Fixes: tags:
>
> Fixes: 195aae321c82 ("r8152: support new chips")
> Fixes: fd3c7d080df5 ("r8152: Add support for the RTL8157 hardware")
> Fixes: ad2a55b63b41 ("r8152: Add support for the RTL8159 chip")
>
> Will it apply and build on the trees those tags point to?
>
> RTL_VER_17_QFN68 and RTL_VER_17_QFN100 come from an earlier patch in
> this series, "r8152: split RTL_VER_17 into QFN68 and QFN100 package
> variants".
> Before that patch the enum only has RTL_VER_17.
>
> rtl8157_up() and rtl8157_down() also only exist after "r8152: split
> rtl8156_enable/up/down into per-generation functions", which is described as
> no functional change. Before that patch there is one shared
> rtl8156_up() with tp->version >= RTL_VER_16 and tp->version < RTL_VER_16
> checks.
>
> So a stable backport would either conflict or need both non-fix patches as
> prerequisites. One of them is the package detection change, which makes an
> unrecognised PLA_PKG_DET value fall back to RTL_VER_UNKNOWN.
>
> Could these fixes go to net separately, written against the pre-refactor code? Or
> could the commit message at least name the prerequisites?
I will reorder the series so the fixes come first, written against the pre-refactor code,
with the refactor rebased on top.
>
> > + ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, 1526);
> > + ocp_write_byte(tp, MCU_TYPE_PLA, PLA_MTPS, 10 * 1024 /
> 64);
> > + break;
>
> [ ... ]
>
> > @@ -6997,6 +7008,11 @@ static void rtl8157_up(struct r8152 *tp)
> > }
> >
> > r8153_aldps_en(tp, true);
> > +
> > + /* Enable Clear_SDR */
> > + ocp_byte_set_bits(tp, MCU_TYPE_USB, 0xd378, BIT(7));
> > + /* Clear SDR bit */
> > + ocp_word_clr_bits(tp, MCU_TYPE_USB, 0xcd06, BIT(15));
> > }
>
> [Severity: High]
> The commit message says:
>
> - RTL8156B (VER_13/15) need Clear_SDR enabled on up, which nothing
> ever did for them.
>
> Is the RTL8156B part missing from this patch? These are the only Clear_SDR
> writes the patch adds. rtl8157_up() is only used for RTL_VER_16,
> RTL_VER_17_QFN68 and RTL_VER_17_QFN100.
>
> In rtl_ops_init(), RTL_VER_13 and RTL_VER_15 are bound to rtl8156_up():
>
> case RTL_VER_12:
> case RTL_VER_13:
> tp->support_2500full = 1;
> fallthrough;
> case RTL_VER_15:
> ...
> ops->up = rtl8156_up;
>
> This patch does not change rtl8156_up(), and it still writes no Clear_SDR
> register:
>
> r8156_exit_oob(tp);
>
> ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
> PLA_MCU_SPDWN_EN);
>
> ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
> RG_PWRDN_EN | ALL_SPEED_OFF);
>
> ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_BUF_TH,
> 0x00600400);
> ...
> r8153_aldps_en(tp, true);
> r8153_u2p3en(tp, true);
>
> So every open or resume on an RTL8156B goes through ops->up ->
> rtl8156_up() without the Clear_SDR enable. The later patches in the series don't
> add it to rtl8156_up() either.
>
> Should rtl8156_up() get the RTL8156B Clear_SDR writes under an
> RTL_VER_13/RTL_VER_15 check, or should this bullet come out of the commit
> message? The 0xd378/0xcd06 writes used for RTL8157/8159 can't be assumed
> to apply to RTL8156B.
I accidentally dropped the corresponding code; I will add it back.
Best Regards,
Chih-Kai
next prev parent reply other threads:[~2026-10-22 8:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 8:18 [PATCH net-next v7 00/10] r8152: refactor and extend RTL8157/8159 support Chih Kai Hsu
2026-10-14 8:18 ` [PATCH net-next v7 01/10] r8152: split r8156_init by generation and factor out wait_autoload_done Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-21 0:52 ` Jakub Kicinski
2026-10-22 7:55 ` Chih Kai Hsu
2026-10-14 8:18 ` [PATCH net-next v7 02/10] r8152: add new init writes for RTL8156/8156B/8157/8159 Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-14 8:18 ` [PATCH net-next v7 03/10] r8152: split RTL_VER_17 into QFN68 and QFN100 package variants Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-14 8:18 ` [PATCH net-next v7 04/10] r8152: split rtl8156_enable/up/down into per-generation functions Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-14 8:18 ` [PATCH net-next v7 05/10] r8152: fix up and down register settings for RTL8156/8156B/8157/8159 Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-21 0:52 ` Jakub Kicinski
2026-10-22 8:08 ` Chih Kai Hsu [this message]
2026-10-14 8:19 ` [PATCH net-next v7 06/10] r8152: split r8157_hw_phy_cfg into RTL8157 and RTL8159 variants Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-14 8:19 ` [PATCH net-next v7 07/10] r8152: add rtl8157_unload and rtl8157_change_mtu Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-14 8:19 ` [PATCH net-next v7 08/10] r8152: add TGPHY register access for RTL8157 and RTL8159 Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-21 0:52 ` Jakub Kicinski
2026-10-22 11:30 ` Chih Kai Hsu
2026-10-14 8:19 ` [PATCH net-next v7 09/10] r8152: extract rtl_fc_pause_pkt_en() and apply it to RTL8156/8157/8159 Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-14 8:19 ` [PATCH net-next v7 10/10] r8152: enable UPS for RTL8157 and RTL8159 QFN68 Chih Kai Hsu
2026-10-15 8:20 ` sashiko-bot
2026-10-21 0:52 ` Jakub Kicinski
2026-10-22 12:11 ` Chih Kai Hsu
2026-10-14 8:25 ` [PATCH net-next v7 00/10] r8152: refactor and extend RTL8157/8159 support netdev-bot+sinfo
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=0595476b3b8f4aefa6f9eb990b17c7d0@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=mail@birger-koblitz.de \
--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 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.