In a previous commit, 7a09876d, ASSERT was changed to WARN_ON, but
the condition wasn't updated. This patch fixed this error.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
These fields have been assigned in netvsc_drv_init() before calling
netvsc_initialize(), so there is no need to check them.
The ASSERTs were already commented out, and this patch removes
them.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The OSD layer was a wrapper around native interfaces
adding little value and was infact buggy -
refer to the osd_wait.patch for details.
This patch gets rid of the OSD abstraction.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In preperation for getting rid of the osd layer; change
the code to use native wait interfaces. As part of this,
fixed the buggy implementation in the osd_wait_primitive
where the condition was cleared potentially after the
condition was signalled.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In preperation for getting rid of the osd.[ch] files;
change all page allocation/free functions to use native interfaces.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This was done to resolve conflicts in the following files due
to patches in Linus's tree and in the staging-next tree:
drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The channel callbacks are called directly from vmbus_event_dpc
which runs in tasklet context. These callbacks need to use
GFP_ATOMIC.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16701
Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't do the interface indirection, it's not needed at all.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't do the interface indirection, it's not needed at all.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't do the interface indirection, it's not needed at all.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't do the interface indirection, it's not needed at all.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't do the interface indirection, it's not needed at all.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As it really is a channel, not a "context" name it so.
This also entailed making a few more functions typesafe as they were
sending a struct vmbus_channel pointer as a void pointer.
There are still a few more that need to be converted (the osd callbacks
are one), but this is good for now.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't do the interface indirection, it's not needed at all.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Don't do the interface indirection, it's not needed at all.
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
No need for it, use the built-in kernel function tracing instead
if you really need something like this.
Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We have ftrace to look at function traces if its really
needed. Don't roll custom macros for this.
Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>