- 16 Aug, 2011 40 commits
-
-
Daniel Mack authored
commit 1faa5d07 upstream. When creating the mixers for an USB audio device, the current code looks at the host interface stored in mixer->chip->ctrl_if. Change this and rather keep a local pointer to the interface that was given when snd_usb_create_mixer() was called. Signed-off-by:
Daniel Mack <zonque@gmail.com> Reported-by:
Nicolai Krakowiak <nicolai.krakowiak@gmail.com> Reported-by:
Lean-Yves LENHOF <jean-yves@lenhof.eu.org> Acked-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Nicolai Krakowiak authored
commit 60c961a9 upstream. Signed-off-by:
-
Daniel Mack authored
commit f4389489 upstream. Signed-off-by:
Renato <naretobh@gmail.com> Signed-off-by:
-
Takashi Iwai authored
commit 0584ffa5 upstream. A slave-timer instance has no timer reference, and this results in NULL-dereference at stopping the timer, typically called at closing the device. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=40682Signed-off-by:
-
Wolfram Sang authored
commit 151798f8 upstream. Cache handling in this driver is broken. The chip has 16-bit registers, yet the register numbers also increase by 2 per register, i.e. there are only even-numbered registers. The cache in this driver, though, simply increments register numbers, so it does need some mapping as seen in sgtl5000_restore_regs(), note the '>> 1': snd_soc_write(codec, SGTL5000_CHIP_LINREG_CTRL, cache[SGTL5000_CHIP_LINREG_CTRL >> 1]); That, of course, won't work with snd_soc_update_bits(). (Thus, we won't even notice the missing register 0x1c in the default regs which shifted all follwing registers to wrong values.) Noticed on the MX28EVK where enabling the regulators simply locked up the chip. Refactor the routines and use a properly sized default_regs array which matches the register layout of the underlying chip, i.e. create a truly flat cache. This also saves some code which should make up for the bigger array a little. When soc-core will somewhen have another cache type which handles a step size, this conversion will also ease the transition. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Tested-by:
Dong Aisheng <b29396@freescale.com> Tested-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Jeff Layton authored
commit f9e8c450 upstream. Regression from 2.6.39... The delimiters in the prefixpath are not being converted based on whether posix paths are in effect. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=727834Reported-and-Tested-by:
Iain Arnell <iarnell@gmail.com> Reported-by:
Patrick Oltmann <patrick.oltmann@gmx.net> Cc: Pavel Shilovsky <piastryyy@gmail.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Jeff Layton authored
commit 80975d21 upstream. The loop around lookup_one_len doesn't handle the case where it might return a negative dentry, which can cause an oops on the next pass through the loop. Check for that and break out of the loop with an error of -ENOENT if there is one. Fixes the panic reported here: https://bugzilla.redhat.com/show_bug.cgi?id=727927Reported-by:
TR Bentley <home@trarbentley.net> Reported-by:
-
Pavel Shilovsky authored
commit 0193e072 upstream. if we failed on getting mid entry in cifs_call_async. Signed-off-by:
Pavel Shilovsky <piastryyy@gmail.com> Signed-off-by:
-
Corentin Chary authored
commit 3df5fdad upstream. Signed-off-by:
Corentin Chary <corentin.chary@gmail.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Corentin Chary authored
commit 49979d09 upstream. The code was completly broken, and should never had been sent to the kernel. That's what happens when you write code without hardware to test it. Signed-off-by:
-
David S. Miller authored
Computers have become a lot faster since we compromised on the partial MD4 hash which we use currently for performance reasons. MD5 is a much safer choice, and is inline with both RFC1948 and other ISS generators (OpenBSD, Solaris, etc.) Furthermore, only having 24-bits of the sequence number be truly unpredictable is a very serious limitation. So the periodic regeneration and 8-bit counter have been removed. We compute and use a full 32-bit sequence number. For ipv6, DCCP was found to use a 32-bit truncated initial sequence number (it needs 43-bits) and that is fixed here as well. Reported-by:
Dan Kaminsky <dan@doxpara.com> Tested-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
We are going to use this for TCP/IP sequence number and fragment ID generation. Signed-off-by:
-
Keith Packard authored
commit 40ee3381 upstream. drm_helper_hpd_irq_event queues another work proc to go and deliver the user-space event, and that function also wants to hold the config mutex, so we shouldn't hold the mutex across the drm_helper_hpd_irq_event call. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Keith Packard authored
commit a65e34c7 upstream. Hotplug detection is a mode setting operation and must hold the struct_mutex or risk colliding with other mode setting operations. In particular, the display port hotplug function attempts to re-train the link if the monitor is supposed to be running when plugged back in. If that happens while mode setting is underway, the link will get scrambled, leaving it in an inconsistent state. This is a special case -- usually the driver mode setting entry points are covered by the upper level DRM code, but in this case the function is invoked as a work function not under the control of DRM. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Keith Packard authored
commit f3234706 upstream. Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring->status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by:
-
Ole Henrik Jahren authored
commit 842d4529 upstream. Because of a typo, calling ioctl with DRM_IOCTL_I915_OVERLAY_PUT_IMAGE is broken if the macro is used directly. When using libdrm the bug is not hit, since libdrm handles the ioctl encoding internally. The typo also leads to the .cmd and .cmd_drv fields of the drm_ioctl structure for DRM_I915_OVERLAY_PUT_IMAGE having inconsistent content. Signed-off-by:
Ole Henrik Jahren <olehenja@alumni.ntnu.no> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jesse Barnes authored
commit 9c54c0dd upstream. Per the specs and to address https://bugs.freedesktop.org/show_bug.cgi?id=36888. Signed-off-by:
-
Adam Jackson authored
commit 302983e9 upstream. Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect. The old math would give you: scaled_width = 1600 * 768; /* 1228800 */ scaled_height = 1360 * 900; /* 1224000 */ if (scaled_width > scaled_height) { /* pillarbox, and true */ width = 1224000 / 768; /* int(1593.75) = 1593 */ x = (1600 - 1593 + 1) / 2; /* 4 */ y = 0; height = 768; } /* ... */ This is broken. The total width of scanout would then be 1593 + 4 + 4, or 1601, which is wider than the panel itself. The hardware very dutifully implements this, and you end up with a black 45° diagonal from the top-left corner to the bottom edge of the screen. It's a cool effect and all, but not what you wanted. Similar things happen for the letterbox case. The problem is that you have an integer number of pixels, which means it's usually impossible to upscale equally on both axes. 1360/768 is 1.7708, 1600/900 is 1.7777. Since we're constrained on the one axis, the other one wants to come out as an even number of pixels (the panel is almost certainly even on both axes, and the x/y offsets will be applied on both sides). In the math above, if 'width' comes out even, rounding down is correct; if it's odd, you'd rather round up. So just increment width/height in those cases. Tested on a Lenovo T500 (Ironlake). Signed-off-by:
Adam Jackson <ajax@redhat.com> Tested-By:
Daniel Manrique <daniel.manrique@canonical.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Thomas Reim authored
commit d522d9cc upstream. Log PCI subsystem vendor and subsystem device ID in addition to PCI vendor and device ID during kernel mode initialisation. This helps to better identify radeon devices of third-party vendors, e. g. for bug analysis. Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board Signed-off-by:
Thomas Reim <reimth@gmail.com> Reviewed-by:
Alex Deucher <alexdeucher@gmail.com> Acked-by:
Stephen Michaels <Stephen.Micheals@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Thomas Reim authored
commit a81b31e9 upstream. ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus for a DVI connector that is not implemented/existent on the board. Fix by applying extented DDC probing for this connector. Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines Tested for kernel 2.6.38 on Asus ECS A740GM-M board BugLink: http://bugs.launchpad.net/bugs/810926Signed-off-by:
-
Thomas Reim authored
drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines (here: Asus M2A-VM HDMI) commit e384fab8 upstream. Some integrated ATI Radeon chipset implementations with add-on HDMI card (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even when the add-on card is not plugged in or HDMI is disabled in BIOS setup. In this case, drm_get_edid() and drm_edid_block_valid() periodically dump data and kernel errors into system log files and onto terminals. For these connectors DDC probing is extended by a check for a correct EDID header. Only in case a valid EDID header is also found, the (HDMI or DVI) connector will be used by the Radeon driver. This prevents the kernel driver from useless flooding of logs and terminal sessions with EDID dumps and error messages. This patch adds a flag 'requires_extended_probe' to the radeon_connector structure. In function radeon_connector_needs_extended_probe() this flag can be set on a chipset family/vendor/connector type specific basis. In addition, function radeon_ddc_probe() has been adapted to perform extended DDC probing if required by the connector's flag. Requires function drm_edid_header_is_valid() in DRM module provided by [PATCH] drm: Separate EDID Header Check from EDID Block Check. Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196 BugLink: http://bugs.launchpad.net/bugs/7228066Signed-off-by:
-
Thomas Reim authored
commit 051963d4 upstream. Provides function drm_edid_header_is_valid() for EDID header check and replaces EDID header check part of function drm_edid_block_valid() by a call of drm_edid_header_is_valid(). This is a prerequisite to extend DDC probing, e. g. in function radeon_ddc_probe() for Radeon devices, by a central EDID header check. Tested for kernel 2.6.35, 2.6.38 and 3.0 Signed-off-by:
-
Jeremy Fitzhardinge authored
commit c2419b4a upstream. Get the information about the VGA console hardware from Xen, and put it into the form the bootloader normally generates, so that the rest of the kernel can deal with VGA as usual. [ Impact: make VGA console work in dom0 ] Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> [v1: Rebased on 2.6.39] [v2: Removed incorrect comments and fixed compile warnings] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Tetsuo Handa authored
commit c71d8ebe upstream. The sendmmsg() introduced by commit 228e548e "net: Add sendmmsg socket system call" is capable of sending to multiple different destination addresses. SMACK is using destination's address for checking sendmsg() permission. However, security_socket_sendmsg() is called for only once even if multiple different destination addresses are passed to sendmmsg(). Therefore, we need to call security_socket_sendmsg() for each destination address rather than only the first destination address. Since calling security_socket_sendmsg() every time when only single destination address was passed to sendmmsg() is a waste of time, omit calling security_socket_sendmsg() unless destination address of previous datagram and that of current datagram differs. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Acked-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
commit 98382f41 upstream. To limit the amount of time we can spend in sendmmsg, cap the number of elements to UIO_MAXIOV (currently 1024). For error handling an application using sendmmsg needs to retry at the first unsent message, so capping is simpler and requires less application logic than returning EINVAL. Signed-off-by:
-
Anton Blanchard authored
commit 728ffb86 upstream. sendmmsg uses a similar error return strategy as recvmmsg but it turns out to be a confusing way to communicate errors. The current code stores the error code away and returns it on the next sendmmsg call. This means a call with completely valid arguments could get an error from a previous call. Change things so we only return an error if no datagrams could be sent. If less than the requested number of messages were sent, the application must retry starting at the first failed one and if the problem is persistent the error will be returned. This matches the behaviour of other syscalls like read/write - it is not an error if less than the requested number of elements are sent. Signed-off-by:
-
Stanislaw Gruszka authored
commit d4930086 upstream. We receive many bug reports about system hang during suspend/resume when ath9k driver is in use. Adrian Chadd remarked that this problem happens on systems that have ASPM disabled. To do not hit the bug, skip doing ->config_pci_powersave magic if PCIe downstream port device, which ath9k device is connected to, has ASPM disabled. Bug was introduced by: commit 53bc7aa0 Author: Vivek Natarajan <vnatarajan@atheros.com> Date: Mon Apr 5 14:48:04 2010 +0530 ath9k: Add support for newer AR9285 chipsets. Patch should address: https://bugzilla.kernel.org/show_bug.cgi?id=37462 https://bugzilla.kernel.org/show_bug.cgi?id=37082 https://bugzilla.redhat.com/show_bug.cgi?id=697157 however I did not receive confirmation about that, except from Camilo Mesias, whose system stops hang regularly with this patch (but still hangs from time to time, but this is probably some other bug). Tested-by:
Camilo Mesias <camilo@mesias.co.uk> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felix Fietkau authored
commit c1227340 upstream. With an uninitialized chainmask, the per-channel power will only contain the power limits for a single chain instead of the combined tx power. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit 17e859a8 upstream. If settings of tx power was deferred during scan or changing channel we have to setup them during commit rxon. Fix problem on 3945 (4965 already has this fix). Optimize code to apply tx settings only when tx power was actually changed. Signed-off-by:
-
Larry Finger authored
commit b6b67df3 upstream. This driver uses information from the self member of the pci_bus struct to get information regarding the bridge to which the PCIe device is attached. Unfortunately, this member is not established on all architectures, which leads to a kernel oops. Skipping the entire block that uses the self member to determine the bridge vendor will only affect RTL8192DE devices as that driver sets the ASPM support flag differently when the bridge vendor is Intel. If the self member is available, there is no functional change. This patch fixes Bugzilla No. 40212. Reported-by:
Hubert Liao <liao.hubertt@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Stanislaw Gruszka authored
commit 00898a47 upstream. We may call rt2x00queue_pause_queue(queue) with queue == NULL. Bug was introduced by commit 62fe7784 "rt2x00: Fix stuck queue in tx failure case" . Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Acked-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit b52398b6 upstream. We should clear skb->data not skb itself. Bug was introduced by: commit 0b8004aa "rt2x00: Properly reserve room for descriptors in skbs". Signed-off-by:
-
John David Anglin authored
commit 548c210f upstream. The return type of __atomic64_add_return of should be s64 or long, not int. This fixes the atomic64 test failure that I previously reported. Signed-off-by:
John David Anglin <dave.anglin@nrc-cnrc.gc.ca> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Carlos O'Donell authored
commit d9ba5fe7 upstream. Implements futex op support and makes futex cmpxchg atomic. Tested on 64-bit SMP kernel running on 2 x PA8700s. [jejb: checkpatch fixes] Signed-off-by:
Carlos O'Donell <carlos@systemhalted.org> Tested-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
-
James Bottomley authored
commit 205e9a21 upstream. Signed-off-by:
-
Shawn Bohrer authored
commit 9ea71503 upstream. commit 7485d0d3 (futexes: Remove rw parameter from get_futex_key()) in 2.6.33 fixed two problems: First, It prevented a loop when encountering a ZERO_PAGE. Second, it fixed RW MAP_PRIVATE futex operations by forcing the COW to occur by unconditionally performing a write access get_user_pages_fast() to get the page. The commit also introduced a user-mode regression in that it broke futex operations on read-only memory maps. For example, this breaks workloads that have one or more reader processes doing a FUTEX_WAIT on a futex within a read only shared file mapping, and a writer processes that has a writable mapping issuing the FUTEX_WAKE. This fixes the regression for valid futex operations on RO mappings by trying a RO get_user_pages_fast() when the RW get_user_pages_fast() fails. This change makes it necessary to also check for invalid use cases, such as anonymous RO mappings (which can never change) and the ZERO_PAGE which the commit referenced above was written to address. This patch does restore the original behavior with RO MAP_PRIVATE mappings, which have inherent user-mode usage problems and don't really make sense. With this patch performing a FUTEX_WAIT within a RO MAP_PRIVATE mapping will be successfully woken provided another process updates the region of the underlying mapped file. However, the mmap() man page states that for a MAP_PRIVATE mapping: It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region. So user-mode users attempting to use futex operations on RO MAP_PRIVATE mappings are depending on unspecified behavior. Additionally a RO MAP_PRIVATE mapping could fail to wake up in the following case. Thread-A: call futex(FUTEX_WAIT, memory-region-A). get_futex_key() return inode based key. sleep on the key Thread-B: call mprotect(PROT_READ|PROT_WRITE, memory-region-A) Thread-B: write memory-region-A. COW happen. This process's memory-region-A become related to new COWed private (ie PageAnon=1) page. Thread-B: call futex(FUETX_WAKE, memory-region-A). get_futex_key() return mm based key. IOW, we fail to wake up Thread-A. Once again doing something like this is just silly and users who do something like this get what they deserve. While RO MAP_PRIVATE mappings are nonsensical, checking for a private mapping requires walking the vmas and was deemed too costly to avoid a userspace hang. This Patch is based on Peter Zijlstra's initial patch with modifications to only allow RO mappings for futex operations that need VERIFY_READ access. Reported-by:
David Oliver <david@rgmadvisors.com> Signed-off-by:
Shawn Bohrer <sbohrer@rgmadvisors.com> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: peterz@infradead.org Cc: eric.dumazet@gmail.com Cc: zvonler@rgmadvisors.com Cc: hughd@google.com Link: http://lkml.kernel.org/r/1309450892-30676-1-git-send-email-sbohrer@rgmadvisors.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
WANG Cong authored
commit 1646ec9d upstream. Fix: arch/cris/arch-v10/kernel/irq.c:239: error: implicit declaration of function 'kgdb_init' arch/cris/arch-v10/kernel/irq.c:240: error: implicit declaration of function 'breakpoint' Declare these two functions. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
WANG Cong <xiyou.wangcong@gmail.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
WANG Cong authored
commit b4bc2812 upstream. Fix: arch/cris/arch-v10/drivers/sync_serial.c:961: error: conflicting types for 'sync_serial_ioctl' Reported-by:
-
WANG Cong authored
commit 4b851d88 upstream. Fix: arch/cris/arch-v10/drivers/sync_serial.c:628: error: 'ret' undeclared (first use in this function) 'ret' should be 'err'. Reported-by:
-
WANG Cong authored
commit d4969213 upstream. Fix this error: kernel/fork.c:267: error: implicit declaration of function 'alloc_thread_info_node' This is due to renaming alloc_thread_info() to alloc_thread_info_node(). [akpm@linux-foundation.org: coding-style fixes] Reported-by:
-
