The patch which went in was correct, but not quite what I had in mind.
Here is a patch to update that a little bit. Original patch is at:
 http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4749f32da939d4e4160541b2cadc22492bb507ecSigned-off-by: NPete Zaitcev <zaitcev@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In yenta_socket, we default to using the resource setting of the CardBus
bridge.  However, this is a PCI-bus-centric view of resources and thus needs
to be converted to generic resources first.  Therefore, add a call to
pcibios_bus_to_resource() call in between.  This function is a mere wrapper on
x86 and friends, however on some others it already exists, is added in this
patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where
is its pcibios_resource_to_bus() ?).
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
(including BARs) when transitioning from D3hot->D0.  This leaves such
a device in an inaccessible state.  The patch below causes the BARs
to be restored when enabling such a device, so that its driver will
be able to access it.

The patch also adds pci_restore_bars as a new global symbol, and adds a
correpsonding EXPORT_SYMBOL_GPL for that.

Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
(re)boot.  Most drivers call pci_enable_device very early, so devices
left in D3hot that lose configuration during the D3hot->D0 transition
will be inaccessible to their drivers.

Drivers could be modified to account for this, but it would
be difficult to know which drivers need modification.  This is
especially true since often many devices are covered by the same
driver.  It likely would be necessary to replicate code across dozens
of drivers.

The patch below should trigger only when transitioning from D3hot->D0
(or at boot), and only for devices that have the "no soft reset" bit
cleared in the PM control register.  I believe it is safe to include
this patch as part of the PCI infrastructure.

The cleanest implementation of pci_restore_bars was to call
pci_update_resource.  Unfortunately, that does not currently exist
for the sparc64 architecture.  The patch below includes a null
implemenation of pci_update_resource for sparc64.

Some have expressed interest in making general use of the the
pci_restore_bars function, so that has been exported to GPL licensed
modules.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This code was never designed to handle more than one instance of do_work()
running at once.
Signed-Off-By: NAlasdair G Kergon <agk@redhat.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The recent change to never ignore the bitmap, revealed that the bitmap isn't
begin flushed properly when an array is stopped.

We call bitmap_daemon_work three times as there is a three-stage pipeline for
flushing updates to the bitmap file.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Firstly, R1BIO_Degraded was being set in a number of places in the resync
code, but is never used there, so get rid of those settings.

Then: When doing a resync, we want to clear the bit in the bitmap iff the
array will be non-degraded when the sync has completed.  However the current
code would clear the bitmap if the array was non-degraded when the resync
*started*, which obviously isn't right (it is for 'resync' but not for
'recovery' - i.e.  rebuilding a failed drive).

This patch calculated 'still_degraded' and uses the to tell bitmap_start_sync
whether this sync should clear the corresponding bit.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The code currently will ignore the bitmap if the array seem to be in-sync.
This is wrong if the array is degraded, and probably wrong anyway.  If the
bitmap says some chunks are not in in-sync, and the superblock says everything
IS in sync, then something is clearly wrong, and it is safer to trust the
bitmap.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Until the bitmap code was added,

   modprobe md

would load the md module.  But now the md module is called 'md-mod', so we
really need an alias for backwards comparability.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

no_overlay bttv parameter implemented to fix OOPS on some PCI chipsets
(like some VIA) with these behaviors:

1) If pci_quicks does identify the chip as having troubles to
   handle PCI2PCI transfers, no_overlay defaults to 1. The user may force
   it to 0, to reenable (not recommended).

2) For newer chipsets not blacklisted, no_overlay=1 is provided as a
   workaround until PCI chipset included on /drivers/pci/quirks.c

Thanks to Bodo Eggert <7eggert@gmx.de>
Signed-off-by: NMichael Krufky <mkrufky@m1k.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Patch fixes oops caused by ide interfaces not on pci.  pcibus_to_node
causes the kernel to crash otherwise.  Patch also adds a BUG_ON to check if
hwif is NULL.
Signed-off-by: NChristoph Lameter <christoph@lameter.com>
Signed-off-by: NShai Fultheim <shai@scalex86.org>
Signed-off-by: NRavikiran Thirumalai <kiran@scalex86.org>
Cc: Andi Kleen <ak@muc.de>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Several people noticed we dropped quite a bit on benchmark figures.
OK, it was my fault but unfortunately I discovered I ran out of brown
paper bags a while ago and forgot to reorder them.

The issue is that a construct introduced in the conversion of the
driver to use the transport class keyed off whether the block request
was tagged or not.  However, the aic7xxx driver doesn't properly set
up the block layer TCQ (it uses the wrong API), so the driver now
things all requests are untagged and we keep it to a queue depth of a
single element.  Oops.

The fix is to use the correct TCQ API.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

ACPI now uses kmalloc(...,GPF_ATOMIC) during suspend/resume.

http://bugzilla.kernel.org/show_bug.cgi?id=3469Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

http://bugzilla.kernel.org/show_bug.cgi?id=4923Signed-off-by: NLen Brown <len.brown@intel.com>

For 2.6.12 behaviour, this (EXPERIMENTAL) driver
should not be built.

Update the driver source with latest from Luming.
Signed-off-by: NLuming Yu <luming.yu@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by Len Brown <len.brown@intel.com>

Burst mode isn't ready for prime time,
but can be enabled for test via "ec_burst=1"
Signed-off-by: NLuming Yu <luming.yu@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Patch from Ian Campbell

On PXA255 there is no way to disable the watchdog. Turning off OIER[E3]
as suggested in the existing comment does not work.

I posted a note to the ARM mailing list a little while ago asking for
opinions from people using SA1100. There was one reponse from Nico who
believes that the SA1100 is the same as the PXA255 in this respect.

You also asked me to involve the watchdog maintainer which I tried to
do but didn't hear anything back. There are only a couple of other
drivers which can't stop the watchdog and there seems to be no
consistancy regarding printing an error etc. I decided to print
something since that matches the case for all the other drivers when
NOWAYOUT is turned on.

Also, I changed the device .name to "watchdog" like most of the other
watchdogs. udev uses it as the device name (by default) and spaces etc.
get in the way.

Superceded 2833/1 because 2.6.13-rc4 caused rejects.
Signed-off-by: NIan Campbell <icampbell@arcom.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch disables the PCI Interrupt Link refernece counts,
which should not co-exist with the 2.6.12 irq_router.resume
method or else a double acpi_pci_link_set() could result
on resume.
Signed-off-by: NDavid Shaohua Li <shaohua.li@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

We have increased PCIBIOS_MIN_IO to 0x4000, but still want
motherboard resources to be allocated properly. So we need
to state 0x1000 (according to the comment) limit explicitely.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The reason we have PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO is because
we want to protect badly documented motherboard PCI resources and thus
don't want to allocate new resources in low IO/MEM space.

However, if we have already discovered a PCI bridge with a specified
resource base, that should override that decision.

This change will allow us to move the "careful" region upwards without
resulting in problems allocating resources in low mappings.  This was
brought on by us having allocated a bus resource at 0x1000, conflicting
with a undocumented VAIO Sony PI resources.

CFQ will currently stall when using write barriers and the default
max_depth setting of 1, since we artificially need a depth of 2 when
pre-pending the first flush. So never deny the barrier request going to
the device.

This is a regression since 2.6.12, it was found in SUSE testing.
Signed-off-by: NJens Axboe <axboe@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The aic7xxx can support Data Group transfers at periods > 12.5, so
eliminate that restriction.  Additionally wide is a requirement for DT
so ensure wide is set if users request DT.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Rebuild the aic7xxx firmware doesn't work anymore after this change
which appeared int 2.6.13-rc1:

   [SCSI] aic7xxx/aic79xx: remove useless byte order macro cruft

Two files did not include byteorder.h, resulting in aic dying with a panic

	"Unknown opcode encountered in seq program"

This fixes it for me.
Signed-off-by: NOlaf Hering <olh@suse.de>
Acked-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Recent changes (well, dating from 12 July) have broken cardbus on my
powerbook: I get 3 messages saying "no resource of type xxx available,
trying to continue", and if I plug in my wireless card, it complains
that there are no resources allocated to the card.  This all worked in
2.6.12.

Looking at the code in yenta_socket.c, function yenta_allocate_res,
it's obvious what is wrong: if we get to line 639 (i.e. there wasn't a
usable preassigned resource), we will always flow through to line 668,
which is the printk that I was seeing, even if a resource was
successfully allocated.  It looks to me as though there should be a
return statement after the two config_writel's in each of the 3
branches of the if statements, so that the function returns after
successfully setting up the resource.

The patch below adds these return statements, and with this patch,
cardbus works on my powerbook once again.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Acked-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Removing the SCSI tape module results in an oops in class_device_destroy if
any devices are present. The patch at the end of this message fixes the bug
by moving class_destroy() later in exit_st() so that the class still exists
when devices are removed. (The bug is old but class_simple_device_remove() did
nothing when the class did not exist.)

The patch also fixes a "class leak" in init_st() error path.

I would like to get this into 2.6.13 but it may be too late?
Signed-off-by: NKai Makisara <kai.makisara@kolumbus.fi>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

I am resubmitting the 2.6 kernel patch for the Version 7.12.02 ips driver.
I have eliminated a couple of inappropriate changes pointed out by Arjan.
Signed-off-by: NJack Hammer <jack_hammer@adaptec.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

This patch does correct radio chip autodetection to avoid misdetecting
mt20xx microtune as tea5767 chip.
Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Martin Drab found that he could get aacraid timeouts with high load on his
controller / disk drive combinations.  After some experimentation Mark
Salyzyn has come up with a patch to reduce the default max_sectors to
something that will keep the controller from being overloaded and will
eliminate the timeout issues.
Signed-off-by: NMark Haverkamp <markh@osdl.org>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Acked-by: NMark Salyzyn <mark_salyzyn@adaptec.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

cs89x0 talks a lot at boot.  Seems like debug leftover.  This patch
downgrades printks to KERN_DEBUG.  While we're at it, make these messages a
bit less obscure.

Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The default resync_max_sector is set to "mddev->size << 1".  If the
raid-personality-module updates mddev->size, it must update
resync_max_sectors too.
Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Peter Missel:
- Add support for the SVideo input on the GDI Black Gold.

Mauro Carvalho Chehab:
- Linux/version.h removed. Replaced by linux/utsname.h

Michael Krufky:
- Added analog support for DViCO FusionHDTV5 Gold.

CC: Peter Missel <peter.missel@onlinehome.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: NMichael Krufky <mkrufky@m1k.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- Fixed some bttv card numbers.

- BTTV and SAA7134 version numbers incremented to reflect changes.

- pci_dma_supported() is called after pci_set_dma_mask() which
  already did check that for us. This patch removes the unneeded call to
  pci_dma_supported() at bttv-driver.c

- Ensure a sufficient I2C bus idle time between 2 messages for
  saa7134-i2c.c

- It is important to write at first to MO_GP3_IO for cx88-tvaudio.c

- Use try_to_freeze() instead of refrigerator at msp3400.c

- Recognizing the MFPE05-2 Tuner at tveeprom.c

- Add new parameter to help identify radio chipsets at tuner module:
  show_i2c=1 will show 16 reading bytes from detected tuners.

- BTTV does generate some Unimplemented IOCTL log at tuner module:
  0x40046d11(dir=1,tp=0x6d,nr=17,sz=4) means that it is sending
  MSP3400 calls to non-msp3400 tuners. Warning eliminated.
  VIDIOSAUDIO is also called, so debug messages updated. It is still
  requiring IOCTL implementation.

- Added two more tuners.

- Add support for the SVideo input on the GDI Black Gold.
Signed-off-by: NPeter Missel <peter.missel@onlinehome.de>
Signed-off-by: NGraham Bevan <graham.bevan@ntlworld.com>
Signed-off-by: NTorsten Seeboth <Torsten.Seeboth@t-online.de>
Signed-off-by: NHartmut Hackmann <hartmut.hackmann@t.online.de>
Signed-off-by: NTobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: NMichael Krufky <mkrufky@m1k.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Make it compile with CONFIG_PM=n

Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Seems that both Greg and I submitted the same patch and it just kept on
applying...

Cc: Greg KH <greg@kroah.com>
Cc: Kumar Gala <galak@freescale.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

If there are devices that use interrupts over a suspend event, ACPI must
restore the PCI interrupt links on resume.  Anything else breaks any
device that hasn't been converted to the new (dubious) PM rules.

Drivers that need the irq free/re-aquire sequence can be done one by one
independently of this one.

Reported by: Jochen Hein (Bugzilla Bug 4312)

When there is disk I/O happening, the framebuffer has a little snow on
the screen.  Once I/O has finished, no garbage remains on screen.

This bug was explained by: Knut Petersen

Most important is CRTC register 2f, signal quality is also improved for
higher vclk values by changing set_vclk() according to the X drivers and
cyblafb.c

The fix is to set the performance register (0x2f) with a more stable
value.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Reported by: Jochen Hein (Bugzilla Bug 4386)

booting leaves the end of long lines in the last line on screen when
scrolling.  When X is running, scrolling puts garbage on the screen
(looks like X data) Console switch fixes the screen.  Behaviour seems to
be identical with noaccel and without on the video=tridentfb parameter
in lilo.conf.

This bug was explained by: Knut_Petersen

Acceleration is broken for all BLADE 3D chips for all versions of kernel
2.6 except for 32bit modes.  Most important reason is that the u32 col
parameter of the graphics engine needs the color value replicated to all
u8 of the u32 (8bit modes) and to both u16 of the u32.

Fix color value passed to graphics engine, verified by the reporter.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The ordering of setting and clearing device_add_pending went wrong on some
occasions, causing multifunction cards only to be handled correctly on the
first insertion, not on subsequent ones.
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>