- 16 10月, 2014 1 次提交
-
-
由 Wei Yan 提交于
I2C drivers for hix5hd2 soc series, including following chipset Hi3716CV200, Hi3719CV100, Hi3718CV100, Hi3719MV100, Hi3718MV100. Signed-off-by: NWei Yan <sledge.yanwei@huawei.com> Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org> [wsa: folded dt docs into this patch] Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 07 10月, 2014 4 次提交
-
-
由 Fabio Estevam 提交于
In the case of errors during probe, we should disable i2c_imx->clk. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Carl Peng 提交于
Add support for AMD version of the DW I2C host controller. The device is enumerated from ACPI namespace with ACPI ID AMD0010. Because the core driver needs an input source clock, and this is not an Intel LPSS device where clocks are provided through drivers/acpi/acpi_lpss.c, we register the clock ourselves if the clock rate is given in ->driver_data Signed-off-by: NCarl Peng <carlpeng008@gmail.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Mika Westerberg 提交于
In order to be able to create missing clock for AMD (and in future possibly others) we move getting clock for the device a bit later. Also make ACPI/DT configuration in the same place depending on from where the device was enumerated from. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Mika Westerberg 提交于
There is no way in ACPI to tell in which speed the host controller is supposed to run, so we default to fast mode (400KHz). Since this has been the default all the time there should be no functional changes with this change. This is the first step required to refactor the driver probe so that we can supply source clock from ACPI part of the driver to the core. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 03 10月, 2014 3 次提交
-
-
由 Anders Berg 提交于
Add I2C bus driver for the controller found in the LSI Axxia family SoCs. The driver implements 10-bit addressing and SMBus transfer modes via emulation (including SMBus block data read). Signed-off-by: NAnders Berg <anders.berg@avagotech.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Naveen Krishna Ch 提交于
The HSI2C module on Exynos7 differs in the transfer status bits. Transfer status bits were moved to INT_ENABLE and INT_STATUS registers This patch adds support for the HSI2C module on Exynos7. 1. Implementes a "hw" field in the variant struct to distinguish the hardware. 2. Updates the dt-new compatible in dt-binding documenation Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Janusz Użycki 提交于
i2cdetect scanned i2c bus slow because the i2c-mxs driver ignored the NO_SLAVE_ACK bit during busy-waiting loop. Thanks to the patch, the speedup happens. Signed-off-by: NJanusz Uzycki <j.uzycki@elproma.com.pl> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 30 9月, 2014 11 次提交
-
-
由 Doug Anderson 提交于
In <https://lkml.org/lkml/2014/6/10/265> pointed out that the 10-bit flag in the cros_ec_tunnel was useless. It went into a 16-bit flags field but was defined at (1 << 16). Since we have no 10-bit i2c devices on the other side of the tunnel on any known devices this was never a problem. Until we do it makes sense to remove this code. On the EC side the code to handle this flag was removed in <https://chromium-review.googlesource.com/204162>. Reported-by: NDave Jones <davej@redhat.com> Signed-off-by: NDoug Anderson <dianders@chromium.org> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Sjoerd Simons 提交于
To enable the cros-ec-tunnel driver to be auto-loaded when build as a module add an of match table (and export it) to match the modalias information passed on to userspace as the Cros EC MFD driver registers the MFD subdevices with an of_compatibility string. Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk> Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
gcc rightfully says: drivers/i2c/busses/i2c-rcar.c:198:10: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Fan Du 提交于
Software is allowed to allocate number of descriptor size from 2 to 256, this i2c controller could process more descriptor, but for i2c core soft ware layer, only one i2c transaction is allowed each time. So here switch to minimum 2 descriptor when initialization. Signed-off-by: NFan Du <fan.du@intel.com> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Haibo Chen 提交于
According to the i.mx spec, for multimaster mode, if I2C is enabled when the bus is busy and asserts start, hardware inhibits the transmission, clears MSTA without signaling a stop, generate an interrupt, and set I2C_I2SR[IAL] to indicate a failed attempt to engage the bus, which means arbitration lost. In this case, we should first test I2C_I2SR[IAL], and clear this bit if it is set, and then I2C controller default to slave receive mode. This patch check the IAL bit every time before an I2c transmission. if IAL is set, clear it and make I2C controller to default mode. Signed-off-by: NHaibo Chen <haibo.chen@freescale.com> Acked-by: NFugang Duan <B38611@freescale.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Doug Anderson 提交于
Having a transfer more than 32 bits is not all that unlikely. Remove the annotation. The unlikely in the IRQ handler can't gain us much. It's not in a loop, so at most it would save 1 instruction per IRQ, which isn't much. In fact on the compiler I tested it produced the exact same code. Remove it too. Suggested-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Sergei Shtylyov 提交于
Check if the ICMSR register (masked with the ICMIER register) evaluates to 0 in the driver's interrupt handler and return IRQ_NONE in that case, like many other drivers do. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Sergei Shtylyov 提交于
rcar_i2c_prepare_msg() always returns 0, so we can make this function return *void* and thus remove the result check in rcar_i2c_master_xfer(). Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Sergei Shtylyov 提交于
rcar_i2c_master_xfer() needlessly compares the message pointers (using indirect addressing) in order to detect the last I2C message, while it's enough to only compare the message indexes. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Tan, Raymond 提交于
Use the platform data to set the clk_freq when there is no DT configuration available. The clk_freq in turn will determine the I2C speed mode. In Quark, there is currently no other configuration mechanism other than board files. Signed-off-by: NRaymond Tan <raymond.tan@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: NHock Leong Kweh <hock.leong.kweh@intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Romain Baeriswyl 提交于
Some legacy devices support ony I2C standard mode at 100kHz. This patch allows to select the standard mode through the DTS with the use of the existing clock-frequency parameter. When clock-frequency parameter is not set, the fast mode is selected. Only when the parameter is set at 100000, the standard mode is selected. Signed-off-by: NRomain Baeriswyl <romainba@abilis.com> Reviewed-by: NChristian Ruppert <christian.ruppert@abilis.com> Acked-by: NAlan Tull <atull@opensource.altera.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 26 9月, 2014 1 次提交
-
-
由 Pali Rohár 提交于
Without proper alias kernel module is not loaded for rtc-efi driver. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Cc: dann frazier <dannf@dannf.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 25 9月, 2014 7 次提交
-
-
由 Peter Hüwe 提交于
If adapter->dev.parent == NULL there is a NULL pointer dereference in acpi_i2c_install_space_handler and acpi_i2c_remove_space_handler. This is present since introduction of this code: 36604751 "i2c: rework kernel config I2C_ACPI" or even da3c6647 "I2C/ACPI: Clean up I2C ACPI code and Add CONFIG_I2C_ACPI" The adapter->dev.parent == NULL case is valid for the i2c_stub, so loading i2c_stub with ACPI_I2C_OPREGION enabled results in an oops. This is also valid at least for i2c_tiny_usb and i2c_robotfuzz_osif. Fix by checking whether it is null before calling ACPI_HANDLE. Signed-off-by: NPeter Huewe <peterhuewe@gmx.de> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
Commit 5d98e61d ("I2C/ACPI: Add i2c ACPI operation region support") renamed the i2c-core module. This may cause regressions for distributions, so put the ACPI code back into the core. Reported-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Tested-by: NLan Tianyu <tianyu.lan@intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Srinivas Kandagatla 提交于
In cases where board has below memory DT node memory{ device_type = "memory"; reg = <0x80000000 0x80000000>; }; Check on the memory range in fdt.c will always fail because it is comparing MAX_PHYS_ADDR with base + size, in fact it should compare it with base + size - 1. This issue was originally noticed on Qualcomm IFC6410 board. Without this patch kernel shows up noticed unnecessary warnings [ 0.000000] Machine model: Qualcomm APQ8064/IFC6410 [ 0.000000] Ignoring memory range 0xffffffff - 0x100000000 [ 0.000000] cma: Reserved 64 MiB at ab800000 as a result the size get reduced to 0x7fffffff which looks wrong. This patch fixes the check involved in generating this warning and as a result it also fixes the wrong size calculation. Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org> [grant.likely: adjust new size calculation also] Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-
由 Marcos Paulo de Souza 提交于
We need to add this module to the nomux table to be able to detect the touchpad. Cc: stablevger.kernel.org Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Srinivas Pandruvada 提交于
Fix code when the operation region callback is for an gpio, which is not at index 0 and for partial pins in a GPIO definition. For example: Name (GMOD, ResourceTemplate () { //3 Outputs that define the Power mode of the device GpioIo (Exclusive, PullDown, , , , "\\_SB.GPI2") {10, 11, 12} }) } If opregion callback calls is for: - Set pin 10, then address = 0 and bit length = 1 - Set pin 11, then address = 1 and bit length = 1 - Set for both pin 11 and pin 12, then address = 1, bit length = 2 This change requires updated ACPICA gpio operation handler code to send the pin index and bit length. Fixes: 473ed7be (gpio / ACPI: Add support for ACPI GPIO operation regions) Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 75ec6e55 ACPICA: Update to GPIO region handler interface. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Bob Moore 提交于
Changes to correct several GPIO issues: 1) The update_rule in a GPIO field definition is now ignored; a read-modify-write operation is never performed for GPIO fields. (Internally, this means that the field assembly/disassembly code is completely bypassed for GPIO.) 2) The Address parameter passed to a GPIO region handler is now the bit offset of the field from a previous Connection() operator. Thus, it becomes a "Pin Number Index" into the Connection() resource descriptor. 3) The bit_width parameter passed to a GPIO region handler is now the exact bit width of the GPIO field. Thus, it can be interpreted as "number of pins". Overall, we can now say that the region handler interface to GPIO handlers is a raw "bit/pin" addressed interface, not a byte-addressed interface like the system_memory handler interface. Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Fu Zhonghui 提交于
On some systems (Asus T100 in particular) there are strict ordering dependencies between LPSS devices with respect to power management that break if they suspend/resume asynchronously. In theory it should be possible to follow those dependencies in the async suspend/resume case too (the ACPI tables tell as that the dependencies are there), but since we're missing infrastructure for that at the moment, disable async suspend/resume for all of the LPSS devices for the time being. Link: http://marc.info/?l=linux-acpi&m=141158962321905&w=2 Fixes: 8ce62f85 (ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices) Signed-off-by: NLi Aubrey <aubrey.li@linux.intel.com> Signed-off-by: NFu Zhonghui <zhonghui.fu@linux.intel.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ [ rjw: Changelog ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 24 9月, 2014 5 次提交
-
-
由 Jarkko Nikula 提交于
There is possibility with misconfigured pins that interrupt occurs instantly after setting irq_set_chained_handler() in gpiochip_set_chained_irqchip(). Now if handler gets called before irq_set_handler_data() the handler gets NULL handler data. Fix this by moving irq_set_handler_data() call before irq_set_chained_handler() in gpiochip_set_chained_irqchip(). Cc: Stable <stable@vger.kernel.org> # 3.15+ Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
-
由 Adrian Hunter 提交于
GPIO direction flags are not getting set because an 'if' statement is the wrong way around. Cc: Stable <stable@vger.kernel.org> # 3.15+ Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com> Acked-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Tom Lendacky 提交于
If the ccp is built as a built-in module, then ccp-crypto (whether built as a module or a built-in module) will be able to load and it will register its crypto algorithms. If the system does not have a CCP this will result in -ENODEV being returned whenever a command is attempted to be queued by the registered crypto algorithms. Add an API, ccp_present(), that checks for the presence of a CCP on the system. The ccp-crypto module can use this to determine if it should register it's crypto alogorithms. Cc: stable@vger.kernel.org Reported-by: NScot Doyle <lkml14@scotdoyle.com> Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com> Tested-by: NScot Doyle <lkml14@scotdoyle.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Srinivas Kandagatla 提交于
since commit 31964ffe ("tty: serial: msm: Remove direct access to GSBI")' serial hangs if earlyprintk are enabled. This hang is noticed only when the GSBI driver is probed and all the earlyprintks before gsbi probe are seen on the console. The reason why it hangs is because GSBI driver disables hclk in its probe function without realizing that the serial IP might be in use by a bootconsole. As gsbi driver disables the clock in probe the bootconsole locks up. Turning off hclk's could be dangerous if there are system components like earlyprintk using the hclk. This patch fixes the issue by delegating the clock management to probe and remove functions in gsbi rather than disabling the clock in probe. More detailed problem description can be found here: http://www.spinics.net/lists/linux-arm-msm/msg10589.htmlTested-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Matt Fleming 提交于
This reverts commit f23cf8bd ("efi/x86: efistub: Move shared dependencies to <asm/efi.h>") as well as the x86 parts of commit f4f75ad5 ("efi: efistub: Convert into static library"). The road leading to these two reverts is long and winding. The above two commits were merged during the v3.17 merge window and turned the common EFI boot stub code into a static library. This necessitated making some symbols global in the x86 boot stub which introduced new entries into the early boot GOT. The problem was that we weren't fixing up the newly created GOT entries before invoking the EFI boot stub, which sometimes resulted in hangs or resets. This failure was reported by Maarten on his Macbook pro. The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all boot code paths"). However, that caused issues for Linus when booting his Sony Vaio Pro 11. It was subsequently reverted in commit f3670394. So that leaves us back with Maarten's Macbook pro not booting. At this stage in the release cycle the least risky option is to revert the x86 EFI boot stub to the pre-merge window code structure where we explicitly #include efi-stub-helper.c instead of linking with the static library. The arm64 code remains unaffected. We can take another swing at the x86 parts for v3.18. Conflicts: arch/x86/include/asm/efi.h Tested-by: NJosh Boyer <jwboyer@fedoraproject.org> Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com> Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64] Tested-by: NLinus Torvalds <torvalds@linux-foundation.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>, Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
- 23 9月, 2014 8 次提交
-
-
由 Emil Goode 提交于
In the brcmf_count_20mhz_channels function we are looping through a list of channels received from firmware. Since the index of the first channel is 0 the condition leads to an off by one bug. This is causing us to hit the WARN_ON_ONCE(1) calls in the brcmu_d11n_decchspec function, which is how I discovered the bug. Introduced by: commit b48d8916 ("brcmfmac: rework wiphy structure setup") Acked-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NEmil Goode <emilgoode@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Alex Deucher 提交于
Otherwise we may fail to init the second compute ring. Noticed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Jani Nikula 提交于
Check the correct bit for audio. Seems like a copy-paste error from the start: commit 9ed109a7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:54:52 2014 +0200 drm/i915: Track has_audio in the pipe config Reported-by: NMartin Andersen <martin.x.andersen@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82756 Cc: stable@vger.kernel.org # 3.16+ Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Peter Ujfalusi 提交于
When the audio stream is paused or suspended we stop the sDMA and when it is unpaused/resumed we start the channel without reconfiguring it. The omap_dma_stop() clears the link configuration when we pause the dma, but it is not setting it back on start. This will result only one audio buffer to be played back and the DMA will stop, since the linking is disabled. We need to restore the CLINK_CTRL register in case of resume. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
由 Peter Ujfalusi 提交于
Add mb() call to resume path to ensure the necessary barrier. Resume can happen after waking up from suspend for example. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
由 Brad Volkin 提交于
Ring init and cleanup are not balanced because we re-init the rings on resume without having cleaned them up on suspend. This leads to the driver leaking the parser's hash tables with a kmemleak signature such as this: unreferenced object 0xffff880405960980 (size 32): comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s) hex dump (first 32 bytes): d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00 ..F............. 98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00 .`(............. backtrace: [<ffffffff81816f9e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811fa678>] kmem_cache_alloc_trace+0x168/0x2f0 [<ffffffffc03e20a5>] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915] [<ffffffffc04088a2>] intel_init_ring_buffer+0x202/0x470 [i915] [<ffffffffc040c998>] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915] [<ffffffffc03eff59>] i915_gem_init_hw+0x2f9/0x3a0 [i915] [<ffffffffc03f0057>] i915_gem_init+0x57/0x1d0 [i915] [<ffffffffc045e26a>] i915_driver_load+0xc0a/0x10e0 [i915] [<ffffffffc02e0d5d>] drm_dev_register+0xad/0x100 [drm] [<ffffffffc02e3b9f>] drm_get_pci_dev+0x8f/0x200 [drm] [<ffffffffc03c934b>] i915_pci_probe+0x3b/0x60 [i915] [<ffffffff81436725>] local_pci_probe+0x45/0xa0 [<ffffffff81437a69>] pci_device_probe+0xd9/0x130 [<ffffffff81524f4d>] driver_probe_device+0x12d/0x3e0 [<ffffffff815252d3>] __driver_attach+0x93/0xa0 [<ffffffff81522e1b>] bus_for_each_dev+0x6b/0xb0 This patch extends the current convention of checking whether a resource is already allocated before allocating it during ring init. Longer term it might make sense to only init the rings once. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83794Tested-by: NKari Suvanto <kari.tj.suvanto@gmail.com> Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Yinghai Lu 提交于
pcie_poll_cmd() take msecs instead of jiffies, so convert timeout to msecs. Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time") Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Florian Fainelli 提交于
We should not be manipulaging the DMA_CTRL registers directly by writing 0 to them to disable DMA. This is an operation that needs to be timed to make sure the DMA engines have been properly stopped since their state machine stops on a packet boundary, not immediately. Make sure that tha bcmgenet_fini_dma() calls bcmgenet_dma_teardown() to ensure a proper DMA engine state. As a result, we need to reorder the function bodies to resolve the use dependency. Fixes: 1c1008c7 ("net: bcmgenet: add main driver file") Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-