From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Mikko Vinni <mmvinni@yahoo.com>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Allen Kay <allen.m.kay@intel.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] PCI: Retry BARs restoration for Type 0 headers only
Date: Mon, 16 Apr 2012 23:07:50 +0200 [thread overview]
Message-ID: <201204162307.51168.rjw@sisk.pl> (raw)
In-Reply-To: <CA+55aFyccAfEpECmD5yKYE4AquV1ZsfjRAL4coP39LmkAqrO=w@mail.gmail.com>
On Monday, April 16, 2012, Linus Torvalds wrote:
> On Mon, Apr 16, 2012 at 1:35 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> >
> > Some shortcomings introduced into pci_restore_state() by commit
> > 26f41062f28d ("PCI: check for pci bar restore completion and
> > retry") have been fixed by recent commit ebfc5b802fa76 ("PCI: Fix
> > regression in pci_restore_state(), v3"), but that commit treats
> > all PCI devices as those with Type 0 configuration headers.
>
> Make me happier and just make all of this a helper function again.
> Call that helper function pci_restore_config_space(), and make the
> existing "pci_restore_config_space()" be called
> "pci_restore_config_space_range()" or something. Ok?
Something like this, you mean?
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PCI: Retry BARs restoration for Type 0 headers only
Some shortcomings introduced into pci_restore_state() by commit
26f41062f28d ("PCI: check for pci bar restore completion and
retry") have been fixed by recent commit ebfc5b802fa76 ("PCI: Fix
regression in pci_restore_state(), v3"), but that commit treats
all PCI devices as those with Type 0 configuration headers. That
is not entirely correct, because Type 1 and Type 2 headers have
different layouts. In particular, the area occupied by BARs in
Type 0 config headers contains the secondary status register in
Type 1 ones and it doesn't make sense to retry the restoration of
that register even if the value read back from it after a write is
not the same as the written one (it very well may be different).
For this reason, make pci_restore_state() only retry the restoration
of BARs for Type 0 config headers. This effectively makes it behave
as before commit 26f41062f28d for all header types except for Type 0.
Tested-by: Mikko Vinni <mmvinni@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/pci/pci.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
Index: linux/drivers/pci/pci.c
===================================================================
--- linux.orig/drivers/pci/pci.c
+++ linux/drivers/pci/pci.c
@@ -991,8 +991,8 @@ static void pci_restore_config_dword(str
}
}
-static void pci_restore_config_space(struct pci_dev *pdev, int start, int end,
- int retry)
+static void pci_restore_config_space_range(struct pci_dev *pdev,
+ int start, int end, int retry)
{
int index;
@@ -1002,6 +1002,18 @@ static void pci_restore_config_space(str
retry);
}
+static void pci_restore_config_space(struct pci_dev *pdev)
+{
+ if (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL) {
+ pci_restore_config_space_range(pdev, 10, 15, 0);
+ /* Restore BARs before the command register. */
+ pci_restore_config_space_range(pdev, 4, 9, 10);
+ pci_restore_config_space_range(pdev, 0, 3, 0);
+ } else {
+ pci_restore_config_space_range(pdev, 0, 15, 0);
+ }
+}
+
/**
* pci_restore_state - Restore the saved state of a PCI device
* @dev: - PCI device that we're dealing with
@@ -1015,13 +1027,7 @@ void pci_restore_state(struct pci_dev *d
pci_restore_pcie_state(dev);
pci_restore_ats_state(dev);
- pci_restore_config_space(dev, 10, 15, 0);
- /*
- * The Base Address register should be programmed before the command
- * register(s)
- */
- pci_restore_config_space(dev, 4, 9, 10);
- pci_restore_config_space(dev, 0, 3, 0);
+ pci_restore_config_space(dev);
pci_restore_pcix_state(dev);
pci_restore_msi_state(dev);
next prev parent reply other threads:[~2012-04-16 21:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-13 9:52 "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2 Mikko Vinni
2012-04-13 9:52 ` Mikko Vinni
2012-04-13 19:18 ` [linux-pm] " Rafael J. Wysocki
2012-04-13 19:49 ` Mikko Vinni
2012-04-13 19:49 ` Mikko Vinni
2012-04-13 20:19 ` Rafael J. Wysocki
2012-04-13 20:47 ` Mikko Vinni
2012-04-14 22:11 ` Rafael J. Wysocki
2012-04-15 10:39 ` Mikko Vinni
2012-04-15 10:39 ` Mikko Vinni
2012-04-15 18:30 ` Rafael J. Wysocki
2012-04-15 19:52 ` Rafael J. Wysocki
2012-04-15 20:56 ` Rafael J. Wysocki
2012-04-16 7:23 ` Mikko Vinni
2012-04-16 16:17 ` Rafael J. Wysocki
2012-04-16 18:57 ` Mikko Vinni
2012-04-16 19:59 ` Rafael J. Wysocki
2012-04-16 20:35 ` [PATCH] PCI: Retry BARs restoration for Type 0 headers only Rafael J. Wysocki
2012-04-16 20:35 ` Linus Torvalds
2012-04-16 21:07 ` Rafael J. Wysocki [this message]
2012-04-16 5:15 ` [linux-pm] "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2 Mikko Vinni
2012-04-16 16:14 ` Rafael J. Wysocki
2012-04-15 18:32 ` [PATCH] PCI: Fix regression in pci_restore_state() Rafael J. Wysocki
2012-04-15 18:36 ` Linus Torvalds
2012-04-15 18:47 ` Rafael J. Wysocki
2012-04-15 18:59 ` Linus Torvalds
2012-04-15 19:40 ` Rafael J. Wysocki
2012-04-23 17:03 ` Bjorn Helgaas
2012-04-23 19:53 ` Rafael J. Wysocki
2012-04-23 20:07 ` Don Dutile
2012-04-23 22:33 ` Bjorn Helgaas
2012-04-23 22:33 ` Bjorn Helgaas
2012-04-24 16:03 ` Don Dutile
2012-04-24 17:01 ` Bjorn Helgaas
2012-04-24 17:35 ` Don Dutile
2012-04-27 22:20 ` Bjorn Helgaas
2012-04-15 8:12 ` [linux-pm] "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2 James Courtier-Dutton
2012-04-15 8:12 ` James Courtier-Dutton
2012-04-15 10:47 ` Mikko Vinni
2012-04-15 10:47 ` Mikko Vinni
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=201204162307.51168.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=allen.m.kay@intel.com \
--cc=bhelgaas@google.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mmvinni@yahoo.com \
--cc=torvalds@linux-foundation.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.