(the bios might not have done that).

From: Arjan van de Ven

This option only worked for the amd64 driver.
On every other driver, the only thing it did was
make it not printk the banner on startup.

This is horribly broken due to a jiffy wrap bug, we never get out of
the while loop, preventing booting on a kernel with this driver
compiled in. (See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124495)

The warning message there has never been reported in any bug report
that google can find, so I'm of the opinion that this driver is trying
to be too clever for its own good.  Rip out the jiffies logic completely,
it should be totally unnecessary.

Signed-off-by: Dave Jones <davej@redhat.com>

From: "Heilmann, Oliver" <Oliver.Heilmann@drkw.com>
                                                                                         
* renamed sis_648_enable to sis_delayed_enable and removed chipset
  references
                                                                                         
* All chipsets that require the sis delay-hack are listed in
  sis_broken_chipsets (and no other place).
                                                                                         
* There are two new module options to force agp3-spec compliant
  initialisation and/or the delay hack.  As I only have a 648FX chipset to
  test on, I figured this might be useful to experiment with on other
  chipsets (i.e.746[FX]).
                                                                                         
Basically, if you have an  SiS chipset and your machine freezes when you
start X, try the -agp_sis_force_delay=1 option. If this fixes your
problem add your PCI ID to sis_broken_chipsets in sis-agp.c
Note to 746[FX] people: I'm still not sure what the differences between
the two 746 versions and the 648 series are. If this patch does not work
for you try playing with the agp_sis_agp_spec module option. Any
feedback is greatly appreciated.

It's not leaking anything currently, as agp_alloc_bridge() doesn't do any
actual allocations right now, but if/when things get changed to support
multiple bridges, these error paths need to free up the allocation.
 

No code changes.

From: Andi Kleen

From: Andi Kleen

Avoids dups with the AMD64 driver.
From: Andi Kleen

This avoids dups with the amd64 driver.
From: Andi Kleen

Some bridges don't have this set it seems.
Detective work, and fixing by Andi Kleen.

From Andi Kleen.

- Add full PCI IDs to the module table for intel-agp and intel-mch-agp.
Don't use PCI_ANY_ID for device, since the drivers cannot handle unknown
devices anyways.
This fixes the problems with them loading both when compiled in and
also helps external tools that use the module PCI table to find the
correct driver.
- Remove wrong hack in intel-mch-agp that checked for long mode.
EM64T capability has nothing to do with the MCH version.
To avoid double probing the fix above is better.
- Handle the case of no AGP capability (unlikely, but better to handle it)

use spaces instead of (borked) tabs.

Turns out that this chipset won't work in AGPv3 mode with the generic AGPv3 routines.
*somehow*, it works in AGPv3 mode with AGPv2 aperture sizing etc. Very, very strange.
Still, until we get some docs from SiS, some support is better than none.

Otherwise we see strange things at boottime if we compile in all drivers, like this..

agpgart: Unsupported Intel chipset (device id: 1a30)
agpgart: Detected an Intel i845 Chipset.

into delerium.codemonkey.org.uk:/mnt/nfs/sepia/bar/src/kernel/2.6/trees/agpgart

This cleans up a larger amount of superfluos ";;" statements in current
Linux kernel sources by converting them to the regular single ";"
statments.

It seems to be a common problem that at the end of a line the semicolon
key is producing an echo.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

From: Anton Blanchard <anton@samba.org>
      Rusty Russell <rusty@rustcorp.com.au>

The iSeries has an arch-specific mapping from physical <-> absolute
addresses.  Fortunately this is only used in a few places.  However, the
following arch-specific macros/functions are provided in addition to the
standard macros:

	__a2p()
	__a2v()
	__p2a()
	__p2v()
	__v2a()
	__v2p()
	absolute_to_phys()
	phys_to_absolute()
	virt_to_absolute()
	absolute_to_virt()

Reduce them to these, with slightly shorter names, and taking either pointers
or unsigned long (as per __va and __pa) rather than making the caller cast:

	abs_to_phys()
	phys_to_abs()

And helper macros:

	virt_to_abs()
	abs_to_virt()

As is standard, virtual addresses are returned as void *, physical and
absolute as unsigned long.

Note that the change the iSeries_setup is a little subtle: ea is set to
__va(pa) above, so "phys_to_abs(pa)" is the same as "virt_to_abs(ea)".

Also, REALADDR is renamed to ISERIES_HV_ADDR and used in a couple of places
where appropriate.

From: Anton Blanchard <anton@samba.org>
      Stephen Rothwell <sfr@canb.auug.org.au>

This patch just ensures that the RI bit is set really early as it seems it
is not on iSeries Power4 machines (or maybe OS400 v5r3 does this).

au88x0 driver
Cleanups - removed duplicate PCI IDs

USB generic driver
add usb_device->speed wrapper for compiling with 2.2.x kernels

into suse.cz:/home/perex/bk/linux-sound/linux-sound

People were getting quite excited about this.

This backs out Maneesh's sysfs patch that was recently added to the
kernel.

In its defense, the original patch did solve some fixes that could be
duplicated on SMP machines, but the side affect of the patch caused lots
of problems.  Basically it caused kobjects to get their references
incremented when files that are not present in the kobject are asked for
(udev can easily trigger this when it looks for files call "dev" in
directories that do not have that file).  This can cause easy oopses
when the VFS later ages out those old dentries and the kobject has its
reference finally released (usually after the module that the kobject
lived in was removed.)

I will continue to work with Maneesh to try to solve the original bug,
but for now, this patch needs to be applied.

From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>

The memory reserved for PCI probe is not freed properly in some cases,
for instance with a 3.5Gb of RAM.

Forward port from 2.4.

Oops, there was two different code path affected by this
bug (strace and normal) and I fixed only one. Here's the
other one:

For the same reason as ppc32, we need to ensure that all stores
done on a CPU has reached the coherency domain and are visible
to loads done by another CPU when context switching as the same
thread may be rescheduled almost right away there.

This updates the ppc32 PCI mmap facility to allow mmap'ing of space
outside of the actual devices, using the host bridge resources instead. 

This allow userland to map things like legacy IO space by either using
the bridge device itself, or simply any PCI device on the same bus
domain

On ppc32, CONFIG_PREEMPT wasn't settable along with CONFIG_SMP
for historical reasons (smp_processor_id() races). Those races have
been fixes since then (well, should have been at least) so it's now
safe to allow both options.