- 24 May, 2015 40 commits
-
-
Vitaly Kuznetsov authored
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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
'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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
'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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
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: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
Move poll_channel() to hyperv_vmbus.h and make it inline and rename it to hv_poll_channel() so it can be reused in other hv_util modules. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
We set kvp_context when we want to postpone receiving a packet from vmbus due to the previous transaction being unfinished. We, however, never reset this state, all consequent kvp_respond_to_host() calls will result in poll_channel() calling hv_kvp_onchannelcallback(). This doesn't cause real issues as: 1) Host is supposed to serialize transactions as well 2) If no message is pending vmbus_recvpacket() will return 0 recvlen. This is just a cleanup. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vitaly Kuznetsov authored
These declarations are internal to hv_util module and hv_fcopy_* declarations already reside there. Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Alex Ng <alexng@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Colin Ian King authored
static analysis with smatch picked up the following error: get_platform_data() error: potential null dereference 'dt_pdata'. (kzalloc returns null) Instead, the code should return NULL to avoid the following null pointer deference. Also, remove the error message as it is redundant, the caller emits an error message to alert of a failure anyhow. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Valentin Rothberg authored
Some more recent distributions set the default interpreter to python3, causing the script to break since it's written for python2. Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Valentin Rothberg authored
Sometimes a user might be interested to filter certain reports (e.g., the many defconfigs). Now, this can be achieved by specifying a Python regex with -i / --ignore. Signed-off-by: Valentin Rothberg <valentinrothberg@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
modprobe SCIF driver upon start and remove it upon unload Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
MIC card driver specific changes to enable SCIF. This patch implements the SCIF hardware bus operations and registers a SCIF device on the SCIF hardware bus. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
MIC host driver specific changes to enable SCIF. This patch implements the SCIF hardware bus operations and registers a SCIF device on the SCIF hardware bus. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
SCIF messaging APIs which allow sending messages between the SCIF endpoints via a byte stream based ring buffer which has been optimized to avoid reads across PCIe. The SCIF messaging APIs are typically used for short < 1024 byte messages for best performance while the RDMA APIs which will be submitted in a future patch series is recommended for larger transfers. The node enumeration API enables a user to query for the number of nodes online in the SCIF network and their node ids. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nikhil Rao authored
SCIF connection APIs which establish a SCIF connection between a pair of SCIF endpoints. A SCIF connection consists of a dedicated queue-pair between the endpoints. Client messages are sent over the queue-pair whereas the signaling associated with the message is multiplexed over the node queue-pair. Similarly other control messages such as exposing registered memory are also sent over the node queue-pair. The SCIF endpoints must be in connected state to exchange messages, register memory, map remote memory and trigger DMA transfers. SCIF connections can be set up asynchronously or synchronously. Thanks to Johnnie S Peters for authoring parts of this patch during early bring up of the SCIF driver. Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Nikhil Rao <nikhil.rao@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
SCIF character device file operations and kernel APIs for opening and closing a user and kernel mode SCIF endpoint. This patch also enables binding to a SCIF port and listening for incoming SCIF connections. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
SCIF node queue pair setup creates the SCIF driver kernel mode private node queue pairs between all the nodes to enable internal control message communication once SCIF gets probed by the SCIF hardware bus. Peer to peer communication between MIC Coprocessor nodes is supported. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
SCIF module initialization, DMA mapping, ioremap wrapper APIs and debugfs hooks. SCIF gets probed by the SCIF hardware bus if SCIF devices were registered by base drivers. A MISC device is registered to provide the SCIF character device interface. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
Update mic_bootparam and define the maximum number of DMA channels Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
The SCIF peer bus is used to register and unregister SCIF peer devices internally by the SCIF driver to signify the addition and removal of peer nodes respectively from the SCIF network. This simplifies remote node handling within SCIF and will also be used to support device probe/remove for SCIF client drivers (e.g. netdev over SCIF) Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
The SCIF hardware bus abstracts the low level hardware driver details like interrupts and mapping remote memory so that the same SCIF driver can work without any changes with the MIC host or card driver as long as the hardware bus operations are implemented. The SCIF hardware device is registered by the host and card drivers on the SCIF hardware bus resulting in probing the SCIF driver. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
SCIF ring buffer is a single producer, single consumer byte stream ring buffer optimized for avoiding reads across the PCIe bus while adding the required barriers and hardware workarounds for the MIC Coprocessor. The ring buffer is used to implement a receive queue for SCIF driver messaging between two nodes and for byte stream messaging between SCIF endpoints. The existing in-kernel ring buffer was not reused since it has not been designed for our use across the PCIe bus where each node runs an independent OS. Each SCIF node has a receive queue for every other SCIF node, and each connected endpoint has a receive queue for messages from its peer. This pair of receive queues is referred to as a SCIF queue pair. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sudeep Dutt authored
This patch introduces the SCIF documentation in the header file and describes the IOCTL interface for user mode. mic_overview.txt is updated with documentation on SCIF and a new document describing SCIF in more details is available in scif_overview.txt. Reviewed-by: Nikhil Rao <nikhil.rao@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ira Snyder authored
The CARMA project has ended, and the hardware has all been moved into storage. It is unlikely to ever be used again. Remove the drivers so that there is no more maintenance burden from ongoing upstream kernel changes. Signed-off-by: Ira W. Snyder <ira.snyder@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tal Shorer authored
Remove trailing whitespace from several lines in drivers/char/misc.c This was done using scripts/cleanfile Signed-off-by: Tal Shorer <tal.shorer@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matt Campbell authored
This patch provides support for the DS28EA00 digital thermometer. The DS28EA00 provides an additional two pins for implementing a sequence detection algorithm. This feature allows you to determine the physical location of the chip in the 1-wire bus without needing pre-existing knowledge of the bus ordering. Support is provided through the sysfs w1_seq file. The file will contain a single line with an integer value representing the device index in the bus starting at 0. Signed-off-by: Matt Campbell <mattrcampbell@gmail.com> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Fries authored
A temperature conversion can take 750 ms and when possible the w1_therm slave driver drops the bus_mutex to allow other bus operations, but that includes operations such as a periodic slave search, which can remove this slave when it is no longer detected. If that happens the sl->family_data will be freed and set to NULL causing w1_slave_show to crash when it wakes up. Signed-off-by: David Fries <David@Fries.net> Reported-By: Thorsten Bschorr <thorsten@bschorr.de> Tested-by: Thorsten Bschorr <thorsten@bschorr.de> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dmitry Khromov authored
Some of 1-Wire devices commonly associated with physical access control systems are attached/generate presence for as short as 100 ms - hence the tens-to-hundreds milliseconds scan intervals are required. Signed-off-by: Dmitry Khromov <dk@icelogic.net> Acked-by: Evgeniy Polyakov <zbr@ioremap.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Krzysztof Kolasa authored
Sometimes, on x86_64, decompression fails with the following error: Decompressing Linux... Decoding failed -- System halted This condition is not needed for a 64bit kernel(from commit d5e7cafd): if( ... || (op + COPYLENGTH) > oend) goto _output_error macro LZ4_SECURE_COPY() tests op and does not copy any data when op exceeds the value. added by analogy to lz4_uncompress_unknownoutputsize(...) Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Tested-by: Alexander Kuleshov <kuleshovmail@gmail.com> Tested-by: Caleb Jorden <cjorden@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Richard Weinberger authored
Not all architectures have io memory. Fixes: drivers/built-in.o: In function `spmi_pmic_arb_probe': spmi-pmic-arb.c:(.text+0x1ed399): undefined reference to `devm_ioremap_resource' Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Hemminger authored
UIO base driver should only free_irq that it has requested. UIO supports drivers without interrupts (irq == 0) or custom handlers. This fixes warnings like: WARNING: CPU: 1 PID: 5478 at kernel/irq/manage.c:1244 __free_irq+0xa9/0x1e0() Trying to free already-free IRQ 0 Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomas Winkler authored
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomas Winkler authored
Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomas Winkler authored
1. mei_nfc_hci_hdr and mei_nfc_hdr are just the same thing so drop one 2. use mei_nfc_hdr structure as the member of the command and the reply instead of replicating all header fields. 3. dump the header for easier debugging Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Tomas Winkler authored
since we move all nfc hanling to the mei_phy module we can kill mei_cl_ops Cc: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-