thus we get a link error on ppc64 with CONFIG_PM=y. This fixes it.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
My patch "Cope with PCI host bridge I/O window not starting at 0"
introduced a bug in the calculation of the virtual addresses for the
I/O windows of PCI host bridges other than the first, because it
didn't account for the fact that hose->io_resource gets offset so that
it reflects the range of global I/O port numbers assigned to the
bridge. This fixes it and simplifies get_bus_io_range() in the
process.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is a bugfix to install Fedora Core 6 by using kernel
command line 'celleb_machine_type_hack=CHRP'.
Yes, this is a one-character fix to add forgotten '='.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Checking whether bus->self is NULL is not enough to know "bus" is the
primary bus.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Celleb has multiple PCI host bridges (phbs). Previous boot logic gives
non-overlapped bus IDs between PCI host bridges so you can identify
PHB by bus ID. But newer boot logic gives same bus ID between PHBs (it
gives bus ID 0 as root bus.) So we have to set 'phb->buid' as
non-zero.
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Use iteration for scanning of PROM node siblings.
Based upon a patch by Greg Onufer, who found this bug.
Signed-off-by: David S. Miller <davem@davemloft.net>
The ACPI EC that is used in MSI laptops knows some non-standard
commands for changing the screen brighntess and a few other things,
which are used by the msi-laptop.c driver. Unfortunately for these
commands no GPE events for IBF and OBF are triggered. Since nowadays
the EC code uses the ec_intr=1 mode by default, this causes these
operations to timeout, although they don't fail. In result, all
operations that you can do with the msi-laptop.c driver take more or
less 1s to complete, which is awfully slow.
In one of the more recent kernels (2.6.20?) the EC subsystem has been
revamped. With that change the EC timeout has been increased. before
that increase the MSI EC accesses were slow -- but not *that* slow,
hence I took notice of this limitation of the MSI EC hardware only very
recently.
The standard EC operations on the MSI EC as defined in the ACPI spec
support GPE events properly.
The following patch adds a new argument "force_poll" to the
ec_transaction() function (and friends). If set to 1, the function
will poll for IBF/OBF even if ec_intr=1 is enabled. If set to 0 the
current behaviour is used. The msi-laptop driver is modified to make
use of this new flag, so that OBF/IBF is polled for the special MSI EC
transactions -- but only for them.
Signed-off-by: Lennart Poettering <mzxreary@0pointer.de>
Acked-by: Alexey Starikovskiy <aystarik@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Just adds GPS support found in R2H thanks to Sam Lin. It will
make a "gps" file in /sys/devices/platform/asus-laptop/.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
We need to handle all events, because some dsdt use events >= 0x80
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
cpm_uart_init_portdesc is referenced from non-init code and thus we were
getting the following warning:
WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:cpm_uart_init_portdesc from .text between 'cpm_uart_init' (at offset 0x18020) and 'cpm_uart_drv_remove'
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The MPC834x_MDS device tree's PCI non-prefetchable MMIO range was
specified incorrectly. Both the local and bus addresses start at
0x90000000.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The MPC832x_MDS device tree's PCI non-prefetchable MMIO range was
specified incorrectly. Both the local and bus addresses start at
0x90000000.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The rheap allocation functions return a pointer, but the actual value is based
on how the heap was initialized, and so it can be anything, e.g. an offset
into a buffer. A ulong is a better representation of the value returned by
the allocation functions.
This patch changes all of the relevant rheap functions to use a unsigned long
integers instead of a pointer. In case of an error, the value returned is
a negative error code that has been cast to an unsigned long. The caller can
use the IS_ERR_VALUE() macro to check for this.
All code which calls the rheap functions is updated accordingly. Macros
IS_MURAM_ERR() and IS_DPERR(), have been deleted in favor of IS_ERR_VALUE().
Also added error checking to rh_attach_region().
Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
HD interface and AC97 interface share some pins and they are enabled at
the same time, In order to use AC97 interface, we need to disable the HD
interface first.
Signed-off-by:Jason Jin<jason.jin@freescale.com>
Acked-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch moves a copy of reg_booke.h to include/asm-powerpc and fixes
up the ifdef protection.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.
Notify handler in ACPI driver is a C-routine, which may call ACPI
interpreter again to get access to some ACPI variables
(acpi_evaluate_xxx).
On these HP machines such an evaluation changes state of some variable
and lets the loop above break.
In the current ACPI implementation Notify requests are being deferred
to the same kacpid workqueue on which the above GPE handler with
infinite loop is executing. Thus we have a deadlock -- loop will
continue to spin, sending notify events, and at the same time
preventing these notify events from being run on a workqueue. All
notify events are deferred, thus we see increase in memory consumption
noticed by author of the thread. Also as GPE handling is bloked,
machines overheat. Eventually by external poll of the same
acpi_evaluate, kacpid is released and all the queued notify events are
free to run, thus 100% cpu utilization by kacpid for several seconds
or more.
To prevent all these horrors it's needed to not put notify events to
kacpid workqueue by either executing them immediately or putting them
on some other thread. It's dangerous to execute notify events in
place, as it will put several ACPI interpreter stacks on top of each
other (at least 4 in case of nx6125), thus causing kernel stack
overflow.
First attempt to create a new thread was done by Peter Wainwright
He created a bunch of threads, which were stealing work from a kacpid
workqueue.
This patch appeared in 2.6.15 kernel shipped with Ubuntu 6.06 LTS.
Second attempt was done by me, I created a new thread for each Notify
event. This worked OK on HP nx machines, but broke Linus' Compaq
n620c, by producing threads with a speed what they stopped the machine
completely. Thus this patch was reverted from 18-rc2 as I remember.
I re-made the patch to create second workqueue just for notify events,
thus hopping it will not break Linus' machine. Patch was tested on the
same HP nx machines in #5534 and #7122, but I did not received reply
from Linus on a test patch sent to him.
Patch went to 19-rc and was rejected with much fanfare again.
There was 4th patch, which inserted schedule_timeout(1) into deferred
execution of kacpid, if we had any notify requests pending, but Linus
decided that it was too complex (involved either changes to workqueue
to see if it's empty or atomic inc/dec).
Now you see last variant which adds yield() to every GPE execution.
http://bugzilla.kernel.org/show_bug.cgi?id=5534http://bugzilla.kernel.org/show_bug.cgi?id=8385
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit c0d127b569.
These changes to AML locking were made to allow
Notify handlers to be called on the stack
and not deadlock. However, that scheme turns
out to be flawed and was reverted by the previous commit,
so this commit restores the locking to it previous design.
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit a8f4af6dc6.
Thus restoring ACPICA's new acpi_serialize code.
This commit by itself may cause a regression, but
it is reverted in this order so that subsequent
reverts reverts under this one can be made
without conflict.
Signed-off-by: Len Brown <len.brown@intel.com>
* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband:
IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters
IB: Put rlimit accounting struct in struct ib_umem
IB/uverbs: Export ib_umem_get()/ib_umem_release() to modules
This reverts commit 5b479c91da.
Quoth Neil Brown:
"It causes an oops when auto-detecting raid arrays, and it doesn't
seem easy to fix.
The array may not be 'open' when do_md_run is called, so
bdev->bd_disk might be NULL, so bd_set_size can oops.
This whole approach of opening an md device before it has been
assembled just seems to get more and more painful. I think I'm going
to have to come up with something clever to provide both backward
comparability with usage expectation, and sane integration into the
rest of the kernel."
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It is preferable to group drivers by usage (net, scsi, ATA, ...) than
by bus. When reviewing drivers, the [PCI|USB|PCMCIA|...] maintainer
is probably less qualified on networking issues than a networking
maintainer. Also, from a practical standpoint, chips often
appear on multiple buses, which is why we do not put drivers into
drivers/pci/net.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Looks like you removed the combined_mode quirk (yay!) but didn't update
kernel-parameters.txt... might confuse people. Here's a patch to remove
mention of it from the documentation.
Signed-off-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Warning(linux-2.6.21-git4//drivers/ata/libata-core.c:904): No description found for parameter 'new_sectors'
Warning(linux-2.6.21-git4//drivers/ata/libata-core.c:941): No description found for parameter 'new_sectors'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This patch fixes some problems with ADMA-capable controllers with
regard to freeze, thaw and irq_clear libata callbacks. Freeze and
thaw didn't switch the ADMA-specific interrupts on or off, and more
critically the irq_clear function didn't respect the restriction that
the notifier clear registers for both ports have to be written at
the same time even when only one port is being cleared. This could
result in timeouts on one port when error handling (i.e. as a result
of hotplug) occurred on the other port.
As well, this fixes some issues in the interrupt handler: we shouldn't
check any ADMA status if the port has ADMA switched off because of
an ATAPI device, and it also checks to see if any ADMA interrupt has
been raised even when we are in port-register mode.
Signed-off-by: Robert Hancock <hancockr@shaw.ca>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
