linux/drivers/char, branch v2.6.37.6

virtio: console: Don't access vqs if device was unplugged

2011-03-14T21:17:31Z

commit d7a62cd0332115d4c7c4689abea0d889a30d8349 upstream. If a virtio-console device gets unplugged while a port is open, a subsequent close() call on the port accesses vqs to free up buffers. This can lead to a crash. The buffers are already freed up as a result of the call to unplug_ports() from virtcons_remove(). The fix is to simply not access vq information if port->portdev is NULL. Reported-by: juzhang Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Revert: tpm_tis: Use timeouts returned from TPM

2011-02-24T22:54:42Z

This is a revert of commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream which has been found to prevent suspend from working on a number of systems. Thanks to Jiri Slaby for tracing this down. Cc: Jiri Slaby Cc: Rafael Wysocki Cc: Stefan Berger Cc: Guillaume Chazarain Cc: Rajiv Andrade Signed-off-by: Greg Kroah-Hartman

agp: ensure GART has an address before enabling it

2011-02-17T23:15:20Z

commit a70b95c017e8b518e1e069853355e4e497453dbb upstream. Some BIOSs (eg. the AMI BIOS on the Asus P4P800 motherboard) don't initialise the GART address, and pcibios_assign_resources() can ignore it because it can be marked as a host bridge (see https://bugzilla.kernel.org/show_bug.cgi?id=24392#c5 for details). This was handled correctly up to 2.6.35, but the pci_enable_device() cleanup in 2.6.36 96576a9e1a0cdb8 ("agp: intel-agp: do not use PCI resources before pci_enable_device()") means that the kernel tries to enable the GART before assigning it an address; in such cases the GART overlaps with other device assignments and ends up being disabled. This patch fixes https://bugzilla.kernel.org/show_bug.cgi?id=24392 Note that I imagine efficeon-agp.c probably has the same problem, but I can't test that and I'd like to make sure this patch is suitable for -stable (since 2.6.36 and 2.6.37 are affected). Signed-off-by: Stephen Kitt Cc: Bjorn Helgaas Cc: Maciej Rutecki Cc: "Rafael J. Wysocki" Cc: Kulikov Vasiliy Cc: Florian Mickler Signed-off-by: Andrew Morton Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

tpm_tis: Use timeouts returned from TPM

2011-02-17T23:15:02Z

commit 9b29050f8f75916f974a2d231ae5d3cd59792296 upstream. The current TPM TIS driver in git discards the timeout values returned from the TPM. The check of the response packet needs to consider that the return_code field is 0 on success and the size of the expected packet is equivalent to the header size + u32 length indicator for the TPM_GetCapability() result + 3 timeout indicators of type u32. I am also adding a sysfs entry 'timeouts' showing the timeouts that are being used. Signed-off-by: Stefan Berger Tested-by: Guillaume Chazarain Signed-off-by: Rajiv Andrade Signed-off-by: Greg Kroah-Hartman

TPM: Long default timeout fix

2011-02-17T23:15:02Z

commit c4ff4b829ef9e6353c0b133b7adb564a68054979 upstream. If duration variable value is 0 at this point, it's because chip->vendor.duration wasn't filled by tpm_get_timeouts() yet. This patch sets then the lowest timeout just to give enough time for tpm_get_timeouts() to further succeed. This fix avoids long boot times in case another entity attempts to send commands to the TPM when the TPM isn't accessible. Signed-off-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

tpm: fix panic caused by "tpm: Autodetect itpm devices"

2011-02-17T23:15:00Z

commit e5cce6c13c25d9ac56955a3ae2fd562719848172 upstream. commit 3f0d3d016d89a5efb8b926d4707eb21fa13f3d27 adds a check for PNP device id to the common tpm_tis_init() function, which in some cases (force=1) will be called without the device being a member of a pnp_dev. Oopsing and panics ensue. Move the test up to before the call to tpm_tis_init(), since it just modifies a global variable anyway. Signed-off-by: Olof Johansson Acked-by: Rajiv Andrade Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

char/ipmi: fix OOPS caused by pnp_unregister_driver on unregistered driver

2011-02-17T23:14:49Z

commit d2478521afc20227658a10a8c5c2bf1a2aa615b3 upstream. This patch fixes an OOPS triggered when calling modprobe ipmi_si a second time after the first modprobe returned without finding any ipmi devices. This can happen if you reload the module after having the first module load fail. The driver was not deregistering from PNP in that case. Peter Huewe originally reported this patch and supplied a fix, I have a different patch based on Linus' suggestion that cleans things up a bit more. Cc: openipmi-developer@lists.sourceforge.net Reviewed-by: Peter Huewe Cc: Randy Dunlap Signed-off-by: Corey Minyard Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

virtio: console: Wake up outvq on host notifications

2011-02-17T23:14:31Z

commit 2770c5ea501be69989a7acf54ec4cb3554c47191 upstream. The outvq needs to be woken up on host notifications so that buffers consumed by the host can be reclaimed, outvq freed, and application writes may proceed again. The need for this is now finally noticed when I have qemu patches ready to use nonblocking IO and flow control. CC: Hans de Goede Signed-off-by: Amit Shah Signed-off-by: Rusty Russell Acked-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

RAMOOPS: Don't overflow over non-allocated regions

2010-12-28T19:12:32Z

The current code mis-calculates the ramoops header size, leading to an overflow over the next record at best, or over a non-allocated region at worst. Fix that calculation. Signed-off-by: Ahmed S. Darwish Acked-by: Marco Stornelli Cc: stable@kernel.org Signed-off-by: Linus Torvalds

agp/intel: Fix missed cached memory flags setting in i965_write_entry()

2010-12-14T11:29:23Z

This fixes regression from a6963596a13e62f8e65b1cf3403a330ff2db407c, that missed to set cached memory type in GTT entry. Signed-off-by: Zhenyu Wang Signed-off-by: Chris Wilson