- 09 Dec, 2011 17 commits
-
-
Felipe Balbi authored
commit 5a4f1844 upstream. Fix a bug which has been on this driver since it was added by the original commit 984aa6db which would never clear IRQSTATUS bits. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Kevin Hilman <khilman@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wolfram Sang authored
commit c2735391 upstream. reg | (1 << clk->enable_shift) always evaluates to true. Switch it to & which makes much more sense. Same fix as 13be9f00 (ARM i.MX28: fix bit operation) at a different location. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Shawn Guo <shawn.guo@freescale.com> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Haojian Zhuang authored
commit c0a39151 upstream. Since CONFIG_USB_GADGET_PXA27X and other macros are renamed to CONFIG_USB_PXA27X. Update them in arch/arm/mach-pxa and arch/arm/configs to keep consistent. Signed-off-by:
Haojian Zhuang <haojian.zhuang@marvell.com> Acked-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
-
Daniel Drake authored
commit a3283969 upstream. While the OLPC display appears to be able to handle either positive or negative sync, the Display Controller only recognises positive sync. This brings viafb (for XO-1.5) in line with lxfb (for XO-1) and fixes a recent regression where the XO-1.5 DCON could no longer be frozen. Thanks to Florian Tobias Schandinat for helping identify the fix. Test case: from a vt, echo 1 > /sys/devices/platform/dcon/freeze should cause the current screen contents to freeze, rather than garbage being displayed. Signed-off-by:
Daniel Drake <dsd@laptop.org> Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
-
Alex Deucher authored
commit 6c47e5c2 upstream. Fixes i2c test failures when i2c_algo_bit.bit_test=1. The hw doesn't actually require a mask, so just set it to the default mask bits for r1xx-r4xx radeon ddc. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Bjorn Helgaas authored
commit 4cac2eb1 upstream. Previously we claimed device ID 0x7450, regardless of the vendor, which is clearly wrong. Now we'll claim that device ID only for AMD. I suspect this was just a typo in the original code, but it's possible this change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix them as we find them. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863Reported-by:
Ralf Jung <ralfjung-e@gmx.de> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Barnes authored
commit cb0e0931 upstream. CB tuning is needed to handle potential process variations that might cause clock jitter for certain PLL settings. However, we were setting it incorrectly since we were using the wrong M value as a check (M1 when we needed to use the whole M value). Fix it up, making my HDMI attached display a little prettier (used to have occasional dots crawl across the display). Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
Timo Aaltonen <timo@canonical.com> Signed-off-by:
-
Ben Skeggs authored
commit ff02b13f upstream. Fixes an information leak to userspace, we were handing out un-zeroed pages for any newly created TTM_PL_TT buffer. Reported-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Tested-by:
-
Eric Anholt authored
commit 9ca1d10d upstream. Unlike the previous one, I don't have known testcases it fixes. I'd rather not go through the same debug cycle on whatever testcases those might be. Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Eric Anholt authored
commit 406478dc upstream. Fixes rendering failures in Unigine Tropics and Sanctuary and the mesa "fire" demo. Signed-off-by:
-
Daniel Vetter authored
commit 775d17b6 upstream. So don't forget to restore them on resume and dump them into the error state. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Alex Deucher authored
commit d724502a upstream. Fixes i2c test failures when i2c_algo_bit.bit_test=1. The hw doesn't actually require a mask, so just set it to the default mask bits for r1xx-r4xx radeon ddc. I missed this part the first time through. Signed-off-by:
-
Xi Wang authored
commit a5cd3351 upstream. There is a potential integer overflow in drm_mode_dirtyfb_ioctl() if userspace passes in a large num_clips. The call to kmalloc would allocate a small buffer, and the call to fb->funcs->dirty may result in a memory corruption. Reported-by:
Haogang Chen <haogangchen@gmail.com> Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
-
Phil Sutter authored
commit 27425286 upstream. This was broken by commit 7759995c (yes, myself). The basic problem here is since the digest state is only saved after the last chunk, the state array is only valid when handling the first chunk of the next buffer. Broken since linux-3.0. Signed-off-by:
Phil Sutter <phil.sutter@viprinet.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Tyler Hicks authored
commit 0f751e64 upstream. From mhalcrow's original commit message: Characters with ASCII values greater than the size of filename_rev_map[] are valid filename characters. ecryptfs_decode_from_filename() will access kernel memory beyond that array, and ecryptfs_parse_tag_70_packet() will then decrypt those characters. The attacker, using the FNEK of the crafted file, can then re-encrypt the characters to reveal the kernel memory past the end of the filename_rev_map[] array. I expect low security impact since this array is statically allocated in the text area, and the amount of memory past the array that is accessible is limited by the largest possible ASCII filename character. This patch solves the issue reported by mhalcrow but with an implementation suggested by Linus to simply extend the length of filename_rev_map[] to 256. Characters greater than 0x7A are mapped to 0x00, which is how invalid characters less than 0x7A were previously being handled. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Reported-by:
Michael Halcrow <mhalcrow@google.com> Signed-off-by:
-
Jeffrey (Sheng-Hui) Chu authored
commit cc6bcf7d upstream. The wrong bits were put on the wire, fix that. This fixes kernel bug #42562. Signed-off-by:
Sheng-Hui J. Chu <jeffchu@broadcom.com> Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Tyler Hicks authored
commit 32001d6f upstream. Dirty pages weren't being written back when an mmap'ed eCryptfs file was closed before the mapping was unmapped. Since f_ops->flush() is not called by the munmap() path, the lower file was simply being released. This patch flushes the eCryptfs file in the vm_ops->close() path. https://launchpad.net/bugs/870326Signed-off-by:
-
- 28 Nov, 2011 2 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit 317451c1. Cc: Matthieu Castet <matthieu.castet@parrot.com> Cc: Thomas Poussevin <thomas.poussevin@parrot.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
- 26 Nov, 2011 21 commits
-
-
Greg Kroah-Hartman authored
-
Jesse Barnes authored
commit c4f9c4c2 upstream. It's needed for 3 pipe support as well as just regular functionality (e.g. DisplayPort). Signed-off-by:
Adam Jackson <ajax@redhat.com> Tested-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Robert Hooker <robert.hooker@canonical.com> Signed-off-by:
-
Jesse Barnes authored
commit 65a21cd6 upstream. The cursor regs have moved around, add the offsets and new macros for getting at them. Signed-off-by:
-
Christoph Hellwig authored
patch 58d84c4e upstream. Currently we always redirty an inode that was attempted to be written out synchronously but has been cleaned by an AIL pushed internall, which is rather bogus. Fix that by doing the i_update_core check early on and return 0 for it. Also include async calls for it, as doing any work for those is just as pointless. While we're at it also fix the sign for the EIO return in case of a filesystem shutdown, and fix the completely non-sensical locking around xfs_log_inode. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Alex Elder <aelder@sgi.com> Signed-off-by:
-
Mitsuo Hayasaka authored
commit db3e74b5 upstream The doalloc arg in xfs_qm_dqattach_one() is a flag that indicates whether a new area to handle quota information will be allocated if needed. Originally, it was passed to xfs_qm_dqget(), but has been removed by the following commit (probably by mistake): commit 8e9b6e7f Author: Christoph Hellwig <hch@lst.de> Date: Sun Feb 8 21:51:42 2009 +0100 xfs: remove the unused XFS_QMOPT_DQLOCK flag As the result, xfs_qm_dqget() called from xfs_qm_dqattach_one() never allocates the new area even if it is needed. This patch gives the doalloc arg to xfs_qm_dqget() in xfs_qm_dqattach_one() to fix this problem. Signed-off-by:
Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> Cc: Alex Elder <aelder@sgi.com> Cc: Christoph Hellwig <hch@infradead.org> Reviewed-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
-
Carlos Maiolino authored
commit b52a360b upstream. Fixes a possible memory corruption when the link is larger than MAXPATHLEN and XFS_DEBUG is not enabled. This also remove the S_ISLNK assert, since the inode mode is checked previously in xfs_readlink_by_handle() and via VFS. Updated to address concerns raised by Ben Hutchings about the loose attention paid to 32- vs 64-bit values, and the lack of handling a potentially negative pathlen value: - Changed type of "pathlen" to be xfs_fsize_t, to match that of ip->i_d.di_size - Added checking for a negative pathlen to the too-long pathlen test, and generalized the message that gets reported in that case to reflect the change As a result, if a negative pathlen were encountered, this function would return EFSCORRUPTED (and would fail an assertion for a debug build)--just as would a too-long pathlen. Signed-off-by:
Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by:
-
Christoph Hellwig authored
commit 87c7bec7 upstream. The code to flush buffers in the umount code is a bit iffy: we first flush all delwri buffers out, but then might be able to queue up a new one when logging the sb counts. On a normal shutdown that one would get flushed out when doing the synchronous superblock write in xfs_unmountfs_writesb, but we skip that one if the filesystem has been shut down. Fix this by moving the delwri list flushing until just before unmounting the log, and while we're at it also remove the superflous delwri list and buffer lru flusing for the rt and log device that can never have cached or delwri buffers. Signed-off-by:
Amit Sahrawat <amit.sahrawat83@gmail.com> Tested-by:
-
Mitsuo Hayasaka authored
commit ed32201e upstream. An attribute of inode can be fetched via xfs_vn_getattr() in XFS. Currently it returns EIO, not negative value, when it failed. As a result, the system call returns not negative value even though an error occured. The stat(2), ls and mv commands cannot handle this error and do not work correctly. This patch fixes this bug, and returns -EIO, not EIO when an error is detected in xfs_vn_getattr(). Signed-off-by:
-
Christoph Hellwig authored
commit c58cb165 upstream. Currently a buffered reader or writer can add pages to the pagecache while we are waiting for the iolock in xfs_file_dio_aio_write. Prevent this by re-checking mapping->nrpages after we got the iolock, and if nessecary upgrade the lock to exclusive mode. To simplify this a bit only take the ilock inside of xfs_file_aio_write_checks. Signed-off-by:
-
Dave Chinner authored
commit 0c38a251 upstream. There is no need to grab the i_mutex of the IO lock in exclusive mode if we don't need to invalidate the page cache. Taking these locks on every direct IO effective serialises them as taking the IO lock in exclusive mode has to wait for all shared holders to drop the lock. That only happens when IO is complete, so effective it prevents dispatch of concurrent direct IO reads to the same inode. Fix this by taking the IO lock shared to check the page cache state, and only then drop it and take the IO lock exclusively if there is work to be done. Hence for the normal direct IO case, no exclusive locking will occur. Signed-off-by:
Joern Engel <joern@logfs.org> Reviewed-by:
-
Christoph Hellwig authored
commit 866e4ed7 upstream. During umount we do not add a dirty inode to the lru and wait for it to become clean first, but force writeback of data and metadata with I_WILL_FREE set. Currently there is no way for XFS to detect that the inode has been redirtied for metadata operations, as we skip the mark_inode_dirty call during teardown. Fix this by setting i_update_core nanually in that case, so that the inode gets flushed during inode reclaim. Alternatively we could enable calling mark_inode_dirty for inodes in I_WILL_FREE state, and let the VFS dirty tracking handle this. I decided against this as we will get better I/O patterns from reclaim compared to the synchronous writeout in write_inode_now, and always marking the inode dirty in some way from xfs_mark_inode_dirty is a better safetly net in either case. Signed-off-by:
-
Christoph Hellwig authored
If removed storage while synchronous buffer write underway, "xfslogd" hangs. Detailed log http://oss.sgi.com/archives/xfs/2011-07/msg00740.html Related work bfc60177 "xfs: fix error handling for synchronous writes" Given that xfs_bwrite actually does the shutdown already after waiting for the b_iodone completion and given that we actually found that calling xfs_force_shutdown from inside xfs_buf_iodone_callbacks was a major contributor the problem it better to drop this call. Signed-off-by:
Ajeet Yadav <ajeet.yadav.77@gmail.com> Reviewed-by:
-
sordna authored
commit 0d145d7d upstream. The following patch contains additional affected webcam models, on top of the patches commited to linux-next 2394d67e and 5b253d88Signed-off-by:
sordna <sordna@gmail.com> Cc: Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Josh Boyer authored
commit 60c71ca9 upstream. We've had another report of the "chipmunk" sound on a Logitech C600 webcam. This patch resolves the issue. Signed-off-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Thomas Poussevin authored
commit 811c926c upstream. The current TT scheduling doesn't allow to play and then record on a full-speed device connected to a high speed hub. The IN iso stream can only start on the first uframe (0-2 for a 165 us) because of CSPLIT transactions. For the OUT iso stream there no such restriction. uframe 0-5 are possible. The idea of this patch is that the first uframe are precious (for IN TT iso stream) and we should allocate the last uframes first if possible. For that we reverse the order of uframe allocation (last uframe first). Here an example : hid interrupt stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ---------------------------------------------------------------------- iso OUT stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 125 | 39 | 0 | 0 | 0 | 0 | 0 | ---------------------------------------------------------------------- There no place for iso IN stream (uframe 0-2 are used) and we got "cannot submit datapipe for urb 0, error -28: not enough bandwidth" error. With the patch this become. iso OUT stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 39 | 0 | 0 | ---------------------------------------------------------------------- iso IN stream ---------------------------------------------------------------------- uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | ---------------------------------------------------------------------- max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 | ---------------------------------------------------------------------- used usecs on a frame | 13 | 0 | 125 | 40 | 125 | 39 | 0 | 0 | ---------------------------------------------------------------------- Signed-off-by:
Matthieu Castet <matthieu.castet@parrot.com> Signed-off-by:
Thomas Poussevin <thomas.poussevin@parrot.com> Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit 2f640bf4 upstream. The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands; shorter commands must be padded. Simon Detheridge reports that his 3-TB USB disk drive claims to use the 8020i protocol (which is normally meant for ATAPI devices like CD drives), and because of its large size, the disk drive requires the use of 16-byte commands. However the usb_stor_pad12_command() routine in usb-storage always sets the command length to 12, making the drive impossible to use. Since the SFF-8020i specification allows for 16-byte commands in future extensions, we may as well accept them. This patch (as1490) changes usb_stor_pad12_command() to leave commands larger than 12 bytes alone rather than truncating them. Signed-off-by:
Simon Detheridge <simon@widgit.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by:
-
Andrew Worsley authored
commit b1ffb4c8 upstream. Fix for ftdi_set_termios() glitching output ftdi_set_termios() is constantly setting the baud rate, data bits and parity unnecessarily on every call, . When called while characters are being transmitted can cause the FTDI chip to corrupt the serial port bit stream output by stalling the output half a bit during the output of a character. Simple fix by skipping this setting if the baud rate/data bits/parity are unchanged. Signed-off-by:
Andrew Worsley <amworsley@gmail.com> Signed-off-by:
-
Bart Hartgers authored
commit 583182ba upstream. This patch for the usb serial ark3116 driver fixes an initialisation ordering bug that gets triggered on hotplug when using at least recent debian/ubuntu userspace. Without it, ark3116 serial cables don't work. Signed-off-by:
Bart Hartgers <bart.hartgers@gmail.com> Tested-by: law_ence.dev@ntlworld.com Signed-off-by:
-
Alan Stern authored
commit 97ff22ee upstream. This patch (as1491) works around a bug in GCC-3.4.6, which is still supposed to be supported. The number of microseconds in the udelay() call in quirk_usb_disable_ehci() is fixed at 100, but the compiler doesn't understand this and generates a link-time error. So we replace the otherwise unused variable "delta" with a simple constant 100. This same pattern is already used in other delay loops in that source file. Signed-off-by:
Konrad Rzepecki <krzepecki@dentonet.pl> Tested-by:
-
Havard Skinnemoen authored
commit 5dc2470c upstream. There's a race between the USB disconnect handler and the TTY close handler which may cause the acm object to be freed while it's still being used. This may lead to things like http://article.gmane.org/gmane.linux.usb.general/54250 and https://lkml.org/lkml/2011/5/29/64 This is the simplest fix I could come up with. Holding on to open_mutex while closing the TTY device prevents acm_disconnect() from freeing the acm object between acm->port.count drops to 0 and the TTY side of the cleanups are finalized. Signed-off-by:
Havard Skinnemoen <hskinnemoen@google.com> Cc: Oliver Neukum <oliver@neukum.name> Signed-off-by:
-
wangyanqing authored
commit 0c165955 upstream. I get report from customer that his usb-serial converter doesn't work well,it sometimes work, but sometimes it doesn't. The usb-serial converter's id: vendor_id product_id 0x4348 0x5523 Then I search the usb-serial codes, and there are two drivers announce support this device, pl2303 and ch341, commit 026dfaf1 cause it. Through many times to test, ch341 works well with this device, and pl2303 doesn't work quite often(it just work quite little). ch341 works well with this device, so we doesn't need pl2303 to support.I try to revert 026dfaf1 first, but it failed. So I prepare this patch by hand to revert it. Signed-off-by:
Wang YanQing <Udknight@gmail.com> Signed-off-by:
-
