Some Supermicro BIOSes describe a SATA PCI BAR as a motherboard resource.
The PNP system driver claims motherboard resources, and this prevents the
sata_nv driver from requesting it later.
This patch disables the PNP0C01/PNP0C02 resources so they won't be claimed
by the PNP system driver, so they'll available for sata_nv.
This fixes the bugs below, where sata_nv detects only two out of four SATA
drives. The signature includes dmesg lines similar to these:
pnp: 00:09: iomem range 0xdfefc000-0xdfefcfff has been reserved
pnp: 00:09: iomem range 0xdfefd000-0xdfefd3ff has been reserved
pnp: 00:09: iomem range 0xdfefe000-0xdfefe3ff has been reserved
PCI: Unable to reserve mem region #6:1000@dfefd000 for device 0000:80:07.0
sata_nv: probe of 0000:80:07.0 failed with error -16
PCI: Unable to reserve mem region #6:1000@dfefe000 for device 0000:80:08.0
sata_nv: probe of 0000:80:08.0 failed with error -16
References:
https://bugzilla.redhat.com/show_bug.cgi?id=280641https://bugzilla.redhat.com/show_bug.cgi?id=313491http://lkml.org/lkml/2008/1/9/449http://thread.gmane.org/gmane.linux.acpi.devel/27312
This is post-2.6.24 material.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If we have the struct pnp_dev available, we can use dev_info(), dev_err(),
etc., to give a little more information and consistency.
[akpm@linux-foundation.org: fix warning]
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the quirk enables the SIR part of the SMCf010 device, the 8250 driver
may claim it as a legacy ttyS device, which makes the legacy probe in the
smsc-ircc2 driver fail.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
These are manual fixups after running Lindent. No functional change.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we enable the SMCf010 IR device, the Toshiba Portege 4000 BIOS claims
the device is working, but it really isn't configured correctly. The BIOS
*will* configure it, but only if we call _SRS after (1) reversing the order
of the SIR and FIR I/O port regions and (2) changing the IRQ from
active-high to active-low.
This patch addresses the 2.6.22 regression:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"
I tested this on a Portege 4000. The smsc-ircc2 driver correctly detects
the device, and "irattach irda0 -s && irdadump" shows transmitted and
received packets.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: "Linus Walleij (LD/EAB)" <linus.walleij@ericsson.com>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some HP firmware leaves the SMCf010 IRDA device incompletely configured, or
reports the wrong resources in _CRS. As a workaround, when we find such a
device, try to auto-configure the device.
This ignores the _CRS data, picks a config from _PRS, and runs _SRS to
configure the device. This makes smsc-ircc2 work correctly with PNP
resources (with no preconfiguration!) on all the machines I tested.
I think Windows does something like this by default for all devices,
so we should consider doing the same thing in Linux.
This patch addresses part of the 2.6.22 regression:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"
It fixes smsc-ircc2 PNP device detection on HP nc6000, nc6220, nw8000,
nw8240, and possibly other machines.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: "Linus Walleij (LD/EAB)" <linus.walleij@ericsson.com>
Cc: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some HP/Compaq firmware reports via ACPI that the SMCF010 IR device is
enabled, but in fact, it leaves the device partly disabled.
HP nw8240 BIOS 68DTV Ver. F.0F, released 9/15/2005 is one BIOS that has this
problem.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Keith Owens <kaos@ocs.com.au>
Cc: Len Brown <lenb@kernel.org>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Matthieu CASTET <castet.matthieu@free.fr>
Cc: Jean Tourrilhes <jt@hpl.hp.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Ville Syrjala <syrjala@sci.fi>
Cc: Russell King <rmk+serial@arm.linux.org.uk>
Cc: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Seems pointless to require .c files to test CONFIG_PNP_DEBUG and
conditionally define DEBUG before including <linux/pnp.h>. Just test
CONFIG_PNP_DEBUG directly in pnp.h.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
