- 12 Apr, 2017 40 commits
-
-
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:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> 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:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-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:
Takashi Iwai <tiwai@suse.de> 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:
Bjorn Helgaas <bhelgaas@google.com> 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:
-
Ritesh Harjani authored
[ Upstream commit a0e31428 ] sdhc-msm controller needs this SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN & SDHCI_QUIRK2_PRESET_VALUE_BROKEN to be set. Hence setting it. Signed-off-by:
Sahitya Tummala <stummala@codeaurora.org> Signed-off-by:
Ritesh Harjani <riteshh@codeaurora.org> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit b897f6db ] We already have in place a quirk for Windows 8 devices, but it looks like the Surface Cover are not conforming to it. Given that we are only interested in 3 feature reports (the ones that the Windows driver retrieves), we should be safe to unconditionally apply the quirk to everybody. In case there is an issue with a controller, we can always mark it as such in the transport driver, and hid-multitouch won't try to retrieve the feature report. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit 8fe89ef0 ] There is no reasons to filter out keyboard and consumer control collections in hid-multitouch. With the previous hid-input fix, there is now a full support of the Type Cover and we can remove all specific bits from hid-core and hid-microsoft. hid-multitouch will automatically set HID_QUIRK_NO_INIT_REPORTS so we can also remove it from the list of ushbid quirks. Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit 5cc5084d ] One more device requiring a quirk :/ Reported-by:
Christian-Nils Boda <christian-nils.boda@gadz.org> Signed-off-by:
-
Benjamin Tissoires authored
[ Upstream commit da809197 ] One more device requiring a quirk :/ [jkosina@suse.cz: update comment based on Bastien's remark] Signed-off-by:
Bastien Nocera <hadess@hadess.net> Signed-off-by:
-
Kiwoong Kim authored
[ Upstream commit 75b1cc4a ] Some UFS host controllers may think granularities of PRDT length and offset as bytes, not double words. Signed-off-by:
Kiwoong Kim <kwmad.kim@samsung.com> Reviewed-by:
-
Brian Norris authored
[ Upstream commit d8ec7595 ] The ARM specifies that the system counter "must be implemented in an always-on power domain," and so we try to use the counter as a source of timekeeping across suspend/resume. Unfortunately, some SoCs (e.g., Rockchip's RK3399) do not keep the counter ticking properly when switched from their high-power clock to the lower-power clock used in system suspend. Support this quirk by adding a new device tree property. Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit c19e4b90 ] We added a bunch of new Mellanox device ID definitions because they'll be used by INTx quirks. Use them in the mlx4 ID table also so grep can find both places. No functional change intended. Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
John Garry authored
[ Upstream commit f65e7866 ] The string for the am max transmissions quirk property is not correct -> fix it. Signed-off-by:
John Garry <john.garry@huawei.com> Reviewed-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit bf46241b ] Most Baytrail-CR devices use analog differential microphones, modify capture default to avoid DMI quirks. Keep digital mics for all other configurations. Signed-off-by:
-
Janusz Dziedzic authored
commit de288e36 upstream. In the case of bounced ep0 requests, we must delay DMA operation until after ->complete() otherwise we might overwrite contents of req->buf. This caused problems with RNDIS gadget. Signed-off-by:
Janusz Dziedzic <januszx.dziedzic@intel.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
HungNien Chen authored
[ Upstream commit 71af01a8 ] Certain devices produced by Weida Tech need to have a wakeup command sent to them before powering on. The call itself will come back with error, but the device can be powered on afterwards. [jkosina@suse.cz: rewrite changelog] [jkosina@suse.cz: remove unused device ID addition] Signed-off-by:
HungNien Chen <hn.chen@weidahitech.com> Reviewed-by:
-
Marcel Hasler authored
[ Upstream commit b2554000 ] All known gamepad adapters by Mayflash (identified as Dragonrise) need HID_QUIRK_MULTI_INPUT to split them up into four input devices. Without this quirk those adapters are falsely recognized as tablets. Fixes bug 115841 (https://bugzilla.kernel.org/show_bug.cgi?id=115841). Signed-off-by:
-
Vladimir Zapolskiy authored
[ Upstream commit f84d42a9 ] In common clock framework CLK_DIVIDER_ONE_BASED or'ed with CLK_DIVIDER_ALLOW_ZERO flags indicates that 1) a divider clock may be set to zero value, 2) divider's zero value is interpreted as a non-divided clock. On the LPC32xx platform clock dividers of PWM and memory card clocks comply with the first condition, but zero value means a gated clock, thus it may happen that the divider value is not updated when the clock is enabled and the clock remains gated. The change adds one-shot quirks, which check for zero value of divider on initialization and set it to a non-zero value, therefore in runtime a gate clock will work as expected. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Reviewed-by:
Sylvain Lemieux <slemieux.tyco@gmail.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Chen-Yu Tsai authored
commit 93a5ec14 upstream. The A31 TCON has mux controls for how TCON outputs are routed to the HDMI and MIPI DSI blocks. Since the A31s does not have MIPI DSI, it only has a mux for the HDMI controller input. This patch only adds support for the compatible strings. Actual support for the mux controls should be added with HDMI and MIPI DSI support. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Chen-Yu Tsai authored
commit 49c440e8 upstream. The A31's display pipeline has 2 frontends, 2 backends, and 2 TCONs. It also has new display enhancement blocks, such as the DRC (Dynamic Range Controller), the DEU (Display Enhancement Unit), and the CMU (Color Management Unit). It supports HDMI, MIPI DSI, and 2 LCD/LVDS channels. The A31s display pipeline is almost the same, just without MIPI DSI. Only the TCON seems to be different, due to the missing mux for MIPI DSI. Add compatible strings for both of them. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Chen-Yu Tsai authored
commit 91ea2f29 upstream. We already have some differences between the 2 supported SoCs. More will be added as we support other SoCs. To avoid bloating the probe function with even more conditionals, move the quirks to a separate data structure that's tied to the compatible string. Signed-off-by:
-
Jason A. Donenfeld authored
commit f5b98461 upstream. Now that our crng uses chacha20, we can rely on its speedy characteristics for replacing MD5, while simultaneously achieving a higher security guarantee. Before the idea was to use these functions if you wanted random integers that aren't stupidly insecure but aren't necessarily secure either, a vague gray zone, that hopefully was "good enough" for its users. With chacha20, we can strengthen this claim, since either we're using an rdrand-like instruction, or we're using the same crng as /dev/urandom. And it's faster than what was before. We could have chosen to replace this with a SipHash-derived function, which might be slightly faster, but at the cost of having yet another RNG construction in the kernel. By moving to chacha20, we have a single RNG to analyze and verify, and we also already get good performance improvements on all platforms. Implementation-wise, rather than use a generic buffer for both get_random_int/long and memcpy based on the size needs, we use a specific buffer for 32-bit reads and for 64-bit reads. This way, we're guaranteed to always have aligned accesses on all platforms. While slightly more verbose in C, the assembly this generates is a lot simpler than otherwise. Finally, on 32-bit platforms where longs and ints are the same size, we simply alias get_random_int to get_random_long. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Suggested-by:
Theodore Ts'o <tytso@mit.edu> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Andy Lutomirski <luto@amacapital.net> Signed-off-by:
-
