- 12 Mar, 2012 39 commits
-
-
Eugeni Dodonov authored
commit eae66b50 upstream. This is yet another workaround related to clock gating which we need on Ivy Bridge. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44610Tested-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Beulich authored
3.0.21's 603b6348 directly used the upstream patch, yet kprobes locking in 3.0.x uses spin_lock...() rather than raw_spin_lock...(). Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
-
Fabio Baltieri authored
commit 31e0017e upstream. Enable use of the generic atomic64 implementation on AVR32 platforms. Without this the kernel fails to build as the architecture does not provide its version. Signed-off-by:
Fabio Baltieri <fabio.baltieri@gmail.com> Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Keng-Yu Lin authored
commit 5a50a7c3 upstream. The models do not resume correctly without acpi_sleep=nonvs. Signed-off-by:
Keng-Yu Lin <kengyu@canonical.com> Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Cc: Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 37b40adf upstream. We create "bsg" link if q->kobj.sd is not NULL, so remove it only when the same condition is true. Fixes: WARNING: at fs/sysfs/inode.c:323 sysfs_hash_and_remove+0x2b/0x77() sysfs: can not remove 'bsg', no directory Call Trace: [<c0429683>] warn_slowpath_common+0x6a/0x7f [<c0537a68>] ? sysfs_hash_and_remove+0x2b/0x77 [<c042970b>] warn_slowpath_fmt+0x2b/0x2f [<c0537a68>] sysfs_hash_and_remove+0x2b/0x77 [<c053969a>] sysfs_remove_link+0x20/0x23 [<c05d88f1>] bsg_unregister_queue+0x40/0x6d [<c0692263>] __scsi_remove_device+0x31/0x9d [<c069149f>] scsi_forget_host+0x41/0x52 [<c0689fa9>] scsi_remove_host+0x71/0xe0 [<f7de5945>] quiesce_and_remove_host+0x51/0x83 [usb_storage] [<f7de5a1e>] usb_stor_disconnect+0x18/0x22 [usb_storage] [<c06c29de>] usb_unbind_interface+0x4e/0x109 [<c067a80f>] __device_release_driver+0x6b/0xa6 [<c067a861>] device_release_driver+0x17/0x22 [<c067a46a>] bus_remove_device+0xd6/0xe6 [<c06785e2>] device_del+0xf2/0x137 [<c06c101f>] usb_disable_device+0x94/0x1a0 Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
-
Javier Martin authored
commit 5ed80a75 upstream. According to i.MX27 Reference Manual (p 1593) TXBIT0 bit selects whether the most significant or the less significant part of the data word written to the FIFO is transmitted. As DSP_A is the same as DSP_B with a data offset of 1 bit, it doesn't make any sense to remove TXBIT0 bit here. Signed-off-by:
Javier Martin <javier.martin@vista-silicon.com> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Mark Brown authored
commit 7679e42e upstream. Recent enhancements in the bias management means that we might not be in standby when the CODEC is idle and can have active widgets without being in full power mode but the shutdown functionality assumes these things. Add checks for the bias level at each stage so that we don't do transitions other than the ON->PREPARE->STANDBY->OFF ones that the drivers are expecting. Signed-off-by:
-
Boaz Harrosh authored
commit 41f8ad76 upstream. It used to be that minors where 8 bit. But now they are actually 20 bit. So the fix is simplicity itself. I've tested with 300 devices and all user-mode utils work just fine. I have also mechanically added 10,000 to the ida (so devices are /dev/osd10000, /dev/osd10001 ...) and was able to mkfs an exofs filesystem and access osds from user-mode. All the open-osd user-mode code uses the same library to access devices through their symbolic names in /dev/osdX so I'd say it's pretty safe. (Well tested) This patch is very important because some of the systems that will be deploying the 3.2 pnfs-objects code are larger than 64 OSDs and will stop to work properly when reaching that number. Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Phil Sutter authored
commit f8f54e19 upstream. Broken by commit 6ef84509 for users passing a request with non-zero 'nbytes' field, like e.g. testmgr. Signed-off-by:
Phil Sutter <phil.sutter@viprinet.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Alan Stern authored
commit 37891abc upstream. This patch (as1531) adds a NOGET quirk for the Slim+ keyboard marketed by AIREN. This keyboard seems to have a lot of bugs; NOGET works around only one of them. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
okias <d.okias@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Andrea Arcangeli authored
commit 1c641e84 upstream. Dave Jones reports a few Fedora users hitting the BUG_ON(mm->nr_ptes...) in exit_mmap() recently. Quoting Hugh's discovery and explanation of the SMP race condition: "mm->nr_ptes had unusual locking: down_read mmap_sem plus page_table_lock when incrementing, down_write mmap_sem (or mm_users 0) when decrementing; whereas THP is careful to increment and decrement it under page_table_lock. Now most of those paths in THP also hold mmap_sem for read or write (with appropriate checks on mm_users), but two do not: when split_huge_page() is called by hwpoison_user_mappings(), and when called by add_to_swap(). It's conceivable that the latter case is responsible for the exit_mmap() BUG_ON mm->nr_ptes that has been reported on Fedora." The simplest way to fix it without having to alter the locking is to make split_huge_page() a noop in nr_ptes terms, so by counting the preallocated pagetables that exists for every mapped hugepage. It was an arbitrary choice not to count them and either way is not wrong or right, because they are not used but they're still allocated. Reported-by:
Dave Jones <davej@redhat.com> Reported-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Acked-by:
-
Felix Fietkau authored
commit 9bbb8168 upstream. Duplicate the data for iniAddac early on, to avoid having to do redundant memcpy calls later. While we're at it, make AR5416 < v2.2 use the same codepath. Fixes a reported crash on x86. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Reported-by:
Magnus Määttä <magnus.maatta@logica.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
commit 8617b093 upstream. rate control algorithms concludes the rate as invalid with rate[i].idx < -1 , while they do also check for rate[i].count is non-zero. it would be safer to zero initialize the 'count' field. recently we had a ath9k rate control crash where the ath9k rate control in ath_tx_status assumed to check only for rate[i].count being non-zero in one instance and ended up in using invalid rate index for 'connection monitoring NULL func frames' which eventually lead to the crash. thanks to Pavel Roskin for fixing it and finding the root cause. https://bugzilla.redhat.com/show_bug.cgi?id=768639 Cc: Pavel Roskin <proski@gnu.org> Signed-off-by:
Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by:
-
Jeff Layton authored
commit 5bccda0e upstream. The cifs code will attempt to open files on lookup under certain circumstances. What happens though if we find that the file we opened was actually a FIFO or other special file? Currently, the open filehandle just ends up being leaked leading to a dentry refcount mismatch and oops on umount. Fix this by having the code close the filehandle on the server if it turns out not to be a regular file. While we're at it, change this spaghetti if statement into a switch too. Reported-by:
CAI Qian <caiqian@redhat.com> Tested-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
David Howells authored
commit b94cfaf6 upstream. Don't clear vm_mm in a deleted VMA as it's unnecessary and might conceivably break the filesystem or driver VMA close routine. Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
-
Anton Vorontsov authored
commit 371528ca upstream. There is an issue when memcg unregisters events that were attached to the same eventfd: - On the first call mem_cgroup_usage_unregister_event() removes all events attached to a given eventfd, and if there were no events left, thresholds->primary would become NULL; - Since there were several events registered, cgroups core will call mem_cgroup_usage_unregister_event() again, but now kernel will oops, as the function doesn't expect that threshold->primary may be NULL. That's a good question whether mem_cgroup_usage_unregister_event() should actually remove all events in one go, but nowadays it can't do any better as cftype->unregister_event callback doesn't pass any private event-associated cookie. So, let's fix the issue by simply checking for threshold->primary. FWIW, w/o the patch the following oops may be observed: BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0 Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs RIP: 0010:[<ffffffff810be32c>] [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0 RSP: 0018:ffff88001d0b9d60 EFLAGS: 00010246 Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0) Call Trace: [<ffffffff8107092b>] cgroup_event_remove+0x2b/0x60 [<ffffffff8103db94>] process_one_work+0x174/0x450 [<ffffffff8103e413>] worker_thread+0x123/0x2d0 Signed-off-by:
Anton Vorontsov <anton.vorontsov@linaro.org> Acked-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Cc: Michal Hocko <mhocko@suse.cz> Signed-off-by:
-
Sascha Hauer authored
commit 5b6b0ad6 upstream. On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION command. This works for SD cards. However, with MMC cards the MMC_SET_BLOCK_COUNT command is used instead, but this needs the same handling. Fix MMC cards by testing for the MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53 board with a Transcend MMC+ card and eMMC. The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this is a regression for these boards introduced in 3.0; it should go to 3.0/3.1/3.2-stable. Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Andrew Morton authored
commit 62aca403 upstream. Michael Cree said: : : I have noticed some user space problems (pulseaudio crashes in pthread : : code, glibc/nptl test suite failures, java compiler freezes on SMP alpha : : systems) that arise when using a 2.6.39 or later kernel on Alpha. : : Bisecting between 2.6.38 and 2.6.39 (using glibc/nptl test suite as : : criterion for good/bad kernel) eventually leads to: : : : : 8d7718aa is the first bad commit : : commit 8d7718aa : : Author: Michel Lespinasse <walken@google.com> : : Date: Thu Mar 10 18:50:58 2011 -0800 : : : : futex: Sanitize futex ops argument types : : : : Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic : : prototypes to use u32 types for the futex as this is the data type the : : futex core code uses all over the place. : : : : Looking at the commit I see there is a change of the uaddr argument in : : the Alpha architecture specific code for futexes from int to u32, but I : : don't see why this should cause a problem. Richard Henderson said: : futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr, : u32 oldval, u32 newval) : ... : : "r"(uaddr), "r"((long)oldval), "r"(newval) : : : There is no 32-bit compare instruction. These are implemented by : consistently extending the values to a 64-bit type. Since the : load instruction sign-extends, we want to sign-extend the other : quantity as well (despite the fact it's logically unsigned). : : So: : : - : "r"(uaddr), "r"((long)oldval), "r"(newval) : + : "r"(uaddr), "r"((long)(int)oldval), "r"(newval) : : should do the trick. Michael said: : This fixes the glibc test suite failures and the pulseaudio related : crashes, but it does not fix the java compiiler lockups that I was (and : are still) observing. That is some other problem. Reported-by:
Michael Cree <mcree@orcon.net.nz> Tested-by:
Phil Carmody <ext-phil.2.carmody@nokia.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Michel Lespinasse <walken@google.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Reviewed-by:
Matt Turner <mattst88@gmail.com> Signed-off-by:
-
Scott Talbert authored
commit ee932bf9 upstream. In the current kernel implementation, the Logitech Harmony 900 remote control is matched to the cdc_ether driver through the generic USB_CDC_SUBCLASS_MDLM entry. However, this device appears to be of the pseudo-MDLM (Belcarra) type, rather than the standard one. This patch blacklists the Harmony 900 from the cdc_ether driver and whitelists it for the pseudo-MDLM driver in zaurus. Signed-off-by:
Scott Talbert <talbert@techie.net> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Gusakov Andrey authored
commit e39d40c6 upstream. s3c2410_dma_suspend suspends channels from 0 to dma_channels. s3c2410_dma_resume resumes channels in reverse order. So pointer should be decremented instead of being incremented. Signed-off-by:
Gusakov Andrey <dron0gus@gmail.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Thomas Gleixner authored
commit 52abb700 upstream. Xommit ac563761(genirq: Unmask oneshot irqs when thread was not woken) fails to unmask when a !IRQ_ONESHOT threaded handler is handled by handle_level_irq. This happens because thread_mask is or'ed unconditionally in irq_wake_thread(), but for !IRQ_ONESHOT interrupts never cleared. So the check for !desc->thread_active fails and keeps the interrupt disabled. Keep the thread_mask zero for !IRQ_ONESHOT interrupts. Document the thread_mask magic while at it. Reported-and-tested-by:
Sven Joachim <svenjoac@gmx.de> Reported-and-tested-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jean Delvare authored
commit 81b5482c upstream. The code is currently always checking the first resource of every device only (several times.) This has been broken since the ACPI check was added in February 2010 in commit 91fedede. Fix the check to run on each resource individually, once. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
H. Peter Anvin authored
commit 5189fa19 upstream. There is only one error code to return for a bad user-space buffer pointer passed to a system call in the same address space as the system call is executed, and that is EFAULT. Furthermore, the low-level access routines, which catch most of the faults, return EFAULT already. Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
Roland McGrath <roland@hack.frob.com> Signed-off-by:
-
H. Peter Anvin authored
commit c8e25258 upstream. The regset common infrastructure assumed that regsets would always have .get and .set methods, but not necessarily .active methods. Unfortunately people have since written regsets without .set methods. Rather than putting in stub functions everywhere, handle regsets with null .get or .set methods explicitly. Signed-off-by:
-
Takashi Iwai authored
commit 7bff172a upstream. A bug report with an old Sony laptop showed that we can't rely on BIOS setting the pins of headphones but the driver should set always by itself. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 3868137e upstream. Some codecs don't supply the mute amp-capabilities although the lowest volume gives the mute. It'd be handy if the parser provides the mute mixers in such a case. This patch adds an extension amp-cap bit (which is used only in the driver) to represent the min volume = mute state. Also modified the amp cache code to support the fake mute feature when this bit is set but the real mute bit is unset. In addition, conexant cx5051 parser uses this new feature to implement the missing mute controls. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42825Signed-off-by:
-
David Howells authored
commit 1d057720 upstream. Enable the compat keyctl wrapper on s390x so that 32-bit s390 userspace can call the keyctl() syscall. There's an s390x assembly wrapper that truncates all the register values to 32-bits and this then calls compat_sys_keyctl() - but the latter only exists if CONFIG_KEYS_COMPAT is enabled, and the s390 Kconfig doesn't enable it. Without this patch, 32-bit calls to the keyctl() syscall are given an ENOSYS error: [root@devel4 ~]# keyctl show Session Keyring -3: key inaccessible (Function not implemented) Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Cc: linux-s390@vger.kernel.org Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Jett.Zhou authored
commit 3380643b upstream. Signed-off-by:
Jett.Zhou <jtzhou@marvell.com> Signed-off-by:
-
Wolfram Sang authored
commit 844990da upstream. The hardware generates an interrupt for every completed command in the queue while the code assumed that it will only generate one interrupt when the queue is empty. So, explicitly check if the queue is really empty. This patch fixed problems which occurred due to high traffic on the bus. While we are here, move the completion-initialization after the parameter error checking. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by:
-
Maxim Uvarov authored
commit 97d2a10d upstream. 1. address has to be page aligned. 2. set_memory_x uses page size argument, not size. Bug causes with following commit: commit da28179b4e90dda56912ee825c7eaa62fc103797 Author: Mingarelli, Thomas <Thomas.Mingarelli@hp.com> Date: Mon Nov 7 10:59:00 2011 +0100 watchdog: hpwdt: Changes to handle NX secure bit in 32bit path commit e67d668e upstream. This patch makes use of the set_memory_x() kernel API in order to make necessary BIOS calls to source NMIs. Signed-off-by:
Maxim Uvarov <maxim.uvarov@oracle.com> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Roland Stigge authored
commit f6737055 upstream. The GPI_28 IRQ was not registered properly. The registration of IRQ_LPC32XX_GPI_28 was added and the (wrong) IRQ_LPC32XX_GPI_11 at LPC32XX_SIC1_IRQ(4) was replaced by IRQ_LPC32XX_GPI_28 (see manual of LPC32xx / interrupt controller). Signed-off-by:
Roland Stigge <stigge@antcom.de> Signed-off-by:
-
Roland Stigge authored
commit 35dd0a75 upstream. This patch fixes the initialization of the interrupt controller of the LPC32xx by correctly setting up SIC1 and SIC2 instead of (wrongly) using the same value as for the Main Interrupt Controller (MIC). Signed-off-by:
-
Roland Stigge authored
commit 94ed7830 upstream. This patch fixes the wakeup disable function by clearing latched events. Signed-off-by:
-
Roland Stigge authored
commit ff424aa4 upstream. This patch fixes a wrong loop limit on UART init. Signed-off-by:
-
Roland Stigge authored
commit 2707208e upstream. This patch fixes a HW bug by flushing RX FIFOs of the UARTs on init. It was ported from NXP's git.lpclinux.com tree. Signed-off-by:
-
Alban Browaeys authored
commit aed3f09d upstream. Before loading the lut (gamma), check the active state of intel_crtc, otherwise at least on gen2 hang ensue. This is reproducible in Xorg via: xset dpms force off then xgamma -rgamma 2.0 # freeze. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44505Signed-off-by:
Alban Browaeys <prahal@yahoo.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Heiko Carstens authored
commit 048cd4e5 upstream. The new is_compat_task() define for the !COMPAT case in include/linux/compat.h conflicts with a similar define in arch/s390/include/asm/compat.h. This is the minimal patch which fixes the build issues. Signed-off-by:
-
Linus Torvalds authored
commit 3c761ea0 upstream. The autofs compat handling fix caused a compile failure when CONFIG_COMPAT isn't defined. Instead of adding random #ifdef'fery in autofs, let's just make the compat helpers earlier to use: without CONFIG_COMPAT, is_compat_task() just hardcodes to zero. We could probably do something similar for a number of other cases where we have #ifdef's in code, but this is the low-hanging fruit. Reported-and-tested-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
-
Ian Kent authored
commit a32744d4 upstream. When the autofs protocol version 5 packet type was added in commit 5c0a32fc ("autofs4: add new packet type for v5 communications"), it obvously tried quite hard to be word-size agnostic, and uses explicitly sized fields that are all correctly aligned. However, with the final "char name[NAME_MAX+1]" array at the end, the actual size of the structure ends up being not very well defined: because the struct isn't marked 'packed', doing a "sizeof()" on it will align the size of the struct up to the biggest alignment of the members it has. And despite all the members being the same, the alignment of them is different: a "__u64" has 4-byte alignment on x86-32, but native 8-byte alignment on x86-64. And while 'NAME_MAX+1' ends up being a nice round number (256), the name[] array starts out a 4-byte aligned. End result: the "packed" size of the structure is 300 bytes: 4-byte, but not 8-byte aligned. As a result, despite all the fields being in the same place on all architectures, sizeof() will round up that size to 304 bytes on architectures that have 8-byte alignment for u64. Note that this is *not* a problem for 32-bit compat mode on POWER, since there __u64 is 8-byte aligned even in 32-bit mode. But on x86, 32-bit and 64-bit alignment is different for 64-bit entities, and as a result the structure that has exactly the same layout has different sizes. So on x86-64, but no other architecture, we will just subtract 4 from the size of the structure when running in a compat task. That way we will write the properly sized packet that user mode expects. Not pretty. Sadly, this very subtle, and unnecessary, size difference has been encoded in user space that wants to read packets of *exactly* the right size, and will refuse to touch anything else. Reported-and-tested-by:
Thomas Meyer <thomas@m3y3r.de> Signed-off-by:
Ian Kent <raven@themaw.net> Signed-off-by:
-
- 01 Mar, 2012 1 commit
-
-
Greg Kroah-Hartman authored
-
