> -----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