- 12 Apr, 2017 40 commits
-
-
Zhang Rui authored
[ Upstream commit cbc00c13 ] In commit 821d6f03 (ACPI / sleep: Do not save NVS for new machines to accelerate S3), to optimize S3 suspend/resume speed, code is introduced to ignore NVS memory saving during S3 for all the platforms later than 2012. But, Lenovo G50-45, a platform released in 2015, still needs NVS memory saving during S3. A quirk is introduced for this platform. Link: https://bugzilla.kernel.org/show_bug.cgi?id=189431Tested-by:
Przemek <soprwa@gmail.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> [ rjw: Drop unnecessary code ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Pierre-Louis Bossart authored
[ Upstream commit a50477e5 ] The existing code assumes a 19.2 MHz MCLK as the default hardware configuration. This is valid for CherryTrail but not for Baytrail. Add explicit MCLK configuration to set the 19.2 clock on/off depending on DAPM events. This is a prerequisite step to enable devices with Baytrail and RT5645 such as Asus X205TA Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 42648c22 ] Fix classic issue of having multiple codecs listed in DSDT but a single one actually enabled. The previous code did not handle such errors and could also lead to uninitalized configurations Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit fd0138dc ] the BIOS reports this codec as RT5640 but it's a rt5670. Use the quirk mechanism to use the cht_bsw_rt5672 machine driver Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 93ffeaa8 ] the BIOS incorrectly reports this codec as 5640 but it is really a rt5670 Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit d2528006 ] rt5670 driver supports also RT5672 codec, but its ACPI ID is missing. This was found on Dell Wyse 3040 box. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Lv Zheng authored
[ Upstream commit 77e9a4aa ] More and more platforms need the button.lid_init_state=open quirk. This patch sets it the default behavior. If a platform doesn't send lid open event or lid open event is lost due to the underlying system problems, then we can compare various combinations: 1. systemd/acpid is used to suspend system or not, systemd has a special logic forcing open event after resuming; 2. _LID returns a cached value or not. The result is as follows: 1. lid_init_state=method 1. cached 1. resumed by lid: (x) event=close (x) systemd=suspends again (x) acpid=suspends again (x) state=close 2. resumed by other: (o) event=close (x) systemd=suspends again (x) acpid=suspends again (o) state=close 2. non-cached 1. resumed by lid: (o) event=open (o) systemd=resumes (o) acpid=resumes (o) state=open 2. resumed by other: (o) event=close (x) systemd=suspends again (x) acpid=suspends again (o) state=close 2. lid_init_state=open 1. cached 1. resumed by lid: (o) event=open (o) systemd=resumes (o) acpid=resumes (x) state=close 2. resumed by other: (x) event=open (o) systemd=resumes (o) acpid=resumes (o) state=close 2. non-cached 1. resumed by lid: (o) event=open (o) systemd=resumes (o) acpid=resumes (o) state=open 2. resumed by other: (x) event=open (o) systemd=resumes (o) acpid=resumes (o) state=close 3. lid_init_state=ignore 1. cached 1. resumed by lid: (o) event=none (x) systemd=suspends again (o) acpid=resumes (x) state=close 2. resumed by other: (o) event=none (x) systemd=suspends again (o) acpid=resumes (o) state=close 2. non-cached 1. resumed by lid: (o) event=none (x) systemd=suspends again (o) acpid=resumes (o) state=open 2. resumed by other: (o) event=none (x) systemd=suspends again (o) acpid=resumes (o) state=close As a conclusion: 1. With systemd changed, lid_init_state=ignore has only one problem and the problem comes from an underlying issue, not userspace and kernel lid handling. 2. Without systemd changed, lid_init_state=open can be the default behavior as the pass ratio is not much worse than lid_init_state=ignore. 3. lid_init_state=method is buggy, we can have a separate patch to make it deprectated. Link: https://bugzilla.kernel.org/show_bug.cgi?id=187271Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
-
Bartosz Golaszewski authored
[ Upstream commit f4d435f3 ] There's an issue with the da850 SATA controller: if port multiplier support is compiled in, but we're connecting the drive directly to the SATA port on the board, the drive can't be detected. To make SATA work on the da850-lcdk board: first try to softreset with pmp - if the operation fails with -EBUSY, retry without pmp. Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Alex Williamson authored
[ Upstream commit 7184f5b4 ] Intel 200-series chipsets have the same errata as 100-series: the ACS capability doesn't follow the PCIe spec, the capability and control registers are dwords rather than words. Add PCIe root port device IDs to existing quirk. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Patrice Chotard authored
[ Upstream commit 8413299c ] Since v4.10-rc1, the following logs appears in loop : [ 801.953836] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 801.960455] xhci-hcd xhci-hcd.0.auto: Cannot set link state. [ 801.966611] usb usb6-port1: cannot disable (err = -32) [ 806.083772] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 806.090370] xhci-hcd xhci-hcd.0.auto: Cannot set link state. [ 806.096494] usb usb6-port1: cannot disable (err = -32) After analysis, xhci try to set link in U3 and returns an error. Using snps,dis_u3_susphy_quirk fix this issue. Signed-off-by:
Patrice Chotard <patrice.chotard@st.com> Signed-off-by:
-
Daniel Vetter authored
[ Upstream commit 858b2c1b ] It's only for a device quirk, and we might as well do that in the load callback. Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-10-daniel.vetter@ffwll.chSigned-off-by:
-
Felipe Balbi authored
[ Upstream commit e42a5dbb ] dwc3 revisions <=3.00a have a limitation where Port Disable command doesn't work. Set the quirk-broken-port-ped property for such controllers so XHCI core can do the necessary workaround. [rogerq@ti.com] Updated code from platform data to device property. Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 21939f00 ] In case 'quirk-broken-port-ped' property is passed in via device property, we should enable the corresponding BROKEN_PED quirk flag for XHCI core. [rogerq@ti.com] Updated code from platform data to device property and added DT binding. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit 41135de1 ] Some devices from Texas Instruments [1] suffer from a silicon bug where Port Enabled/Disabled bit should not be used to silence an erroneous device. The bug is so that if port is disabled with PED bit, an IRQ for device removal (or attachment) will never fire. Just for the sake of completeness, the actual problem lies with SNPS USB IP and this affects all known versions up to 3.00a. A separate patch will be added to dwc3 to enabled this quirk flag if version is <= 3.00a. [1] - AM572x Silicon Errata http://www.ti.com/lit/er/sprz429j/sprz429j.pdf Section i896— USB xHCI Port Disable Feature Does Not Work Signed-off-by:
-
Kevin Hilman authored
[ Upstream commit 7e431af8 ] Add PM support for DA850 device-tree boot. Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 5feeca3c ] GPIO descriptors are the preferred way over legacy GPIO numbers nowadays. Convert the driver to use GPIO descriptors internally but still allow passing legacy GPIO numbers from platform data to support existing platforms. Based on commits 633a21d8 ("input: gpio_keys_polled: Add support for GPIO descriptors") and 1ae5ddb6 ("Input: gpio_keys_polled - request GPIO pin as input."). Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Vignesh R authored
[ Upstream commit b6ffcf21 ] UART uses as EDMA as dma engine on AM437x SoC and therefore, requires OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK quirk for AM437x platform as well. While at that, drop use of of_machine_is_compatible() and instead pass quirks via device data. Signed-off-by:
Vignesh R <vigneshr@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit dd374909 ] The core framework already handles setting this parameter with a platform quirk. Add the appropriate flag so that we always set AHBBURST to 0. Technically DT should be doing this, but we always do it for msm chipidea devices so setting the flag in the driver works just as well. If the burst needs to be anything besides 0, we expect the 'ahb-burst-config' dts property to be present. Acked-by:
Peter Chen <peter.chen@nxp.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by:
-
subhashj@codeaurora.org authored
[ Upstream commit 7caf489b ] If we issue the link startup to the device while its UniPro state is LinkDown (and device state is sleep/power-down) then link startup will not move the device state to Active. Device will only move to active state if the link starup is issued when its UniPro state is LinkUp. So in this case, we would have to issue the link startup 2 times to make sure that device moves to active state. Reviewed-by:
Gilad Broner <gbroner@codeaurora.org> Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Zang Leigang authored
[ Upstream commit 141f8165 ] Add a new ufshcd_state, indicats that an err handler may get to run immediately. Use UFSHCD_STATE_ERROR here looks not literaly correct. Signed-off-by:
Zang Leigang <zangleigang@hisilicon.com> Reviewed-by:
-
youling257 authored
[ Upstream commit 57180048 ] There are literally dozens of Insyde devices with a different name but with the same audio routing. Use a generic quirk to match on vendor name only to avoid recurring edits of the same thing. Signed-off-by:
youling257 <youling257@gmail.com> Signed-off-by:
-
Paulo Zanoni authored
[ Upstream commit 98b2f01c ] Back in 2014, commit fb7023e0 ("drm/i915: BDW: Adding Reserved PCI IDs.") added the reserved PCI IDs in order to try to make sure we had working drivers in case we ever released products using these IDs (since we had instances of this type of problem in the past). The problem is that the patch only touched the macros used by early-quirks.c and by the user space components that rely on i915_pciids.h, it didn't touch the macros used by i915_pci.c. So we correctly handled the stolen memory for these theoretical IDs, but we didn't actually drive the devices from i915.ko. So this patch fixes the original commit by actually making i915.ko drive these IDs, which was the goal. There's no information on what would be the GT count on these IDs, so we just go with the safer intel_broadwell_info, at the risk of ignoring a possibly inexistent BSD2_RING. I did some checking, and it seems that these IDs are driven by intel-gpu-tools, xf86-video-intel and libdrm (since they contain old copies of i915_pciids.h), but they are not checked by mesa. The alternative to this patch would be to just assume we're actually never going to use these IDs, and then remove them from our ID lists and make sure our user space components sync the latest i915_pciids.h copy. I'm fine with either approaches, as long as we make sure that every component tries to drive the same list of PCI IDs. Fixes: fb7023e0 ("drm/i915: BDW: Adding Reserved PCI IDs.") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1483473860-17644-3-git-send-email-paulo.r.zanoni@intel.comSigned-off-by:
-
Paulo Zanoni authored
[ Upstream commit 0784bc62 ] Commit 8d9c20e1 ("drm/i915: Remove .is_mobile field from platform struct") removed mobile vs desktop differences for HSW+, but forgot the Broadwell reserved IDs, so do it now. It's interesting to notice that these IDs are used by early-quirks.c but are *not* used by i915_pci.c. Cc: Carlos Santa <carlos.santa@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Paulo Zanoni authored
[ Upstream commit 7fbd995c ] Remove duplicated IDs from the list. Currently, this definition is only used by early-quirks.c. From my understanding of the code, having duplicated IDs shouldn't be causing any bugs. Fixes: 8d9c20e1 ("drm/i915: Remove .is_mobile field from platform struct") Cc: Carlos Santa <carlos.santa@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
[ Upstream commit 23c4cfbd ] No reason not to be const. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1482923186-22430-1-git-send-email-jani.nikula@intel.comSigned-off-by:
-
Marcel Hasler authored
[ Upstream commit 8aa2cc7e ] The DolphinBar by Mayflash (identified as Dragonrise) needs HID_QUIRK_MULTI_INPUT to split it up into four input devices. Without this quirk the adapter is falsely recognized as a tablet. See also bug 115841 (https://bugzilla.kernel.org/show_bug.cgi?id=115841). Signed-off-by:
Marcel Hasler <mahasler@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Alex Wood authored
[ Upstream commit f83f90cf ] The Futaba TOSD-5711BB VFD crashes when the initial HID report is requested, register the display in hid-ids and tell hid-quirks to not do the init. Signed-off-by:
Alex Wood <thetewood@gmail.com> Signed-off-by:
-
Lv Zheng authored
[ Upstream commit 9c4aa1ee ] Sometimes, the users may require a quirk to be provided from ACPI subsystem core to prevent a GPE from flooding. Normally, if a GPE cannot be dispatched, ACPICA core automatically prevents the GPE from firing. But there are cases the GPE is dispatched by _Lxx/_Exx provided via AML table, and OSPM is lacking of the knowledge to get _Lxx/_Exx correctly executed to handle the GPE, thus the GPE flooding may still occur. The existing quirk mechanism can be enabled/disabled using the following commands to prevent such kind of GPE flooding during runtime: # echo mask > /sys/firmware/acpi/interrupts/gpe00 # echo unmask > /sys/firmware/acpi/interrupts/gpe00 To avoid GPE flooding during boot, we need a boot stage mechanism. This patch provides such a boot stage quirk mechanism to stop this kind of GPE flooding. This patch doesn't fix any feature gap but since the new feature gaps could be found in the future endlessly, and can disappear if the feature gaps are filled, providing a boot parameter rather than a DMI table should suffice. Link: https://bugzilla.kernel.org/show_bug.cgi?id=53071 Link: https://bugzilla.kernel.org/show_bug.cgi?id=117481 Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793Signed-off-by:
-
Keith Busch authored
[ Upstream commit e6282aef ] Some OEMs believe they own the Identify Controller vendor specific region and will repurpose it with their own values. While not common, we can't rely on the PCI VID:DID to tell use how to decode the field we reserved for this as the stripe size so we need to do something else for the list of devices using this quirk. The field was supposed to allow flexibility on the device's back-end striping, but it turned out that never materialized; the chunk is always the same as MDTS in the products subscribing to this quirk, so this patch removes the stripe_size field and sets the chunk to the max hw transfer size for the devices using this quirk. Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Lee, Chun-Yi authored
[ Upstream commit 5241b193 ] The AMW0_GUID1 wmi is not only found on Acer family but also other machines like Lenovo, Fujitsu and Medion. In the past, acer-wmi handled those non-Acer machines by quirks list. But actually acer-wmi driver was loaded on any machine that had AMW0_GUID1. This behavior is strange because those machines should be supported by appropriate wmi drivers. e.g. fujitsu-laptop, ideapad-laptop. This patch adds the logic to check the machine that has AMW0_GUID1 should be in Acer/Packard Bell/Gateway white list. But, it still keeps the quirk list of those supported non-acer machines for backward compatibility. Tested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
Lee, Chun-Yi <jlee@suse.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Nobutaka Okabe authored
[ Upstream commit 7f38ca04 ] This patch adds native DSD support for the following devices. - TEAC NT-503 - TEAC UD-503 - TEAC UD-501 (1) Add quirks for native DSD support for TEAC devices. (2) A specific vendor command is needed to switch between PCM/DOP and DSD mode, same as Denon/Marantz devices. Signed-off-by:
Nobutaka Okabe <nob77413@gmail.com> Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit 044bc425 ] It's not very enlightening to see pci 0000:07:00.0: [Firmware Bug]: VPD access disabled in the dmesg log because there's no clue about what the firmware bug is. Expand the message to explain why we're disabling VPD. Signed-off-by:
-
Alberto Aguirre authored
[ Upstream commit 17f08b0d ] The Axe-Fx II implicit feedback end point and the data sync endpoint are in different interface descriptors. Add quirk to ensure a sync endpoint is properly configured. Signed-off-by:
Alberto Aguirre <albaguirre@gmail.com> Signed-off-by:
-
Subhash Jadavani authored
[ Upstream commit 56d4a186 ] The maximum value PA_SaveConfigTime is 250 (10us) but this is not enough for some vendors. Gear switch from PWM to HS may fail even with this max. PA_SaveConfigTime. Gear switch can be issued by host controller as an error recovery and any software delay will not help on this case so we need to increase PA_SaveConfigTime to >32us as per vendor recommendation. This change adds a quirk to increase the PA_SaveConfigTime parameter. Reviewed-by:
Venkat Gopalakrishnan <venkatg@codeaurora.org> Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit 0d414268 ] Pull the register resource lookup out of thunder_pem_init() so we can easily add a corresponding lookup using ACPI. No functional change intended. Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit dfd1972c ] Use a local "struct device *dev" for brevity. No functional change intended. Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Tomasz Nowicki authored
[ Upstream commit 093d24a2 ] Currently we use one shared global acpi_pci_root_ops structure to keep controller-specific ops. We pass its pointer to acpi_pci_root_create() and associate it with a host bridge instance for good. Such a design implies serious drawback. Any potential manipulation on the single system-wide acpi_pci_root_ops leads to kernel crash. The structure content is not really changing even across multiple host bridges creation; thus it was not an issue so far. In preparation for adding ECAM quirks mechanism (where controller-specific PCI ops may be different for each host bridge) allocate new acpi_pci_root_ops and fill in with data for each bridge. Now it is safe to have different controller-specific info. As a consequence free acpi_pci_root_ops when host bridge is released. No functional changes in this patch. Signed-off-by:
Tomasz Nowicki <tn@semihalf.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 5e7ec268 ] Add CPU ID for Atom Z34xx processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition from official BSP code. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Chuck Lever authored
[ Upstream commit 4d712ef1 ] S5.3.3.1 of RFC 2203 requires that an incoming GSS-wrapped message whose sequence number lies outside the current window is dropped. The rationale is: The reason for discarding requests silently is that the server is unable to determine if the duplicate or out of range request was due to a sequencing problem in the client, network, or the operating system, or due to some quirk in routing, or a replay attack by an intruder. Discarding the request allows the client to recover after timing out, if indeed the duplication was unintentional or well intended. However, clients may rely on the server dropping the connection to indicate that a retransmit is needed. Without a connection reset, a client can wait forever without retransmitting, and the workload just stops dead. I've reproduced this behavior by running xfstests generic/323 on an NFSv4.0 mount with proto=rdma and sec=krb5i. To address this issue, have the server close the connection when it silently discards an incoming message due to a GSS sequence number problem. There are a few other places where the server will never reply. Change those spots in a similar fashion. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Subhash Jadavani authored
[ Upstream commit c6a6db43 ] Some UFS devices require host PA_TACTIVATE to be higher than device PA_TACTIVATE otherwise it may get stuck during hibern8 sequence. This change allows this by using quirk. Reviewed-by:
-
