commit 62b218cb13724881b5314f10ac0f177f4fdef8b6 Author: Greg Kroah-Hartman Date: Thu Jun 23 15:06:00 2011 -0700 Linux 2.6.39.2 commit 890cd1ba9bba495fd7eb8e8cdfea0b016a34bfa6 Author: Stanislaw Gruszka Date: Wed Jun 8 15:26:31 2011 +0200 iwlegacy: fix channel switch locking commit 51e65257142a87fe46a1ce5c35c86c5baf012614 upstream. We use priv->mutex to avoid race conditions between chswitch_done() and mac_channel_switch(), when marking channel switch in progress. But chswitch_done() can be called in atomic context from rx_csa() or with mutex already taken from commit_rxon(). To fix remove mutex from chswitch_done() and use atomic bitops for marking channel switch pending. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 4d41d0d8666e0bb083224cf1cd49f1c9be55d467 Author: Stanislaw Gruszka Date: Thu Jun 2 18:17:15 2011 +0200 iwlagn: fix channel switch locking commit 6f213ff1919fab6f8244ceae55631b5d6ef750a7 upstream. We use priv->mutex to avoid race conditions between iwl_chswitch_done() and iwlagn_mac_channel_switch(), when marking channel switch in progress. But iwl_chswitch_done() can be called in atomic context from iwl_rx_csa() or with mutex already taken from iwlagn_commit_rxon(). These bugs were introduced by: commit 79d07325502e73508f917475bc1617b60979dd94 Author: Wey-Yi Guy Date: Thu May 6 08:54:11 2010 -0700 iwlwifi: support channel switch offload in driver To fix remove mutex from iwl_chswitch_done() and use atomic bitops for marking channel switch pending. Also remove iwl2030_hw_channel_switch() since 2000 series adapters are 2.4GHz only devices. Signed-off-by: Stanislaw Gruszka Acked-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit aa27055641f8f60c26e9f436b08350f9b339cd3a Author: Wey-Yi Guy Date: Fri May 27 08:40:24 2011 -0700 iwlagn: send tx power command if defer cause by RXON not match commit 43e4e0b94984b45d52048e3ac027cac15c718b65 upstream. During channge channel, tx power will not send to uCode, the tx power command should send after scan complete. but should also can send after RXON command. Stable fix identified by Stanislaw Gruszka . Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 2cd3e43e8db9d0ae1af443418547f65ee1efa280 Author: Namhyung Kim Date: Tue Jun 14 14:20:19 2011 +1000 md/raid5: fix FUA request handling in ops_run_io() commit b062962edb086011e94ec4d9eb3f6a6d814f2a8f upstream. Commit e9c7469bb4f5 ("md: implment REQ_FLUSH/FUA support") introduced R5_WantFUA flag and set rw to WRITE_FUA in that case. However remaining code still checks whether rw is exactly same as WRITE or not, so FUAed-write ends up with being treated as READ. Fix it. This bug has been present since 2.6.37 and the fix is suitable for any -stable kernel since then. It is not clear why this has not caused more problems. Cc: Tejun Heo Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit fbfa65f9e3eb26937a90f023a8fd4d181189c1ef Author: Namhyung Kim Date: Mon Jun 13 14:48:22 2011 +0900 md/raid5: fix raid5_set_bi_hw_segments commit 9b2dc8b665932a8e681a7ab3237f60475e75e161 upstream. The @bio->bi_phys_segments consists of active stripes count in the lower 16 bits and processed stripes count in the upper 16 bits. So logical-OR operator should be bitwise one. This bug has been present since 2.6.27 and the fix is suitable for any -stable kernel since then. Fortunately the bad code is only used on error paths and is relatively unlikely to be hit. Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 1d15c2e0b935bcc27fe802655058051f934adf1d Author: Namhyung Kim Date: Thu Jun 9 11:42:54 2011 +1000 md: check ->hot_remove_disk when removing disk commit 01393f3d5836b7d62e925e6f4658a7eb22b83a11 upstream. Check pers->hot_remove_disk instead of pers->hot_add_disk in slot_store() during disk removal. The linear personality only has ->hot_add_disk and no ->hot_remove_disk, so that removing disk in the array resulted to following kernel bug: $ sudo mdadm --create /dev/md0 --level=linear --raid-devices=4 /dev/loop[0-3] $ echo none | sudo tee /sys/block/md0/md/dev-loop2/slot BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD c9f5d067 PUD 8575a067 PMD 0 Oops: 0010 [#1] SMP CPU 2 Modules linked in: linear loop bridge stp llc kvm_intel kvm asus_atk0110 sr_mod cdrom sg Pid: 10450, comm: tee Not tainted 3.0.0-rc1-leonard+ #173 System manufacturer System Product Name/P5G41TD-M PRO RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff880085757df0 EFLAGS: 00010282 RAX: ffffffffa00168e0 RBX: ffff8800d1431800 RCX: 000000000000006e RDX: 0000000000000001 RSI: 0000000000000002 RDI: ffff88008543c000 RBP: ffff880085757e48 R08: 0000000000000002 R09: 000000000000000a R10: 0000000000000000 R11: ffff88008543c2e0 R12: 00000000ffffffff R13: ffff8800b4641000 R14: 0000000000000005 R15: 0000000000000000 FS: 00007fe8c9e05700(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 00000000b4502000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process tee (pid: 10450, threadinfo ffff880085756000, task ffff8800c9f08000) Stack: ffffffff8138496a ffff8800b4641000 ffff88008543c268 0000000000000000 ffff8800b4641000 ffff88008543c000 ffff8800d1431868 ffffffff81a78a90 ffff8800b4641000 ffff88008543c000 ffff8800d1431800 ffff880085757e98 Call Trace: [] ? slot_store+0xaa/0x265 [] rdev_attr_store+0x89/0xa8 [] sysfs_write_file+0x108/0x144 [] vfs_write+0xb1/0x10d [] ? trace_hardirqs_on_caller+0x111/0x135 [] sys_write+0x4d/0x77 [] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [< (null)>] (null) RSP CR2: 0000000000000000 ---[ end trace ba5fc64319a826fb ]--- Signed-off-by: Namhyung Kim Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 93b18ca021e7b38d26eb55bcb0d1ca4c9105f643 Author: Tetsuo Handa Date: Mon Jun 13 13:49:11 2011 +0900 TOMOYO: Fix oops in tomoyo_mount_acl(). commit 4e78c724d47e2342aa8fde61f6b8536f662f795f upstream. In tomoyo_mount_acl() since 2.6.36, kern_path() was called without checking dev_name != NULL. As a result, an unprivileged user can trigger oops by issuing mount(NULL, "/", "ext3", 0, NULL) request. Fix this by checking dev_name != NULL before calling kern_path(dev_name). Signed-off-by: Tetsuo Handa Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 89ae106c9a9c2747e11ae1bacd7f5a65207a9296 Author: Dave Jones Date: Sun Jun 12 16:35:28 2011 -0400 CPUFREQ: Remove cpufreq_stats sysfs entries on module unload. commit 13f067537f34456443f61c950cd6dc37d1d5f3ee upstream. cpufreq_stats leaves behind its sysfs entries, which causes a panic when something stumbled across them. (Discovered by unloading cpufreq_stats while powertop was loaded). Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman commit 28223659e8b6af5d7303849f64cc3e7a4003bcbc Author: Thomas Gleixner Date: Tue Jul 20 14:34:50 2010 +0200 x86: cpu-hotplug: Prevent softirq wakeup on wrong CPU commit fd8a7de177b6f56a0fc59ad211c197a7df06b1ad upstream. After a newly plugged CPU sets the cpu_online bit it enables interrupts and goes idle. The cpu which brought up the new cpu waits for the cpu_online bit and when it observes it, it sets the cpu_active bit for this cpu. The cpu_active bit is the relevant one for the scheduler to consider the cpu as a viable target. With forced threaded interrupt handlers which imply forced threaded softirqs we observed the following race: cpu 0 cpu 1 bringup(cpu1); set_cpu_online(smp_processor_id(), true); local_irq_enable(); while (!cpu_online(cpu1)); timer_interrupt() -> wake_up(softirq_thread_cpu1); -> enqueue_on(softirq_thread_cpu1, cpu0); ^^^^ cpu_notify(CPU_ONLINE, cpu1); -> sched_cpu_active(cpu1) -> set_cpu_active((cpu1, true); When an interrupt happens before the cpu_active bit is set by the cpu which brought up the newly onlined cpu, then the scheduler refuses to enqueue the woken thread which is bound to that newly onlined cpu on that newly onlined cpu due to the not yet set cpu_active bit and selects a fallback runqueue. Not really an expected and desirable behaviour. So far this has only been observed with forced hard/softirq threading, but in theory this could happen without forced threaded hard/softirqs as well. It's probably unobservable as it would take a massive interrupt storm on the newly onlined cpu which causes the softirq loop to wake up the softirq thread and an even longer delay of the cpu which waits for the cpu_online bit. Signed-off-by: Thomas Gleixner Reviewed-by: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 9441ac93bbff3c5759058f26999f26002d99e82b Author: Florian Fainelli Date: Mon Jun 6 10:15:49 2011 +0200 x86: devicetree: Add missing early_init_dt_setup_initrd_arch stub commit 977cb76d52e7aa040e18a84b29fe6fd80d79319b upstream. This patch fixes the following build failure: drivers/built-in.o: In function `early_init_dt_check_for_initrd': /home/florian/dev/kernel/x86/linux-2.6-x86/drivers/of/fdt.c:571: undefined reference to `early_init_dt_setup_initrd_arch' make: *** [.tmp_vmlinux1] Error 1 which happens as soon as we enable initrd support on a x86 devicetree platform such as Intel CE4100. Signed-off-by: Florian Fainelli Acked-by: Grant Likely Cc: Maxime Bizon Acked-by: Sebastian Andrzej Siewior Link: http://lkml.kernel.org/r/201106061015.50039.ffainelli@freebox.fr Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 007b2687279cc06356884433ee630c1663d8378b Author: Johannes Berg Date: Wed Jun 8 13:27:29 2011 +0200 mac80211: fix IBSS teardown race commit f3209bea110cade12e2b133da8b8499689cb0e2e upstream. Ignacy reports that sometimes after leaving an IBSS joining a new one didn't work because there still were stations on the list. He fixed it by flushing stations when attempting to join a new IBSS, but this shouldn't be happening in the first case. When I looked into it I saw a race condition in teardown that could cause stations to be added after flush, and thus cause this situation. Ignacy confirms that after applying my patch he hasn't seen this happen again. Reported-by: Ignacy Gawedzki Debugged-by: Ignacy Gawedzki Tested-by: Ignacy Gawedzki Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 50224eeecc2357b6287ed2dc81963b61d89f824d Author: Williams, Mitch A Date: Tue Jun 7 14:22:57 2011 -0700 igb: fix i350 SR-IOV failture commit 665c8c8ee405738375b679246b49342ce38ba056 upstream. When SR-IOV is enabled, i350 devices fail to pass traffic. This is due to the driver attempting to enable RSS on the PF device, which is not supported by the i350. When max_vfs is specified on an i350 adapter, set the number of RSS queues to 1. This issue affects 2.6.39 as well. Signed-off-by: Mitch Williams Tested-by: Jeff Pieper Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c0ada91b9e3d46f7584f5a5392baecd5b3add5a8 Author: Stanislaw Gruszka Date: Mon Jun 6 15:11:30 2011 +0200 iwl4965: set tx power after rxon_assoc commit 51892dbbd511911c0f965a36b431fc3e8f1e4f8a upstream. Setting tx power can be deferred during scan or changing channel. If after that correct tx power settings will not be sent to device, we can observe transmission problems and timeouts. Force to send tx power settings also after partial rxon change, to assure device always be configured with up-to-date settings. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=36492 Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit cb7520a5acacfdc38c56cbb568e177086c9901d1 Author: Stanislaw Gruszka Date: Thu May 26 17:14:22 2011 +0200 iwlagn: use cts-to-self protection on 5000 adapters series commit 42b70a5f6d18165a075d189d1bee82fad7cdbf29 upstream. This patch fixes 802.11n stability and performance regression we have since 2.6.35. It boost performance on my 5GHz N-only network from about 5MB/s to 8MB/s. Similar percentage boost can be observed on 2.4 GHz. These are test results of 5x downloading of approximately 700MB iso image: vanilla: 5.27 5.22 4.94 4.47 5.31 ; avr 5.0420 std 0.35110 patched: 8.07 7.95 8.06 7.99 7.96 ; avr 8.0060 std 0.055946 This was achieved with NetworkManager configured to do not perform periodical scans, by configuring constant BSSID. With periodical scans, after some time, performance downgrade to unpatched driver level, like in example below: patched: 7.40 7.61 4.28 4.37 4.80 avr 5.6920 std 1.6683 However patch still make better here, since similar test on unpatched driver make link disconnects with below messages after some time: wlan1: authenticate with 00:23:69:35:d1:3f (try 1) wlan1: authenticate with 00:23:69:35:d1:3f (try 2) wlan1: authenticate with 00:23:69:35:d1:3f (try 3) wlan1: authentication with 00:23:69:35:d1:3f timed out On 2.6.35 kernel patch helps against connection hangs with messages: iwlagn 0000:20:00.0: queue 10 stuck 3 time. Fw reload. iwlagn 0000:20:00.0: On demand firmware reload iwlagn 0000:20:00.0: Stopping AGG while state not ON or starting Signed-off-by: Stanislaw Gruszka Acked-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 6a523c78659129ea7c0c3c6be9c67cac6812b08f Author: Marek Olšák Date: Fri Jun 10 14:41:26 2011 +0000 drm/radeon/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit commit a27bb4b209dd6c327fa4e7185f2487f9508a58db upstream. To my knowledge, the limit is 16 on r300. (the docs don't say what the limit is) The lack of bounds checking can be abused to do all sorts of things (from bypassing parts of the CS checker to crashing the kernel). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36745 Signed-off-by: Marek Olšák Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 4164979de808ea1f11ee404f8e60227464620aeb Author: Robert Richter Date: Tue May 31 12:35:41 2011 +0200 oprofile, dcookies: Fix possible circular locking dependency commit fe47ae7f53e179d2ef6771024feb000cbb86640f upstream. The lockdep warning below detects a possible A->B/B->A locking dependency of mm->mmap_sem and dcookie_mutex. The order in sync_buffer() is mm->mmap_sem/dcookie_mutex, while in sys_lookup_dcookie() it is vice versa. Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before copy_to_user(). oprofiled/4432 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [] might_fault+0x53/0xa3 but task is already holding lock: (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (dcookie_mutex){+.+.+.}: [] lock_acquire+0xf8/0x11e [] mutex_lock_nested+0x63/0x309 [] get_dcookie+0x30/0x144 [] sync_buffer+0x196/0x3ec [oprofile] [] task_exit_notify+0x16/0x1a [oprofile] [] notifier_call_chain+0x37/0x63 [] __blocking_notifier_call_chain+0x50/0x67 [] blocking_notifier_call_chain+0x14/0x16 [] profile_task_exit+0x1a/0x1c [] do_exit+0x2a/0x6fc [] do_group_exit+0x83/0xae [] sys_exit_group+0x17/0x1b [] system_call_fastpath+0x16/0x1b -> #0 (&mm->mmap_sem){++++++}: [] __lock_acquire+0x1085/0x1711 [] lock_acquire+0xf8/0x11e [] might_fault+0x80/0xa3 [] sys_lookup_dcookie+0x104/0x149 [] system_call_fastpath+0x16/0x1b other info that might help us debug this: 1 lock held by oprofiled/4432: #0: (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149 stack backtrace: Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9 Call Trace: [] print_circular_bug+0xae/0xbc [] __lock_acquire+0x1085/0x1711 [] ? get_parent_ip+0x11/0x42 [] ? might_fault+0x53/0xa3 [] lock_acquire+0xf8/0x11e [] ? might_fault+0x53/0xa3 [] ? path_put+0x22/0x27 [] might_fault+0x80/0xa3 [] ? might_fault+0x53/0xa3 [] sys_lookup_dcookie+0x104/0x149 [] system_call_fastpath+0x16/0x1b References: https://bugzilla.kernel.org/show_bug.cgi?id=13809 Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit f79cee54477edb58f0eebdea6107eb33731361ab Author: Robert Richter Date: Thu May 26 18:39:35 2011 +0200 oprofile: Fix locking dependency in sync_start() commit 130c5ce716c9bfd1c2a2ec840a746eb7ff9ce1e6 upstream. This fixes the A->B/B->A locking dependency, see the warning below. The function task_exit_notify() is called with (task_exit_notifier) .rwsem set and then calls sync_buffer() which locks buffer_mutex. In sync_start() the buffer_mutex was set to prevent notifier functions to be started before sync_start() is finished. But when registering the notifier, (task_exit_notifier).rwsem is locked too, but now in different order than in sync_buffer(). In theory this causes a locking dependency, what does not occur in practice since task_exit_notify() is always called after the notifier is registered which means the lock is already released. However, after checking the notifier functions it turned out the buffer_mutex in sync_start() is unnecessary. This is because sync_buffer() may be called from the notifiers even if sync_start() did not finish yet, the buffers are already allocated but empty. No need to protect this with the mutex. So we fix this theoretical locking dependency by removing buffer_mutex in sync_start(). This is similar to the implementation before commit: 750d857 oprofile: fix crash when accessing freed task structs which introduced the locking dependency. Lockdep warning: oprofiled/4447 is trying to acquire lock: (buffer_mutex){+.+...}, at: [] sync_buffer+0x31/0x3ec [oprofile] but task is already holding lock: ((task_exit_notifier).rwsem){++++..}, at: [] __blocking_notifier_call_chain+0x39/0x67 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 ((task_exit_notifier).rwsem){++++..}: [] lock_acquire+0xf8/0x11e [] down_write+0x44/0x67 [] blocking_notifier_chain_register+0x52/0x8b [] profile_event_register+0x2d/0x2f [] sync_start+0x47/0xc6 [oprofile] [] oprofile_setup+0x60/0xa5 [oprofile] [] event_buffer_open+0x59/0x8c [oprofile] [] __dentry_open+0x1eb/0x308 [] nameidata_to_filp+0x60/0x67 [] do_last+0x5be/0x6b2 [] path_openat+0xc7/0x360 [] do_filp_open+0x3d/0x8c [] do_sys_open+0x110/0x1a9 [] sys_open+0x20/0x22 [] system_call_fastpath+0x16/0x1b -> #0 (buffer_mutex){+.+...}: [] __lock_acquire+0x1085/0x1711 [] lock_acquire+0xf8/0x11e [] mutex_lock_nested+0x63/0x309 [] sync_buffer+0x31/0x3ec [oprofile] [] task_exit_notify+0x16/0x1a [oprofile] [] notifier_call_chain+0x37/0x63 [] __blocking_notifier_call_chain+0x50/0x67 [] blocking_notifier_call_chain+0x14/0x16 [] profile_task_exit+0x1a/0x1c [] do_exit+0x2a/0x6fc [] do_group_exit+0x83/0xae [] sys_exit_group+0x17/0x1b [] system_call_fastpath+0x16/0x1b other info that might help us debug this: 1 lock held by oprofiled/4447: #0: ((task_exit_notifier).rwsem){++++..}, at: [] __blocking_notifier_call_chain+0x39/0x67 stack backtrace: Pid: 4447, comm: oprofiled Not tainted 2.6.39-00007-gcf4d8d4 #10 Call Trace: [] print_circular_bug+0xae/0xbc [] __lock_acquire+0x1085/0x1711 [] ? sync_buffer+0x31/0x3ec [oprofile] [] lock_acquire+0xf8/0x11e [] ? sync_buffer+0x31/0x3ec [oprofile] [] ? mark_lock+0x42f/0x552 [] ? sync_buffer+0x31/0x3ec [oprofile] [] mutex_lock_nested+0x63/0x309 [] ? sync_buffer+0x31/0x3ec [oprofile] [] sync_buffer+0x31/0x3ec [oprofile] [] ? __blocking_notifier_call_chain+0x39/0x67 [] ? __blocking_notifier_call_chain+0x39/0x67 [] task_exit_notify+0x16/0x1a [oprofile] [] notifier_call_chain+0x37/0x63 [] __blocking_notifier_call_chain+0x50/0x67 [] blocking_notifier_call_chain+0x14/0x16 [] profile_task_exit+0x1a/0x1c [] do_exit+0x2a/0x6fc [] ? retint_swapgs+0xe/0x13 [] do_group_exit+0x83/0xae [] sys_exit_group+0x17/0x1b [] system_call_fastpath+0x16/0x1b Reported-by: Marcin Slusarz Cc: Carl Love Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit 409dbd2f927fe65ffad9eb57253abded37ed1905 Author: Robert Richter Date: Thu May 26 18:22:54 2011 +0200 oprofile: Free potentially owned tasks in case of errors commit 6ac6519b93065625119a347be1cbcc1b89edb773 upstream. After registering the task free notifier we possibly have tasks in our dying_tasks list. Free them after unregistering the notifier in case of an error. Signed-off-by: Robert Richter Signed-off-by: Greg Kroah-Hartman commit f94e820b157193b5b518aa891f5f19da5c9ab395 Author: Daniel T Chen Date: Mon Jun 6 18:55:34 2011 -0400 ALSA: hda: Fix quirk for Dell Inspiron 910 commit 0a1896b27b030529ec770aefd790544a1bdb7d5a upstream. BugLink: https://launchpad.net/bugs/792712 The original reporter states that sound from the internal speakers is inaudible until using the model=auto quirk. This symptom is due to an existing quirk mask for 0x102802b* that uses the model=dell quirk. To limit the possible regressions, leave the existing quirk mask but add a higher priority specific mask for the reporter's PCI SSID. Reported-and-tested-by: rodni hipp Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 71ccce482d457ee108e02bb3b636b1bdbe4aa218 Author: Sangbeom Kim Date: Fri Jun 10 10:36:54 2011 +0900 ASoC: SAMSUNG: Fix the incorrect referencing of I2SCON register commit 33195500edf260e8c8809ab9dfc67f50e0ce031f upstream. If DMA active status should be checked, I2SCON register should be referenced. In this patch, Fix the incorrect referencing of I2SCON register. Reported-by : Lakkyung Jung Signed-off-by: Sangbeom Kim Acked-by: Jassi Brar Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a28f077aa8b13983837eaad2a3897891b9d511be Author: Lars-Peter Clausen Date: Thu Jun 9 13:22:36 2011 +0200 ASoC: snd_soc_new_{mixer,mux,pga} make sure to use right DAPM context commit 4b80b8c2eee5282dab57f094fd3893c0c09f750c upstream. Currently it is possible that snd_soc_new_{mixer,mux,pga} is called with a DAPM context not matching the widgets context. This can lead to a wrong prefix_len calculation, which will result in undefined behaviour. To avoid this always use the DAPM context from the widget itself. Signed-off-by: Lars-Peter Clausen Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ea0fd1f2712b03caa2f7a55ea7ff2fb062d43996 Author: Mark Brown Date: Wed Jun 8 18:07:49 2011 +0100 ASoC: WM8804 does not support sample rates below 32kHz commit 3115ae174620eeab4b16f52c8d0a9a35d2717e3c upstream. Reported-by: Kieran O'Leary Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman commit 67a07350f91e72a2fa3156128b6fd86a72b1ced2 Author: Mark Brown Date: Tue Jun 7 23:42:04 2011 +0100 ASoC: Fix WM8962 headphone volume update for use of advanced caches commit 0f82bdf572fc6e42147151aa4d52542f7fc6d793 upstream. Signed-off-by: Mark Brown Acked-by: Liam Girdwood Signed-off-by: Greg Kroah-Hartman commit 2df3e8e0679694d0e653b2ac2b6b4dfd5094b072 Author: Lars-Peter Clausen Date: Mon Jun 6 13:38:35 2011 +0200 ASoC: AD1836: Fix setting the PCM format commit 8ca695f273709a9d147826716a8dee3e0eb2407f upstream. Signed-off-by: Lars-Peter Clausen Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2b19835bf217dc2264e68706be3741e3e7fb5fdd Author: Jeff Layton Date: Fri Jun 10 16:14:57 2011 -0400 cifs: don't allow cifs_reconnect to exit with NULL socket pointer commit 7fdbaa1b8daa1009b705985b903e3d2ebccad456 upstream. It's possible for the following set of events to happen: cifsd calls cifs_reconnect which reconnects the socket. A userspace process then calls cifs_negotiate_protocol to handle the NEGOTIATE and gets a reply. But, while processing the reply, cifsd calls cifs_reconnect again. Eventually the GlobalMid_Lock is dropped and the reply from the earlier NEGOTIATE completes and the tcpStatus is set to CifsGood. cifs_reconnect then goes through and closes the socket and sets the pointer to zero, but because the status is now CifsGood, the new socket is not created and cifs_reconnect exits with the socket pointer set to NULL. Fix this by only setting the tcpStatus to CifsGood if the tcpStatus is CifsNeedNegotiate, and by making sure that generic_ip_connect is always called at least once in cifs_reconnect. Note that this is not a perfect fix for this issue. It's still possible that the NEGOTIATE reply is handled after the socket has been closed and reconnected. In that case, the socket state will look correct but it no NEGOTIATE was performed on it be for the wrong socket. In that situation though the server should just shut down the socket on the next attempted send, rather than causing the oops that occurs today. Reported-and-Tested-by: Ben Greear Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 83a9a8034ee98ac21804c376ec90af8e4997790e Author: John Johansen Date: Wed Jun 8 15:07:47 2011 -0700 AppArmor: Fix sleep in invalid context from task_setrlimit commit 1780f2d3839a0d3eb85ee014a708f9e2c8f8ba0e upstream. Affected kernels 2.6.36 - 3.0 AppArmor may do a GFP_KERNEL memory allocation with task_lock(tsk->group_leader); held when called from security_task_setrlimit. This will only occur when the task's current policy has been replaced, and the task's creds have not been updated before entering the LSM security_task_setrlimit() hook. BUG: sleeping function called from invalid context at mm/slub.c:847 in_atomic(): 1, irqs_disabled(): 0, pid: 1583, name: cupsd 2 locks held by cupsd/1583: #0: (tasklist_lock){.+.+.+}, at: [] do_prlimit+0x61/0x189 #1: (&(&p->alloc_lock)->rlock){+.+.+.}, at: [] do_prlimit+0x94/0x189 Pid: 1583, comm: cupsd Not tainted 3.0.0-rc2-git1 #7 Call Trace: [] __might_sleep+0x10d/0x112 [] slab_pre_alloc_hook.isra.49+0x2d/0x33 [] kmem_cache_alloc+0x22/0x132 [] prepare_creds+0x35/0xe4 [] aa_replace_current_profile+0x35/0xb2 [] aa_current_profile+0x45/0x4c [] apparmor_task_setrlimit+0x19/0x3a [] security_task_setrlimit+0x11/0x13 [] do_prlimit+0xd2/0x189 [] sys_setrlimit+0x3b/0x48 [] system_call_fastpath+0x16/0x1b Signed-off-by: John Johansen Reported-by: Miles Lane Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit a765227c18a65d95783442983e3653f2e339dc51 Author: Dmitry Torokhov Date: Tue May 31 14:37:23 2011 -0700 USB: xhci - fix interval calculation for FS isoc endpoints commit cd3c18ba2fac14b34d03cae111f215009735ea06 upstream. Full-speed isoc endpoints specify interval in exponent based form in frames, not microframes, so we need to adjust accordingly. NEC xHCI host controllers will return an error code of 0x11 if a full speed isochronous endpoint is added with the Interval field set to something less than 3 (2^3 = 8 microframes, or one frame). It is impossible for a full speed device to have an interval smaller than one frame. This was always an issue in the xHCI driver, but commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()" removed the clamping of the minimum value in the Interval field, which revealed this bug. This needs to be backported to stable kernels back to 2.6.31. Reported-by: Matt Evans Signed-off-by: Dmitry Torokhov Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 6f4e275454b31659f57ad6203fd912a08d8f0e9f Author: Sarah Sharp Date: Thu Jun 2 11:33:02 2011 -0700 xhci: Disable MSI for some Fresco Logic hosts. commit f5182b4155b9d686c5540a6822486400e34ddd98 upstream. Some Fresco Logic hosts, including those found in the AUAU N533V laptop, advertise MSI, but fail to actually generate MSI interrupts. Add a new xHCI quirk to skip MSI enabling for the Fresco Logic host controllers. Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device ID 0x1000, regardless of PCI revision ID, do not support MSI. This should be backported to stable kernels as far back as 2.6.36, which was the first kernel to support MSI on xHCI hosts. Signed-off-by: Sarah Sharp Reported-by: Sergey Galanov Signed-off-by: Greg Kroah-Hartman commit 604759f768090595b1ee6cb08371c7f9b0625a6f Author: Maarten Lankhorst Date: Wed Jun 1 23:27:50 2011 +0200 xhci: Do not issue device reset when device is not setup commit 001fd3826f4c736ce292315782d015f768399080 upstream. xHCI controllers respond to a Reset Device command when the Slot is in the Enabled/Disabled state by returning an error. This is fine on other host controllers, but the Etron xHCI host controller returns a vendor-specific error code that the xHCI driver doesn't understand. The xHCI driver then gives up on device enumeration. Instead of issuing a command that will fail, just return. This fixes the issue with the xhci driver not working on ASRock P67 Pro/Extreme boards. This should be backported to stable kernels as far back as 2.6.34. Signed-off-by: Maarten Lankhorst Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 91b0ce380e8ce633aa6803f62e70890774a42c53 Author: Maarten Lankhorst Date: Wed Jun 1 23:27:49 2011 +0200 xhci: Add defines for hardcoded slot states commit e2b0217715c6d10379d94bdfe5560af96eecbb7c upstream. This needs to be added to the stable trees back to 2.6.34 to support an upcoming bug fix. Signed-off-by: Maarten Lankhorst Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 4a2cb90c538f06c873a187aa743575d48685d7a6 Author: Greg Kroah-Hartman Date: Fri Jun 10 16:49:10 2011 -0700 Revert "x86, efi: Retain boot service code until after switching to virtual mode" This reverts commit 0aed459e8487eb6ebdb4efe8cefe1eafbc704b30, which was commit 916f676f8dc016103f983c7ec54c18ecdbb6e349 upstream. It breaks some people's machines, so this will all get worked out in the 3.0 kernel release, it's not quite ready for 2.6.39 just yet. Thanks to Maarten Lankhorst for reporting the issue. Cc: Maarten Lankhorst Cc: Jim Bos Cc: Matthew Garrett Cc: H. Peter Anvin Cc: Tony Luck Cc: Yinghai Lu Signed-off-by: Greg Kroah-Hartman commit f8c003f782fd913969aa44648fd382d998587533 Author: Alan Stern Date: Tue Jun 7 11:35:52 2011 -0400 usb-storage: redo incorrect reads commit 21c13a4f7bc185552c4b402b792c3bbb9aa69df0 upstream. Some USB mass-storage devices have bugs that cause them not to handle the first READ(10) command they receive correctly. The Corsair Padlock v2 returns completely bogus data for its first read (possibly it returns the data in encrypted form even though the device is supposed to be unlocked). The Feiya SD/SDHC card reader fails to complete the first READ(10) command after it is plugged in or after a new card is inserted, returning a status code that indicates it thinks the command was invalid, which prevents the kernel from retrying the read. Since the first read of a new device or a new medium is for the partition sector, the kernel is unable to retrieve the device's partition table. Users have to manually issue an "hdparm -z" or "blockdev --rereadpt" command before they can access the device. This patch (as1470) works around the problem. It adds a new quirk flag, US_FL_INVALID_READ10, indicating that the first READ(10) should always be retried immediately, as should any failing READ(10) commands (provided the preceding READ(10) command succeeded, to avoid getting stuck in a loop). The patch also adds appropriate unusual_devs entries containing the new flag. Signed-off-by: Alan Stern Tested-by: Sven Geggus Tested-by: Paul Hartman CC: Matthew Dharm Signed-off-by: Greg Kroah-Hartman commit 4506268880911c6c25128611d071405561094783 Author: Steffen Sledz Date: Tue Jun 7 14:01:56 2011 +0200 USB: serial: add another 4N-GALAXY.DE PID to ftdi_sio driver commit a26d31cef06f43a76327c21235e75450869df2b8 upstream. E.g. newer CAN 2.0 A/B <=> USB 2.0 converters report idProduct=f3c2. Signed-off-by: Steffen Sledz Signed-off-by: Greg Kroah-Hartman commit 3e94008b59acfad59d2e76e17750e91b476ea6e1 Author: Libor Pechacek Date: Fri May 20 14:53:25 2011 +0200 USB: core: Tolerate protocol stall during hub and port status read commit 3824c1ddaf744be44b170a335332b9d6afe79254 upstream. Protocol stall should not be fatal while reading port or hub status as it is transient state. Currently hub EP0 STALL during port status read results in failed device enumeration. This has been observed with ST-Ericsson (formerly Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard. Signed-off-by: Libor Pechacek Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman commit 4a4a0b34ef0e4bc65dc38bb5366397d19e3a08fc Author: Greg Kroah-Hartman Date: Tue Jun 7 15:03:37 2011 -0700 Revert "USB: option: add ID for ZTE MF 330" commit 3095ec895fd5ec19a7cb60b5cbfa766d68a74a24 upstream. This reverts commit a559d2c8c1bf652ea2d0ecd6ab4a250fcdb37db8. Turns out that device id 0x1d6b:0x0002 is a USB hub, which causes havoc when the option driver tries to bind to it. So revert this as it doesn't seem to be needed at all. Thanks to Michael Tokarev and Paweł Drobek for working on resolving this issue. Cc: Paweł Drobek Cc: Michael Tokarev Cc: Dominik Brodowski Signed-off-by: Greg Kroah-Hartman commit a33ebb8d3f369922763afbf744f7dad9ba6f7318 Author: Torsten Hilbrich Date: Mon Jun 6 15:39:55 2011 +0200 USB: option Add blacklist for ZTE K3765-Z (19d2:2002) commit 7e8e62e4a5d26e4cb45f25dddd093837d75616c2 upstream. The funtion option_send_status times out when sending USB messages to the interfaces 0, 1, and 2 of this UMTS stick. This results in a 5s timeout in the function causing other tty operations to feel very sluggish. This patch adds a blacklist entry for these 3 interfaces on the ZTE K3765-Z device. I was also able to reproduce the problem with v2.6.38 and v2.6.39. This is very similar to a problem fixed in commit 7a89e4cb9cdaba92f5fbc509945cf4e3c48db4e2 Author: Herton Ronaldo Krzesinski Date: Wed Mar 9 09:19:48 2011 +0000 USB: serial: option: Apply OPTION_BLACKLIST_SENDSETUP also for ZTE MF626 Signed-off-by: Torsten Hilbrich Signed-off-by: Greg Kroah-Hartman commit 5618dd5ab02b2fbd93e432954725bfe8c5ae6032 Author: Dan Williams Date: Mon Jun 6 16:55:41 2011 -0500 option: add Prolink PH300 modem IDs commit 5c3e4076ee8253c1e3688d10653ddee47a03b0db upstream. Simple ID addition. Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 546dfbd1cb8678d70d2bbacc1d7aaf5417cc12a4 Author: Dan Williams Date: Mon Jun 6 16:22:44 2011 -0500 option: add Alcatel X200 to sendsetup blacklist commit 15badbcc8eede58b0d7e53a3acde1c90a7b6e40e upstream. This modem really wants sendsetup blacklisted for interfaces 0 and 1, otherwise the kernel hardlocks for about 10 seconds while waiting for the modem's firmware to respond, which it of course doesn't do. A slight complication here is that TCT (who owns the Alcatel brand) used the same USB IDs for the X200 as the X060s despite the devices having completely different firmware and AT command sets, so we end up adding the X060s to the blacklist at the same time. PSA to OEMs: don't use the same USB IDs for different devices. Really. It makes your kittens cry. Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 54aa4fdee504e9ece39880032ea4331001802d8d Author: Dan Williams Date: Mon Jun 6 16:08:39 2011 -0500 option: add Zoom 4597 modem USB IDs commit cdacb598fe7ab85de80908c818dd7d66a2971117 upstream. Uses Longcheer-based firmware and AT command set. Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit c14276ca9b14f8a7f3b40bec3083c276754e012b Author: Mathias Krause Date: Thu Jun 9 20:05:18 2011 +0200 exec: delay address limit change until point of no return commit dac853ae89043f1b7752875300faf614de43c74b upstream. Unconditionally changing the address limit to USER_DS and not restoring it to its old value in the error path is wrong because it prevents us using kernel memory on repeated calls to this function. This, in fact, breaks the fallback of hard coded paths to the init program from being ever successful if the first candidate fails to load. With this patch applied switching to USER_DS is delayed until the point of no return is reached which makes it possible to have a multi-arch rootfs with one arch specific init binary for each of the (hard coded) probed paths. Since the address limit is already set to USER_DS when start_thread() will be invoked, this redundancy can be safely removed. Signed-off-by: Mathias Krause Cc: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 50091c12f224d7b767efd11478f6948812728c07 Author: Michael Chang Date: Mon May 30 14:28:25 2011 +0800 staging: gma500: get control from firmware framebuffer if conflicts commit aaa5c677910d313ca1318c905c799c459c6f0078 upstream. Many Linux distributions would enable vesafb in order to display early stage boot splash. In this case, we will get garbled X Window screen if running X fbdev on psbfb. This is because fb0 is occupied by vesafb while psbfb is on fb1. They tried to drive the same pieces of hardware at the same time. With unmodified X start-up, it would try to use default fb0 framebuffer device and unfortunately it is now broken becaues fb1 supersedes it. We should let psbfb takeover framebuffer control from vesafb to get around this problem. See also commit : 4410f3910947dcea8672280b3adecd53cec4e85e Signed-off-by: Michael Chang Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit b2577a0c1590467946eb245b76006a2369779a52 Author: Toby Gray Date: Mon Jun 6 14:52:48 2011 +0100 USB: cdc-acm: Adding second ACM channel support for Nokia E7 and C7 commit 4061fde2fa80f40cb27114f60500d38d0afcf350 upstream. This adds the Nokia E7 and C7 to the list of devices in cdc-acm, allowing the secondary ACM channel on the device to be exposed. Without this patch the ACM driver won't claim this secondary channel as it's marked as having a vendor-specific protocol. Signed-off-by: Toby Gray Signed-off-by: Greg Kroah-Hartman commit 17753081ca3a32851ef406ca076fcec20152a00c Author: Joerg Roedel Date: Mon Jun 6 16:50:14 2011 +0200 x86/amd-iommu: Fix boot crash with hidden PCI devices commit 26018874e3584f1658570d41d57d4c34f6a53aa0 upstream. Some PCIe cards ship with a PCI-PCIe bridge which is not visible as a PCI device in Linux. But the device-id of the bridge is present in the IOMMU tables which causes a boot crash in the IOMMU driver. This patch fixes by removing these cards from the IOMMU handling. This is a pure -stable fix, a real fix to handle this situation appriatly will follow for the next merge window. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit c79ad65e6c31da9955b0848fb0be15a6b95d7ef8 Author: Joerg Roedel Date: Mon Jun 6 16:04:02 2011 +0200 x86/amd-iommu: Fix 3 possible endless loops commit 0de66d5b35ee148455e268b2782873204ffdef4b upstream. The driver contains several loops counting on an u16 value where the exit-condition is checked against variables that can have values up to 0xffff. In this case the loops will never exit. This patch fixed 3 such loops. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit a4d37345244dea111a49dda25cc30b2ae7dab05c Author: Joerg Roedel Date: Mon May 30 15:56:24 2011 +0200 x86/amd-iommu: Use only per-device dma_ops commit 27c2127a15d340706c0aa84e311188a14468d841 upstream. Unfortunatly there are systems where the AMD IOMMU does not cover all devices. This breaks with the current driver as it initializes the global dma_ops variable. This patch limits the AMD IOMMU to the devices listed in the IVRS table fixing DMA for devices not covered by the IOMMU. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 69694054d5004619d095cdcd1346cf291068a84d Author: Laurent Pinchart Date: Mon May 30 15:45:47 2011 -0300 media: Fix media device minor registration commit 8c89ddd536bbe97c1e50424778a139abbf5763c3 upstream. The find_next_zero_bit() is called with the from and to arguments in the wrong order. This results in the function always returning 0, and all media devices being registered with minor 0. Furthermore, mdev->minor is then used before being assigned with the find_next_zero_bit() return value. This really makes sure we'll always use minor 0. Fix this and let the system support more than one media device. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e18e2fa510632dbbfcabc8f60c817f4a8576b11f Author: Jeff Layton Date: Mon Jun 6 15:40:23 2011 -0400 cifs: silence printk when establishing first session on socket commit 9c4843ea576107a3c1fb94f2f758f198e9fe9e54 upstream. When signing is enabled, the first session that's established on a socket will cause a printk like this to pop: CIFS VFS: Unexpected SMB signature This is because the key exchange hasn't happened yet, so the signature field is bogus. Don't try to check the signature on the socket until the first session has been established. Also, eliminate the specific check for SMB_COM_NEGOTIATE since this check covers that case too. Cc: Shirish Pargaonkar Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit da85f8e3be97d43ec727637c40e8b5d7a2731e34 Author: Linus Walleij Date: Tue May 31 18:14:39 2011 +0200 genirq: Fix descriptor init on non-sparse IRQs commit e7fbad300a7a6432238f086e3c9a61538a905858 upstream. The genirq changes are initializing descriptors for sparse IRQs quite differently from how non-sparse (stacked?) IRQs are initialized, with the effect that on my platform all IRQs are default-disabled on sparse IRQs and default-enabled if non-sparse IRQs are used, crashing some GPIO driver. Fix this by refactoring the non-sparse IRQs to use the same descriptor init function as the sparse IRQs. Signed-off: Linus Walleij Link: http://lkml.kernel.org/r/1306858479-16622-1-git-send-email-linus.walleij@stericsson.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit dec314e6cc29b2c5d19aa84c1267a1dd750451cf Author: Bruno Prémont Date: Tue May 24 19:59:17 2011 +0000 video: Fix use-after-free by vga16fb on rmmod commit a50d28de8d5085e0f34f96088a45cc156d022021 upstream. Since fb_info is now refcounted and thus may get freed at any time it gets unregistered module unloading will try to unregister framebuffer as stored in platform data on probe though this pointer may be stale. Cleanup platform data on framebuffer release. Signed-off-by: Bruno Prémont Signed-off-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 8f83b904ea7590794fc8ce490eaf57ac68955ee7 Author: Dan Carpenter Date: Fri Jun 3 07:45:28 2011 +0300 xen: off by one errors in multicalls.c commit f124c6ae59e193705c9ddac57684d50006d710e6 upstream. b->args[] has MC_ARGS elements, so the comparison here should be ">=" instead of ">". Otherwise we read past the end of the array one space. Signed-off-by: Dan Carpenter Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 36980edb6cde842b885c118f59a8e3c9d51d7869 Author: OGAWA Hirofumi Date: Tue May 31 19:38:07 2011 +0900 fat: Fix corrupt inode flags when remove ATTR_SYS flag commit 1adffbae22332bb558c2a29de19d9aca391869f6 upstream. We are clearly missing '~' in fat_ioctl_set_attributes(). Reported-by: Dmitry Dmitriev Signed-off-by: OGAWA Hirofumi Signed-off-by: Greg Kroah-Hartman commit 473e5a1d28fc1842fd9714a97d46af2c6b6fc1b0 Author: Daniel Haid Date: Wed Jun 8 20:04:45 2011 +1000 drm/radeon/kms: fix for radeon on systems >4GB without hardware iommu commit 62fff811d73095bd95579d72f558f03c78f7914a upstream. On my x86_64 system with >4GB of ram and swiotlb instead of a hardware iommu (because I have a VIA chipset), the call to pci_set_dma_mask (see below) with 40bits returns an error. But it seems that the radeon driver is designed to have need_dma32 = true exactly if pci_set_dma_mask is called with 32 bits and false if it is called with 40 bits. I have read somewhere that the default are 32 bits. So if the call fails I suppose that need_dma32 should be set to true. And indeed the patch fixes the problem I have had before and which I had described here: http://choon.net/forum/read.php?21,106131,115940 Acked-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit a9f1135fc0a404146e3147a921a19b7a312c5642 Author: Alex Deucher Date: Fri May 27 10:05:03 2011 -0400 drm/radeon/kms: viewport height has to be even commit adcfde516e10aad72d66f6fefd36e6d0e6bd7be7 upstream. Otherwise, no vblank interrupts. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37522 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 6cafca4977364cbc0dc0ecf985f72e52ef5bd808 Author: Hans de Goede Date: Sat Jun 4 15:39:21 2011 +0200 drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007 commit 6a574b5b9b186e28abd3e571dfd1700c5220b510 upstream. I found this while figuring out why gnome-shell would not run on my Asus EeeBox PC EB1007. As a standalone "pc" this device cleary does not have an internal panel, yet it claims it does. Add a quirk to fix this. Signed-off-by: Hans de Goede Reviewed-by: Keith Packard Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman commit e53108c524204a64f92030e7e983807b5d5f3fcd Author: Peter Zijlstra Date: Mon Jun 6 12:32:43 2011 +0200 lockdep: Fix lock_is_held() on recursion commit f2513cde93f0957d5dc6c09bc24b0cccd27d8e1d upstream. The main lock_is_held() user is lockdep_assert_held(), avoid false assertions in lockdep_off() sections by unconditionally reporting the lock is taken. [ the reason this is important is a lockdep_assert_held() in ttwu() which triggers a warning under lockdep_off() as in printk() which can trigger another wakeup and lock up due to spinlock recursion, as reported and heroically debugged by Arne Jansen ] Reported-and-tested-by: Arne Jansen Signed-off-by: Peter Zijlstra Cc: Linus Torvalds Link: http://lkml.kernel.org/r/1307398759.2497.966.camel@laptop Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7f7638a04e4229fec978f7055150be5f6cee7bd9 Author: Stefan Metzmacher Date: Wed Jun 1 02:01:41 2011 +0000 usbnet/cdc_ncm: add missing .reset_resume hook commit 85e3c65fa3a1d0542c181510a950a2be7733ff29 upstream. This avoids messages like this after suspend: cdc_ncm 2-1.4:1.6: no reset_resume for driver cdc_ncm? cdc_ncm 2-1.4:1.7: no reset_resume for driver cdc_ncm? cdc_ncm 2-1.4:1.6: usb0: unregister 'cdc_ncm' usb-0000:00:1d.0-1.4, CDC NCM This is important for the Ericsson F5521gw GSM/UMTS modem. Otherwise modemmanager looses the fact that the cdc_ncm and cdc_acm devices belong together. The cdc_ether module does the same. Signed-off-by: Stefan Metzmacher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 10f1c78901cbd8a181d47e978e0a2930e3d323a8 Author: Jens Axboe Date: Fri May 27 07:44:43 2011 +0200 block: export blk_{get,put}_queue() commit d86e0e83b32bc84600adb0b6ea1fce389b266682 upstream. We need them in SCSI to fix a bug, but currently they are not exported to modules. Export them. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8220b32e2fd53d8b6afb103237a99634139769eb Author: Luciano Coelho Date: Thu May 19 00:43:38 2011 +0300 nl80211: fix check for valid SSID size in scan operations commit 208c72f4fe44fe09577e7975ba0e7fa0278f3d03 upstream. In both trigger_scan and sched_scan operations, we were checking for the SSID length before assigning the value correctly. Since the memory was just kzalloc'ed, the check was always failing and SSID with over 32 characters were allowed to go through. This was causing a buffer overflow when copying the actual SSID to the proper place. This bug has been there since 2.6.29-rc4. Signed-off-by: Luciano Coelho Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1605e36ae2144c97685dcfa251e4de789c2a5c76 Author: Joe Perches Date: Tue Mar 29 15:21:32 2011 -0700 asus-wmi: Remove __init from asus_wmi_platform_init commit 39ddf3bf6463bc86041e806b43e014d50a144aa4 upstream. It's used by a non-init function. Signed-off-by: Joe Perches Signed-off-by: Matthew Garrett Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit 37978293453b3cfcf1d659ed6836b9f8de8ca0fa Author: Josh Boyer Date: Fri May 20 16:22:25 2011 -0400 powerpc: Fix 32-bit SMP build commit 6de06f313a65d0ecabf055e708d082002b568866 upstream. Commit 69e3cea8d5fd526 ("powerpc/smp: Make start_secondary_resume available to all CPU variants") introduced start_secondary_resume to misc_32.S, however it uses a 64-bit instruction which is not valid on 32-bit platforms. Use 'stw' instead. Reported-by: Richard Cochran Tested-by: Richard Cochran Signed-off-by: Josh Boyer Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a9c48a40ee2a8e5bf07515ec4cfcd349b8f0f8ad Author: Jordan_Hargrave@Dell.com Date: Mon May 9 15:24:55 2011 -0500 PCI: Set PCIE maxpayload for card during hotplug insertion commit e522a7126c7c144a1dd14c6f217ac31e71082b1d upstream. The following patch sets the MaxPayload setting to match the parent reading when inserting a PCIE card into a hotplug slot. On our system, the upstream bridge is set to 256, but when inserting a card, the card setting defaults to 128. As soon as I/O is performed to the card it starts receiving errors since the payload size is too small. Reviewed-by: Kenji Kaneshige Signed-off-by: Jordan Hargrave Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 66bff327ac7ed733f6c99e4ac65647b94441b608 Author: Jiri Slaby Date: Wed Mar 30 00:10:57 2011 +0200 serial: core, remove uart_update_termios commit 6f5c24ad0f7619502199185a026a228174a27e68 upstream. Now, uart_update_termios is empty, so it's time to remove it. We no longer need a live tty in .dtr_rts. So this should prune all the bugs where tty is zeroed in port->tty during tty_port_block_til_ready. There is one thing to note. We don't set ASYNC_NORMAL_ACTIVE now. It's because this is done already in tty_port_block_til_ready. Signed-off-by: Jiri Slaby Cc: Alan Cox Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 8d99e578d8688d146e37d6fa099e7e7d4b14ab21 Author: Jiri Slaby Date: Wed Mar 30 00:10:56 2011 +0200 serial: core, do not set DTR/RTS twice on startup commit 303a7a1199c20f7c9452f024a6e17bf348b6b398 upstream. In .dtr_rts we do: uart_set_mctrl(uport, TIOCM_DTR | TIOCM_RTS) and call uart_update_termios. It does: uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS) once again. As the only callsite of uart_update_termios is .dtr_rts, remove the uart_set_mctrl from uart_update_termios to not set it twice. Signed-off-by: Jiri Slaby Cc: Alan Cox Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit b218cdecace041cad6d46b1f5a4e57fb9976f598 Author: Jiri Slaby Date: Wed Mar 30 00:10:55 2011 +0200 serial: core, move termios handling to uart_startup commit c7d7abff40c27f82fe78b1091ab3fad69b2546f9 upstream. We should not fiddle with speed and cflags in .dtr_rts hook. Actually we might not have tty at that moment already. So move the console cflag copy and speed setup into uart_startup. Actually the speed setup is already there, but we need to call it unconditionally (uart_startup is called from uart_open with hw_init = 0). This means we move uart_change_speed before dtr/rts setup in .dtr_rts. But this should not matter as the setup should be called after uart_change_speed anyway. Before: After: dtr/rts setup (dtr_rts) uart_change_speed (startup) uart_change_speed (update_termios) dtr/rts setup (dtr_rts) dtr/rts setup (update_termios) dtr/rts setup (update_termios) The second setup will dismiss with the next patch. Signed-off-by: Jiri Slaby Cc: Alan Cox Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 2d9da2444b556ba2cfeaa2223f6247f5cc7b6803 Author: Hugh Dickins Date: Sun Jun 5 22:03:13 2011 -0700 mm: fix ENOSPC returned by handle_mm_fault() commit e0dcd8a05be438b3d2e49ef61441ea3a463663f8 upstream. Al Viro observes that in the hugetlb case, handle_mm_fault() may return a value of the kind ENOSPC when its caller is expecting a value of the kind VM_FAULT_SIGBUS: fix alloc_huge_page()'s failure returns. Signed-off-by: Hugh Dickins Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 097f0612d1769feab15f2bb6b346d7cfd24f1812 Author: Jussi Kivilinna Date: Mon May 30 10:15:47 2011 +0300 zd1211rw: fix to work on OHCI commit 59342f6a6bc35df623fb44784daa5e1077063b8f upstream. zd1211 devices register 'EP 4 OUT' endpoint as Interrupt type on USB 2.0: Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 However on USB 1.1 endpoint becomes Bulk: Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Commit 37939810b937aba830dd751291fcdc51cae1a6cb assumed that endpoint is always interrupt type and changed usb_bulk_msg() calls to usb_interrupt_msg(). Problem here is that usb_bulk_msg() on interrupt endpoint selfcorrects the call and changes requested pipe to interrupt type (see usb_bulk_msg). However with usb_interrupt_msg() on bulk endpoint does not correct the pipe type to bulk, but instead URB is submitted with interrupt type pipe. So pre-2.6.39 used usb_bulk_msg() and therefore worked with both endpoint types, however in 2.6.39 usb_interrupt_msg() with bulk endpoint causes ohci_hcd to fail submitted URB instantly with -ENOSPC and preventing zd1211rw from working with OHCI. Fix this by detecting endpoint type and using correct endpoint/pipe types for URB. Also fix asynchronous zd_usb_iowrite16v_async() to use right URB type on 'EP 4 OUT'. Signed-off-by: Jussi Kivilinna Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 99117bb2c3c260dceab0ff02c16c03b9e84c5ae8 Author: Stanislaw Gruszka Date: Wed Jun 1 17:17:57 2011 +0200 iwl4965: correctly validate temperature value commit dfe21582ac5ebc460dda98c67e8589dd506d02cd upstream. In some cases we can read wrong temperature value. If after that temperature value will not be updated to good one, we badly configure tx power parameters and device is unable to send a data. Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=35932 Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0db9466ed48263ab2951e89240b482912695c4a6 Author: Stanislaw Gruszka Date: Tue May 24 16:28:55 2011 +0200 iwl4965: fix 5GHz operation commit aac11c1b351413aa3412e258e2b2dcba31777209 upstream. rx_status.band is used uninitialized, what disallow to work on 5GHz . Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit dfa6c86d98fb51982aae3e89a7025c5136adcebe Author: Jean Delvare Date: Tue May 31 15:50:51 2011 -0400 hwmon: (coretemp) Relax target temperature range check commit 4c6e0f8101e62d8b2d01dc94b835a98b191a1454 upstream. The current temperature range check of MSR_IA32_TEMPERATURE_TARGET seems too strict to me, some TjMax values documented in Documentation/hwmon/coretemp wouldn't pass. Relax the check so that all the documented values pass. Signed-off-by: Jean Delvare Cc: Carsten Emde Cc: Fenghua Yu Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit a1a7093468df0a3704fcf6dbf0628dd83be223f9 Author: Guenter Roeck Date: Tue May 31 06:54:21 2011 -0700 hwmon: (coretemp) Fix TjMax detection for older CPUs commit 4f5f71a7abe329bdad81ee6a8e4545054a7cc30a upstream. Commit a321cedb12904114e2ba5041a3673ca24deb09c9 excludes CPU models 0xe, 0xf, 0x16, and 0x1a from TjMax temperature adjustment, even though several of those CPUs are known to have TiMax other than 100 degrees C, and even though the code in adjust_tjmax() explicitly handles those CPUs and points to a Web document listing several of the affected CPU IDs. Reinstate original TjMax adjustment if TjMax can not be determined using the IA32_TEMPERATURE_TARGET register. https://bugzilla.kernel.org/show_bug.cgi?id=32582 Signed-off-by: Guenter Roeck Cc: Huaxu Wan Cc: Carsten Emde Cc: Valdis Kletnieks Cc: Henrique de Moraes Holschuh Cc: Yong Wang Cc: Rudolf Marek Cc: Fenghua Yu Tested-by: Jean Delvare Acked-by: Jean Delvare Acked-by: Fenghua Yu Signed-off-by: Greg Kroah-Hartman commit 09babe131592377e75ccaf0bb276d481566d1f2b Author: Daniel Halperin Date: Tue May 31 11:59:30 2011 -0700 ath9k: fix two more bugs in tx power commit 21fdc87248d1d28492c775e05fa92b3c8c7bc8db upstream. This is the same fix as commit 841051602e3fa18ea468fe5a177aa92b6eb44b56 Author: Matteo Croce Date: Fri Dec 3 02:25:08 2010 +0100 The ath9k driver subtracts 3 dBm to the txpower as with two radios the signal power is doubled. The resulting value is assigned in an u16 which overflows and makes the card work at full power. in two more places. I grepped the ath tree and didn't find any others. Signed-off-by: Daniel Halperin Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 50735b7c8817711271b1c399b75014b0b0d68097 Author: Rajkumar Manoharan Date: Fri May 20 17:52:14 2011 +0530 ath9k: set 40 Mhz rate only if hw is configured in ht40 commit 41e2b05b9598d6bdf91fc20280bfc538d853f769 upstream. Whenever there is a channel width change from 40 Mhz to 20 Mhz, the hardware is reconfigured to ht20. Meantime before doing the rate control updation, the packets are being transmitted are selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH. While transmitting ht40 rate packets in ht20 mode is causing baseband panic with AR9003 based chips. ==== BB update: BB status=0x02001109 ==== ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2 src=0 ** ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 ** ath: ** BB mode: BB_gen_controls=0x000033c0 ** ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% ** ath: ==== BB update: done ==== Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 3493a689667e041c73be8bfd5144df1b480866e0 Author: Rajkumar Manoharan Date: Fri May 20 17:52:10 2011 +0530 ath9k: Reset chip on baseband hang commit a4d86d953b8593791cb29cf2acffd48f9ee6c4f9 upstream. Resetting hardware helps to recover from baseband hang/panic for AR9003 based chips. Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0769e21bf4b5cf48878c1ca819276e80465b39e7 Author: James Bottomley Date: Wed May 25 15:52:14 2011 -0500 Fix oops caused by queue refcounting failure commit e73e079bf128d68284efedeba1fbbc18d78610f9 upstream. In certain circumstances, we can get an oops from a torn down device. Most notably this is from CD roms trying to call scsi_ioctl. The root cause of the problem is the fact that after scsi_remove_device() has been called, the queue is fully torn down. This is actually wrong since the queue can be used until the sdev release function is called. Therefore, we add an extra reference to the queue which is released in sdev->release, so the queue always exists. Reported-by: Parag Warudkar Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit e0b1510e56c0f40a7d84a766a53521a268c41d75 Author: Namhyung Kim Date: Sat May 28 14:44:46 2011 +0200 nbd: limit module parameters to a sane value commit 3b2710824e00d238554c13b5add347e6c701ab1a upstream. The 'max_part' parameter controls the number of maximum partition a nbd device can have. However if a user specifies very large value it would exceed the limitation of device minor number and can cause a kernel oops (or, at least, produce invalid device nodes in some cases). In addition, specifying large 'nbds_max' value causes same problem for the same reason. On my desktop, following command results to the kernel bug: $ sudo modprobe nbd max_part=100000 kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/block/nbd4/range CPU 1 Modules linked in: nbd(+) bridge stp llc kvm_intel kvm asus_atk0110 sg sr_mod cdrom Pid: 2522, comm: modprobe Tainted: G W 2.6.39-leonard+ #159 System manufacturer System Product Name/P5G41TD-M PRO RIP: 0010:[] [] internal_create_group+0x2f/0x166 RSP: 0018:ffff8801009f1de8 EFLAGS: 00010246 RAX: 00000000ffffffef RBX: ffff880103920478 RCX: 00000000000a7bd3 RDX: ffffffff81a2dbe0 RSI: 0000000000000000 RDI: ffff880103920478 RBP: ffff8801009f1e38 R08: ffff880103920468 R09: ffff880103920478 R10: ffff8801009f1de8 R11: ffff88011eccbb68 R12: ffffffff81a2dbe0 R13: ffff880103920468 R14: 0000000000000000 R15: ffff880103920400 FS: 00007f3c49de9700(0000) GS:ffff88011f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f3b7fe7c000 CR3: 00000000cd58d000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 2522, threadinfo ffff8801009f0000, task ffff8801009a93a0) Stack: ffff8801009f1e58 ffffffff812e8f6e ffff8801009f1e58 ffffffff812e7a80 ffff880000000010 ffff880103920400 ffff8801002fd0c0 ffff880103920468 0000000000000011 ffff880103920400 ffff8801009f1e48 ffffffff8115ab6a Call Trace: [] ? device_add+0x4f1/0x5e4 [] ? dev_set_name+0x41/0x43 [] sysfs_create_group+0x13/0x15 [] blk_trace_init_sysfs+0x14/0x16 [] blk_register_queue+0x4c/0xfd [] add_disk+0xe4/0x29c [] nbd_init+0x2ab/0x30d [nbd] [] ? 0xffffffffa007dfff [] do_one_initcall+0x7f/0x13e [] sys_init_module+0xa1/0x1e3 [] system_call_fastpath+0x16/0x1b Code: 41 57 41 56 41 55 41 54 53 48 83 ec 28 0f 1f 44 00 00 48 89 fb 41 89 f6 49 89 d4 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe b9 ea ff ff ff 48 83 7f 30 00 0f 84 09 01 00 00 49 RIP [] internal_create_group+0x2f/0x166 RSP ---[ end trace 753285ffbf72c57c ]--- Signed-off-by: Namhyung Kim Cc: Laurent Vivier Cc: Paul Clements Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b7f788ce3f4ad895fe29cb225765c54f59a64d4d Author: Tejun Heo Date: Wed Jun 1 08:27:41 2011 +0200 block: blkdev_get() should access ->bd_disk only after success commit 4c49ff3fe128ca68dabd07537415c419ad7f82f9 upstream. d4dc210f69 (block: don't block events on excl write for non-optical devices) added dereferencing of bdev->bd_disk to test GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE; however, bdev->bd_disk can be %NULL if open failed which can lead to an oops. Test the flag after testing open was successful, not before. Signed-off-by: Tejun Heo Reported-by: David Miller Tested-by: David Miller Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 344bfe4456acedc5087677dd84b5a1aaa3137f8b Author: Artem Bityutskiy Date: Tue May 31 08:40:40 2011 +0300 UBIFS: fix memory leak on error path commit 812eb258311f89bcd664a34a620f249d54a2cd83 upstream. UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write failure because it forgets to free the 'struct ubifs_dent_node *dent' object. Although the object is small, the alignment can make it large - e.g., 2KiB if the min. I/O unit is 2KiB. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 103b2f0904c37b7dfe919489d268e5090a4a6a89 Author: Artem Bityutskiy Date: Tue May 31 07:03:21 2011 +0300 UBIFS: fix shrinker object count reports commit cf610bf4199770420629d3bc273494bd27ad6c1d upstream. Sometimes VM asks the shrinker to return amount of objects it can shrink, and we return the ubifs_clean_zn_cnt in that case. However, it is possible that this counter is negative for a short period of time, due to the way UBIFS TNC code updates it. And I can observe the following warnings sometimes: shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-8541616642706119788 This patch makes sure UBIFS never returns negative count of objects. Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit 646543453327a2b85083f4012d3bbeb5dabdabb8 Author: Chris Metcalf Date: Tue May 17 15:25:21 2011 -0400 arch/tile: allocate PCI IRQs later in boot commit f4de51de2edcd26ec77bfc71b1f00b1de5a5dc20 upstream. This change became required due to some recent reworking in the platform-independent IRQ code. It is required for 2.6.38 and later. Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman commit c39eaeb11a73c6f09d2042d55930c54e356fc1c1 Author: kerstin jonsson Date: Tue May 17 23:57:11 2011 +0000 powerpc/4xx: Fix regression in SMP on 476 commit c560bbceaf6b06e52f1ef20131b76a3fdc0a2c19 upstream. commit c56e58537d504706954a06570b4034c04e5b7500 breaks SMP support in PPC_47x chip. secondary_ti must be set to current thread info before callin kick_cpu or else start_secondary_47x will jump into void when trying to return to c-code. In the current setup secondary_ti is initialized before the CPU idle task is started and only the boot core will start. I am not sure this is the correct solution, but it makes SMP possible in my chip. Note! The HOTPLUG support probably need some fixing to, There is no trampoline code available in head_44x.S - start_secondary_resume? Signed-off-by: Kerstin Jonsson Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit f4f6cfc11c3481c36cc3c8cff15dd756ddf1748e Author: Mike Habeck Date: Sat May 28 13:15:07 2011 -0500 intel-iommu: Add domain check in domain_remove_one_dev_info commit 8519dc4401ddf8a5399f979870bbeeadbc111186 upstream. The comment in domain_remove_one_dev_info() states "No need to compare PCI domain; it has to be the same". But for the si_domain that isn't going to be true, as it consists of all the PCI devices that are identity mapped thus multiple PCI domains can be in si_domain. The code needs to validate the PCI domain too. Signed-off-by: Mike Habeck Signed-off-by: Mike Travis Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit b8f794de1463ab32ed90c97ad6edbcecd931abed Author: Mike Travis Date: Sat May 28 13:15:06 2011 -0500 intel-iommu: Remove Host Bridge devices from identity mapping commit 825507d6d059f1cbe2503e0e5a3926225b983aec upstream. When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge devices that do not use the IOMMU causes a kernel panic. Fix that by not inserting those devices into the si_domain. Signed-off-by: Mike Travis Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 80ebe0ace73cb376f66bdeeb92f4e7b5d4a3f8fb Author: Mike Travis Date: Sat May 28 13:15:05 2011 -0500 intel-iommu: Use coherent DMA mask when requested commit c681d0ba1252954208220ad32248a3e8e2fc98e4 upstream. The __intel_map_single function is not honoring the passed in DMA mask. This results in not using the coherent DMA mask when called from intel_alloc_coherent(). Signed-off-by: Mike Travis Acked-by: Chris Wright Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 87cc4d1e3e05af38c7c51323a3d86fe2572ab033 Author: Chris Wright Date: Sat May 28 13:15:04 2011 -0500 intel-iommu: Dont cache iova above 32bit commit 1c9fc3d11b84fbd0c4f4aa7855702c2a1f098ebb upstream. Mike Travis and Mike Habeck reported an issue where iova allocation would return a range that was larger than a device's dma mask. https://lkml.org/lkml/2011/3/29/423 The dmar initialization code will reserve all PCI MMIO regions and copy those reservations into a domain specific iova tree. It is possible for one of those regions to be above the dma mask of a device. It is typical to allocate iovas with a 32bit mask (despite device's dma mask possibly being larger) and cache the result until it exhausts the lower 32bit address space. Freeing the iova range that is >= the last iova in the lower 32bit range when there is still an iova above the 32bit range will corrupt the cached iova by pointing it to a region that is above 32bit. If that region is also larger than the device's dma mask, a subsequent allocation will return an unusable iova and cause dma failure. Simply don't cache an iova that is above the 32bit caching boundary. Reported-by: Mike Travis Reported-by: Mike Habeck Acked-by: Mike Travis Tested-by: Mike Habeck Signed-off-by: Chris Wright Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 3a2bc9ae5ee092a0db8aa07d695e15b14a3fe2a4 Author: Mike Travis Date: Sat May 28 13:15:03 2011 -0500 intel-iommu: Speed up processing of the identity_mapping function commit cb452a4040bb051d92e85d6e7eb60c11734c1781 upstream. When there are a large count of PCI devices, and the pass through option for iommu is set, much time is spent in the identity_mapping function hunting though the iommu domains to check if a specific device is "identity mapped". Speed up the function by checking the cached info to see if it's mapped to the static identity domain. Signed-off-by: Mike Travis Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 001a5287ce15ac855136d9912ba3a71e40befa0a Author: Chris Wright Date: Sat May 28 13:15:02 2011 -0500 intel-iommu: Check for identity mapping candidate using system dma mask commit 8fcc5372fbac085199d84a880503ed67aba3fe49 upstream. The identity mapping code appears to make the assumption that if the devices dma_mask is greater than 32bits the device can use identity mapping. But that is not true: take the case where we have a 40bit device in a 44bit architecture. The device can potentially receive a physical address that it will truncate and cause incorrect addresses to be used. Instead check to see if the device's dma_mask is large enough to address the system's dma_mask. Signed-off-by: Mike Travis Reviewed-by: Mike Habeck Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 26265892ce15ab6637959631b03d25528f817e76 Author: Alex Williamson Date: Tue May 24 12:19:04 2011 -0400 intel-iommu: Only unlink device domains from iommu commit 9b4554b21ed07e8556405510638171f0c787742a upstream. Commit a97590e5 added unlinking domains from iommus to reciprocate the iommu from domains unlinking that was already done. We actually want to only do this for device domains and never for the static identity map domain or VM domains. The SI domain is special and never freed, while VM domain->id lives in their own special address space, separate from iommu->domain_ids. In the current code, a VM can get domain->id zero, then mark that domain unused when unbound from pci-stub. This leads to DMAR write faults when the device is re-bound to the host driver. Signed-off-by: Alex Williamson Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit a58f19eeb2ed09582f482e9ecdc6438ee6a28f0a Author: Alex Williamson Date: Tue May 24 12:02:41 2011 +0100 intel-iommu: Flush unmaps at domain_exit commit 7b668357810ecb5fdda4418689d50f5d95aea6a8 upstream. We typically batch unmaps to be lazily flushed out at regular intervals. When we destroy a domain, we need to force a flush of these lazy unmaps to be sure none reference the domain we're about to free. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=35062 Signed-off-by: Alex Williamson Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman commit 3e8b966859c94b48e13e95c3f829743453451f72 Author: Rusty Russell Date: Mon May 30 11:14:08 2011 -0600 lguest: fix timer interrupt setup commit 15517f7c213442e4d8a098cf0732b237f764c576 upstream. Without an IRQ chip set, we now get a WARN_ON and no timer interrupt. This prevents booting. Fortunately, the fix is a one-liner: set up the timer IRQ like everything else. Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman