> -----Original Message-----
> From: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> Sent: Monday, November 6, 2023 4:28 PM
> To: Li, Meng <Meng.Li@xxxxxxxxxxxxx>
> Cc: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>; Steven Rostedt
> <rostedt@xxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; USB mailing list
> <linux-usb@xxxxxxxxxxxxxxx>; linux-rt-users <linux-rt-users@xxxxxxxxxxxxxxx>
> Subject: Re: RE: USB: add check to detect host controller hardware removal
>
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> On 2023-11-06 03:02:42 [+0000], Li, Meng wrote:
> > > Good. Meng Li, can you test a patch that replaces the
> > > local_irq_disable() - usb_hcd_irq() - local_irq_enable() lines with
> > > a single call to generic_handle_irq_safe()?
> >
> > It needs an irq number as parameter, what I should pass to this
> > function, 0 or dev->irq or other value?
>
> dev->irq is what it asks for. I would really appreciate if you would
> instead use the sysfs interface to remove the device prior physically removing
> it. This should solve your trouble.
>
This is not my original issue that I encountered.
I agree that we should remove the device from sys interface firstly, and then do hot-plug action.
My original issue was the calltrace on RT kernel if I remove the device from sys interface.
# echo 1 > /sys/bus/pci/devices/0001:01:00.0/remove
xhci_hcd 0001:01:00.0: remove, state 1
usb usb2: USB disconnect, device number 1
usb 2-4: USB disconnect, device number 2
xhci_hcd 0001:01:00.0: USB bus 2 deregistered
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46
in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 765, name: sh
root@nxp-ls1043:preempt_count: 0, expected: 0
RCU nest depth: 0, expected: 0
~# CPU: 0 PID: 765 Comm: sh Tainted: G W 6.1.57-rt10-yocto-preempt-rt #1
Hardware name: LS1043A RDB Board (DT)
Call trace:
dump_backtrace.part.0+0xc8/0xd4
show_stack+0x20/0x30
dump_stack_lvl+0x6c/0x88
dump_stack+0x18/0x34
__might_resched+0x160/0x1c0
rt_spin_lock+0x38/0xb0
xhci_irq+0x44/0x16d0
usb_hcd_irq+0x38/0x5c
usb_hcd_pci_remove+0x84/0x14c
xhci_pci_remove+0x78/0xc0
pci_device_remove+0x44/0xcc
device_remove+0x54/0x8c
device_release_driver_internal+0x1ec/0x260
device_release_driver+0x20/0x30
pci_stop_bus_device+0x8c/0xcc
pci_stop_and_remove_bus_device_locked+0x28/0x44
remove_store+0xa0/0xb0
dev_attr_store+0x20/0x34
sysfs_kf_write+0x4c/0x5c
kernfs_fop_write_iter+0x128/0x1f0
vfs_write+0x1c0/0x2f0
ksys_write+0x78/0x110
__arm64_sys_write+0x24/0x30
invoke_syscall+0x5c/0x130
el0_svc_common.constprop.0+0x4c/0xf4
do_el0_svc+0x34/0xc0
el0_svc+0x2c/0x84
el0t_64_sync_handler+0xf4/0x120
el0t_64_sync+0x18c/0x190
and then I checked the commit log to get which commit introduced this issue.
I found out the commit is
commit c548795abe0d3520b74e18f23ca0a0d72deddab9
Author: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
Date: Wed Jun 9 17:34:27 2010 -0400
USB: add check to detect host controller hardware removal
And then, Alan Stern told me the background of this issue. so, I started to do hotplug operation on my board to see what symptom on my nxp-ls1043/6 board.
And then there were lots of discussion followed.
Thanks,
Limeng
> > Thanks,
> > Limeng
>
> Sebastian
