aboutsummaryrefslogtreecommitdiff
path: root/arch/i386/pci/fixup.c
AgeCommit message (Collapse)Author
2006-01-09[PATCH] PCI: update Toshiba ohci quirk DMI tableJesse Barnes
I upgraded my Toshiba Satellite BIOS recently to see if it would fix an ACPI related problem I have (http://bugzilla.kernel.org/show_bug.cgi?id=5727). Unfortunately, it didn't, and moreover, Toshiba chose to change the system version in the DMI table with the update, causing the OHCI1394 related quirk to break. This patch updates the DMI table for the quirk to include Toshiba's new version name for this machine; I've tested it and it seems to work fine. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-10[PATCH] PCI: fix for Toshiba ohci1394 quirkJesse Barnes
After much testing and agony, I've discovered that my previous ohci1394 quirk for Toshiba laptops is not 100% reliable. It apparently fails to do the interrupt line change either correctly or in time, since in about 2 out of 5 boots, the kernel's irqdebug code will *still* disable irq 11 when the ohci1394 driver is loaded (at pci_enable_device time I think). This patch switches things around a little in the workaround. First, it removes the mdelay. I didn't see a need for it and my testing has shown that it's not necessary for the quirk to work. Secondly, instead of trying to change the interrupt line to what ACPI tells us it should be, this patch makes the quirk use the value in the PCI_INTERRUPT_LINE register. On this laptop at least, that seems to be the right thing to do, though additional testing on other laptops and/or with actual firewire devices would be appreciated. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-01[PATCH] toshiba_ohci1394_dmi_table should be __devinitdata, not __devinitRoland Dreier
I don't really understand why gcc gives the error it does, but without this patch, when building with CONFIG_HOTPLUG=n, I get errors like: CC arch/x86_64/pci/../../i386/pci/fixup.o arch/x86_64/pci/../../i386/pci/fixup.c: In function `pci_fixup_i450nx': arch/x86_64/pci/../../i386/pci/fixup.c:13: error: pci_fixup_i450nx causes a section type conflict The change is obviously correct: an array should be declared __devinitdata rather that __devinit. Signed-off-by: Roland Dreier <rolandd@cisco.com> Acked-by: Martin J. Bligh <mbligh@mbligh.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-28[PATCH] PCI fixup for Toshiba laptops and ohci1394Jesse Barnes
This is a fix for a bug I see on my Toshiba laptop, where the ohci1394 controller gets initialized improperly. The patch adds two PCI fixups to arch/i386/pci/fixup.c, one that happens early on to cache the value of the PCI_CACHE_LINE_SIZE config register, and another that later restores the value, along with a valid IRQ number and some BAR values. I've tested it on my laptop, and it prevents me from running into what I consider to be a major bug: IRQ 11 is disabled by the IRQ debug code, causing my wireless to break. Thanks to Rob for the original patch to ohci1394.c and Stefan for lots of proofreading (and a last minute bug caught in review!) and additional information collection. I think the DMI system list is correct, but we may need to add some more PCI IDs to the PCI_FIXUP macros over time. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-05-17[PATCH] fix memory scribble in arch/i386/pci/fixup.cChristoph Lameter
The GET_INDEX() macro should use just the low three bits of the devfn, otherwise we have a memory scribble in pcie_rootport_aspm_quirk that overwrites ptype_all Fix it to be more careful about its arguments while at it. Acked by Dely Sy <dely.l.sy@intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!