linux/drivers, branch v2.6.25.10

DRM: enable bus mastering on i915 at resume time

2008-07-03T03:46:15Z

commit ea7b44c8e6baa1a4507f05ba2c0009ac21c3fe0b upstream On 9xx chips, bus mastering needs to be enabled at resume time for much of the chip to function. With this patch, vblank interrupts will work as expected on resume, along with other chip functions. Fixes kernel bugzilla #10844. Signed-off-by: Jie Luo Signed-off-by: Jesse Barnes Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

IB/mthca: Clear ICM pages before handing to FW

2008-07-03T03:46:15Z

commit 87afd448b186c885d67a08b7417cd46253b6a9d6 upstream Current memfree FW has a bug which in some cases, assumes that ICM pages passed to it are cleared. This patch uses __GFP_ZERO to allocate all ICM pages passed to the FW. Once firmware with a fix is released, we can make the workaround conditional on firmware version. This fixes the bug reported by Arthur Kepner here: http://lists.openfabrics.org/pipermail/general/2008-May/050026.html [ Rewritten to be a one-liner using __GFP_ZERO instead of vmap()ing ICM memory and memset()ing it to 0. - Roland ] Signed-off-by: Eli Cohen Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman

TTY: fix for tty operations bugs

2008-07-03T03:46:14Z

This is fixed with the recent tty operations rewrite in mainline in a different way, this is a selective backport of the relevant portions to the -stable tree. Signed-off-by: Alan Cox Signed-off-by: Greg Kroah-Hartman

hwmon: (adt7473) Initialize max_duty_at_overheat before use

2008-06-24T21:08:31Z

commit ed4ec814e45ae8b1596aea0a29b92f6c3614acaa upstream data->max_duty_at_overheat is not updated in adt7473_update_device, so it might be used before it is initialized (if the user reads from sysfs file max_duty_at_crit before writing to it.) Signed-off-by: Jean Delvare Acked-by: Darrick J. Wong Signed-off-by: Mark M. Hoffman Signed-off-by: Greg Kroah-Hartman

hwmon: (lm85) Fix function RANGE_TO_REG()

2008-06-24T21:08:30Z

Function RANGE_TO_REG() is broken. For a requested range of 2000 (2 degrees C), it will return an index value of 15, i.e. 80.0 degrees C, instead of the expected index value of 0. All other values are handled properly, just 2000 isn't. The bug was introduced back in November 2004 by this patch: http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=1c28d80f1992240373099d863e4996cdd5d646d0 In Linus' kernel I decided to rewrite the whole function in a way which was more obviously correct. But for -stable let's just do the minimal fix. Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

watchdog: hpwdt: fix use of inline assembly

2008-06-24T21:08:30Z

commit 1f6ef2342972dc7fd623f360f84006e2304eb935 upstream The inline assembly in drivers/watchdog/hpwdt.c was incredibly broken, and included all the function prologue and epilogue stuff, even though it was itself then inside a C function where the compiler would add its own prologue and epilogue on top of it all. This then just _happened_ to work if you had exactly the right compiler version and exactly the right compiler flags, so that gcc just happened to not create any prologue at all (the gcc-generated epilogue wouldn't matter, since it would never be reached). But the more proper way to fix it is to simply not do this. Move the inline asm to the top level, with no surrounding function at all (the better alternative would be to remove the prologue and make it actually use proper description of the arguments to the inline asm, but that's a bigger change than the one I'm willing to make right now). Tested-by: S.Çağlar Onur Acked-by: Thomas Mingarelli Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

atl1: relax eeprom mac address error check

2008-06-24T21:08:28Z

upstream commit: 58c7821c4264a7ddd6f0c31c5caaf393b3897f10 The atl1 driver tries to determine the MAC address thusly: - If an EEPROM exists, read the MAC address from EEPROM and validate it. - If an EEPROM doesn't exist, try to read a MAC address from SPI flash. - If that fails, try to read a MAC address directly from the MAC Station Address register. - If that fails, assign a random MAC address provided by the kernel. We now have a report of a system fitted with an EEPROM containing all zeros where we expect the MAC address to be, and we currently handle this as an error condition. Turns out, on this system the BIOS writes a valid MAC address to the NIC's MAC Station Address register, but we never try to read it because we return an error when we find the all- zeros address in EEPROM. This patch relaxes the error check and continues looking for a MAC address even if it finds an illegal one in EEPROM. http://ubuntuforums.org/showthread.php?t=562617 [jacliburn@bellsouth.net: backport to 2.6.25.7] Signed-off-by: Radu Cristescu Signed-off-by: Jay Cliburn Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

SCSI: sr: fix corrupt CD data after media change and delay

2008-06-22T05:24:56Z

commit: d1daeabf0da5bfa1943272ce508e2ba785730bf0 upstream Reported-by: Geert Uytterhoeven If you delay 30s or more before mounting a CD after inserting it then the kernel has the wrong value for the CD size. http://marc.info/?t=121276133000001 The problem is in sr_test_unit_ready(): the function eats unit attentions without adjusting the sdev->changed status. This means that when the CD signals changed media via unit attention, we can ignore it. Fix by making sr_test_unit_ready() adjust the changed status. Reported-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman

ACPICA: Ignore ACPI table signature for Load() operator

2008-06-22T05:24:55Z

upstream bc45b1d39a925b56796bebf8a397a0491489d85c Without this patch booting with acpi_osi="!Windows 2006" is required for several machines to function properly with cpufreq due to failure to load a Vista specific table with a bad signature. Only "SSDT" is acceptable to the ACPI spec, but tables are seen with OEMx and null sigs. Therefore, signature validation is worthless. Apparently MS ACPI accepts such signatures, ACPICA must be compatible. http://bugzilla.kernel.org/show_bug.cgi?id=9919 http://bugzilla.kernel.org/show_bug.cgi?id=10383 http://bugzilla.kernel.org/show_bug.cgi?id=10454 https://bugzilla.novell.com/show_bug.cgi?id=396311 Signed-off-by: Bob Moore Signed-off-by: Lin Ming Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

scsi_host regression: fix scsi host leak

2008-06-22T05:24:55Z

The patch is upstream as commit 3ed7897242b7efe977f3a8d06d4e5a4ebe28b10e A different backport is necessary because of the class_device to device conversion post 2.6.25. commit 9c7701088a61cc0cf8a6e1c68d1e74e3cc2ee0b7 Author: Dave Young Date: Tue Jan 22 14:01:34 2008 +0800 scsi: use class iteration api Isn't a correct replacement for the original hand rolled host lookup. The problem is that class_find_child would get a reference to the host's class device which is never released. Since the host class device holds a reference to the host gendev, the host can never be freed. In 2.6.25 we started using class_find_device, and this function also gets a reference to the device, so we end up with an extra ref and the host will not get released. This patch adds a class_put_device to balance the class_find_device() get. I kept the scsi_host_get in scsi_host_lookup, because the target layer is using scsi_host_lookup and it looks like it needs the SHOST_DEL check. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman