linux-kernel - Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Dec 2008 17:45:12 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Frans Pop <elendil@...net.nl>, Greg KH <greg@...ah.com>,
	Ingo Molnar <mingo@...e.hu>, jbarnes@...tuousgeek.org,
	lenb@...nel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tiwai@...e.de, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Regression from 2.6.26: Hibernation (possibly suspend) broken
 on Toshiba R500 (bisected)

On Fri, 5 Dec 2008, Rafael J. Wysocki wrote:
> > 
> > Maybe the PIO window matters? Any magic suspend registers are usually in 
> > PIO space, not in MMIO space. Did /proc/ioports change, and if so, how? 
> 
> |18,20c18,19
> |< 1000-1fff : PCI Bus 0000:03
> |<   1000-10ff : PCI CardBus 0000:04
> |<   1400-14ff : PCI CardBus 0000:04
> |---
> |> 1000-10ff : PCI CardBus 0000:04
> |> 1400-14ff : PCI CardBus 0000:04
> 
> where the first one is with my patch and the second one is with the "no sizing
> for transparent bridges" patch.  No difference to my eyes, if the "transparent"
> bridge is really transparent. :-)

Well, there _is_ a difference, although a subtle one. Not for the Cardbus 
card itself, but for decode of _non-cardbus_ IO ranges.

IOW, if there is a secret magic IO port that we don't know about at (say) 
address 0x1100, then the difference is that now there would be a fight 
over who would take it.

And I think I actually have found some secret IO decoding in ICH7. Damn. I 
_hate_ it when Intel does that. I asked (long ago) that Intel double-check 
that we have quirks for all their idiotic magic IO addresses, but they 
clearly never did that.

Or maybe I'm reading the ICH7 docs wrong. But I don't think I am.

NOTE NOTE NOTE! I didn't check which all LPC bridges there are out there 
that have these magic registers. But it shows up in the ICH7 docs. It 
migth exist in ICH[5-9] for all I know. But at least for ICH7, the only 
LPC bridge ID's I find in the spec update are 27b8, 27b9 and 27bd, which 
are those three devices that I list in the quirks.

Somebody should double-check this, and also check whether ICH6-9 have the 
same LPC decode logic..

Anyway, does this cause anything to be printed out for you? I have _not_ 
checked whether this is the only such programmable hidden range register 
set.

That said, the "no IO window" case should be the safe one (if there are 
hidden IO ports that clash), and it's the one that does _not_ work for 
you, so this may not be it either. But these kinds of quirks were very 
common reasons for ACPI power states not working (because we would just 
allocate something else on top of the damn hidden things that we didn't 
know about).

		Linus

---
 drivers/pci/quirks.c |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 5f4f85f..355ccf2 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -474,6 +474,42 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_4, quirk_
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich6_lpc_acpi);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich6_lpc_acpi);

+static void __devinit ich7_lpc_generic_decode(struct pci_dev *dev, unsigned reg, const char *name)
+{
+	u32 val;
+	u32 mask, base;
+
+	pci_read_config_dword(dev, reg, &val);
+
+	/* Enabled? */
+	if (!(val & 1))
+		return;
+
+	/* Base in bits 15:2 */
+	base = val & 0xfffc;
+
+	/* Decode mask in bits 23:18 */
+	mask = (val >> 16) & 0xfc;
+
+	/* The mask is only on a dword address, the word/byte is always matched */
+	mask |= 3;
+
+	/* Just print it out for now. We should reserve it after debugging */
+	dev_info(&dev->dev, "%s PIO at %04x (mask %04x)\n", name, base, mask);
+}
+
+static void __devinit quirk_ich7_lpc_decode(struct pci_dev *dev)
+{
+	ich7_lpc_generic_decode(dev, 0x84, "ICH7 LPC Generic IO decode 1");
+	ich7_lpc_generic_decode(dev, 0x88, "ICH7 LPC Generic IO decode 2");
+	ich7_lpc_generic_decode(dev, 0x8c, "ICH7 LPC Generic IO decode 3");
+	ich7_lpc_generic_decode(dev, 0x90, "ICH7 LPC Generic IO decode 4");
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_0, quirk_ich7_lpc_decode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_1, quirk_ich7_lpc_decode);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,   PCI_DEVICE_ID_INTEL_ICH7_31, quirk_ich7_lpc_decode);
+
+
 /*
  * VIA ACPI: One IO region pointed to by longword at
  *	0x48 or 0x20 (256 bytes of ACPI registers)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/