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. Is there any other way that a device could already exist when board_added() is called? 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
