- 08 Dec, 2016 8 commits
-
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1644505 The PTFF instruction is not a function of ETR, rename and move the PTFF definitions from etr.h to timex.h. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 9dc06ccf) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1644505 The sync clock operation of the channel subsystem call for STP delivers the TOD clock difference as a result. Use this TOD clock difference instead of the difference between the TOD timestamps before and after the sync clock operation. Signed-off-by:
-
Luis Henriques authored
UBUNTU: [Config] Increase the NR_CPUS to 512 for amd64 to support systems with a large number of cores. BugLink: http://bugs.launchpad.net/bugs/1579205Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1648449 The NVMe driver currently configures a single MSI/MSIX interrupt for its admin queue, then later after initializing the NVMe controller and detecting the number of queues the controller can handle, the driver releases its MSI/MSIX interrupt and immediately re-configures enough MSI/MSIX interrupts for all the queues. However, on Amazon AWS instances with passthrough NVMe drives, this MSI/MSIX release/request causes failures of some of the interrupts, resulting in some (usually all but one or two but sometimes none) of the NVMe drive(s) failing to initialize. This combines the MSI/MSIX configurations, so all the MSI/MSIX configuration is done once. This avoids the interrupt failures, but it also results in more MSI/MSIX interrupts being configured than are needed. Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
Brad Figg <brad.figg@canonical.com>
-
Brad Figg authored
Signed-off-by: -
Luis Henriques authored
Signed-off-by: -
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1647887 Commit 90c9712f ("NVMe: Always use MSI/MSI-x interrupts") changed the NVMe driver to always use MSI/MSI-x interrupts. However, later commit 30d6592f ("NVMe: Don't unmap controller registers on reset") as well as commit e9820e41 ("UBUNTU: (fix) NVMe: Don't unmap controller registers on reset") accidentally reverted part of the original commit, which reverted the NVMe driver to using GSI interrupts instead of always using MSI/MSI-x interrupts. This un-reverts the accidental reversion, to restore the NVMe driver to always use MSI/MSI-x interrupts. Signed-off-by:
Thadeu Lima de Souza Cascardo <thadeu.cascardo@canonical.com> Acked-by:
-
Luis Henriques authored
Ignore: yes Signed-off-by:
-
- 07 Dec, 2016 1 commit
-
-
Luis Henriques authored
Signed-off-by:
-
- 06 Dec, 2016 31 commits
-
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1646643 Update to latest upstream driver version, from: http://support.huawei.com/enterprise/SoftwareVersionActionNew!showVDetailNew?lang=en&idAbsPath=fixnode01%7C7919749%7C9856522%7C9856629%7C21242728&pid=21242728&vrc=21243470%7C21243471%7C21243473%7C21992501&from=soft&tab=bz&bz_vr=21243471&bz_vrc=&nbz_vr=nullSigned-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1633577Signed-off-by:
-
Andrey Smetanin authored
BugLink: https://bugs.launchpad.net/bugs/1644394 Actually kvm_arch_irq_routing_update() should be kvm_arch_post_irq_routing_update() as it's called at the end of irq routing update. This renaming frees kvm_arch_irq_routing_update function name. kvm_arch_irq_routing_update() weak function which will be used to update mappings for arch-specific irq routing entries (in particular, the upcoming Hyper-V synthetic interrupts). Signed-off-by:
Andrey Smetanin <asmetanin@virtuozzo.com> Reviewed-by:
Roman Kagan <rkagan@virtuozzo.com> Signed-off-by:
Denis V. Lunev <den@openvz.org> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit abdb080f) Signed-off-by:
Steve Rutherford <srutherford@google.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1645453Signed-off-by:
-
Anders K. Pedersen authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit a8b1e36d upstream. With HZ=100 element timeout in dynamic sets (i.e. flow tables) is 10 times higher than configured. Add proper conversion to/from jiffies, when interacting with userspace. I tested this on Linux 4.8.1, and it applies cleanly to current nf and nf-next trees. Fixes: 22fe54d5 ("netfilter: nf_tables: add support for dynamic set updates") Signed-off-by:
Anders K. Pedersen <akp@cohaesio.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mark Bloch authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 9db0ff53 upstream. When there is a CM id object that has port assigned to it, it means that the cm-id asked for the specific port that it should go by it, but if that port was removed (hot-unplug event) the cm-id was not updated. In order to fix that the port keeps a list of all the cm-id's that are planning to go by it, whenever the port is removed it marks all of them as invalid. This commit fixes a kernel panic which happens when running traffic between guests and we force reboot a guest mid traffic, it triggers a kernel panic: Call Trace: [<ffffffff815271fa>] ? panic+0xa7/0x16f [<ffffffff8152b534>] ? oops_end+0xe4/0x100 [<ffffffff8104a00b>] ? no_context+0xfb/0x260 [<ffffffff81084db2>] ? del_timer_sync+0x22/0x30 [<ffffffff8104a295>] ? __bad_area_nosemaphore+0x125/0x1e0 [<ffffffff81084240>] ? process_timeout+0x0/0x10 [<ffffffff8104a363>] ? bad_area_nosemaphore+0x13/0x20 [<ffffffff8104aabf>] ? __do_page_fault+0x31f/0x480 [<ffffffff81065df0>] ? default_wake_function+0x0/0x20 [<ffffffffa0752675>] ? free_msg+0x55/0x70 [mlx5_core] [<ffffffffa0753434>] ? cmd_exec+0x124/0x840 [mlx5_core] [<ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0 [<ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0 [<ffffffff8152a815>] ? page_fault+0x25/0x30 [<ffffffffa024da25>] ? cm_alloc_msg+0x35/0xc0 [ib_cm] [<ffffffffa024e821>] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm] [<ffffffffa024f836>] ? cm_destroy_id+0x176/0x320 [ib_cm] [<ffffffffa024fb00>] ? ib_destroy_cm_id+0x10/0x20 [ib_cm] [<ffffffffa034f527>] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib] [<ffffffffa034f590>] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib] [<ffffffffa034f5a5>] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib] [<ffffffff81094d20>] ? worker_thread+0x170/0x2a0 [<ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40 [<ffffffff81094bb0>] ? worker_thread+0x0/0x2a0 [<ffffffff8109aef6>] ? kthread+0x96/0xa0 [<ffffffff8100c20a>] ? child_rip+0xa/0x20 [<ffffffff8109ae60>] ? kthread+0x0/0xa0 [<ffffffff8100c200>] ? child_rip+0x0/0x20 Fixes: a977049d ("[PATCH] IB: Add the kernel CM implementation") Signed-off-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Reviewed-by:
Maor Gottlieb <maorg@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Tariq Toukan authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 5b810a24 upstream. The real QP is destroyed in case of the ref count reaches zero, but for XRC target QPs this call was missed and caused to QP leaks. Let's call to destroy for all flows. Fixes: 0e0ec7e0 ('RDMA/core: Export ib_open_qp() to share XRC...') Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
Noa Osherovich <noaos@mellanox.com> Signed-off-by:
-
Mark Bloch authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 3c7ba576 upstream. sg_alloc_table gets unsigned int as parameter while the driver returns it as size_t. Check npages isn't greater than maximum unsigned int. Fixes: eeb8461e ("IB: Refactor umem to use linear SG table") Signed-off-by:
-
Eli Cohen authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit dbaaff2a upstream. When an internal error condition is detected, make sure to set the device inactive after dispatching the event so ULPs can get a notification of this event. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Eli Cohen <eli@mellanox.com> Signed-off-by:
Mohamad Haj Yahia <mohamad@mellanox.com> Signed-off-by:
-
Daniel Jurgens authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 16b0e069 upstream. When creating kernel CQs use 128B CQE stride if the cache line size is 128B, 64B otherwise. This prevents multiple CQEs from residing in a 128B cache line, which can cause retries when there are concurrent read and writes in one cache line. Tested with IPoIB on PPC64, saw ~5% throughput improvement. Fixes: e126ba97 ('mlx5: Add driver for Mellanox Connect-IB adapters') Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
Matan Barak authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 593ff73b upstream. Currently, if ib_copy_to_udata fails, the CQ won't be deleted from the radix tree and the HW (HW2SW). Fixes: 225c7b1f ('IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters') Signed-off-by:
Matan Barak <matanb@mellanox.com> Signed-off-by:
-
Daniel Jurgens authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 37995116 upstream. Check the returned GID index value and return an error if it is invalid. Fixes: 5070cd22 ('IB/mlx4: Replace mechanism for RoCE GID management') Signed-off-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
-
Brian Norris authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 6f75c3fd upstream. Consider two devices, A and B, where B is a child of A, and B utilizes asynchronous suspend (it does not matter whether A is sync or async). If B fails to suspend_noirq() or suspend_late(), or is interrupted by a wakeup (pm_wakeup_pending()), then it aborts and sets the async_error variable. However, device A does not (immediately) check the async_error variable; it may continue to run its own suspend_noirq()/suspend_late() callback. This is bad. We can resolve this problem by doing our error and wakeup checking (particularly, for the async_error flag) after waiting for children to suspend, instead of before. This also helps align the logic for the noirq and late suspend cases with the logic in __device_suspend(). It's easy to observe this erroneous behavior by, for example, forcing a device to sleep a bit in its suspend_noirq() (to ensure the parent is waiting for the child to complete), then return an error, and watch the parent suspend_noirq() still get called. (Or similarly, fake a wakeup event at the right (or is it wrong?) time.) Fixes: de377b39 (PM / sleep: Asynchronous threads for suspend_late) Fixes: 28b6fd6e (PM / sleep: Asynchronous threads for suspend_noirq) Reported-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit ceb75787 upstream. Make sure to drop the reference taken by class_find_device() after opening the RTC device. Fixes: 77437fd4 (pm: boot time suspend selftest) Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit d6124b40 upstream. This subsystem consistently fails to drop the device reference taken by class_find_device(). Note that some of these lookup functions already take a reference to the returned data, while others claim no reference is needed (or does not seem need one). Fixes: 183b9b59 ("uwb: add the UWB stack (core files)") Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 722f1910 upstream. Make sure to drop the reference taken by bus_find_device_by_name() before returning from mfd_clone_cell(). Fixes: a9bbba99 ("mfd: add platform_device sharing support for mfd") Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Luca Coelho authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit e0d9727c upstream. The SPLC data parsing is too restrictive and was not trying find the correct element for WiFi. This causes problems with some BIOSes where the SPLC method exists, but doesn't have a WiFi entry on the first element of the list. The domain type values are also incorrect according to the specification. Fix this by complying with the actual specification. Additionally, replace all occurrences of SPLX to SPLC, since SPLX is only a structure internal to the ACPI tables, and may not even exist. Fixes: bcb079a1 ("iwlwifi: pcie: retrieve and parse ACPI power limitations") Reported-by:
Chris Rorvick <chris@rorvick.com> Tested-by:
Paul Bolle <pebolle@tiscali.nl> Tested-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Lokesh Vutla authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 3984903a upstream. RTC can be clocked from an external 32KHz oscillator, or from the Peripheral PLL. The RTC has an internal oscillator buffer to support direct operation with a crystal. ---------------------------------------- | Device --------- | | | | | | | RTCSS | | | --------- | | | OSC |<------| RTC | | | | |------>| OSC |--- | | | | -------- | | | | | ----|clk | | | -------- | | | | | | PRCM |--- | | | | -------- -------- | ---------------------------------------- The RTC functional clock is sourced by default from the clock derived from the Peripheral PLL. In order to select source as external osc clk the following changes needs to be done: - Enable the RTC OSC (RTC_OSC_REG[4]OSC32K_GZ = 0) - Enable the clock mux(RTC_OSC_REG[6]K32CLK_EN = 1) - Select the external clock source (RTC_OSC_REG[3]32KCLK_SEL = 1) Fixes: 399cf0f6 ("rtc: omap: Add external clock enabling support") Signed-off-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
Dave Gerlach <d-gerlach@ti.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit a29e52a6 upstream. Fix the retrn value check which testing the wrong variable in mmp2_clk_init(). Fixes: 1ec770d9 ("clk: mmp: add mmp2 DT support for clock driver") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit deab0726 upstream. Fix the retrn value check which testing the wrong variable in pxa168_clk_init(). Fixes: ab08aefc ("clk: mmp: add pxa168 DT support for clock driver") Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 10f2bfb0 upstream. Fix the retrn value check which testing the wrong variable in pxa910_clk_init(). Fixes: 2bc61da9 ("clk: mmp: add pxa910 DT support for clock driver") Signed-off-by:
-
Mario Kleiner authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 8e94a46c upstream. External clients which import our bo's wait only for exclusive dmabuf-fences, not on shared ones, ditto for bo's which we import from external providers and write to. Therefore attach exclusive fences on prime shared buffers if our exported buffer gets imported by an external client, or if we import a buffer from an external exporter. See discussion in thread: https://lists.freedesktop.org/archives/dri-devel/2016-October/122370.html Prime export tested on Intel iGPU + AMD Tonga dGPU as DRI3/Present Prime render offload, and with the Tonga standalone as primary gpu. v2: Add a wait for all shared fences before prime export, as suggested by Christian Koenig. v3: - Mark buffer prime_exported in amdgpu_gem_prime_pin, so we only use the exclusive fence when exporting a bo to external clients like a separate iGPU, but not when exporting/importing from/to ourselves as part of regular DRI3 fd passing. - Propagate failure of reservation_object_wait_rcu back to caller. v4: - Switch to a prime_shared_count counter instead of a flag, which gets in/decremented on prime_pin/unpin, so we can switch back to shared fences if all clients detach from our exported bo. - Also switch to exclusive fence for prime imported bo's. v5: - Drop lret, instead use int ret -> long ret, as proposed by Christian. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95472 Tested-by: Mike Lothian <mike@fireburn.co.uk> (v1) Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com>. Cc: Christian König <christian.koenig@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Sven Ebenfeld authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 83d2c9a9 upstream. When using AES-XTS on a Wandboard, we receive a Mode error: caam_jr 2102000.jr1: 20001311: CCB: desc idx 19: AES: Mode error. According to the Security Reference Manual, the Low Power AES units of the i.MX6 do not support the XTS mode. Therefore we must not register XTS implementations in the Crypto API. Signed-off-by:
Sven Ebenfeld <sven.ebenfeld@gmail.com> Reviewed-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Theodore Ts'o authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 8cdf3372 upstream. If the block size or cluster size is insane, reject the mount. This is important for security reasons (although we shouldn't be just depending on this check). Ref: http://www.securityfocus.com/archive/1/539661 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506Reported-by:
Borislav Petkov <bp@alien8.de> Reported-by:
Nikolay Borisov <kernel@kyup.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Borislav Petkov authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit c6a38553 upstream. So Sebastian turned off the PIE for kernel builds but that was too late - Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc options with, say cc-disable-warning, fails: gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs ... -Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp /dev/null:1:0: error: code model kernel does not support PIC mode because that returns an error and we can't disable the warning. For example in this case: KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,) which leads to gcc issuing all those warnings again. So let's turn off PIE/PIC at the earliest possible moment, when we declare KBUILD_CFLAGS so that cc-disable-warning picks it up too. Also, we need the $(call cc-option ...) because -fno-PIE is supported since gcc v3.4 and our lowest supported gcc version is 3.2 right now. Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 90944e40 upstream. If the gcc is configured to do -fPIE by default then the build aborts later with: | Unsupported relocation type: unknown type rel type name (29) Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 82031ea2 upstream. Adding -no-PIE to the fstack protector check. -no-PIE was introduced before -fstack-protector so there is no need for a runtime check. Without it the build stops: |Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken due to -mcmodel=kernel + -fPIE if -fPIE is enabled by default. Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by:
-
Sebastian Andrzej Siewior authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 8ae94224 upstream. Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic Tagging it stable so it is possible to compile recent stable kernels as well. Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 93d710a6 upstream. We get the following build error from UM Linux after adding an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX": ERROR: "devm_ioremap_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! ERROR: "of_address_to_resource" [drivers/i2c/muxes/i2c-mux-reg.ko] undefined! It appears that the I2C mux core code depends on HAS_IOMEM for historical reasons, while CONFIG_I2C_MUX_REG does *not* have a direct dependency on HAS_IOMEM. This creates a situation where a allyesconfig or allmodconfig for UM Linux will select I2C_MUX, and will implicitly enable I2C_MUX_REG as well, and the compilation will fail for the register driver. Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and removing the dependency from I2C_MUX. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Reported-by:
Jonathan Cameron <jic23@jic23.retrosnub.co.uk> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Jonathan Cameron <jic23@kernel.org> Acked-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Oliver Hartkopp authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit deb507f9 upstream. Andrey Konovalov reported an issue with proc_register in bcm.c. As suggested by Cong Wang this patch adds a lock_sock() protection and a check for unsuccessful proc_create_data() in bcm_connect(). Reference: http://marc.info/?l=linux-netdev&m=147732648731237Reported-by:
Andrey Konovalov <andreyknvl@google.com> Suggested-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Acked-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Azhar Shaikh authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 274e43ed upstream. Commit 41a3da2b ("mfd: intel-lpss: Save register context on suspend") saved the register context while going to suspend and also put the device in reset state. Due to the resetting of device, system cannot enter S3/S0ix states when no_console_suspend flag is enabled. The system and serial console both hang. The resetting of device is not needed while going to suspend. Hence remove this code. Fixes: 41a3da2b ("mfd: intel-lpss: Save register context on suspend") Signed-off-by:
Azhar Shaikh <azhar.shaikh@intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
