Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 6月, 2006 3 次提交
  3. 24 3月, 2006 5 次提交
    • E
      [PATCH] PCI: kzalloc() conversion in drivers/pci · f5afe806
      由 Eric Sesterhenn 提交于 
      this patch converts drivers/pci to kzalloc usage.
Compile tested with allyes config.
Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f5afe806
    • B
      [PATCH] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix · 8c4b2cf9
      由 Bernhard Kaindl 提交于 
      "In some cases, especially on modern laptops with a lot of PCI and cardbus
bridges, we're unable to assign correct secondary/subordinate bus numbers
to all cardbus bridges due to BIOS limitations unless we are using
"pci=assign-busses" boot option." -- Ivan Kokshaysky (from a patch comment)

Without it, Cardbus cards inserted are never seen by PCI because the parent
PCI-PCI Bridge of the Cardbus bridge will not pass and translate Type 1 PCI
configuration cycles correctly and the system will fail to find and
initialise the PCI devices in the system.

Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering:
http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html

The reason for this is that:
 ``All PCI busses located behind a PCI-PCI bridge must reside between the
secondary bus number and the subordinate bus number (inclusive).''

"pci=assign-busses" makes pcibios_assign_all_busses return 1 and this
turns on PCI renumbering during PCI probing.

Alan suggested to use DMI automatically set assign-busses on problem systems.

The only question for me was where to put it.  I put it directly before
scanning PCI bus into pcibios_scan_root() because it's called from legacy,
acpi and numa and so it can be one place for all systems and configurations
which may need it.

AMD64 Laptops are also affected and fixed by assign-busses, and the code is
also incuded from arch/x86_64/pci/ that place will also work for x86_64
kernels, I only ifdef'-ed the x86-only Laptop in this example.

Affected and known or assumed to be fixed with it are (found by googling):

* ASUS Z71V and L3s
* Samsung X20
* Compaq R3140us and all Compaq R3000 series laptops with TI1620 Controller,
  also Compaq R4000 series (from a kernel.org bugreport)
* HP zv5000z (AMD64 3700+, known that fixup_parent_subordinate_busnr fixes it)
* HP zv5200z
* IBM ThinkPad 240
* An IBM ThinkPad (1.8 GHz Pentium M) debugged by Pavel Machek
  gives the correspondig message which detects the possible problem.
* MSI S260 / Medion SIM 2100 MD 95600

The patch also expands the "try pci=assign-busses" warning so testers will
help us to update the DMI table.

Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      8c4b2cf9
    • M
      [PATCH] PCI: make MSI quirk inheritable from the pci bus · 6e325a62
      由 Michael S. Tsirkin 提交于 
      It turns out AMD 8131 quirk only affects MSI for devices behind the 8131 bridge.
Handle this by adding a flags field in pci_bus, inherited from parent to child.
Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6e325a62
    • R
      [PATCH] PCI: Avoid leaving MASTER_ABORT disabled permanently when returning from pci_scan_bridge. · bbe8f9a3
      由 Ralf Baechle 提交于 
      > On Mon, Feb 13, 2006 at 05:13:21PM -0800, David S. Miller wrote:
> >
> > In drivers/pci/probe.c:pci_scan_bridge(), if this is not the first
> > pass (pass != 0) we don't restore the PCI_BRIDGE_CONTROL_REGISTER and
> > thus leave PCI_BRIDGE_CTL_MASTER_ABORT off:
> >
> > int __devinit pci_scan_bridge(struct pci_bus *bus, struct pci_dev * dev, int max, int pass)
> > {
> >  ...
> > 	/* Disable MasterAbortMode during probing to avoid reporting
> > 	   of bus errors (in some architectures) */
> > 	pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &bctl);
> > 	pci_write_config_word(dev, PCI_BRIDGE_CONTROL,
> > 			      bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT);
> >  ...
> > 	if ((buses & 0xffff00) && !pcibios_assign_all_busses() && !is_cardbus) {
> > 		unsigned int cmax, busnr;
> > 		/*
> > 		 * Bus already configured by firmware, process it in the first
> > 		 * pass and just note the configuration.
> > 		 */
> > 		if (pass)
> > 			return max;
> >  ...
> > 	}
> >
> > 	pci_write_config_word(dev, PCI_BRIDGE_CONTROL, bctl);
> >  ...
> >
> > This doesn't seem intentional.

Agreed, looks like an accident.  The patch [1] originally came from Kip
Walker (Broadcom back then) between 2.6.0-test3 and 2.6.0-test4.  As I
recall it was supposed to fix an issue with with PCI aborts being
signalled by the PCI bridge of the Broadcom BCM1250 family of SOCs when
probing behind pci_scan_bridge.  It is undeseriable to disable
PCI_BRIDGE_CTL_MASTER_ABORT in pci_{read,write)_config_* and the
behaviour wasn't considered a bug in need of a workaround, so this was
put in probe.c.

I don't have an affected system at hand, so can't really test but I
propose something like the below patch.

[1] http://www.linux-mips.org/git?p=linux.git;a=commit;h=599457e0cb702a31a3247ea6a5d9c6c99c4cf195

[PCI] Avoid leaving MASTER_ABORT disabled permanently when returning from pci_scan_bridge.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bbe8f9a3
    • K
      [PATCH] PCI: really fix parent's subordinate busnr · e3ac86d8
      由 Kristen Accardi 提交于 
      After you find the maximum value of the subordinate buses below the child
bus, you must fix the parent's subordinate bus number again, otherwise
it may be too small.
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e3ac86d8
  5. 10 1月, 2006 5 次提交
  7. 29 10月, 2005 1 次提交
  9. 23 9月, 2005 1 次提交
    • I
      [PATCH] pci: fixup parent subordinate busnr · 12f44f46
      由 Ivan Kokshaysky 提交于 
      I believe the change that broke things is introduction of
pci_fixup_parent_subordinate_busnr().

The patch here does two things:
- hunk #1 should fix the problems you've seen when you boot without
  additional "pci" kernel options;
- hunk #2 supposedly fixes boot with "pci=assign-busses" option which
  otherwise hangs Acer TM81xx machines as reported.

Please try this with and without "pci=assign-busses". If it boots,
I'd like to see 'lspci -vvx' for both cases.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      12f44f46
  11. 22 9月, 2005 1 次提交
    • A
      [PATCH] fix drivers/pci/probe.c warning · 3c6de929
      由 Amos Waterland 提交于 
      This function expects an unsigned 32-bit type as its third argument:

 static u32 pci_size(u32 base, u32 maxbase, u32 mask)

However, given these definitions:

 #define PCI_BASE_ADDRESS_MEM_MASK (~0x0fUL)
 #define PCI_ROM_ADDRESS_MASK (~0x7ffUL)

these two calls in drivers/pci/probe.c are problematic for architectures
for which a UL is not equivalent to a u32:

 sz = pci_size(l, sz, PCI_BASE_ADDRESS_MEM_MASK);
 sz = pci_size(l, sz, PCI_ROM_ADDRESS_MASK);

Hence the below compile warning when building for ARCH=ppc64:

 drivers/pci/probe.c: In function `pci_read_bases':
 /.../probe.c:168: warning: large integer implicitly truncated to unsigned type
 /.../probe.c:218: warning: large integer implicitly truncated to unsigned type

Here is a simple fix.
Signed-off-by: NAmos Waterland <apw@us.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3c6de929
  13. 11 9月, 2005 1 次提交
  15. 10 9月, 2005 1 次提交
  17. 09 9月, 2005 2 次提交
  19. 30 7月, 2005 1 次提交
  21. 02 7月, 2005 2 次提交
  23. 28 6月, 2005 4 次提交
  25. 14 6月, 2005 1 次提交
    • O
      [PATCH] Fix PCI BAR size interpretation on 64-bit arches · f797f9cc
      由 Olof Johansson 提交于 
      On 64-bit machines, PCI_BASE_ADDRESS_MEM_MASK and other mask constants
passed to pci_size() are 64-bit (for example ~0x0fUL).  However, pci_size
does comparisons between the u32 arguments and the mask, which will fail
even though any result from pci_size is still just 32-bit.

Changing the mask argument to u32 seems the obvious thing to do, since all
arithmetic in the function is 32-bit and having a larger mask makes no
sense.

This triggered on a PPC64 system here where an adapter (VGA, as it
happened) had a memory region base of 0xfe000000 and a sz of the same,
matching the if (max == maxbase ...) test at the bottom of pci_size but
failing the mask comparison.  Quite a corner case which I guess explains
why we haven't seen it until now.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NGreg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f797f9cc
  27. 04 5月, 2005 1 次提交
  29. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus 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!
      1da177e4