- 23 Mar, 2011 40 commits
-
-
Nicholas Bellinger authored
commit 904f0bc4 upstream. the target infrastructure fails to send the correct conventional size to READ_CAPACITY that force a retry with READ_CAPACITY_16, which reads the capacity for devices > 2TB. Fix by adding the correct return to trigger RC(16). Reported-by:
Ben Jarvis <bjarvismn@gmail.com> Signed-off-by:
Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Vasily Khoruzhick authored
commit 64c25a92 upstream. MONO was renamed to MONO1. Signed-off-by:
Vasily Khoruzhick <anarsoul@gmail.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Przemyslaw Bruski authored
commit efed5f26 upstream. Clear input settings before initialization. Signed-off-by:
Przemyslaw Bruski <pbruskispam@op.pl> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Przemyslaw Bruski authored
commit f164753a upstream. SDPIF status retrieval always returned the default settings instead of the actual ones. Signed-off-by:
-
Przemyslaw Bruski authored
commit 4c1847e8 upstream. SPDIF status mask creation was incorrect. Signed-off-by:
-
Takashi Iwai authored
commit 98d21df4 upstream. loopback_pos_update() can be called in the timer callback, thus the lock held should be irq-safe. Otherwise you'll get AB/BA deadlock together with substream->self_group.lock. Reported-and-tested-by:
Knut Petersen <Knut_Petersen@t-online.de> Signed-off-by:
-
Dan Rosenberg authored
commit 4a122c10 upstream. The user-supplied index into the adapters array needs to be checked, or an out-of-bounds kernel pointer could be accessed and used, leading to potentially exploitable memory corruption. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
-
Ben Hutchings authored
commit 0f12a4e2 upstream. Commit 280c73d3 ("PCI: centralize the capabilities code in pci-sysfs.c") changed the initialisation of the "rom" and "vpd" attributes, and made the failure path for the "vpd" attribute incorrect. We must free the new attribute structure (attr), but instead we currently free dev->vpd->attr. That will normally be NULL, resulting in a memory leak, but it might be a stale pointer, resulting in a double-free. Found by inspection; compile-tested only. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jiri Slaby authored
commit 87e3dc38 upstream. Some broken BIOSes on ICH4 chipset report an ACPI region which is in conflict with legacy IDE ports when ACPI is disabled. Even though the regions overlap, IDE ports are working correctly (we cannot find out the decoding rules on chipsets). So the only problem is the reported region itself, if we don't reserve the region in the quirk everything works as expected. This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO which is 0x1000. Some regions might be (and are by a fast google query) below this border, but the only difference is that they won't be reserved anymore. They should still work though the same as before. The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl): pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f] At 0x0100 a 128 bytes long ACPI region is reported in the quirk for ICH4. ata_piix then fails to find disks because the IDE legacy ports are zeroed: ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007]) References: https://bugzilla.novell.com/show_bug.cgi?id=558740Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by:
-
Jiri Slaby authored
commit cdb97558 upstream. Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN and GPIO_EN bits are set to 1. Add checks for these bits into the quirks prior to the region creation. While at it, name the constants by macros. Signed-off-by:
-
Brandeburg, Jesse authored
commit b99af4b0 upstream. Revert commit 7eb93b17 Author: Yu Zhao <yu.zhao@intel.com> Date: Fri Apr 3 15:18:11 2009 +0800 PCI: SR-IOV quirk for Intel 82576 NIC If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash BAR and program the SR-IOV BARs to use the old Flash Memory Space. Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet section 7.9.2.14.2 for details. http://download.intel.com/design/network/datashts/82576_Datasheet.pdfSigned-off-by:
Yu Zhao <yu.zhao@intel.com> Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Yu Zhao <yu.zhao@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 270fdc07 upstream. As reported on http://ubuntuforums.org/showthread.php?t=1594007 the PKB-1700 needs same special handling as WKB-2000. This change is originally based on patch posted by user asmoore82 on the Ubuntu forums. Signed-off-by:
Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Henrik Rydberg authored
commit 2d9ca4e9 upstream. The magic trackpad and mouse both report touch orientation in opposite direction to the bcm5974 driver and what is written in Documents/input/multi-touch-protocol.txt. This patch reverts the direction, so that all in-kernel devices with this feature behave the same way. Since no known application has been utilizing this information yet, it seems appropriate also for stable. Cc: Michael Poole <mdpoole@troilus.org> Signed-off-by:
Henrik Rydberg <rydberg@euromail.se> Acked-by:
Chase Douglas <chase.douglas@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit 584c0c4c upstream. Currently some special handling for the unusual case like dual-ADCs or a single-input-src is done in the tree-parse time in set_capture_mixer(). But this setup could be overwritten by static init verbs. This patch moves the initialization into the init phase so that such input-src setup won't be lost. Signed-off-by:
-
Vitaliy Kulikov authored
commit 094a4245 upstream. When the mux for digital mic is different from the mux for other mics, the current auto-parser doesn't handle them in a right way but provides only one mic. This patch fixes the issue. Signed-off-by:
Vitaliy Kulikov <Vitaliy.Kulikov@idt.com> Signed-off-by:
-
David Henningsson authored
commit 0a3fabe3 upstream. Do not initialize again the what has already been initialized as multi outs, as this breaks surround speakers. Tested-by:
Bartłomiej Żogała <nusch88@gmail.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
David Henningsson authored
commit 7e59e097 upstream. Without this change, a volume control named "Surround" or "Side" would get an unnecessary index, causing it to be ignored by the vmaster and PulseAudio. Tested-by:
-
David Henningsson authored
commit ebbeb3d6 upstream. When more than one pair of internal speakers is present, allow names according to their channels. Tested-by:
-
David Henningsson authored
commit 32eea388 upstream. The pin config values would change the association instead of the sequence, this commit fixes that up. Tested-by:
-
Paul Zimmerman authored
commit 500132a0 upstream. Use the Mult and bMaxBurst values from the endpoint companion descriptor to calculate the max length of an isoc transfer. Add USB_SS_MULT macro to access Mult field of bmAttributes, at Sarah's suggestion. This patch should be queued for the 2.6.36 and 2.6.37 stable trees, since those were the first kernels to have isochronous support for SuperSpeed devices. Signed-off-by:
Paul Zimmerman <paulz@synopsys.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
Sarah Sharp authored
commit 01a1fdb9 upstream. When an endpoint stalls, we need to update the xHCI host's internal dequeue pointer to move it past the stalled transfer. This includes updating the cycle bit (TRB ownership bit) if we have moved the dequeue pointer past a link TRB with the toggle cycle bit set. When we're trying to find the new dequeue segment, find_trb_seg() is supposed to keep track of whether we've passed any link TRBs with the toggle cycle bit set. However, this while loop's body while (cur_seg->trbs > trb || &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) { Will never get executed if the ring only contains one segment. find_trb_seg() will return immediately, without updating the new cycle bit. Since find_trb_seg() has no idea where in the segment the TD that stalled was, make the caller, xhci_find_new_dequeue_state(), check for this special case and update the cycle bit accordingly. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by:
-
Sarah Sharp authored
commit bf161e85 upstream. When an endpoint stalls, the xHCI driver must move the endpoint ring's dequeue pointer past the stalled transfer. To do that, the driver issues a Set TR Dequeue Pointer command, which will complete some time later. Takashi was having issues with USB 1.1 audio devices that stalled, and his analysis of the code was that the old code would not update the xHCI driver's ring dequeue pointer after the command completes. However, the dequeue pointer is set in xhci_find_new_dequeue_state(), just before the set command is issued to the hardware. Setting the dequeue pointer before the Set TR Dequeue Pointer command completes is a dangerous thing to do, since the xHCI hardware can fail the command. Instead, store the new dequeue pointer in the xhci_virt_ep structure, and update the ring's dequeue pointer when the Set TR dequeue pointer command completes. While we're at it, make sure we can't queue another Set TR Dequeue Command while the first one is still being processed. This just won't work with the internal xHCI state code. I'm still not sure if this is the right thing to do, since we might have a case where a driver queues multiple URBs to a control ring, one of the URBs Stalls, and then the driver tries to cancel the second URB. There may be a race condition there where the xHCI driver might try to issue multiple Set TR Dequeue Pointer commands, but I would have to think very hard about how the Stop Endpoint and cancellation code works. Keep the fix simple until when/if we run into that case. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by:
-
Alan Stern authored
commit 9b37596a upstream. The hcd->state variable is a disaster. It's not clearly owned by either usbcore or the host controller drivers, and they both change it from time to time, potentially stepping on each other's toes. It's not protected by any locks. And there's no mechanism to prevent it from going through an invalid transition. This patch (as1451) takes a first step toward fixing these problems. As it turns out, usbcore uses hcd->state for essentially only two things: checking whether the controller's root hub is running and checking whether the controller has died. Therefore the patch adds two new atomic bitflags to the hcd structure, to store these pieces of information. The new flags are used only by usbcore, and a private spinlock prevents invalid combinations (a dead controller's root hub cannot be running). The patch does not change the places where usbcore sets hcd->state, since HCDs may depend on them. Furthermore, there is one place in usb_hcd_irq() where usbcore still must use hcd->state: An HCD's interrupt handler can implicitly indicate that the controller died by setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a big improvement over the current code. The patch makes one other change. The hcd_bus_suspend() and hcd_bus_resume() routines now check first whether the host controller has died; if it has then they return immediately without calling the HCD's bus_suspend or bus_resume methods. This fixes the major problem reported in Bugzilla #29902: The system fails to suspend after a host controller dies during system resume. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Alex Terekhov <a.terekhov@gmail.com> Signed-off-by:
-
Matthew Garrett authored
commit 294d95f2 upstream. If a device plug/unplug is detected on an ATI SB700 USB controller in D3, it appears to set the port status register but not the controller status register. As a result we'll fail to detect the plug event. Check the port status register on resume as well in order to catch this case. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit b14e840d upstream. The document says: |2.1 Problem description | When at least two USB devices are simultaneously running, it is observed that | sometimes the INT corresponding to one of the USB devices stops occurring. This may | be observed sometimes with USB-to-serial or USB-to-network devices. | The problem is not noticed when only USB mass storage devices are running. |2.2 Implication | This issue is because of the clearing of the respective Done Map bit on reading the ATL | PTD Done Map register when an INT is generated by another PTD completion, but is not | found set on that read access. In this situation, the respective Done Map bit will remain | reset and no further INT will be asserted so the data transfer corresponding to that USB | device will stop. |2.3 Workaround | An SOF INT can be used instead of an ATL INT with polling on Done bits. A time-out can | be implemented and if a certain Done bit is never set, verification of the PTD completion | can be done by reading PTD contents (valid bit). | This is a proven workaround implemented in software. Russell King run into this with an USB-to-serial converter. This patch implements his suggestion to enable the high frequent SOF interrupt only at the time we have ATL packages queued. It goes even one step further and enables the SOF interrupt only if we have more than one ATL packet queued at the same time. Tested-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Larry Finger authored
commit 6410db59 upstream. The driver for the RTL8187L chips returns IEEE80211_TX_STAT_ACK for all packets, even if the maximum number of retries was exhausted. In addition it fails to setup max_rates in the ieee80211_hw struct, This behavior may be responsible for the problems noted in Bug 14168. As the bug is very old, testers have not been found, and I do not have the case where the indicated signal is less than -70 dBm. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Acked-by:
Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Felipe Contreras authored
commit ab42abf3 upstream. We need to protect not only the dmm_map list, but the individual map_obj's, otherwise, we might be building the scatter-gather list with garbage. So, use the existing proc_lock for that. I observed race conditions which caused kernel panics while running stress tests, also, Tuomas Kulve found it happening quite often in Gumstix Over. This patch fixes those. Cc: Tuomas Kulve <tuomas@kulve.fi> Signed-off-by:
Felipe Contreras <felipe.contreras@nokia.com> Signed-off-by:
Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by:
-
Jeff Mahoney authored
commit cecf826d upstream. linux/delay.h is pulled in somehow on x86 but not on ia64 or powerpc. This fixes a build failure on those arches since they use [mu]delay. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
wangyanqing authored
commit d0781383 upstream. I picked up a new DAK-780EX(professional digitl reverb/mix system), which use CH341T chipset to communication with computer on 3/2011 and the CH341T's vendor code is 1a86 Looking up the CH341T's vendor and product id's I see: 1a86 QinHeng Electronics 5523 CH341 in serial mode, usb to serial port converter CH341T,CH341 are the products of the same company, maybe have some common hardware, and I test the ch341.c works well with CH341T Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 7a89e4cb upstream. On https://bugs.launchpad.net/ubuntu/+source/linux/+bug/636091, one of the cases reported is a big timeout on option_send_setup, which causes some side effects as tty_lock is held. Looks like some of ZTE MF626 devices also don't like the RTS/DTR setting in option_send_setup, like with 4G XS Stick W14. The reporter confirms which this it solves the long freezes in his system. Signed-off-by:
-
Jiri Slaby authored
commit 6960f40a upstream. Make sure that we check the return value of tty_port_tty_get. Sometimes it may return NULL and we later dereference that. The only place here is in kobil_read_int_callback, so fix it. Signed-off-by:
-
Alan Stern authored
commit 969e3033 upstream. When a driver doesn't know how much data a device is going to send, the buffer size should be at least as big as the endpoint's maxpacket value. The serial drivers don't follow this rule; many of them request only 256-byte bulk-in buffers. As a result, they suffer overflow errors if a high-speed device wants to send a lot of data, because high-speed bulk endpoints are required to have a maxpacket size of 512. This patch (as1450) fixes the problem by using the driver's bulk_in_size value as a minimum, always allocating buffers no smaller than the endpoint's maxpacket size. Signed-off-by:
Flynn Marquardt <flynn@flynnux.de> Signed-off-by:
-
Yin Kangkai authored
commit 0d0389e5 upstream. In 8250.c original ns16550 autoconfig code, we change the divisor latch when we goto to high speed mode, we're assuming the previous speed is legacy. This some times is not true. For example in a system with both CONFIG_SERIAL_8250 and CONFIG_SERIAL_8250_PNP set, in this case, the code (autoconfig) will be called twice, one in serial8250_init/probe() and the other is from serial_pnp_probe. When serial_pnp_probe calls the autoconfig for NS16550A, it's already in high speed mode, change the divisor latch (quot << 3) in this case will make the UART console garbled. CC: Greg Kroah-Hartman <greg@kroah.com> CC: David Woodhouse <dwmw2@infradead.org> CC: linux-kernel@vger.kernel.org Signed-off-by:
Yin Kangkai <kangkai.yin@linux.intel.com> Signed-off-by:
-
Yin Kangkai authored
commit 95926d2d upstream. For any reason if the NS16550A was not work in high speed mode (e.g. we hold NS16550A from going to high speed mode in autoconfig_16550a()), now we are resume from suspend, we should also set the uartclk to the correct value. Otherwise it is still the old 1843200 and that will bring issues. CC: Greg Kroah-Hartman <greg@kroah.com> CC: David Woodhouse <dwmw2@infradead.org> CC: linux-kernel@vger.kernel.org Signed-off-by:
-
Dan Carpenter authored
commit d8653d30 upstream. This is used to store the spi_device ->modalias so they have to be the same size. SPI_NAME_SIZE is 32. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Felix Fietkau authored
commit 2e286947 upstream. The hardware rx filter flag triggered by FIF_PROMISC_IN_BSS is overly broad and covers even frames with PHY errors. When this flag is enabled, this message shows up frequently during scanning or hardware resets: ath: Could not stop RX, we could be confusing the DMA engine when we start RX up Since promiscuous mode is usually not particularly useful, yet enabled by default by bridging (either used normally in 4-addr mode, or with hacks for various virtualization software), we should sacrifice it for better reliability during normal operation. This patch leaves it enabled if there are active monitor mode interfaces, since it's very useful for debugging. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Senthil Balasubramanian authored
commit ac45c12d upstream. There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
-
Senthil Balasubramanian authored
commit 0a8d7cb0 upstream. We need to read and backup AR_WA register value permanently and reading this after the chip is awakened results in this register being zeroed out. This seems to fix the ASPM with L1 enabled issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. Signed-off-by:
-
Chris Wilson authored
commit 007c80a5 upstream. As detect will use hw registers and may modify structures, it needs to be serialised by use of the dev->mode_config.mutex. Make it so. Otherwise, we may cause random crashes as the sysfs file is queried whilst a concurrent hotplug poll is being run. For example: [ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100 [ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.190020] *pde = 00000000 [ 1189.190104] Oops: 0000 [#1] SMP [ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status [ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 1189.192007] [ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701 [ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0 [ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915] [ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004 [ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c [ 1189.192007] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000) [ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007] e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00 [ 1189.192007] e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e [ 1189.192007] 30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000 [ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007] [<e0c22203>] ? intel_tv_detect+0x89/0x12d [i915] [ 1189.192007] [<e0a9dcef>] ? status_show+0x0/0x2f [drm] [ 1189.192007] [<e0a9dd03>] ? status_show+0x14/0x2f [drm] [Digression: what is upowerd doing reading those power hungry files?] Reported-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 942b0e95 upstream. Typo in the aspect scale setup. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
