talos-obmc-linux/drivers/hv, branch v4.6

Drivers: hv: vmbus: Fix signaling logic in hv_need_to_signal_on_read()

2016-04-30T21:05:44+00:00

On the consumer side, we have interrupt driven flow management of the producer. It is sufficient to base the signaling decision on the amount of space that is available to write after the read is complete. The current code samples the previous available space and uses this in making the signaling decision. This state can be stale and is unnecessary. Since the state can be stale, we end up not signaling the host (when we should) and this can result in a hang. Fix this problem by removing the unnecessary check. I would like to thank Arseney Romanenko for pointing out this issue. Also, issue a full memory barrier before making the signaling descision to correctly deal with potential reordering of the write (read index) followed by the read of pending_sz. Signed-off-by: K. Y. Srinivasan Tested-by: Dexuan Cui Cc: Signed-off-by: Greg Kroah-Hartman

Merge tag 'char-misc-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2016-03-17T20:47:50+00:00

Pull char/misc updates from Greg KH: "Here is the big char/misc driver update for 4.6-rc1. The majority of the patches here is hwtracing and some new mic drivers, but there's a lot of other driver updates as well. Full details in the shortlog. All have been in linux-next for a while with no reported issues" * tag 'char-misc-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (238 commits) goldfish: Fix build error of missing ioremap on UM nvmem: mediatek: Fix later provider initialization nvmem: imx-ocotp: Fix return value of imx_ocotp_read nvmem: Fix dependencies for !HAS_IOMEM archs char: genrtc: replace blacklist with whitelist drivers/hwtracing: make coresight-etm-perf.c explicitly non-modular drivers: char: mem: fix IS_ERROR_VALUE usage char: xillybus: Fix internal data structure initialization pch_phub: return -ENODATA if ROM can't be mapped Drivers: hv: vmbus: Support kexec on ws2012 r2 and above Drivers: hv: vmbus: Support handling messages on multiple CPUs Drivers: hv: utils: Remove util transport handler from list if registration fails Drivers: hv: util: Pass the channel information during the init call Drivers: hv: vmbus: avoid unneeded compiler optimizations in vmbus_wait_for_unload() Drivers: hv: vmbus: remove code duplication in message handling Drivers: hv: vmbus: avoid wait_for_completion() on crash Drivers: hv: vmbus: don't loose HVMSG_TIMER_EXPIRED messages misc: at24: replace memory_accessor with nvmem_device_read eeprom: 93xx46: extend driver to plug into the NVMEM framework eeprom: at25: extend driver to plug into the NVMEM framework ...

Drivers: hv: vmbus: Support kexec on ws2012 r2 and above

2016-03-02T00:57:20+00:00

WS2012 R2 and above hosts can support kexec in that thay can support reconnecting to the host (as would be needed in the kexec path) on any CPU. Enable this. Pre ws2012 r2 hosts don't have this ability and consequently cannot support kexec. Signed-off-by: Alex Ng Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: Support handling messages on multiple CPUs

2016-03-02T00:57:20+00:00

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 Signed-off-by: Greg Kroah-Hartman

Drivers: hv: utils: Remove util transport handler from list if registration fails

2016-03-02T00:57:20+00:00

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 Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: util: Pass the channel information during the init call

2016-03-02T00:57:20+00:00

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 3cace4a61610 ("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: K. Y. Srinivasan Reported-by: Vitaly Kuznetsov Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: avoid unneeded compiler optimizations in vmbus_wait_for_unload()

2016-03-02T00:57:20+00:00

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 Signed-off-by: Vitaly Kuznetsov Reviewed-by: Radim Kr.má Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: remove code duplication in message handling

2016-03-02T00:57:20+00:00

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: Radim Krcmar Signed-off-by: Vitaly Kuznetsov Reviewed-by: Radim Kr.má Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: avoid wait_for_completion() on crash

2016-03-02T00:57:20+00:00

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: Radim Krcmar Signed-off-by: Vitaly Kuznetsov Reviewed-by: Radim Kr.má Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: don't loose HVMSG_TIMER_EXPIRED messages

2016-03-02T00:57:20+00:00

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: Vitaly Kuznetsov Reviewed-by: Radim Kr.má Signed-off-by: K. Y. Srinivasan Signed-off-by: Greg Kroah-Hartman