On 01/30/2013 04:31 PM, Paul Bolle wrote: > On Wed, 2013-01-30 at 11:08 +0800, Gu Zheng wrote: >> On 01/29/2013 06:35 PM, Paul Bolle wrote: >>> So should the fix here be to actually suspend and remove this >>> device? (Note that pciehp_suspend() is now basically a NOP.) >> The resume routine should handle all possible situations here. As Rafael said, >> in some cases there's no way to tell the difference between "internal" and "external". >> If this problem seriously disturbs you, you can avoid this feature. > > 0) Actually, before v3.7 I was unaware of pciehp. And if these errors > hadn't shown up I would still be. I'm only using pciehp because Fedora > 17 has CONFIG_HOTPLUG_PCI_PCIE enabled in its kernel config. > >> But the better way is >> reporting a bug report on the bugzilla, it can call more developers to fix this issue. > > 1) Fine with me, though my experience is that kernel bugs should first > be discussed on the appropriate mailinglist. > > 2) Regarding the errors I see at resume: it seems that if a device > already exists when board_added() is called, this almost certainly means > we're resuming with the same device we suspended with. So there's no > reason to send errors to the log. No, It's hard to detect whether the existed device is the one you want to resume. Maybe the existed device was added during suspend, and the one you really want to resume was removed. > > Is there any other way that a device could already exist when > board_added() is called? It's hard to say, the pcie device is a typical one. > > > Paul Bolle > > -- 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
