All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux PM mailing list <linux-pm@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] PCI / PM: Block races between runtime PM and system sleep
Date: Sun, 26 Jun 2011 14:22:00 +0200	[thread overview]
Message-ID: <201106261422.00690.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1106252235560.10907-100000@netrider.rowland.org>

On Sunday, June 26, 2011, Alan Stern wrote:
> On Fri, 24 Jun 2011, Rafael J. Wysocki wrote:
> 
> > > > I'm still not clear on why the error handler needs to run at this time.
> > > 
> > > Because SATA ports are suspended with the help of the SCSI error handling
> > > mechanism (which Tejun claims is the best way to do that).
> 
> > I've carried out this exercise to see how complicated it is going to be
> > and it doesn't really seem to be _that_ complicated.  The appended patch
> > illustrates this, but it hasn't been tested, so caveat emptor.
> 
> The patch is straightforward enough.  But will it be sufficient?
> 
> Suppose a SATA port is already in runtime suspend when the system sleep
> starts.  Will the error handler be able to do its special job?  I don't
> know...  It may turn out to be necessary for the SATA port to be
> runtime resumed somewhere along the line.

That's correct, but at least in the ususal situation (i.e. sdev_gendev is
not suspended at run time) the patch makes things work when runtime PM
is disabled during system suspend and enabled during system resume.

It still may be necessary to add code to the SATA subsystem if sdev_gendev
is to be suspended at run time for SATA controllers.  I'm not aware of any
of such cases, though.

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Tejun Heo <tj@kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Linux PM mailing list <linux-pm@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH] PCI / PM: Block races between runtime PM and system sleep
Date: Sun, 26 Jun 2011 14:22:00 +0200	[thread overview]
Message-ID: <201106261422.00690.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1106252235560.10907-100000@netrider.rowland.org>

On Sunday, June 26, 2011, Alan Stern wrote:
> On Fri, 24 Jun 2011, Rafael J. Wysocki wrote:
> 
> > > > I'm still not clear on why the error handler needs to run at this time.
> > > 
> > > Because SATA ports are suspended with the help of the SCSI error handling
> > > mechanism (which Tejun claims is the best way to do that).
> 
> > I've carried out this exercise to see how complicated it is going to be
> > and it doesn't really seem to be _that_ complicated.  The appended patch
> > illustrates this, but it hasn't been tested, so caveat emptor.
> 
> The patch is straightforward enough.  But will it be sufficient?
> 
> Suppose a SATA port is already in runtime suspend when the system sleep
> starts.  Will the error handler be able to do its special job?  I don't
> know...  It may turn out to be necessary for the SATA port to be
> runtime resumed somewhere along the line.

That's correct, but at least in the ususal situation (i.e. sdev_gendev is
not suspended at run time) the patch makes things work when runtime PM
is disabled during system suspend and enabled during system resume.

It still may be necessary to add code to the SATA subsystem if sdev_gendev
is to be suspended at run time for SATA controllers.  I'm not aware of any
of such cases, though.

Thanks,
Rafael

  reply	other threads:[~2011-06-26 12:23 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-19 19:49 [PATCH] PCI / PM: Block races between runtime PM and system sleep Rafael J. Wysocki
2011-06-20 14:46 ` Alan Stern
2011-06-20 14:46 ` Alan Stern
2011-06-20 19:42   ` Rafael J. Wysocki
2011-06-20 19:42   ` Rafael J. Wysocki
2011-06-20 21:00     ` Alan Stern
2011-06-20 21:28       ` Rafael J. Wysocki
2011-06-20 21:28       ` Rafael J. Wysocki
2011-06-21 14:52         ` Alan Stern
2011-06-21 14:52         ` Alan Stern
2011-06-21 23:49           ` Rafael J. Wysocki
2011-06-21 23:49           ` Rafael J. Wysocki
2011-06-22 14:20             ` Alan Stern
2011-06-22 14:20             ` Alan Stern
2011-06-23 17:46               ` Rafael J. Wysocki
2011-06-23 17:46               ` Rafael J. Wysocki
2011-06-23 18:35                 ` Alan Stern
2011-06-23 20:49                   ` Rafael J. Wysocki
2011-06-23 20:49                   ` Rafael J. Wysocki
2011-06-23 21:02                     ` Alan Stern
2011-06-23 21:02                     ` Alan Stern
2011-06-23 21:16                       ` Rafael J. Wysocki
2011-06-23 21:16                       ` Rafael J. Wysocki
2011-06-23 21:38                         ` Alan Stern
2011-06-23 22:35                           ` Rafael J. Wysocki
2011-06-23 22:35                           ` Rafael J. Wysocki
2011-06-23 22:59                             ` Rafael J. Wysocki
2011-06-23 22:59                             ` Rafael J. Wysocki
2011-06-26  2:39                               ` Alan Stern
2011-06-26 12:22                                 ` Rafael J. Wysocki [this message]
2011-06-26 12:22                                   ` Rafael J. Wysocki
2011-06-26  2:39                               ` Alan Stern
2011-06-23 21:38                         ` Alan Stern
2011-06-23 18:35                 ` Alan Stern
2011-06-20 21:00     ` Alan Stern
2011-06-19 19:49 Rafael J. Wysocki

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=201106261422.00690.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.