- 22 Nov, 2010 38 commits
-
-
Alan Stern authored
commit 56626a72 upstream. A few devices (such as the RCA VR5220 voice recorder) are so non-compliant with the USB spec that they have invalid maxpacket sizes for endpoint 0. Nevertheless, as long as we can safely use them, we may as well do so. This patch (as1432) softens our acceptance criterion by allowing high-speed devices to have ep0-maxpacket sizes other than 64. A warning is printed in the system log when this happens, and the existing error message is clarified. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
James <bjlockie@lockie.ca> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Alon Ziv authored
commit 97cd8dc4 upstream. The bulk-read callback had two bugs: a) The bulk-in packet's leading two zeros were returned (and the two last bytes truncated) b) The wrong URB was transmitted for the second (and later) read requests, causing further reads to return the entire packet (including leading zeros) Signed-off-by:
Alon Ziv <alon-git@nolaviz.org> Signed-off-by:
-
Alan Stern authored
commit 80f0cf39 upstream. This patch (as1430) fixes a bug in usbcore. When a device configuration change occurs or a device is removed, the endpoints for the old config should be completely disabled. However it turns out they aren't; this is because usb_unbind_interface() calls usb_enable_interface() or usb_set_interface() to put interfaces back in altsetting 0, which re-enables the interfaces' endpoints. As a result, when a device goes through a config change or is unconfigured, the ep_in[] and ep_out[] arrays may be left holding old pointers to usb_host_endpoint structures. If the device is deauthorized these structures get freed, and the stale pointers cause errors when the the device is eventually unplugged. The solution is to disable the endpoints after unbinding the interfaces instead of before. This isn't as large a change as it sounds, since usb_unbind_interface() disables all the interface's endpoints anyway before calling the driver's disconnect routine, unless the driver claims to support "soft" unbind. This fixes Bugzilla #19192. Thanks to "Tom" Lei Ming for diagnosing the underlying cause of the problem. Signed-off-by:
Carsten Sommer <carsten_sommer@ymail.com> Signed-off-by:
-
Jean-Christophe PLAGNIOL-VILLARD authored
commit 969affff upstream. to ensure gpio_is_valid return false Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Anders Larsen authored
commit 93ad03d6 upstream. The WAGO 750-923 USB Service Cable is used for configuration and firmware updates of several industrial automation products from WAGO Kontakttechnik GmbH. Bus 004 Device 002: ID 1be3:07a6 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1be3 idProduct 0x07a6 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 WAGO USB Service Cable iSerial 3 1277796751 . . . Signed-off-by:
Anders Larsen <al@alarsen.net> Signed-off-by:
-
DJ Delorie authored
commit 2f1136d1 upstream. RX610 development board by Renesas Bus 001 Device 024: ID 045b:0053 Hitachi, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x045b Hitachi, Ltd idProduct 0x0053 bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 RX-Stick iSerial 3 0001 . . . http://am.renesas.com/rx610stickSigned-off-by:
DJ Delorie <dj@delorie.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit ecfa153e upstream. There are lots of ZTE USB id's currently not covered by usb/serial. Adds them, to allow those devices to work properly on Linux. While here, put the USB ID's for 0x2002/0x2003 at the sorted order. This patch is based on zte.c file found on MF645. PS.: The ZTE driver is commenting the USB ID for 0x0053. It also adds, commented, an USB ID for 0x0026. Not sure why, but I think that 0053 is used by their devices in storage mode only. So, I opted to keep the comment on this patch. Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Sergei Shtylyov authored
commit 00be545e upstream. Blackfin's musb_platform_init() needs to call gpio_free() for error cleanup iff otg_get_transceiver() call returns NULL. Signed-off-by:
Sergei Shtylyov <sshtylyov@ru.mvista.com> Acked-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 0f266abd upstream. This adds the requested device ids to the ftdi_sio driver. Reported-by:
Ewan Bingham <ewan@auc.co.uk> Cc: Kuba Ober <kuba@mareimbrium.org> Signed-off-by:
-
Daniel Suchy authored
commit 59c6ccd9 upstream. This patch for FTDI USB serial driver ads new VID/PIDs used on various devices manufactured by Papouch (http://www.papouch.com). These devices have their own VID/PID, although they're using standard FTDI chip. In ftdi_sio.c, I also made small cleanup to have declarations for all Papouch devices together. Signed-off-by:
Daniel Suchy <danny@danysek.cz> Signed-off-by:
-
Rainer Keller authored
commit 99c1e4f8 upstream. The OpenDCC project is developing a new hardware. This patch adds its PID to the list of known FTDI devices. The PID can be found at http://www.opendcc.de/elektronik/usb/opendcc_usb.htmlSigned-off-by:
Rainer Keller <mail@rainerkeller.de> Signed-off-by:
-
Rich Mattes authored
commit 3126d823 upstream. Adds support for Accesio USB to Serial adapters, which are built around FTDI FT232 UARTs. Tested with the Accesio USB-COM-4SM. Signed-off-by:
Rich Mattes <richmattes@gmail.com> Signed-off-by:
-
Julia Lawall authored
commit 0d91f22b upstream. In this code, 0 is returned on memory allocation failure, even though other failures return -ENOMEM or other similar values. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression ret; expression x,e1,e2,e3; @@ ret = 0 ... when != ret = e1 *x = \(kmalloc\|kcalloc\|kzalloc\)(...) ... when != ret = e2 if (x == NULL) { ... when != ret = e3 return ret; } // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Acked-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Christian Lamparter authored
commit 1a92795d upstream. Source: http://www.wikidevi.com/wiki/Intersil/p54/usb/windowsSigned-off-by:
-
Christian Lamparter authored
commit 11791a6f upstream. The ISL3887 chip needs a USB reset, whenever the usb-frontend module "p54usb" is reloaded. This patch fixes an off-by-one bug, if the user is running a kernel without the CONFIG_PM option set and for some reason (e.g.: compat-wireless) wants to switch between different p54usb modules. Signed-off-by:
-
Nicolas Kaiser authored
commit e5953cbd upstream. The arguments were transposed, we want to assign the error code to 'ret', which is being returned. Signed-off-by:
Nicolas Kaiser <nikai@nikai.net> Signed-off-by:
Jens Axboe <jaxboe@fusionio.com> Signed-off-by:
-
Avi Kivity authored
commit 9581d442 upstream kvm reloads the host's fs and gs blindly, however the underlying segment descriptors may be invalid due to the user modifying the ldt after loading them. Fix by using the safe accessors (loadsegment() and load_gs_index()) instead of home grown unsafe versions. This is CVE-2010-3698. Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Zachary Amsden authored
commit 47008cd8 upstream. The VMCB is reset whenever we receive a startup IPI, so Linux is setting TSC back to zero happens very late in the boot process and destabilizing the TSC. Instead, just set TSC to zero once at VCPU creation time. Why the separate patch? So git-bisect is your friend. Signed-off-by:
Zachary Amsden <zamsden@redhat.com> Signed-off-by:
-
Zachary Amsden authored
commit 58877679 upstream. On reset, VMCB TSC should be set to zero. Instead, code was setting tsc_offset to zero, which passes through the underlying TSC. Signed-off-by:
-
Joerg Roedel authored
commit 953899b6 upstream. The tsc_offset adjustment in svm_vcpu_load is executed unconditionally even if Linux considers the host tsc as stable. This causes a Linux guest detecting an unstable tsc in any case. This patch removes the tsc_offset adjustment if the host tsc is stable. The guest will now get the benefit of a stable tsc too. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Avi Kivity authored
commit 3444d7da upstream. vmx does not restore GDT.LIMIT to the host value, instead it sets it to 64KB. This means host userspace can learn a few bits of host memory. Fix by reloading GDTR when we load other host state. Signed-off-by:
-
Xiao Guangrong authored
commit 5fd5387c upstream. In no-direct mapping, we mark sp is 'direct' when we mapping the guest's larger page, but its access is encoded form upper page-struct entire not include the last mapping, it will cause access conflict. For example, have this mapping: [W] / PDE1 -> |---| P[W] | | LPA \ PDE2 -> |---| [R] P have two children, PDE1 and PDE2, both PDE1 and PDE2 mapping the same lage page(LPA). The P's access is WR, PDE1's access is WR, PDE2's access is RO(just consider read-write permissions here) When guest access PDE1, we will create a direct sp for LPA, the sp's access is from P, is W, then we will mark the ptes is W in this sp. Then, guest access PDE2, we will find LPA's shadow page, is the same as PDE's, and mark the ptes is RO. So, if guest access PDE1, the incorrect #PF is occured. Fixed by encode the last mapping access into direct shadow page Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Signed-off-by:
-
Xiao Guangrong authored
commit 9e7b0e7f upstream. If the mapping is writable but the dirty flag is not set, we will find the read-only direct sp and setup the mapping, then if the write #PF occur, we will mark this mapping writable in the read-only direct sp, now, other real read-only mapping will happily write it without #PF. It may hurt guest's COW Fixed by re-install the mapping when write #PF occur. Signed-off-by:
-
Joerg Roedel authored
commit 061e2fd1 upstream. This patch makes KVM on 32 bit SVM working again by correcting the masks used for iret interception. With the wrong masks the upper 32 bits of the intercepts are masked out which leaves vmrun unintercepted. This is not legal on svm and the vmrun fails. Bug was introduced by commits 95ba8273 and 3cfc3092. Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Gleb Natapov <gleb@redhat.com> Signed-off-by:
-
Cliff Wickman authored
commit 37a2f9f3 upstream. The copy of /proc/vmcore to a user buffer proceeds much faster if the kernel addresses memory as cached. With this patch we have seen an increase in transfer rate from less than 15MB/s to 80-460MB/s, depending on size of the transfer. This makes a big difference in time needed to save a system dump. Signed-off-by:
Cliff Wickman <cpw@sgi.com> Acked-by:
"Eric W. Biederman" <ebiederm@xmission.com> Cc: kexec@lists.infradead.org LKML-Reference: <E1OtMLz-0001yp-Ia@eag09.americas.sgi.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Suresh Siddha authored
commit 75e3cfbe upstream. Currently the redirection hint in the interrupt-remapping table entry is set to 0, which means the remapped interrupt is directed to the processors listed in the destination. So in logical flat mode in the presence of intr-remapping, this results in a single interrupt multi-casted to multiple cpu's as specified by the destination bit mask. But what we really want is to send that interrupt to one of the cpus based on the lowest priority delivery mode. Set the redirection hint in the IRTE to '1' to indicate that we want the remapped interrupt to be directed to only one of the processors listed in the destination. This fixes the issue of same interrupt getting delivered to multiple cpu's in the logical flat mode in the presence of interrupt-remapping. While there is no functional issue observed with this behavior, this will impact performance of such configurations (<=8 cpu's using logical flat mode in the presence of interrupt-remapping) Signed-off-by:
Suresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <20100827181049.013051492@sbsiddha-MOBL3.sc.intel.com> Cc: Weidong Han <weidong.han@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Andreas Herrmann authored
commit 3fdbf004 upstream. Instead of adapting the CPU family check in amd_special_default_mtrr() for each new CPU family assume that all new AMD CPUs support the necessary bits in SYS_CFG MSR. Tom2Enabled is architectural (defined in APM Vol.2). Tom2ForceMemTypeWB is defined in all BKDGs starting with K8 NPT. In pre K8-NPT BKDG this bit is reserved (read as zero). W/o this adaption Linux would unnecessarily complain about bad MTRR settings on every new AMD CPU family, e.g. [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4863MB of RAM. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> LKML-Reference: <20100930123235.GB20545@loge.amd.com> Signed-off-by:
-
Paul Fox authored
commit 286e5b97 upstream. Avoids a potential infinite loop. It was observed once, during an EC hacking/debugging session - not in regular operation. Signed-off-by:
Daniel Drake <dsd@laptop.org> Cc: dilinger@queued.net Signed-off-by:
-
Alok Kataria authored
commit 76fac077 upstream. x86 smp_ops now has a new op, stop_other_cpus which takes a parameter "wait" this allows the caller to specify if it wants to stop until all the cpus have processed the stop IPI. This is required specifically for the kexec case where we should wait for all the cpus to be stopped before starting the new kernel. We now wait for the cpus to stop in all cases except for panic/kdump where we expect things to be broken and we are doing our best to make things work anyway. This patch fixes a legitimate regression, which was introduced during 2.6.30, by commit id 4ef702c1. Signed-off-by:
Alok N Kataria <akataria@vmware.com> LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Jeremy Fitzhardinge <jeremy@xensource.com> Signed-off-by:
-
Andre Przywara authored
commit 7ef8aa72 upstream. The AMD SSE5 feature set as-it has been replaced by some extensions to the AVX instruction set. Thus the bit formerly advertised as SSE5 is re-used for one of these extensions (XOP). Although this changes the /proc/cpuinfo output, it is not user visible, as there are no CPUs (yet) having this feature. To avoid confusion this should be added to the stable series, too. Signed-off-by:
Andre Przywara <andre.przywara@amd.com> LKML-Reference: <1283778860-26843-2-git-send-email-andre.przywara@amd.com> Signed-off-by:
-
Cliff Wickman authored
commit 3ee48b6a upstream. During the reading of /proc/vmcore the kernel is doing ioremap()/iounmap() repeatedly. And the buildup of un-flushed vm_area_struct's is causing a great deal of overhead. (rb_next() is chewing up most of that time). This solution is to provide function set_iounmap_nonlazy(). It causes a subsequent call to iounmap() to immediately purge the vma area (with try_purge_vmap_area_lazy()). With this patch we have seen the time for writing a 250MB compressed dump drop from 71 seconds to 44 seconds. Signed-off-by:
-
Darren Hart authored
commit 7ada876a upstream. futex_wait() is leaking key references due to futex_wait_setup() acquiring an additional reference via the queue_lock() routine. The nested key ref-counting has been masking bugs and complicating code analysis. queue_lock() is only called with a previously ref-counted key, so remove the additional ref-counting from the queue_(un)lock() functions. Also futex_wait_requeue_pi() drops one key reference too many in unqueue_me_pi(). Remove the key reference handling from unqueue_me_pi(). This was paired with a queue_lock() in futex_lock_pi(), so the count remains unchanged. Document remaining nested key ref-counting sites. Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Reported-and-tested-by: Matthieu Fertré<matthieu.fertre@kerlabs.com> Reported-by: Louis Rilling<louis.rilling@kerlabs.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: John Kacur <jkacur@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> LKML-Reference: <4CBB17A8.70401@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Alan Cox authored
commit c19483cc upstream. Fortunately this is only exploitable on very unusual hardware. [Reported a while ago but nothing happened so just fixing it] Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mathieu Desnoyers authored
commit 7740191c upstream. Fix incorrect handling of the following case: INTERACTIVE INTERACTIVE_SOMETHING_ELSE The comparison only checks up to each element's length. Changelog since v1: - Embellish using some Rostedtisms. [ mingo: ^^ == smaller and cleaner ] Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tony Lindgren <tony@atomide.com> LKML-Reference: <20100913214700.GB16118@Krystal> Signed-off-by:
-
Vasiliy Kulikov authored
commit 5b917a14 upstream. Structure new_line is copied to userland with some padding fields unitialized. It leads to leaking of stack memory. Signed-off-by:
Vasiliy Kulikov <segooon@gmail.com> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Paul Mackerras authored
commit 9f5f9ffe upstream. The logic to distinguish marked instruction events from ordinary events on PPC970 and derivatives was flawed. The result is that instruction sampling didn't get enabled in the PMU for some marked instruction events, so they would never trigger. This fixes it by adding the appropriate break statements in the switch statement. Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Max Vozeler authored
commit 584c5b7c upstream. The way the event handler works can cause it to delay events until eventual wakeup for another event. For example, on device detach (vhci): - Write to sysfs detach file -> usbip_event_add(VDEV_EVENT_DOWN) -> wakeup() #define VDEV_EVENT_DOWN (USBIP_EH_SHUTDOWN | USBIP_EH_RESET). - Event thread wakes up and passes the event to event_handler() to process. - It processes and clears the USBIP_EH_SHUTDOWN flag then returns. - The outer event loop (event_handler_loop()) calls wait_event_interruptible(). The processing of the second flag which is part of VDEV_EVENT_DOWN (USBIP_EH_RESET) did not happen yet. It is delayed until the next event. This means the ->reset callback may not happen for a long time (if ever), leaving the usbip port in a weird state which prevents its reuse. This patch changes the handler to process all flags before waiting for another wakeup. I have verified this change to fix a problem which prevented reattach of a usbip device. It also helps for socket errors which missed the RESET as well. The delayed event processing also affects the stub side of usbip and the error handling there. Signed-off-by:
Max Vozeler <mvz@vozeler.com> Reported-by:
Marco Lancione <marco@optikam.com> Tested-by:
Luc Jalbert <ljalbert@optikam.com> Signed-off-by:
-
Max Vozeler authored
commit 0c9a32f0 upstream. This patch changes vhci to behave like dummy and other hcds when disconnecting a device. Previously detaching a device from the root hub did not notify the usb core of the disconnect and left the device visible. Signed-off-by:
-
- 29 Oct, 2010 2 commits
-
-
Greg Kroah-Hartman authored
-
Stefan Bader authored
commit 39aa3cb3 upstream. So it can be used by all that need to check for that. Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
