- 12 Mar, 2012 39 commits
-
-
Steffen Maier authored
commit 7b3cc67d upstream. Git commit 25f269f1 "[S390] qdio: EQBS retry after CCQ 96" introduced a regression in regard to the zfcp data router. Revoke the incorrect simplification of the function call arguments for the qdio handler to make the zfcp hardware data router working again. This is applicable to 3.2+ kernels. Signed-off-by:
Steffen Maier <maier@linux.vnet.ibm.com> Reviewed-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Rothwell authored
commit f21c6d4a upstream. Fixes these build errors: ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined! ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined! ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined! Cc: Timur Tabi <timur@freescale.com> Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Johannes Berg authored
commit 5dcbf480 upstream. When trying to remove a key, we always send key flags just setting the key type, not including the multicast flag and the key ID. As a result, whenever any key was removed, the unicast key 0 would be removed, causing a complete connection loss after the second rekey (the first doesn't cause a key removal). Fix the key removal code to include the key ID and multicast flag, thus removing the correct key. Reported-by:
Alexander Schnaidt <alex.schnaidt@googlemail.com> Tested-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> 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:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Prashanth Nageshappa authored
commit f986a499 upstream. register_kprobe() aborts if the address of the new request falls in a prohibited area (such as ftrace pouch, __kprobes annotated functions, non-kernel text addresses, jump label text). We however don't return the right error on this abort, resulting in a silent failure - incorrect adding/reporting of kprobes ('perf probe do_fork+18' or 'perf probe mcount' for instance). In V2 we are incorporating Masami Hiramatsu's feedback. This patch fixes it by returning -EINVAL upon failure. While we are here, rename the label used for exit to be more appropriate. Signed-off-by:
Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by:
Prashanth K Nageshappa <prashanth@linux.vnet.ibm.com> Acked-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Jason Baron <jbaron@redhat.com> Signed-off-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:
-
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:
-
Jeff Moyer authored
commit 880641bb upstream. Bart Van Assche reported a hung fio process when either hot-removing storage or when interrupting the fio process itself. The (pruned) call trace for the latter looks like so: fio D 0000000000000001 0 6849 6848 0x00000004 ffff880092541b88 0000000000000046 ffff880000000000 ffff88012fa11dc0 ffff88012404be70 ffff880092541fd8 ffff880092541fd8 ffff880092541fd8 ffff880128b894d0 ffff88012404be70 ffff880092541b88 000000018106f24d Call Trace: schedule+0x3f/0x60 io_schedule+0x8f/0xd0 wait_for_all_aios+0xc0/0x100 exit_aio+0x55/0xc0 mmput+0x2d/0x110 exit_mm+0x10d/0x130 do_exit+0x671/0x860 do_group_exit+0x44/0xb0 get_signal_to_deliver+0x218/0x5a0 do_signal+0x65/0x700 do_notify_resume+0x65/0x80 int_signal+0x12/0x17 The problem lies with the allocation batching code. It will opportunistically allocate kiocbs, and then trim back the list of iocbs when there is not enough room in the completion ring to hold all of the events. In the case above, what happens is that the pruning back of events ends up freeing up the last active request and the context is marked as dead, so it is thus responsible for waking up waiters. Unfortunately, the code does not check for this condition, so we end up with a hung task. Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Reported-by:
Bart Van Assche <bvanassche@acm.org> Tested-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:
Sascha Hauer <s.hauer@pengutronix.de> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Chris Ball <cjb@laptop.org> Signed-off-by:
-
Ludovic Desroches authored
commit ef878198 upstream. Some callbacks are set too early -- i.e. we can have dma capabilities but we can't get a dma channel. So wait to get the dma channel before setting callbacks and change logs consequently. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> 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:
-
Mark Brown authored
commit e7c248a0 upstream. The jack detection on WM1811 is often required during system suspend, add it as another check when deciding if we should suspend. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> 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:
-
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:
-
Takashi Iwai authored
commit 068b9394 upstream. When there are multiple input sources, the driver wrongly overwrites with the value of the last input source on other slots at resume. Thus the primary input source may be shown wrongly. Reported-and-tested-by:
Julian Sikorski <belegdol@gmail.com> Signed-off-by:
-
Joerg Roedel authored
commit 1018faa6 upstream. It turned out that a performance counter on AMD does not count at all when the GO or HO bit is set in the control register and SVM is disabled in EFER. This patch works around this issue by masking out the HO bit in the performance counter control register when SVM is not enabled. The GO bit is not touched because it is only set when the user wants to count in guest-mode only. So when SVM is disabled the counter should not run at all and the not-counting is the intended behaviour. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Avi Kivity <avi@redhat.com> Cc: Stephane Eranian <eranian@google.com> Cc: David Ahern <dsahern@gmail.com> Cc: Gleb Natapov <gleb@redhat.com> Cc: Robert Richter <robert.richter@amd.com> Link: http://lkml.kernel.org/r/1330523852-19566-1-git-send-email-joerg.roedel@amd.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-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:
-
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-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:
-
Ohad Ben-Cohen authored
commit 435792d9 upstream. omap3isp depends on omap's iommu and will fail to probe if initialized before it (which always happen if they are builtin). Make omap's iommu subsys_initcall as an interim solution until the probe deferral mechanism is merged. Reported-by:
James <angweiyang@gmail.com> Debugged-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Ohad Ben-Cohen <ohad@wizery.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Hiroshi Doyu <hdoyu@nvidia.com> Cc: Joerg Roedel <Joerg.Roedel@amd.com> Signed-off-by:
-
- 01 Mar, 2012 1 commit
-
-
Greg Kroah-Hartman authored
-
