- 06 Apr, 2016 40 commits
-
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Different implementations of Cavium ThunderX use different phys for network support. Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Andreas Färber authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Drop two extra occurrences of "on" in option title and help text. Fixes: 379d7ac7 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.") Cc: David Daney <david.daney@cavium.com> Signed-off-by:
Andreas Färber <afaerber@suse.de> Acked-by:
David Daney <david.daney@cavium.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit e2ad1f97) Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Previously we selected MDIO_OCTEON, which after creating the Thunder specific MDIO bus driver is much less useful. Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 When the code was factored out of mdio-octeon.c, the MODULE_DESCRIPTION, MODULE_AUTHOR and MODULE_LICENSE annotations were inadvertently omitted. Restore them so that we don't get kernel taint warnings upon module loading. Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 The Cavium Thunder SoCs have multiple MIDO buses that are part of a single PCI device. To model this in the device tree we call the PCI parent device a "cavium,thunder-8890-mdio-nexus", it has several children, one for each MDIO bus. The MDIO bus hardware is identical to that found in the OCTEON SoCs, so we use that code for things that are not part of the PCI driver probe/remove Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1562968Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 A follow-on patch uses PCI probing to find the Thunder MDIO hardware. In preparation for this, split out the common code into a new file mdio-cavium.c, which will be used by both the existing OCTEON driver, and the new Thunder PCI based driver. As part of the refactoring simplify the struct cavium_mdiobus by removing fields that are only ever used in the probe function and can just as well be local variables. Use readq/writeq in preference to readq_relaxed/writeq_relaxed as the relaxed form was an optimization for an early chip revision, and the MDIO drivers are not performance bottlenecks that need optimization in the first place. Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1562968Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1562968 Remove the call to force the octeon-mdio driver to be loaded. Allow the standard driver loading mechanisms to load the PHY drivers, and use -EPROBE_DEFER to cause the BGX driver to be probed only after the PHY drivers are available. Reorder the setting of MAC addresses and PHY probing to allow BGX LMACs with no attached PHY to still be assigned a MAC address. Signed-off-by:
-
Dan Williams authored
BugLink: http://bugs.launchpad.net/bugs/1563293 ZONE_DEVICE (merged in 4.3) and ZONE_CMA (proposed) are examples of new mm zones that are bumping up against the current maximum limit of 4 zones, i.e. 2 bits in page->flags for the GFP_ZONE_TABLE. The GFP_ZONE_TABLE poses an interesting constraint since include/linux/gfp.h gets included by the 32-bit portion of a 64-bit build. We need to be careful to only build the table for zones that have a corresponding gfp_t flag. GFP_ZONES_SHIFT is introduced for this purpose. This patch does not attempt to solve the problem of adding a new zone that also has a corresponding GFP_ flag. Vlastimil points out that ZONE_DEVICE, by depending on x86_64 and SPARSEMEM_VMEMMAP implies that SECTIONS_WIDTH is zero. In other words even though ZONE_DEVICE does not fit in GFP_ZONE_TABLE it is free to consume another bit in page->flags (expand ZONES_WIDTH) with room to spare. Link: https://bugzilla.kernel.org/show_bug.cgi?id=110931 Fixes: 033fbae9 ("mm: ZONE_DEVICE for "device memory"") Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Reported-by:
Mark <markk@clara.co.uk> Reported-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit b11a7b94) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1563293 This reverts commit f671c3e6. This patch never made it upstream. Instead, commit b11a7b94 ('mm: exclude ZONE_DEVICE from GFP_ZONE_TABLE') replaced it. Signed-off-by:
-
Sergey Senozhatsky authored
BugLink: http://bugs.launchpad.net/bugs/1534216 console_unlock() allows to cond_resched() if its caller has set `console_may_schedule' to 1, since 8d91f8b1 ("printk: do cond_resched() between lines while outputting to consoles"). The rules are: -- console_lock() always sets `console_may_schedule' to 1 -- console_trylock() always sets `console_may_schedule' to 0 However, console_trylock() callers (among them is printk()) do not always call printk() from atomic contexts, and some of them can cond_resched() in console_unlock(), so console_trylock() can set `console_may_schedule' to 1 for such processes. For !CONFIG_PREEMPT_COUNT kernels, however, console_trylock() always sets `console_may_schedule' to 0. It's possible to drop explicit preempt_disable()/preempt_enable() in vprintk_emit(), because console_unlock() and console_trylock() are now smart enough: a) console_unlock() does not cond_resched() when it's unsafe (console_trylock() takes care of that) b) console_unlock() does can_use_console() check. Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Cc: Jan Kara <jack@suse.com> Cc: Tejun Heo <tj@kernel.org> Cc: Kyle McMartin <kyle@kernel.org> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Calvin Owens <calvinowens@fb.com> Signed-off-by:
-
Thierry Reding authored
BugLink: http://bugs.launchpad.net/bugs/1560395 Provide subsystem-level suspend and resume helpers that can be used to implement suspend/resume on atomic mode-setting enabled drivers. v2: simplify locking, enhance kerneldoc comments v3: pass lock acquisition context by parameter, improve kerneldoc v4: - remove redundant code (already provided by atomic helpers) (Maarten Lankhorst) - move backoff dance from drm_modeset_lock_all_ctx() into suspend helper (Daniel Vetter) v5: handle potential EDEADLK from drm_atomic_helper_duplicate_state() and drm_atomic_helper_disable_all() (Daniel Vetter) Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449075005-13937-2-git-send-email-thierry.reding@gmail.comSigned-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 14942760) Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by:
-
Maarten Lankhorst authored
BugLink: http://bugs.launchpad.net/bugs/1560395 This is similar to the other drm_for_each_*_mask functions. Changes since v1: - Use for_each_if Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
-
Rafael J. Wysocki authored
BugLink: http://bugs.launchpad.net/bugs/1560395 Introduce a new runtime PM function, pm_runtime_get_if_in_use(), that will increment the device's runtime PM usage counter and return 1 if its status is RPM_ACTIVE and its usage counter is greater than 0 at the same time (0 will be returned otherwise). This is useful for things that should only be done if the device is active (from the runtime PM perspective) and used by somebody (as indicated by the usage counter) already and they are not worth bothering otherwise. Requested-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit a436b6a1) Signed-off-by:
-
Timo Aaltonen authored
BugLink: http://bugs.launchpad.net/bugs/1560395Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Starting with Windows 2012 R2, message inteerupts can be delivered on any VCPU in the guest. Support this functionality. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d81274aa) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1541585 This reverts commit 6e97c2369f18d020c1384bf0716aec6009e8128a.
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1541585 If util transport fails to initialize for any reason, the list of transport handlers may become corrupted due to freeing the transport handler without removing it from the list. Fix this by cleaning it up from the list. Signed-off-by:
Alex Ng <alexng@microsoft.com> Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Pass the channel information to the util drivers that need to defer reading the channel while they are processing a request. This would address the following issue reported by Vitaly: Commit 3cace4a6 ("Drivers: hv: utils: run polling callback always in interrupt context") removed direct *_transaction.state = HVUTIL_READY assignments from *_handle_handshake() functions introducing the following race: if a userspace daemon connects before we get first non-negotiation request from the server hv_poll_channel() won't set transaction state to HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on the first real request from the server. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Message header is modified by the hypervisor and we read it in a loop, we need to prevent compilers from optimizing accesses. There are no such optimizations at this moment, this is just a future proof. Suggested-by:
Radim Krcmar <rkrcmar@redhat.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 We have 3 functions dealing with messages and they all implement the same logic to finalize reads, move it to vmbus_signal_eom(). Suggested-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 wait_for_completion() may sleep, it enables interrupts and this is something we really want to avoid on crashes because interrupt handlers can cause other crashes. Switch to the recently introduced vmbus_wait_for_unload() doing busy wait instead. Reported-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 We must handle HVMSG_TIMER_EXPIRED messages in the interrupt context and we offload all the rest to vmbus_on_msg_dpc() tasklet. This functions loops to see if there are new messages pending. In case we'll ever see HVMSG_TIMER_EXPIRED message there we're going to lose it as we can't handle it from there. Avoid looping in vmbus_on_msg_dpc(), we're OK with handling one message per interrupt. Signed-off-by:
-
Andrey Smetanin authored
BugLink: http://bugs.launchpad.net/bugs/1541585 VMBus hypercall codes inside Hyper-V UAPI header will be used by QEMU to implement VMBus host devices support. Signed-off-by:
Andrey Smetanin <asmetanin@virtuozzo.com> Acked-by:
Roman Kagan <rkagan@virtuozzo.com> CC: Gleb Natapov <gleb@kernel.org> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Joerg Roedel <joro@8bytes.org> CC: "K. Y. Srinivasan" <kys@microsoft.com> CC: Haiyang Zhang <haiyangz@microsoft.com> CC: Roman Kagan <rkagan@virtuozzo.com> CC: Denis V. Lunev <den@openvz.org> CC: qemu-devel@nongnu.org [Do not rename the constant at the same time as moving it, as that would cause semantic conflicts with the Hyper-V tree. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (back ported from commit 18f09861) Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 On the channel send side, many of the VMBUS device drivers explicity serialize access to the outgoing ring buffer. Give more control to the VMBUS device drivers in terms how to serialize accesss to the outgoing ring buffer. The default behavior will be to aquire the ring lock to preserve the current behavior. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 The function hv_ringbuffer_read() is called always on a pre-assigned CPU. Each chnnel is bound to a specific CPU and this function is always called on the CPU the channel is bound. There is no need to acquire the spin lock; get rid of this overhead. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1541585 The hvsock driver needs this API to release all the resources related to the channel. Signed-off-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1541585 This will be used by the coming hv_sock driver. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Only the coming hv_sock driver has a "true" value for this flag. We treat the hvsock offers/channels as special VMBus devices. Since the hv_sock driver handles all the hvsock offers/channels, we need to tweak vmbus_match() for hv_sock driver, so we introduce this flag. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1541585 A function to send the type of message is also added. The coming net/hvsock driver will use this function to proactively request the host to offer a VMBus channel for a new hvsock connection. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1541585 When the hvsock channel's outbound ringbuffer is full (i.e., hv_ringbuffer_write() returns -EAGAIN), we should avoid the unnecessary signaling the host. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1541585 A helper function is also added. Signed-off-by:
-
Dexuan Cui authored
BugLink: http://bugs.launchpad.net/bugs/1541585 This will be used by the coming net/hvsock driver. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 clocksource_change_rating() involves mutex usage and can't be called in interrupt context. It also makes sense to avoid doing redundant work on crash. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 We have to call vmbus_initiate_unload() on crash to make kdump work but the crash can also be happening in interrupt (e.g. Sysrq + c results in such) where we can't schedule or the following will happen: [ 314.905786] bad: scheduling from the idle thread! Just skipping the wait (and even adding some random wait here) won't help: to make host-side magic working we're supposed to receive CHANNELMSG_UNLOAD (and actually confirm the fact that we received it) but we can't use interrupt-base path (vmbus_isr()-> vmbus_on_msg_dpc()). Implement a simple busy wait ignoring all the other messages and use it if we're in an interrupt context. Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1541585 When we pick a CPU to use for a new subchannel we try find a non-used one on the appropriate NUMA node, we keep track of them with the primary->alloced_cpus_in_node mask. Under normal circumstances we don't run out of available CPUs but it is possible when we we don't initialize some cpus in Linux, e.g. when we boot with 'nr_cpus=' limitation. Avoid the infinite loop in init_vp_index() by checking that we still have non-used CPUs in the alloced_cpus_in_node mask and resetting it in case we don't. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Add vendor and device attributes to VMBUS devices. These will be used by Hyper-V tools as well user-level RDMA libraries that will use the vendor/device tuple to discover the RDMA device. Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1541585 Cleanup vmbus_set_event() by inlining the hypercall to post the event and since the return value of vmbus_set_event() is not checked, make it void. As part of this cleanup, get rid of the function hv_signal_event() as it is only callled from vmbus_set_event(). Signed-off-by:
-
Len Brown authored
BugLink: http://bugs.launchpad.net/bugs/1559918 Some SKL-H configurations require "intel_idle.max_cstate=7" to boot. While that is an effective workaround, it disables C10. This patch detects the problematic configuration, and disables C8 and C9, keeping C10 enabled. Note that enabling SGX in BIOS SETUP can also prevent this issue, if the system BIOS provides that option. https://bugzilla.kernel.org/show_bug.cgi?id=109081 "Freezes with Intel i7 6700HQ (Skylake), unless intel_idle.max_cstate=7" Signed-off-by:
Len Brown <len.brown@intel.com> Cc: stable@vger.kernel.org (cherry picked from commit d70e28f5) Signed-off-by:
-
