linux-stable.git/drivers/char, branch linux-2.6.36.y

agp: ensure GART has an address before enabling it

2011-02-17T22:47:31+00:00

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: Autodetect itpm devices

2011-02-17T22:47:27+00:00

commit 3f0d3d016d89a5efb8b926d4707eb21fa13f3d27 upstream.

Some Lenovos have TPMs that require a quirk to function correctly. This can
be autodetected by checking whether the device has a _HID of INTC0102. This
is an invalid PNPid, and as such is discarded by the pnp layer - however
it's still present in the ACPI code, so we can pull it out that way. This
means that the quirk won't be automatically applied on non-ACPI systems,
but without ACPI we don't have any way to identify the chip anyway so I
don't think that's a great concern.

Signed-off-by: Matthew Garrett 
Acked-by: Rajiv Andrade 
Tested-by: Jiri Kosina 
Tested-by: Andy Isaacson 
Signed-off-by: James Morris 
Signed-off-by: Greg Kroah-Hartman

tpm_tis: Use timeouts returned from TPM

2011-02-17T22:47:26+00:00

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-17T22:47:25+00:00

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

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

2011-02-17T22:47:22+00:00

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-17T22:47:13+00:00

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

2011-01-07T21:58:42+00:00

commit 1873bb8115e678ad9fd0aac9dbbc68383bc36e06 upstream.

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 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

n_gsm: gsm_data_alloc buffer allocation could fail and it is not being checked

2011-01-07T21:58:37+00:00

commit 093d804611b9a38fe59753b37c29f840518406a9 upstream.

gsm_data_alloc buffer allocation could fail and it is not being checked.

Add check for allocated buffer and return if the buffer allocation
fails.

Signed-off-by: Ken Mills 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

n_gsm: Fix message length handling when building header

2011-01-07T21:58:37+00:00

commit be7a7411d63ccad165d66fe8e0b11b2ee336159b upstream.

Fix message length handling when building header

When the message length is greater than 127, the length field in the header
is built incorrectly. According to the spec, when the length is less than 128
the length field is a single byte formatted as: bbbbbbb1. When it is greater
than 127 then the field is two bytes of the format: bbbbbbb0 bbbbbbbb.

Signed-off-by: Ken Mills 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

intel-gtt: fix gtt_total_entries detection

2010-12-09T21:32:58+00:00

commit e5e408fc94595aab897f613b6f4e2f5b36870a6f upstream.

In commit f1befe71 Chris Wilson added some code to clear the full gtt
on g33/pineview instead of just the mappable part. The code looks like
it was copy-pasted from agp/intel-gtt.c, at least an identical piece
of code is still there (in intel_i830_init_gtt_entries). This lead to
a regression in 2.6.35 which was supposedly fixed in commit e7b96f28

Now this commit makes absolutely no sense to me. It seems to be
slightly confused about chipset generations - it references docs for
4th gen but the regression concerns 3rd gen g33. Luckily the the g33
gmch docs are available with the GMCH Graphics Control pci config
register definitions. The other (bigger problem) is that the new
check in there uses the i830 stolen mem bits (.5M, 1M or 8M of stolen
mem). They are different since the i855GM.

The most likely case is that it hits the 512M fallback, which was
probably the right thing for the boxes this was tested on.

So the original approach by Chris Wilson seems to be wrong and the
current code is definitely wrong. There is a third approach by Jesse
Barnes from his RFC patch "Who wants a bigger GTT mapping range?"
where he simply shoves g33 in the same clause like later chipset
generations.

I've asked him and Jesse confirmed that this should work. So implement
it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16891$
Tested-by: Anisse Astier 
Signed-off-by: Anisse Astier 
Signed-off-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Signed-off-by: Greg Kroah-Hartman