commit c823b666ed298bcabbccf7ca3e4063f26dcec19c Author: Greg Kroah-Hartman Date: Wed Oct 8 19:58:32 2008 -0700 Linux 2.6.25.18 commit 8c4d2d9f936a353f3336fd521341826a70e0a9fd Author: Herbert Xu Date: Mon Sep 15 11:48:46 2008 -0700 udp: Fix rcv socket locking [ Upstream commits d97106ea52aa57e63ff40d04479016836bbb5a4e and 93821778def10ec1e69aa3ac10adee975dad4ff3 ] The previous patch in response to the recursive locking on IPsec reception is broken as it tries to drop the BH socket lock while in user context. This patch fixes it by shrinking the section protected by the socket lock to sock_queue_rcv_skb only. The only reason we added the lock is for the accounting which happens in that function. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bb5168ca75d488ee10e4653ddbf4cd51a57707f3 Author: Vlad Yasevich Date: Thu Sep 18 16:28:27 2008 -0700 sctp: Fix oops when INIT-ACK indicates that peer doesn't support AUTH [ Upstream commit add52379dde2e5300e2d574b172e62c6cf43b3d3 ] If INIT-ACK is received with SupportedExtensions parameter which indicates that the peer does not support AUTH, the packet will be silently ignore, and sctp_process_init() do cleanup all of the transports in the association. When T1-Init timer is expires, OOPS happen while we try to choose a different init transport. The solution is to only clean up the non-active transports, i.e the ones that the peer added. However, that introduces a problem with sctp_connectx(), because we don't mark the proper state for the transports provided by the user. So, we'll simply mark user-provided transports as ACTIVE. That will allow INIT retransmissions to work properly in the sctp_connectx() context and prevent the crash. Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b18dfc326dd814b63abd0a484e3e300300065edc Author: Vlad Yasevich Date: Thu Sep 18 16:27:38 2008 -0700 sctp: do not enable peer features if we can't do them. [ Upstream commit 0ef46e285c062cbe35d60c0adbff96f530d31c86 ] Do not enable peer features like addip and auth, if they are administratively disabled localy. If the peer resports that he supports something that we don't, neither end can use it so enabling it is pointless. This solves a problem when talking to a peer that has auth and addip enabled while we do not. Found by Andrei Pelinescu-Onciul . Signed-off-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8d9f9fdc074522b022abfa500a25a072d5e13113 Author: Vegard Nossum Date: Thu Sep 11 19:05:29 2008 -0700 netlink: fix overrun in attribute iteration [ Upstream commit 1045b03e07d85f3545118510a587035536030c1c ] kmemcheck reported this: kmemcheck: Caught 16-bit read from uninitialized memory (f6c1ba30) 0500110001508abf050010000500000002017300140000006f72672e66726565 i i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u ^ Pid: 3462, comm: wpa_supplicant Not tainted (2.6.27-rc3-00054-g6397ab9-dirty #13) EIP: 0060:[] EFLAGS: 00010296 CPU: 0 EIP is at nla_parse+0x5a/0xf0 EAX: 00000008 EBX: fffffffd ECX: c06f16c0 EDX: 00000005 ESI: 00000010 EDI: f6c1ba30 EBP: f6367c6c ESP: c0a11e88 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: f781cc84 CR3: 3632f000 CR4: 000006d0 DR0: c0ead9bc DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff4ff0 DR7: 00000400 [] rtnl_setlink+0x63/0x130 [] rtnetlink_rcv_msg+0x165/0x200 [] netlink_rcv_skb+0x76/0xa0 [] rtnetlink_rcv+0x1e/0x30 [] netlink_unicast+0x281/0x290 [] netlink_sendmsg+0x1b9/0x2b0 [] sock_sendmsg+0xd2/0x100 [] sys_sendto+0xa5/0xd0 [] sys_send+0x36/0x40 [] sys_socketcall+0x1e6/0x2c0 [] sysenter_do_call+0x12/0x3f [] 0xffffffff This is the line in nla_ok(): /** * nla_ok - check if the netlink attribute fits into the remaining bytes * @nla: netlink attribute * @remaining: number of bytes remaining in attribute stream */ static inline int nla_ok(const struct nlattr *nla, int remaining) { return remaining >= sizeof(*nla) && nla->nla_len >= sizeof(*nla) && nla->nla_len <= remaining; } It turns out that remaining can become negative due to alignment in nla_next(). But GCC promotes "remaining" to unsigned in the test against sizeof(*nla) above. Therefore the test succeeds, and the nla_for_each_attr() may access memory outside the received buffer. A short example illustrating this point is here: #include main(void) { printf("%d\n", -1 >= sizeof(int)); } ...which prints "1". This patch adds a cast in front of the sizeof so that GCC will make a signed comparison and fix the illegal memory dereference. With the patch applied, there is no kmemcheck report. Signed-off-by: Vegard Nossum Acked-by: Thomas Graf Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e808212e98c4d8032c7bf88a0f122d58daff6621 Author: Santwona Behera Date: Fri Sep 12 16:04:26 2008 -0700 niu: panic on reset [ Upstream commit cff502a38394fd33693f6233e03fca363dfa956d ] The reset_task function in the niu driver does not reset the tx and rx buffers properly. This leads to panic on reset. This patch is a modified implementation of the previously posted fix. Signed-off-by: Santwona Behera Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4b37352ee6c6551bd8bea079219d352990b648ed Author: Neil Horman Date: Tue Sep 9 13:51:35 2008 -0700 ipv6: Fix OOPS in ip6_dst_lookup_tail(). [ Upstream commit e550dfb0c2c31b6363aa463a035fc9f8dcaa3c9b ] This fixes kernel bugzilla 11469: "TUN with 1024 neighbours: ip6_dst_lookup_tail NULL crash" dst->neighbour is not necessarily hooked up at this point in the processing path, so blindly dereferencing it is the wrong thing to do. This NULL check exists in other similar paths and this case was just an oversight. Also fix the completely wrong and confusing indentation here while we're at it. Based upon a patch by Evgeniy Polyakov. Signed-off-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dcd761a24946b6721ecf3d10f1889296cdf3d6e7 Author: Zachary Amsden Date: Wed Oct 1 16:45:04 2008 +0000 x86: Fix broken LDT access in VMI commit de59985e3a623d4d5d6207f1777398ca0606ab1c upstream After investigating a JRE failure, I found this bug was introduced a long time ago, and had already managed to survive another bugfix which occurred on the same line. The result is a total failure of the JRE due to LDT selectors not working properly. This one took a long time to rear up because LDT usage is not very common, but the bug is quite serious. It got introduced along with another bug, already fixed, by 75b8bb3e56ca09a467fbbe5229bc68627f7445be Signed-off-by: Zachary Amsden Cc: Ingo Molnar Cc: Glauber de Oliveira Costa Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3aafff5cf6ddd4f8cb6df0f9cf268446bbca80ce Author: Thomas Gleixner Date: Tue Sep 9 21:38:57 2008 +0200 clockevents: remove WARN_ON which was used to gather information commit 61c22c34c6f80a8e89cff5ff717627c54cc14fd4 upstream The issue of the endless reprogramming loop due to a too small min_delta_ns was fixed with the previous updates of the clock events code, but we had no information about the spread of this problem. I added a WARN_ON to get automated information via kerneloops.org and to get some direct reports, which allowed me to analyse the affected machines. The WARN_ON has served its purpose and would be annoying for a release kernel. Remove it and just keep the information about the increase of the min_delta_ns value. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 16ce8d264fc9ecb24e1a5e2351eb3fcc10ac322c Author: Maciej W. Rozycki Date: Fri Sep 5 14:05:31 2008 -0700 ntp: fix calculation of the next jiffie to trigger RTC sync commit 4ff4b9e19a80b73959ebeb28d1df40176686f0a8 upstream We have a bug in the calculation of the next jiffie to trigger the RTC synchronisation. The aim here is to run sync_cmos_clock() as close as possible to the middle of a second. Which means we want this function to be called less than or equal to half a jiffie away from when now.tv_nsec equals 5e8 (500000000). If this is not the case for a given call to the function, for this purpose instead of updating the RTC we calculate the offset in nanoseconds to the next point in time where now.tv_nsec will be equal 5e8. The calculated offset is then converted to jiffies as these are the unit used by the timer. Hovewer timespec_to_jiffies() used here uses a ceil()-type rounding mode, where the resulting value is rounded up. As a result the range of now.tv_nsec when the timer will trigger is from 5e8 to 5e8 + TICK_NSEC rather than the desired 5e8 - TICK_NSEC / 2 to 5e8 + TICK_NSEC / 2. As a result if for example sync_cmos_clock() happens to be called at the time when now.tv_nsec is between 5e8 + TICK_NSEC / 2 and 5e8 to 5e8 + TICK_NSEC, it will simply be rescheduled HZ jiffies later, falling in the same range of now.tv_nsec again. Similarly for cases offsetted by an integer multiple of TICK_NSEC. This change addresses the problem by subtracting TICK_NSEC / 2 from the nanosecond offset to the next point in time where now.tv_nsec will be equal 5e8, effectively shifting the following rounding in timespec_to_jiffies() so that it produces a rounded-to-nearest result. Signed-off-by: Maciej W. Rozycki Signed-off-by: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 22e4330618d27748cc69b62d3c96223bcefe6c6c Author: Thomas Gleixner Date: Sat Sep 6 03:06:08 2008 +0200 x86: HPET: read back compare register before reading counter commit 72d43d9bc9210d24d09202eaf219eac09e17b339 upstream After fixing the u32 thinko I sill had occasional hickups on ATI chipsets with small deltas. There seems to be a delay between writing the compare register and the transffer to the internal register which triggers the interrupt. Reading back the value makes sure, that it hit the internal match register befor we compare against the counter value. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 59ff733c6b6ef547bb09a9902020750dfbb2200f Author: Thomas Gleixner Date: Sat Sep 6 03:03:32 2008 +0200 x86: HPET fix moronic 32/64bit thinko commit f7676254f179eac6b5244a80195ec8ae0e9d4606 upstream We use the HPET only in 32bit mode because: 1) some HPETs are 32bit only 2) on i386 there is no way to read/write the HPET atomic 64bit wide The HPET code unification done by the "moron of the year" did not take into account that unsigned long is different on 32 and 64 bit. This thinko results in a possible endless loop in the clockevents code, when the return comparison fails due to the 64bit/332bit unawareness. unsigned long cnt = (u32) hpet_read() + delta can wrap over 32bit. but the final compare will fail and return -ETIME causing endless loops. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 9d29a18def727d9e0d5c656cfc86a278988b7926 Author: Thomas Gleixner Date: Sat Sep 6 03:01:45 2008 +0200 clockevents: broadcast fixup possible waiters commit 7300711e8c6824fcfbd42a126980ff50439d8dd0 upstream Until the C1E patches arrived there where no users of periodic broadcast before switching to oneshot mode. Now we need to trigger a possible waiter for a periodic broadcast when switching to oneshot mode. Otherwise we can starve them for ever. Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 4f8e2bf785bd7e5ba9b93a7d5ad5c18ba409a199 Author: Thomas Gleixner Date: Wed Sep 3 21:37:24 2008 +0000 HPET: make minimum reprogramming delta useful commit 7cfb0435330364f90f274a26ecdc5f47f738498c upstream The minimum reprogramming delta was hardcoded in HPET ticks, which is stupid as it does not work with faster running HPETs. The C1E idle patches made this prominent on AMD/RS690 chipsets, where the HPET runs with 25MHz. Set it to 5us which seems to be a reasonable value and fixes the problems on the bug reporters machines. We have a further sanity check now in the clock events, which increases the delta when it is not sufficient. Signed-off-by: Thomas Gleixner Tested-by: Luiz Fernando N. Capitulino Tested-by: Dmitry Nezhevenko Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 19ab6cbbf02a7d4ca81ef44cc856ce11870e202b Author: Thomas Gleixner Date: Wed Sep 3 21:37:14 2008 +0000 clockevents: prevent endless loop lockup commit 1fb9b7d29d8e85ba3196eaa7ab871bf76fc98d36 upstream The C1E/HPET bug reports on AMDX2/RS690 systems where tracked down to a too small value of the HPET minumum delta for programming an event. The clockevents code needs to enforce an interrupt event on the clock event device in some cases. The enforcement code was stupid and naive, as it just added the minimum delta to the current time and tried to reprogram the device. When the minimum delta is too small, then this loops forever. Add a sanity check. Allow reprogramming to fail 3 times, then print a warning and double the minimum delta value to make sure, that this does not happen again. Use the same function for both tick-oneshot and tick-broadcast code. Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ffa4da2a25bb4ac08f710ac99827baf48a8f8d57 Author: Thomas Gleixner Date: Wed Sep 3 21:37:08 2008 +0000 clockevents: prevent multiple init/shutdown commit 9c17bcda991000351cb2373f78be7e4b1c44caa3 upstream While chasing the C1E/HPET bugreports I went through the clock events code inch by inch and found that the broadcast device can be initialized and shutdown multiple times. Multiple shutdowns are not critical, but useless waste of time. Multiple initializations are simply broken. Another CPU might have the device in use already after the first initialization and the second init could just render it unusable again. Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit e73068458bf253c2e738cd55080c3a54c61037ef Author: Thomas Gleixner Date: Wed Sep 3 21:37:03 2008 +0000 clockevents: enforce reprogram in oneshot setup commit 7205656ab48da29a95d7f55e43a81db755d3cb3a upstream In tick_oneshot_setup we program the device to the given next_event, but we do not check the return value. We need to make sure that the device is programmed enforced so the interrupt handler engine starts working. Split out the reprogramming function from tick_program_event() and call it with the device, which was handed in to tick_setup_oneshot(). Set the force argument, so the devices is firing an interrupt. Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit fbbece349081a689d5687d9ebc769a847fdf423a Author: Thomas Gleixner Date: Wed Sep 3 21:36:57 2008 +0000 clockevents: prevent endless loop in periodic broadcast handler commit d4496b39559c6d43f83e4c08b899984f8b8089b5 upstream The reprogramming of the periodic broadcast handler was broken, when the first programming returned -ETIME. The clockevents code stores the new expiry value in the clock events device next_event field only when the programming time has not been elapsed yet. The loop in question calculates the new expiry value from the next_event value and therefor never increases. Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 6141266c43db890ada7df589358b8553de2e6322 Author: Venkatesh Pallipadi Date: Wed Sep 3 21:36:50 2008 +0000 clockevents: prevent clockevent event_handler ending up handler_noop commit 7c1e76897492d92b6a1c2d6892494d39ded9680c upstream There is a ordering related problem with clockevents code, due to which clockevents_register_device() called after tickless/highres switch will not work. The new clockevent ends up with clockevents_handle_noop as event handler, resulting in no timer activity. The problematic path seems to be * old device already has hrtimer_interrupt as the event_handler * new clockevent device registers with a higher rating * tick_check_new_device() is called * clockevents_exchange_device() gets called * old->event_handler is set to clockevents_handle_noop * tick_setup_device() is called for the new device * which sets new->event_handler using the old->event_handler which is noop. Change the ordering so that new device inherits the proper handler. This does not have any issue in normal case as most likely all the clockevent devices are setup before the highres switch. But, can potentially be affecting some corner case where HPET force detect happens after the highres switch. This was a problem with HPET in MSI mode code that we have been experimenting with. Signed-off-by: Venkatesh Pallipadi Signed-off-by: Shaohua Li Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit dc317ed0f9cb83f616b95ae6abdba44832c60f39 Author: Zhao Yakui Date: Tue Sep 23 13:38:13 2008 +0800 ACPI: Avoid bogus EC timeout when EC is in Polling mode commit 9d699ed92a459cb408e2577e8bbeabc8ec3989e1 upstream When EC is in Polling mode, OS will check the EC status continually by using the following source code: clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags); while (time_before(jiffies, delay)) { if (acpi_ec_check_status(ec, event)) return 0; msleep(1); } But msleep is realized by the function of schedule_timeout. At the same time although one process is already waken up by some events, it won't be scheduled immediately. So maybe there exists the following phenomena: a. The current jiffies is already after the predefined jiffies. But before timeout happens, OS has no chance to check the EC status again. b. If preemptible schedule is enabled, maybe preempt schedule will happen before checking loop. When the process is resumed again, maybe timeout already happens, which means that OS has no chance to check the EC status. In such case maybe EC status is already what OS expects when timeout happens. But OS has no chance to check the EC status and regards it as AE_TIME. So it will be more appropriate that OS will try to check the EC status again when timeout happens. If the EC status is what we expect, it won't be regarded as timeout. Only when the EC status is not what we expect, it will be regarded as timeout, which means that EC controller can't give a response in time. http://bugzilla.kernel.org/show_bug.cgi?id=9823 http://bugzilla.kernel.org/show_bug.cgi?id=11141 Signed-off-by: Zhao Yakui Signed-off-by: Zhang Rui Signed-off-by: Andi Kleen Signed-off-by: Greg Kroah-Hartman commit 80ad012478ee989402ac014aab956e4534acd498 Author: Ingo Molnar Date: Sat Aug 23 17:59:07 2008 +0200 rtc: fix deadlock commit 38c052f8cff1bd323ccfa968136a9556652ee420 upstream if get_rtc_time() is _ever_ called with IRQs off, we deadlock badly in it, waiting for jiffies to increment. So make the code more robust by doing an explicit mdelay(20). This solves a very hard to reproduce/debug hard lockup reported by Mikael Pettersson. Reported-by: Mikael Pettersson Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f54fd05032fea1808f5e76dc8a94cde40f5d9f01 Author: Chuck Ebbert Date: Wed Sep 24 19:26:04 2008 -0400 x86: add io delay quirk for Presario F700 commit e6a5652fd156a286faadbf7a4062b5354d4e346e upstream Manually adding "io_delay=0xed" fixes system lockups in ioapic mode on this machine. System Information Manufacturer: Hewlett-Packard Product Name: Presario F700 (KA695EA#ABF) Base Board Information Manufacturer: Quanta Product Name: 30D3 Reference: https://bugzilla.redhat.com/show_bug.cgi?id=459546 Signed-off-by: Chuck Ebbert Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 05ec0ff50561e9c295a4d1b64ca2d0d7d0227820 Author: Milan Broz Date: Wed Sep 3 19:41:12 2008 -0400 ACPI: Fix thermal shutdowns commit 9f497bcc695fb828da023d74ad3c966b1e58ad21 upstream ACPI: Fix thermal shutdowns Do not use unsigned int if there is test for negative number... See drivers/acpi/processor_perflib.c static unsigned int ignore_ppc = -1; ... if (event == CPUFREQ_START && ignore_ppc <= 0) { ignore_ppc = 0; ... Signed-off-by: Milan Broz Signed-off-by: Andi Kleen Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit ef1e78583cb3b184316f909c7cfe365c2fee2cd2 Author: Sven Wegener Date: Sun Sep 28 14:14:21 2008 +0200 i2c-dev: Return correct error code on class_create() failure In Linus' tree: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commit;h=e74783ec3cb981211689bd2cfd3248f8dc48ec01 We need to convert the error pointer from class_create(), else we'll return the successful return code from register_chrdev() on failure. Signed-off-by: Sven Wegener Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 24ac281c6c6ae8d1fe9752cb5647e6d140134a6f Author: Andrew Morton Date: Sat Sep 6 01:10:03 2008 +0000 drivers/mmc/card/block.c: fix refcount leak in mmc_block_open() commit 70bb08962ea9bd50797ae9f16b2493f5f7c65053 upstream mmc_block_open() increments md->usage although it returns with -EROFS when default mounting a MMC/SD card with write protect switch on. This reference counting bug prevents /dev/mmcblkX from being released on card removal, and situation worsen with reinsertion until the minor number range runs out. Reported-by: Acked-by: Pierre Ossman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c73c1f8872fdb4aad48e791667ec3d0c180802ce Author: Mike Rapoport Date: Wed Oct 1 10:39:24 2008 -0700 pxa2xx_spi: fix build breakage commit 20b918dc77b383e9779dafceee3f2198a6f7b0e5 upstream This patch fixes a build error in the pxa2xx-spi driver, introduced by commit 7e96445533ac3f4f7964646a202ff3620602fab4 ("pxa2xx_spi: dma bugfixes") CC drivers/spi/pxa2xx_spi.o drivers/spi/pxa2xx_spi.c: In function 'map_dma_buffers': drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary & drivers/spi/pxa2xx_spi.c:331: error: invalid operands to binary & drivers/spi/pxa2xx_spi.c: In function 'pump_transfers': drivers/spi/pxa2xx_spi.c:897: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'unsigned int' [dbrownell@users.sourceforge.net: fix warning too ] Signed-off-by: Mike Rapoport Acked-by: Eric Miao Signed-off-by: Andrew Morton Signed-off-by: David Brownell Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit fccc31912109db9ae905dadcb8c7e1faa8139557 Author: Ned Forrester Date: Sat Sep 13 22:05:54 2008 +0000 pxa2xx_spi: chipselect bugfixes commit 8423597d676615f3dd2d9ab36f59f147086b90b8 upstream Fixes several chipselect bugs in the pxa2xx_spi driver. These bugs are in all versions of this driver and prevent using it with chips like m25p16 flash. 1. The spi_transfer.cs_change flag is handled too early: before spi_transfer.delay_usecs applies, thus making the delay ineffective at holding chip select. 2. spi_transfer.delay_usecs is ignored on the last transfer of a message (likewise not holding chipselect long enough). 3. If spi_transfer.cs_change is set on the last transfer, the chip select is always disabled, instead of the intended meaning: optionally holding chip select enabled for the next message. Those first three bugs were fixed with a relocation of delays and chip select de-assertions. 4. If a message has the cs_change flag set on the last transfer, and had the chip select stayed enabled as requested (see 3, above), it would not have been disabled if the next message is for a different chip. Fixed by dropping chip select regardless of cs_change at end of a message, if there is no next message or if the next message is for a different chip. This patch should apply to all kernels back to and including 2.6.20; it was test patched against 2.6.20. An additional patch would be required for older kernels, but those versions are very buggy anyway. Signed-off-by: Ned Forrester Cc: Vernon Sauder Cc: Eric Miao Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 8ab089f0e6cfdb11f83e1c7cb05ca900bcb76244 Author: Ned Forrester Date: Sat Sep 13 22:05:47 2008 +0000 pxa2xx_spi: dma bugfixes commit 7e96445533ac3f4f7964646a202ff3620602fab4 upstream Fixes two DMA bugs in the pxa2xx_spi driver. The first bug is in all versions of this driver; the second was introduced in the 2.6.20 kernel, and prevents using the driver with chips like m25p16 flash (which can issue large DMA reads). 1. Zero length transfers are permitted for use to insert timing, but pxa2xx_spi.c will fail if this is requested in DMA mode. Fixed by using programmed I/O (PIO) mode for such transfers. 2. Transfers larger than 8191 are not permitted in DMA mode. A test for length rejects all large transfers regardless of DMA or PIO mode. Worked around by rejecting only large transfers with DMA mapped buffers, and forcing all other transfers larger than 8191 to use PIO mode. A rate limited warning is issued for DMA transfers forced to PIO mode. This patch should apply to all kernels back to and including 2.6.20; it was test patched against 2.6.20. An additional patch would be required for older kernels, but those versions are very buggy anyway. Signed-off-by: Ned Forrester Cc: Vernon Sauder Cc: Eric Miao Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3319a7b0218fe79b94c8038932f4febff71da0e3 Author: Geoff Levand Date: Tue Sep 23 22:05:34 2008 +0000 USB: fix hcd interrupt disabling commit 83a798207361cc26385187b2e71efa2b5d75de7f upstream Commit de85422b94ddb23c021126815ea49414047c13dc, 'USB: fix interrupt disabling for HCDs with shared interrupt handlers' changed usb_add_hcd() to strip IRQF_DISABLED from irqflags prior to calling request_irq() with the justification that such a removal was necessary for shared interrupts to work properly. Unfortunately, the change in that commit unconditionally removes the IRQF_DISABLED flag, causing problems on platforms that don't use a shared interrupt but require IRQF_DISABLED. This change adds a check for IRQF_SHARED prior to removing the IRQF_DISABLED flag. Fixes the PS3 system startup hang reported with recent Fedora and OpenSUSE kernels. Note that this problem is hidden when CONFIG_LOCKDEP=y (ps3_defconfig), as local_irq_enable_in_hardirq() is defined as a null statement for that config. Signed-off-by: Geoff Levand Cc: Alan Stern Cc: Stefan Becker Signed-off-by: Greg Kroah-Hartman