- 13 Aug, 2010 26 commits
-
-
John G. Rogers authored
commit afad1964 upstream. I have added the ProductID=0xe729 VendorID=FTDI_VID=0x0403 which will enable support for the Segway Robotic Mobility Platform (RMP200) in the ftdi_sio kernel module. Currently, users of the Segway RMP200 must use a RUN+="/sbin/modprobe -q ftdi-sio product=0xe729 vendor=0x0403 in a udev rule to get the ftdi_sio module to handle the usb interface and mount it on /dev/ttyXXX. This is not a good solution because some users will have multiple USB to Serial converters which will use the ftdi_sio module. Signed-off-by:
John Rogers <jgrogers@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Phil Dibowitz authored
commit 93362a87 upstream. The Logitech Harmony 700 series needs an extra delay during initialization. This patch adds a USB quirk which enables such a delay and adds the device to the quirks list. Signed-off-by:
Phil Dibowitz <phil@ipom.com> Signed-off-by:
-
Steven Robertson authored
commit 33d973ad upstream. Enlarging the buffer size via the MON_IOCT_RING_SIZE ioctl causes general protection faults. It appears the culprit is an incorrect argument to mon_free_buff: instead of passing the size of the current buffer being freed, the size of the new buffer is passed. Use the correct size argument to mon_free_buff when changing the size of the buffer. Signed-off-by:
Steven Robertson <steven@strobe.cc> Acked-by:
Pete Zaitcev <zaitcev@redhat.com> Signed-off-by:
-
Uwe Kleine-König authored
commit 868003ca upstream. This is a follow up to 14cb0deb (arm/imx/gpio: add spinlock protection) and fixes the following build failure: CC arch/arm/mach-imx/pcm970-baseboard.o In file included from arch/arm/include/asm/gpio.h:6, from include/linux/gpio.h:8, from arch/arm/mach-imx/pcm970-baseboard.c:20: arch/arm/plat-mxc/include/mach/gpio.h:40: error: expected specifier-qualifier-list before 'spinlock_t' Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Will Deacon authored
commit cdf357f1 upstream. On versions of the Cortex-A9 prior to r2p0, performing TLB invalidations by ASID match can result in the incorrect ASID being broadcast to other CPUs. As a consequence of this, the targetted TLB entries are not invalidated across the system. This workaround changes the TLB flushing routines to invalidate entries regardless of the ASID. Tested-by:
Rob Clark <rob@ti.com> Acked-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Catalin Marinas authored
commit 492c5d94 upstream. On SMP systems, the SMSC911x registers may be accessed by multiple CPUs and this seems to put the chip in an inconsistent state. The patch adds spinlocks to the smsc911x_reg_read, smsc911x_reg_write, smsc911x_rx_readfifo and smsc911x_tx_writefifo functions. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Nathan Lynch authored
commit a2a20c41 upstream. If signalfd is used to consume a signal generated by a POSIX interval timer or POSIX message queue, the ssi_int field does not reflect the data (sigevent->sigev_value) supplied to timer_create(2) or mq_notify(3). (The ssi_ptr field, however, is filled in.) This behavior differs from signalfd's treatment of sigqueue-generated signals -- see the default case in signalfd_copyinfo. It also gives results that differ from the case when a signal is handled conventionally via a sigaction-registered handler. So, set signalfd_siginfo->ssi_int in the remaining cases (__SI_TIMER, __SI_MESGQ) where ssi_ptr is set. akpm: a non-back-compatible change. Merge into -stable to minimise the number of kernels which are in the field and which miss this feature. Signed-off-by:
Nathan Lynch <ntl@pobox.com> Acked-by:
Davide Libenzi <davidel@xmailserver.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Tejun Heo authored
commit aca27ba9 upstream. Commit a82afdfc (block: use the same failfast bits for bio and request) moved BIO_RW_* bits around such that they match up with REQ_* bits. Unfortunately, fs.h hard coded RW_MASK, RWA_MASK, READ, WRITE, READA and SWRITE as 0, 1, 2 and 3, and expected them to match with BIO_RW_* bits. READ/WRITE didn't change but BIO_RW_AHEAD was moved to bit 4 instead of bit 1, breaking RWA_MASK, READA and SWRITE. This patch updates RWA_MASK, READA and SWRITE such that they match the BIO_RW_* bits again. A follow up patch will update the definitions to directly use BIO_RW_* bits so that this kind of breakage won't happen again. Neil also spotted missing RWA_MASK conversion. Stable: The offending commit a82afdfc was released with v2.6.32, so this patch should be applied to all kernels since then but it must _NOT_ be applied to kernels earlier than that. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-and-bisected-by:
Vladislav Bolkhovitin <vst@vlnb.net> Root-caused-by:
Neil Brown <neilb@suse.de> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Julia Lawall authored
commit ceeab929 upstream. The comments in the code indicate that file_info should be released if the function fails. This releasing is done at the label out_free, not out. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @r exists@ local idexpression x; statement S; expression E; identifier f,f1,l; position p1,p2; expression *ptr != NULL; @@ x@p1 = kmem_cache_zalloc(...); ... if (x == NULL) S <... when != x when != if (...) { <+...x...+> } ( x->f1 = E | (x->f1 == NULL || ...) | f(...,x->f1,...) ) ...> ( return <+...x...+>; | return@p2 ...; ) @script:python@ p1 << r.p1; p2 << r.p2; @@ print "* file: %s kmem_cache_zalloc %s" % (p1[0].file,p1[0].line) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by:
-
Lino Sanfilippo authored
commit 31f73bee upstream. In ecryptfs_lookup_and_interpose_lower() the lower mount is not decremented if allocation of a dentry info struct failed. As a result the lower filesystem cant be unmounted any more (since it is considered busy). This patch corrects the reference counting. Signed-off-by:
Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by:
-
Tyler Hicks authored
commit c43f7b8f upstream. Lower filesystems that only implemented unlocked_ioctl weren't being passed ioctl calls because eCryptfs only checked for lower_file->f_op->ioctl and returned -ENOTTY if it was NULL. eCryptfs shouldn't implement ioctl(), since it doesn't require the BKL. This patch introduces ecryptfs_unlocked_ioctl() and ecryptfs_compat_ioctl(), which passes the calls on to the lower file system. https://bugs.launchpad.net/ecryptfs/+bug/469664Reported-by:
James Dupin <james.dupin@gmail.com> Signed-off-by:
-
Chris Wright authored
commit b7300b78 upstream. The cgroup device whitelist code gets confused when trying to grant permission to a disk partition that is not currently open. Part of blkdev_open() includes __blkdev_get() on the whole disk. Basically, the only ways to reliably allow a cgroup access to a partition on a block device when using the whitelist are to 1) also give it access to the whole block device or 2) make sure the partition is already open in a different context. The patch avoids the cgroup check for the whole disk case when opening a partition. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=589662Signed-off-by:
Chris Wright <chrisw@sous-sol.org> Acked-by:
Serge E. Hallyn <serue@us.ibm.com> Tested-by:
Vivek Goyal <vgoyal@redhat.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: "Daniel P. Berrange" <berrange@redhat.com> Signed-off-by:
-
NeilBrown authored
commit 51e9ac77 upstream. If the 'bio_split' path in raid10-read is used while resync/recovery is happening it is possible to deadlock. Fix this be elevating ->nr_waiting for the duration of both parts of the split request. This fixes a bug that has been present since 2.6.22 but has only started manifesting recently for unknown reasons. It is suitable for and -stable since then. Reported-by:
Justin Bronder <jsbronder@gentoo.org> Tested-by:
-
Borislav Petkov authored
commit 11071282 upstream. ide_cd_error_cmd() can complete an erroneous request with leftover buffers. Signal this with its return value so that the request is not accessed after its completion in the irq handler and we oops. Signed-off-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Peter Huewe authored
commit fa260c00 upstream. Fix a build failure "error: void value not ignored as it ought to be" by removing an assignment of a void return value. The functionality of the code is not changed. Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Acked-by:
Henrik Kretzschmar <henne@nachtwindheim.de> Signed-off-by:
-
Miklos Szeredi authored
commit 6965031d upstream. SPLICE_F_NONBLOCK is clearly documented to only affect blocking on the pipe. In __generic_file_splice_read(), however, it causes an EAGAIN if the page is currently being read. This makes it impossible to write an application that only wants failure if the pipe is full. For example if the same process is handling both ends of a pipe and isn't otherwise able to determine whether a splice to the pipe will fill it or not. We could make the read non-blocking on O_NONBLOCK or some other splice flag, but for now this is the simplest fix. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
David Woodhouse authored
commit 1f6ea6e5 upstream. We were seeing faults in the solos-pci receive tasklet when packets arrived for a VCC which was currently being closed: [18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] SS:ESP 0068:dfb89d14 [18845.090712] [<c13ecff3>] ? do_page_fault+0x0/0x2e1 [18845.120042] [<e082f490>] ? br2684_push+0x19/0x234 [br2684] [18845.153530] [<e084fa13>] solos_bh+0x28b/0x7c8 [solos_pci] [18845.186488] [<e084f711>] ? solos_irq+0x2d/0x51 [solos_pci] [18845.219960] [<c100387b>] ? handle_irq+0x3b/0x48 [18845.247732] [<c10265cb>] ? irq_exit+0x34/0x57 [18845.274437] [<c1025720>] tasklet_action+0x42/0x69 [18845.303247] [<c102643f>] __do_softirq+0x8e/0x129 [18845.331540] [<c10264ff>] do_softirq+0x25/0x2a [18845.358274] [<c102664c>] _local_bh_enable_ip+0x5e/0x6a [18845.389677] [<c102666d>] local_bh_enable+0xb/0xe [18845.417944] [<e08490a8>] ppp_unregister_channel+0x32/0xbb [ppp_generic] [18845.458193] [<e08731ad>] pppox_unbind_sock+0x18/0x1f [pppox] This patch uses an RCU-inspired approach to fix it. In the RX tasklet's find_vcc() function we first refuse to use a VCC which already has the ATM_VF_READY bit cleared. And in the VCC close function, we synchronise with the tasklet to ensure that it can't still be using the VCC before we continue and allow the VCC to be destroyed. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Tested-by:
Nathan Williams <nathan@traverse.com.au> Signed-off-by:
-
Tejun Heo authored
commit 549e1561 upstream. MSI delivery from on-board ahci controller doesn't work on K8M800. At this point, it's unclear whether the culprit is with the ahci controller or the host bridge. Given the track record and considering the rather minimal impact of MSI, disabling it seems reasonable. Signed-off-by:
Rainer Hurtado Navarro <publio.escipion.el.africano@gmail.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Rafael J. Wysocki authored
commit 3d2a5318 upstream. There is no reason to run NVidia-specific quirks related to HT MSI mappings with MSI disabled via pci=nomsi, so make __nv_msi_ht_cap_quirk() return immediately in that case. This allows at least one machine to boot 100% of the time with pci=nomsi (it still doesn't boot reliably without that). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16443 . Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Peter Huewe authored
commit 060132ae upstream. This patch prevents the code from calling parport_release and parport_unregister_device twice with the same arguments - and thus fixes an oops. Rationale: After the first call the parport is already released and the handle isn't valid anymore and calling parport_release and parport_unregister_device twice isn't a good idea. Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Randy Dunlap authored
commit e928c077 upstream. line6 uses snd_pcm*() functions, so it should select SND_PCM. ERROR: "snd_pcm_period_elapsed" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_set_ops" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_free_pages" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_ioctl" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_malloc_pages" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_hw_constraint_ratdens" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_format_physical_width" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_lib_preallocate_pages_for_all" [drivers/staging/line6/line6usb.ko] undefined! ERROR: "snd_pcm_new" [drivers/staging/line6/line6usb.ko] undefined! Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Markus Grabner <grabner@icg.tugraz.at> Signed-off-by:
-
Alok Kataria authored
commit 9f242dc1 upstream. When running on VMware's platform, we have seen situations where the AP's try to calibrate the lpj values and fail to get good calibration runs becasue of timing issues. As a result delays don't work correctly on all cpus. The solutions is to set preset_lpj value based on the current tsc frequency value. This is similar to what KVM does as well. Signed-off-by:
Alok N Kataria <akataria@vmware.com> LKML-Reference: <1280790637.14933.29.camel@ank32.eng.vmware.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
H. Peter Anvin authored
commit 113fc5a6 upstream. xchg() and cmpxchg() modify their memory operands, not merely read them. For some versions of gcc the "memory" clobber has apparently dealt with the situation, but not for all. Originally-by:
H. Peter Anvin <hpa@zytor.com> Cc: Glauber Costa <glommer@redhat.com> Cc: Avi Kivity <avi@redhat.com> Cc: Peter Palfrader <peter@palfrader.org> Cc: Greg KH <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Zachary Amsden <zamsden@redhat.com> Cc: Marcelo Tosatti <mtosatti@redhat.com> LKML-Reference: <4C4F7277.8050306@zytor.com> Signed-off-by:
-
H. Peter Anvin authored
commit a01c7800 upstream. In nvram_write, first of all, correctly handle the case where the file pointer is already beyond the end; we should return EOF in that case. Second, make the logic a bit more explicit so that gcc can statically prove that the copy_from_user() is safe. Once the condition of the beyond-end filepointer is eliminated, the copy is safe but gcc can't prove it, causing build failures for i386 allyesconfig. Third, eliminate the entirely superfluous variable "len", and just use the passed-in variable "count" instead. Signed-off-by:
-
Sam Ravnborg authored
commit e32e78c5 upstream. Thomas Backlund reported that the powerpc build broke with make 3.82. It failed with the following message: arch/powerpc/Makefile:183: *** mixed implicit and normal rules. Stop. The fix is to avoid mixing non-wildcard and wildcard targets. Reported-by:
Thomas Backlund <tmb@mandriva.org> Tested-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Tejun Heo authored
commit 213373cf upstream. SIDPR window registers are shared across ports and as each access is done in two steps, accesses to different ports under EH may race. This primarily is caused by incorrect host locking in EH context and should be fixed by defining locking requirements for each EH operation which can be used during EH and enforcing them but for now work around the problem by adding a dedicated SIDPR lock and grabbing it for each SIDPR access. Signed-off-by:
Mark Knecht <markknecht@gmail.com> Reported-by:
Paul Check <paul@thechecks.ca> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
- 10 Aug, 2010 14 commits
-
-
Greg Kroah-Hartman authored
-
Larry Finger authored
commit 9d1ac34e upstream. In kernel Bugzilla #15825 (2 users), in a wireless mailing list thread (http://lists.infradead.org/pipermail/b43-dev/2010-May/000124.html), and on a netbook owned by John Linville (http://marc.info/?l=linux-wireless&m=127230751408818&w=4), there are reports of ssb failing to detect an SPROM at the normal location. After studying the MMIO trace dump for the Broadcom wl driver, it was determined that the affected boxes had a relocated SPROM. This patch fixes all systems that have reported this problem. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Christoph Fritz authored
commit da1fdb02 upstream. Ethernet driver b44 does register ssb by it's pcihost_wrapper and doesn't set ssb_chipcommon. A check on this value introduced with commit d53cdbb9 and ea2db495 triggers: BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [<c1266c36>] ssb_is_sprom_available+0x16/0x30 Signed-off-by:
Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by:
-
Rafał Miłecki authored
commit ea2db495 upstream. Our offset handling becomes even a little more hackish now. For some reason I do not understand all offsets as inrelative. It assumes base offset is 0x1000 but it will work for now as we make offsets relative anyway by removing base 0x1000. Should be cleaner however. Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
John W. Linville authored
commit d53cdbb9 upstream. Attempting to read registers that don't exist on the SSB bus can cause hangs on some boxes. At least some b43 devices are 'in the wild' that don't have SPROMs at all. When the SSB bus support loads, it attempts to read these (non-existant) SPROMs and causes hard hangs on the box -- no console output, etc. This patch adds some intelligence to determine whether or not the SPROM is present before attempting to read it. This avoids those hard hangs on those devices with no SPROM attached to their SSB bus. The SSB-attached devices (e.g. b43, et al.) won't work, but at least the box will survive to test further patches. :-) Signed-off-by:
-
Greg Kroah-Hartman authored
Turns out this isn't the best way to resolve this issue. The individual patches will be applied instead. Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: -
Zhao Yakui authored
commit 6363ee6f upstream. On some laptops there is no HDMI/DP. But the xrandr still reports several disconnected HDMI/display ports. In such case the user will be confused. >DVI1 disconnected (normal left inverted right x axis y axis) >DP1 disconnected (normal left inverted right x axis y axis) >DVI2 disconnected (normal left inverted right x axis y axis) >DP2 disconnected (normal left inverted right x axis y axis) >DP3 disconnected (normal left inverted right x axis y axis) This patch set is to use the child device parsed in VBT to decide whether the HDMI/DP/LVDS/TV should be initialized. Parse the child device from VBT. The device class type is also added for LFP, TV, HDMI, DP output. https://bugs.freedesktop.org/show_bug.cgi?id=22785Signed-off-by:
Zhao Yakui <yakui.zhao@intel.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Adam Jackson authored
Combined patches from 2.6.33 for fixing LVDS detection. 7cf4f69d drm/i915: Don't set up the LVDS if it isn't in the BIOS device table. 38b3037e drm/i915: Fix LVDS presence check 6e36595a drm/i915: Declare the new VBT parsing functions as static 11ba1592 drm/i915: Don't check for lid presence when detecting LVDS Acked-by:
-
Jeremy Fitzhardinge authored
commit 8a22b999 upstream. xen_sched_clock only counts unstolen time. In principle this should be useful to the Linux scheduler so that it knows how much time a process actually consumed. But in practice this doesn't work very well as the scheduler expects the sched_clock time to be synchronized between cpus. It also uses sched_clock to measure the time a task spends sleeping, in which case "unstolen time" isn't meaningful. So just use plain xen_clocksource_read to return wallclock nanoseconds for sched_clock. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by:
-
Michael Neuling authored
An allmodconfig compile on ppc64 with 2.6.32.17 currently gives this error fs/cifs/dns_resolve.h:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cifs_init_dns_resolver' This adds the correct header file to fix this. Signed-off-by:
Michael Neuling <mikey@neuling.org> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
David Howells authored
commit 51c20fcc upstream. Remove the __exit mark from cifs_exit_dns_resolver() as it's called by the module init routine in case of error, and so may have been discarded during linkage. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Dave Airlie authored
commit 88be12c4 upstream. Otherwise we can get an oops if the user has no get_ref/put_ref requirement. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Bob Peterson authored
commit 728a756b upstream. This patch fixes a kernel Oops in the GFS2 rename code. The problem was in the way the gfs2 directory code was trying to re-use sentinel directory entries. In the failing case, gfs2's rename function was renaming a file to another name that had the same non-trivial length. The file being renamed happened to be the first directory entry on the leaf block. First, the rename code (gfs2_rename in ops_inode.c) found the original directory entry and decided it could do its job by simply replacing the directory entry with another. Therefore it determined correctly that no block allocations were needed. Next, the rename code deleted the old directory entry prior to replacing it with the new name. Therefore, the soon-to-be replaced directory entry was temporarily made into a directory entry "sentinel" or a place holder at the start of a leaf block. Lastly, it went to re-add the replacement directory entry in that leaf block. However, when gfs2_dirent_find_space was looking for space in the leaf block, it used the wrong value for the sentinel. That threw off its calculations so later it decides it can't really re-use the sentinel and therefore must allocate a new leaf block. But because it previously decided to re-use the directory entry, it didn't waste the time to grab a new block allocation for the inode. Therefore, the inode's i_alloc pointer was still NULL and it crashes trying to reference it. In the case of sentinel directory entries, the entire dirent is reused, not just the "free space" portion of it, and therefore the function gfs2_dirent_find_space should use the value 0 rather than GFS2_DIRENT_SIZE(0) for the actual dirent size. Fixing this calculation enables the reproducer programs to work properly. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
James Bottomley authored
commit a91c1be2 upstream. we also need to clean up and free the cdev. Reported-by:
Jani Nikula <ext-jani.1.nikula@nokia.com> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
