On 01/29/2013 07:35 PM, Rafael J. Wysocki wrote: > On Tuesday, January 29, 2013 11:35:32 AM Paul Bolle wrote: >> Gu, >> >> On Tue, 2013-01-29 at 10:10 +0800, Gu Zheng wrote: >>> I think cause of the issue you mentioned is the device already exists when we resume. >>> Because we do not really suspend/remove the device when suspend, the device still exists, so >>> we try to add the device when resume will failed. The suspend routine does not match the resume, >>> it seems a bug here. >> >> Thanks. So should the fix here be to actually suspend and remove this >> device? (Note that pciehp_suspend() is now basically a NOP.) > > I think it wouldn't be useful to remove devices on all suspends, but then there > are a few different situations that resume has to consider and handle correctly: > > 1) Device has been removed while suspended. > 2) Device was present before suspend and is still there. > 3) Device has been added while suspended. > Hi Rafael, Though removing devices on all suspends does not seem useful, I do not think let the pciehp_suspend() be a NOP and the resume handle all the conditions is a good way. Do the current pciehp driver's suspend and resume routines follow the pcie specification? And, what's the difficulty to detect and handle the different situations that you mentioned above? Thanks, Gu > Thanks, > Rafael > > -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
