linux-toradex.git/include, branch v2.6.27.16

Revert "vt: fix background color on line feed"

2009-02-12T17:31:12+00:00

commit 93f78da405685a756beeaeae4b5e41fcec39eab3 upstream.

This reverts commit c9e587abfdec2c2aaa55fab83bcb4972e2f84f9b, and the
subsequent commits that fixed it up:

 - afa9b649 "fbcon: prevent cursor disappearance after switching to 512
   character font"

 - d850a2fa "vt/fbcon: fix background color on line feed"

 - 7fe3915a "vt/fbcon: update scrl_erase_char after 256/512-glyph font
   switch"

by request of Alan Cox. Quoth Alan:
  "Unfortunately it's wrong and its been causing breakages because
   various apps like ncurses expect our previous (and correct)
   behaviour."

Alexander sent out a similar patch.

Requested-by: Alan Cox 
Tested-by: Jan Engelhardt 
Cc: Alexander V. Lukyanov 
Signed-off-by: Linus Torvalds 
Cc: Tony Jones 
Signed-off-by: Greg Kroah-Hartman

serial: set correct baud_base for Oxford Semiconductor Ltd EXSYS EX-41092 Dual 16950 Serial adapter

2009-02-12T17:31:11+00:00

commit 39aced68d664291db3324d0fcf0985ab5626aac2 upstream.

The PCI-card identified as "Oxford Semiconductor Ltd EXSYS EX-41092 Dual
16950 Serial adapter" is only usable with other devices (i.e. not the same
card) after doing a "setserial /dev/ttyS baud_base 115200".  This
baud_base should be default for this card.

Signed-off-by: Niels de Vos 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

PCI: return error on failure to read PCI ROMs

2009-02-12T17:31:10+00:00

commit 97c44836cdec1ea713a15d84098a1a908157e68f upstream.

This patch makes the ROM reading code return an error to user space if
the size of the ROM read is equal to 0.

The patch also emits a warnings if the contents of the ROM are invalid,
and documents the effects of the "enable" file on ROM reading.

Signed-off-by: Timothy S. Nelson 
Acked-by: Alex Villacis-Lasso 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

wait: prevent exclusive waiter starvation

2009-02-12T17:31:04+00:00

commit 777c6c5f1f6e757ae49ecca2ed72d6b1f523c007 upstream.

With exclusive waiters, every process woken up through the wait queue must
ensure that the next waiter down the line is woken when it has finished.

Interruptible waiters don't do that when aborting due to a signal.  And if
an aborting waiter is concurrently woken up through the waitqueue, noone
will ever wake up the next waiter.

This has been observed with __wait_on_bit_lock() used by
lock_page_killable(): the first contender on the queue was aborting when
the actual lock holder woke it up concurrently.  The aborted contender
didn't acquire the lock and therefor never did an unlock followed by
waking up the next waiter.

Add abort_exclusive_wait() which removes the process' wait descriptor from
the waitqueue, iff still queued, or wakes up the next waiter otherwise.
It does so under the waitqueue lock.  Racing with a wake up means the
aborting process is either already woken (removed from the queue) and will
wake up the next waiter, or it will remove itself from the queue and the
concurrent wake up will apply to the next waiter after it.

Use abort_exclusive_wait() in __wait_event_interruptible_exclusive() and
__wait_on_bit_lock() when they were interrupted by other means than a wake
up through the queue.

[akpm@linux-foundation.org: coding-style fixes]
Reported-by: Chris Mason 
Signed-off-by: Johannes Weiner 
Mentored-by: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Matthew Wilcox 
Cc: Chuck Lever 
Cc: Nick Piggin 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

module: remove over-zealous check in __module_get()

2009-02-12T17:31:02+00:00

commit 7f9a50a5b89b87f8e754f59ae9968da28be618a5 upstream.

Impact: fix spurious BUG_ON() triggered under load

module_refcount() isn't reliable outside stop_machine(), as demonstrated
by Karsten Keil , networking can trigger it under load
(an inc on one cpu and dec on another while module_refcount() is tallying
 can give false results, for example).

Almost noone should be using __module_get, but that's another issue.

Cc: Karsten Keil 
Signed-off-by: Rusty Russell 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ACPI: Enable bit 11 in _PDC to advertise hw coord

2009-02-12T17:30:59+00:00

commit d96f94c604453f87fe24154b87e1e9a3a72511f8 upstream.

Bit 11 in intel PDC definitions is meant for OS capability to handle
hardware coordination of P-states. In Linux we have always supported
hwardware coordination of P-states. Just let the BIOSes know that we
support it, by setting this bit.

Some BIOSes use this bit to choose between hardware or software coordination
and without this change below, BIOSes switch to software coordination, which
is not very optimal in terms of power consumption and extra wakeups from idle.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPICA: Fix wrong resource descriptor length for 64-bit build

2009-02-06T22:00:43+00:00

commit 9db4fcd99f7ef886ded97cd26a8642c70fbe34df upstream.

The "minimal" descriptors such as EndTag are calculated as 12
bytes long, but the actual length in the internal descriptor is
16 because of the round-up to 8 on 64-bit build.

http://www.acpica.org/bugzilla/show_bug.cgi?id=728

Signed-off-by: Bob Moore 
Signed-off-by: Lin Ming 
Signed-off-by: Andi Kleen 
Signed-off-by: Len Brown 
Cc: Thomas Renninger 
Signed-off-by: Greg Kroah-Hartman

ACPI: Change acpi_evaluate_integer to support 64-bit on 32-bit kernels

2009-02-06T22:00:42+00:00

commit 27663c5855b10af9ec67bc7dfba001426ba21222 upstream

As of version 2.0, ACPI can return 64-bit integers.  The current
acpi_evaluate_integer only supports 64-bit integers on 64-bit platforms.
Change the argument to take a pointer to an acpi_integer so we support
64-bit integers on all platforms.

lenb: replaced use of "acpi_integer" with "unsigned long long"
lenb: fixed bug in acpi_thermal_trips_update()

Signed-off-by: Matthew Wilcox 
Signed-off-by: Len Brown 
Cc: Thomas Renninger 
Signed-off-by: Greg Kroah-Hartman

PCI: irq and pci_ids patch for Intel Tigerpoint DeviceIDs

2009-02-06T22:00:38+00:00

commit 57064d213d2e44654d4f13c66df135b5e7389a26 upstream.

This patch adds the Intel Tigerpoint LPC Controller DeviceIDs.

Signed-off-by: Seth Heasley 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

net: fix packet socket delivery in rx irq handler

2009-02-06T22:00:36+00:00

commit 9b22ea560957de1484e6b3e8538f7eef202e3596 upstream.

The changes to deliver hardware accelerated VLAN packets to packet
sockets (commit bc1d0411) caused a warning for non-NAPI drivers.
The __vlan_hwaccel_rx() function is called directly from the drivers
RX function, for non-NAPI drivers that means its still in RX IRQ
context:

[   27.779463] ------------[ cut here ]------------
[   27.779509] WARNING: at kernel/softirq.c:136 local_bh_enable+0x37/0x81()
...
[   27.782520]  [] netif_nit_deliver+0x5b/0x75
[   27.782590]  [] __vlan_hwaccel_rx+0x79/0x162
[   27.782664]  [] atl1_intr+0x9a9/0xa7c [atl1]
[   27.782738]  [] handle_IRQ_event+0x23/0x51
[   27.782808]  [] handle_edge_irq+0xc2/0x102
[   27.782878]  [] do_IRQ+0x4d/0x64

Split hardware accelerated VLAN reception into two parts to fix this:

- __vlan_hwaccel_rx just stores the VLAN TCI and performs the VLAN
  device lookup, then calls netif_receive_skb()/netif_rx()

- vlan_hwaccel_do_receive(), which is invoked by netif_receive_skb()
  in softirq context, performs the real reception and delivery to
  packet sockets.

Reported-and-tested-by: Ramon Casellas 
Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller 
Cc: Jesse Brandeburg 
Signed-off-by: Greg Kroah-Hartman