- 30 May, 2012 40 commits
-
-
Jonathan Nieder authored
commit 44d27f7d upstream. On big-endian systems (e.g., Apple PowerBook), trying to use a logitech wireless mouse with the Logitech Unifying Receiver does not work with v3.2 and later kernels. The device doesn't show up in /dev/input. Older kernels work fine. That is because the new hid-logitech-dj driver claims the device. The device arrival notification appears: 20 00 41 02 00 00 00 00 00 00 00 00 00 00 00 and we read the report_types bitfield (02 00 00 00) to find out what kind of device it is. Unfortunately the driver only reads the first 8 bits and treats that value as a 32-bit little-endian number, so on a powerpc the report type seems to be 0x02000000 and is not recognized. Even on little-endian machines, connecting a media center remote control (report type 00 01 00 00) with this driver loaded would presumably fail for the same reason. Fix both problems by using get_unaligned_le32() to read all four bytes, which is a little clearer anyway. After this change, the wireless mouse works on Hugo's PowerBook again. Based on a patch by Nestor Lopez Casado. Addresses http://bugs.debian.org/671292Reported-by:
Hugo Osvaldo Barrera <hugo@osvaldobarrera.com.ar> Inspired-by:
Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Nicolas Ferre authored
commit 07e4e556 upstream. A possible race condition appears because we are not initializing the ohci->regs before calling usb_hcd_request_irqs(). We move the call to ohci_init() in hcd->driver->reset() instead of hcd->driver->start() to fix this. This was experienced when we share the same IRQ line between OHCI and EHCI controllers. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Tested-by:
Christian Eggers <christian.eggers@kathrein.de> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alan Stern authored
commit df767b71 upstream. This patch (as1553) adds an unusual_dev entrie for the Yarvik PMP400 MP4 music player. Signed-off-by:
Jesse Feddema <jdfeddema@gmail.com> Tested-by:
-
David Herrmann authored
commit 74b89e8a upstream. We incorrectly parse incoming IR data. The extra byte contains the upper bits and not the lower bits of the x/y coordinates. User-space expects absolute position data from us so this patch does not break existing applications. On the contrary, it extends the virtual view and fixes garbage reports for margin areas of the virtual screen. Reported-by:
Peter Bukovsky <bukovsky.peter@gmail.com> Signed-off-by:
David Herrmann <dh.herrmann@googlemail.com> Signed-off-by:
-
Matthias Fend authored
commit eb9c5836 upstream. The out functions should only handle actual available data instead of the complete buffer. Otherwise for example the ep0_consume function will report ghost events since it tries to decode the complete buffer - which may contain partly invalid data. Signed-off-by:
Matthias Fend <matthias.fend@wolfvision.net> Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
Éric Piel authored
commit b69cc672 upstream. This adds VID/PID for the PI E-861. Without it, I had to do: modprobe -q ftdi-sio product=0x1008 vendor=0x1a72 http://www.physikinstrumente.com/en/products/prdetail.php?sortnr=900610Signed-off-by:
Éric Piel <piel@delmic.com> Signed-off-by:
-
Lothar Waßmann authored
commit 8b979f7c upstream. This patch fixes a problem reported here: http://article.gmane.org/gmane.linux.ports.arm.kernel/155242/match=auartSigned-off-by:
Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by:
-
Peter Chen authored
commit 4d0947de upstream. dTD's next dtd pointer need to be updated once CPU writes it, or this request may not be handled by controller, then host will get NAK from device forever. This problem occurs when there is a request is handling, we need to add a new request to dTD list, if this new request is added before the current one is finished, the new request is intended to added as next dtd pointer at current dTD, but without wmb(), the dTD's next dtd pointer may not be updated when the controller reads it. In that case, the controller will still get Terminate Bit is 1 at dTD's next dtd pointer, that means there is no next request, then this new request is missed by controller. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Acked-by:
Li Yang <leoli@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sarah Sharp authored
commit 1c12443a upstream. The upcoming Intel Lynx Point chipset includes an xHCI host controller that can have ports switched from the EHCI host controller, just like the Intel Panther Point xHCI host. This time, ports from both EHCI hosts can be switched to the xHCI host controller. The PCI config registers to do the port switching are in the exact same place in the xHCI PCI configuration registers, with the same semantics. Hooray for shipping patches for next-gen hardware before the current gen hardware is even available for purchase! This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Sarah Sharp authored
commit 51c9e6c7 upstream. If the user chooses to say "no" to CONFIG_USB_XHCI_HCD on a system with an Intel Panther Point chipset, the PCI quirks code or the EHCI driver will switch the ports over to the xHCI host, but the xHCI driver will never load. The ports will be powered off and seem "dead" to the user. Fix this by only switching the ports over if CONFIG_USB_XHCI_HCD is either compiled in, or compiled as a module. This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by:
Eric Anholt <eric.anholt@intel.com> Reported-by:
David Bein <d.bein@f5.com> Signed-off-by:
-
Hans de Goede authored
commit 9c745995 upstream. While testing unplugging an UVC HD webcam with usb-redirection (so through usbdevfs), my userspace usb-redir code was getting a value of -1 in iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt is not a valid value. The source of this -1 is the default case in xhci-ring.c:process_isoc_td() adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR in this case, so this patch adds handling for that completion code to process_isoc_td(). This was observed and tested with the following xhci controller: 1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can do, but since I cannot come up with anything better I've left that as is. This patch should be backported to kernels as old as 2.6.36, which contain the commit 04e51901 "USB: xHCI: Isochronous transfer implementation". Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Christian Melki authored
commit f9a9111b upstream. We noticed that we were loosing data at speed less than 2400 baud. It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr reg. The input code still fills the buffer with 64 bytes if I remember correctly and thus data is lost. Our fix was to remove whiping of the fcr content and just add the TRIGGER_1 which we want for latency. I can't see why this would not work on less than 2400 always, for all uarts ... Otherwise one would have to make sure the filling of the fifo re-checks the current state of available fifo size (urrk). Signed-off-by:
Christian Melki <christian.melki@ericsson.se> Signed-off-by:
-
Paul Zimmerman authored
commit 6a23ccd2 upstream. bMaxPacketSize0 field for super speed is a power of 2, not a count. The size itself is always 512. Max packet size for a super speed bulk endpoint is 1024, so allocate the urb size in halt_simple() accordingly. Signed-off-by:
Paul Zimmerman <paulz@synopsys.com> Acked-by:
-
Steffen Müller authored
commit 166cb70e upstream. Tested-by:
Steffen Müller <steffen.mueller@radio-frei.de> Signed-off-by:
Stefan Seyfried <seife+kernel@b1-systems.com> Signed-off-by:
-
Arnaud Patard authored
commit aaa10eb1 upstream. The rules used to make 8250_pci "ignore" the PCH uarts are lacking pci subids entries, preventing it to match and thus is breaking serial port support for theses systems. This has been tested on a nanoETXexpress-TT, which has a specifici uart clock. Tested-by:
Erwan Velu <Erwan.Velu@zodiacaerospace.com> Signed-off-by:
Arnaud Patard <apatard@hupstream.com> Signed-off-by:
-
Oliver Neukum authored
commit 2f338c8a upstream. cleanup() is not called if the last close() comes after disconnect(). That leads to a memory leak. Rectified by checking for an earlier disconnect() in release() Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Oliver Neukum authored
commit 24a85bae upstream. wdm_flush() returns unsanitized USB error codes. They must be cleaned up to before being anded to user space Signed-off-by:
-
Johan Hovold authored
commit 2c4d6bf2 upstream. Move usb_translate_errors from usb core to linux/usb.h as it is meant to be accessed from drivers. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Julia Lawall authored
commit abae41e6 upstream. aux_free is freed on all other exits from the function. By removing the return, we can benefit from the vfree already at the end of the function. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Kees Cook authored
commit 591bfc6b upstream. The HOWTO document needed updating for the new kernel versioning. The git URI for -next was updated as well. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Linus Torvalds authored
commit a70b52ec upstream. We had for some reason overlooked the AIO interface, and it didn't use the proper rw_verify_area() helper function that checks (for example) mandatory locking on the file, and that the size of the access doesn't cause us to overflow the provided offset limits etc. Instead, AIO did just the security_file_permission() thing (that rw_verify_area() also does) directly. This fixes it to do all the proper helper functions, which not only means that now mandatory file locking works with AIO too, we can actually remove lines of code. Reported-by:
Manish Honap <manish_honap_vit@yahoo.co.in> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
commit 31a67102 upstream. During early boot, when the scheduler hasn't really been fully set up, we really can't do blocking allocations because with certain (dubious) configurations the "might_resched()" calls can actually result in scheduling events. We could just make such users always use GFP_ATOMIC, but quite often the code that does the allocation isn't really aware of the fact that the scheduler isn't up yet, and forcing that kind of random knowledge on the initialization code is just annoying and not good for anybody. And we actually have a the 'gfp_allowed_mask' exactly for this reason: it's just that the kernel init sequence happens to set it to allow blocking allocations much too early. So move the 'gfp_allowed_mask' initialization from 'start_kernel()' (which is some of the earliest init code, and runs with preemption disabled for good reasons) into 'kernel_init()'. kernel_init() is run in the newly created thread that will become the 'init' process, as opposed to the early startup code that runs within the context of what will be the first idle thread. So by the time we reach 'kernel_init()', we know that the scheduler must be at least limping along, because we've already scheduled from the idle thread into the init thread. Reported-by:
Steven Rostedt <rostedt@goodmis.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
-
Dan Williams authored
commit fc25f79a upstream. OEM parameters [1] are parsed from the platform option-rom / efi driver. By default the driver was validating the parameters for the dual-controller case, but in single-controller case only the first set of parameters may be valid. Limit the validation to the number of actual controllers detected otherwise the driver may fail to parse the valid parameters leading to driver-load or runtime failures. [1] the platform specific set of phy address, configuration,and analog tuning values [stable v3.0+] Reported-by:
Dave Jiang <dave.jiang@intel.com> Tested-by:
Dan Williams <dan.j.williams@intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Heiko Carstens authored
commit d5e50a51 upstream. When setting the current task state to TASK_UNINTERRUPTIBLE this can race with a different cpu. The other cpu could set the task state after it inspected it (while it was still TASK_RUNNING) to TASK_RUNNING which would change the state from TASK_UNINTERRUPTIBLE to TASK_RUNNING again. This race was always present in the pfault interrupt code but didn't cause anything harmful before commit f2db2e6c "[S390] pfault: cpu hotplug vs missing completion interrupts" which relied on the fact that after setting the task state to TASK_UNINTERRUPTIBLE the task would really sleep. Since this is not necessarily the case the result may be a list corruption of the pfault_list or, as observed, a use-after-free bug while trying to access the task_struct of a task which terminated itself already. To fix this, we need to get a reference of the affected task when receiving the initial pfault interrupt and add special handling if we receive yet another initial pfault interrupt when the task is already enqueued in the pfault list. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Reviewed-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Steve Wise authored
commit 14b92228 upstream. Log a warning and drop the abort message. Otherwise we will do a bogus wake_up() and crash. Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Steve Wise authored
commit 0f1dcfae upstream. This fixes a race where an ingress abort fails to wake up the thread blocked in rdma_init() causing the app to hang. Signed-off-by:
-
Dan Carpenter authored
commit fefe1ed1 upstream. fault_reason - 0x20 == ARRAY_SIZE(irq_remap_fault_reasons) is one past the end of the array. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Joerg Roedel <joerg.roedel@amd.com> Cc: Youquan Song <youquan.song@intel.com> Cc: walter harms <wharms@bfs.de> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Link: http://lkml.kernel.org/r/20120513170938.GA4280@elgon.mountainSigned-off-by:
Ingo Molnar <mingo@kernel.org> [bwh: Backported to 3.2: s/irq_remap_fault_reasons/intr_remap_fault_reasons/] Signed-off-by:
-
Mark Brown authored
commit e81dba85 upstream. If we fail while registering a regulator make sure we release the supply for the regulator if there is one. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Yishai Hadas authored
commit c4870eb8 upstream. Commit bc3e53f6 ("mm: distinguish between mlocked and pinned pages") introduced a separate counter for pinned pages and used it in the IB stack. However, in ib_umem_get() the pinned counter is incremented, but ib_umem_release() wrongly decrements the locked counter. Fix this. Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Reviewed-by:
Christoph Lameter <cl@linux.com> Signed-off-by:
-
David Howells authored
commit 45de6767 upstream. Use the 32-bit compat keyctl() syscall wrapper on Sparc64 for Sparc32 binary compatibility. Without this, keyctl(KEYCTL_INSTANTIATE_IOV) is liable to malfunction as it uses an iovec array read from userspace - though the kernel should survive this as it checks pointers and sizes anyway. I think all the other keyctl() function should just work, provided (a) the top 32-bits of each 64-bit argument register are cleared prior to invoking the syscall routine, and the 32-bit address space is right at the 0-end of the 64-bit address space. Most of the arguments are 32-bit anyway, and so for those clearing is not required. Signed-off-by: David Howells <dhowells@redhat.com cc: "David S. Miller" <davem@davemloft.net> cc: sparclinux@vger.kernel.org Signed-off-by:
-
Tilman Schmidt authored
commit e055d03d upstream. An out-of-place "OK" response to the "AT+GMR" (get firmware version) command turns out to be, more often than not, a delayed response to a previous command rather than an actual error, so continue waiting for the version number in that case. Signed-off-by:
Tilman Schmidt <tilman@imap.cc> Signed-off-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 3.2: adjust indentation] Signed-off-by:
-
Tilman Schmidt authored
commit 62a1cfe0 upstream. If DISCONNECT_B3_IND was synthesized because of a DISCONNECT_REQ with existing logical connections, the connection state wasn't updated accordingly. Also the emitted DISCONNECT_B3_IND message wasn't included in the debug log as requested. This patch fixes both of these issues. Signed-off-by:
-
Tilman Schmidt authored
commit 8e618aad upstream. Introduce a global ratelimit for CAPI message dumps to protect against possible log flood. Drop the ratelimit for ignored messages which is now covered by the global one. Signed-off-by:
-
nagalakshmi.nandigama@lsi.com authored
commit e42fafc2 upstream. The ioc->pfacts member in the IOC structure is getting set to zero following a call to _base_get_ioc_facts due to the memset in that routine. So if the ioc->pfacts was read after a host reset, there would be a NULL pointer dereference. The routine _base_get_ioc_facts is called from context of host reset. The problem in _base_get_ioc_facts is the size of Mpi2IOCFactsReply is 64, whereas the sizeof "struct mpt2sas_facts" is 60, so there is a four byte overflow resulting from the memset. Also, there is memset in _base_get_port_facts using the incorrect structure, it should be "struct mpt2sas_port_facts" instead of Mpi2PortFactsReply. Signed-off-by:
Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Luis R. Rodriguez authored
commit 80007efe upstream. It has happened twice now where elaborate troubleshooting has undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0] has been set but yet net/wireless/db.txt was not updated. Despite the documentation on this it seems system integrators could use some more help with this, so throw out a kernel warning at boot time when their database is empty. This does mean that the error-prone system integrator won't likely realize the issue until they boot the machine but -- it does not seem to make sense to enable a build bug breaking random build testing. [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Youngsin Lee <youngsin@qualcomm.com> Cc: Raja Mani <rmani@qca.qualcomm.com> Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com> Cc: Vipin Mehta <vipimeht@qca.qualcomm.com> Cc: yahuan@qca.qualcomm.com Cc: jjan@qca.qualcomm.com Cc: vthiagar@qca.qualcomm.com Cc: henrykim@qualcomm.com Cc: jouni@qca.qualcomm.com Cc: athiruve@qca.qualcomm.com Cc: cjkim@qualcomm.com Cc: philipk@qca.qualcomm.com Cc: sunnykim@qualcomm.com Cc: sskwak@qualcomm.com Cc: kkim@qualcomm.com Cc: mattbyun@qualcomm.com Cc: ryanlee@qualcomm.com Cc: simbap@qualcomm.com Cc: krislee@qualcomm.com Cc: conner@qualcomm.com Cc: hojinkim@qualcomm.com Cc: honglee@qualcomm.com Cc: johnwkim@qualcomm.com Cc: jinyong@qca.qualcomm.com Signed-off-by:
Luis R. Rodriguez <mcgrof@frijolero.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Eric Paris authored
commit 154c50ca upstream. We reset the bool names and values array to NULL, but do not reset the number of entries in these arrays to 0. If we error out and then get back into this function we will walk these NULL pointers based on the belief that they are non-zero length. Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
-
Stephen M. Cameron authored
commit 9bc3711c upstream. Upgraded firmware on Smart Array P7xx (and some others) made them show up as SCSI revision 5 devices and this caused the driver to fail to map MSA2xxx logical drives to the correct bus/target/lun. A symptom of this would be that the target ID of the logical drives as presented by the external storage array is ignored, and all such logical drives are assigned to target zero, differentiated only by LUN. Some multipath software reportedly does not deal well with this behavior, failing to recognize different paths to the same device as such. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
Scott Teel <scott.teel@hp.com> Signed-off-by:
-
Maxim Levitsky authored
commit 452380ef upstream. major == 0 allocates dynamic major, not major == -1 Signed-off-by:
Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
Chris Metcalf authored
commit e6d9668e upstream. Some discussion with the glibc mailing lists revealed that this was necessary for 64-bit platforms with MIPS-like sign-extension rules for 32-bit values. The original symptom was that passing (uid_t)-1 to setreuid() was failing in programs linked -pthread because of the "setxid" mechanism for passing setxid-type function arguments to the syscall code. SYSCALL_WRAPPERS handles ensuring that all syscall arguments end up with proper sign-extension and is thus the appropriate fix for this problem. On other platforms (s390, powerpc, sparc64, and mips) this was fixed in 2.6.28.6. The general issue is tracked as CVE-2009-0029. Signed-off-by:
Chris Metcalf <cmetcalf@tilera.com> Signed-off-by:
-
Chris Metcalf authored
commit 8d695143 upstream. Looks like a cut and paste bug from the x86 version. Signed-off-by:
-
