linux-toradex.git/drivers, branch v2.6.27.24

powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver

2009-05-20T05:20:14+00:00

commit d9f0c5f9bc74f16d0ea0f6c518b209e48783a796 upstream.

The MPC5200 PSC device is wired up to a dedicated interrupt line
which is never shared.  This patch removes the IRQF_SHARED flag
from the request_irq() call which eliminates the "IRQF_DISABLED
is not guaranteed on shared IRQs" warning message from the console
output.

Signed-off-by: Grant Likely 
Reviewed-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

ehea: fix invalid pointer access

2009-05-20T05:20:14+00:00

commit 0b2febf38a33d7c40fb7bb4a58c113a1fa33c412 upstream.

This patch fixes an invalid pointer access in case the receive queue
holds no pointer to the next skb when the queue is empty.

Signed-off-by: Hannes Hering 
Signed-off-by: Jan-Bernd Themann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mm: page_mkwrite change prototype to match fault

2009-05-20T05:20:09+00:00

commit c2ec175c39f62949438354f603f4aa170846aabb upstream


mm: page_mkwrite change prototype to match fault

Change the page_mkwrite prototype to take a struct vm_fault, and return
VM_FAULT_xxx flags.  There should be no functional change.

This makes it possible to return much more detailed error information to
the VM (and also can provide more information eg.  virtual_address to the
driver, which might be important in some special cases).

This is required for a subsequent fix.  And will also make it easier to
merge page_mkwrite() with fault() in future.

Signed-off-by: Nick Piggin 
Cc: Chris Mason 
Cc: Trond Myklebust 
Cc: Miklos Szeredi 
Cc: Steven Whitehouse 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: Artem Bityutskiy 
Cc: Felix Blyakher 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

i2c-algo-pca: Let PCA9564 recover from unacked data byte (state 0x30)

2009-05-20T05:20:08+00:00

commit 2196d1cf4afab93fb64c2e5b417096e49b661612 upstream

Currently, the i2c-algo-pca driver does nothing if the chip enters state
0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been
received).  Thus, the i2c bus connected to the controller gets stuck
afterwards.

I have seen this kind of error on a custom board in certain load
situations most probably caused by interference or noise.

A possible reaction is to let the controller generate a STOP condition.
This is documented in the PCA9564 data sheet (2006-09-01) and the same
is done for other NACK states as well.

Further, state 0x38 isn't handled completely, either. Try to do another
START in this case like the data sheet says. As this couldn't be tested,
I've added a comment to try to reset the chip if the START doesn't help
as suggested by Wolfram Sang.

Signed-off-by: Enrik Berkhan 
Reviewed-by: Wolfram Sang 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

i2c-algo-bit: Fix timeout test

2009-05-20T05:20:08+00:00

commit 0cdba07bb23cdd3e0d64357ec3d983e6b75e541f upstream

When fetching DDC using i2c algo bit, we were often seeing timeouts
before getting valid EDID on a retry. The VESA spec states 2ms is the
DDC timeout, so when this translates into 1 jiffie and we are close
to the end of the time period, it could return with a timeout less than
2ms.

Change this code to use time_after instead of time_after_eq.

Signed-off-by: Dave Airlie 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

USB: Gadget: fix UTF conversion in the usbstring library

2009-05-20T05:20:07+00:00

commit 0f43158caddcbb110916212ebe4e39993ae70864 upstream.

This patch (as1234) fixes a bug in the UTF8 -> UTF-16 conversion
routine in the gadget/usbstring library.  In a UTF-8 multi-byte
sequence, all bytes after the first should have their high-order
two bits set to 10, not 11.

Signed-off-by: Alan Stern 
Acked-by: David Brownell 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

md: remove ability to explicit set an inactive array to 'clean'.

2009-05-20T05:20:07+00:00

commit 5bf295975416f8e97117bbbcfb0191c00bc3e2b4 upstream.

Being able to write 'clean' to an 'array_state' of an inactive array
to activate it in 'clean' mode is both unnecessary and inconvenient.

It is unnecessary because the same can be achieved by writing
'active'.  This activates and array, but it still remains 'clean'
until the first write.

It is inconvenient because writing 'clean' is more often used to
cause an 'active' array to revert to 'clean' mode (thus blocking
any writes until a 'write-pending' is promoted to 'active').

Allowing 'clean' to both activate an array and mark an active array as
clean can lead to races:  One program writes 'clean' to mark the
active array as clean at the same time as another program writes
'inactive' to deactivate (stop) and active array.  Depending on which
writes first, the array could be deactivated and immediately
reactivated which isn't what was desired.

So just disable the use of 'clean' to activate an array.

This avoids a race that can be triggered with mdadm-3.0 and external
metadata, so it suitable for -stable.

Reported-by: Rafal Marszewski 
Acked-by: Dan Williams 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md/raid10: don't clear bitmap during recovery if array will still be degraded.

2009-05-20T05:20:05+00:00

commit 18055569127253755d01733f6ecc004ed02f88d0 upstream.

If we have a raid10 with multiple missing devices, and we recover just
one of these to a spare, then we risk (depending on the bitmap and
array chunk size) clearing bits of the bitmap for which recovery isn't
complete (because a device is still missing).

This can lead to a subsequent "re-add" being recovered without
any IO happening, which would result in loss of data.

This patch takes the safe approach of not clearing bitmap bits
if the array will still be degraded.

This patch is suitable for all active -stable kernels.

Cc: stable@kernel.org
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

md: fix some (more) errors with bitmaps on devices larger than 2TB.

2009-05-20T05:20:05+00:00

commit db305e507d554430a69ede901a6308e6ecb72349 upstream.

If a write intent bitmap covers more than 2TB, we sometimes work with
values beyond 32bit, so these need to be sector_t.  This patches
add the required casts to some unsigned longs that are being shifted
up.

This will affect any raid10 larger than 2TB, or any raid1/4/5/6 with
member devices that are larger than 2TB.

Signed-off-by: NeilBrown 
Reported-by: "Mario 'BitKoenig' Holbe" 
Signed-off-by: Greg Kroah-Hartman

md: fix loading of out-of-date bitmap.

2009-05-20T05:20:05+00:00

commit b74fd2826c5acce20e6f691437b2d19372bc2057 upstream.

When md is loading a bitmap which it knows is out of date, it fills
each page with 1s and writes it back out again.  However the
write_page call makes used of bitmap->file_pages and
bitmap->last_page_size which haven't been set correctly yet.  So this
can sometimes fail.

Move the setting of file_pages and last_page_size to before the call
to write_page.

This bug can cause the assembly on an array to fail, thus making the
data inaccessible.  Hence I think it is a suitable candidate for
-stable.

Reported-by: Vojtech Pavlik 
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman