[PATCH net] r8152: handle the return value of usb_reset_device()

[PATCH net] r8152: handle the return value of usb_reset_device()

[Chih Kai Hsu]

If usb_reset_device() returns a negative error code, stop the
process of probing.

Fixes: 10c3271712f5 ("r8152: disable the ECM mode")
Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com>
---
 drivers/net/usb/r8152.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1ace1d2398c9..b1268553cd70 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -9851,7 +9851,12 @@ static int rtl8152_probe_once(struct usb_interface *intf,
 	struct net_device *netdev;
 	int ret;
 
-	usb_reset_device(udev);
+	ret = usb_reset_device(udev);
+	if (ret < 0) {
+		dev_err(&intf->dev, "USB reset failed, errno=%d\n", ret);
+		return ret;
+	}
+
 	netdev = alloc_etherdev(sizeof(struct r8152));
 	if (!netdev) {
 		dev_err(&intf->dev, "Out of memory\n");
-- 
2.34.1

RE: [PATCH net] r8152: handle the return value of usb_reset_device()

[Hayes Wang]

Chih Kai Hsu <hsu.chih.kai@realtek.com>
> Sent: Thursday, June 4, 2026 5:23 PM
> To: kuba@kernel.org; davem@davemloft.net
> Cc: netdev@vger.kernel.org; nic_swsd <nic_swsd@realtek.com>;
> linux-kernel@vger.kernel.org; linux-usb@vger.kernel.org; Chih Kai Hsu
> <hsu.chih.kai@realtek.com>
> Subject: [PATCH net] r8152: handle the return value of usb_reset_device()
> 
> If usb_reset_device() returns a negative error code, stop the process of
> probing.
> 
> Fixes: 10c3271712f5 ("r8152: disable the ECM mode")
> Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com>

Reviewed-by: Hayes Wang <hayeswang@realtek.com>

Best Regards,
Hayes

Re: [PATCH net] r8152: handle the return value of usb_reset_device()

[Andrew Lunn]

On Thu, Jun 04, 2026 at 05:22:47PM +0800, Chih Kai Hsu wrote:
> If usb_reset_device() returns a negative error code, stop the
> process of probing.
> 
> Fixes: 10c3271712f5 ("r8152: disable the ECM mode")

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

Does this bother people?

	Andrew

RE: [PATCH net] r8152: handle the return value of usb_reset_device()

[Chih Kai Hsu]

On 04/06/26 8:54 pm, Andrew Lunn wrote:

> On Thu, Jun 04, 2026 at 05:22:47PM +0800, Chih Kai Hsu wrote:
> > If usb_reset_device() returns a negative error code, stop the process
> > of probing.
> >
> > Fixes: 10c3271712f5 ("r8152: disable the ECM mode")
> 
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> 
> Does this bother people?
Yes, it does.
If the driver does not return early when receiving an error code from usb_reset_device(),
the subsequent execution will trigger a kernel call trace.

> 
>         Andrew

Best Regards,
Chih Kai

Re: [PATCH net] r8152: handle the return value of usb_reset_device()

[Andrew Lunn]

On Fri, Jun 05, 2026 at 02:42:34AM +0000, Chih Kai Hsu wrote:
> On 04/06/26 8:54 pm, Andrew Lunn wrote:
> 
> > On Thu, Jun 04, 2026 at 05:22:47PM +0800, Chih Kai Hsu wrote:
> > > If usb_reset_device() returns a negative error code, stop the process
> > > of probing.
> > >
> > > Fixes: 10c3271712f5 ("r8152: disable the ECM mode")
> > 
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > 
> > Does this bother people?
> Yes, it does.
> If the driver does not return early when receiving an error code from usb_reset_device(),
> the subsequent execution will trigger a kernel call trace.

Please include a link to such a bug report, kernel call trace etc, to
to show it bothers somebody. Do you have the hardware and can trigger
this?

	Andrew

RE: [PATCH net] r8152: handle the return value of usb_reset_device()

[Chih Kai Hsu]

On 05/06/26 12:04 pm, Andrew Lunn wrote:

> On Fri, Jun 05, 2026 at 02:42:34AM +0000, Chih Kai Hsu wrote:
> > On 04/06/26 8:54 pm, Andrew Lunn wrote:
> >
> > > On Thu, Jun 04, 2026 at 05:22:47PM +0800, Chih Kai Hsu wrote:
> > > > If usb_reset_device() returns a negative error code, stop the
> > > > process of probing.
> > > >
> > > > Fixes: 10c3271712f5 ("r8152: disable the ECM mode")
> > >
> > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.h
> > > tml
> > >
> > > Does this bother people?
> > Yes, it does.
> > If the driver does not return early when receiving an error code from
> > usb_reset_device(), the subsequent execution will trigger a kernel call trace.
> 
> Please include a link to such a bug report, kernel call trace etc, to to show it
> bothers somebody. Do you have the hardware and can trigger this?

If the driver ignores the error from usb_reset_device(), I get the following call trace.

[ 2405.758846] Call Trace:
[ 2405.758853]  <TASK>
[ 2405.758872]  usb_probe_interface+0x15b/0x350
[ 2405.758895]  really_probe+0xdb/0x340
[ 2405.758910]  ? pm_runtime_barrier+0x55/0x90
[ 2405.758926]  __driver_probe_device+0x78/0x140
[ 2405.758940]  driver_probe_device+0x1f/0xa0
[ 2405.75895s3]  ? __pfx___driver_attach+0x10/0x10
[ 2405.758965]  __driver_attach+0xcb/0x1e0
[ 2405.758979]  bus_for_each_dev+0x82/0xd0
[ 2405.758992]  bus_add_driver+0x12f/0x210
[ 2405.759035]  ? __pfx_rtl8152_driver_init+0x10/0x10 [r8152]
[ 2405.759069]  driver_register+0x75/0xe0
[ 2405.759079]  usb_register_driver+0x99/0x150
[ 2405.759092]  ? usb_register_device_driver.cold+0x3a/0x40
[ 2405.759107]  do_one_initcall+0x58/0x300
[ 2405.759124]  do_init_module+0x84/0x280
[ 2405.759138]  init_module_from_file+0x8a/0xe0
[ 2405.759160]  idempotent_init_module+0x114/0x310
[ 2405.759178]  __x64_sys_finit_module+0x6d/0xd0
[ 2405.759190]  ? syscall_trace_enter+0x173/0x1f0
[ 2405.759205]  do_syscall_64+0x7e/0x250
[ 2405.759216]  ? syscall_exit_work+0xb0/0x1b0
[ 2405.759228]  ? do_syscall_64+0xb6/0x250
[ 2405.759239]  ? count_memcg_events+0x15d/0x230
[ 2405.759251]  ? handle_mm_fault+0x248/0x360
[ 2405.759264]  ? do_user_addr_fault+0x21a/0x690
[ 2405.759278]  ? irqentry_exit_to_user_mode+0x2c/0x1c0
[ 2405.759290]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 2405.759300] RIP: 0033:0x7f7fa09010cd
[ 2405.759335] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 03 4d 0f 00 f7 d8 64 89 01 48
[ 2405.759344] RSP: 002b:00007fff7deaa418 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 2405.759356] RAX: ffffffffffffffda RBX: 0000555bbeb58750 RCX: 00007f7fa09010cd
[ 2405.759362] RDX: 0000000000000000 RSI: 0000555bb09c65ee RDI: 0000000000000003
[ 2405.759368] RBP: 00007fff7deaa4d0 R08: 0000000000000000 R09: 00007fff7deaa460
[ 2405.759375] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 2405.759380] R13: 0000555bbeb583c0 R14: 0000555bb09c65ee R15: 0000000000000000
[ 2405.759395]  </TASK>
[ 2405.759400] ---[ end trace 0000000000000000 ]---

> 
>         Andrew

Best Regards,
Chih-Kai

Re: [PATCH net] r8152: handle the return value of usb_reset_device()

[Andrew Lunn]

On Fri, Jun 05, 2026 at 06:26:46AM +0000, Chih Kai Hsu wrote:
> On 05/06/26 12:04 pm, Andrew Lunn wrote:
> 
> > On Fri, Jun 05, 2026 at 02:42:34AM +0000, Chih Kai Hsu wrote:
> > > On 04/06/26 8:54 pm, Andrew Lunn wrote:
> > >
> > > > On Thu, Jun 04, 2026 at 05:22:47PM +0800, Chih Kai Hsu wrote:
> > > > > If usb_reset_device() returns a negative error code, stop the
> > > > > process of probing.
> > > > >
> > > > > Fixes: 10c3271712f5 ("r8152: disable the ECM mode")
> > > >
> > > > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.h
> > > > tml
> > > >
> > > > Does this bother people?
> > > Yes, it does.
> > > If the driver does not return early when receiving an error code from
> > > usb_reset_device(), the subsequent execution will trigger a kernel call trace.
> > 
> > Please include a link to such a bug report, kernel call trace etc, to to show it
> > bothers somebody. Do you have the hardware and can trigger this?
> 
> If the driver ignores the error from usb_reset_device(), I get the following call trace.

O.K, great.

We have had a lot of AI driven bug fixes for theoretical issues, which
in practice are unlikely to happen. We want to consider such patches
as just ongoing development work, and merge them via net-next, and not
backport them to stable.

From the commit message it is not always clear if a patch is just
fixing a theoretical problem, or a real problem which bothers
people. So sometimes we need to ask....

Including in the commit message a Reported-by, or a link to issue
report, makes it very clear it is a real issue which bothers somebody,
so we don't need to ask. Please consider this with further
submissions.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew