commit c26f60b69ab33168db3b6b1ca383c39d5f6452b3 Author: Greg Kroah-Hartman Date: Wed Dec 21 13:00:46 2011 -0800 Linux 3.1.6 commit 8aabd0f9fbe5f4639c9ebe96054d660f2ef574ab Author: Bjørn Mork Date: Tue Dec 13 05:33:02 2011 +0100 USB: option: Removing one bogus and adding some new Huawei combinations commit 02a551c9755b799579e0a093bcc99b80b4dc1453 upstream. Huawei use the product code HUAWEI_PRODUCT_E353 (0x1506) for a number of different devices, which each can appear with a number of different descriptor sets. Different types of interfaces can be identified by looking at the subclass and protocol fields Subclass 1 protocol 8 is actually the data interface of a CDC ECM set, with subclass 1 protocol 9 as the control interface. Neither support serial data communcation, and cannot therefore be supported by this driver. At the same time, add a few other sets which appear if the device is configured in "Windows mode" using this modeswitch message: 55534243000000000000000000000011060000000100000000000000000000 Signed-off-by: Bjørn Mork Cc: stable Signed-off-by: Greg Kroah-Hartman commit 37e5dade10e1a58c74262a51c0ade9fb3227c196 Author: Alex Hermann Date: Mon Dec 12 21:42:23 2011 +0100 usb: option: Add Huawei E398 controlling interfaces commit 414b591fd16655871e9f5592a55368b10a3ccc30 upstream. This patch adds the controlling interfaces for the Huawei E398. Thanks to Bjørn Mork for extracting the interface numbers from the windows driver. Signed-off-by: Alex Hermann Signed-off-by: Greg Kroah-Hartman commit 7d965526535d46003108ca518a2287a28cc27bab Author: Krzysztof Hałasa Date: Mon Dec 12 14:51:00 2011 +0100 USB: cdc-acm: add IDs for Motorola H24 HSPA USB module. commit 6abff5dc4d5a2c90e597137ce8987e7fd439259b upstream. Add USB IDs for Motorola H24 HSPA USB module. Signed-off-by: Krzysztof Hałasa Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 6aa53a149539376d91688d30ede2aa6c7970d2e2 Author: Yinghai Lu Date: Mon Dec 12 12:39:14 2011 -0800 ibft: Fix finding IBFT ACPI table on UEFI commit 935a9fee51c945b8942be2d7b4bae069167b4886 upstream. Found one system with UEFI/iBFT, kernel does not detect the iBFT during iscsi_ibft module loading. Root cause: on x86 (UEFI), we are calling of find_ibft_region() much earlier - specifically in setup_arch() before ACPI is enabled. Try to split acpi checking code out and call that later At that time ACPI iBFT already get permanent mapped with ioremap. So isa_virt_to_bus() will get wrong phys from right virt address. We could just skip that phys address printing. For legacy one, print the found address early. -v2: update comments and description according to Konrad. -v3: fix problem about module use case that is found by Konrad. -v4: use acpi_get_table() instead of acpi_table_parse() to handle module use case that is found by Konrad again.. Signed-off-by: Yinghai Lu Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 6b811b6a59edcf33dc695cd6edd5c5dd9096bf36 Author: Alex Deucher Date: Mon Dec 12 09:23:48 2011 -0500 drm/radeon/kms: add some new pci ids commit cd5cfce856684e13b9b57d46b78bb827e9c4da3c upstream. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43739 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 95ef45cf95424cffc4719e80067c392ba0a382e7 Author: Larry Finger Date: Sun Dec 11 10:27:54 2011 -0600 staging: r8712u: Add new USB ID commit c7caf4d4c56aee40b995f5858ccf1c814f3d2da2 upstream. Add USB ID for Sitecom WLA-2000 v1.001 WLAN. Reported-and-tested-by: Roland Gruber Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit b0c1dfb82b43b53fb60104f7969b87b7c54cc832 Author: Roel Kluin Date: Tue Dec 13 10:37:00 2011 +0100 fuse: fix llseek bug commit b48c6af2086ab2ba8a9c9b6ce9ecb34592ce500c upstream. The test in fuse_file_llseek() "not SEEK_CUR or not SEEK_SET" always evaluates to true. This was introduced in 3.1 by commit 06222e49 (fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek) and changed the behavior of SEEK_CUR and SEEK_SET to always retrieve the file attributes. This is a performance regression. Fix the test so that it makes sense. Signed-off-by: Miklos Szeredi CC: Josef Bacik CC: Al Viro Signed-off-by: Greg Kroah-Hartman commit 3425a017beef04b5152fb6c3c7b2b2768473ed21 Author: Miklos Szeredi Date: Tue Dec 13 10:36:59 2011 +0100 fuse: fix fuse_retrieve commit 48706d0a91583d08c56e7ef2a7602d99c8d4133f upstream. Fix two bugs in fuse_retrieve(): - retrieving more than one page would yield repeated instances of the first page - if more than FUSE_MAX_PAGES_PER_REQ pages were requested than the request page array would overflow fuse_retrieve() was added in 2.6.36 and these bugs had been there since the beginning. Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 91bcbb691f0dfe96fe385ba174fc3966049733ae Author: Yongqiang Yang Date: Tue Dec 13 22:29:12 2011 -0500 ext4: handle EOF correctly in ext4_bio_write_page() commit 5a0dc7365c240795bf190766eba7a27600be3b3e upstream. We need to zero out part of a page which beyond EOF before setting uptodate, otherwise, mapread or write will see non-zero data beyond EOF. Signed-off-by: Yongqiang Yang Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 8afe1f656c3cb0eff4219e3a4a22b95579148ad6 Author: Yongqiang Yang Date: Tue Dec 13 21:51:55 2011 -0500 ext4: avoid potential hang in mpage_submit_io() when blocksize < pagesize commit 13a79a4741d37fda2fbafb953f0f301dc007928f upstream. If there is an unwritten but clean buffer in a page and there is a dirty buffer after the buffer, then mpage_submit_io does not write the dirty buffer out. As a result, da_writepages loops forever. This patch fixes the problem by checking dirty flag. Signed-off-by: Yongqiang Yang Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit d118bc3aec8134c35f9de6dbb85d6c30d71a1b54 Author: Andrea Arcangeli Date: Tue Dec 13 21:41:15 2011 -0500 ext4: avoid hangs in ext4_da_should_update_i_disksize() commit ea51d132dbf9b00063169c1159bee253d9649224 upstream. If the pte mapping in generic_perform_write() is unmapped between iov_iter_fault_in_readable() and iov_iter_copy_from_user_atomic(), the "copied" parameter to ->end_write can be zero. ext4 couldn't cope with it with delayed allocations enabled. This skips the i_disksize enlargement logic if copied is zero and no new data was appeneded to the inode. gdb> bt #0 0xffffffff811afe80 in ext4_da_should_update_i_disksize (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x1\ 08000, len=0x1000, copied=0x0, page=0xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2467 #1 ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\ xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512 #2 0xffffffff810d97f1 in generic_perform_write (iocb=, iov=, nr_segs=, pos=0x108000, ppos=0xffff88001e26be40, count=, written=0x0) at mm/filemap.c:2440 #3 generic_file_buffered_write (iocb=, iov=, nr_segs=, p\ os=0x108000, ppos=0xffff88001e26be40, count=, written=0x0) at mm/filemap.c:2482 #4 0xffffffff810db5d1 in __generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, ppos=0\ xffff88001e26be40) at mm/filemap.c:2600 #5 0xffffffff810db853 in generic_file_aio_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=, pos=) at mm/filemap.c:2632 #6 0xffffffff811a71aa in ext4_file_write (iocb=0xffff88001e26bde8, iov=0xffff88001e26bec8, nr_segs=0x1, pos=0x108000) a\ t fs/ext4/file.c:136 #7 0xffffffff811375aa in do_sync_write (filp=0xffff88003f606a80, buf=, len=, \ ppos=0xffff88001e26bf48) at fs/read_write.c:406 #8 0xffffffff81137e56 in vfs_write (file=0xffff88003f606a80, buf=0x1ec2960
, count=0x4\ 000, pos=0xffff88001e26bf48) at fs/read_write.c:435 #9 0xffffffff8113816c in sys_write (fd=, buf=0x1ec2960
, count=0x\ 4000) at fs/read_write.c:487 #10 #11 0x00007f120077a390 in __brk_reservation_fn_dmi_alloc__ () #12 0x0000000000000000 in ?? () gdb> print offset $22 = 0xffffffffffffffff gdb> print idx $23 = 0xffffffff gdb> print inode->i_blkbits $24 = 0xc gdb> up #1 ext4_da_write_end (file=0xffff88003f606a80, mapping=0xffff88001d3824e0, pos=0x108000, len=0x1000, copied=0x0, page=0\ xffffea0000d792e8, fsdata=0x0) at fs/ext4/inode.c:2512 2512 if (ext4_da_should_update_i_disksize(page, end)) { gdb> print start $25 = 0x0 gdb> print end $26 = 0xffffffffffffffff gdb> print pos $27 = 0x108000 gdb> print new_i_size $28 = 0x108000 gdb> print ((struct ext4_inode_info *)((char *)inode-((int)(&((struct ext4_inode_info *)0)->vfs_inode))))->i_disksize $29 = 0xd9000 gdb> down 2467 for (i = 0; i < idx; i++) gdb> print i $30 = 0xd44acbee This is 100% reproducible with some autonuma development code tuned in a very aggressive manner (not normal way even for knumad) which does "exotic" changes to the ptes. It wouldn't normally trigger but I don't see why it can't happen normally if the page is added to swap cache in between the two faults leading to "copied" being zero (which then hangs in ext4). So it should be fixed. Especially possible with lumpy reclaim (albeit disabled if compaction is enabled) as that would ignore the young bits in the ptes. Signed-off-by: Andrea Arcangeli Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 4649c711b045511d0817f6975bf346f05d0b960d Author: Theodore Ts'o Date: Mon Dec 12 22:06:18 2011 -0500 ext4: display the correct mount option in /proc/mounts for [no]init_itable commit fc6cb1cda5db7b2d24bf32890826214b857c728e upstream. /proc/mounts was showing the mount option [no]init_inode_table when the correct mount option that will be accepted by parse_options() is [no]init_itable. Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 6415da6d18a55702cee3f01662733d0501635bbc Author: Theodore Ts'o Date: Mon Dec 12 10:53:02 2011 -0500 ext4: fix ext4_end_io_dio() racing against fsync() commit b5a7e97039a80fae673ccc115ce595d5b88fb4ee upstream. We need to make sure iocb->private is cleared *before* we put the io_end structure on i_completed_io_list. Otherwise fsync() could potentially run on another CPU and free the iocb structure out from under us. Reported-by: Kent Overstreet Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit d7587810a40aee32ec6bdfc2d4bce7ba9fd03c3e Author: Ian Campbell Date: Wed Dec 14 12:16:08 2011 +0000 xen: only limit memory map to maximum reservation for domain 0. commit d3db728125c4470a2d061ac10fa7395e18237263 upstream. d312ae878b6a "xen: use maximum reservation to limit amount of usable RAM" clamped the total amount of RAM to the current maximum reservation. This is correct for dom0 but is not correct for guest domains. In order to boot a guest "pre-ballooned" (e.g. with memory=1G but maxmem=2G) in order to allow for future memory expansion the guest must derive max_pfn from the e820 provided by the toolstack and not the current maximum reservation (which can reflect only the current maximum, not the guest lifetime max). The existing algorithm already behaves this correctly if we do not artificially limit the maximum number of pages for the guest case. For a guest booted with maxmem=512, memory=128 this results in: [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable) [ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved) -[ 0.000000] Xen: 0000000000100000 - 0000000008100000 (usable) -[ 0.000000] Xen: 0000000008100000 - 0000000020800000 (unusable) +[ 0.000000] Xen: 0000000000100000 - 0000000020800000 (usable) ... [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] DMI not present or invalid. [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved) [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) -[ 0.000000] last_pfn = 0x8100 max_arch_pfn = 0x1000000 +[ 0.000000] last_pfn = 0x20800 max_arch_pfn = 0x1000000 [ 0.000000] initial memory mapped : 0 - 027ff000 [ 0.000000] Base memory trampoline at [c009f000] 9f000 size 4096 -[ 0.000000] init_memory_mapping: 0000000000000000-0000000008100000 -[ 0.000000] 0000000000 - 0008100000 page 4k -[ 0.000000] kernel direct mapping tables up to 8100000 @ 27bb000-27ff000 +[ 0.000000] init_memory_mapping: 0000000000000000-0000000020800000 +[ 0.000000] 0000000000 - 0020800000 page 4k +[ 0.000000] kernel direct mapping tables up to 20800000 @ 26f8000-27ff000 [ 0.000000] xen: setting RW the range 27e8000 - 27ff000 [ 0.000000] 0MB HIGHMEM available. -[ 0.000000] 129MB LOWMEM available. -[ 0.000000] mapped low ram: 0 - 08100000 -[ 0.000000] low ram: 0 - 08100000 +[ 0.000000] 520MB LOWMEM available. +[ 0.000000] mapped low ram: 0 - 20800000 +[ 0.000000] low ram: 0 - 20800000 With this change "xl mem-set 512M" will successfully increase the guest RAM (by reducing the balloon). There is no change for dom0. Reported-and-Tested-by: George Shuklin Signed-off-by: Ian Campbell Reviewed-by: David Vrabel Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit ab60f998af2d14c0c3d1d85edd38aea5ca41b1f6 Author: Alex Deucher Date: Fri Oct 28 16:07:36 2011 -0400 drm/radeon/kms: fix DP setup on TRAVIS bridges commit cf2aff6eff251b6fbdaf8c253e65ff7c693de8cd upstream. Supposedly both NUTMEG and TRAVIS should use the same panel mode, but switching the panel mode for TRAVIS gets things working. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41569 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit bdcb5dfae2b68aafbb66f56b8f10c4876f341e32 Author: Alex Deucher Date: Mon Oct 31 08:58:47 2011 -0400 drm/radeon/kms: rework DP bridge checks commit 1d33e1fc8dcce667a70387b666a8b6f60153d90f upstream. Return the encoder id rather than a boolean. This is needed for differentiate between multiple DP bridge chips. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 26b947d476c08b8f3879b4c0cd4d1545653d74f4 Author: Alex Deucher Date: Tue Oct 25 11:34:51 2011 -0400 drm/radeon/kms: cleanup atombios_adjust_pll() commit b4f15f808b9a79b6ad9032fa5f6d8b88e1e1bf11 upstream. The logic was messy and hard to follow. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 9f0f2bb728f4e87568f89a5603f7d3b76ef6a3b9 Author: Phillip Lougher Date: Wed Nov 2 13:38:01 2011 -0700 hfs: fix hfs_find_init() sb->ext_tree NULL ptr oops commit 434a964daa14b9db083ce20404a4a2add54d037a upstream. Clement Lecigne reports a filesystem which causes a kernel oops in hfs_find_init() trying to dereference sb->ext_tree which is NULL. This proves to be because the filesystem has a corrupted MDB extent record, where the extents file does not fit into the first three extents in the file record (the first blocks). In hfs_get_block() when looking up the blocks for the extent file (HFS_EXT_CNID), it fails the first blocks special case, and falls through to the extent code (which ultimately calls hfs_find_init()) which is in the process of being initialised. Hfs avoids this scenario by always having the extents b-tree fitting into the first blocks (the extents B-tree can't have overflow extents). The fix is to check at mount time that the B-tree fits into first blocks, i.e. fail if HFS_I(inode)->alloc_blocks >= HFS_I(inode)->first_blocks Note, the existing commit 47f365eb57573 ("hfs: fix oops on mount with corrupted btree extent records") becomes subsumed into this as a special case, but only for the extents B-tree (HFS_EXT_CNID), it is perfectly acceptable for the catalog B-Tree file to grow beyond three extents, with the remaining extent descriptors in the extents overfow. This fixes CVE-2011-2203 Reported-by: Clement LECIGNE Signed-off-by: Phillip Lougher Cc: Jeff Mahoney Cc: Christoph Hellwig Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Moritz Mühlenhoff Signed-off-by: Greg Kroah-Hartman commit d02ab857b278eb3a232daf85f78af0252044a728 Author: Eryu Guan Date: Tue Nov 1 19:04:59 2011 -0400 jbd/jbd2: validate sb->s_first in journal_get_superblock() commit 8762202dd0d6e46854f786bdb6fb3780a1625efe upstream. I hit a J_ASSERT(blocknr != 0) failure in cleanup_journal_tail() when mounting a fsfuzzed ext3 image. It turns out that the corrupted ext3 image has s_first = 0 in journal superblock, and the 0 is passed to journal->j_head in journal_reset(), then to blocknr in cleanup_journal_tail(), in the end the J_ASSERT failed. So validate s_first after reading journal superblock from disk in journal_get_superblock() to ensure s_first is valid. The following script could reproduce it: fstype=ext3 blocksize=1024 img=$fstype.img offset=0 found=0 magic="c0 3b 39 98" dd if=/dev/zero of=$img bs=1M count=8 mkfs -t $fstype -b $blocksize -F $img filesize=`stat -c %s $img` while [ $offset -lt $filesize ] do if od -j $offset -N 4 -t x1 $img | grep -i "$magic";then echo "Found journal: $offset" found=1 break fi offset=`echo "$offset+$blocksize" | bc` done if [ $found -ne 1 ];then echo "Magic \"$magic\" not found" exit 1 fi dd if=/dev/zero of=$img seek=$(($offset+23)) conv=notrunc bs=1 count=1 mkdir -p ./mnt mount -o loop $img ./mnt Cc: Jan Kara Signed-off-by: Eryu Guan Signed-off-by: "Theodore Ts'o" Cc: Moritz Mühlenhoff Signed-off-by: Greg Kroah-Hartman commit f92285eb8772be3bde3a2d8e6ec123fefb7ece80 Author: Mark Langsdorf Date: Fri Nov 18 16:33:06 2011 +0100 x86, hpet: Immediately disable HPET timer 1 if rtc irq is masked commit 2ded6e6a94c98ea453a156748cb7fabaf39a76b9 upstream. When HPET is operating in RTC mode, the TN_ENABLE bit on timer1 controls whether the HPET or the RTC delivers interrupts to irq8. When the system goes into suspend, the RTC driver sends a signal to the HPET driver so that the HPET releases control of irq8, allowing the RTC to wake the system from suspend. The switchover is accomplished by a write to the HPET configuration registers which currently only occurs while servicing the HPET interrupt. On some systems, I have seen the system suspend before an HPET interrupt occurs, preventing the write to the HPET configuration register and leaving the HPET in control of the irq8. As the HPET is not active during suspend, it does not generate a wake signal and RTC alarms do not work. This patch forces the HPET driver to immediately transfer control of the irq8 channel to the RTC instead of waiting until the next interrupt event. Signed-off-by: Mark Langsdorf Link: http://lkml.kernel.org/r/20111118153306.GB16319@alberich.amd.com Tested-by: Andreas Herrmann Signed-off-by: Andreas Herrmann Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit dc43883928066a7fc474755c6e96f8fae348fe59 Author: Konrad Rzeszutek Wilk Date: Mon Nov 21 18:02:02 2011 -0500 xen/pm_idle: Make pm_idle be default_idle under Xen. commit e5fd47bfab2df0c2184cc0bf4245d8e1bb7724fb upstream. The idea behind commit d91ee5863b71 ("cpuidle: replace xen access to x86 pm_idle and default_idle") was to have one call - disable_cpuidle() which would make pm_idle not be molested by other code. It disallows cpuidle_idle_call to be set to pm_idle (which is excellent). But in the select_idle_routine() and idle_setup(), the pm_idle can still be set to either: amd_e400_idle, mwait_idle or default_idle. This depends on some CPU flags (MWAIT) and in AMD case on the type of CPU. In case of mwait_idle we can hit some instances where the hypervisor (Amazon EC2 specifically) sets the MWAIT and we get: Brought up 2 CPUs invalid opcode: 0000 [#1] SMP Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1 RIP: e030:[] [] mwait_idle+0x6f/0xb4 ... Call Trace: [] cpu_idle+0xae/0xe8 [] cpu_bringup_and_idle+0xe/0x10 RIP [] mwait_idle+0x6f/0xb4 RSP In the case of amd_e400_idle we don't get so spectacular crashes, but we do end up making an MSR which is trapped in the hypervisor, and then follow it up with a yield hypercall. Meaning we end up going to hypervisor twice instead of just once. The previous behavior before v3.0 was that pm_idle was set to default_idle regardless of select_idle_routine/idle_setup. We want to do that, but only for one specific case: Xen. This patch does that. Fixes RH BZ #739499 and Ubuntu #881076 Reported-by: Stefan Bader Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 572b113fe89287f81dad1a0f9057d48e0b17e910 Author: Sascha Hauer Date: Fri Nov 11 16:28:05 2011 +0100 mmc: mxcmmc: fix falling back to PIO commit e58f516ff4730c4047c3f104b061f7a03e9a263c upstream. When we can't configure the dma channel we want to fall back to PIO. We do this by setting host->do_dma to zero. This does not work as do_dma is used to see whether dma can be used for the current transfer. Instead, we have to set host->dma to NULL. Signed-off-by: Sascha Hauer Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman commit f986d9886478c6761c9cc3f44cbe15f96db5d6e1 Author: Arnaud Patard Date: Sun Dec 11 20:32:25 2011 +0100 ARM: 7204/1: arch/arm/kernel/setup.c: initialize arm_dma_zone_size earlier commit 9811ccdfa94b4773c8030569bd8ec75eafa485ac upstream. arm_dma_zone_size is used by arm_bootmem_free() which is called by paging_init(). Thus it needs to be set before calling it. Signed-off-by: Arnaud Patard Acked-by: Nicolas Pitre Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 584e8debed486b7ea98ba2d8dbf20e0a49d2798b Author: Axel Lin Date: Thu Dec 8 08:04:12 2011 -0500 hwmon: (jz4740) fix signedness bug commit 0b57d7602b68f7b2786b2f0e22da39cbd4139a95 upstream. wait_for_completion_interruptible_timeout() may return negative value. In this case, checking if (t > 0) will return true if t is unsigned. Signed-off-by: Axel Lin Acked-by: Lars-Peter Clausen Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 55f8ec6278236c45d82367cc6eca5028e1c7f87c Author: Linus Torvalds Date: Mon Dec 12 22:06:55 2011 -0800 linux/log2.h: Fix rounddown_pow_of_two(1) commit 13c07b0286d340275f2d97adf085cecda37ede37 upstream. Exactly like roundup_pow_of_two(1), the rounddown version was buggy for the case of a compile-time constant '1' argument. Probably because it originated from the same code, sharing history with the roundup version from before the bugfix (for that one, see commit 1a06a52ee1b0: "Fix roundup_pow_of_two(1)"). However, unlike the roundup version, the fix for rounddown is to just remove the broken special case entirely. It's simply not needed - the generic code 1UL << ilog2(n) does the right thing for the constant '1' argment too. The only reason roundup needed that special case was because rounding up does so by subtracting one from the argument (and then adding one to the result) causing the obvious problems with "ilog2(0)". But rounddown doesn't do any of that, since ilog2() naturally truncates (ie "rounds down") to the right rounded down value. And without the ilog2(0) case, there's no reason for the special case that had the wrong value. tl;dr: rounddown_pow_of_two(1) should be 1, not 0. Acked-by: Dmitry Torokhov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5bf4dba2647ee7eb377cb0f809d7abea461d34ae Author: Jeff Layton Date: Thu Dec 1 20:23:34 2011 -0500 cifs: check for NULL last_entry before calling cifs_save_resume_key commit 7023676f9ee851d94f0942e879243fc1f9081c47 upstream. Prior to commit eaf35b1, cifs_save_resume_key had some NULL pointer checks at the top. It turns out that at least one of those NULL pointer checks is needed after all. When the LastNameOffset in a FIND reply appears to be beyond the end of the buffer, CIFSFindFirst and CIFSFindNext will set srch_inf.last_entry to NULL. Since eaf35b1, the code will now oops in this situation. Fix this by having the callers check for a NULL last entry pointer before calling cifs_save_resume_key. No change is needed for the call site in cifs_readdir as it's not reachable with a NULL current_entry pointer. This should fix: https://bugzilla.redhat.com/show_bug.cgi?id=750247 Cc: Christoph Hellwig Reported-by: Adam G. Metzler Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 42354507ebd4124dbe46e46fe1ba7d9e0af0fe70 Author: Tejun Heo Date: Fri Nov 18 10:55:35 2011 -0800 percpu: fix chunk range calculation commit a855b84c3d8c73220d4d3cd392a7bee7c83de70e upstream. Percpu allocator recorded the cpus which map to the first and last units in pcpu_first/last_unit_cpu respectively and used them to determine the address range of a chunk - e.g. it assumed that the first unit has the lowest address in a chunk while the last unit has the highest address. This simply isn't true. Groups in a chunk can have arbitrary positive or negative offsets from the previous one and there is no guarantee that the first unit occupies the lowest offset while the last one the highest. Fix it by actually comparing unit offsets to determine cpus occupying the lowest and highest offsets. Also, rename pcu_first/last_unit_cpu to pcpu_low/high_unit_cpu to avoid confusion. The chunk address range is used to flush cache on vmalloc area map/unmap and decide whether a given address is in the first chunk by per_cpu_ptr_to_phys() and the bug was discovered by invalid per_cpu_ptr_to_phys() translation for crash_note. Kudos to Dave Young for tracking down the problem. Signed-off-by: Tejun Heo Reported-by: WANG Cong Reported-by: Dave Young Tested-by: Dave Young LKML-Reference: <4EC21F67.10905@redhat.com> Signed-off-by: Thomas Renninger Signed-off-by: Greg Kroah-Hartman commit 31922adf08bd43e543eebb83adb856a489986aa6 Author: Sebastian Andrzej Siewior Date: Mon Nov 28 12:33:10 2011 +0100 target/file: walk properly over sg list commit 9649fa1b8764f64c8cc4293e197e14cd46fe7205 upstream. This patch changes fileio to use for_each_sg() when walking se_task->task_sg memory passed into from loopback LLD struct scsi_cmnd scatterlist memory. This addresses an issue where FILEIO backends with loopback where hitting the following OOPs with mkfs.ext2: |kernel BUG at include/linux/scatterlist.h:97! |invalid opcode: 0000 [#1] PREEMPT SMP |Modules linked in: sd_mod tcm_loop target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs scsi_mod | |Pid: 671, comm: LIO_fileio Not tainted 3.1.0-rc10+ #139 Bochs Bochs |EIP: 0060:[] EFLAGS: 00010202 CPU: 0 |EIP is at fd_do_task+0x396/0x420 [target_core_file] | [] __transport_execute_tasks+0xd4/0x190 [target_core_mod] | [] transport_execute_tasks+0x3c/0xf0 [target_core_mod] |EIP: [] fd_do_task+0x396/0x420 [target_core_file] SS:ESP 0068:dea47e90 Signed-off-by: Sebastian Andrzej Siewior Cc: Christoph Hellwig Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 32d7d1813d394c2e74b444cc4226ece55a26739a Author: Nicholas Bellinger Date: Sun Nov 27 22:25:14 2011 -0800 iscsi-target: Add missing F_BIT for iscsi_tm_rsp commit 7ae0b1038f9f7d4c91e9afd4dbbc98210bf1a241 upstream. This patch sets the missing ISCSI_FLAG_CMD_FINAL bit in iscsit_send_task_mgt_rsp() for a struct iscsi_tm_rsp PDU. This usage is hardcoded for all TM response PDUs in RFC-3720 section 10.6. Reported-by: whucecil Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 2b16ab8d498d84a33a7f827184beb3c9fbc7da9f Author: Roland Dreier Date: Tue Nov 22 13:51:34 2011 -0800 target: Fix page length in emulated INQUIRY VPD page 86h commit 1289a0571c037b4757f60597d646aedb70361ec3 upstream. The LSB of the page length is at offset 3, not 2. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 6764359b3a2840ea27cf09d1c4306598af8767bd Author: Roland Dreier Date: Tue Nov 22 13:51:33 2011 -0800 target: Handle 0 correctly in transport_get_sectors_6() commit 9b5cd7f37e1e018432111333e2a67f78ba41edfe upstream. SBC-3 says: A TRANSFER LENGTH field set to zero specifies that 256 logical blocks shall be written. Any other value specifies the number of logical blocks that shall be written. The old code was always just returning the value in the TRANSFER LENGTH byte. Fix this to return 256 if the byte is 0. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 43dd6e6faffcacc6d8d9d12f15d6aa5f2f4fa351 Author: Nicholas Bellinger Date: Tue Nov 15 23:59:00 2011 -0800 iscsi-target: Fix residual count hanlding + remove iscsi_cmd->residual_count commit 7e46cf02687e40197ae07c623e660be2a2720064 upstream. This patch fixes iscsi-target handling of underflow where residual data is causing an OOPs by using the incorrect iscsi_cmd_t->data_length initially assigned in iscsit_allocate_se_cmd(). It resets iscsi_cmd_t->data_length from se_cmd_t->data_length after transport_generic_allocate_tasks() has been invoked in iscsit_handle_scsi_cmd() RX context, and converts iscsi_cmd->residual_count usage to access iscsi_cmd->se_cmd.residual_count to get the proper residual count set by target-core. Reported-by: Cc: Christoph Hellwig Cc: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 1c9c1ada7ee0b4b42e451d35153dff3735b28cac Author: Nicholas Bellinger Date: Tue Nov 15 22:13:24 2011 -0800 target: Reject SCSI data overflow for fabrics using transport_generic_map_mem_to_cmd commit fef58a6096770ed6ab49103a430cc755254a74d9 upstream. This patch changes transport_generic_map_mem_to_cmd() to reject SCSI data overflow and to send exception status with CHECK_CONDITION + TCM_INVALID_CDB_FIELD for fabrics that are passing a pre-populated struct scatterlist (eg: tcm_loop and iscsi-target) being mapped into se_cmd->t_data_sg and se_cmd->t_data_nents. This addresses an OOPs where transport_allocate_data_tasks() would walk the incorrect post OVERFLOW cmd->data_length value beyond the end of the passed scatterlist. Cc: Christoph Hellwig Cc: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit f55f75a191f661f652920f788501e6546a60c3f5 Author: Tetsuo Handa Date: Thu Dec 8 21:24:06 2011 +0900 TOMOYO: Fix pathname handling of disconnected paths. commit 1418a3e5ad4d01b1d4abf2c479c50b0cedd59e3f upstream. Current tomoyo_realpath_from_path() implementation returns strange pathname when calculating pathname of a file which belongs to lazy unmounted tree. Use local pathname rather than strange absolute pathname in that case. Also, this patch fixes a regression by commit 02125a82 "fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API". Signed-off-by: Tetsuo Handa Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0e70f402bc3d69cb2c9607dc4216698b564a53b9 Author: Al Viro Date: Mon Dec 5 08:43:34 2011 -0500 fix apparmor dereferencing potentially freed dentry, sanitize __d_path() API commit 02125a826459a6ad142f8d91c5b6357562f96615 upstream. __d_path() API is asking for trouble and in case of apparmor d_namespace_path() getting just that. The root cause is that when __d_path() misses the root it had been told to look for, it stores the location of the most remote ancestor in *root. Without grabbing references. Sure, at the moment of call it had been pinned down by what we have in *path. And if we raced with umount -l, we could have very well stopped at vfsmount/dentry that got freed as soon as prepend_path() dropped vfsmount_lock. It is safe to compare these pointers with pre-existing (and known to be still alive) vfsmount and dentry, as long as all we are asking is "is it the same address?". Dereferencing is not safe and apparmor ended up stepping into that. d_namespace_path() really wants to examine the place where we stopped, even if it's not connected to our namespace. As the result, it looked at ->d_sb->s_magic of a dentry that might've been already freed by that point. All other callers had been careful enough to avoid that, but it's really a bad interface - it invites that kind of trouble. The fix is fairly straightforward, even though it's bigger than I'd like: * prepend_path() root argument becomes const. * __d_path() is never called with NULL/NULL root. It was a kludge to start with. Instead, we have an explicit function - d_absolute_root(). Same as __d_path(), except that it doesn't get root passed and stops where it stops. apparmor and tomoyo are using it. * __d_path() returns NULL on path outside of root. The main caller is show_mountinfo() and that's precisely what we pass root for - to skip those outside chroot jail. Those who don't want that can (and do) use d_path(). * __d_path() root argument becomes const. Everyone agrees, I hope. * apparmor does *NOT* try to use __d_path() or any of its variants when it sees that path->mnt is an internal vfsmount. In that case it's definitely not mounted anywhere and dentry_path() is exactly what we want there. Handling of sysctl()-triggered weirdness is moved to that place. * if apparmor is asked to do pathname relative to chroot jail and __d_path() tells it we it's not in that jail, the sucker just calls d_absolute_path() instead. That's the other remaining caller of __d_path(), BTW. * seq_path_root() does _NOT_ return -ENAMETOOLONG (it's stupid anyway - the normal seq_file logics will take care of growing the buffer and redoing the call of ->show() just fine). However, if it gets path not reachable from root, it returns SEQ_SKIP. The only caller adjusted (i.e. stopped ignoring the return value as it used to do). Reviewed-by: John Johansen ACKed-by: John Johansen Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 7e9062c8c8172253a86b3db01e52f8e576306a95 Author: Mel Gorman Date: Thu Dec 8 14:34:30 2011 -0800 mm: vmalloc: check for page allocation failure before vmlist insertion commit 1368edf0647ac112d8cfa6ce47257dc950c50f5c upstream. Commit f5252e00 ("mm: avoid null pointer access in vm_struct via /proc/vmallocinfo") adds newly allocated vm_structs to the vmlist after it is fully initialised. Unfortunately, it did not check that __vmalloc_area_node() successfully populated the area. In the event of allocation failure, the vmalloc area is freed but the pointer to freed memory is inserted into the vmlist leading to a a crash later in get_vmalloc_info(). This patch adds a check for ____vmalloc_area_node() failure within __vmalloc_node_range. It does not use "goto fail" as in the previous error path as a warning was already displayed by __vmalloc_area_node() before it called vfree in its failure path. Credit goes to Luciano Chavez for doing all the real work of identifying exactly where the problem was. Signed-off-by: Mel Gorman Reported-by: Luciano Chavez Tested-by: Luciano Chavez Reviewed-by: Rik van Riel Acked-by: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2b5650085aa82f04312a9451bbfc45d809580055 Author: Michal Hocko Date: Thu Dec 8 14:34:27 2011 -0800 mm: Ensure that pfn_valid() is called once per pageblock when reserving pageblocks commit d021563888312018ca65681096f62e36c20e63cc upstream. setup_zone_migrate_reserve() expects that zone->start_pfn starts at pageblock_nr_pages aligned pfn otherwise we could access beyond an existing memblock resulting in the following panic if CONFIG_HOLES_IN_ZONE is not configured and we do not check pfn_valid: IP: [] setup_zone_migrate_reserve+0xcd/0x180 *pdpt = 0000000000000000 *pde = f000ff53f000ff53 Oops: 0000 [#1] SMP Pid: 1, comm: swapper Not tainted 3.0.7-0.7-pae #1 VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform EIP: 0060:[] EFLAGS: 00010006 CPU: 0 EIP is at setup_zone_migrate_reserve+0xcd/0x180 EAX: 000c0000 EBX: f5801fc0 ECX: 000c0000 EDX: 00000000 ESI: 000c01fe EDI: 000c01fe EBP: 00140000 ESP: f2475f58 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 1, ti=f2474000 task=f2472cd0 task.ti=f2474000) Call Trace: [] __setup_per_zone_wmarks+0xec/0x160 [] setup_per_zone_wmarks+0xf/0x20 [] init_per_zone_wmark_min+0x27/0x86 [] do_one_initcall+0x2b/0x160 [] kernel_init+0xbe/0x157 [] kernel_thread_helper+0x6/0xd Code: a5 39 f5 89 f7 0f 46 fd 39 cf 76 40 8b 03 f6 c4 08 74 32 eb 91 90 89 c8 c1 e8 0e 0f be 80 80 2f 86 c0 8b 14 85 60 2f 86 c0 89 c8 <2b> 82 b4 12 00 00 c1 e0 05 03 82 ac 12 00 00 8b 00 f6 c4 08 0f EIP: [] setup_zone_migrate_reserve+0xcd/0x180 SS:ESP 0068:f2475f58 CR2: 00000000000012b4 We crashed in pageblock_is_reserved() when accessing pfn 0xc0000 because highstart_pfn = 0x36ffe. The issue was introduced in 3.0-rc1 by 6d3163ce ("mm: check if any page in a pageblock is reserved before marking it MIGRATE_RESERVE"). Make sure that start_pfn is always aligned to pageblock_nr_pages to ensure that pfn_valid s always called at the start of each pageblock. Architectures with holes in pageblocks will be correctly handled by pfn_valid_within in pageblock_is_reserved. Signed-off-by: Michal Hocko Signed-off-by: Mel Gorman Tested-by: Dang Bo Reviewed-by: KAMEZAWA Hiroyuki Cc: Andrea Arcangeli Cc: David Rientjes Cc: Arve Hjnnevg Cc: KOSAKI Motohiro Cc: John Stultz Cc: Dave Hansen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d13226b503ebfb6d1191dad27e0b0cda8796f73a Author: Thomas Gleixner Date: Mon Dec 5 21:16:06 2011 +0100 ptp: Fix clock_getres() implementation commit d68fb11c3dae75c8331538dcf083a65e697cc034 upstream. The clock_getres() function must return the resolution in the timespec argument and return 0 for success. Signed-off-by: Thomas Gleixner Acked-by: John Stultz Cc: Richard Cochran Signed-off-by: Greg Kroah-Hartman commit f767f25ebc6a9233e50561657468f31bceb84a1e Author: Yong Zhang Date: Wed Nov 9 16:04:51 2011 +0800 lockdep, kmemcheck: Annotate ->lock in lockdep_init_map() commit a33caeb118198286309859f014c0662f3ed54ed4 upstream. Since commit f59de89 ("lockdep: Clear whole lockdep_map on initialization"), lockdep_init_map() will clear all the struct. But it will break lock_set_class()/lock_set_subclass(). A typical race condition is like below: CPU A CPU B lock_set_subclass(lockA); lock_set_class(lockA); lockdep_init_map(lockA); /* lockA->name is cleared */ memset(lockA); __lock_acquire(lockA); /* lockA->class_cache[] is cleared */ register_lock_class(lockA); look_up_lock_class(lockA); WARN_ON_ONCE(class->name != lock->name); lock->name = name; So restore to what we have done before commit f59de89 but annotate ->lock with kmemcheck_mark_initialized() to suppress the kmemcheck warning reported in commit f59de89. Reported-by: Sergey Senozhatsky Reported-by: Borislav Petkov Suggested-by: Vegard Nossum Signed-off-by: Yong Zhang Cc: Tejun Heo Cc: David Rientjes Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/20111109080451.GB8124@zhy Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 7f37071e9df2344a7d7d066235ec72a0d1a4b013 Author: Youquan Song Date: Thu Dec 8 14:34:18 2011 -0800 thp: set compound tail page _count to zero commit 58a84aa92723d1ac3e1cc4e3b0ff49291663f7e1 upstream. Commit 70b50f94f1644 ("mm: thp: tail page refcounting fix") keeps all page_tail->_count zero at all times. But the current kernel does not set page_tail->_count to zero if a 1GB page is utilized. So when an IOMMU 1GB page is used by KVM, it wil result in a kernel oops because a tail page's _count does not equal zero. kernel BUG at include/linux/mm.h:386! invalid opcode: 0000 [#1] SMP Call Trace: gup_pud_range+0xb8/0x19d get_user_pages_fast+0xcb/0x192 ? trace_hardirqs_off+0xd/0xf hva_to_pfn+0x119/0x2f2 gfn_to_pfn_memslot+0x2c/0x2e kvm_iommu_map_pages+0xfd/0x1c1 kvm_iommu_map_memslots+0x7c/0xbd kvm_iommu_map_guest+0xaa/0xbf kvm_vm_ioctl_assigned_device+0x2ef/0xa47 kvm_vm_ioctl+0x36c/0x3a2 do_vfs_ioctl+0x49e/0x4e4 sys_ioctl+0x5a/0x7c system_call_fastpath+0x16/0x1b RIP gup_huge_pud+0xf2/0x159 Signed-off-by: Youquan Song Reviewed-by: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 75aaef5468ceb118aa55825cf6a52d60d09dfde0 Author: Youquan Song Date: Thu Dec 8 14:34:16 2011 -0800 thp: add compound tail page _mapcount when mapped commit b6999b19120931ede364fa3b685e698a61fed31d upstream. With the 3.2-rc kernel, IOMMU 2M pages in KVM works. But when I tried to use IOMMU 1GB pages in KVM, I encountered an oops and the 1GB page failed to be used. The root cause is that 1GB page allocation calls gup_huge_pud() while 2M page calls gup_huge_pmd. If compound pages are used and the page is a tail page, gup_huge_pmd() increases _mapcount to record tail page are mapped while gup_huge_pud does not do that. So when the mapped page is relesed, it will result in kernel oops because the page is not marked mapped. This patch add tail process for compound page in 1GB huge page which keeps the same process as 2M page. Reproduce like: 1. Add grub boot option: hugepagesz=1G hugepages=8 2. mount -t hugetlbfs -o pagesize=1G hugetlbfs /dev/hugepages 3. qemu-kvm -m 2048 -hda os-kvm.img -cpu kvm64 -smp 4 -mem-path /dev/hugepages -net none -device pci-assign,host=07:00.1 kernel BUG at mm/swap.c:114! invalid opcode: 0000 [#1] SMP Call Trace: put_page+0x15/0x37 kvm_release_pfn_clean+0x31/0x36 kvm_iommu_put_pages+0x94/0xb1 kvm_iommu_unmap_memslots+0x80/0xb6 kvm_assign_device+0xba/0x117 kvm_vm_ioctl_assigned_device+0x301/0xa47 kvm_vm_ioctl+0x36c/0x3a2 do_vfs_ioctl+0x49e/0x4e4 sys_ioctl+0x5a/0x7c system_call_fastpath+0x16/0x1b RIP put_compound_page+0xd4/0x168 Signed-off-by: Youquan Song Reviewed-by: Andrea Arcangeli Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7171d74d6be6346a3e33e32f7270ee09852999f4 Author: Claudio Scordino Date: Thu Dec 8 14:33:56 2011 -0800 fs/proc/meminfo.c: fix compilation error commit b53fc7c2974a50913f49e1d800fe904a28c338e3 upstream. Fix the error message "directives may not be used inside a macro argument" which appears when the kernel is compiled for the cris architecture. Signed-off-by: Claudio Scordino Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c7443ad3168fc2fdafdaec2ad5facf9704937092 Author: Jonghwan Choi Date: Thu Dec 8 14:34:02 2011 -0800 drivers/rtc/rtc-s3c.c: fix driver clock enable/disable balance issues commit 2dbcd05f1e9e0932833d16dab1696176fc164b07 upstream. If an error occurs after the clock is enabled, the enable/disable state can become unbalanced. Signed-off-by: Jonghwan Choi Cc: Alessandro Zummo Acked-by: Kukjin Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bc0d9454f9eea8dc68d43cc485ea8125244a2a79 Author: Mark Brown Date: Mon Dec 5 20:50:45 2011 +0000 ASoC: Provide a more complete DMA driver stub commit cefcc03ffc9527dde56807339edb1719c8dbae5f upstream. Allow userspace applications to do more parameter setting by providing a more complete stub DMA driver specifying a wildcard set of formats and channels and essentially random values for the DMA parameters. This is required for useful runtime operation of the dummy DMA driver until we are able to figure out how to power up links and do hw_params() from DAPM. Sending to stable as without this the dummy driver is not terribly useful. Reported-by: Kyung-Kwee Ryu Tested-by: Kyung-Kwee Ryu Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 464986c2baa6daa8c7455606becdbf0fb9dd56d4 Author: Hans Verkuil Date: Mon Nov 14 19:20:49 2011 +0100 ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode commit 83713fc9373be2e943f82e9d36213708c6b0050e upstream. The function setup_vpif_input_channel_mode() used the VSCLKDIS register instead of VIDCLKCTL. This meant that when in HD mode videoport channel 0 used a different clock from channel 1. Clearly a copy-and-paste error. Signed-off-by: Hans Verkuil Acked-by: Manjunath Hadli Signed-off-by: Sekhar Nori Signed-off-by: Greg Kroah-Hartman commit 950f10d78925298d870690bbe48e492f294f15b0 Author: Anders Darander Date: Wed Nov 30 08:47:44 2011 +0100 ARM: at91: Fix USB AT91 gadget registration commit 0e934e22f3fabb98c41737e2e30bd9db2668e935 upstream. Since 193ab2a6070039e7ee2b9b9bebea754a7c52fd1b, various AT91 boards don't register at91_udc anymore due to depending on a now non-existing symbol. Fix the symbol name. Signed-off-by: Anders Darander Signed-off-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit d0e41c6542b81dd38498053a5eeda07f5468caf6 Author: Jean-Christophe PLAGNIOL-VILLARD Date: Mon Nov 28 12:53:08 2011 +0100 ARM: at91: fix clock conid for atmel_tcb.1 on 9260/9g20 commit 1808958d27b1250295f01dff4997d8a8814adaab upstream. The conid is supposed to be t0/t1/t2_clk. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman commit a9d6c07ba834e92799dd97e4f5025770c79fef1b Author: Wolfram Sang Date: Sat Nov 26 11:39:14 2011 +0100 arm: mx23: recognise stmp378x as mx23 commit 11357be9246c7d1acf9b37ad54a18b29bbb734be upstream. Adding the machine_is_* line was forgotten when converting mach-stmp378x to mach-mxs. Signed-off-by: Wolfram Sang Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 25966c26fa066050b6270b5f94b58b8cf1f5a6ef Author: Manjunathappa, Prakash Date: Thu Nov 10 11:43:21 2011 +0530 ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0 commit f1b21c525693b0159aed83b5871f2d0f077f208e upstream. On OMAP-L138 platform, EDMA event queue 0 should be used for audio transfers so that they are not starved by video data moving on event queue 1. Commit 48519f0ae03bc7e86b3dc93e56f1334d53803770 (ASoC: davinci: let platform data define edma queue numbers) had a side-effect of changing this behavior by making the driver actually honor the platform data passed. Fix this now by passing event queue 0 as the queue to be used for audio transfers. Signed-off-by: Manjunathappa, Prakash Signed-off-by: Sekhar Nori Signed-off-by: Greg Kroah-Hartman commit b2b3ffbcbc6fb1b98ef3cb4dd85bc1d095ac95ee Author: Thomas Gleixner Date: Mon Dec 5 21:20:23 2011 +0100 alarmtimers: Fix time comparison commit c9c024b3f3e07d087974db4c0dc46217fff3a6c0 upstream. The expiry function compares the timer against current time and does not expire the timer when the expiry time is >= now. That's wrong. If the timer is set for now, then it must expire. Make the condition expiry > now for breaking out the loop. Signed-off-by: Thomas Gleixner Acked-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit e0b652a1a218e863e8fcf00aee316bf618bd0c1a Author: Takashi Iwai Date: Sun Dec 4 13:44:06 2011 +0100 ALSA: hda - Fix GPIO LED setup for IDT 92HD75 codecs commit f1a73746c6664442082e3d53e1804f46e1910436 upstream. Some HP laptops with IDT 92HD75 codecs may use a GPIO > 4 for the mute LED, but currently the driver doesn't check this properly, and confuses the mute LED behavior. This ended up with the silent output on some HP laptops due to having another GPIO used as external amp control. This patch fixes the problem by checking the max GPIO count and comparing with the given value from DMI entry instead of magic fixed value 4 and 8, and adding a new field to indicate the VREF mute-LED behavior. Reported-and-tested-by: Vitaliy Kulikov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 72a8cf91f33281144ffbd9d2b756565686f7159d Author: Takashi Iwai Date: Fri Dec 2 15:29:12 2011 +0100 ALSA: hda/realtek - Fix Oops in alc_mux_select() commit cce4aa378a049f4275416ee6302dd24f37b289df upstream. When no imux is available (e.g. a single capture source), alc_auto_init_input_src() may trigger an Oops due to the access to -1. Add a proper zero-check to avoid it. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 95d2c2c87d9363718f0248a95414cda168f295b7 Author: David Dillow Date: Thu Dec 1 23:26:53 2011 -0500 ALSA: sis7019 - give slow codecs more time to reset commit fc084e0b930d546872ab23667052499f7daf0fed upstream. There are some AC97 codec and board combinations that have been observed to take a very long time to respond after the cold reset has completed. In one case, more than 350 ms was required. To allow users to have sound on those platforms, we'll wait up to 500ms for the codec to become ready. As a board may have multiple codecs, with some faster than others to reset, we add a module parameter to inform the driver which codecs should be present. Reported-by: KotCzarny Signed-off-by: David Dillow Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman