linux.git/drivers/pci, branch v2.6.21.7

[PATCH] PCI: quirk disable MSI on via vt3351

2007-06-11T18:36:47+00:00

The Via VT3351 APIC does not play well with MSI and unleashes a flood
of APIC errors when MSI is used to deliver interrupts.  The problem
was recently exposed when the atl1 network device driver, which enables
MSI by default, stimulated APIC errors on an Asus M2V mainboard, which
employs the Via VT3351.
See http://bugzilla.kernel.org/show_bug.cgi?id=8472 for additional
details on this bug.

Signed-off-by: Jay Cliburn 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Chris Wright

[PATCH] pci-quirks: disable MSI on RS400-200 and RS480

2007-05-23T21:32:49+00:00

MSI doesn't work on RS400-200 and RS480 requiring pci=nomsi kernel boot
parameter for ahci to work.  This patch renames quirk_svw_msi() to
quirk_disable_all_msi() and use it to disable MSI on those chips.

  http://thread.gmane.org/gmane.linux.ide/17820
  http://thread.gmane.org/gmane.linux.ide/17516
  https://bugzilla.novell.com/show_bug.cgi?id=263893

Signed-off-by: Tejun Heo 
Cc: Matí-as Alejandro Torres 
Cc: Greg K-H 
Cc: Jeff Garzik 
Signed-off-by: Andrew Morton 
Signed-off-by: Chris Wright

Revert "adjust legacy IDE resource setting (v2)"

2007-04-23T21:19:36+00:00

This reverts commit ed8ccee0918ad063a4741c0656fda783e02df627.

It causes hang on boot for some users and we don't yet know why:

http://bugzilla.kernel.org/show_bug.cgi?id=7562

http://lkml.org/lkml/2007/4/20/404
http://lkml.org/lkml/2007/3/25/113

Just reverse it for 2.6.21-final, having broken X server is somehow
better than unbootable system.

Signed-off-by: Bartlomiej Zolnierkiewicz

[PATCH] msi: synchronously mask and unmask msi-x irqs.

2007-04-03T21:02:49+00:00

This is a simplified and actually more comprehensive form of a bug
fix from Mitch Williams .

When we mask or unmask a msi-x irqs the writes may be posted because
we are writing to memory mapped region.  This means the mask and
unmask don't happen immediately but at some unspecified time in the
future.  Which is out of sync with how the mask/unmask logic work
for ioapic irqs.

The practical result is that we get very subtle and hard to track down
irq migration bugs.

This patch performs a read flush after writes to the MSI-X table for mask
and unmask operations.  Since the SMP affinity is set while the interrupt
is masked, and since it's unmasked immediately after, no additional flushes
are required in the various affinity setting routines.

The testing by Mitch Williams on his especially problematic system should
still be valid as I have only simplified the code, not changed the
functionality.

We currently have 7 drivers: cciss, mthca, cxgb3, forceth, s2io,
pcie/portdrv_core, and qla2xxx in 2.6.21 that are affected by this
problem when the hardware they driver is plugged into the right slot.

Given the difficulty of reproducing this bug and tracing it down to
anything that even remotely resembles a cause, even if people are
being affected we aren't likely to see many meaningful bug reports, and
the people who see this bug aren't likely to be able to reproduce this
bug in a timely fashion.  So it is best to get this problem fixed
as soon as we can so people don't have problems.

Then if people do have a kernel message stating "No irq for vector" we
will know it is yet another novel cause that needs a complete new
investigation.

Cc: Greg KH 
Cc: Andrew Morton 
Signed-off-by: "Eric W. Biederman" 
Acked-by: Mitch Williams 
Acked-by: "Siddha, Suresh B" 
Signed-off-by: Linus Torvalds

PCI: Fix warning message in PCIE port driver

2007-03-26T21:13:08+00:00

PCIE error output should conform to vendor_id:device_id.

Signed-off-by: Prarit Bhargava 
Signed-off-by: Greg Kroah-Hartman

PCI: Stop unhiding the SMBus on Toshiba laptops

2007-03-26T21:13:07+00:00

It was found that the Toshiba laptops with hidden Intel SMBus have SMM
code handling the thermal management which accesses the SMBus. Thus it
is not safe to unhide it and let Linux access it. We have to leave the
SMBus hidden. SMM is a pain, really.

This fixes bugs #6315 and #6395, for good this time.

Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

[PATCH] pci: Repair pci_save/restore_state so we can restore one save many times.

2007-03-12T23:31:50+00:00

Because we do not reserve space for the pci-x and pci-e state in struct
pci dev we need to dynamically allocate it.  However because we need
to support restore being called multiple times after a single save
it is never safe to free the buffers we have allocated to hold the
state.

So this patch modifies the save routines to first check to see
if we have already allocated a state buffer before allocating
a new one.  Then the restore routines are modified to not free
the state after restoring it.  Simple and it fixes some subtle
error path handling bugs, that are hard to test for.

Signed-off-by: Eric W. Biederman 
Signed-off-by: Greg Kroah-Hartman 
Acked-by: Auke Kok 
Signed-off-by: Linus Torvalds

[PATCH] msi: Safer state caching.

2007-03-12T23:31:50+00:00

There are two ways pci_save_state and pci_restore_state are used.  As
helper functions during suspend/resume, and as helper functions around
a hardware reset event.  When used as helper functions around a hardware
reset event there is no reason to believe the calls will be paired, nor
is there a good reason to believe that if we restore the msi state from
before the reset that it will match the current msi state.  Since arch
code may change the msi message without going through the driver, drivers
currently do not have enough information to even know when to call
pci_save_state to ensure they will have msi state in sync with the other
kernel irq reception data structures.

It turns out the solution is straight forward, cache the state in the
existing msi data structures (not the magic pci saved things) and
have the msi code update the cached state each time we write to the hardware.
This means we never need to read the hardware to figure out what the hardware
state should be.

By modifying the caching in this manner we get to remove our save_state
routines and only need to provide restore_state routines.

The only fields that were at all tricky to regenerate were the msi and msi-x
control registers and the way we regenerate them currently is a bit dependent
upon assumptions on how we use the allow msi registers to be configured and used
making the code a little bit brittle.  If we ever change what cases we allow
or how we configure the msi bits we can address the fragility then.

Signed-off-by: Eric W. Biederman 
Signed-off-by: Greg Kroah-Hartman 
Acked-by: Auke Kok 
Signed-off-by: Linus Torvalds

pci: fix section mismatch warning

2007-03-09T23:36:30+00:00

drivers/pci/search.c caused following section mismatch warning
(if compiled with CONFIG_HOTPLUG=n):

WARNING: drivers/pci/built-in.o - Section mismatch: reference to .init.text: from .text.pci_find_bus after 'pci_find_bus' (at offset 0x24)

This was due to pci_find_bus() calling a function marked __devinit.
Fix was to remove the __devinit from the offending function.

Signed-off-by: Sam Ravnborg 
Signed-off-by: Greg Kroah-Hartman

PCI: aer: fix section mismatch warning

2007-03-09T23:36:30+00:00

Fix following section mismatch warning (when compiled with CONFIG_HOTPLUG=n):
WARNING: drivers/pci/built-in.o - Section mismatch: reference to .init.text:aer_probe from .data between 'aerdrv' (at offset 0x1608) and 'aer_error_handlers'

Warning was fixed by renaming aerdrv to aerdriver so we pass the whitelist.

Signed-off-by: Sam Ravnborg 
Signed-off-by: Greg Kroah-Hartman