Linux/ACPI core files using internal.h all PREFIX "ACPI: ",
however, not all ACPI drivers use/want it -- and they
should not have to #undef PREFIX to define their own.

Add GPL commment to internal.h while we are there.

This does not change any actual console output,
asside from a whitespace fix.
Signed-off-by: NLen Brown <len.brown@intel.com>

As soon as the framebuffer is registered, our methods may be called by the
kernel. This leads to a crash as xenfb_refresh() gets called before we have
the irq.

Connect to the backend before registering our framebuffer with the kernel.

[ Fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14059 ]
Signed-off-by: NMichal Schmidt <mschmidt@redhat.com>
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If we change the inverted attribute to another value, the LED will not be
inverted until we change the GPIO state.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: Samuel R. C. Vale <srcvale@holoscopio.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When setting the same GPIO number, multiple IRQ shared requests will be
done without freing the previous request.  It will also try to free a
failed request or an already freed IRQ if 0 was written to the gpio file.

All these oops and leaks were fixed with the following solution: keep the
previous allocated GPIO (if any) still allocated in case the new request
fails.  The alternative solution would desallocate the previous allocated
GPIO and set gpio as 0.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NSamuel R. C. Vale <srcvale@holoscopio.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This failure is very common on many platforms.  Handling it in the ACPI
processor driver is enough, and we don't need a warning message unless
CONFIG_ACPI_DEBUG is set.

Based on a patch from Zhang Rui.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the BIOS reports an invalid throttling state (which seems to be
fairly common after system boot), a reset is done to state T0.
Because of a check in acpi_processor_get_throttling_ptc(), the reset
never actually gets executed, which results in the error reoccurring
on every access of for example /proc/acpi/processor/CPU0/throttling.

Add a 'force' option to acpi_processor_set_throttling() to ensure
the reset really takes effect.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13389

This patch, together with the next one, fixes a regression introduced in
2.6.30, listed on the regression list. They have been available for 2.5
months now in bugzilla, but have not been picked up, despite various
reminders and without any reason given.

Google shows that numerous people are hitting this issue. The issue is in
itself relatively minor, but the bug in the code is clear.

The patches have been in all my kernels and today testing has shown that
throttling works correctly with the patches applied when the system
overheats (http://bugzilla.kernel.org/show_bug.cgi?id=13918#c14).
Signed-off-by: NFrans Pop <elendil@planet.nl>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Summary:
Kernel panic arise when stack protection is enabled, since strncat will
add a null terminating byte '\0'; So in functions
like this one (wmi_query_block):
        char wc[4]="WC";
	....
	strncat(method, block->object_id, 2);
        ...
the length of wc should be n+1 (wc[5]) or stack protection
fault will arise. This is not noticeable when stack protection is
disabled,but , isn't good either.
Config used: [CONFIG_CC_STACKPROTECTOR_ALL=y,
	      CONFIG_CC_STACKPROTECTOR=y]

Panic Trace
------------
       .... stack-protector: kernel stack corrupted in : fa7b182c
       2.6.30-rc8-obelisco-generic
       call_trace:
           [<c04a6c40>] ? panic+0x45/0xd9
	   [<c012925d>] ? __stack_chk_fail+0x1c/0x40
	   [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi]
	   [<fa7b182c>] ? wmi_query_block+0x15a/0x162 [wmi]
	   [<fa7e7000>] ? acer_wmi_init+0x00/0x61a [acer_wmi]
	   [<fa7e7135>] ? acer_wmi_init+0x135/0x61a [acer_wmi]
	   [<c0101159>] ? do_one_initcall+0x50+0x126

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13514Signed-off-by: NCostantino Leandro <lcostantino@gmail.com>
Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Len Brown <len.brown@intel.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Jens reported early_ioremap messages with old ASUS board...

> [    1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
> [    1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36
> [    1.561007] Call Trace:
> [    1.568638]  [<c136e48b>] ? printk+0x18/0x1d
> [    1.581734]  [<c15513ff>] __early_ioremap+0x74/0x1e9
> [    1.596898]  [<c15515aa>] early_ioremap+0x1a/0x1c
> [    1.611270]  [<c154a187>] __acpi_map_table+0x18/0x1a
> [    1.626451]  [<c135a7f8>] acpi_os_map_memory+0x1d/0x25
> [    1.642129]  [<c119459c>] acpi_tb_verify_table+0x20/0x49
> [    1.658321]  [<c1193e50>] acpi_get_table_with_size+0x53/0xa1
> [    1.675553]  [<c1193eae>] acpi_get_table+0x10/0x15
> [    1.690192]  [<c155cc19>] acpi_processor_init+0x23/0xab
> [    1.706126]  [<c1001043>] do_one_initcall+0x33/0x180
> [    1.721279]  [<c155cbf6>] ? acpi_processor_init+0x0/0xab
> [    1.737479]  [<c106893a>] ? register_irq_proc+0xaa/0xc0
> [    1.753411]  [<c10689b7>] ? init_irq_proc+0x67/0x80
> [    1.768316]  [<c15405e7>] kernel_init+0x120/0x176
> [    1.782678]  [<c15404c7>] ? kernel_init+0x0/0x176
> [    1.797062]  [<c10038b7>] kernel_thread_helper+0x7/0x10
> [    1.812984] 00000080 + ffe00000

that is rather later.
acpi_gbl_permanent_mmap should be set in acpi_early_init()
if acpi is not disabled

and we have
> [    0.000000] ASUS P2B-DS detected: force use of acpi=ht

just don't load acpi_processor_init...
Reported-and-tested-by: NJens Rosenboom <jens@leia.mcbone.net>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The return value of the get_temp function is not checked when doing a
thermal zone update.  This may lead to a critical shutdown if get_temp
fails and the content of the temp variable is incorrectly set higher than
the critical trip point.

This has been observed on a system with incorrect ACPI implementation
where the corresponding methods were not serialized and therefore
sometimes triggered ACPI errors (AE_ALREADY_EXISTS).  The following
critical shutdowns indicated a temperature of 2097 C, which was obviously
wrong.

The patch adds a return value check that jumps over all trip point
evaluations printing a warning if get_temp fails.  The trip points are
evaluated again on the next polling interval with successful get_temp
execution.
Signed-off-by: NMichael Brunner <mibru@gmx.de>
Acked-by: NZhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix incorrect verdict check and returns error if device_create failed,
otherwise driver triggers kernel oops.

Signed-off-by: Joonwoo Park<joonwpark81@gmail.com>
Cc: Rodolfo Giometti <giometti@enneenne.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With while (count++ < 50) { ...  } count can reach 51, not 50, so we
shouldn't give an error message on a count of 50.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

If we run out of memory, use keventd to fill the buffer.  There's a
report of this happening: "Page allocation failures in guest",
Message-ID: <20090713115158.0a4892b0@mjolnir.ossman.eu>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch is based on commit d2f3ad4c (pxaficp-ir: remove incorrect
net_device_ops). Do the same for sa1100_ir.
Untested.
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch is based on commit d2f3ad4c (pxaficp-ir: remove incorrect
net_device_ops). Do the same for au1k_ir.
Untested.
Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When I rewrote tty ldisc code to use proper reference counts (commits
65b77046 and cbe9352f) in order to avoid a race with hangup, the
test-program that Eric Biederman used to trigger the original problem
seems to have exposed another long-standing bug: the hangup code did the
'tty_ldisc_halt()' to stop any buffer flushing activity, but unlike the
other call sites it never actually flushed any pending work.

As a result, if you get just the right timing, the pending work may be
just about to execute (ie the timer has already triggered and thus
cancel_delayed_work() was a no-op), when we then re-initialize the ldisc
from under it.

That, in turn, results in various random problems, usually seen as a
NULL pointer dereference in run_timer_softirq() or a BUG() in
worker_thread (but it can be almost anything).

Fix it by adding the required 'flush_scheduled_work()' after doing the
tty_ldisc_halt() (this also requires us to move the ldisc halt to before
taking the ldisc mutex in order to avoid a deadlock with the workqueue
executing do_tty_hangup, which requires the mutex).

The locking should be cleaned up one day (the requirement to do this
outside the ldisc_mutex is very annoying, and weakens the lock), but
that's a larger and separate undertaking.
Reported-by: NEric W. Biederman <ebiederm@xmission.com>
Tested-by: NXiaotian Feng <xtfeng@gmail.com>
Tested-by: NYanmin Zhang <yanmin_zhang@linux.intel.com>
Tested-by: NDave Young <hidave.darkstar@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

GCC 4.3.3 and 4.4.1 happily moves the dword load instruction out of the
loop in orion_nand_read_buf. This patch makes the instruction volatile
to avoid the issue. I've discussed this at gcc-help, refer to the thread
at

  http://gcc.gnu.org/ml/gcc-help/2009-08/msg00187.html

The early clobber is added to avoid the destination registers and the
source register overlapping.
Signed-off-by: NSimon Kagstrom <simon.kagstrom@netinsight.net>
Signed-off-by: NNicolas Pitre <nico@marvell.com>

The NETPOLL requires that interrupts remain disabled in its callbacks.

Using *_irq_save()/irq_restore() to replace *_irq_disable()/irq_enable()
functions in NETPOLL's callbacks of smc91x, so that it doesn't enable
interrupts when already disabled, and kgdboe/netconsole would work
properly over smc91x.
Signed-off-by: NDongdong Deng <dongdong.deng@windriver.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes broken pxaficp-ir. The problem was in incorrect
net_device_ops being specified which prevented the driver from
operating. The symptoms were:
 - failing ifconfig for IrLAN, resulting in
	SIOCSIFFLAGS: Cannot assign requested address
 - irattach working for IrCOMM, but the port stayed disabled

Moreover this patch corrects missing sysfs device link.
Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The NETPOLL API requires that interrupts remain disabled in
netpoll_send_skb(). The use of "A functions set" in the NETPOLL API
callbacks causes the interrupts to get enabled and can lead to kernel
instability.

The solution is to use "B functions set" to prevent the irqs from
getting enabled while in netpoll_send_skb().

A functions set:
local_irq_disable()/local_irq_enable()
spin_lock_irq()/spin_unlock_irq()
spin_trylock_irq()/spin_unlock_irq()

B functions set:
local_irq_save()/local_irq_restore()
spin_lock_irqsave()/spin_unlock_irqrestore()
spin_trylock_irqsave()/spin_unlock_irqrestore()
Signed-off-by: NDongdong Deng <dongdong.deng@windriver.com>
Acked-by: NMatt Mackall <mpm@selenic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAndreas Mohr <andi@lisas.de>
Acked-by: NRichard Röjfors <richard.rojfors.ext@mocean-labs.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

E100 places it's RX packet descriptors inside skb->data and uses them
with bidirectional streaming DMA mapping. Data in descriptors is
accessed simultaneously by the chip (writing status and size when
a packet is received) and CPU (reading to check if the packet was
received). This isn't a valid usage of PCI DMA API, which requires use
of the coherent (consistent) memory for such purpose. Unfortunately e100
chips working in "simplified" RX mode have to store received data
directly after the descriptor. Fixing the driver to conform to the API
would require using unsupported "flexible" RX mode or receiving data
into a coherent memory and using CPU to copy it to network buffers.

This patch, while not yet making the driver conform to the PCI DMA API,
allows it to work correctly on X86 with swiotlb (while not breaking
other architectures).
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the NULL test on block is needed, it should be before the dereference of
the base field.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
expression E1,E2;
identifier fld;
statement S1,S2;
@@

E1 = E2->fld;
(
if (E1 == NULL) S1 else S2
|
*if (E2 == NULL) S1 else S2
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

If io_subchannel_initialize_dev fails it will release the only
reference to the ccw device therefore the caller should not
kfree this device since this is done in the release function.
Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

It was mixing up TTM placement values and flags.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

RTL8187B always needs MSR_LINK_ENEDCA flag to be set even when it is in
no link mode, otherwise it'll not be able to associate when this flag is
not set after the change "mac80211: fix managed mode BSSID handling".

By accident, setting BSSID of AP before association makes 8187B to
successfuly associate even when ENEDCA flag isn't set, which was the
case before the mac80211 change. But now the BSSID of AP we are trying
to associate is only available after association is successful, and
any attempt to associate without the needed flag doesn't work.
Signed-off-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Acked-by: NHin-Tak Leung <htl10@users.sourceforge.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Needed for occlusion queries on rv530 chips.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Sometimes, when using the touchscreen, it stops working till next restart
and the following message is printed:

	ucb1400: unexpected IE_STATUS = 0x0

The following patch retriggers the touchscreen interrupt unconditionally.
This prevents hanging of the touchscreen in case of bogus interrupt
occurence.
Signed-off-by: NPavel Revak <palo@bielyvlk.sk>
Acked-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This patch enables ADC filtering on UCB1400 codec by default. The
benefit from this change is mostly on some Colibri boards where
the ADCSYNC pin of the UCB1400 codec isn't connected causing the
touchscreen to jitter very badly. This change has no visible
effect on boards where the ADCSYNC pin is connected.
Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Tested-by: NPalo Revak <palo@bielyvlk.sk>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Tested-by: NMartin Capitanio <martin@capitanio.org>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This adds the relocation necessary for OQ support on the r100/r200
chipsets.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm sysfs class suspend / resume methods could not distinguish
between different device types wich could lead to illegal type casts.

Use struct device_type and make sure the class suspend / resume callbacks
are aware of those. There is no per device-type suspend / resume. Only
new-style PM.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The previous patch assumes the ioctl already existed, when
it actually didn't.

It also didn't return the correct error code.
Signed-off-by: NDave Airlie <airlied@redhat.com>

- blk clk is enabled when an irq arrives. The clk should be enabled,
  but just to make sure.
- All error bits are handled no matter state machine state
- All irq's will run complete() except for irq's that wasn't an event.
- No more looking into status registers just in case an interrupt
  has happend and the irq handle wasn't executed.
- irq_disable/enable are now separete functions.
- clk settings calculation changed to round upwards instead of
  downwards.
- Number of address send attempts before giving up is increased to 12
  from 10 since it most times take 8 tries before getting through.
Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Silicon Errata 1.153 has been fixed on OMAP 3630|4430 with the use of a later
version of I2C IP block.

The errata impacts OMAP 2420|2430|3430, enable the workaround for these based
on I2C IP block revision number instead of OMAP CPU type
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

ACK any pending read/write interrupts before exiting the ISR either after
completing the operation [ARDY interrupt] or in case of an error
[NACK|AL interrupt]
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

I2C status ack for [RX]RDR and [RX]RDY could
cause race conditions of clearing the event
twice and a violation of the programing
sequence as defined in TRM This patch fixes
the same.
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Without the check, the config space may be filled with zeros. Though
the driver should try to avoid call restoring before saving, but the
pci layer also should check this.

Also removes the existing check in pci_restore_standard_config, since
it's superfluous with the new check in restore_state.
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NAlek Du <alek.du@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

When ibm_newemac netdev instance is shutdown with "ifconfig down",
the netdev interface does not go properly down. netif_carrier_ok()
keeps returning TRUE even after "ifconfig down".

The problem can be seen when ibm_newemac instances are slaves of
a bonding interface. The bonding interface code uses netif_carrier_ok()
to determine the link status of its slaves. When ibm_newemac slave is
shutdown with "ifconfig down", the bonding interface won't detect any
link status change because netif_carrier_ok() keeps returning TRUE.
Signed-off-by: NPetri Gynther <pgynther@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reported-by: cemede@gmail.com
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>