summaryrefslogtreecommitdiff
path: root/drivers/hid/intel-ish-hid/ishtp/client.c
AgeCommit message (Collapse)Author
2017-05-30HID: intel_ish-hid: convert timespec to ktime_tArnd Bergmann
The internal accounting uses 'timespec' based time stamps, which is slightly inefficient and also problematic once we get to the time_t overflow in 2038. When communicating to the firmware, we even get an open-coded 64-bit division that prevents the code from being build-tested on 32-bit architectures and is inefficient due to the double conversion from 64-bit nanoseconds to seconds+nanoseconds and then microseconds. This changes the code to use ktime_t instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-05-30HID: intel_ish-hid: clarify locking in client codeArnd Bergmann
I was trying to understand this code while working on a warning fix and the locking made no sense: spin_lock_irqsave() is pointless when run inside of an interrupt handler or nested inside of another spin_lock_irq() or spin_lock_irqsave(). Here it turned out that the comment above the function is wrong, as both recv_ishtp_cl_msg_dma() and recv_ishtp_cl_msg() can in fact be called from a work queue rather than an ISR, so we do have to use the irqsave() version once. This fixes the comments accordingly, removes the misleading 'dev_flags' variable and modifies the inner spinlock to not use 'irqsave'. No functional change is intended, this is just for readability and it slightly simplifies the object code. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2017-05-30HID: intel_ish-hid: fix potential uninitialized data usageArnd Bergmann
gcc points out an uninialized pointer dereference that could happen if we ever get to recv_ishtp_cl_msg_dma() or recv_ishtp_cl_msg() with an empty &dev->read_list: drivers/hid/intel-ish-hid/ishtp/client.c: In function 'recv_ishtp_cl_msg_dma': drivers/hid/intel-ish-hid/ishtp/client.c:1049:3: error: 'cl' may be used uninitialized in this function [-Werror=maybe-uninitialized] The warning only appeared in very few randconfig builds, as the spinlocks tend to prevent gcc from tracing the variables. I only saw it in configurations that had neither SMP nor LOCKDEP enabled. As we can see, we only enter the case if 'complete_rb' is non-NULL, and then 'cl' is known to point to complete_rb->cl. Adding another initialization to the same pointer is harmless here and makes it clear to the compiler that the behavior is well-defined. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2016-08-17HID: intel_ish-hid: ISH Transport layerSrinivas Pandruvada
The ISH transport layer (ishtp) is a bi-directional protocol implemented on the top of PCI based inter processor communication layer. This layer offers: - Connection management - Flow control with the firmware - Multiple client sessions - Client message transfer - Client message reception - DMA for RX and TX for fast data transfer Refer to Documentation/hid/intel-ish-hid.txt for overview of the functionality implemented in this layer. Original-author: Daniel Drubin <daniel.drubin@intel.com> Reviewed-and-tested-by: Ooi, Joyce <joyce.ooi@intel.com> Tested-by: Grant Likely <grant.likely@secretlab.ca> Tested-by: Rann Bar-On <rb6@duke.edu> Tested-by: Atri Bhattacharya <badshah400@aim.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>