Commit 985087db 'misc: add support for bmp18x chips to the bmp085
driver' changed the BMP085 config symbol to a boolean.  I see no
reason why the shared code cannot be built as a module, so change it
back to tristate.

Fixes: 985087db ("misc: add support for bmp18x chips to the bmp085 driver")
Cc: Eric Andersson <eric.andersson@unixphere.com>
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Kconfig currently controlling compilation of this code is:

drivers/misc/Kconfig:config ARM_CHARLCD
drivers/misc/Kconfig:   bool "ARM Ltd. Character LCD Driver"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and this driver did not have a ".remove"
function coded for non-modular drivers either.

Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

We don't replace module.h with init.h since the file already has that.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Allow the pch_phub driver to be build on MIPS platforms, in preparation
for its use on the MIPS Boston board.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The pr_debug() will never be executed.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NMatthias Lange <matthias.lange@kernkonzept.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of calling release_firmware() on every error and then jumping
lets have a common release_firmware() in the error path.
This patch also fixes a memory leak where we missed release_firmware()
if mic_x100_load_command_line() fails.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Instead of jumping to a label and then returning from there lets return
directly.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If request_firmware() succeeds then rc becomes 0. After that if the test
for strcmp() fails then we were jumping to label done: and returning rc.
But rc being 0 we returned success whereas we have failed here and we
were supposed to return an error.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

>From the error path we are printing an error message with dev_err(). No
need to print almost same message with dev_dbg().
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After the loop we test "if (!retry)" to see if we timedout.  The problem
is "retry--" is a post-op so retry will be -1 at the end of the loop.  I
have fixed this by changing it to a pre-op instead.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes the following crash seen when MIC reset is invoked in
RESET_FAILED state due to device_del being called a second time on an
already deleted device:

[<ffffffff813b2295>] device_del+0x45/0x1d0
[<ffffffff813b243e>] device_unregister+0x1e/0x60
[<ffffffffa040f1c2>] scif_unregister_device+0x12/0x20 [scif_bus]
[<ffffffffa042f75a>] cosm_stop+0xaa/0xe0 [mic_cosm]
[<ffffffffa042f844>] cosm_reset_trigger_work+0x14/0x20 [mic_cosm]

The fix consists in realizing that because cosm_reset changes the
state to MIC_RESETTING, cosm_stop needs the previous state, before it
changed to MIC_RESETTING, to decide whether a hw_ops->stop had
previously been issued. This is now provided in a new cosm_device
member cdev->prev_state.
Reviewed-by: NSudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds Intel(R) Trace Hub PCI ID for Broxton SOC.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds Intel(R) Trace Hub PCI ID for Apollo Lake SOC.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, the character device write method allocates a temporary buffer
for user's data, but the user's data size is not sanitized and can cause
arbitrarily large allocations via kzalloc() or an integer overflow that
will then result in overwriting kernel memory.

This patch trims the input buffer size to avoid these issues.
Reported-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since both sw_start and sw_end are master indices, the size of array
that holds them is sw_end - sw_start + 1, which the current code gets
wrong, allocating one item less than required.

This patch corrects the allocation size, avoiding potential slab
corruption.
Signed-off-by: NChunyan Zhang <zhang.chunyan@linaro.org>
[alexander.shishkin@linux.intel.com: re-wrote the commit message]
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, the list of stm_sources linked to an stm device is protected by
a spinlock, which also means that sources' .unlink() method is called under
this spinlock. However, this method may (and does) sleep, which means
trouble.

This patch slightly reworks locking around stm::link_list so that bits that
might_sleep() are called with a mutex held instead. Modification of this
list requires both mutex and spinlock to be held, while looking at the list
can be done under either mutex or spinlock.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Right now, if stm device removal has to unbind from a policy (that is,
an stm device that has STP policy, gets removed), it will trigger a
nested lock on the stm device's policy mutex.

This patch fixes the problem by moving the locking from the policy
unbinding to policy removal (configfs path), where it's actually needed;
the other caller of the policy unbinding function already takes the
mutex around the call.
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The newly added STM code uses SRCU, but does not ensure that
this code is part of the kernel:

drivers/built-in.o: In function `stm_source_link_show':
include/linux/srcu.h:221: undefined reference to `__srcu_read_lock'
include/linux/srcu.h:238: undefined reference to `__srcu_read_unlock'
drivers/built-in.o: In function `stm_source_link_drop':
include/linux/srcu.h:221: undefined reference to `__srcu_read_lock'
include/linux/srcu.h:238: undefined reference to `__srcu_read_unlock'

This adds a Kconfig 'select' statement like all the other SRCU using
drivers have.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 7bd1d409 ("stm class: Introduce an abstraction for System Trace Module devices")
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If NO_DMA=y:

    ERROR: "dma_free_coherent" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
    ERROR: "dma_alloc_coherent" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined!
    ERROR: "dma_supported" [drivers/hwtracing/intel_th/intel_th.ko] undefined!

Add a dependency on HAS_DMA to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If STM=n, it doesn't make sense to ask about STM_DUMMY and
STM_SOURCE_CONSOLE support, which are not even built when enabled
anyway. Hence hide these options if STM=n.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Other than plainly parsing the device tree there is no way to
know which CPU a tracer is affined to.  As such adding an
interface to lookup the CPU field enclosed in the etm_drvdata
structure that was initialised at boot time.
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The coresight drivers have absolutely no control over bind and unbind
operations triggered from sysfs. The operations simply can't be
cancelled or denied event when one or several tracing sessions are
under way.  Since the memory associated to individual device is
invariably freed, the end result is a kernel crash when the path from
source to sink is travelled again as demonstrated here[1].

One solution could be to keep track of all the path (i.e tracing
session) that get created and iterate through the elements of those path
looking for the coresight device that is being removed.  This proposition
doesn't scale well since there is no upper bound on the amount of
concurrent trace session that can be created.

With the above in mind, this patch prevent devices from being unbounded
from their driver by using the driver->suppress_bind_attr option.  That way
trace sessions can be managed without fearing to loose devices.

Since device can't be removed anymore the xyz_remove() functions found in
each driver is also removed.

[1]. http://www.spinics.net/lists/arm-kernel/msg474952.htmlReported-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In function 'coresight_unregister()', all references to the csdev that
is being taken away need to be removed from the topology.  Otherwise
building the next coresight path from source to sink may use memory
that has been released.
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The reference count taken by function bus_find_device() needs
to be released if a child device is found, something this patch
is adding.
Reported-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In its current form the code never frees csdev->refcnt allocated
in coresight_register().  There is also a problem with csdev->conns
that is freed before device_unregister() rather than in the device
release function.

This patch addresses both issues by moving kfree(csdev->conns) to
coresight_device_release() and freeing csdev->refcnt, also in
the same function.
Reported-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On some platform the following lockdep error occurs when doing simple
manipulations:

    [   23.197021]
    [   23.198608] ======================================================
    [   23.205078] [ INFO: possible circular locking dependency detected ]
    [   23.211639] 4.4.0-rc8-00025-gbbf360b #172 Not tainted
    [   23.216918] -------------------------------------------------------
    [   23.223480] sh/858 is trying to acquire lock:
    [   23.228057]  (coresight_mutex){+.+.+.}, at: [<c0415d40>] coresight_enable+0x1c/0x1b4
    [   23.236206]
    [   23.236206] but task is already holding lock:
    [   23.242309]  (s_active#52){++++.+}, at: [<c01d4b40>] kernfs_fop_write+0x5c/0x1c0
    [   23.250122]
    [   23.250122] which lock already depends on the new lock.
    [   23.250122]
    [   23.258697]
    [   23.258697] the existing dependency chain (in reverse order) is:
    [   23.266510]
    -> #1 (s_active#52){++++.+}:
    [   23.270843]        [<c01d30ec>] __kernfs_remove+0x294/0x35c
    [   23.276672]        [<c01d3e44>] kernfs_remove_by_name_ns+0x44/0x8c
    [   23.283172]        [<c01d6318>] remove_files+0x3c/0x84
    [   23.288543]        [<c01d66b4>] sysfs_remove_group+0x48/0x9c
    [   23.294494]        [<c01d6734>] sysfs_remove_groups+0x2c/0x3c
    [   23.300506]        [<c030b658>] device_remove_attrs+0x5c/0x74
    [   23.306549]        [<c030c290>] device_del+0x110/0x218
    [   23.311950]        [<c030c3c4>] device_unregister+0x2c/0x6c
    [   23.317779]        [<c04156d8>] coresight_unregister+0x30/0x40
    [   23.323883]        [<c041a290>] etm_probe+0x228/0x2e8
    [   23.329193]        [<c02bc760>] amba_probe+0xe4/0x160
    [   23.334503]        [<c0310540>] driver_probe_device+0x23c/0x480
    [   23.340728]        [<c0310820>] __driver_attach+0x9c/0xa0
    [   23.346374]        [<c030e400>] bus_for_each_dev+0x70/0xa4
    [   23.352142]        [<c030fcf4>] driver_attach+0x24/0x28
    [   23.357604]        [<c030f86c>] bus_add_driver+0x1e0/0x278
    [   23.363372]        [<c0310d48>] driver_register+0x80/0x100
    [   23.369110]        [<c02bc508>] amba_driver_register+0x58/0x5c
    [   23.375244]        [<c0749514>] etm_driver_init+0x18/0x1c
    [   23.380889]        [<c0009918>] do_one_initcall+0xc4/0x20c
    [   23.386657]        [<c0715e7c>] kernel_init_freeable+0x160/0x208
    [   23.392974]        [<c052d7fc>] kernel_init+0x18/0xf0
    [   23.398254]        [<c0010850>] ret_from_fork+0x14/0x24
    [   23.403747]
    -> #0 (coresight_mutex){+.+.+.}:
    [   23.408447]        [<c008ed60>] lock_acquire+0xe4/0x210
    [   23.413909]        [<c0530a30>] mutex_lock_nested+0x74/0x450
    [   23.419860]        [<c0415d40>] coresight_enable+0x1c/0x1b4
    [   23.425689]        [<c0416030>] enable_source_store+0x58/0x68
    [   23.431732]        [<c030b358>] dev_attr_store+0x20/0x2c
    [   23.437286]        [<c01d55e8>] sysfs_kf_write+0x50/0x54
    [   23.442871]        [<c01d4ba8>] kernfs_fop_write+0xc4/0x1c0
    [   23.448699]        [<c015b60c>] __vfs_write+0x34/0xe4
    [   23.454040]        [<c015bf38>] vfs_write+0x98/0x174
    [   23.459228]        [<c015c7a8>] SyS_write+0x4c/0xa8
    [   23.464355]        [<c00107c0>] ret_fast_syscall+0x0/0x1c
    [   23.470031]
    [   23.470031] other info that might help us debug this:
    [   23.470031]
    [   23.478393]  Possible unsafe locking scenario:
    [   23.478393]
    [   23.484619]        CPU0                    CPU1
    [   23.489349]        ----                    ----
    [   23.494079]   lock(s_active#52);
    [   23.497497]                                lock(coresight_mutex);
    [   23.503906]                                lock(s_active#52);
    [   23.509918]   lock(coresight_mutex);
    [   23.513702]
    [   23.513702]  *** DEADLOCK ***
    [   23.513702]
    [   23.519897] 3 locks held by sh/858:
    [   23.523529]  #0:  (sb_writers#7){.+.+.+}, at: [<c015ec38>] __sb_start_write+0xa8/0xd4
    [   23.531799]  #1:  (&of->mutex){+.+...}, at: [<c01d4b38>] kernfs_fop_write+0x54/0x1c0
    [   23.539916]  #2:  (s_active#52){++++.+}, at: [<c01d4b40>] kernfs_fop_write+0x5c/0x1c0
    [   23.548156]
    [   23.548156] stack backtrace:
    [   23.552734] CPU: 0 PID: 858 Comm: sh Not tainted 4.4.0-rc8-00025-gbbf360b #172
    [   23.560302] Hardware name: Generic OMAP4 (Flattened Device Tree)
    [   23.566589] Backtrace:
    [   23.569152] [<c00154d4>] (dump_backtrace) from [<c00156d0>] (show_stack+0x18/0x1c)
    [   23.577087]  r7:ed4b8570 r6:c0936400 r5:c07ae71c r4:00000000
    [   23.583038] [<c00156b8>] (show_stack) from [<c027e69c>] (dump_stack+0x98/0xc0)
    [   23.590606] [<c027e604>] (dump_stack) from [<c008a750>] (print_circular_bug+0x21c/0x33c)
    [   23.599090]  r5:c0939d60 r4:c0936400
    [   23.602874] [<c008a534>] (print_circular_bug) from [<c008e370>] (__lock_acquire+0x1c98/0x1d88)
    [   23.611877]  r10:00000003 r9:c0fd7a5c r8:ed4b8550 r7:ed4b8570 r6:ed4b8000 r5:c0ff69e4
    [   23.620117]  r4:c0936400 r3:ed4b8550
    [   23.623901] [<c008c6d8>] (__lock_acquire) from [<c008ed60>] (lock_acquire+0xe4/0x210)
    [   23.632080]  r10:00000000 r9:00000000 r8:60000013 r7:c07cb7b4 r6:00000001 r5:00000000
    [   23.640350]  r4:00000000
    [   23.643005] [<c008ec7c>] (lock_acquire) from [<c0530a30>] (mutex_lock_nested+0x74/0x450)
    [   23.651458]  r10:ecc0bf80 r9:edbe7dcc r8:ed4b8000 r7:c0fd7a5c r6:c0415d40 r5:00000000
    [   23.659729]  r4:c07cb780
    [   23.662384] [<c05309bc>] (mutex_lock_nested) from [<c0415d40>] (coresight_enable+0x1c/0x1b4)
    [   23.671234]  r10:ecc0bf80 r9:edbe7dcc r8:ed733c00 r7:00000000 r6:ed733c00 r5:00000002
    [   23.679473]  r4:ed762140
    [   23.682128] [<c0415d24>] (coresight_enable) from [<c0416030>] (enable_source_store+0x58/0x68)
    [   23.691070]  r7:00000000 r6:ed733c00 r5:00000002 r4:ed762160
    [   23.697052] [<c0415fd8>] (enable_source_store) from [<c030b358>] (dev_attr_store+0x20/0x2c)
    [   23.705780]  r5:edbe7dc0 r4:c0415fd8
    [   23.709533] [<c030b338>] (dev_attr_store) from [<c01d55e8>] (sysfs_kf_write+0x50/0x54)
    [   23.717834]  r5:edbe7dc0 r4:c030b338
    [   23.721618] [<c01d5598>] (sysfs_kf_write) from [<c01d4ba8>] (kernfs_fop_write+0xc4/0x1c0)
    [   23.730163]  r7:00000000 r6:00000000 r5:00000002 r4:edbe7dc0
    [   23.736145] [<c01d4ae4>] (kernfs_fop_write) from [<c015b60c>] (__vfs_write+0x34/0xe4)
    [   23.744323]  r10:00000000 r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:00000002 r5:c01d4ae4
    [   23.752593]  r4:ee385a40
    [   23.755249] [<c015b5d8>] (__vfs_write) from [<c015bf38>] (vfs_write+0x98/0x174)
    [   23.762908]  r9:ecc0a000 r8:c0010964 r7:ecc0bf80 r6:000ab0d8 r5:00000002 r4:ee385a40
    [   23.771057] [<c015bea0>] (vfs_write) from [<c015c7a8>] (SyS_write+0x4c/0xa8)
    [   23.778442]  r8:c0010964 r7:00000002 r6:000ab0d8 r5:ee385a40 r4:ee385a40
    [   23.785522] [<c015c75c>] (SyS_write) from [<c00107c0>] (ret_fast_syscall+0x0/0x1c)
    [   23.793457]  r7:00000004 r6:00000001 r5:000ab0d8 r4:00000002
    [   23.799652] coresight-etb10 54162000.etb: ETB enabled
    [   23.805084] coresight-funnel 54164000.funnel: FUNNEL inport 0 enabled
    [   23.811859] coresight-replicator 44000000.ocp:replicator: REPLICATOR enabled
    [   23.819335] coresight-funnel 54158000.funnel: FUNNEL inport 0 enabled
    [   23.826110] coresight-etm3x 5414c000.ptm: ETM tracing enabled

The locking in coresight_unregister() is not required as the only customers of
the function are drivers themselves when an initialisation failure has been
encoutered.
Reported-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This change restricts the reading and setting of the head and tail
pointers on 32bit X86 to 32bit for both correctness and
performance reasons. On uniprocessor X86_32, the atomic64_read
may be implemented as a non-locked cmpxchg8b. This may result in
updates to the pointers done by the VMCI device being overwritten.
On MP systems, there is no such correctness issue, but using 32bit
atomics avoids the overhead of the locked 64bit operation. All this
is safe because the queue size on 32bit systems will never exceed
a 32bit value.
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NJorgen Hansen <jhansen@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The hvsock driver needs this API to release all the resources related
to the channel.
Signed-off-by: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This will be used by the coming hv_sock driver.
Signed-off-by: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A helper function is also added.
Signed-off-by: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This will be used by the coming net/hvsock driver.
Signed-off-by: NDexuan Cui <decui@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>