> I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and > pci_disable_msi(). Suspend calls mei_reset with request for disabling interrupts I'm pretty sure I do free_irq and I do disable_msi in the suspend (Hope we are looking at the same code) I don't see a call to mei_enable_interrupts() from > mei_me_pci_resume(). I don't think mei_enable_interrupts() is used > anywhere. pci_dev_msi_enabled() enables the interrupts in > mei_me_pci_resume() looks like. Again here we call mei_reset with request of enabling the interrupts > > However, I did notice one thing, if pci_dev_msi_enabled() returns false, > request_threaded_irq() is called with IRQF_SHARED. Again might just be > fine, it leads me to the next question. > Is the MSI disabled on your platform? > mei_me_pci_suspend() has code that runs after disabling interrupts. Does > this need to be split into suspend() and suspend_noirq() ops, since the IRQ > could be shared? If you don't have msi I think usually it is shared with some USB device, but I haven't seen that in my code I will check again. Would other resume block the interrupt line? > It is a possibility if pci_enable_msi() takes longer in resume path and > pci_dev_msi_enabled() returns false, then IRQF_SHARED is requested. > > Don't know if this helpful, but I thought I would ask just in case, it helps you > think of something you didn't before. Please let me know if you need help > gathering data from my system. Thanks for ideas I will check that points. Thanks Tomas > -- Shuah > > Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research > America (Silicon Valley) shuah.kh at samsung.com | (970) 672-0658
