- 14 Apr, 2014 40 commits
-
-
Grazvydas Ignotas authored
commit c1c52848 upstream. omapfb does not currently set pseudo palette correctly for color depths above 16bpp, making red text invisible, command like echo -e '\e[0;31mRED' > /dev/tty1 will display nothing on framebuffer console in 24bpp mode. This is because temporary variable is declared incorrectly, fix it. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Qiang Huang <h.huangqiang@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nithin Sujir authored
commit df465abf upstream. Some systems that don't need wake-on-lan may choose to power down the chip on system standby. Upon resume, the power on causes the boot code to startup and initialize the hardware. On one new platform, this is causing the device to go into a bad state due to a race between the driver and boot code, once every several hundred resumes. The same race exists on open since we come up from a power on. This patch adds a wait for boot code signature at the beginning of tg3_init_hw() which is common to both cases. If there has not been a power-off or the boot code has already completed, the signature will be present and poll_fw() returns immediately. Also return immediately if the device does not have firmware. Signed-off-by:
Nithin Nayak Sujir <nsujir@broadcom.com> Signed-off-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Michael Chan authored
commit 091f0ea3 upstream. After Power-on-reset, the 5719's TX DMA length registers may contain uninitialized values and cause TX DMA to stall. Check for invalid values and set a register bit to flush the TX channels. The bit needs to be turned off after the DMA channels have been flushed. Signed-off-by:
-
Dan Carpenter authored
commit 3806b45b upstream. The "rpm * div" operations can overflow here, so this patch adds an upper limit to rpm to prevent that. Jean Delvare helped me with this patch. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Roger Lucas <vt8231@hiddenengine.co.uk> Signed-off-by:
Jean Delvare <khali@linux-fr.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Henrik Rydberg authored
commit 25f2bd7f upstream. The crash reported and investigated in commit 5f4513 turned out to be caused by a change to the read interface on newer (2012) SMCs. Tests by Chris show that simply reading the data valid line is enough for the problem to go away. Additional tests show that the newer SMCs no longer wait for the number of requested bytes, but start sending data right away. Apparently the number of bytes to read is no longer specified as before, but instead found out by reading until end of data. Failure to read until end of data confuses the state machine, which eventually causes the crash. As a remedy, assuming bit0 is the read valid line, make sure there is nothing more to read before leaving the read function. Tested to resolve the original problem, and runtested on MBA3,1, MBP4,1, MBP8,2, MBP10,1, MBP10,2. The patch seems to have no effect on machines before 2012. Tested-by:
Chris Murphy <chris@cmurf.com> Signed-off-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Guenter Roeck authored
commit 1102dcab upstream. TjMax for the CE4100 series of Atom CPUs was previously reported to be 110 degrees C. cpuinfo logs on the web show existing CPU types CE4110, CE4150, and CE4170, reported as "model name : Intel(R) Atom(TM) CPU CE41{1|5|7}0 @ 1.{2|6}0GHz" with model 28 (0x1c) and stepping 10 (0x0a). Add the three known variants to the tjmax table. Signed-off-by:
-
Guenter Roeck authored
commit 41e58a1f upstream. Atom CPUs don't have a register to retrieve TjMax. Detection so far was incomplete. Use the X86 model ID to improve it. Signed-off-by:
-
Guenter Roeck authored
commit 5592906f upstream. Document the Atom series D2000 and N2000 (Cedar Trail) as being supported. List and set TjMax for those series. Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: "R, Durgadoss" <durgadoss.r@intel.com> Signed-off-by:
-
Jean Delvare authored
commit fcc14ac1 upstream. Document the new Atom series (Tunnel Creek and Medfield) as being supported, and list TjMax for the Atom E600 series. Also enable the Atom tjmax heuristic for these Atom CPU models. Signed-off-by:
Guenter Roeck <guenter.roeck@ericsson.com> Cc: Alexander Stein <alexander.stein@systec-electronic.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: "R, Durgadoss" <durgadoss.r@intel.com> Signed-off-by:
-
Kailang Yang authored
commit ba4c4d0a upstream. It's compatible with ALC269. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Takashi Iwai authored
commit 6408eac2 upstream. The current code may access to the already freed object. The input device must be accessed and unregistered before freeing the top level sound object. Signed-off-by:
-
Anssi Hannula authored
commit 18e39186 upstream. hdmi_channel_allocation() tries to find a HDMI channel allocation that matches the number channels in the playback stream and contains only speakers that the HDMI sink has reported as available via EDID. If no such allocation is found, 0 (stereo audio) is used. Using CA 0 causes the audio causes the sink to discard everything except the first two channels (front left and front right). However, the sink may be capable of receiving more channels than it has speakers (and then perform downmix or discard the extra channels), in which case it is preferable to use a CA that contains extra channels than to use CA 0 which discards all the non-stereo channels. Additionally, it seems that HBR (HD) passthrough output does not work on Intel HDMI codecs when CA is set to 0 (possibly the codec zeroes channels not present in CA). This happens with all receivers that report a 5.1 speaker mask since a HBR stream is carried on 8 channels to the codec. Add a fallback in the CA selection so that the CA channel count at least matches the stream channel count, even if the stream contains channels not present in the sink speaker descriptor. Thanks to GrimGriefer at OpenELEC forums for discovering that changing the sink speaker mask allowed HBR output. Reported-by: GrimGriefer Reported-by: Ashecrow Reported-by:
Frank Zafka <kafkaesque1978@gmail.com> Reported-by:
Peter Frühberger <fritsch@xbmc.org> Signed-off-by:
Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
-
Torsten Schenk authored
commit 4c2aee00 upstream. Patch makes midi output buffer DMA-able by allocating it separately. Signed-off-by:
Torsten Schenk <torsten.schenk@zoho.com> Signed-off-by:
-
Torsten Schenk authored
commit 5ece263f upstream. Patch makes pcm buffers DMA-able by allocating each one separately. Signed-off-by:
-
Jussi Kivilinna authored
commit ddb6b5a9 upstream. Patch fixes 6fire not to use stack as URB transfer_buffer. URB buffers need to be DMA-able, which stack is not. Furthermore, transfer_buffer should not be allocated as part of larger device structure because DMA coherency issues and patch fixes this issue too. Signed-off-by:
Jussi Kivilinna <jussi.kivilinna@iki.fi> Tested-by:
-
Dan Carpenter authored
commit bd5fe738 upstream. "idx" is controled by the user and can be a negative offset into the input_names[] array. Signed-off-by:
-
Torstein Hegge authored
commit 61ac5130 upstream. UAC2_EXTENSION_UNIT_V2 differs from UAC1_EXTENSION_UNIT, but can be handled in the same way when parsing the unit. Otherwise parse_audio_unit() fails when it sees an extension unit on a UAC2 device. UAC2_EXTENSION_UNIT_V2 is outside the range allocated by UAC1. Signed-off-by:
Torstein Hegge <hegge@resisty.net> Acked-by:
Daniel Mack <zonque@gmail.com> Signed-off-by:
-
Eldad Zack authored
commit 5dae5fd2 upstream. Current code mishandles the case where the device is a UAC2 and the bDescriptorSubtype is a UAC2 Effect Unit (0x07). It tries to parse it as a Processing Unit (which is similar to two other UAC1 units with overlapping subtypes), but since the structure is different (See: 4.7.2.10, 4.7.2.11 in UAC2 standard), the parsing is done incorrectly and prevents the device from initializing. For now, just ignore the unit. Signed-off-by:
Eldad Zack <eldad@fogrefinery.com> Signed-off-by:
-
Aaron Plattner authored
commit d52392b1 upstream. Vendor ID 0x10de0060 is used by a yet-to-be-named GPU chip. Reviewed-by:
Andy Ritger <aritger@nvidia.com> Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Signed-off-by:
-
Aaron Plattner authored
commit 7ae48b56 upstream. Vendor ID 0x10de0051 is used by a yet-to-be-named GPU chip. Signed-off-by:
Daniel Dadap <ddadap@nvidia.com> Signed-off-by:
-
Takashi Iwai authored
commit bddee96b upstream. When a selection to a converter MUX is changed in hdmi_pcm_open(), it should be cached so that the given connection can be restored properly at PM resume. We need just to replace the corresponding snd_hda_codec_write() call with snd_hda_codec_write_cache(). Signed-off-by:
-
Takashi Iwai authored
commit 6962d914 upstream. We've got regression reports that my previous fix for spurious wakeups after S5 on HP Haswell machines leads to the automatic reboot at shutdown on some machines. It turned out that the fix for one side triggers another BIOS bug in other side. So, it's exclusive. Since the original S5 wakeups have been confirmed only on HP machines, it'd be safer to apply it only to limited machines. As a wild guess, limiting to machines with HP PCI SSID should suffice. This patch should be backported to kernels as old as 3.12, that contain the commit 638298dc "xhci: Fix spurious wakeups after S5 on Haswell". Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: <dashing.meng@gmail.com> Reported-by:
Niklas Schnelle <niklas@komani.de> Reported-by:
Giorgos <ganastasiouGR@gmail.com> Reported-by: <art1@vhex.net> Signed-off-by:
-
Takashi Iwai authored
commit 638298dc upstream. Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show mysterious wakeups after shutdown occasionally. After discussing with BIOS engineers, they explained that the new BIOS expects that the wakeup sources are cleared and set to D3 for all wakeup devices when the system is going to sleep or power off, but the current xhci driver doesn't do this properly (partly intentionally). This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci shutdown ops as done in xhci_stop(), and setting the device to PCI D3 at shutdown and remove ops. The PCI D3 call is based on the initial fix patch by Oliver Neukum. [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names in them. Sarah also fixed a collision with a quirk submitted around the same time, by changing the xhci->quirks bit from 17 to 18.] This patch should be backported to kernels as old as 3.0, that contain the commit 1c12443a "xhci: Add Lynx Point to list of Intel switchable hosts." Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Oliver Neukum authored
commit 455f5892 upstream. It has been reported that this chipset really cannot sleep without this extraordinary delay. This patch should be backported, in order to ensure this host functions under stable kernels. The last quirk for Fresco Logic hosts (commit bba18e33 "xhci: Extend Fresco Logic MSI quirk.") was backported to stable kernels as old as 2.6.36. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Julius Werner authored
commit e92aee33 upstream. This patch adds the Port Reset Change flag to the set of bits that are preemptively cleared on init/resume of a hub. In theory this bit should never be set unexpectedly... in practice it can still happen if BIOS, SMM or ACPI code plays around with USB devices without cleaning up correctly. This is especially dangerous for XHCI root hubs, which don't generate any more Port Status Change Events until all change bits are cleared, so this is a good precaution to have (similar to how it's already done for the Warm Port Reset Change flag). Signed-off-by:
Julius Werner <jwerner@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
James Ralston authored
commit 9f961a5f upstream. This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Sarah Sharp authored
commit f217c980 upstream. The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable remote wakeup for devices in the lower power link state L1. It has nothing to do with the device suspend remote wakeup from L2. The RWE bit is designed to be set once (when USB 2.0 LPM is enabled for the port) and cleared only when USB 2.0 LPM is disabled for the port. The xHCI bus suspend method was setting the RWE bit erroneously, and the bus resume method was clearing it. The xHCI 1.0 specification with errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware Controlled LPM": "While Hardware USB2 LPM is enabled, software shall not modify the HIRDBESL or RWE fields of the USB2 PORTPMSC register..." If we have previously enabled USB 2.0 LPM for a device, that means when the USB 2.0 bus is resumed, we violate the xHCI specification by clearing RWE. It also means that after a bus resume, the host would think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM enabled, which is not what we want. This patch should be backported to kernels as old as 3.2, that contain the commit 65580b43 "xHCI: set USB2 hardware LPM". That was the first kernel that supported USB 2.0 Link PM. Signed-off-by:
-
Seth Heasley authored
commit 1cfc7df3 upstream. This patch adds the AHCI-mode SATA DeviceIDs for the Intel Coleto Creek PCH. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
-
James Ralston authored
commit 151743fd upstream. This patch adds the AHCI-mode SATA Device IDs for the Intel Wellsburg PCH Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Colin Leitner authored
commit 8704211f upstream. FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would only report this limitation for CS6 to dmesg and fail to reflect this fact to tcgetattr. This patch reverts the unsupported CSIZE setting and reports the fact with less severance to dmesg for both CS5 and CS6. To test the patch it's sufficient to call stty -F /dev/ttyUSB0 cs5 which will succeed without the patch and report an error with the patch applied. As an additional fix this patch ensures that the control request will always include a data bit size. Signed-off-by:
Colin Leitner <colin.leitner@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> [bwh: Backported to 3.2: - Old code is cosmetically different - s/ddev/\&port->dev/] Signed-off-by:
-
Thomas Pugliese authored
commit f74b75e7 upstream. change WA_SEGS_MAX to a number that is legal according to the WUSB spec. Signed-off-by:
Thomas Pugliese <thomas.pugliese@gmail.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Thomas Pugliese authored
commit 7b6bc07a upstream. For isochronous endpoints, set the RPIPE wMaxPacketSize value using wOverTheAirPacketSize from the endpoint companion descriptor instead of wMaxPacketSize from the normal endpoint descriptor. Signed-off-by:
-
David Cohen authored
commit 85601f8c upstream. Add PCI id for Intel Merrifield Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Signed-off-by:
-
Heikki Krogerus authored
commit b62cd96d upstream. Add PCI id for Intel BayTrail. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Cc: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Sarah Sharp authored
commit dcc01c08 upstream. Before the USB core resets a device, we need to disable the L1 timeout for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may transition into L1 in between descriptor fetches, before we know if the USB device descriptors changed. LPM will be re-enabled after the full device descriptors are fetched, and we can confirm the device still supports USB 2.0 LPM after the reset. We don't need to wait for the USB device to exit L1 before resetting the device, since the xHCI roothub port diagrams show a transition to the Reset state from any of the Ux states (see Figure 34 in the 2012-08-14 xHCI specification update). This patch should be backported to kernels as old as 3.2, that contain the commit 65580b43 "xHCI: set USB2 hardware LPM". That was the first commit to enable USB 2.0 hardware-driven Link Power Management. Signed-off-by:
-
Alan Stern authored
commit f875fdbf upstream. Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm field in their pci_driver structures should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. The corresponding change has already been made for ohci-hcd. Without this change, controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by:
-
Alan Stern authored
commit 9d892429 upstream. This patch fixes a build error that occurs when CONFIG_PM is enabled and CONFIG_PM_SLEEP isn't: >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function) .pm = &usb_hcd_pci_pm_ops Since the usb_hcd_pci_pm_ops structure is defined and used when CONFIG_PM is enabled, its declaration should not be protected by CONFIG_PM_SLEEP. Signed-off-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Alan Stern authored
commit 69820e01 upstream. Since ohci-hcd supports runtime PM, the .pm field in its pci_driver structure should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. Without this change, OHCI controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by:
-
Johan Hovold authored
commit ff8a43c1 upstream. Make sure to fail properly if the device is not accepted during attach in order to avoid null-pointer derefs (of missing interface private data) at disconnect or release. Signed-off-by:
-
Johan Hovold authored
commit e877dd2f upstream. Fix endianess bugs in firmware handling introduced by commits cb7a7c6a ("ti_usb_3410_5052: add Multi-Tech modem support") and 05a3d905 ("ti_usb_3410_5052: support alternate firmware") which made the driver use the wrong firmware for certain devices on big-endian machines. Signed-off-by:
-
