linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Paul Bolle <pebolle@tiscali.nl>, Oliver Neukum <oneukum@suse.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org
Subject: Re: pciehp: errors on resume
Date: Wed, 30 Jan 2013 11:47:54 +0800	[thread overview]
Message-ID: <510897EA.4080605@cn.fujitsu.com> (raw)
In-Reply-To: <3774810.Obias7PJ4I@vostro.rjw.lan>

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
> 
> 



  parent reply	other threads:[~2013-01-30  3:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-28 12:46 pciehp: errors on resume Paul Bolle
2013-01-29  2:10 ` Gu Zheng
2013-01-29 10:35   ` Paul Bolle
2013-01-29 11:35     ` Rafael J. Wysocki
2013-01-29 12:32       ` Paul Bolle
2013-01-29 14:45         ` Martin Mokrejs
2013-01-29 21:41           ` Rafael J. Wysocki
2013-01-30  3:47       ` Gu Zheng [this message]
2013-01-30  3:08     ` Gu Zheng
2013-01-30  8:31       ` Paul Bolle
2013-01-31  6:47         ` Gu Zheng
2013-01-31 10:58           ` Paul Bolle
2013-01-31 13:18             ` Rafael J. Wysocki
2013-01-31 13:16           ` Rafael J. Wysocki
     [not found] ` <512336fb.42d70e0a.73ed.ffffc77eSMTPIN_ADDED_BROKEN@mx.google.com>
2013-02-19  9:28   ` Paul Bolle
2013-02-19 10:07     ` Gu Zheng
     [not found]       ` <20130222074942.GA2398@richard.(null)>
2013-02-22  8:58         ` Gu Zheng
     [not found]     ` <5124284e.09d80e0a.294a.ffff9ee6SMTPIN_ADDED_BROKEN@mx.google.com>
2013-02-20  8:08       ` Paul Bolle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=510897EA.4080605@cn.fujitsu.com \
    --to=guz.fnst@cn.fujitsu.com \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=oneukum@suse.de \
    --cc=pebolle@tiscali.nl \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).