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

ide/libata: fix ata_id_is_cfa() (take 4)

2009-02-17T17:29:02+00:00

commit 2999b58b795ad81f10e34bdbbfd2742172f247e4 upstream.

When checking for the CFA feature set support, ata_id_is_cfa() tests bit 2 in
word 82 of the identify data instead the word 83;  it also checks the ATA/PI
version support in the word 80 (which the CompactFlash specifications have as
reserved), this having no slightest chance to work on the modern CF cards that
don't have 0x848A in the word 0...

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Jeff Garzik 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

net: Fix userland breakage wrt. linux/if_tunnel.h

2009-02-17T17:28:55+00:00

[ Upstream commit 0afd4a21ba7d75e93fa79cf05d7a21774e149c0f ]

Reported by Andrew Walrond 

Changeset c19e654ddbe3831252f61e76a74d661e1a755530
("gre: Add netlink interface") added an include
of linux/ip.h to linux/if_tunnel.h

We can't really let that get exposed to userspace
because this conflicts with types defined in netinet/ip.h
which userland is almost certainly going to have included
either explicitly or implicitly.

So guard this include with a __KERNEL__ ifdef.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

syscall define: fix uml compile bug

2009-02-17T17:28:47+00:00

commit 6c5979631b4b03c9288776562c18036765e398c1 upstream.

With the new system call defines we get this on uml:

arch/um/sys-i386/built-in.o: In function `sys_call_table':
(.rodata+0x308): undefined reference to `sys_sigprocmask'

Reason for this is that uml passes the preprocessor option
-Dsigprocmask=kernel_sigprocmask to gcc when compiling the kernel.
This causes SYSCALL_DEFINE3(sigprocmask, ...) to be expanded to
SYSCALL_DEFINEx(3, kernel_sigprocmask, ...) and finally to a system
call named sys_kernel_sigprocmask.  However sys_sigprocmask is missing
because of this.

To avoid macro expansion for the system call name just concatenate the
name at first define instead of carrying it through severel levels.
This was pointed out by Al Viro.

Signed-off-by: Heiko Carstens 
Cc: Geert Uytterhoeven 
Cc: Al Viro 
Reviewed-by: WANG Cong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
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:50:36+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:50:35+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

serial: RS485 ioctl structure uses __u32 include linux/types.h

2009-02-12T17:50:27+00:00

commit 60c20fb8c00a2b23308ae4517f145383bc66d291 upstream.

In the commit below a new struct serial_rs485 was introduced for a new
ioctl:

    commit c26c56c0f40e200e61d1390629c806f6adaffbcc
    Author: Alan Cox 
    Date:   Mon Oct 13 10:37:48 2008 +0100

	tty: Cris has a nice RS485 ioctl so we should steal it

This structure uses the __u32 types for some of its members, which leads
to the following compile error:

    $ cc -I.../include -c X.c
    In file included from X.c:2: .../include/linux/serial.h:185:
		error: expected specifier-qualifier-list before ‘__u32’
    $

It seems that these types are appropriate for this structure as it is
to be exposed to userspace.  These types are available via linux/types.h
so move the include of that outside the __KERNEL__ section.

Signed-off-by: Andy Whitcroft 
Signed-off-by: Andrew Morton 
Signed-off-by: Alan Cox 
Signed-off-by: Linus Torvalds 
Cc: Matthew Burgess 
Signed-off-by: Greg Kroah-Hartman

module: remove over-zealous check in __module_get()

2009-02-12T17:50:26+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

wait: prevent exclusive waiter starvation

2009-02-12T17:50:23+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

PCI: irq and pci_ids patch for Intel Tigerpoint DeviceIDs

2009-02-06T21:47:23+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

kmalloc: return NULL instead of link failure

2009-02-06T21:47:19+00:00

commit 1cf3eb2ff6b0844c678f2f48d0053b9d12b7da67 upstream.

The SLAB kmalloc with a constant value isn't consistent with the other
implementations because it bails out with __you_cannot_kmalloc_that_much
rather than returning NULL and properly allowing the caller to fall back
to vmalloc or take other action.  This doesn't happen with a non-constant
value or with SLOB or SLUB.

Starting with 2.6.28, I've been seeing build failures on s390x.  This is
due to init_section_page_cgroup trying to allocate 2.5MB when the max size
for a kmalloc on s390x is 2MB.

It's failing because the value is constant.  The workarounds at the call
size are ugly and the caller shouldn't have to change behavior depending
on what the backend of the API is.

So, this patch eliminates the link failure and returns NULL like the other
implementations.

Signed-off-by: Jeff Mahoney 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: Matt Mackall 
Cc: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Pekka Enberg 
Signed-off-by: Greg Kroah-Hartman