- 12 7月, 2017 2 次提交
-
-
由 Lv Zheng 提交于
On Lenovo ThinkPad X1 Carbon - the 5th Generation, enabling an earlier EC event freezing timing causes acpitz-virtual-0 to report a stuck 48C temparature. And with EC firmware revisioned as 1.14, without reverting back to old EC event freezing timing, the fan still blows up after a system resume. This reverts the culprit change so that the regression can be fixed without upgrading the EC firmware. Fixes: d3028305 (ACPI / EC: Enable event freeze mode to improve event handling) Link: https://bugzilla.kernel.org/show_bug.cgi?id=191181#c168Tested-by: NDamjan Georgievski <gdamjan@gmail.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Cc: 4.9+ <stable@vger.kernel.org> # 4.9+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
According to bug reports, although the busy polling mode can make noirq stages execute faster, it causes abnormal fan blowing up after system resume (see the first link below for a video demonstration) on Lenovo ThinkPad X1 Carbon - the 5th Generation. The problem can be fixed by upgrading the EC firmware on that machine. However, many reporters confirm that the problem can be fixed by stopping busy polling during suspend/resume and for some of them upgrading the EC firmware is not an option. For this reason, drop the noirq stage hooks from the EC driver to fix the regression. Fixes: c3a696b6 (ACPI / EC: Use busy polling mode when GPE is not enabled) Link: https://youtu.be/9NQ9x-Jm99Q Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129Reported-by: NAndreas Lindhe <andreas@lindhe.io> Tested-by: NGjorgji Jankovski <j.gjorgji@gmail.com> Tested-by: NDamjan Georgievski <gdamjan@gmail.com> Tested-by: NFernando Chaves <nanochaves@gmail.com> Tested-by: NTomislav Ivek <tomislav.ivek@gmail.com> Tested-by: NDenis P. <theoriginal.skullburner@gmail.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 29 6月, 2017 4 次提交
-
-
由 Carlo Caione 提交于
ASUS GL720VMK is also affected by the EC GPE preference issue. Signed-off-by: NCarlo Caione <carlo@caione.org> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Chris Chiu 提交于
Some Asus laptops (verified on X550VXK/FX502VD/FX502VE) get no interrupts when pressing media keys thus the corresponding functions are not invoked. It's due to the _GPE defines in DSDT for EC returns differnt value compared to the GPE Number in ECDT. Confirmed with Asus that the vale in ECDT is the correct one. This commit uses DMI quirks to prevent calling _GPE when doing ec_parse_device() and keep the ECDT GPE number setting for the EC device. With previous commit, it is ensured that if there is an ECDT, it can always be kept as boot_ec, this patch thus can implement a quirk on top of the determined ECDT boot_ec. Link: https://phabricator.endlessm.com/T16033 Link: https://phabricator.endlessm.com/T16722 Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651Tested-by: NDaniel Drake <drake@endlessm.com> Signed-off-by: NChris Chiu <chiu@endlessm.com> Signed-off-by: NCarlo Caione <carlo@caione.org> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
We prepared _INI/_STA methods for \_SB, \_SB.PCI0, \_SB.LID0 and \_SB.EC, _HID(PNP0C09)/_CRS/_GPE for \_SB.EC to poke Windows behavior with qemu, we got the following execution sequence: \_SB._INI \_SB.PCI0._STA \_SB.LID0._STA \_SB.EC._STA \_SB.PCI0._INI \_SB.LID0._INI \_SB.EC._INI There is no extra DSDT EC device enumeration process occurring before the main ACPI device enumeration process. That means acpi_ec_dsdt_probe() is not Windows-compatible. Tracking back, it was added by the following commit: Commit: c5279dee Subject: ACPI: EC: Add some basic check for ECDT data but that commit was misguided. Why we shouldn't enumerate DSDT EC before the main ACPI device enumeration? The only way to know if the DSDT EC is valid would be to evaluate its _STA control method, but it's not safe to evaluate this control method that early and out of the ACPI enumeration process, because _STA may refer to entities (such as resources or ACPI device objects) that may not have been initialized before OSPM starts to enumerate them via the main ACPI device enumeration. But after we had reverted back to the expected behavior, a regression was reported. On that platform, there is no ECDT, but the platform control methods access EC operation region earlier than Linux expects causing some ACPI method execution errors. For this reason, we just go back to old behavior to still probe DSDT EC as the boot EC. However, that turns out to lead to yet another functional breakage and in order to work around all of the problems, we skip boot stage DSDT probe when the ECDT exists so that a later quirk can always use correct ECDT GPE setting. Link: http://bugzilla.kernel.org/show_bug.cgi?id=11880 Link: http://bugzilla.kernel.org/show_bug.cgi?id=119261 Link: http://bugzilla.kernel.org/show_bug.cgi?id=195651Tested-by: NDaniel Drake <drake@endlessm.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> [ rjw: Changelog & comments massage ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
It's reported that some buggy BIOS tables can contain 2 DSDT ECs, one of them is invalid but acpi_ec_dsdt_probe() fails to pick the valid one. This patch simply enhances sanity checks in ec_parse_device() as a workaround to skip probing wrong namespace ECs. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195651Tested-by: NDaniel Drake <drake@endlessm.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 28 6月, 2017 2 次提交
-
-
由 Lv Zheng 提交于
acpi_ec_cmd_string() currently is only enabled for "DEBUG" macro, but users trend to use CONFIG_DYNAMIC_DEBUG and enable ec.c pr_debug() print-outs by "dyndbg='file ec.c +p'". In this use case, all command names are turned into UNDEF and the log is confusing. This affects bugzilla triage work. This patch fixes this issue by enabling acpi_ec_cmd_string() for CONFIG_DYNAMIC_DEBUG. Tested-by: NWang Wendy <wendy.wang@intel.com> Tested-by: NFeng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Lv Zheng 提交于
The EC event IRQ (SCI_EVT) can only be handled by submitting QR_EC. As the EC driver handles SCI_EVT in a workqueue, after SCI_EVT is flagged and before QR_EC is submitted, there is a period risking IRQ storming. EC IRQ must be masked for this period but linux EC driver never does so. No end user notices the IRQ storming and no developer fixes this known issue because: 1. The EC IRQ is always edge triggered GPE, and 2. The kernel can execute no-op EC IRQ handler very fast. For edge-triggered EC GPE platforms, it is only reported of post-resume EC event lost issues, there won't be an IRQ storming. For level triggered EC GPE platforms, fortunately the kernel is always fast enough to execute such a no-op EC IRQ handler so that the IRQ handler won't be accumulated to starve the task contexts, causing a real IRQ storming. But the IRQ storming actually can still happen when: 1. The EC IRQ performs like level triggered GPE, and 2. The kernel EC debugging log is turned on but the console is slow enough. There are more and more platforms using EC GPE as wake GPE where the EC GPE is likely designed as level triggered. Then when EC debugging log is enabled, the EC IRQ handler is no longer a no-op but dumps IRQ status to the consoles. If the consoles are slow enough, the EC IRQs can arrive much faster than executing the handler. Finally the accumulated EC event IRQ handlers starve the task contexts, causing the IRQ storming to occur, and the kernel hangs can be observed during boot/resume. This patch fixes this issue by masking EC IRQ for this period: 1. Begins when there is an SCI_EVT IRQ pending, and 2. Ends when there is a QR_EC completed (SCI_EVT acknowledged). Tested-by: NWang Wendy <wendy.wang@intel.com> Tested-by: NFeng Chenzhou <chenzhoux.feng@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 23 6月, 2017 1 次提交
-
-
由 Andrew Duggan 提交于
The F54 driver is currently only using the first 6 bytes of F54 so there is no need to read all 27 bytes. Some Dell systems (Dell XP13 9333 and similar) have an issue with the touchpad or I2C bus when reading reports larger then 16 bytes. Reads larger then 16 bytes are reported in two HID reports. Something about the back to back reports seems to cause the next read to report incorrect data. This results in F30 failing to load and the click button failing to work. Previous issues with the I2C controller or touchpad were addressed in: commit 5b65c2a0 ("HID: rmi: check sanity of the incoming report") Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=195949Signed-off-by: NAndrew Duggan <aduggan@synaptics.com> Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: NNick Dyer <nick@shmanahar.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 22 6月, 2017 3 次提交
-
-
The i2c-imx driver incorrectly uses readb()/writeb() to read and write to the appropriate registers when performing a repeated start. The appropriate imx_i2c_read_reg()/imx_i2c_write_reg() functions should be used instead. Performing a repeated start results in a kernel panic. The platform is imx. Signed-off-by: NMichail G Etairidis <m.etairidis@beck-ipc.com> Fixes: ce1a7884 ("i2c: imx: add DMA support for freescale i2c driver") Fixes: 054b62d9 ("i2c: imx: fix the i2c bus hang issue when do repeat restart") Acked-by: NFugang Duan <fugang.duan@nxp.com> Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Jarkko Nikula 提交于
Commit f406270b ("ACPI / scan: Set the visited flag for all enumerated devices") caused that two group of special SPI or I2C devices do not enumerate. SPI and I2C devices are expected to be enumerated by the SPI and I2C subsystems but change caused that acpi_bus_attach() marks those devices with acpi_device_set_enumerated(). First group of devices are matched using Device Tree compatible property with special _HID "PRP0001". Those devices have matched scan handler, acpi_scan_attach_handler() retuns 1 and acpi_bus_attach() marks them with acpi_device_set_enumerated(). Second group of devices without valid _HID such as "LNXVIDEO" have device->pnp.type.platform_id set to zero and change again marks them with acpi_device_set_enumerated(). Fix this by flagging the SPI and I2C devices during struct acpi_device object initialization time and let the code in acpi_bus_attach() to go through the device_attach() and acpi_default_enumeration() path for all SPI and I2C devices. Fixes: f406270b (ACPI / scan: Set the visited flag for all enumerated devices) Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Cc: 4.11+ <stable@vger.kernel.org> # 4.11+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mike Snitzer 提交于
If only a subset of the devices associated with multiple regions support a given special operation (eg. DISCARD) then the dec_count() that is used to set error for the region must increment the io->count. Otherwise, when the dec_count() is called it can cause the dm-io caller's bio to be completed multiple times. As was reported against the dm-mirror target that had mirror legs with a mix of discard capabilities. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=196077Reported-by: NZhang Yi <yizhan@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
- 21 6月, 2017 11 次提交
-
-
由 Mike Snitzer 提交于
Use spin_lock_irqsave and spin_unlock_irqrestore rather than spin_{lock,unlock}_irq in submit_flush_bio(). Otherwise lockdep issues the following warning: DEBUG_LOCKS_WARN_ON(current->hardirq_context) WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2748 trace_hardirqs_on_caller+0x107/0x180 Reported-by: NOndrej Kozina <okozina@redhat.com> Tested-by: NOndrej Kozina <okozina@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Acked-by: NMikulas Patocka <mpatocka@redhat.com>
-
由 Daniel Vetter 提交于
In commit 91eefc05 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Dec 14 00:08:10 2016 +0100 drm: Tighten locking in drm_mode_getconnector I reordered the logic a bit in that IOCTL, but that broke userspace since it'll get the new mode list, but not the new property values. Fix that again. v2: Fix up the error path handling when copy_to_user for the modes failes (Dhinakaran). Fixes: 91eefc05 ("drm: Tighten locking in drm_mode_getconnector") Cc: Sean Paul <seanpaul@chromium.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Reported-by: N"H.J. Lu" <hjl.tools@gmail.com> Tested-by: N"H.J. Lu" <hjl.tools@gmail.com> Cc: <stable@vger.kernel.org> # v4.11+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100576 Cc: "H.J. Lu" <hjl.tools@gmail.com> Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170620202837.1701-1-daniel.vetter@ffwll.ch
-
由 Marcin Nowakowski 提交于
gic_read_count(), gic_write_compare() and gic_write_cpu_compare() are often used in a sequence to update the compare register with a count value increased by a small offset. With small delta values used to update the compare register, the time to update function trace for these operations may be longer than the update timeout leading to update failure. Signed-off-by: NMarcin Nowakowski <marcin.nowakowski@imgtec.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: linux-mips@linux-mips.org Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1496991845-27031-1-git-send-email-marcin.nowakowski@imgtec.com
-
由 Niklas Cassel 提交于
When having the skb pointer in the first descriptor, stmmac_tx_clean can get called at a moment where the IP has only cleared the own bit of the first descriptor, thus freeing the skb, even though there can be several descriptors whose buffers point into the same skb. By simply moving the skb pointer from the first descriptor to the last descriptor, a skb will get freed only when the IP has cleared the own bit of all the descriptors that are using that skb. Signed-off-by: NNiklas Cassel <niklas.cassel@axis.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Edward Cree 提交于
Somehow two copies of the line 'up_write(&vf->efx->filter_sem);' got into efx_ef10_sriov_set_vf_vlan(). This would put the mutex in a bad state and cause all subsequent down attempts to hang. Fixes: 671b53ee ("sfc: Ensure down_write(&filter_sem) and up_write() are matched before calling efx_net_open()") Signed-off-by: NEdward Cree <ecree@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Madalin Bucur 提交于
Remove the use of arch_setup_dma_ops() that was not exported and was breaking loadable module compilation. Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Madalin Bucur 提交于
Make sure dma_ops are set, to be later used by the Ethernet driver. Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Alex Deucher 提交于
Fixes resume from suspend. bug: https://bugzilla.kernel.org/show_bug.cgi?id=196121Reported-by: NPrzemek <soprwa@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Disable PX on these systems. bug: https://bugs.freedesktop.org/show_bug.cgi?id=101491Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Increase the default display clock on newer asics to accomodate some high res modes with really high refresh rates. bug: https://bugs.freedesktop.org/show_bug.cgi?id=93826Acked-by: NChunming Zhou <david1.zhou@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
We were using the wrong structure which lead to an overflow on some boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=101387Acked-by: NChunming Zhou <david1.zhou@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 20 6月, 2017 14 次提交
-
-
由 Ralph Sennhauser 提交于
As it turns out more than just Armada 370 and XP support using GPIO lines as PWM lines. For example the Armada 38x family has the same hardware support. As such "marvell,armada-370-xp-gpio" for the compatible string is a misnomer. Change the compatible string to "marvell,armada-370-gpio" before the driver makes it out of the -rc stage. This also follows the practice of using only the first device family supported as part of the name. Also update the documentation and comments in the code accordingly. Fixes: 757642f9 ("gpio: mvebu: Add limited PWM support") Signed-off-by: NRalph Sennhauser <ralph.sennhauser@gmail.com> Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Daniel Stone 提交于
Setting these bits causes libinput to fail to initialize the device; setting BTN_TOUCH and BTN_TOOL_FINGER causes it to treat the mouse as a touchpad, and it then refuses to continue when it discovers ABS_X is not set. This breaks all known Wayland compositors, as well as Xorg when the libinput driver is being used. This reverts commit f4b65b95. Signed-off-by: NDaniel Stone <daniels@collabora.com> Cc: Che-Liang Chiou <clchiou@chromium.org> Cc: Thierry Escande <thierry.escande@collabora.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 Daniel Drake 提交于
Without this quirk, the touchpad is not responsive on this product, with the following message repeated in the logs: psmouse serio1: bad data from KBC - timeout Add it to the notimeout list alongside other similar Fujitsu laptops. Signed-off-by: NDaniel Drake <drake@endlessm.com> Cc: stable@vger.kernel.org Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Manish Rangankar 提交于
Signed-off-by: NManish Rangankar <manish.rangankar@cavium.com> Reviewed-by: NLee Duncan <lduncan@suse.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Manish Rangankar 提交于
Signed-off-by: NManish Rangankar <manish.rangankar@cavium.com> Reviewed-by: NLee Duncan <lduncan@suse.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
-
由 Jason A. Donenfeld 提交于
Odd versions of gcc for the sh4 architecture will actually warn about flags being used while uninitialized, so we set them to zero. Non crazy gccs will optimize that out again, so it doesn't make a difference. Next, over aggressive gccs could inline the expression that defines use_lock, which could then introduce a race resulting in a lock imbalance. By using READ_ONCE, we prevent that fate. Finally, we make that assignment const, so that gcc can still optimize a nice amount. Finally, we fix a potential deadlock between primary_crng.lock and batched_entropy_reset_lock, where they could be called in opposite order. Moving the call to invalidate_batched_entropy to outside the lock rectifies this issue. Fixes: b169c13dSigned-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NTheodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org
-
由 Junshan Fang 提交于
Signed-off-by: NJunshan Fang <Junshan.Fang@amd.com> Reviewed-by: NRoger.He <Hongbo.He@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Dhinakaran Pandiyan 提交于
Maarten and Ville noticed that we are enabling backlight via DP aux very early in the modeset_init path via the intel_dp_aux_setup_backlight() function, since commit e7156c83 ("drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)"). Looks like all we need to do during _setup_backlight() is read the current brightness state instead of modifying it. v2: Rewrote commit message. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Yetunde Adebisi <yetundex.adebisi@intel.com> Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: NJani Nikula <jani.nikula@intel.com> Tested-by: NPuthikorn Voravootivat <puthik@chromium.org> Fixes: e7156c83 ("drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)") Link: http://patchwork.freedesktop.org/patch/msgid/1497384239-2965-1-git-send-email-dhinakaran.pandiyan@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit f6262bda) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1497895708-19422-1-git-send-email-dhinakaran.pandiyan@intel.com
-
由 Allen Hubbe 提交于
Do not sleep in ntb_async_tx_submit, which could deadlock. This reverts commit "8c874cc1" Fixes: 8c874cc1 ("NTB: Address out of DMA descriptor issue with NTB") Reported-by: NJia-Ju Bai <baijiaju1990@163.com> Signed-off-by: NAllen Hubbe <Allen.Hubbe@dell.com> Acked-by: NDave Jiang <dave.jiang@intel.com> Signed-off-by: NJon Mason <jdmason@kudzu.us>
-
由 Dave Jiang 提交于
Fixing doorbell register length to 32bits per spec. On Skylake NTB, the doorbell registers are 32bit write only registers. The source for the doorbell is a 64bit register that shows the interrupt bits. Signed-off-by: NDave Jiang <dave.jiang@intel.com> Fixes: 783dfa6c ("ntb: Adding Skylake Xeon NTB support") Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com> Signed-off-by: NJon Mason <jdmason@kudzu.us>
-
由 Logan Gunthorpe 提交于
A divide by zero error occurs if qp_count is less than mw_count because num_qps_mw is calculated to be zero. The calculation appears to be incorrect. The requirement is for num_qps_mw to be set to qp_count / mw_count with any remainder divided among the earlier mws. For example, if mw_count is 5 and qp_count is 12 then mws 0 and 1 will have 3 qps per window and mws 2 through 4 will have 2 qps per window. Thus, when mw_num < qp_count % mw_count, num_qps_mw is 1 higher than when mw_num >= qp_count. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> Fixes: e26a5843 ("NTB: Split ntb_hw_intel and ntb_transport drivers") Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com> Signed-off-by: NJon Mason <jdmason@kudzu.us>
-
由 Logan Gunthorpe 提交于
In cases where there are more mw's than spads/2-2, the mw count gets reduced to match the limitation. ntb_transport also tries to ensure that there are fewer qps than mws but uses the full mw count instead of the reduced one. When this happens, the math in 'ntb_transport_setup_qp_mw' will get confused and result in a kernel paging request bug. This patch fixes the bug by reducing qp_count to the reduced mw count instead of the full mw count. Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> Fixes: e26a5843 ("NTB: Split ntb_hw_intel and ntb_transport drivers") Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com> Signed-off-by: NJon Mason <jdmason@kudzu.us>
-
由 Gary R Hook 提交于
The order parameters are powers of 2; adjust the usage information to use correct mathematical representations. Signed-off-by: NGary R Hook <gary.hook@amd.com> Fixes: 8a7b6a77 ("ntb: ntb perf tool") Acked-by: NDave Jiang <dave.jiang@intel.com> Signed-off-by: NJon Mason <jdmason@kudzu.us>
-
由 Lin Yun Sheng 提交于
This patch fixes the phy loopback self_test failed issue. when Marvell Phy Module is loaded, it will powerdown fiber when doing phy loopback self test, which cause phy loopback self_test fail. Signed-off-by: NLin Yun Sheng <linyunsheng@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 19 6月, 2017 3 次提交
-
-
由 Raju Rangoju 提交于
During the module initialisation there is a possible race (basically race between uld and lld) where neither the uld nor lld notifies the uP about where to route the ctrl queue completions. LLD skips notifying uP as the rdma queues were not created by then (will leave it to ULD to notify the uP). As the ULD comes up, it also skips notifying the uP as the flag FULL_INIT_DONE is not set yet (ULD assumes that the interface is not up yet). Consequently, this race between uld and lld leaves uP unnotified about where to send the ctrl queue completions to, leading to iwarp RI_RES WR failure. Here is the race: CPU 0 CPU1 - allocates nic rx queus - t4_sge_alloc_ctrl_txq() (if rdma rsp queues exists, tell uP to route ctrl queue compl to rdma rspq) - acquires the mutex_lock - allocates rdma response queues - if FULL_INIT_DONE set, tell uP to route ctrl queue compl to rdma rspq - relinquishes mutex_lock - acquires the mutex_lock - enable_rx() - set FULL_INIT_DONE - relinquishes mutex_lock This patch fixes the above issue. Fixes: e7519f99('cxgb4: avoid enabling napi twice to the same queue') Signed-off-by: NRaju Rangoju <rajur@chelsio.com> Acked-by: NSteve Wise <swise@opengridcomputing.com> CC: Stable <stable@vger.kernel.org> # 4.9+ Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ville Syrjälä 提交于
If intel_crtc_disable_noatomic() were to ever get called during resume we'd end up deadlocking since resume has its own acqcuire_ctx but intel_crtc_disable_noatomic() still tries to use the mode_config.acquire_ctx. Pass down the correct acquire ctx from the top. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-3-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit da1d0e26) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Ville Syrjälä 提交于
Pass down the correct acquire context to the pipe A quirk load detect hack during display resume. Avoids deadlocking the entire thing. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit aecd36b8) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-