From: Simon Horman <horms@kernel.org>
To: hsu.chih.kai@realtek.com
Cc: Simon Horman <horms@kernel.org>,
nic_swsd@realtek.com, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bjorn@mork.no, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, netdev@vger.kernel.org,
davem@davemloft.net
Subject: Re: [PATCH net-next v3 1/2] r8152: add helper functions for PLA/USB OCP registers
Date: Tue, 24 Mar 2026 18:05:32 +0000 [thread overview]
Message-ID: <20260324180532.261099-1-horms@kernel.org> (raw)
In-Reply-To: <20260323082226.2601-451-nic_swsd@realtek.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
r8152: add helper functions for PLA/USB OCP registers
This commit introduces new helper functions (ocp_dword_w0w1,
ocp_word_w0w1, ocp_byte_w0w1, and their _clr_bits/_set_bits variants)
to simplify bitwise operations on PLA/USB OCP registers throughout the
r8152 driver.
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 3b6d4252d34c..ba6dc4dbfd80 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
[ ... ]
> @@ -3875,35 +3873,30 @@ static void r8153c_ups_en(struct r8152 *tp, bool enable)
>
> static void r8156_ups_en(struct r8152 *tp, bool enable)
> {
> - u32 ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_POWER_CUT);
> -
> if (enable) {
> r8156_ups_flags(tp);
>
> - ocp_data |= UPS_EN | USP_PREWAKE | PHASE2_EN;
> - ocp_write_byte(tp, MCU_TYPE_USB, USB_POWER_CUT, ocp_data);
> + ocp_byte_set_bits(tp, MCU_TYPE_USB, USB_POWER_CUT,
> + UPS_EN | USP_PREWAKE | PHASE2_EN);
>
> - ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_2);
> - ocp_data |= UPS_FORCE_PWR_DOWN;
> - ocp_write_byte(tp, MCU_TYPE_USB, USB_MISC_2, ocp_data);
> + ocp_byte_set_bits(tp, MCU_TYPE_USB, USB_MISC_2,
> + UPS_FORCE_PWR_DOWN);
>
> switch (tp->version) {
> case RTL_VER_13:
> case RTL_VER_15:
> - ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_UPHY_XTAL);
> - ocp_data &= ~OOBS_POLLING;
> - ocp_write_byte(tp, MCU_TYPE_USB, USB_UPHY_XTAL, ocp_data);
> + ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_UPHY_XTAL,
> + OOBS_POLLING);
^^^^
Does this actually change the hardware behavior for RTL_VER_13 and
RTL_VER_15?
The old code read a 16-bit word with ocp_read_word() to get
OOBS_POLLING (BIT(8)), then cleared BIT(8) in the local variable, but
wrote it back using ocp_write_byte(). Since ocp_write_byte() masks the
data with 0xff, the write operation would only touch the low 8 bits and
never actually clear BIT(8) in the hardware register. This made the old
code effectively a no-op for clearing OOBS_POLLING.
The new code uses ocp_word_clr_bits() which calls ocp_word_w0w1(), and
that performs a proper 16-bit read-modify-write cycle with
ocp_write_word(). This means BIT(8) will now actually be cleared in the
hardware.
While this looks like it fixes a latent bug where OOBS_POLLING was never
being cleared, the commit message describes this as pure refactoring to
simplify the code with no mention of a behavioral change.
Can you confirm whether this behavioral change is intentional? Should
the commit message document that OOBS_POLLING will now actually be
cleared for RTL_VER_13/15 devices during UPS enable, when it was not
being cleared before?
> break;
> default:
> break;
> }
> } else {
> - ocp_data &= ~(UPS_EN | USP_PREWAKE);
> - ocp_write_byte(tp, MCU_TYPE_USB, USB_POWER_CUT, ocp_data);
> + ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_POWER_CUT,
> + UPS_EN | USP_PREWAKE);
>
> - ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_2);
> - ocp_data &= ~UPS_FORCE_PWR_DOWN;
> - ocp_write_byte(tp, MCU_TYPE_USB, USB_MISC_2, ocp_data);
> + ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_MISC_2,
> + UPS_FORCE_PWR_DOWN);
>
> if (ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0) & PCUT_STATUS) {
> tp->rtl_ops.hw_phy_cfg(tp);
next prev parent reply other threads:[~2026-03-24 18:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 8:22 [PATCH net-next v3 0/2] r8152: add helper functions for PLA/USB/PHY OCP registers Chih Kai Hsu
2026-03-23 8:22 ` [PATCH net-next v3 1/2] r8152: add helper functions for PLA/USB " Chih Kai Hsu
2026-03-24 6:04 ` Hayes Wang
2026-03-25 3:00 ` Chih Kai Hsu
2026-03-24 18:05 ` Simon Horman [this message]
2026-03-25 3:35 ` Chih Kai Hsu
2026-03-25 16:44 ` Simon Horman
2026-03-23 8:22 ` [PATCH net-next v3 2/2] r8152: add helper functions for PHY " Chih Kai Hsu
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=20260324180532.261099-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=bjorn@mork.no \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hsu.chih.kai@realtek.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@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 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.