- 12 Apr, 2017 40 commits
-
-
Matjaz Hegedic authored
[ Upstream commit 90b28ded ] Without the parameter reboot=a, ASUS EeeBook X205TA will hang when it should reboot. This adds the appropriate quirk, thus fixing the problem. Signed-off-by:
Matjaz Hegedic <matjaz.hegedic@gmail.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
João Paulo Rechi Vita authored
[ Upstream commit 71050ae7 ] Some Asus laptops that have an airplane-mode indicator LED, also have the WMI WLAN user bit set, and the following bits in their DSDT: Scope (_SB) { (...) Device (ATKD) { (...) Method (WMNB, 3, Serialized) { (...) If (LEqual (IIA0, 0x00010002)) { OWGD (IIA1) Return (One) } } } } So when asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, it drives the airplane-mode indicator LED (through the call to OWGD) in an inverted fashion: the LED is ON when airplane mode is OFF (since wlan is ON), and vice-versa. This commit skips registering RFKill switches at all for these laptops, to allow the asus-wireless driver to drive the airplane mode LED correctly through the ASHS ACPI device. Relying on the presence of ASHS and ASUS_WMI_DSTS_USER_BIT avoids adding DMI-based quirks for at least 21 different laptops. Signed-off-by:
João Paulo Rechi Vita <jprvita@endlessm.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit 0b445549 ] In soft (no-reboot) mode, the driver self-pings watchdog upon expiration of an interrupt. However the interrupt itself was not cleared thus on first hit, the system enters infinite interrupt handling loop. On Odroid U3 (Exynos4412), when booted with s3c2410_wdt.soft_noboot=1 argument the console is flooded: # killall -9 watchdog [ 60.523760] s3c2410-wdt 10060000.watchdog: watchdog timer expired (irq) [ 60.536744] s3c2410-wdt 10060000.watchdog: watchdog timer expired (irq) Fix this by writing something to the WTCLRINT register to clear the interrupt. The register WTCLRINT however appeared in S3C6410 so a new watchdog quirk and flavor are needed. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Sinan Kaya authored
[ Upstream commit 33be632b ] The Qualcomm QDF2xxx root ports don't advertise an ACS capability, but they do provide ACS-like features to disable peer transactions and validate bus numbers in requests. To be specific: * Hardware supports source validation but it will report the issue as Completer Abort instead of ACS Violation. * Hardware doesn't support peer-to-peer and each root port is a root complex with unique segment numbers. * It is not possible for one root port to pass traffic to the other root port. All PCIe transactions are terminated inside the root port. Add an ACS quirk for the QDF2400 and QDF2432 products. [bhelgaas: changelog] Signed-off-by:
Sinan Kaya <okaya@codeaurora.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit cd3e2eb8 ] Sort the list of Intel devices that have no PCI D3 delay by ID. Add a comment for group of devices that had not been marked yet. There is no functional change. Signed-off-by:
-
yangbo lu authored
[ Upstream commit e9acc77d ] Initially all QorIQ platforms were PowerPC architecture and they didn't support card detection except several platforms. The driver added the quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION as default and this made broken-cd property in dts node didn't work. Now QorIQ platform turns to ARM architecture and most of them could support card detection. However it's a large number of dts trees that need to be fixed with broken-cd if we remove the default SDHCI_QUIRK_BROKEN_CARD_DETECTION in driver. And the users don't want to see this. So this patch is to remove this default quirk just for ARM and keep it for PowerPC.(Note, QorIQ PowerPC platform only has big-endian eSDHC while QorIQ ARM platform has big-endian or little-endian eSDHC) This makes broken-cd property work again for ARM. Signed-off-by:
Yangbo Lu <yangbo.lu@nxp.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Dongdong Liu authored
[ Upstream commit 72f2ff0d ] The PCIe Root Port in Hip06/Hip07 SoCs advertises an MSI capability, but it cannot generate MSIs. It can transfer MSI/MSI-X from downstream devices, but does not support MSI/MSI-X itself. Add a quirk to prevent use of MSI/MSI-X by the Root Port. [bhelgaas: changelog, sort vendor ID #define, drop device ID #define] Signed-off-by:
Dongdong Liu <liudongdong3@huawei.com> Signed-off-by:
Gabriele Paoloni <gabriele.paoloni@huawei.com> Reviewed-by:
Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by:
-
Jon Mason authored
[ Upstream commit ce709f86 ] The Broadcom Northstar2 SoC has a number of quirks for the PAXC (internal/fake) PCI bus. Specifically, the PCI config space is shared between the root port and the first PF (ie., PF0), and a number of fields are tied to zero (thus preventing them from being set). These cannot be "fixed" in device firmware, so we must fix them with a quirk. Signed-off-by:
Jon Mason <jon.mason@broadcom.com> Signed-off-by:
-
Will Deacon authored
[ Upstream commit 3046ec67 ] Commit 680a0873 ("arm: kernel: Add SMC structure parameter") added a new "quirk" parameter to the SMC and HVC SMCCC backends, but only updated the comment for the SMC version. This patch adds the new paramater to the comment describing the HVC version too. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Andy Gross authored
[ Upstream commit 82bcd087 ] This patch adds a Qualcomm specific quirk to the arm_smccc_smc call. On Qualcomm ARM64 platforms, the SMC call can return before it has completed. If this occurs, the call can be restarted, but it requires using the returned session ID value from the interrupted SMC call. The quirk stores off the session ID from the interrupted call in the quirk structure so that it can be used by the caller. This patch folds in a fix given by Sricharan R: https://lkml.org/lkml/2016/9/28/272Signed-off-by:
Andy Gross <andy.gross@linaro.org> Reviewed-by:
-
Andy Gross authored
[ Upstream commit 680a0873 ] This patch adds a quirk parameter to the arm_smccc_(smc/hvc) calls. The quirk structure allows for specialized SMC operations due to SoC specific requirements. The current arm_smccc_(smc/hvc) is renamed and macros are used instead to specify the standard arm_smccc_(smc/hvc) or the arm_smccc_(smc/hvc)_quirk function. This patch and partial implementation was suggested by Will Deacon. Signed-off-by:
-
Ping Cheng authored
[ Upstream commit e7deb157 ] Non-generic devices have numbered_buttons set for both pen and touch interfaces by default. The actual number of buttons on the interface is normally manually decided later, which is different from what those HID generic devices are processed, where number of buttons are directly retrieved from HID descriptors. This patch adds the missed HID_GENERIC check and moves the statement to wacom_setup_pad_input_capabilities since it's not a quirk anymore. Signed-off-by:
Ping Cheng <ping.cheng@wacom.com> Reviewed-by:
Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Mylène Josserand authored
[ Upstream commit 2ad6f30d ] Some SoCs have a reset line that must be asserted/deasserted. This patch adds a quirk to handle the new compatible "allwinner,sun6i-a31-i2s" which will deassert the reset line on probe function and assert it on remove's one. This new compatible is useful in case of A33 codec driver, for example. Signed-off-by:
Mylène Josserand <mylene.josserand@free-electrons.com> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
Dan Carpenter authored
[ Upstream commit 1ded56df ] The "port" variable was allocated with devm_kzalloc() so if we free it with kfree() it will be freed twice. Also I changed it to propogate the error from devm_ioremap_resource() instead of returning -ENOMEM. Fixes: c5d46039 ("PCI: Add MCFG quirks for X-Gene host controller") Also-posted-by:
Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Tanmay Inamdar <tinamdar@apm.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:
-
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:
-
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:
-
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:
-
Paolo Bonzini authored
commit 06ce521a upstream. handle_vmon gets a reference on VMXON region page, but does not release it. Release the reference. Found by syzkaller; based on a patch by Dmitry. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: "Charles (Chas) Williams" <ciwillia@brocade.com> 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:
-
Chris Salls authored
commit cf01fb99 upstream. In the case that compat_get_bitmap fails we do not want to copy the bitmap to the user as it will contain uninitialized stack data and leak sensitive data. Signed-off-by:
Chris Salls <salls@cs.ucsb.edu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Johan Hovold authored
commit cf903e9d upstream. A patch documenting how to specify which kernels a particular fix should be backported to (seemingly) inadvertently added a minus sign after the kernel version. This particular stable-tag format had never been used prior to this patch, and was neither present when the patch in question was first submitted (it was added in v2 without any comment). Drop the minus sign to avoid any confusion. Fixes: fdc81b79 ("stable_kernel_rules: Add clause about specification of kernel versions to patch.") Signed-off-by:
Johan Hovold <johan@kernel.org> 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:
-
Changbin Du authored
commit 5180edc2 upstream. The srcu read lock must be held while accessing kvm memslots. This patch fix below warning for function kvmgt_rw_gpa(). [ 165.345093] [ ERR: suspicious RCU usage. ] [ 165.416538] Call Trace: [ 165.418989] dump_stack+0x85/0xc2 [ 165.422310] lockdep_rcu_suspicious+0xd7/0x110 [ 165.426769] kvm_read_guest_page+0x195/0x1b0 [kvm] [ 165.431574] kvm_read_guest+0x50/0x90 [kvm] [ 165.440492] kvmgt_rw_gpa+0x43/0xa0 [kvmgt] [ 165.444683] kvmgt_read_gpa+0x11/0x20 [kvmgt] [ 165.449061] gtt_get_entry64+0x4d/0xc0 [i915] [ 165.453438] ppgtt_populate_shadow_page_by_guest_entry+0x380/0xdc0 [i915] [ 165.460254] shadow_mm+0xd1/0x460 [i915] [ 165.472488] intel_vgpu_create_mm+0x1ab/0x210 [i915] [ 165.477472] intel_vgpu_g2v_create_ppgtt_mm+0x5f/0xc0 [i915] [ 165.483154] pvinfo_mmio_write+0x19b/0x1d0 [i915] [ 165.499068] intel_vgpu_emulate_mmio_write+0x3f9/0x600 [i915] [ 165.504827] intel_vgpu_rw+0x114/0x150 [kvmgt] [ 165.509281] intel_vgpu_write+0x16f/0x1a0 [kvmgt] [ 165.513993] vfio_mdev_write+0x20/0x30 [vfio_mdev] [ 165.518793] vfio_device_fops_write+0x24/0x30 [vfio] [ 165.523770] __vfs_write+0x28/0x120 [ 165.540529] vfs_write+0xce/0x1f0 v2: fix Cc format for stable Signed-off-by:
Changbin Du <changbin.du@intel.com> Reviewed-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Reviewed-by:
Jike Song <jike.song@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Zhenyu Wang authored
commit 2958b901 upstream. Fix to correctly assign 1ms for gvt scheduler interval time, as previous code using HZ is pretty broken. And use no delay for start gvt scheduler function. Fixes: 4b63960e ("drm/i915/gvt: vGPU schedule policy framework") Cc: Zhi Wang <zhi.a.wang@intel.com> Acked-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Signed-off-by:
-
