linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: linux-pm <linux-pm@lists.osdl.org>, linux-pci@atrey.karlin.mff.cuni.cz
Cc: linux-kernel@vger.kernel.org, greg@kroah.com
Subject: Re: [RFC] firmware leaves device in D3hot at boot
Date: Thu, 23 Jun 2005 22:28:07 -0400	[thread overview]
Message-ID: <20050624022807.GF28077@tuxdriver.com> (raw)
In-Reply-To: <20050623191451.GA20572@tuxdriver.com>

On Thu, Jun 23, 2005 at 03:14:52PM -0400, John W. Linville wrote:

> This issue regarding D3hot->D0 state transitions seems like a piece
> of minutiae that we should not force individual drivers to address.

After some thought, I'm inclined to think that the patch below is
the right one.  It unconditionally saves and restores the PCI config
registers when pci_enable_device is called.  Although this is often
(usually?) unnecessary, it seems like a safe thing to do and it should
not be a performance-sensitive path.  The code to check for whether
or not this is necessary would be a little harder to read IMHO,
so I think this is warranted.

The comment block at the head of pci_enable_device says "Initialize
device before it's used by a driver" which implies that saving and
restoring the PCI config should be safe if the function is used
as intended.  Out of ~318 files referencing pci_enable_device, ~47
of them (~15%) of them are actually calling pci_enable_device from
multiple places.  Most of these that I've looked at so far are calling
it from ->resume as well as ->probe.  A few drivers seem to call
pci_enable_device from one of several branches within the same if
statement inside the ->probe function, but I figure thoese examples
are equivalent to just calling it from a single place.

Is calling pci_enable_device from ->resume really proper?  If not,
what should those devices be doing?  I'll be happy to take a glance
at all the drivers calling pci_enable_device multiple times if there
is general agreement that the approach below would be acceptable.

What do you all think?

John

P.S.  Below is the one-liner I used to determine who is accessing
pci_enable_device.  It probably misses a few strays...

# Generate list of calls to pci_enable_device
find . -type f -name '*.c' -exec \
	grep -H pci_enable_device[[:space:]]*\(.*\).*[\;\)] {} \; | \
	cut -f1 -d: | sort | uniq -c

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -399,10 +399,23 @@ pci_enable_device(struct pci_dev *dev)
 {
 	int err;
 
+	/* Need to save the PCI config space because some firmware
+	   will leave devices in D3hot on boot and some devices
+	   will loose config (incl BARs) in D3hot->D0 PM state
+	   transition.	Could make drivers do this, but better to
+	   leave them ignorant of PCI PM trivia...
+	*/
+	if (err = pci_save_state(dev))
+		return err;
+
 	if ((err = pci_enable_device_bars(dev, (1 << PCI_NUM_RESOURCES) - 1)))
 		return err;
 	pci_fixup_device(pci_fixup_enable, dev);
 	dev->is_enabled = 1;
+
+	if (err = pci_restore_state(dev))
+		return err;
+
 	return 0;
 }
 
-- 
John W. Linville
linville@tuxdriver.com

  reply	other threads:[~2005-06-24  2:28 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-23 19:14 [RFC] firmware leaves device in D3hot at boot John W. Linville
2005-06-24  2:28 ` John W. Linville [this message]
2005-06-30 17:10   ` Greg KH
2005-07-01  1:41     ` John W. Linville
2005-07-01  2:26       ` [patch 2.6.12] pci: restore BAR values in pci_enable_device John W. Linville
2005-07-01  2:26       ` [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars John W. Linville
2005-07-02  7:29         ` Grant Grundler
2005-07-02  8:09           ` Russell King
2005-07-05 20:05             ` Matthew Wilcox
2005-07-05 21:46               ` Russell King
2005-07-05 23:34                 ` Ivan Kokshaysky
2005-07-06  7:46                   ` Russell King
2005-07-08  0:57                   ` John W. Linville
2005-07-08  0:59                     ` [patch 2.6.13-rc2] pci: restore BAR values in pci_set_power_state for D3hot->D0 John W. Linville
2005-07-08  3:43                       ` [linux-pm] " david-b
2005-07-08 12:37                         ` John W. Linville
2005-07-08  3:11                     ` [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars David S. Miller
2005-07-08  5:51                       ` Ivan Kokshaysky
2005-07-08  6:35                         ` David S. Miller
2005-07-08  7:03                           ` Ivan Kokshaysky
2005-07-08  7:33                             ` David S. Miller
2005-07-08  8:20                               ` Ivan Kokshaysky
2005-07-08 18:34                                 ` [patch 2.6.13-rc2] pci: restore BAR values from pci_set_power_state for D3hot->D0 John W. Linville
2005-07-08 19:08                                   ` David S. Miller
2005-07-10 17:53                                   ` Ivan Kokshaysky
2005-07-11 12:48                                   ` Lennert Buytenhek
2005-07-11 13:15                                     ` John W. Linville
2005-07-11 13:19                                       ` [patch 2.6.13-rc2] PCI: Add symbol exports for pci_restore_bars John W. Linville
2005-07-11 17:18                                         ` Greg KH
2005-07-11 17:36                                           ` John W. Linville
2005-07-11 17:38                                             ` [patch 2.6.13-rc2] PCI: Add GPL symbol export " John W. Linville
2005-07-12  2:28                                   ` [patch 2.6.13-rc2] pci: restore BAR values from pci_set_power_state for D3hot->D0 Adam Belay
2005-07-13 17:34                                     ` John W. Linville
2005-07-26 23:49                                   ` Greg KH
2005-07-27  1:36                                     ` John W. Linville
2005-07-27 14:12                                       ` John W. Linville
2005-07-27 14:19                                         ` [patch 2.6.13-rc3] pci: restore BAR values after D3hot->D0 for devices that need it John W. Linville
2005-07-31 19:36                                           ` Ralf Baechle
2005-08-02 17:31                                             ` Greg KH
2005-08-02 16:41                                           ` Jesse Brandeburg
2005-09-14 13:52                                           ` [patch 2.6.14-rc1] pci: only call pci_restore_bars at boot John W. Linville
2005-09-14 15:08                                             ` Jeff Garzik
2005-09-14 16:26                                               ` David S. Miller
2005-09-14 16:47                                                 ` John W. Linville
2005-09-14 18:22                                                 ` Ivan Kokshaysky
2005-07-05 17:46           ` [patch 2.6.12 (repost w/ corrected subject)] pci: restore BAR values in pci_enable_device_bars John W. Linville
2005-07-18 12:17             ` Grant Grundler

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=20050624022807.GF28077@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-pm@lists.osdl.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 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).