linux/drivers, branch v2.6.32.12

r8169: clean up my printk uglyness

2010-04-26T14:41:38Z

commit 93f4d91d879acfcb0ba9c2725e3133fcff2dfd1e upstream. Fix formatting on r8169 printk Brandon Philips noted that I had a spacing issue in my printk for the last r8169 patch that made it quite ugly. Fix that up and add the PFX macro to it as well so it looks like the other r8169 printks Signed-off-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

mptspi: Fix for incorrect data underrun errata

2010-04-26T14:41:36Z

commit 9b53b39243cf23a0b68eaa16c37ce16eada69a46 upstream. Errata: Certain conditions on the scsi bus may casue the 53C1030 to incorrectly signal a SCSI_DATA_UNDERRUN to the host. Workaround 1: For an Errata on LSI53C1030 When the length of request data and transfer data are different with result of command (READ or VERIFY), DID_SOFT_ERROR is set. Workaround 2: For potential trouble on LSI53C1030. It is checked whether the length of request data is equal to the length of transfer and residual. MEDIUM_ERROR is set by incorrect data. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

mptctl : Remove printk which floods unnecessary messages to var/log/message

2010-04-26T14:41:36Z

commit e39e145dfb78d4e20d89139d2576306b4279c126 upstream. Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

IB/iser: Rewrite SG handling for RDMA logic

2010-04-26T14:41:36Z

commit c1ccaf2478f84c2665cf57f981db143aa582d646 upstream. After dma-mapping an SG list provided by the SCSI midlayer, iser has to make sure the mapped SG is "aligned for RDMA" in the sense that its possible to produce one mapping in the HCA IOMMU which represents the whole SG. Next, the mapped SG is formatted for registration with the HCA. This patch re-writes the logic that does the above, to make it clearer and simpler. It also fixes a bug in the being aligned for RDMA checks, where a "start" check wasn't done but rather only "end" check. [commit message in RH kernel tree: "Under heavy load, without the patch, the HCA can be programmed to write (corrupt) into pages/location which doesn't belong to the SG associated with the actual I/O and cause a kernel oops."] Signed-off-by: Alexander Nezhinsky Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

tpm: autoload tpm_tis based on system PnP IDs

2010-04-26T14:41:36Z

commit 31bde71c202722a76686c3cf69a254c8a912275a upstream. The tpm_tis driver already has a list of supported pnp_device_ids. This patch simply exports that list as a MODULE_DEVICE_TABLE() so that the module autoloader will discover and load the module at boottime. Signed-off-by: Matt Domsch Acked-by: Rajiv Andrade Signed-off-by: Andrew Morton Signed-off-by: James Morris Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

md: deal with merge_bvec_fn in component devices better.

2010-04-26T14:41:35Z

commit 627a2d3c29427637f4c5d31ccc7fcbd8d312cd71 upstream. If a component device has a merge_bvec_fn then as we never call it we must ensure we never need to. Currently this is done by setting max_sector to 1 PAGE, however this does not stop a bio being created with several sub-page iovecs that would violate the merge_bvec_fn. So instead set max_phys_segments to 1 and set the segment boundary to the same as a page boundary to ensure there is only ever one single-page segment of IO requested at a time. This can particularly be an issue when 'xen' is used as it is known to submit multiple small buffers in a single bio. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman

Input: wacom - switch mode upon system resume

2010-04-26T14:41:34Z

commit 014f61504af276ba9d9544d8a7401d8f8526eb73 upstream. When Wacom devices wake up from a sleep, the switch mode command (wacom_query_tablet_data) is needed before wacom_open is called. wacom_query_tablet_data should not be executed inside wacom_open since wacom_open is called more than once during probe. Reported-and-tested-by: Anton Anikin Signed-off-by: Ping Cheng Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Limit burst to 64 bits

2010-04-26T14:41:34Z

commit 2060c44576c79086ff24718878d7edaa7384a985 upstream. access_bit_width field is u8 in ACPICA, thus 256 value written to it becomes 0, causing divide by zero later. Proper fix would be to remove access_bit_width at all, just because we already have access_byte_width, which is access_bit_width / 8. Limit access width to 64 bit for now. https://bugzilla.kernel.org/show_bug.cgi?id=15749 fixes regression caused by the fix for: https://bugzilla.kernel.org/show_bug.cgi?id=14667 Signed-off-by: Alexey Starikovskiy Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Allow multibyte access to EC

2010-04-26T14:41:34Z

commit dadf28a10c3eb29421837a2e413ab869ebd upstream http://bugzilla.kernel.org/show_bug.cgi?id=14667 [bwh: Backport to 2.6.32; same applies to 2.6.33] Signed-off-by: Alexey Starikovskiy Signed-off-by: Len Brown Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

r8169: offical fix for CVE-2009-4537 (overlength frame DMAs)

2010-04-26T14:41:34Z

commit c0cd884af045338476b8e69a61fceb3f34ff22f1 upstream. Official patch to fix the r8169 frame length check error. Based on this initial thread: http://marc.info/?l=linux-netdev&m=126202972828626&w=1 This is the official patch to fix the frame length problems in the r8169 driver. As noted in the previous thread, while this patch incurs a performance hit on the driver, its possible to improve performance dynamically by updating the mtu and rx_copybreak values at runtime to return performance to what it was for those NICS which are unaffected by the ideosyncracy (if there are any). Summary: A while back Eric submitted a patch for r8169 in which the proper allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too much data. This was done in commit fdd7b4c3302c93f6833e338903ea77245eb510b4. A long time prior to that however, Francois posted 126fa4b9ca5d9d7cb7d46f779ad3bd3631ca387c, which expiclitly disabled the MaxSize setting due to the fact that the hardware behaved in odd ways when overlong frames were received on NIC's supported by this driver. This was mentioned in a security conference recently: http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html It seems that if we can't enable frame size filtering, then, as Eric correctly noticed, we can find ourselves DMA-ing too much data to a buffer, causing corruption. As a result is seems that we are forced to allocate a frame which is ready to handle a maximally sized receive. This obviously has performance issues with it, so to mitigate that issue, this patch does two things: 1) Raises the copybreak value to the frame allocation size, which should force appropriately sized packets to get allocated on rx, rather than a full new 16k buffer. 2) This patch only disables frame filtering initially (i.e., during the NIC open), changing the MTU results in ring buffer allocation of a size in relation to the new mtu (along with a warning indicating that this is dangerous). Because of item (2), individuals who can't cope with the performance hit (or can otherwise filter frames to prevent the bug), or who have hardware they are sure is unaffected by this issue, can manually lower the copybreak and reset the mtu such that performance is restored easily. Signed-off-by: Neil Horman Signed-off-by: David S. Miller Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman