On attempt to register a dynamic minor misc device its minor number is
updated to a virtual minor number prior to device_create() call,
however on error path misc->minor == MISC_DYNAMIC_MINOR is not
restored.

Following the rule of thumb that a function returning an error must
not change the state of the caller, assign MISC_DYNAMIC_MINOR back.

The problem is met in a sutuation, when subsys_initcall(misc_init) is
not yet called and misc_class is not created, but misc_register()
modifies statically defined ".minor = MISC_DYNAMIC_MINOR", therefore
implicitly changing the client's logic on next attempt (e.g. retrying
from deferred list) to register a misc device, whose minor number is
converted from dynamic to some unknown static one.
Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A previous commit, c93b76b3 ("mei: bus: report also uuid in module
alias") caused a build error as I missed applying a needed patch to add
some macros to uapi/linux/uuid.h.  Instead of those additional macros,
change the mei code to use the existing uuid structure directly.

Fixes: c93b76b3
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch splits CONFIG_I8K compile option to SENSORS_DELL_SMM and CONFIG_I8K.
Option SENSORS_DELL_SMM is now used to enable compilation of dell-smm-hwmon
driver and old CONFIG_I8K option to enable /proc/i8k interface in driver.

So this change allows to compile dell-smm-hwmon driver without legacy /proc/i8k
interface which is needed only for old Dell Inspirion models or for userspace
i8kutils package.

For backward compatibility when CONFIG_I8K is enabled then also SENSORS_DELL_SMM
is enabled and so driver dell-smm-hwmon (with /proc/i8k) is compiled.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit moves i8k driver to hwmon tree under name dell-smm-hwmon which is
better name then abbreviation i8k. For backward compatibility is added macro
MODULE_ALIAS("i8k") so modprobe will load driver also old name i8k. CONFIG_I8K
compile option was not changed.

This commit also adds me as maintainer of this new dell-smm-hwmon driver and
remove Guenter Roeck from list who is implicit maintainer all hwmon drivers.
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

My static checker complains that this sprintf() can overflow but really
it can't.  Just silence the warning by using snprintf().
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If NO_DMA=y:

    drivers/built-in.o: In function `xilly_of_unmap':
    xillybus_of.c:(.text+0xa860e): undefined reference to `dma_unmap_single'
    drivers/built-in.o: In function `xilly_map_single_of':
    xillybus_of.c:(.text+0xa8668): undefined reference to `dma_map_single'
    xillybus_of.c:(.text+0xa8676): undefined reference to `dma_mapping_error'
    xillybus_of.c:(.text+0xa86ca): undefined reference to `dma_unmap_single'
    drivers/built-in.o: In function `xilly_dma_sync_single_for_device_of':
    xillybus_of.c:(.text+0xa8700): undefined reference to `dma_sync_single_for_cpu'
    drivers/built-in.o: In function `xilly_dma_sync_single_for_cpu_of':
    xillybus_of.c:(.text+0xa8726): undefined reference to `dma_sync_single_for_cpu'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NEli Billauer <eli.billauer@gmail.com>
--
v2:
  - Add Acked-by, send to char and misc drivers maintainers.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the close parenthesis.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During bootup pcmcia (pccardd) code enforces the following warning
backtrace:

do not call blocking ops when !TASK_RUNNING; state=1 set at [<c0319e74>] pccardd+0xb8/0x3fc
Modules linked in:
CPU: 0 PID: 14 Comm: pccardd Not tainted 4.0.0-rc6+ #11
Hardware name: Sharp-Collie
[<c0105cd8>] (unwind_backtrace) from [<c0103ef8>] (show_stack+0x10/0x14)
[<c0103ef8>] (show_stack) from [<c010e9b8>] (warn_slowpath_common+0x74/0xac)
[<c010e9b8>] (warn_slowpath_common) from [<c010ea20>] (warn_slowpath_fmt+0x30/0x40)
[<c010ea20>] (warn_slowpath_fmt) from [<c012b1b4>] (__might_sleep+0x84/0xa0)
[<c012b1b4>] (__might_sleep) from [<c040fbb0>] (mutex_lock_nested+0x24/0x388)
[<c040fbb0>] (mutex_lock_nested) from [<c0319eb4>] (pccardd+0xf8/0x3fc)
[<c0319eb4>] (pccardd) from [<c0127370>] (kthread+0xdc/0xfc)
[<c0127370>] (kthread) from [<c01013a8>] (ret_from_fork+0x14/0x2c)
---[ end trace fd94911637eed4ba ]---

This happens due to kthread trying to lock mutex in a TASK_INTERRUPTIBLE
state. Limit TASK_INTERRUPTIBLE task state to the schedule() call only,
so that the rest of the code runs in TASK_RUNNING state.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

[um maintainers appear to be vanished]

I can't prove the case pointed out in
https://bugzilla.kernel.org/show_bug.cgi?id=82341
is correct so let us play safe.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This code is no longer used now that mach-msm has been removed.
Delete it.

Cc: David Brown <davidb@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Primary channels are distributed evenly across all vcpus we have. When the host
asks us to create subchannels it usually makes us num_cpus-1 offers and we are
supposed to distribute the work evenly among the channel itself and all its
subchannels. Make sure they are all assigned to different vcpus.
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 need to call init_vp_index() after we added the channel to the appropriate
list (global or subchannel) to be able to use this information when assigning
the channel to the particular vcpu. To do so we need to move a couple of
functions around. The only real change is the init_vp_index() call. This is a
small refactoring without a functional change.
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>

It is unlikely that that host will ask us to close only one subchannel for a
device but let's be consistent. Do both num_sc++ and num_sc-- with
channel->lock to be on the safe side.
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>

next_oc and num_sc fields of struct vmbus_channel deserve a description. Move
them closer to sc_list as these fields are related to it.
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>

Remove some code duplication, no functional change intended.
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>

Explicitly kill tasklets we create on module unload.
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>

In case there was an error reported in the response to the CHANNELMSG_OPENCHANNEL
call we need to do the cleanup as a vmbus_open() user won't be doing it after
receiving an error. The cleanup should be done on all failure paths. We also need
to avoid returning open_info->response.open_result.status as the return value as
all other errors we return from vmbus_open() are -EXXX and vmbus_open() callers
are not supposed to analyze host error codes.
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>

Implement the protocol for tearing down the monitor state established with
the host.
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Get rid of some unused definitions.
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

free_channel() has been invoked in
vmbus_remove() -> hv_process_channel_removal(), or vmbus_remove() ->
... -> vmbus_close_internal() -> hv_process_channel_removal().

We also change to use list_for_each_entry_safe(), because the entry
is removed in hv_process_channel_removal().

This patch fixes a bug in the vmbus unload path.

Thank Dan Carpenter for finding the issue!
Signed-off-by: NDexuan Cui <decui@microsoft.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 96c1d058 ("Drivers: hv: vmbus: Add
support for VMBus panic notifier handler") introduced
atomic_notifier_chain_register() call on module load. We also need to call
atomic_notifier_chain_unregister() on module unload as otherwise the following
crash is observed when we bring hv_vmbus back:

[   39.788877] BUG: unable to handle kernel paging request at ffffffffa00078a8
[   39.788877] IP: [<ffffffff8109d63f>] notifier_call_chain+0x3f/0x80
...
[   39.788877] Call Trace:
[   39.788877]  [<ffffffff8109de7d>] __atomic_notifier_call_chain+0x5d/0x90
...
[   39.788877]  [<ffffffff8109d788>] ? atomic_notifier_chain_register+0x38/0x70
[   39.788877]  [<ffffffff8109d767>] ? atomic_notifier_chain_register+0x17/0x70
[   39.788877]  [<ffffffffa002814f>] hv_acpi_init+0x14f/0x1000 [hv_vmbus]
[   39.788877]  [<ffffffff81002144>] do_one_initcall+0xd4/0x210
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>

In case we do request_resource() in vmbus_acpi_add() we need to tear it down
to be able to load the driver again. Otherwise the following crash in observed
when hv_vmbus unload/load sequence is performed on a Generation2 instance:

[   38.165701] BUG: unable to handle kernel paging request at ffffffffa00075a0
[   38.166315] IP: [<ffffffff8107dc5f>] __request_resource+0x2f/0x50
[   38.166315] PGD 1f34067 PUD 1f35063 PMD 3f723067 PTE 0
[   38.166315] Oops: 0000 [#1] SMP
[   38.166315] Modules linked in: hv_vmbus(+) [last unloaded: hv_vmbus]
[   38.166315] CPU: 0 PID: 267 Comm: modprobe Not tainted 3.19.0-rc5_bug923184+ #486
[   38.166315] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
[   38.166315] task: ffff88003f401cb0 ti: ffff88003f60c000 task.ti: ffff88003f60c000
[   38.166315] RIP: 0010:[<ffffffff8107dc5f>]  [<ffffffff8107dc5f>] __request_resource+0x2f/0x50
[   38.166315] RSP: 0018:ffff88003f60fb58  EFLAGS: 00010286
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>

Unify driver registration reporting and move it to debug level as normally daemons write to syslog themselves
and these kernel messages are useless.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce FCOPY_VERSION_1 to support kernel replying to the negotiation
message with its own version.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce VSS_OP_REGISTER1 to support kernel replying to the negotiation
message with its own version.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use /dev/vmbus/hv_vss instead of netlink.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use /dev/vmbus/hv_kvp instead of netlink.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert to hv_utils_transport to support both netlink and /dev/vmbus/hv_kvp communication methods.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unify the code with the recently introduced hv_utils_transport. Netlink
communication is disabled for fcopy.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert to hv_utils_transport to support both netlink and /dev/vmbus/hv_vss communication methods.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The intention is to make KVP/VSS drivers work through misc char devices.
Introduce an abstraction for kernel/userspace communication to make the
migration smoother. Transport operational mode (netlink or char device)
is determined by the first received message. To support driver upgrades
the switch from netlink to chardev operational mode is supported.

Every hv_util daemon is supposed to register 2 callbacks:
1) on_msg() to get notified when the userspace daemon sent a message;
2) on_reset() to get notified when the userspace daemon drops the connection.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Get an additional reference otherwise a crash is observed when hv_utils module is being unloaded while
fcopy daemon is still running. .owner gives us an additional reference when
someone holds a descriptor for the device.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Switch to using the hvutil_device_state state machine from using 3 different state variables:
fcopy_transaction.active, opened, and in_hand_shake.

State transitions are:
-> HVUTIL_DEVICE_INIT when driver loads or on device release
-> HVUTIL_READY if the handshake was successful
-> HVUTIL_HOSTMSG_RECEIVED when there is a non-negotiation message from the host
-> HVUTIL_USERSPACE_REQ after userspace daemon read the message
   -> HVUTIL_USERSPACE_RECV after/if userspace has replied
-> HVUTIL_READY after we respond to the host
-> HVUTIL_DEVICE_DYING on driver unload

In hv_fcopy_onchannelcallback() process ICMSGTYPE_NEGOTIATE messages even when
the userspace daemon is disconnected, otherwise we can make the host think
we don't support FCOPY and disable the service completely.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Switch to using the hvutil_device_state state machine from using kvp_transaction.active.

State transitions are:
-> HVUTIL_DEVICE_INIT when driver loads or on device release
-> HVUTIL_READY if the handshake was successful
-> HVUTIL_HOSTMSG_RECEIVED when there is a non-negotiation message from the host
-> HVUTIL_USERSPACE_REQ after we sent the message to the userspace daemon
   -> HVUTIL_USERSPACE_RECV after/if the userspace daemon has replied
-> HVUTIL_READY after we respond to the host
-> HVUTIL_DEVICE_DYING on driver unload

In hv_vss_onchannelcallback() process ICMSGTYPE_NEGOTIATE messages even when
the userspace daemon is disconnected, otherwise we can make the host think
we don't support VSS and disable the service completely.

Unfortunately there is no good way we can figure out that the userspace daemon
has died (unless we start treating all timeouts as such), add a protection
against processing new VSS_OP_REGISTER messages while being in the middle of a
transaction (HVUTIL_USERSPACE_REQ or HVUTIL_USERSPACE_RECV state).
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Switch to using the hvutil_device_state state machine from using 2 different state variables: kvp_transaction.active and
in_hand_shake.

State transitions are:
-> HVUTIL_DEVICE_INIT when driver loads or on device release
-> HVUTIL_READY if the handshake was successful
-> HVUTIL_HOSTMSG_RECEIVED when there is a non-negotiation message from the host
-> HVUTIL_USERSPACE_REQ after we sent the message to the userspace daemon
   -> HVUTIL_USERSPACE_RECV after/if the userspace daemon has replied
-> HVUTIL_READY after we respond to the host
-> HVUTIL_DEVICE_DYING on driver unload

In hv_kvp_onchannelcallback() process ICMSGTYPE_NEGOTIATE messages even when
the userspace daemon is disconnected, otherwise we can make the host think
we don't support KVP and disable the service completely.

Unfortunately there is no good way we can figure out that the userspace daemon
has died (unless we start treating all timeouts as such). In case the daemon
restarts we skip the negotiation procedure (so the daemon is supposed to has
the same version). This behavior is unchanged from in_handshake approach.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

KVP/VSS/FCOPY drivers work in fully serialized mode: we wait till userspace
daemon registers, wait for a message from the host, send this message to the
daemon, get the reply, send it back to host, wait for another message.
Introduce enum hvutil_device_state to represend this state in all 3 drivers.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

'fcopy_work' (and fcopy_work_func) is a misnomer as it sounds like we expect
this useful work to happen and in reality it is just an emergency escape when
timeout happens.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

'kvp_work' (and kvp_work_func) is a misnomer as it sounds like we expect
this useful work to happen and in reality it is just an emergency escape when
timeout happens.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In theory, the host is not supposed to issue any requests before be reply to
the previous one. In KVP we, however, support the following scenarios:
1) A message was received before userspace daemon registered;
2) A message was received while the previous one is still being processed.
In VSS we support only the former. Add support for the later, use
hv_poll_channel() to do the job.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In theory, the host is not supposed to issue any requests before be reply to
the previous one. In KVP we, however, support the following scenarios:
1) A message was received before userspace daemon registered;
2) A message was received while the previous one is still being processed.
In FCOPY we support only the former. Add support for the later, use
hv_poll_channel() to do the job.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Tested-by: NAlex Ng <alexng@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>