linux-toradex.git/drivers/char, branch v2.6.35.6

char: Mark /dev/zero and /dev/kmem as not capable of writeback

2010-09-27T00:18:24+00:00

commit 371d217ee1ff8b418b8f73fb2a34990f951ec2d4 upstream.

These devices don't do any writeback but their device inodes still can get
dirty so mark bdi appropriately so that bdi code does the right thing and files
inodes to lists of bdi carrying the device inodes.

Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

drm/i915,agp/intel: Add second set of PCI-IDs for B43

2010-09-27T00:18:23+00:00

commit 41a51428916ab04587bacee2dda61c4a0c4fc02f upstream.

There is a second revision of B43 (a desktop gen4 part) floating around,
functionally equivalent to the original B43, so simply add the new
PCI-IDs.

Bugzilla: https://bugs.freedesktop.org/show_bugs.cgi?id=30221
Signed-off-by: Chris Wilson 
Signed-off-by: Greg Kroah-Hartman

agp/intel: fix dma mask bits on sandybridge

2010-09-27T00:18:21+00:00

[This is backport patch from upstream 877fdacf.]

Signed-off-by: Zhenyu Wang 
Signed-off-by: Greg Kroah-Hartman

agp/intel: fix physical address mask bits for sandybridge

2010-09-27T00:18:21+00:00

[This is backport patch from upstream 8dfc2b14.]

Signed-off-by: Zhenyu Wang 
Signed-off-by: Greg Kroah-Hartman

intel_agp, drm/i915: Add all sandybridge graphics devices support

2010-09-27T00:18:21+00:00

New pci ids for all sandybridge graphics versions on desktop/mobile/server.

[This is backport patch from upstream commit 4fefe435 and 85540480.]

Signed-off-by: Zhenyu Wang 
Signed-off-by: Greg Kroah-Hartman

virtio: console: Fix poll blocking even though there is data to read

2010-09-27T00:18:20+00:00

commit 6df7aadcd9290807c464675098b5dd2dc9da5075 upstream.

I found this while working on a Linux agent for spice, the symptom I was
seeing was select blocking on the spice vdagent virtio serial port even
though there were messages queued up there.

virtio_console's port_fops_poll checks port->inbuf != NULL to determine
if read won't block. However if an application reads enough bytes from
inbuf through port_fops_read, to empty the current port->inbuf,
port->inbuf will be NULL even though there may be buffers left in the
virtqueue.

This causes poll() to block even though there is data to be read,
this patch fixes this by using will_read_block(port) instead of the
port->inbuf != NULL check.

Signed-off-By: Hans de Goede 
Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

virtio: console: Prevent userspace from submitting NULL buffers

2010-09-27T00:18:20+00:00

commit 65745422a898741ee0e7068ef06624ab06e8aefa upstream.

A userspace could submit a buffer with 0 length to be written to the
host.  Prevent such a situation.

This was not needed previously, but recent changes in the way write()
works exposed this condition to trigger a virtqueue event to the host,
causing a NULL buffer to be sent across.

Signed-off-by: Amit Shah 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

agp/intel: Promote warning about failure to setup flush to error.

2010-09-20T20:36:47+00:00

commit df51e7aa2cf204e3a65657a1d60b96cfda133e9b upstream.

Make sure we always detect when we fail to correctly allocate the Isoch
Flush Page and print an error to warn the user about the likely memory
corruption that will result in invalid rendering or worse.

Signed-off-by: Chris Wilson 
Signed-off-by: Greg Kroah-Hartman

drm/agp/i915: trim stolen space to 32M

2010-08-26T23:46:17+00:00

commit d1d6ca73ef548748e141747e7260798327d6a2c1 upstream.

Some BIOSes will claim a large chunk of stolen space.  Unless we
reclaim it, our aperture for remapping buffer objects will be
constrained.  So clamp the stolen space to 32M and ignore the rest.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15469 among others.

Adding the ignored stolen memory back into the general pool using the
memory hotplug code is left as an exercise for the reader.

Signed-off-by: Jesse Barnes 
Reviewed-by: Simon Farnsworth 
Tested-by: Artem S. Tashkinov 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman

Fix init ordering of /dev/console vs callers of modprobe

2010-08-26T23:46:04+00:00

commit 31d1d48e199e99077fb30f6fb9a793be7bec756f upstream.

Make /dev/console get initialised before any initialisation routine that
invokes modprobe because if modprobe fails, it's going to want to open
/dev/console, presumably to write an error message to.

The problem with that is that if the /dev/console driver is not yet
initialised, the chardev handler will call request_module() to invoke
modprobe, which will fail, because we never compile /dev/console as a
module.

This will lead to a modprobe loop, showing the following in the kernel
log:

	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1
	request_module: runaway loop modprobe char-major-5-1

This can happen, for example, when the built in md5 module can't find
the built in cryptomgr module (because the latter fails to initialise).
The md5 module comes before the call to tty_init(), presumably because
'crypto' comes before 'drivers' alphabetically.

Fix this by calling tty_init() from chrdev_init().

Signed-off-by: David Howells 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman