This fixes the information copied back to userspace by the get reserved
contexts ioctl.
From: Egbert Eich <eich@suse.de>
Signed-off-by: Dave Airlie <airlied@linux.ie>
When recently addressing remarks by Alexey Dobriyan about
the isp116x-hcd, I introduced a bug in the driver. Please
apply the attached patch to fix it.
Signed-off-by: Olav Kongas <ok@artecdesign.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch has a one line oops fix, plus related cleanups.
- The bugfix uses microframe scheduling data given to the hardware to
test "is this a periodic QH", rather than testing for nonzero period.
(Prevents an oops by providing the correct answer.)
- The cleanup going along with the patch should make it clearer what's
going on whenever those bitfields are accessed.
The bug came about when, around January, two new kinds of EHCI interrupt
scheduling operation were added, involving both the high speed (24 KBytes
per millisec) and low/full speed (1-64 bytes per millisec) microframe
scheduling. A driver for the Edirol UA-1000 Audio Capture Unit ran into
the oops; it used one of the newly supported high speed modes.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus 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: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus 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: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
prevent:
HOTPLUG_CPU=y
ACPI_PROCESSOR=y
ACPI_HOTPLUG_CPU=n
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The video driver doesn't properly remove all the notify handlers
on module unload. This has a side effect of subdevices failing
to register on module reload, but sudden death looms if the
handlers trigger after the module is unloaded.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch upports all relevant code fixes and bumps the driver version
to 7.0 to signify starting a new tree.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
this patch is just a cross-port of the fixup for aic7xxx DT settings.
As the same restrictions apply for aic79xx also (DT requires wide
transfers) the dt setting routine should be modified equivalently.
And an invalid period setting will be caught by ahd_find_syncrate()
anyway.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This code was never designed to handle more than one instance of do_work()
running at once.
Signed-Off-By: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus 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: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus 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: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus 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: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus 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: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus 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: Michael Krufky <mkrufky@m1k.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus 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: Christoph Lameter <christoph@lameter.com>
Signed-off-by: Shai Fultheim <shai@scalex86.org>
Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
Cc: Andi Kleen <ak@muc.de>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus 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: James Bottomley <James.Bottomley@SteelEye.com>
commit from running until a change has been made in
the destination. In this instance the desired result
was to choose the destination version of the file
and ignore the source version, but git would not
allow that.
Here I added a blank line to let git commit think
I resolved a merge conflict.
ACPI now uses kmalloc(...,GPF_ATOMIC) during suspend/resume.
http://bugzilla.kernel.org/show_bug.cgi?id=3469
Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len 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: Luming Yu <luming.yu@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: Luming Yu <luming.yu@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This parameter is important only to people who take the time to tune the
margin control settings, otherwise it's completely irrelevant. However,
just in case anyone should want to do this, it's appropriate to include
the parameter.
I don't do anything with it in DV by design, so the parameter will come
up as off by default, so if anyone actually wants to play with the
margin control settings they'll have to enable it under the
spi_transport class first.
I also updated the transfer settings display to report all of the PPR
settings instead of only DT, IU and QAS
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.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: Ian Campbell <icampbell@arcom.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
There's a slight problem in the way you've done the transport
parameters; reading from the variables actually produces the current
settings, not the ones you just set (and there's usually a lag because
devices don't renegotiate until the next command goes over the bus). If
you set the bit immediately, you get into the situation where the
transport parameters report something as being set even if the drive
cannot support it.
I patched the driver to do it this way and also corrected a panic in the
proc routines.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This patch updates various scsi_transport_spi parameters with the actual
parameters used by the driver internally.
Domain Validation for all devices should now work properly.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This patch updates the aic79xx driver to take advantage of the
scsi_transport_spi infrastructure. Patch is quite a mess as some
procedures have been reshuffled to be closer to the aic7xxx driver.
Rejections fixed and
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
