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

V4L/DVB (7475): Added support for Terratec Cinergy T USB XXS

2008-07-24T16:14:12+00:00

commit dc88807ed61ed0fc0d57bd80a92508b9de638f5d upstream.


Alexander Simon found out that the Terratec Cinergy T USB XXS is just a
clone of another DiB7070P-based device.

Signed-off-by: Patrick Boettcher 
Signed-off-by: Mauro Carvalho Chehab 
Cc: Ludwig Nussel 
Signed-off-by: Greg Kroah-Hartman

mmc: don't use DMA on newer ENE controllers

2008-07-24T16:14:11+00:00

commit bf5b1935d8e42b36a34645788eb261461fe07f2e upstream.

Even the newer ENE controllers have bugs in their DMA engine that make
it too dangerous to use. Disable it until someone has figured out under
which conditions it corrupts data.

This has caused problems at least once, and can be found as bug report
10925 in the kernel bugzilla.

Signed-off-by: Pierre Ossman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

pxamci: trivial fix of DMA alignment register bit clearing

2008-07-24T16:14:11+00:00

commit 4fe16897c59882420d66f2d503106653d026ed6c upstream

Signed-off-by: Karl Beldan 
Acked-by: Eric Miao 
Signed-off-by: Pierre Ossman 
Signed-off-by: Greg Kroah-Hartman

pxamci: fix byte aligned DMA transfers

2008-07-24T16:14:10+00:00

commit 97f8571e663c808ad2d01a396627235167291556 upstream

The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.

For performance reasons all scatter-gather addresses passed to
pxamci_request should be aligned on 8-byte boundaries, but if
this can't be guaranteed, byte aligned DMA transfers in the
have to be enabled in the controller to get correct behaviour.

Signed-off-by: Philipp Zabel 
Signed-off-by: Pierre Ossman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

SCSI: mptspi: fix oops in mptspi_dv_renegotiate_work()

2008-07-24T16:14:10+00:00

commit 081a5bcb39b455405d58f79bb3c9398a9d4477ed upstream

The problem here is that if the ioc faults too early in the bring up
sequence (as it usually does for an irq routing problem), ioc_reset gets
called before the scsi host is even allocated.  This causes an oops when
it later schedules a renegotiation.  Fix this by checking ioc->sh before
trying to renegotiate.

Cc: Eric Moore 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

drivers/char/pcmcia/ipwireless/hardware.c fix resource leak

2008-07-24T16:14:10+00:00

commit 43f77e91eadbc290eb76a08110a039c809dde6c9 upstream

Coverity CID: 2172 RESOURCE_LEAK

When pool_allocate() tries to enlarge a packet, if it can not allocate enough
memory, it returns NULL without first freeing the old packet.

This patch just frees the packet first.

Signed-off-by: Darren Jenkins 
Acked-by: Jiri Kosina 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

drivers/isdn/i4l/isdn_common.c fix small resource leak

2008-07-24T16:14:09+00:00

commit 4fc89e3911aa5357b55b85b60c4beaeb8a48a290 upstream

Coverity CID: 1356 RESOURCE_LEAK

I found a very old patch for this that was Acked but did not get applied
https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.html

There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when
copy_from_user() returns an un-copied data length (length != 0).  The below
patch should be a minimally invasive fix.

Signed-off-by: Darren Jenkins 
Acked-by: Karsten Keil 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fbdev: bugfix for multiprocess defio

2008-07-24T16:14:09+00:00

commit f31ad92f34913043cf008d6e479e92dfbaf02df1 upstream

This patch is a bugfix for how defio handles multiple processes manipulating
the same framebuffer.

Thanks to Bernard Blackham for identifying this bug.

It occurs when two applications mmap the same framebuffer and concurrently
write to the same page.  Normally, this doesn't occur since only a single
process mmaps the framebuffer.  The symptom of the bug is that the mapping
applications will hang.  The cause is that defio incorrectly tries to add the
same page twice to the pagelist.  The solution I have is to walk the pagelist
and check for a duplicate before adding.  Since I needed to walk the pagelist,
I now also keep the pagelist in sorted order.

Signed-off-by: Jaya Kumar 
Cc: Bernard Blackham 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

serial8250: sanity check nr_uarts on all paths.

2008-07-24T16:14:09+00:00

commit 05d81d2222beec7b63ac8c1c8cdb5bb4f82c2bad upstream

I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird
mysterious crash in sysfs.  After taking an in-depth look I realized that
CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of
the serial8250_ports array.

Ouch!!!

Don't let this happen to someone else.

Signed-off-by: Eric W. Biederman 
Acked-by: Alan Cox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ov7670: clean up ov7670_read semantics

2008-07-24T16:14:09+00:00

commit bca5c2c550f16d2dc2d21ffb7b4712bd0a7d32a9 upstream

Cortland Setlow pointed out a bug in ov7670.c where the result from
ov7670_read() was just being checked for !0, rather than <0.  This made me
realize that ov7670_read's semantics were rather confusing; it both fills
in 'value' with the result, and returns it.  This is goes against general
kernel convention; so rather than fixing callers, let's fix the function.

This makes ov7670_read return <0 in the case of an error, and 0 upon
success. Thus, code like:

res = ov7670_read(...);
if (!res)
	goto error;

.will work properly.

Signed-off-by: Cortland Setlow 
Signed-off-by: Andres Salomon 
Acked-by: Jonathan Corbet 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman