> -----Original Message----- > From: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > Sent: Monday, November 6, 2023 5:09 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: 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 08:54:50 [+0000], Li, Meng wrote: > > > 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 > > Right. > > > 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. > > Okay. I somehow mapped it that you try to add this to xhci. > The suggested replacement should cover it. Better if we could get rid of it ;) > generic_handle_irq_safe(dev->irq) works find on my board, there is no calltrace anymore. Will you create a patch in later? Thanks, Limeng > > Thanks, > > Limeng > > Sebastian