- 03 Feb, 2012 40 commits
-
-
Andiry Xu authored
commit cf840551 upstream. When a TD length mismatch is found during isoc TRB enqueue, it directly returns -EINVAL. However, isoc transfer is partially enqueued at this time, and the ring should be cleared. This should be backported to kernels as old as 2.6.36, which contain the commit 522989a2 "xhci: Fix failed enqueue in the middle of isoch TD." Signed-off-by:
Andiry Xu <andiry.xu@amd.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sarah Sharp authored
commit d0cd5d48 upstream. The xHCI hub port code gets passed a zero-based port number by the USB core. It then adds one to in order to find a device slot by port number and device speed by calling xhci_find_slot_id_by_port. That function clearly states it requires a one-based port number. The xHCI port status change event handler was using a zero-based port number that it got from find_faked_portnum_from_hw_portnum, not a one-based port number. This lead to the doorbells never being rung for a device after a resume, or worse, a different device with the same speed having its doorbell rung (which could lead to bad power management in the xHCI host controller). This patch should be backported to kernels as old as 2.6.39. Signed-off-by:
-
Julia Lawall authored
commit 2492c6e6 upstream. Add missing iounmap in error handling code, in a case where the function already preforms iounmap on some other execution path. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression e; statement S,S1; int ret; @@ e = \(ioremap\|ioremap_nocache\)(...) ... when != iounmap(e) if (<+...e...+>) S ... when any when != iounmap(e) *if (...) { ... when != iounmap(e) return ...; } ... when any iounmap(e); // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Andiry Xu authored
commit a8501639 upstream. Fix some endian issues for storage gadgets. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alexander Shishkin authored
commit 37fd3710 upstream. UDC core will call disconnect() and unbind() for us upon the gadget removal, so we should not do it ourselves. Otherwise, a composite gadget will explode, for example. Others might too. This was introduced during conversion to new style gadget in 2c7f0989 (usb: gadget: langwell: convert to new style). Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: linux-usb@vger.kernel.org Signed-off-by:
-
Harrison Metzger authored
commit 1097cceb upstream. This changes the max length for the usb seven segment delcom device to 8 from 6. Delcom has both 6 and 8 variants and having 8 works fine with devices which are only 6. Signed-off-by:
Harrison Metzger <harrisonmetz@gmail.com> Signed-off-by:
Stuart Pook <stuart@acm.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit b3ef051d upstream. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=784345Reported-by:
Francis Moreau <francis.moro@gmail.com> Reported-and-tested-by:
Christian D <chrisudeussen@gmail.com> Reported-and-tested-by:
Jimmy Dorff <jdorff@phy.duke.edu> Reported-and-tested-by: collura@ieee.org Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Ryan Mallon authored
commit bf9c05d5 upstream. The assignment of handle in vmw_framebuffer_create_handle doesn't actually do anything useful and is incorrectly assigning an integer value to a pointer argument. It appears that this is a typo and should be dereferencing handle rather than assigning to it directly. This fixes a bug where an undefined handle value is potentially returned to user-space. Signed-off-by:
Ryan Mallon <rmallon@gmail.com> Reviewed-by: Jakob Bornecrantz<jakob@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Johannes Berg authored
commit b49ba04a upstream. When an interrupt comes in, we read the reason bits and collect them into "trans_pcie->inta". This happens with the spinlock held. However, there's a bug resetting this variable -- that happens after the spinlock has been released. This means that it is possible for interrupts to be missed if the reset happens after some other interrupt reasons were already added to the variable. I found this by code inspection, looking for a reason that we sometimes see random commands time out. It seems possible that this causes such behaviour, but I can't say for sure right now since it happens extremely infrequently on my test systems. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Lucas Kannebley Tavares authored
commit 26aa38ca upstream. There was an error on the jsm driver that would cause it to be unable to recover after a second error is detected. At the first error, the device recovers properly: [72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0 [72521.485695] EEH: This PCI device has failed 1 times in the last hour: ... [72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm [72532.105689] jsm: Port 3 added However, at the second error, it cascades until EEH disables the device: [72631.229549] Call Trace: ... [72641.725687] jsm: Port 3 added [72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0 [72641.725698] EEH: This PCI device has failed 3 times in the last hour: It was caused because the PCI state was not being saved after the first restore. Therefore, at the second recovery the PCI state would not be restored. Signed-off-by:
Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com> Signed-off-by:
Breno Leitao <brenohl@br.ibm.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
Rabin Vincent authored
commit ef605fdb upstream. Protect against pl011_console_write() and the interrupt for the console UART running concurrently on different CPUs. Otherwise the console_write could spin for a long time waiting for the UART to become not busy, while the other CPU continuously services UART interrupts and keeps the UART busy. The checks for sysrq and oops_in_progress are taken from 8250.c. Signed-off-by:
Rabin Vincent <rabin.vincent@stericsson.com> Reviewed-by:
Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Reviewed-by:
Bibek Basu <bibek.basu@stericsson.com> Reviewed-by:
Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jiri Slaby authored
commit 0eee50af upstream. Commit 74c21077 (serial: Use block_til_ready helper) and its fixup 3f582b8c (serial: fix termios settings in open) introduced a regression on UV systems. The serial eventually freezes while being used. It's completely unpredictable and sometimes needs a heap of traffic to happen first. To reproduce this, yast installation was used as it turned out to be pretty reliable in reproducing. Especially during installation process where one doesn't have an SSH daemon running. And no monitor as the HW is completely headless. So this was fun to find. Given the machine doesn't boot on vanilla before 2.6.36 final. (And the commits above are older.) Unless there is some bad race in the code, the hardware seems to be pretty broken. Otherwise pure MSR read should not cause such a bug, or? So to prevent the bug, revert to the old behavior. I.e. read modem status only if we really have to -- for non-CLOCAL set serials. Non-CLOCAL works on this hardware OK, I tried. See? I don't. And document that shit. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> References: https://lkml.org/lkml/2011/12/6/573 References: https://bugzilla.novell.com/show_bug.cgi?id=718518Signed-off-by:
-
Eric W. Biederman authored
commit 6d443d84 upstream. Calling edge_remove_sysfs_attrs from edge_disconnect is too late as the device has already been removed from sysfs. Do the simple and obvious thing and make edge_remove_sysfs_attrs the port_remove method. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Reported-by:
Wolfgang Frisch <wfpub@roembden.net> Signed-off-by:
-
Felipe Balbi authored
commit 68d8a781 upstream. The way our code was written, we should never have a DWC3_EP_PENDING_REQUEST flag set out of a Data Phase and the code in __dwc3_gadget_ep0_queue() did not reflect that situation properly. Tidy up that case to avoid any possible mistakes when starting requests for IRQs which are long gone. Signed-off-by:
-
Dan Williams authored
commit 074cc735 upstream. More ports we now know how to talk to. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Bjørn Mork authored
commit e8537bd2 upstream. using a separate read and write mutex for locking is sufficient to make the driver accept simultaneous read and write. This improves useability a lot. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Bjørn Mork authored
commit c428b70c upstream. wdm_in_callback() will also touch this field, so we cannot change it without locking Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Alan Cox authored
commit 2353f806 upstream. 0x04d8, 0x000a: Hornby Elite Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Peter Naulls authored
commit fc216ec3 upstream. I tested this against 2.6.39 in the Ubuntu kernel, however I see the IDs are not in latest 3.2 git. This adds IDs for the FTDI controller in the Rainforest Automation Zigbee dongle. Signed-off-by:
Peter Naulls <peter@chocky.org> Signed-off-by:
-
Peter Korsgaard authored
commit 55f13aea upstream. Port A for JTAG, port B for serial. Signed-off-by:
Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by:
-
Johan Hovold authored
commit 108e02b1 upstream. Fix regression introduced by commit b1ffb4c8 ("USB: Fix Corruption issue in USB ftdi driver ftdi_sio.c") which caused the termios settings to no longer be initialised at open. Consequently it was no longer possible to set the port to the default speed of 9600 baud without first changing to another baud rate and back again. Reported-by:
Roland Ramthun <mail@roland-ramthun.de> Signed-off-by:
Johan Hovold <jhovold@gmail.com> Tested-by:
-
Johan Hovold authored
commit eb833a9e upstream. Return EINVAL if new baud_base does not match the current one. The baud_base is device specific and can not be changed. This restores the old (pre-2005) behaviour which was changed due to a misunderstanding regarding this fact (see https://lkml.org/lkml/2005/1/20/84). Reported-by:
Torbjörn Lofterud <torbjorn@pi.nxs.se> Signed-off-by:
-
Kentaro Matsuyama authored
commit e423d740 upstream. Add vendor and product ID for USB 3G/LTE modem of docomo L-02C Signed-off-by:
Kentaro Matsuyama <kentaro.matsuyama@gmail.com> Signed-off-by:
-
nagalakshmi.nandigama@lsi.com authored
commit 2cb6fc8c upstream. Removed redundant calling of _scsih_probe_devices() from _scsih_probe as it is getting called from _scsih_scan_finished. Also moved the function scsi_scan_host(shost) to get called after the volumes on warp drive are reported to the OS. Otherwise by the time the (ioc->hide_drives) flags is set, the volumes on warp drive are reported to the OS already. Also modified the initialization of reply queues only in case of driver load time in the function _base_make_ioc_operational(). Signed-off-by:
Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
David Vrabel authored
commit 7a7546b3 upstream. If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct xen_spinlock is 32 bits. When a spin lock is contended and xl->spinners is modified the two bytes immediately after the spin lock would be corrupted. This is a regression caused by 84eb950d (x86, ticketlock: Clean up types and accessors) which reduced the size of arch_spinlock_t. Fix this by making xl->spinners a u8 if NR_CPUS < 256. A BUILD_BUG_ON() is also added to check the sizes of the two structures are compatible. In many cases this was not noticable as there would often be padding bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK, CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled). The bnx2 driver is affected. In struct bnx2, phy_lock and indirect_lock may have no padding after them. Contention on phy_lock would corrupt indirect_lock making it appear locked and the driver would deadlock. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Jeremy Fitzhardinge <jeremy@goop.org> Acked-by:
Ian Campbell <ian.campbell@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Eric W. Biederman authored
commit ce597919 upstream. Recently an OOPS was observed from the usb serial io_ti driver when it tried to remove sysfs directories. Upon investigation it turns out this driver was always buggy and that a recent sysfs change had stopped guarding itself against removing attributes from sysfs directories that had already been removed. :( Historically we have been silent about attempting to files from nonexistent sysfs directories and have politely returned error codes. That has resulted in people writing broken code that ignores the error codes. Issue a kernel WARNING and a stack backtrace to make it clear in no uncertain terms that abusing sysfs is not ok, and the callers need to fix their code. This change transforms the io_ti OOPS into a more comprehensible error message and stack backtrace. Signed-off-by:
-
Will Deacon authored
commit 612539e8 upstream. On v7, we use the same cache maintenance instructions for data lines as for unified lines. This was not the case for v6, where HARVARD_CACHE was defined to indicate the L1 cache topology. This patch removes the erroneous compile-time check for HARVARD_CACHE in proc-v7.S, ensuring that we perform I-side invalidation at boot. Reported-and-Acked-by:
Shawn Guo <shawn.guo@linaro.org> Acked-by:
Catalin Marinas <Catalin.Marinas@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Srinidhi KASAGAR authored
commit d65015f7 upstream. This applies ARM errata 764369 for all ux500 platforms. Signed-off-by:
-
Nicolas Ferre authored
commit 3e90772f upstream. Currently setting it to PQFP changes subtype to BGA as subtypes are swapped in at91rm9200_set_type(). Wrong subtype causes GPIO bank D not to work at all. After this fix, subtype is still set as unknown. But board code should fill it in with proper value. Another information is thus printed. Bug discovery and first implementation made by Veli-Pekka Peltola. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Eric Anholt authored
commit 04115a9d upstream. Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Keith Packard <keithp@keithp.com> Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Paulo Zanoni authored
commit ba68e086 upstream. This is a revert of 81a14b46. We already set the mode polarity using the SDVO commands with struct intel_sdvo_dtd. We have at least 3 bugs that get fixed with this patch. The documentation, despite not clear, can also be interpreted in a way that suggests this patch is needed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=15766 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42174 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43333Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniel Vetter authored
commit 4cd53c0c upstream. Two things seem to do the trick on my ivb machine here: - prevent the gt from powering down while waiting for seqno notification interrupts by grabbing the force_wake in get_irq (and dropping it in put_irq again). - ordering writes from the ring's CS by reading a CS register, ACTHD seems to work. Only the blt&bsd ring on ivb seem to be massively affected by this, but for paranoia do this dance also on the render ring and on snb (i.e. all gpus with forcewake). Tested with Eric's glCopyPixels loop which without this patch scores a missed irq every few seconds. This patch needs my forcewake rework to use a spinlock instead of dev->struct_mutex. After crawling through docs a lot I've found the following nugget: Internal doc "SNB GT PM Programming Guide", Section 4.3.1: "GT does not generate interrupts while in RC6 (by design)" So it looks like rc6 and irq generation are indeed related. v2: Improve the comment per Eugeni Dodonov's suggestion. v3: Add the documentation snipped. Also restrict the w/a to ivb only for -fixes, as suggested by Keith Packard. Cc: Eric Anholt <eric@anholt.net> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Eugeni Dodonov <eugeni.dodonov@intel.com> Tested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Takashi Iwai authored
commit b3a81520 upstream. The very same problem is seen on Haier W18 laptop with ALC861 as seen on ASUS A6Rp, which was fixed by the commit 3b25eb69. Now we just need to add a new SSID entry pointing to the same fixup. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42656Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 3b25eb69 upstream. The refactoring of Realtek codec driver in 3.2 kernel caused a regression for ASUS A6Rp laptop; it doesn't give any output. The reason was that this machine has a secret master mute (or EAPD) control via NID 0x0f VREF. Setting VREF50 on this node makes the sound working again. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42588Signed-off-by:
-
Gustavo Maciel Dias Vieira authored
commit a6a600d1 upstream. HP laptop models with buggy BIOS are apparently frequent, including machines with different codecs. Set the polarity of the mute led based on the SSID and include an entry for the HP Mini 110-3100. Signed-off-by:
Gustavo Maciel Dias Vieira <gustavo@sagui.org> Tested-by:
Predrag Ivanovic <predivan@open.telekom.rs> Signed-off-by:
-
Andreas Schwab authored
commit 2a353506 upstream. Passing the address of a variable as an operand to an asm statement doesn't mark the value of this variable as used, so gcc may optimize its initialisation away. Fix this by using the "m" constraint instead. Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Andreas Herrmann authored
commit 5b68edc9 upstream. We've decided to provide CPU family specific container files (starting with CPU family 15h). E.g. for family 15h we have to load microcode_amd_fam15h.bin instead of microcode_amd.bin Rationale is that starting with family 15h patch size is larger than 2KB which was hard coded as maximum patch size in various microcode loaders (not just Linux). Container files which include patches larger than 2KB cause different kinds of trouble with such old patch loaders. Thus we have to ensure that the default container file provides only patches with size less than 2KB. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Cc: Borislav Petkov <borislav.petkov@amd.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20120120164412.GD24508@alberich.amd.com [ documented the naming convention and tidied the code a bit. ] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Russ Anderson authored
commit 5a51467b upstream. uv_gpa_to_soc_phys_ram() was inadvertently ignoring the shift values. This fix takes the shift into account. Signed-off-by:
Russ Anderson <rja@sgi.com> Link: http://lkml.kernel.org/r/20120119020753.GA7228@sgi.comSigned-off-by:
-
Cliff Wickman authored
commit d2ebc71d upstream. Initialize two spinlocks in tlb_uv.c and also properly define/initialize the uv_irq_lock. The lack of explicit initialization seems to be functionally harmless, but it is diagnosed when these are turned on: CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_LOCKDEP=y Signed-off-by:
Cliff Wickman <cpw@sgi.com> Cc: Dimitri Sivanich <sivanich@sgi.com> Link: http://lkml.kernel.org/r/E1RnXd1-0003wU-PM@eag09.americas.sgi.com [ Added the uv_irq_lock initialization fix by Dimitri Sivanich ] Signed-off-by:
-
Stefan Berger authored
commit a927b813 upstream. This patch adds a delay after aborting a command. Some TPMs need this and will not process the subsequent command correctly otherwise. It's worth noting that a TPM randomly failing to process a command, maps to randomly failing suspend/resume operations. Signed-off-by:
Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
-
