Commit Graph

10 Commits

Author SHA1 Message Date
Randy Dunlap 7edab2f087 pci/i386: style cleanups
Mostly CodingStyle cleanups for arch/i386/pci/i386.c:
- fit in 80 columns;
- use a #defined value instead of an inline constant;
Also change one resource_size_t (DBG) printk from %08lx to %lx since
it can be more than 32 bits (more than 8 hexits).

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-01 14:36:58 -08:00
Greg Kroah-Hartman 6851ecc6e2 PCI: Revert "PCI: i386/x86_84: disable PCI resource decode on device disable"
This reverts commit 53e4d30dd6.

It was found that it caused unneeded problems (see
http://bugzilla.kernel.org/show_bug.cgi?id=7082 for details of one such
issue.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-02 23:02:24 -08:00
Greg Kroah-Hartman e31dd6e452 [PATCH] 64bit resource: change pci core and arch code to use resource_size_t
Based on a patch series originally from Vivek Goyal <vgoyal@in.ibm.com>

Cc: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-27 09:24:00 -07:00
Christoph Lameter 68402ddc67 [PATCH] mm: remove VM_LOCKED before remap_pfn_range and drop VM_SHM
Remove VM_LOCKED before remap_pfn range from device drivers and get rid of
VM_SHM.

remap_pfn_range() already sets VM_IO.  There is no need to set VM_SHM since
it does nothing.  VM_LOCKED is of no use since the remap_pfn_range does not
place pages on the LRU.  The pages are therefore never subject to swap
anyways.  Remove all the vm_flags settings before calling remap_pfn_range.

After removing all the vm_flag settings no use of VM_SHM is left.  Drop it.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Acked-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-06-25 10:00:55 -07:00
Rajesh Shah 53e4d30dd6 [PATCH] PCI: i386/x86_84: disable PCI resource decode on device disable
When a PCI device is disabled via pci_disable_device(), it's still
left decoding its BAR resource ranges even though its driver
will have likely released those regions (and may even have
unloaded). pci_enable_device() already explicitly enables
BAR resource decode for the device being enabled. This patch
disables resource decode for the PCI device being disabled,
making it symmetric with the enable call.

I saw this while doing something else, not because of a
problem report. Still, seems to be the correct thing to do.

Signed-off-by: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-21 11:59:59 -07:00
Rajesh Shah ed6d14f976 [PATCH] PCI: remove bogus resource collision error
When attempting to hotadd a PCI card with a bridge on it, I saw
the kernel reporting resource collision errors even when there were
really no collisions. The problem is that the code doesn't skip
over "invalid" resources with their resource type flag not set.
Others have reported similar problems at boot time and for
non-bridge PCI card hotplug too, where the code flags a
resource collision for disabled ROMs. This patch fixes both
problems.

Signed-off-by: Rajesh Shah <rajesh.shah@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-11-23 23:04:27 -08:00
Michael S. Tsirkin 346d38823b [PATCH] arch/386/pci: remap_pfn_range -> io_remap_pfn_range
Convert i386/pci to use io_remap_pfn_range instead of remap_pfn_range.
This is good for Xen which reuses i386/pci/i386.c for domain 0 code.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-08 14:57:24 -07:00
Ivan Kokshaysky 81d4af1340 [PATCH] x86: pci_assign_unassigned_resources() update
I had some time to think about PCI assign issues in 2.6.13-rc series.

The major problem here is that we call pci_assign_unassigned_resources()
way too early - at subsys_initcall level. Therefore we give no chances
to ACPI and PnP routines (called at fs_initcall level) to reserve their
respective resources properly, as the comments in drivers/pnp/system.c
and drivers/acpi/motherboard.c suggest:

 /**
  * Reserve motherboard resources after PCI claim BARs,
  * but before PCI assign resources for uninitialized PCI devices
  */

So I moved the pci_assign_unassigned_resources() call to
pcibios_assign_resources() (fs_initcall), which should hopefully fix a
lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary.

Other changes:
- remove resource assignment code from pcibios_assign_resources(), since
  it duplicates pci_assign_unassigned_resources() functionality and
  actually does nothing in 2.6.13;
- modify ROM assignment code as per Ben's suggestion: try to use firmware
  settings by default (if PCI_ASSIGN_ROMS is not set);
- set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for
  various setups.

Confirmed by Tero Roponen <teanropo@cc.jyu.fi> (who had problems with
the 4kB CardBus IO size previously).

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-08-30 11:14:48 -07:00
Ivan Kokshaysky 299de0343c [PATCH] PCI: pci_assign_unassigned_resources() on x86
- Add sanity check for io[port,mem]_resource in setup-bus.c. These
  resources look like "free" as they have no parents, but obviously
  we must not touch them.
- In i386.c:pci_allocate_bus_resources(), if a bridge resource cannot be
  allocated for some reason, then clear its flags. This prevents any child
  allocations in this range, so the setup-bus code will work with a clean
  resource sub-tree.
- i386.c:pcibios_enable_resources() doesn't enable bridges, as it checks
  only resources 0-5, which looks like a clear bug to me. I suspect it
  might break hotplug as well in some cases.

From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-01 13:35:50 -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