Commit Graph

6 Commits

Author SHA1 Message Date
Jesse Barnes
19272684b8 [PATCH] PCI: update Toshiba ohci quirk DMI table
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>
2006-01-09 12:13:21 -08:00
Jesse Barnes
6e6ece5dc6 [PATCH] PCI: fix for Toshiba ohci1394 quirk
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-10 16:09:18 -08:00
Roland Dreier
1d37374197 [PATCH] toshiba_ohci1394_dmi_table should be __devinitdata, not __devinit
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-11-01 21:27:22 -08:00
Jesse Barnes
f8977d0a9b [PATCH] PCI fixup for Toshiba laptops and ohci1394
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-10-28 15:37:02 -07:00
Christoph Lameter
ff0d2f90fd [PATCH] fix memory scribble in arch/i386/pci/fixup.c
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-05-17 09:27:05 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00