04 Jan, 2016
2 commits
-
Trailing white space is not accepted in kernel coding style. Remove
them.Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman -
s/regsiter/register/
Signed-off-by: Geliang Tang
Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
27 Dec, 2015
1 commit
-
…/chanwoo/extcon into char-misc-next
Chanwoo writes:
Update extcon for 4.5
Detailed description for patchset:
1. Add new MAX3355 extcon driver
- Maxim Integrated MAX3355E chip integrates a charge pump
and comparator to enable a system with an integrated
USB OTG dual-role transceiver to function as an USB OTG
dual-role device.2. Update the extcon-arizona driver for jack detection
- Add the device binding for the jack detection and add
the documentation of extcon-arizona.c.3. Fix the minor issue of extcon driver
- Add IRQF_ONESHOT to interrupt flags of extcon-rt8973.
- Fix the return value regmap_irq_get_virq() of
extcon-max(14577|77693|77843).c driver by using script[1].
[1] http://permalink.gmane.org/gmane.linux.kernel/2046107
22 Dec, 2015
5 commits
-
Signed-off-by: Andrew F. Davis
Signed-off-by: Mathieu Poirier
Signed-off-by: Greg Kroah-Hartman -
Connection child names associated to ports can sometimes be NULL,
which is the case when booting a system on QEMU or when the Coresight
power domain isn't switched on.This patch is adding a check to make sure a NULL string isn't fed
to strcmp(), something that avoid crashing the system.Cc: # v3.18+
Reported-by: Tyler Baker
Signed-off-by: Mathieu Poirier
Signed-off-by: Greg Kroah-Hartman -
For performance critical devices, we distribute the incoming
channel interrupt load across available CPUs in the guest.
Include Fibre channel devices in the set of devices for which
we would distribute the interrupt load.Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
The return type of hvt_op_poll() is unsigned int and -EBADF is
inappropriate, poll functions return POLL* statuses.Reported-by: Dexuan Cui
Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
With the recent change af3ff643ea91ba64dd8d0b1cbed54d44512f96cd
(Drivers: hv: vmbus: Use uuid_le type consistently), we always get this
warning:CC [M] drivers/input/serio/hyperv-keyboard.o
drivers/input/serio/hyperv-keyboard.c:427:2: warning: missing braces around
initializer [-Wmissing-braces]
{ HV_KBD_GUID, },
^
drivers/input/serio/hyperv-keyboard.c:427:2: warning: (near initialization
for .id_table[0].guid.b.) [-Wmissing-braces]The patch fixes the warning.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
21 Dec, 2015
1 commit
-
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.Signed-off-by: Sergei Shtylyov
Acked-by: Chanwoo Choi
Acked-by: Rob Herring
[cw00.choi: Add the GPIOLIB dependency]
Signed-off-by: Chanwoo Choi
15 Dec, 2015
31 commits
-
Currently, there is only one user for hv_ringbuffer_read()/
hv_ringbuffer_peak() functions and the usage of these functions is:
- insecure as we drop ring_lock between them, someone else (in theory
only) can acquire it in between;
- non-optimal as we do a number of things (acquire/release the above
mentioned lock, calculate available space on the ring, ...) twice and
this path is performance-critical.Remove hv_ringbuffer_peek() moving the logic from __vmbus_recvpacket() to
hv_ringbuffer_read().Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
vmbus_recvpacket() and vmbus_recvpacket_raw() are almost identical but
there are two discrepancies:
1) vmbus_recvpacket() doesn't propagate errors from hv_ringbuffer_read()
which looks like it is not desired.
2) There is an error message printed in packetlen > bufferlen case in
vmbus_recvpacket(). I'm removing it as it is usless for users to see
such messages and /vmbus_recvpacket_raw() doesn't have it.Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
hv_ringbuffer_peek() does the same as hv_ringbuffer_read() without
advancing the read index. The only functional change this patch brings
is moving hv_need_to_signal_on_read() call under the ring_lock but this
function is just a couple of comparisons.Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
smp_read_barrier_depends() does nothing on almost all arcitectures
including x86 and having it in the beginning of
hv_get_ringbuffer_availbytes() does not provide any guarantees anyway.Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Convert 6+-string comments repeating function names to normal kernel-style
comments and fix a couple of other comment style issues. No textual or
functional changes intended.Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
The crash is observed when a service is being disabled host side while
userspace daemon is connected to the device:[ 90.244859] general protection fault: 0000 [#1] SMP
...
[ 90.800082] Call Trace:
[ 90.800082] [] __fput+0xc8/0x1f0
[ 90.800082] [] ____fput+0xe/0x10
...
[ 90.800082] [] do_signal+0x28/0x580
[ 90.800082] [] ? finish_task_switch+0xa6/0x180
[ 90.800082] [] ? __schedule+0x28f/0x870
[ 90.800082] [] ? hvt_op_read+0x12a/0x140 [hv_utils]
...The problem is that hvutil_transport_destroy() which does misc_deregister()
freeing the appropriate device is reachable by two paths: module unload
and from util_remove(). While module unload path is protected by .owner in
struct file_operations util_remove() path is not. Freeing the device while
someone holds an open fd for it is a show stopper.In general, it is not possible to revoke an fd from all users so the only
way to solve the issue is to defer freeing the hvutil_transport structure.Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
When Hyper-V host asks us to remove some util driver by closing the
appropriate channel there is no easy way to force the current file
descriptor holder to hang up but we can start to respond -EBADF to all
operations asking it to exit gracefully.As we're setting hvt->mode from two separate contexts now we need to use
a proper locking.Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
As a preparation to reusing outmsg_lock to protect test-and-set openrations
on 'mode' rename it the more general 'lock'.Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
inmsg should be freed in case of on_msg() failure to avoid memory leak.
Preserve the error code from on_msg().Signed-off-by: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Fix the write()'s argument in the daemon code.
Cc: Vitaly Kuznetsov
Cc: "K. Y. Srinivasan"
Signed-off-by: Dexuan Cui
Cc: stable@vger.kernel.org
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
When the handshake with daemon is complete, we should poll the channel since
during the handshake, we will not be processing any messages. This is a
potential bug if the host is waiting for a response from the guest.
I would like to thank Dexuan for pointing this out.Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Force all channel messages to be delivered on CPU0. These messages are not
performance critical and are used during the setup and teardown of the
channel.Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Hypervisor Top Level Functional Specification v3/4 says
that TSC page sequence value = -1(0xFFFFFFFF) is used to
indicate that TSC page no longer reliable source of reference
timer. Unfortunately, we found that Windows Hyper-V guest
side implementation uses sequence value = 0 to indicate
that Tsc page no longer valid. This is clearly visible
inside Windows 2012R2 ntoskrnl.exe HvlGetReferenceTime()
function dissassembly:HvlGetReferenceTime proc near
xchg ax, ax
loc_1401C3132:
mov rax, cs:HvlpReferenceTscPage
mov r9d, [rax]
test r9d, r9d
jz short loc_1401C3176
rdtsc
mov rcx, cs:HvlpReferenceTscPage
shl rdx, 20h
or rdx, rax
mov rax, [rcx+8]
mov rcx, cs:HvlpReferenceTscPage
mov r8, [rcx+10h]
mul rdx
mov rax, cs:HvlpReferenceTscPage
add rdx, r8
mov ecx, [rax]
cmp ecx, r9d
jnz short loc_1401C3132
jmp short loc_1401C3184
loc_1401C3176:
mov ecx, 40000020h
rdmsr
shl rdx, 20h
or rdx, rax
loc_1401C3184:
mov rax, rdx
retn
HvlGetReferenceTime endpThis patch aligns Tsc page invalid sequence value with
Windows Hyper-V guest implementation which is more
compatible with both Hyper-V hypervisor and KVM hypervisor.Signed-off-by: Andrey Smetanin
Signed-off-by: Denis V. Lunev
CC: "K. Y. Srinivasan"
CC: Haiyang Zhang
CC: Vitaly KuznetsovSigned-off-by: Denis V. Lunev
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Currently we have two policies for deciding when to signal the host:
One based on the ring buffer state and the other based on what the
VMBUS client driver wants to do. Consider the case when the client
wants to explicitly control when to signal the host. In this case,
if the client were to defer signaling, we will not be able to signal
the host subsequently when the client does want to signal since the
ring buffer state will prevent the signaling. Implement logic to
have only one signaling policy in force for a given channel.Signed-off-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
Tested-by: Haiyang Zhang
Cc: # v4.2+
Signed-off-by: Greg Kroah-Hartman -
This patch makes 16GB GPUs work in Hyper-V VMs, since, for
compatibility reasons, the Hyper-V BIOS lists MMIO ranges in 2GB
chunks in its root bus's _CRS object.Signed-off-by: Jake Oshins
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
spinlock is unnecessary here.
mutex is enough.Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
We want to simplify vmbus_onoffer_rescind() by not invoking
hv_process_channel_removal(NULL, ...).Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
In the path vmbus_onoffer_rescind() -> vmbus_device_unregister() ->
device_unregister() -> ... -> __device_release_driver(), we can see for a
device without a driver loaded: dev->driver is NULL, so
dev->bus->remove(dev), namely vmbus_remove(), isn't invoked.As a result, vmbus_remove() -> hv_process_channel_removal() isn't invoked
and some cleanups(like sending a CHANNELMSG_RELID_RELEASED message to the
host) aren't done.We can demo the issue this way:
1. rmmod hv_utils;
2. disable the Heartbeat Integration Service in Hyper-V Manager and lsvmbus
shows the device disappears.
3. re-enable the Heartbeat in Hyper-V Manager and modprobe hv_utils, but
lsvmbus shows the device can't appear again.
This is because, the host thinks the VM hasn't released the relid, so can't
re-offer the device to the VM.We can fix the issue by moving hv_process_channel_removal()
from vmbus_close_internal() to vmbus_device_release(), since the latter is
always invoked on device_unregister(), whether or not the dev has a driver
loaded.Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
This fixes an incorrect assumption of channel state in the function.
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
process_chn_event(), running in the tasklet, can race with
vmbus_close_internal() in the case of SMP guest, e.g., when the former is
accessing channel->inbound.ring_buffer, the latter could be freeing the
ring_buffer pages.To resolve the race, we can serialize them by disabling the tasklet when
the latter is running here.Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
The irq we extract from ACPI is not used - we deliver hypervisor
interrupts on a special vector. Make the necessary adjustments.Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
The macro VMBUS_DEVICE() is unused; get rid of it.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Use uuid_le_cmp() for comparing GUIDs.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Consistently use uuid_le type in the Hyper-V driver code.
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
The Backup integration service on WS2012 has appearently trouble to
negotiate with a guest which does not support the provided util version.
Currently the VSS driver supports only version 5/0. A WS2012 offers only
version 1/x and 3/x, and vmbus_prep_negotiate_resp correctly returns an
empty icframe_vercnt/icmsg_vercnt. But the host ignores that and
continues to send ICMSGTYPE_NEGOTIATE messages. The result are weird
errors during boot and general misbehaviour.Check the Windows version to work around the host bug, skip hv_vss_init
on WS2012 and older.Signed-off-by: Olaf Hering
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
This defines the channel type for PCI front-ends in Hyper-V VMs.
Signed-off-by: Jake Oshins
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
This patch exposes the function that hv_vmbus.ko uses to make hypercalls. This
is necessary for retargeting an interrupt when it is given a new affinity.Since we are exporting this API, rename the API as it will be visible outside
the hv.c file.Signed-off-by: Jake Oshins
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
This patch exposes the mapping between Linux CPU number and Hyper-V virtual
processor number. This is necessary because the hypervisor needs to know which
virtual processors to target when making a mapping in the Interrupt Redirection
Table in the I/O MMU.Signed-off-by: Jake Oshins
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Before vmbus_connect() synic is setup per vcpu - this means
hypervisor receives writes at synic msr's and probably allocate
hypervisor resources per synic setup.If vmbus_connect() failed for some reason it's neccessary to cleanup
synic setup by call hv_synic_cleanup() at each vcpu to get a chance
to free allocated resources by hypervisor per synic.This patch does appropriate cleanup in case of vmbus_connect() failure.
Signed-off-by: Andrey Smetanin
Signed-off-by: Denis V. Lunev
Reviewed-by: Vitaly Kuznetsov
CC: "K. Y. Srinivasan"
CC: Haiyang Zhang
CC: Vitaly Kuznetsov
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Use memdup_user to handle OOM.
Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport abstraction')
Signed-off-by: Olaf Hering
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman -
Catch allocation errors in hvutil_transport_send.
Fixes: 14b50f80c32d ('Drivers: hv: util: introduce hv_utils_transport abstraction')
Signed-off-by: Olaf Hering
Signed-off-by: K. Y. Srinivasan
Signed-off-by: Greg Kroah-Hartman
