linux-stable.git/drivers/pci, branch linux-2.6.25.y

pci: VT3336 can't do MSI either

2008-08-06T17:11:05+00:00

commit 66d715c95a39e84cd25204a665915621457d9691 upstream

It seems VT3336 can't do msi either as with its bro 3351.  Disable it.
Reported in the following SUSE bug.

  https://bugzilla.novell.com/show_bug.cgi?id=300001

Signed-off-by: Tejun Heo 
Acked-by: Jesse Barnes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

pci: revert SMBus unhide on HP Compaq nx6110

2008-03-28T21:45:22+00:00

This reverts commit 3c0a654e390d00fef9d8faed758f5e1e8078adb5 and
fixes kernel bug #10245:

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

The HP Compaq nc6120 has the same PCI sub-device ID as the nx6110, and the
SMBus is used by ACPI for thermal management on the nc6120, so Linux should
not attach a native driver to it.  This means that this quirk is unsafe and
has to be removed.

I also added a comment to help developers realize that adding new IDs to this
SMBus unhiding quirk table should be done only with great care, and in
particular only after checking that ACPI is not making use of the SMBus.

Signed-off-by: Jean Delvare 
Cc: Tomasz Koprowski 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Revert "PCI: remove transparent bridge sizing"

2008-03-26T18:22:40+00:00

This reverts commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f, which
caused various interesting problems for people, including wrong resource
allocations.  See for example bugzilla entry "2.6.25-rc2: ohci1394
problem (MMIO broken)" at

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

And Gary Hade says:

 "The same change had also exposed an issue reported by Paul Martin that
  has been causing an Oops while hotplugging ThinkPads to a ThinkPad
  Dock II.  See

	http://lkml.org/lkml/2008/2/19/405
	http://bugzilla.kernel.org/show_bug.cgi?id=9961

  I have a fix for the ThinkPad docking Oops but if the issue being
  discussed here is caused by the transparent bridge sizing removal
  change I totally agree that it should be reverted."

  The transparent bridge sizing removal change was motivated by
  insufficient PCI memory resource for a transparent bridge window that
  was being created as a result of expansion ROM(s) being included in
  the transparent bridge sizing calculations.

  A later "PCI: Remove default PCI expansion ROM memory allocation"
  change ( re: http://lkml.org/lkml/2007/12/11/361 ) removes the
  expansion ROM(s) from the transparent bridge sizing calculations which
  actually resolves the original issue in a different manner.  So, even
  if the "PCI: remove transparent bridge sizing" is not problematic it
  is no longer needed anyway."

Identified-by: Ivan Kokshaysky 
Tested-by: Thomas Meyer 
Acked-by: Gary Hade 
Acked-by: Ingo Molnar 
Cc: Stefan Richter 
Signed-off-by: Linus Torvalds

PCI: revert "pcie: utilize pcie transaction pending bit"

2008-03-25T05:38:44+00:00

Revert as it is reported to cause problems for people.

commit 4348a2dc49f9baecd34a9b0904245488c6189398
Author: Shaohua Li 
Date:   Wed Oct 24 10:45:08 2007 +0800

    pcie: utilize pcie transaction pending bit

    PCIE has a mechanism to wait for Non-Posted request to complete. I think
    pci_disable_device is a good place to do this.

    Signed-off-by: Shaohua Li 
    Signed-off-by: Greg Kroah-Hartman 

Due to the regression reported at
http://bugzilla.kernel.org/show_bug.cgi?id=10065

Cc: Shaohua Li 
Cc: Soeren Sonnenburg 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

PCI: iova: lockdep false alarm fix

2008-03-25T05:38:44+00:00

lockdep goes off on the iova copy_reserved_iova() because it and a function
it calls grabs locks in the from, and the to of the copy operation.

The function grab locks of the same lock classes triggering the warning.  The
first lock grabbed is for the constant reserved areas that is never accessed
after early boot.  Technically you could do without grabbing the locks for the
"from" structure its copying reserved areas from.

But dropping the from locks to me looks wrong, even though it would be ok.

The affected code only runs in early boot as its setting up the DMAR
engines.

This patch gives the reserved_ioval_list locks special lockdep classes.

Signed-off-by: Mark Gross 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

pciehp: don't enable slot unless forced

2008-03-18T02:26:05+00:00

This fixes a 2.6.25 regression reported by Alex Chiang.

Invoke pciehp_enable_slot() at startup only when pciehp_force=1.
Some HP equipment apparently cannot cope with it otherwise.

This restores the (previously working) 2.6.24 behaviour here,
while allowing machines that need a kick to use pciehp_force=1.

This was the original design back in October 2007,
but Kristen suggested we try without it first:

   Kristen Carlson Accardi wrote:
   >I think it would be ok to try allowing the slot to be enabled when not
   >using pciehp_force mode.  We can wrap it later if it proves to break things

This ended up breaking one of Alex's setups,
so it's time to put the wrapper back in now.

Signed-off-by: Mark Lord 
Acked-by: Alex Chiang 
Acked-by: Kristen Carlson Accardi 
Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/pci-2.6

2008-03-13T20:16:22+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/pci-2.6:
  PCI: fix issue with busses registering multiple times in sysfs

PCI: fix issue with busses registering multiple times in sysfs

2008-03-13T17:21:09+00:00

PCI busses can be registered multiple times, so we need to detect if we
have registered our bus structure in sysfs already.  If so, don't do it
again.

Thanks to Guennadi Liakhovetski  for reporting
the problem, and to Linus for poking me to get me to believe that it was
a real problem.

Cc: Linus Torvalds 
Cc: Guennadi Liakhovetski 
Signed-off-by: Greg Kroah-Hartman

Merge branches 'release', 'button-sysfs', 'misc', 'mismatch', 'randconfig' and 'toshiba' into release

2008-03-13T05:59:49+00:00

PCI Hotplug: Fix small mem leak in IBM Hot Plug Controller Driver

2008-03-10T23:38:02+00:00

In drivers/pci/hotplug/ibmphp_ebda.c::ebda_rsrc_controller(), storage is
allocated with kzalloc() and assigned to 'tmp_slot'.  Then lots of
stuff, like ->flag, ->supported_speed etc is set in tmp_slot.  A bit
further down there's then this test :

  if (!bus_info_ptr1) {
    rc = -ENODEV;
    goto error;
  }

At this point, tmp_slot has not been assigned to anything, so when
erroring-out we want to free it, but nothing at the 'error:' label
free's 'tmp_slot' - and we can't really free 'tmp_slot' at 'error:'
since we may jump to that label later when 'tmp_slot' *has* been used
and we do not want it freed. So, the only sane option left seems to be
to kfree(tmp_slot) just before jumping to the 'error:' label in the one
place where this is what actually makes sense. The following patch does
just that and thus kills off a tiny potential memory leak.


Signed-off-by: Jesper Juhl 
Signed-off-by: Greg Kroah-Hartman