From: Simon Horman <horms@kernel.org>
To: Chih Kai Hsu <hsu.chih.kai@realtek.com>
Cc: nic_swsd <nic_swsd@realtek.com>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"bjorn@mork.no" <bjorn@mork.no>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCH net-next v3 1/2] r8152: add helper functions for PLA/USB OCP registers
Date: Wed, 25 Mar 2026 16:44:24 +0000 [thread overview]
Message-ID: <20260325164424.GG111839@horms.kernel.org> (raw)
In-Reply-To: <9be8e74588604d9d9f5c10d33c6881e3@realtek.com>
On Wed, Mar 25, 2026 at 03:35:24AM +0000, Chih Kai Hsu wrote:
> On 25/03/26 2:06 am, Simon Horman 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.
> >
> > 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.
> >
> The OOBS_POLLING (BIT(8)) must be cleared in the USB_UPHY_XTAL register.
> The old code using ocp_write_byte() is wrong.
I expect the best way forward here is to submit a fix for (only) that
problem to net-next.
>
> > 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.
> >
> I will mention this fix in the v4 commit message.
>
> Thanks for your review.
>
> Best Regards,
> Chih-Kai
next prev parent reply other threads:[~2026-03-25 16:44 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
2026-03-25 3:35 ` Chih Kai Hsu
2026-03-25 16:44 ` Simon Horman [this message]
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=20260325164424.GG111839@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.