Re: [PATCH] staging: ft1000: fix braces warning

2015-02-03 Thread Joe Perches
On Tue, 2015-02-03 at 19:58 +0100, Bilel DRIRA wrote:
 This patch fix the checkpatch.pl WARNING:
[]
 diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
 b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
[]
 @@ -1963,11 +1948,10 @@ static irqreturn_t ft1000_interrupt(int irq, void 
 *dev_id)
   ft1000_read_reg(dev,
   
 FT1000_REG_MAG_DFSR);
   }
 - if (tempword  0x1f) {
 + if (tempword  0x1f)
   ft1000_copy_up_pkt(dev);
 - } else {
 + else
   break;
 - }
   cnt++;
   } while (cnt  MAX_RCV_LOOP);
  

trivia: the logic here is generally better inverted:

if (!(tempword  0x1f))
break;
ft1000_copy_up_pkt(dev);
cnt++;
} while (cnt  etc...)


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH 3/4] Drivers: hv: vmbus: protect vmbus_get_outgoing_channel() against channel removal

2015-02-03 Thread Dexuan Cui
 -Original Message-
 From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
 Sent: Wednesday, February 4, 2015 1:01 AM
 To: KY Srinivasan; de...@linuxdriverproject.org
 Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason Wang
 Subject: [PATCH 3/4] Drivers: hv: vmbus: protect vmbus_get_outgoing_channel()
 against channel removal
 
 list_for_each_safe() we have in vmbus_get_outgoing_channel() works, however,
 we
 are not protected against the channel being removed (e.g. after receiving
 rescind
 offer). Users of this function (storvsc_do_io() is the only one at this 
 moment)
 can get a link to an already freed channel. Make vmbus_get_outgoing_channel()
 search holding primary-lock as child channels are not being freed unless 
 they're
 removed from parent's list.
 
 Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
 ---
  drivers/hv/channel_mgmt.c  | 10 +++---
  drivers/scsi/storvsc_drv.c |  2 ++
  2 files changed, 9 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
 index fdccd16..af6243c 100644
 --- a/drivers/hv/channel_mgmt.c
 +++ b/drivers/hv/channel_mgmt.c
 @@ -881,18 +881,20 @@ cleanup:
   */
  struct vmbus_channel *vmbus_get_outgoing_channel(struct vmbus_channel
 *primary)
  {
 - struct list_head *cur, *tmp;
 + struct list_head *cur;
   int cur_cpu;
   struct vmbus_channel *cur_channel;
   struct vmbus_channel *outgoing_channel = primary;
   int cpu_distance, new_cpu_distance;
 + unsigned long flags;
 
   if (list_empty(primary-sc_list))
 - return outgoing_channel;
 + return vmbus_get_channel(outgoing_channel);
 
   cur_cpu = hv_context.vp_index[get_cpu()];
   put_cpu();
 - list_for_each_safe(cur, tmp, primary-sc_list) {
 + spin_lock_irqsave(primary-lock, flags);
hmm, we should avoid the locking here because it's a performance killer...
How about adding vmbus_get/put_channel() in vmbus_open/close()?

Thanks,
-- Dexuan

 + list_for_each(cur, primary-sc_list) {
   cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
   if (cur_channel-state != CHANNEL_OPENED_STATE)
   continue;
 @@ -913,6 +915,8 @@ struct vmbus_channel
 *vmbus_get_outgoing_channel(struct vmbus_channel *primary)
 
   outgoing_channel = cur_channel;
   }
 + outgoing_channel = vmbus_get_channel(outgoing_channel);
 + spin_unlock_irqrestore(primary-lock, flags);
 
   return outgoing_channel;
  }
 diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
 index 4cff0dd..3b9b851 100644
 --- a/drivers/scsi/storvsc_drv.c
 +++ b/drivers/scsi/storvsc_drv.c
 @@ -1370,6 +1370,8 @@ static int storvsc_do_io(struct hv_device *device,
 
 VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
   }
 
 + vmbus_put_channel(outgoing_channel);
 +
   if (ret != 0)
   return ret;
 
 --
 1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH 2/4] Drivers: hv: vmbus: do not lose rescind offer on failure in vmbus_process_offer()

2015-02-03 Thread Dexuan Cui
 -Original Message-
 From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
 Sent: Wednesday, February 4, 2015 1:01 AM
 To: KY Srinivasan; de...@linuxdriverproject.org
 Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason Wang
 Subject: [PATCH 2/4] Drivers: hv: vmbus: do not lose rescind offer on failure 
 in
 vmbus_process_offer()
 
 In case we hit a failure condition in vmbus_process_offer() and a rescind 
 offer
 was pending for the channel we just do free_channel() so
 CHANNELMSG_RELID_RELEASED
 will never be send to the host. We have to follow 
 vmbus_process_rescind_offer()
 path anyway.
 
 To support the change we need to protect list_del in
 vmbus_process_rescind_offer()
 hitting an uninitialized list.
 
 Reported-by: Dexuan Cui de...@microsoft.com
 Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
 ---
  drivers/hv/channel_mgmt.c | 20 ++--
  1 file changed, 18 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
 index eb9ce94..fdccd16 100644
 --- a/drivers/hv/channel_mgmt.c
 +++ b/drivers/hv/channel_mgmt.c
 @@ -152,6 +152,7 @@ static struct vmbus_channel *alloc_channel(void)
   spin_lock_init(channel-inbound_lock);
   spin_lock_init(channel-lock);
 
 + INIT_LIST_HEAD(channel-listentry);
   INIT_LIST_HEAD(channel-sc_list);
   INIT_LIST_HEAD(channel-percpu_list);
 
 @@ -308,6 +309,7 @@ static void vmbus_process_offer(struct work_struct
 *work)
   struct vmbus_channel *channel;
   bool fnew = true;
   bool enq = false;
 + bool failure = false;
   int ret;
   unsigned long flags;
 
 @@ -408,19 +410,33 @@ static void vmbus_process_offer(struct work_struct
 *work)
   spin_lock_irqsave(vmbus_connection.channel_lock, flags);
   list_del(newchannel-listentry);
   spin_unlock_irqrestore(vmbus_connection.channel_lock,
 flags);
 + /*
 +  * Init listentry again as vmbus_process_rescind_offer can try
 +  * doing list_del again.
 +  */
 + INIT_LIST_HEAD(channel-listentry);
   kfree(newchannel-device_obj);
 + newchannel-device_obj = NULL;
   goto err_free_chan;
   }
 + goto done_init_rescind;
 +err_free_chan:
 + failure = true;
  done_init_rescind:
 + /*
 +  * Get additional reference as vmbus_put_channel() can be called
 +  * either directly or through vmbus_process_rescind_offer().
 +  */
 + vmbus_get_channel(newchannel);
   spin_lock_irqsave(newchannel-lock, flags);
here we get the lock.

   /* The next possible work is rescind handling */
   INIT_WORK(newchannel-work, vmbus_process_rescind_offer);
   /* Check if rescind offer was already received */
   if (newchannel-rescind)
   queue_work(newchannel-controlwq, newchannel-work);
 + else if (failure)
 + vmbus_put_channel(newchannel);
Here in vmbus_put_channel(), we try to get the same spinlock -- dead lock.

-- Dexuan

   spin_unlock_irqrestore(newchannel-lock, flags);
 - return;
 -err_free_chan:
   vmbus_put_channel(newchannel);
  }
 
 --
 1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH 4/4] hyperv: netvsc: improve protection against rescind offer

2015-02-03 Thread Dexuan Cui
 -Original Message-
 From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
 Sent: Wednesday, February 4, 2015 1:01 AM
 To: KY Srinivasan; de...@linuxdriverproject.org
 Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason Wang
 Subject: [PATCH 4/4] hyperv: netvsc: improve protection against rescind offer
 
 The check added in commit c3582a2c4d0b (hyperv: Add support for vNIC hot
 removal) is incomplete as there is no synchronization between
 vmbus_onoffer_rescind() and netvsc_send(). In case we get the offer after we
 checked out_channel-rescind and before netvsc_send() finishes its job we can
 get a crash as we'll be dealing with already freed channel.
 
 Make netvsc_send() take additional reference to the channel with newly
 introduced vmbus_get_channel(), this guarantees we won't lose the channel.
 We
 can still get rescind while we're processing but this won't cause a crash.
 
 Reported-by: Jason Wang jasow...@redhat.com
 Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
 ---
  drivers/net/hyperv/netvsc.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
 index 9f49c01..d9b13a1 100644
 --- a/drivers/net/hyperv/netvsc.c
 +++ b/drivers/net/hyperv/netvsc.c
 @@ -763,11 +763,16 @@ int netvsc_send(struct hv_device *device,
   out_channel = net_device-chn_table[packet-q_idx];
   if (out_channel == NULL)
   out_channel = device-channel;
 - packet-channel = out_channel;
 + packet-channel = vmbus_get_channel(out_channel);
 
 - if (out_channel-rescind)
 + if (!packet-channel)
   return -ENODEV;
 
 + if (out_channel-rescind) {
 + vmbus_put_channel(out_channel);

IMO the patch doesn't resolve the real issue.
At most it prevents the channel from disappearing in netvsc_send() only,
while actually we also need to make sure the channel is not freed before the
driver runs netvsc_remove() - rndis_filter_device_remove() - 
- netvsc_device_remove() - vmbus_close().

I suggest we add vmbus_get/put_channel() in vmbus_open/close()?

-- Dexuan

 + return -ENODEV;
 + }
 +
   if (packet-page_buf_cnt) {
   ret = vmbus_sendpacket_pagebuffer(out_channel,
 packet-page_buf,
 @@ -810,6 +815,7 @@ int netvsc_send(struct hv_device *device,
  packet, ret);
   }
 
 + vmbus_put_channel(packet-channel);
   return ret;
  }
 
 --

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()

2015-02-03 Thread Jason Wang



On Tue, Feb 3, 2015 at 11:46 PM, Haiyang Zhang haiya...@microsoft.com 
wrote:




 -Original Message-
 From: Jason Wang [mailto:jasow...@redhat.com]
 Sent: Monday, February 2, 2015 1:49 AM
   btw, I find during netvsc_start_xmit(), ret was change to 
-ENOSPC

  when
   queue_sends[q_idx]  1. But non of the caller check -ENOSPC in 
fact?

 
  In this case, we don't request re-send, so set ret to a value 
other

  than
  -EAGAIN.
 
 Why not? We have available slots for it to be sent now. Dropping the

 packet in this case may cause out of order sending.


The EAGAIN error doesn't normally happen, because we set the hi water 
mark

to stop send queue.


This is not true since only txq was stopped which means only network 
stack stop sending packets but not for control path e.g 
rndis_filter_send_request() or other callers who call 
vmbus_sendpacket() directly (e.g recv completion). 

For control path, user may meet several errors when they want to change 
mac address under heavy load. 

What's more serious is netvsc_send_recv_completion(), it can not even 
recover from more than 3 times of EAGAIN.


I must say mixing data packets with control packets with the same 
channel sounds really scary. Since control packets could be blocked or 
even dropped because of data packets already queued during heavy load, 
and you need to synchronize two paths carefully (e.g I didn't see any 
tx lock were held if rndis_filter_send_request() call netsc_send() 
which may stop or start a queue).



 If in really rare case, the ring buffer is full and there
is no outstanding sends, we can't stop queue here because there will 
be no
send-completion msg to wake it up. 


Confused, I believe only txq is stopped but we may still get completion 
interrupt in this case.


And, the ring buffer is likely to be 
occupied by other special msg, e.g. receive-completion msg (not a 
normal case),
so we can't assume there are available slots. 


Then why not checking hv_ringbuf_avail_percent() instead? And there's 
no need to check queue_sends since it does not count recv completion.



We don't request retry from
the upper layer in this case to avoid possible busy retry.


Can't we just do this by stopping txq and depending on tx interrupt to 
wake it?


Thanks

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723au: multiple condition with no effect - if identical to else

2015-02-03 Thread Jes Sorensen
Nicholas Mc Guire hof...@osadl.org writes:
 A number if/else if/else branches are identical - so the condition has no
 effect on the effective code and can be significantly simplified - this 
 patch removes the condition and the duplicated code.

 Signed-off-by: Nicholas Mc Guire hof...@osadl.org
 ---

 This looks like the output of some broken code-generator - unlikely someone
 wrote this by hand. In any case it needs a review by someone that knows the
 details of the driver. 

 Anyway the number of useless code repetition is potentially record breaking !

 Patch was compile tested for x86_64_defconfig + CONFIG_STAGING=y
 CONFIG_R8723AU=m, CONFIG_8723AU_BT_COEXIST=y

 Patch is against 3.0.19-rc7 (localversoin = -next-20150203)

  .../staging/rtl8723au/hal/rtl8723a_bt-coexist.c|   60 
 +++-
  1 file changed, 8 insertions(+), 52 deletions(-)

Why make it simple if you can make it complicated :)

I presume it's against 3.19-rc7 since a 3.0.19 would be rather obsolete.

Signed-off-by: Jes Sorensen jes.soren...@redhat.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RESEND 2/6] hv: vmbus_post_msg: retry the hypercall on some transient errors

2015-02-03 Thread K. Y. Srinivasan
From: Dexuan Cui [mailto:de...@microsoft.com]

I got HV_STATUS_INVALID_CONNECTION_ID on Hyper-V 2008 R2 when keeping running
rmmod hv_netvsc; modprobe hv_netvsc; rmmod hv_utils; modprobe hv_utils
in a Linux guest. Looks the host has some kind of throttling mechanism if
some kinds of hypercalls are sent too frequently.
Without the patch, the driver can occasionally fail to load.

Also let's retry HV_STATUS_INSUFFICIENT_MEMORY, though we didn't get it
before.

Removed 'case -ENOMEM', since the hypervisor doesn't return this.

CC: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Jason Wang jasow...@redhat.com
Signed-off-by: Dexuan Cui de...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 arch/x86/include/uapi/asm/hyperv.h |2 ++
 drivers/hv/connection.c|   11 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/uapi/asm/hyperv.h 
b/arch/x86/include/uapi/asm/hyperv.h
index 90c458e..ce6068d 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -225,6 +225,8 @@
 #define HV_STATUS_INVALID_HYPERCALL_CODE   2
 #define HV_STATUS_INVALID_HYPERCALL_INPUT  3
 #define HV_STATUS_INVALID_ALIGNMENT4
+#define HV_STATUS_INSUFFICIENT_MEMORY  11
+#define HV_STATUS_INVALID_CONNECTION_ID18
 #define HV_STATUS_INSUFFICIENT_BUFFERS 19
 
 typedef struct _HV_REFERENCE_TSC_PAGE {
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index c4acd1c..af2388f 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -440,9 +440,16 @@ int vmbus_post_msg(void *buffer, size_t buflen)
ret = hv_post_message(conn_id, 1, buffer, buflen);
 
switch (ret) {
+   case HV_STATUS_INVALID_CONNECTION_ID:
+   /*
+* We could get this if we send messages too
+* frequently.
+*/
+   ret = -EAGAIN;
+   break;
+   case HV_STATUS_INSUFFICIENT_MEMORY:
case HV_STATUS_INSUFFICIENT_BUFFERS:
ret = -ENOMEM;
-   case -ENOMEM:
break;
case HV_STATUS_SUCCESS:
return ret;
@@ -452,7 +459,7 @@ int vmbus_post_msg(void *buffer, size_t buflen)
}
 
retries++;
-   msleep(100);
+   msleep(1000);
}
return ret;
 }
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RESEND 5/6] hv: channel_mgmt: match var type to return type of wait_for_completion

2015-02-03 Thread K. Y. Srinivasan
From: Nicholas Mc Guire der.h...@hofr.at

return type of wait_for_completion_timeout is unsigned long not int, this
patch changes the type of t from int to unsigned long.

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel_mgmt.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 36bacc7..6be93f0 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -789,7 +789,8 @@ int vmbus_request_offers(void)
 {
struct vmbus_channel_message_header *msg;
struct vmbus_channel_msginfo *msginfo;
-   int ret, t;
+   int ret;
+   unsigned long t;
 
msginfo = kmalloc(sizeof(*msginfo) +
  sizeof(struct vmbus_channel_message_header),
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RESEND 1/6] hv: hv_util: move vmbus_open() to a later place

2015-02-03 Thread K. Y. Srinivasan
From: Dexuan Cui [mailto:de...@microsoft.com]

Before the line vmbus_open() returns, srv-util_cb can be already running
and the variables, like util_fw_version, are needed by the srv-util_cb.

So we have to make sure the variables are initialized before the vmbus_open().

CC: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Vitaly Kuznetsov vkuzn...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Signed-off-by: Dexuan Cui de...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/hv_util.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 3b9c9ef..c5be773 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -340,12 +340,8 @@ static int util_probe(struct hv_device *dev,
 
set_channel_read_state(dev-channel, false);
 
-   ret = vmbus_open(dev-channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0,
-   srv-util_cb, dev-channel);
-   if (ret)
-   goto error;
-
hv_set_drvdata(dev, srv);
+
/*
 * Based on the host; initialize the framework and
 * service version numbers we will negotiate.
@@ -365,6 +361,11 @@ static int util_probe(struct hv_device *dev,
hb_srv_version = HB_VERSION;
}
 
+   ret = vmbus_open(dev-channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0,
+   srv-util_cb, dev-channel);
+   if (ret)
+   goto error;
+
return 0;
 
 error:
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RESEND 4/6] hv: channel: match var type to return type of wait_for_completion

2015-02-03 Thread K. Y. Srinivasan
From: Nicholas Mc Guire der.h...@hofr.at

return type of wait_for_completion_timeout is unsigned long not int, this
patch changes the type of t from int to unsigned long.

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 26dcf26..f687995 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -71,7 +71,8 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
struct vmbus_channel_msginfo *open_info = NULL;
void *in, *out;
unsigned long flags;
-   int ret, t, err = 0;
+   int ret, err = 0;
+   unsigned long t;
 
spin_lock_irqsave(newchannel-lock, flags);
if (newchannel-state == CHANNEL_OPEN_STATE) {
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RESEND 6/6] hv: hv_balloon: match var type to return type of wait_for_completion

2015-02-03 Thread K. Y. Srinivasan
From: Nicholas Mc Guire der.h...@hofr.at

return type of wait_for_completion_timeout is unsigned long not int, this
patch changes the type of t from int to unsigned long.

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/hv_balloon.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index ff16938..965c37a 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1414,7 +1414,8 @@ static void balloon_onchannelcallback(void *context)
 static int balloon_probe(struct hv_device *dev,
const struct hv_vmbus_device_id *dev_id)
 {
-   int ret, t;
+   int ret;
+   unsigned long t;
struct dm_version_request version_req;
struct dm_capabilities cap_msg;
 
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RESEND 3/6] hv: vmbus_open(): reset the channel state on ENOMEM

2015-02-03 Thread K. Y. Srinivasan
From: Dexuan Cui [mailto:de...@microsoft.com]

Without this patch, the state is put to CHANNEL_OPENING_STATE, and when
the driver is loaded next time, vmbus_open() will fail immediately due to
newchannel-state != CHANNEL_OPEN_STATE.

CC: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Dexuan Cui de...@microsoft.com
Reviewed-by: Jason Wang jasow...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 2978f5e..26dcf26 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -89,9 +89,10 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
out = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
 
-   if (!out)
-   return -ENOMEM;
-
+   if (!out) {
+   err = -ENOMEM;
+   goto error0;
+   }
 
in = (void *)((unsigned long)out + send_ringbuffer_size);
 
@@ -199,6 +200,7 @@ error0:
free_pages((unsigned long)out,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
kfree(open_info);
+   newchannel-state = CHANNEL_OPEN_STATE;
return err;
 }
 EXPORT_SYMBOL_GPL(vmbus_open);
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


AWAITING URGENT REPLY

2015-02-03 Thread Mr. Lou Yost
INTERNATIONAL FUNDS TRANSFER / AUDIT UNIT UNITED NATIONS
(World Bank Assisted Programme) Directorate of International Payment and 
Transfers UN Plaza,
 DC2-2060, New York, 10017.
Attention:-The Beneficiary,
My Names are Mr. Lou Yost, I'm the 2nd vice chairman of the united nations/ 
international monetary fund investigating unit, we arrived into Africa on 5th 
January 2015, Following series of Complaints, by Beneficiaries who are yet to 
receive their outstanding Contract/Inheritance/lottery Funds, from the Banks in 
African Countries.
The International monitory fund investigating Unit discovered particularly in 
your own case that some corrupt bank/ Government Officials had the intention of 
diverting your Funds to their own private Accounts abroad. The Team that 
carried out the investigation recovered some Payment Files which have since 
been approved for payment which yours was inclusive, secondly, in the same file 
of yours, there is a letter here stating that you are dead, so based on this, 
we are contacting you to verify the true position of your status, and you have 
only 48hours to reply this mail or we will work with what we saw in your file 
that you are dead, and I will personally append my signature to push your fund 
into the government treasury account as an unclaimed fund.
Note that the United Nations special payment unit has been authorized to handle 
your Payment File and based on our recommendation, your Outstanding fund have 
been credited in our Paying Bank Escrow Account in your Favor pending your 
reconfirmation to this office of your true position in this matter. You are 
hereby advised to reply this mail immediately to confirm whether or not you 
actually wrote that Letter forfeiting your Funds otherwise you should indicate 
your interest in receiving your fund.
Please resend your Full Name Residential Address, Telephone Number, Mobile 
Number if any, Age and Marital Status. Core Job or Occupation, A valid form of 
identification, and the Amount expecting. Please state if it was Contract/ 
Inheritance or Lottery funds and the country you were expecting payment from.
 You are advised to fully co-operate with this Team so that we can serve you 
better in this first Quota payment of this year 2015, and we assure you that we 
must bring to book all these corrupt officials of central bank if we found them 
guilty.
Waiting,
Mr. Lou Yost.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/1] Drivers: hv: vmbus: Add support for the NetworkDirect GUID

2015-02-03 Thread K. Y. Srinivasan
NetworkDirect is a service that supports guest RDMA. Define the GUID for this
service.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel_mgmt.c |2 ++
 include/linux/hyperv.h|   10 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 6be93f0..0ba6b5c 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -413,6 +413,8 @@ static const struct hv_vmbus_device_id hp_devs[] = {
{ HV_SCSI_GUID, },
/* Network */
{ HV_NIC_GUID, },
+   /* NetworkDirect Guest RDMA */
+   { HV_ND_GUID, },
 };
 
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index e73cfeb..b079abf 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1110,6 +1110,16 @@ void vmbus_driver_unregister(struct hv_driver 
*hv_driver);
}
 
 /*
+ * NetworkDirect. This is the guest RDMA service.
+ * {8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}
+ */
+#define HV_ND_GUID \
+   .guid = { \
+   0x3d, 0xaf, 0x2e, 0x8c, 0xa7, 0x32, 0x09, 0x4b, \
+   0xab, 0x99, 0xbd, 0x1f, 0x1c, 0x86, 0xb5, 0x01 \
+   }
+
+/*
  * Common header for Hyper-V ICs
  */
 
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/1] Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()

2015-02-03 Thread K. Y. Srinivasan
Correctly rollback state if the failure occurs after we have handed over
the ownership of the buffer to the host.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
 drivers/hv/channel.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index f687995..bf0cf8f 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -137,7 +137,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
   GFP_KERNEL);
if (!open_info) {
err = -ENOMEM;
-   goto error0;
+   goto error_gpadl;
}
 
init_completion(open_info-waitevent);
@@ -153,7 +153,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
 
if (userdatalen  MAX_USER_DEFINED_BYTES) {
err = -EINVAL;
-   goto error0;
+   goto error_gpadl;
}
 
if (userdatalen)
@@ -197,6 +197,9 @@ error1:
list_del(open_info-msglistentry);
spin_unlock_irqrestore(vmbus_connection.channelmsg_lock, flags);
 
+error_gpadl:
+   vmbus_teardown_gpadl(newchannel, newchannel-ringbuffer_gpadlhandle);
+
 error0:
free_pages((unsigned long)out,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 0/2] staging: sm7xxfb: checkpatch cleanup

2015-02-03 Thread Sudip Mukherjee
Hi,
Continuing with the checkpatch cleanup, this series will just fix the CamelCase.
Two different patches are made just to make review easier.
Now there is only one checkpatch warning pending about __setup, which will be 
fixed
in one of the upcoming patch where I will introduce the use of fb_get_options() 
and
that will also fix the compilation warning of unused function.

thanks
sudip

Sudip Mukherjee (2):
  staging: sm7xxfb: fix camelcase
  staging: sm7xxfb: fix remaining camelcase

 drivers/staging/sm7xxfb/sm7xx.h   | 44 ++---
 drivers/staging/sm7xxfb/sm7xxfb.c | 58 +++
 2 files changed, 51 insertions(+), 51 deletions(-)

-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


AWAITING URGENT REPLY

2015-02-03 Thread Mr. Lou Yost
INTERNATIONAL FUNDS TRANSFER / AUDIT UNIT UNITED NATIONS
(World Bank Assisted Programme) Directorate of International Payment and 
Transfers UN Plaza,
 DC2-2060, New York, 10017.
Attention:-The Beneficiary,
My Names are Mr. Lou Yost, I'm the 2nd vice chairman of the united nations/ 
international monetary fund investigating unit, we arrived into Africa on 5th 
January 2015, Following series of Complaints, by Beneficiaries who are yet to 
receive their outstanding Contract/Inheritance/lottery Funds, from the Banks in 
African Countries.
The International monitory fund investigating Unit discovered particularly in 
your own case that some corrupt bank/ Government Officials had the intention of 
diverting your Funds to their own private Accounts abroad. The Team that 
carried out the investigation recovered some Payment Files which have since 
been approved for payment which yours was inclusive, secondly, in the same file 
of yours, there is a letter here stating that you are dead, so based on this, 
we are contacting you to verify the true position of your status, and you have 
only 48hours to reply this mail or we will work with what we saw in your file 
that you are dead, and I will personally append my signature to push your fund 
into the government treasury account as an unclaimed fund.
Note that the United Nations special payment unit has been authorized to handle 
your Payment File and based on our recommendation, your Outstanding fund have 
been credited in our Paying Bank Escrow Account in your Favor pending your 
reconfirmation to this office of your true position in this matter. You are 
hereby advised to reply this mail immediately to confirm whether or not you 
actually wrote that Letter forfeiting your Funds otherwise you should indicate 
your interest in receiving your fund.
Please resend your Full Name Residential Address, Telephone Number, Mobile 
Number if any, Age and Marital Status. Core Job or Occupation, A valid form of 
identification, and the Amount expecting. Please state if it was Contract/ 
Inheritance or Lottery funds and the country you were expecting payment from.
 You are advised to fully co-operate with this Team so that we can serve you 
better in this first Quota payment of this year 2015, and we assure you that we 
must bring to book all these corrupt officials of central bank if we found them 
guilty.
Waiting,
Mr. Lou Yost.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


AWAITING URGENT REPLY

2015-02-03 Thread Mr. Lou Yost
INTERNATIONAL FUNDS TRANSFER / AUDIT UNIT UNITED NATIONS
(World Bank Assisted Programme) Directorate of International Payment and 
Transfers UN Plaza,
 DC2-2060, New York, 10017.
Attention:-The Beneficiary,
My Names are Mr. Lou Yost, I'm the 2nd vice chairman of the united nations/ 
international monetary fund investigating unit, we arrived into Africa on 5th 
January 2015, Following series of Complaints, by Beneficiaries who are yet to 
receive their outstanding Contract/Inheritance/lottery Funds, from the Banks in 
African Countries.
The International monitory fund investigating Unit discovered particularly in 
your own case that some corrupt bank/ Government Officials had the intention of 
diverting your Funds to their own private Accounts abroad. The Team that 
carried out the investigation recovered some Payment Files which have since 
been approved for payment which yours was inclusive, secondly, in the same file 
of yours, there is a letter here stating that you are dead, so based on this, 
we are contacting you to verify the true position of your status, and you have 
only 48hours to reply this mail or we will work with what we saw in your file 
that you are dead, and I will personally append my signature to push your fund 
into the government treasury account as an unclaimed fund.
Note that the United Nations special payment unit has been authorized to handle 
your Payment File and based on our recommendation, your Outstanding fund have 
been credited in our Paying Bank Escrow Account in your Favor pending your 
reconfirmation to this office of your true position in this matter. You are 
hereby advised to reply this mail immediately to confirm whether or not you 
actually wrote that Letter forfeiting your Funds otherwise you should indicate 
your interest in receiving your fund.
Please resend your Full Name Residential Address, Telephone Number, Mobile 
Number if any, Age and Marital Status. Core Job or Occupation, A valid form of 
identification, and the Amount expecting. Please state if it was Contract/ 
Inheritance or Lottery funds and the country you were expecting payment from.
 You are advised to fully co-operate with this Team so that we can serve you 
better in this first Quota payment of this year 2015, and we assure you that we 
must bring to book all these corrupt officials of central bank if we found them 
guilty.
Waiting,
Mr. Lou Yost.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: lustre: lustre: lmv: fix sparse warnings related to static declarations

2015-02-03 Thread Mohammad Jamal
This patch removes the sparse warnings present in the lproc_lmv.c

Signed-off-by: Mohammad Jamal md.jamalmohiud...@gmail.com
---
 drivers/staging/lustre/lustre/lmv/lproc_lmv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c 
b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
index 5be4176..804476b 100644
--- a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
+++ b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
@@ -215,7 +215,7 @@ static struct lprocfs_vars lprocfs_lmv_module_vars[] = {
{ NULL }
 };
 
-struct file_operations lmv_proc_target_fops = {
+static struct file_operations lmv_proc_target_fops = {
.owner  = THIS_MODULE,
.open= lmv_target_seq_open,
.read= seq_read,
@@ -223,7 +223,7 @@ struct file_operations lmv_proc_target_fops = {
.release  = seq_release,
 };
 
-void lprocfs_lmv_init_vars(struct lprocfs_static_vars *lvars)
+static void lprocfs_lmv_init_vars(struct lprocfs_static_vars *lvars)
 {
lvars-module_vars= lprocfs_lmv_module_vars;
lvars-obd_vars   = lprocfs_lmv_obd_vars;
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: rtl8723au: multiple condition with no effect - if identical to else

2015-02-03 Thread Nicholas Mc Guire
On Tue, 03 Feb 2015, Jes Sorensen wrote:

 Nicholas Mc Guire hof...@osadl.org writes:
  A number if/else if/else branches are identical - so the condition has no
  effect on the effective code and can be significantly simplified - this 
  patch removes the condition and the duplicated code.
 
  Signed-off-by: Nicholas Mc Guire hof...@osadl.org
  ---
 
  This looks like the output of some broken code-generator - unlikely someone
  wrote this by hand. In any case it needs a review by someone that knows the
  details of the driver. 
 
  Anyway the number of useless code repetition is potentially record breaking 
  !
 
  Patch was compile tested for x86_64_defconfig + CONFIG_STAGING=y
  CONFIG_R8723AU=m, CONFIG_8723AU_BT_COEXIST=y
 
  Patch is against 3.0.19-rc7 (localversoin = -next-20150203)
 
   .../staging/rtl8723au/hal/rtl8723a_bt-coexist.c|   60 
  +++-
   1 file changed, 8 insertions(+), 52 deletions(-)
 
 Why make it simple if you can make it complicated :)
 
 I presume it's against 3.19-rc7 since a 3.0.19 would be rather obsolete.


yes - thats a typo - sorry for that.
 
 Signed-off-by: Jes Sorensen jes.soren...@redhat.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH RFC] staging: comedi: dt282x: condition with no effect - if identical to else

2015-02-03 Thread Ian Abbott

On 03/02/15 12:38, Nicholas Mc Guire wrote:

The if and the else branch code are identical - so the condition has no
effect on the effective code - this patch removes the condition and the
duplicated code.

Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---

The if and else branch are identical code thus the condition has no effect

 if (cmd-scan_begin_src == TRIG_FOLLOW) {
 /* internal trigger */
 err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
 } else {
 /* external trigger */
 /* should be level/edge, hi/lo specification here */
 err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
 }

As the comments indicate that they are serving different purposes this
looks like a bug. In any case - if intentional - it would need some
comments on why.

This needs a review by someone that knows the details of this driver.
Also not sure about the retained comment string if that is still valid now.

Patch was only compile tested for x86_64_defconfig + CONFIG_STAGING=y
CONFIG_COMEDI=m, COMEDI_ISA_DRIVERS=y, CONFIG_COMEDI_DT282X=m

Patch is against 3.0.19-rc7 (localversion = -next-20150203)

  drivers/staging/comedi/drivers/dt282x.c |   10 ++
  1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dt282x.c 
b/drivers/staging/comedi/drivers/dt282x.c
index 051dfb2..22c59e5 100644
--- a/drivers/staging/comedi/drivers/dt282x.c
+++ b/drivers/staging/comedi/drivers/dt282x.c
@@ -685,14 +685,8 @@ static int dt282x_ai_cmdtest(struct comedi_device *dev,

err |= cfc_check_trigger_arg_is(cmd-start_arg, 0);

-   if (cmd-scan_begin_src == TRIG_FOLLOW) {
-   /* internal trigger */
-   err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
-   } else {
-   /* external trigger */
-   /* should be level/edge, hi/lo specification here */


I think what that comment means is that it should allow scan_begin_arg 
to have various combinations of the CR_EDGE and CR_INVERT bits set. 
I.e. it ought to allow whatever combination of CR_EDGE and CR_INVERT 
better describes the nature of the external trigger signal, in addition 
to allowing the lazy default value 0.


I don't know what the nature of the external trigger signal is, as I 
haven't seen the manual.  I think Hartley might have seen one.



-   err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
-   }
+   /* internal trigger */


That comment would be misleading as it could be an internal or external 
trigger.


If you want to apply this patch, remove that comment first.  But I'd 
rather leave the existing code there as a reminder.



+   err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);

err |= cfc_check_trigger_arg_min(cmd-convert_arg, 4000);





--
-=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: lustre: lustre: lmv: fix sparse warnings about static declarations

2015-02-03 Thread Mohammad Jamal
This patch adds a static keyword to lprocfs_lmv_init_vars and
lprocfs_lmv_module_vars to suppress the sparse warnings about
static declaration

Signed-off-by: Mohammad Jamal md.jamalmohiud...@gmail.com
---
 drivers/staging/lustre/lustre/lmv/lproc_lmv.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c 
b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
index 5be4176..804476b 100644
--- a/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
+++ b/drivers/staging/lustre/lustre/lmv/lproc_lmv.c
@@ -215,7 +215,7 @@ static struct lprocfs_vars lprocfs_lmv_module_vars[] = {
{ NULL }
 };
 
-struct file_operations lmv_proc_target_fops = {
+static struct file_operations lmv_proc_target_fops = {
.owner  = THIS_MODULE,
.open= lmv_target_seq_open,
.read= seq_read,
@@ -223,7 +223,7 @@ struct file_operations lmv_proc_target_fops = {
.release  = seq_release,
 };
 
-void lprocfs_lmv_init_vars(struct lprocfs_static_vars *lvars)
+static void lprocfs_lmv_init_vars(struct lprocfs_static_vars *lvars)
 {
lvars-module_vars= lprocfs_lmv_module_vars;
lvars-obd_vars   = lprocfs_lmv_obd_vars;
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/fwserial: use correct vendor/version IDs

2015-02-03 Thread Stefan Richter
On Feb 02 Peter Hurley wrote:
 On 01/28/2015 03:07 PM, Clemens Ladisch wrote:
  The driver was using the vendor ID 0xd00d1e from the FireWire core.
  However, this ID was not registered, and invalid.
  
  Instead, use the vendor/version IDs that now are officially assigned to
  firewire-serial:
  https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments
 
 That's great that we have official OUIs now, but I have to NACK this
 patch as is.
 
 The problem is a host with the old OUIs will not recognize a remote
 unit with the new OUIs, and vice versa.
 
 Even though the new ids could be added to the unit driver's id_table,
 (which would let hosts with the new OUI connect to either OUI remote),
 it wouldn't let 3.19- hosts connect to 3.20+ hosts.

Actually there are no 3.19- hosts that speak fwserial; there are only
staging hosts that do so.  So, with this patch added, certain staging
hosts would become unable to talk with certain other staging hosts (and
with future Linux hosts, once fwserial gets merged upstream).

Both fwserial-the-implementation and fwserial-the-protocol are your own,
and as yet unmerged.  (In addition, there does not yet exist a second
implementation, AFAIK.)  So I'd say there is still opportunity to improve
the protocol even in incompatible ways if justified.  Switching to
valid identifiers may very well be such a justifiable change.
-- 
Stefan Richter
-=-= --=- ---==
http://arcgraph.de/sr/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: sm7xxfb: make smtc_scr_info static

2015-02-03 Thread Max Perepelitsyn
This symbol is never used anywhere else besides sm7xxfb.c

Signed-off-by: Max Perepelitsyn mperepelit...@gmail.com
---
 drivers/staging/sm7xxfb/sm7xxfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
b/drivers/staging/sm7xxfb/sm7xxfb.c
index 2ae9fd0..72036c2 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -111,7 +111,7 @@ static struct vesa_mode vesa_mode_table[] = {
{0x31B, 1280, 1024, 24},
 };
 
-struct screen_info smtc_scr_info;
+static struct screen_info smtc_scr_info;
 
 /* process command line options, get vga parameter */
 static int __init sm7xx_vga_setup(char *options)
-- 
2.2.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/fwserial: use correct vendor/version IDs

2015-02-03 Thread Peter Hurley
On 02/03/2015 03:44 AM, Stefan Richter wrote:
 On Feb 02 Peter Hurley wrote:
 On 01/28/2015 03:07 PM, Clemens Ladisch wrote:
 The driver was using the vendor ID 0xd00d1e from the FireWire core.
 However, this ID was not registered, and invalid.

 Instead, use the vendor/version IDs that now are officially assigned to
 firewire-serial:
 https://ieee1394.wiki.kernel.org/index.php/IEEE_OUI_Assignments

 That's great that we have official OUIs now, but I have to NACK this
 patch as is.

 The problem is a host with the old OUIs will not recognize a remote
 unit with the new OUIs, and vice versa.

 Even though the new ids could be added to the unit driver's id_table,
 (which would let hosts with the new OUI connect to either OUI remote),
 it wouldn't let 3.19- hosts connect to 3.20+ hosts.
 
 Actually there are no 3.19- hosts that speak fwserial; there are only
 staging hosts that do so.  So, with this patch added, certain staging
 hosts would become unable to talk with certain other staging hosts (and
 with future Linux hosts, once fwserial gets merged upstream).

The breakage seems gratuitous especially considering the existing OUI
has been in use for a decade.

 Both fwserial-the-implementation and fwserial-the-protocol are your own,
 and as yet unmerged.

I've been waiting for you to work through the patch backlog from Feb and
Mar of last year before sending you more patches to merge fwserial.

  (In addition, there does not yet exist a second
 implementation, AFAIK.)  So I'd say there is still opportunity to improve
 the protocol even in incompatible ways if justified.  Switching to
 valid identifiers may very well be such a justifiable change.

I would appreciate you sharing any suggestions for improving the protocol.

While I concede the protocol is not perfect, I'm struggling to see how
changing the OUI improves it.

Regards,
Peter Hurley


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: sm7xxfb: make smtc_scr_info static

2015-02-03 Thread Sudip Mukherjee
On Tue, Feb 03, 2015 at 02:44:28PM +0600, Max Perepelitsyn wrote:
 This symbol is never used anywhere else besides sm7xxfb.c

Hi Greg,
do i need to do anything about this patch? maybe a tested-by or reviewed-by?

regards
sudip

 
 Signed-off-by: Max Perepelitsyn mperepelit...@gmail.com
 ---
  drivers/staging/sm7xxfb/sm7xxfb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
 b/drivers/staging/sm7xxfb/sm7xxfb.c
 index 2ae9fd0..72036c2 100644
 --- a/drivers/staging/sm7xxfb/sm7xxfb.c
 +++ b/drivers/staging/sm7xxfb/sm7xxfb.c
 @@ -111,7 +111,7 @@ static struct vesa_mode vesa_mode_table[] = {
   {0x31B, 1280, 1024, 24},
  };
  
 -struct screen_info smtc_scr_info;
 +static struct screen_info smtc_scr_info;
  
  /* process command line options, get vga parameter */
  static int __init sm7xx_vga_setup(char *options)
 -- 
 2.2.2
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()

2015-02-03 Thread Haiyang Zhang


 -Original Message-
 From: Jason Wang [mailto:jasow...@redhat.com]
 Sent: Monday, February 2, 2015 1:49 AM
   btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC
  when
   queue_sends[q_idx]  1. But non of the caller check -ENOSPC in fact?
 
  In this case, we don't request re-send, so set ret to a value other
  than
  -EAGAIN.
 
 Why not? We have available slots for it to be sent now. Dropping the
 packet in this case may cause out of order sending.

The EAGAIN error doesn't normally happen, because we set the hi water mark
to stop send queue. If in really rare case, the ring buffer is full and there
is no outstanding sends, we can't stop queue here because there will be no
send-completion msg to wake it up. And, the ring buffer is likely to be 
occupied by other special msg, e.g. receive-completion msg (not a normal case),
so we can't assume there are available slots. We don't request retry from
the upper layer in this case to avoid possible busy retry.

Thanks,
- Haiyang

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 2/4] Drivers: hv: vmbus: do not lose rescind offer on failure in vmbus_process_offer()

2015-02-03 Thread Vitaly Kuznetsov
In case we hit a failure condition in vmbus_process_offer() and a rescind offer
was pending for the channel we just do free_channel() so 
CHANNELMSG_RELID_RELEASED
will never be send to the host. We have to follow vmbus_process_rescind_offer()
path anyway.

To support the change we need to protect list_del in 
vmbus_process_rescind_offer()
hitting an uninitialized list.

Reported-by: Dexuan Cui de...@microsoft.com
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
 drivers/hv/channel_mgmt.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index eb9ce94..fdccd16 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -152,6 +152,7 @@ static struct vmbus_channel *alloc_channel(void)
spin_lock_init(channel-inbound_lock);
spin_lock_init(channel-lock);
 
+   INIT_LIST_HEAD(channel-listentry);
INIT_LIST_HEAD(channel-sc_list);
INIT_LIST_HEAD(channel-percpu_list);
 
@@ -308,6 +309,7 @@ static void vmbus_process_offer(struct work_struct *work)
struct vmbus_channel *channel;
bool fnew = true;
bool enq = false;
+   bool failure = false;
int ret;
unsigned long flags;
 
@@ -408,19 +410,33 @@ static void vmbus_process_offer(struct work_struct *work)
spin_lock_irqsave(vmbus_connection.channel_lock, flags);
list_del(newchannel-listentry);
spin_unlock_irqrestore(vmbus_connection.channel_lock, flags);
+   /*
+* Init listentry again as vmbus_process_rescind_offer can try
+* doing list_del again.
+*/
+   INIT_LIST_HEAD(channel-listentry);
kfree(newchannel-device_obj);
+   newchannel-device_obj = NULL;
goto err_free_chan;
}
+   goto done_init_rescind;
+err_free_chan:
+   failure = true;
 done_init_rescind:
+   /*
+* Get additional reference as vmbus_put_channel() can be called
+* either directly or through vmbus_process_rescind_offer().
+*/
+   vmbus_get_channel(newchannel);
spin_lock_irqsave(newchannel-lock, flags);
/* The next possible work is rescind handling */
INIT_WORK(newchannel-work, vmbus_process_rescind_offer);
/* Check if rescind offer was already received */
if (newchannel-rescind)
queue_work(newchannel-controlwq, newchannel-work);
+   else if (failure)
+   vmbus_put_channel(newchannel);
spin_unlock_irqrestore(newchannel-lock, flags);
-   return;
-err_free_chan:
vmbus_put_channel(newchannel);
 }
 
-- 
1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/4] Drivers: hv: vmbus: implement get/put usage workflow for vmbus channels

2015-02-03 Thread Vitaly Kuznetsov
free_channel() function frees the channel unconditionally so we need to make
sure nobody has any link to it. This is not trivial and there are several
examples of races we have:

1) In vmbus_onoffer_rescind() we check for channel existence with
   relid2channel() and then use it. This can go wrong if we're in the middle
   of channel removal (free_channel() was already called).

2) In process_chn_event() we check for channel existence with
   pcpu_relid2channel() and then use it. This can also go wrong.

3) vmbus_free_channels() just frees all channels, in case we're in the middle
   of vmbus_process_rescind_offer() crash is possible.

The issue can be solved by holding vmbus_connection.channel_lock everywhere,
however, it looks like a way to deadlocks and performance degradation. Get/put
workflow fits here the best.

Implement vmbus_get_channel()/vmbus_put_channel() pair instead of
free_channel().

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
 drivers/hv/channel_mgmt.c | 45 ++---
 drivers/hv/connection.c   |  7 +--
 drivers/hv/hyperv_vmbus.h |  4 
 include/linux/hyperv.h| 13 +
 4 files changed, 60 insertions(+), 9 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 36bacc7..eb9ce94 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -147,6 +147,8 @@ static struct vmbus_channel *alloc_channel(void)
return NULL;
 
channel-id = atomic_inc_return(chan_num);
+   atomic_set(channel-count, 1);
+
spin_lock_init(channel-inbound_lock);
spin_lock_init(channel-lock);
 
@@ -178,19 +180,47 @@ static void release_channel(struct work_struct *work)
 }
 
 /*
- * free_channel - Release the resources used by the vmbus channel object
+ * vmbus_put_channel - Decrease the channel usage counter and release the
+ * resources when this counter reaches zero.
  */
-static void free_channel(struct vmbus_channel *channel)
+void vmbus_put_channel(struct vmbus_channel *channel)
 {
+   unsigned long flags;
 
/*
 * We have to release the channel's workqueue/thread in the vmbus's
 * workqueue/thread context
 * ie we can't destroy ourselves.
 */
-   INIT_WORK(channel-work, release_channel);
-   queue_work(vmbus_connection.work_queue, channel-work);
+   spin_lock_irqsave(channel-lock, flags);
+   if (atomic_dec_and_test(channel-count)) {
+   channel-dying = true;
+   INIT_WORK(channel-work, release_channel);
+   spin_unlock_irqrestore(channel-lock, flags);
+   queue_work(vmbus_connection.work_queue, channel-work);
+   } else
+   spin_unlock_irqrestore(channel-lock, flags);
+}
+EXPORT_SYMBOL_GPL(vmbus_put_channel);
+
+/* vmbus_get_channel - Get additional reference to the channel */
+struct vmbus_channel *vmbus_get_channel(struct vmbus_channel *channel)
+{
+   unsigned long flags;
+   struct vmbus_channel *ret = NULL;
+
+   if (!channel)
+   return NULL;
+
+   spin_lock_irqsave(channel-lock, flags);
+   if (!channel-dying) {
+   atomic_inc(channel-count);
+   ret = channel;
+   }
+   spin_unlock_irqrestore(channel-lock, flags);
+   return ret;
 }
+EXPORT_SYMBOL_GPL(vmbus_get_channel);
 
 static void percpu_channel_enq(void *arg)
 {
@@ -253,7 +283,7 @@ static void vmbus_process_rescind_offer(struct work_struct 
*work)
list_del(channel-sc_list);
spin_unlock_irqrestore(primary_channel-lock, flags);
}
-   free_channel(channel);
+   vmbus_put_channel(channel);
 }
 
 void vmbus_free_channels(void)
@@ -262,7 +292,7 @@ void vmbus_free_channels(void)
 
list_for_each_entry(channel, vmbus_connection.chn_list, listentry) {
vmbus_device_unregister(channel-device_obj);
-   free_channel(channel);
+   vmbus_put_channel(channel);
}
 }
 
@@ -391,7 +421,7 @@ done_init_rescind:
spin_unlock_irqrestore(newchannel-lock, flags);
return;
 err_free_chan:
-   free_channel(newchannel);
+   vmbus_put_channel(newchannel);
 }
 
 enum {
@@ -549,6 +579,7 @@ static void vmbus_onoffer_rescind(struct 
vmbus_channel_message_header *hdr)
queue_work(channel-controlwq, channel-work);
 
spin_unlock_irqrestore(channel-lock, flags);
+   vmbus_put_channel(channel);
 }
 
 /*
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index c4acd1c..d1ce134 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -247,7 +247,8 @@ void vmbus_disconnect(void)
  * Map the given relid to the corresponding channel based on the
  * per-cpu list of channels that have been affinitized to this CPU.
  * This will be used in the channel callback path as we can do this
- * mapping in a lock-free fashion.
+ * mapping in a lock-free fashion. Takes additional reference to 

[PATCH 3/4] Drivers: hv: vmbus: protect vmbus_get_outgoing_channel() against channel removal

2015-02-03 Thread Vitaly Kuznetsov
list_for_each_safe() we have in vmbus_get_outgoing_channel() works, however, we
are not protected against the channel being removed (e.g. after receiving 
rescind
offer). Users of this function (storvsc_do_io() is the only one at this moment)
can get a link to an already freed channel. Make vmbus_get_outgoing_channel()
search holding primary-lock as child channels are not being freed unless 
they're
removed from parent's list.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
 drivers/hv/channel_mgmt.c  | 10 +++---
 drivers/scsi/storvsc_drv.c |  2 ++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index fdccd16..af6243c 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -881,18 +881,20 @@ cleanup:
  */
 struct vmbus_channel *vmbus_get_outgoing_channel(struct vmbus_channel *primary)
 {
-   struct list_head *cur, *tmp;
+   struct list_head *cur;
int cur_cpu;
struct vmbus_channel *cur_channel;
struct vmbus_channel *outgoing_channel = primary;
int cpu_distance, new_cpu_distance;
+   unsigned long flags;
 
if (list_empty(primary-sc_list))
-   return outgoing_channel;
+   return vmbus_get_channel(outgoing_channel);
 
cur_cpu = hv_context.vp_index[get_cpu()];
put_cpu();
-   list_for_each_safe(cur, tmp, primary-sc_list) {
+   spin_lock_irqsave(primary-lock, flags);
+   list_for_each(cur, primary-sc_list) {
cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
if (cur_channel-state != CHANNEL_OPENED_STATE)
continue;
@@ -913,6 +915,8 @@ struct vmbus_channel *vmbus_get_outgoing_channel(struct 
vmbus_channel *primary)
 
outgoing_channel = cur_channel;
}
+   outgoing_channel = vmbus_get_channel(outgoing_channel);
+   spin_unlock_irqrestore(primary-lock, flags);
 
return outgoing_channel;
 }
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 4cff0dd..3b9b851 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1370,6 +1370,8 @@ static int storvsc_do_io(struct hv_device *device,
   VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
}
 
+   vmbus_put_channel(outgoing_channel);
+
if (ret != 0)
return ret;
 
-- 
1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 4/4] hyperv: netvsc: improve protection against rescind offer

2015-02-03 Thread Vitaly Kuznetsov
The check added in commit c3582a2c4d0b (hyperv: Add support for vNIC hot
removal) is incomplete as there is no synchronization between
vmbus_onoffer_rescind() and netvsc_send(). In case we get the offer after we
checked out_channel-rescind and before netvsc_send() finishes its job we can
get a crash as we'll be dealing with already freed channel.

Make netvsc_send() take additional reference to the channel with newly
introduced vmbus_get_channel(), this guarantees we won't lose the channel. We
can still get rescind while we're processing but this won't cause a crash.

Reported-by: Jason Wang jasow...@redhat.com
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
 drivers/net/hyperv/netvsc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 9f49c01..d9b13a1 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -763,11 +763,16 @@ int netvsc_send(struct hv_device *device,
out_channel = net_device-chn_table[packet-q_idx];
if (out_channel == NULL)
out_channel = device-channel;
-   packet-channel = out_channel;
+   packet-channel = vmbus_get_channel(out_channel);
 
-   if (out_channel-rescind)
+   if (!packet-channel)
return -ENODEV;
 
+   if (out_channel-rescind) {
+   vmbus_put_channel(out_channel);
+   return -ENODEV;
+   }
+
if (packet-page_buf_cnt) {
ret = vmbus_sendpacket_pagebuffer(out_channel,
  packet-page_buf,
@@ -810,6 +815,7 @@ int netvsc_send(struct hv_device *device,
   packet, ret);
}
 
+   vmbus_put_channel(packet-channel);
return ret;
 }
 
-- 
1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 0/4] Drivers: hv: Further protection for the rescind path

2015-02-03 Thread Vitaly Kuznetsov
This series is a continuation of the Drivers: hv: vmbus: serialize Offer and
Rescind offer. I'm trying to address a number of theoretically possible issues
with rescind offer handling. All these complications come from the fact that
a rescind offer results in vmbus channel being freed and we must ensure nobody
still uses it. Instead of introducing new locks I suggest we switch channels
usage to the get/put workflow.

The main part of the series is [PATCH 1/4] which introduces the workflow for
vmbus channels, all other patches fix different corner cases using this
workflow. I'm not sure all such cases are covered with this series (probably
not), but in case protection is required in some other places it should become
relatively easy to add one.

I did some sanity testing with CONFIG_DEBUG_LOCKDEP=y and nothing popped out,
however, additional testing would be much appreciated.

K.Y., Haiyang, I'm not sending this series to netdev@ and linux-scsi@ as it is
supposed to be applied as a whole, please resend these patches with your
sign-offs when (and if) we're done with reviews. Thanks!

Vitaly Kuznetsov (4):
  Drivers: hv: vmbus: implement get/put usage workflow for vmbus
channels
  Drivers: hv: vmbus: do not lose rescind offer on failure in
vmbus_process_offer()
  Drivers: hv: vmbus: protect vmbus_get_outgoing_channel() against
channel removal
  hyperv: netvsc: improve protection against rescind offer

 drivers/hv/channel_mgmt.c   | 75 +
 drivers/hv/connection.c |  7 +++--
 drivers/hv/hyperv_vmbus.h   |  4 +++
 drivers/net/hyperv/netvsc.c | 10 --
 drivers/scsi/storvsc_drv.c  |  2 ++
 include/linux/hyperv.h  | 13 
 6 files changed, 95 insertions(+), 16 deletions(-)

-- 
1.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RFC] staging: comedi: dt282x: condition with no effect - if identical to else

2015-02-03 Thread Nicholas Mc Guire
The if and the else branch code are identical - so the condition has no
effect on the effective code - this patch removes the condition and the
duplicated code.

Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---

The if and else branch are identical code thus the condition has no effect

if (cmd-scan_begin_src == TRIG_FOLLOW) {
/* internal trigger */
err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
} else {
/* external trigger */
/* should be level/edge, hi/lo specification here */
err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
}

As the comments indicate that they are serving different purposes this
looks like a bug. In any case - if intentional - it would need some
comments on why.

This needs a review by someone that knows the details of this driver.
Also not sure about the retained comment string if that is still valid now.

Patch was only compile tested for x86_64_defconfig + CONFIG_STAGING=y
CONFIG_COMEDI=m, COMEDI_ISA_DRIVERS=y, CONFIG_COMEDI_DT282X=m

Patch is against 3.0.19-rc7 (localversion = -next-20150203)

 drivers/staging/comedi/drivers/dt282x.c |   10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/comedi/drivers/dt282x.c 
b/drivers/staging/comedi/drivers/dt282x.c
index 051dfb2..22c59e5 100644
--- a/drivers/staging/comedi/drivers/dt282x.c
+++ b/drivers/staging/comedi/drivers/dt282x.c
@@ -685,14 +685,8 @@ static int dt282x_ai_cmdtest(struct comedi_device *dev,
 
err |= cfc_check_trigger_arg_is(cmd-start_arg, 0);
 
-   if (cmd-scan_begin_src == TRIG_FOLLOW) {
-   /* internal trigger */
-   err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
-   } else {
-   /* external trigger */
-   /* should be level/edge, hi/lo specification here */
-   err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
-   }
+   /* internal trigger */
+   err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
 
err |= cfc_check_trigger_arg_min(cmd-convert_arg, 4000);
 
-- 
1.7.10.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous bug fixes and cleanup

2015-02-03 Thread K. Y. Srinivasan
This is a resend of the patches from Dexuan and Nicholas

Dexuan Cui (3):
  hv: hv_util: move vmbus_open() to a later place
  hv: vmbus_post_msg: retry the hypercall on some transient errors
  hv: vmbus_open(): reset the channel state on ENOMEM

Nicholas Mc Guire (3):
  hv: channel: match var type to return type of wait_for_completion
  hv: channel_mgmt: match var type to return type of
wait_for_completion
  hv: hv_balloon: match var type to return type of wait_for_completion

 arch/x86/include/uapi/asm/hyperv.h |2 ++
 drivers/hv/channel.c   |   11 +++
 drivers/hv/channel_mgmt.c  |3 ++-
 drivers/hv/connection.c|   11 +--
 drivers/hv/hv_balloon.c|3 ++-
 drivers/hv/hv_util.c   |   11 ++-
 6 files changed, 28 insertions(+), 13 deletions(-)

-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: rtl8723au: multiple condition with no effect - if identical to else

2015-02-03 Thread Nicholas Mc Guire
A number if/else if/else branches are identical - so the condition has no
effect on the effective code and can be significantly simplified - this 
patch removes the condition and the duplicated code.

Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---

This looks like the output of some broken code-generator - unlikely someone
wrote this by hand. In any case it needs a review by someone that knows the
details of the driver. 

Anyway the number of useless code repetition is potentially record breaking !

Patch was compile tested for x86_64_defconfig + CONFIG_STAGING=y
CONFIG_R8723AU=m, CONFIG_8723AU_BT_COEXIST=y

Patch is against 3.0.19-rc7 (localversoin = -next-20150203)

 .../staging/rtl8723au/hal/rtl8723a_bt-coexist.c|   60 +++-
 1 file changed, 8 insertions(+), 52 deletions(-)

diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c 
b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
index 412d8cf..73cfddd 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
@@ -7255,63 +7255,19 @@ btdm_2AntTdmaDurationAdjust(struct rtw_adapter 
*padapter, u8 bScoHid,
RTPRINT(FBT, BT_TRACE, ([BTCoex], first run 
TdmaDurationAdjust()!!\n));
if (bScoHid) {
if (bTxPause) {
-   if (maxInterval == 1) {
-   btdm_2AntPsTdma(padapter, true, 15);
-   pBtdm8723-psTdmaDuAdjType = 15;
-   } else if (maxInterval == 2) {
-   btdm_2AntPsTdma(padapter, true, 15);
-   pBtdm8723-psTdmaDuAdjType = 15;
-   } else if (maxInterval == 3) {
-   btdm_2AntPsTdma(padapter, true, 15);
-   pBtdm8723-psTdmaDuAdjType = 15;
-   } else {
-   btdm_2AntPsTdma(padapter, true, 15);
-   pBtdm8723-psTdmaDuAdjType = 15;
-   }
+   btdm_2AntPsTdma(padapter, true, 15);
+   pBtdm8723-psTdmaDuAdjType = 15;
} else {
-   if (maxInterval == 1) {
-   btdm_2AntPsTdma(padapter, true, 11);
-   pBtdm8723-psTdmaDuAdjType = 11;
-   } else if (maxInterval == 2) {
-   btdm_2AntPsTdma(padapter, true, 11);
-   pBtdm8723-psTdmaDuAdjType = 11;
-   } else if (maxInterval == 3) {
-   btdm_2AntPsTdma(padapter, true, 11);
-   pBtdm8723-psTdmaDuAdjType = 11;
-   } else {
-   btdm_2AntPsTdma(padapter, true, 11);
-   pBtdm8723-psTdmaDuAdjType = 11;
-   }
+   btdm_2AntPsTdma(padapter, true, 11);
+   pBtdm8723-psTdmaDuAdjType = 11;
}
} else {
if (bTxPause) {
-   if (maxInterval == 1) {
-   btdm_2AntPsTdma(padapter, true, 7);
-   pBtdm8723-psTdmaDuAdjType = 7;
-   } else if (maxInterval == 2) {
-   btdm_2AntPsTdma(padapter, true, 7);
-   pBtdm8723-psTdmaDuAdjType = 7;
-   } else if (maxInterval == 3) {
-   btdm_2AntPsTdma(padapter, true, 7);
-   pBtdm8723-psTdmaDuAdjType = 7;
-   } else {
-   btdm_2AntPsTdma(padapter, true, 7);
-   pBtdm8723-psTdmaDuAdjType = 7;
-   }
+   btdm_2AntPsTdma(padapter, true, 7);
+   pBtdm8723-psTdmaDuAdjType = 7;
} else {
-   if (maxInterval == 1) {
-   btdm_2AntPsTdma(padapter, true, 3);
-   pBtdm8723-psTdmaDuAdjType = 3;
-   } else if (maxInterval == 2) {
-   btdm_2AntPsTdma(padapter, true, 3);
-   pBtdm8723-psTdmaDuAdjType = 3;
-   } else if (maxInterval == 3) {
-   btdm_2AntPsTdma(padapter, true, 3

Re: [PATCH] staging: lustre: lustre: lmv: fix sparse warnings about static declarations

2015-02-03 Thread Sudip Mukherjee
On Tue, Feb 03, 2015 at 08:54:45PM +0530, Mohammad Jamal wrote:
 This patch adds a static keyword to lprocfs_lmv_init_vars and
 lprocfs_lmv_module_vars to suppress the sparse warnings about
 static declaration
have you build tested your patch?

After your patch:
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:218:31: warning: 
‘lmv_proc_target_fops’ defined but not used [-Wunused-variable]
drivers/staging/lustre/lustre/lmv/lproc_lmv.c:226:13: warning: 
‘lprocfs_lmv_init_vars’ defined but not used [-Wunused-function]

WARNING: lprocfs_lmv_init_vars [drivers/staging/lustre/lustre/lmv/lmv.ko] 
undefined!
WARNING: lmv_proc_target_fops [drivers/staging/lustre/lustre/lmv/lmv.ko] 
undefined!

regards
sudip

 
 Signed-off-by: Mohammad Jamal md.jamalmohiud...@gmail.com
 ---
snip
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: sm7xxfb: make smtc_scr_info static

2015-02-03 Thread Sudip Mukherjee
On Tue, Feb 03, 2015 at 02:44:28PM +0600, Max Perepelitsyn wrote:
 This symbol is never used anywhere else besides sm7xxfb.c
 
 Signed-off-by: Max Perepelitsyn mperepelit...@gmail.com

Tested-by: Sudip Mukherjee su...@vectorindia.org

 ---
  drivers/staging/sm7xxfb/sm7xxfb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c 
 b/drivers/staging/sm7xxfb/sm7xxfb.c
 index 2ae9fd0..72036c2 100644
 --- a/drivers/staging/sm7xxfb/sm7xxfb.c
 +++ b/drivers/staging/sm7xxfb/sm7xxfb.c
 @@ -111,7 +111,7 @@ static struct vesa_mode vesa_mode_table[] = {
   {0x31B, 1280, 1024, 24},
  };
  
 -struct screen_info smtc_scr_info;
 +static struct screen_info smtc_scr_info;
  
  /* process command line options, get vga parameter */
  static int __init sm7xx_vga_setup(char *options)
 -- 
 2.2.2
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH] hyper-v: allow access to vmbus from userspace driver

2015-02-03 Thread KY Srinivasan


 -Original Message-
 From: Stephen Hemminger [mailto:step...@networkplumber.org]
 Sent: Tuesday, February 3, 2015 11:04 AM
 To: KY Srinivasan; Haiyang Zhang
 Cc: de...@linuxdriverproject.org; net...@vger.kernel.org
 Subject: [PATCH] hyper-v: allow access to vmbus from userspace driver
 
 Brocade is submitting a hyper-v driver for DPDK d...@dpdk.org but this
 driver needs a hook in the hyper-v bus layer to allow the additional hv_uio
 driver to access the shared vmbus pages. The hv_uio driver lives in DPDK (like
 igb_uio) and provides userspace access to raw network packets.
 
 Signed-off-by: Stas Egorov sego...@mirantis.com
 Signed-off-by: Stephen Hemminger step...@networkplumber.org
 
 ---
  drivers/hv/connection.c |   20 +---
  include/linux/hyperv.h  |3 +++
  2 files changed, 20 insertions(+), 3 deletions(-)
 
 --- a/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
 +++ b/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
 @@ -64,6 +64,21 @@ static __u32 vmbus_get_next_version(__u3
   }
  }
 
 +static const uuid_le HV_NET_GUID = {
 + .b = {
 + 0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46,
 + 0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e
 + }
 +};
 +

We already have this guid defined in linux/hyperv.h; look at HV_NIC_GUID.
 
 +void vmbus_get_pages(unsigned long *int_page, unsigned long
 +monitor_pages[2]) {
 + *int_page = (unsigned long)vmbus_connection.int_page;
 + monitor_pages[0] = (unsigned
 long)vmbus_connection.monitor_pages[0];
 + monitor_pages[1] = (unsigned
 long)vmbus_connection.monitor_pages[1];
 +}
 +EXPORT_SYMBOL_GPL(vmbus_get_pages);
 +
  static int vmbus_negotiate_version(struct vmbus_channel_msginfo
 *msginfo,
   __u32 version)
  {
 @@ -347,7 +362,8 @@ static void process_chn_event(u32 relid)
   else
   bytes_to_read = 0;
   } while (read_state  (bytes_to_read != 0));
 - } else {
 + } else if (!memcmp(channel-device_obj-dev_type,
 HV_NET_GUID,
 +sizeof(uuid_le))) {
   pr_err(no channel callback for relid - %u\n, relid);
   }

I am not sure this message is all that useful. We may just get rid of the 
message.
If we get rid of this message, we can significantly simplify.

 
 --- a/include/linux/hyperv.h  2015-02-03 10:58:51.751752450 -0800
 +++ b/include/linux/hyperv.h  2015-02-03 10:58:51.751752450 -0800
 @@ -868,6 +868,9 @@ extern int vmbus_recvpacket_raw(struct v
 
  extern void vmbus_ontimer(unsigned long data);
 
 +extern void vmbus_get_pages(unsigned long *int_page,
 + unsigned long monitor_pages[2]);
 +
  /* Base driver object */
  struct hv_driver {
   const char *name;

Thanks,

K. Y
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] hyper-v: allow access to vmbus from userspace driver

2015-02-03 Thread Stephen Hemminger
Brocade is submitting a hyper-v driver for DPDK d...@dpdk.org
but this driver needs a hook in the hyper-v bus layer
to allow the additional hv_uio driver to access the shared vmbus
pages. The hv_uio driver lives in DPDK (like igb_uio) and provides
userspace access to raw network packets.

Signed-off-by: Stas Egorov sego...@mirantis.com
Signed-off-by: Stephen Hemminger step...@networkplumber.org

---
 drivers/hv/connection.c |   20 +---
 include/linux/hyperv.h  |3 +++
 2 files changed, 20 insertions(+), 3 deletions(-)

--- a/drivers/hv/connection.c   2015-02-03 10:58:51.751752450 -0800
+++ b/drivers/hv/connection.c   2015-02-03 10:58:51.751752450 -0800
@@ -64,6 +64,21 @@ static __u32 vmbus_get_next_version(__u3
}
 }
 
+static const uuid_le HV_NET_GUID = {
+   .b = {
+   0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46,
+   0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e
+   }
+};
+
+void vmbus_get_pages(unsigned long *int_page, unsigned long monitor_pages[2])
+{
+   *int_page = (unsigned long)vmbus_connection.int_page;
+   monitor_pages[0] = (unsigned long)vmbus_connection.monitor_pages[0];
+   monitor_pages[1] = (unsigned long)vmbus_connection.monitor_pages[1];
+}
+EXPORT_SYMBOL_GPL(vmbus_get_pages);
+
 static int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo,
__u32 version)
 {
@@ -347,7 +362,8 @@ static void process_chn_event(u32 relid)
else
bytes_to_read = 0;
} while (read_state  (bytes_to_read != 0));
-   } else {
+   } else if (!memcmp(channel-device_obj-dev_type, HV_NET_GUID,
+  sizeof(uuid_le))) {
pr_err(no channel callback for relid - %u\n, relid);
}
 
--- a/include/linux/hyperv.h2015-02-03 10:58:51.751752450 -0800
+++ b/include/linux/hyperv.h2015-02-03 10:58:51.751752450 -0800
@@ -868,6 +868,9 @@ extern int vmbus_recvpacket_raw(struct v
 
 extern void vmbus_ontimer(unsigned long data);
 
+extern void vmbus_get_pages(unsigned long *int_page,
+   unsigned long monitor_pages[2]);
+
 /* Base driver object */
 struct hv_driver {
const char *name;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: ft1000: fix braces warning

2015-02-03 Thread Bilel DRIRA
This patch fix the checkpatch.pl WARNING:

 WARNING: braces {} are not necessary for single statement blocks

Signed-off-by: Bilel DRIRA bilel...@gmail.com
---
 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c |   78 +-
 1 file changed, 31 insertions(+), 47 deletions(-)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 5e0cdcf26180..56da289de076 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -204,11 +204,11 @@ static inline void ft1000_write_dpram_mag_16(struct 
net_device *dev,
/* Provide mutual exclusive access while reading ASIC registers. */
spin_lock_irqsave(info-dpram_lock, flags);
ft1000_write_reg(dev, FT1000_REG_DPRAM_ADDR, offset);
-   if (Index) {
+   if (Index)
ft1000_write_reg(dev, FT1000_REG_MAG_DPDATAL, value);
-   } else {
+   else
ft1000_write_reg(dev, FT1000_REG_MAG_DPDATAH, value);
-   }
+
spin_unlock_irqrestore(info-dpram_lock, flags);
 }
 
@@ -440,9 +440,8 @@ static int ft1000_reset_card(struct net_device *dev)
tempword =
ft1000_read_dpram_mag_16(dev, 
FT1000_MAG_DPRAM_FEFE,
 
FT1000_MAG_DPRAM_FEFE_INDX);
-   if (tempword == 0xfefe) {
+   if (tempword == 0xfefe)
break;
-   }
mdelay(20);
}
 
@@ -621,9 +620,9 @@ static void ft1000_hbchk(u_long data)
 
tempword = ft1000_read_reg(dev, FT1000_REG_DOORBELL);
/* Let's check doorbell again if fail */
-   if (tempword  FT1000_DB_HB) {
+   if (tempword  FT1000_DB_HB)
tempword = ft1000_read_reg(dev, FT1000_REG_DOORBELL);
-   }
+
if (tempword  FT1000_DB_HB) {
pr_info(heartbeat doorbell not clear by firmware\n);
if (info-AsicID == ELECTRABUZZ_ID) {
@@ -766,9 +765,8 @@ static void ft1000_send_cmd(struct net_device *dev, u16 
*ptempbuffer, int size,
 
size += sizeof(struct pseudo_hdr);
/* check for odd byte and increment to 16-bit word align value */
-   if ((size  0x0001)) {
+   if ((size  0x0001))
size++;
-   }
pr_debug(total length = %d\n, size);
pr_debug(length = %d\n, ntohs(*ptempbuffer));
/*
@@ -911,9 +909,8 @@ static bool ft1000_receive_cmd(struct net_device *dev, u16 
*pbuffer,
 * Calculate pseudo header checksum
 */
tempword = *ppseudohdr++;
-   for (i = 1; i  7; i++) {
+   for (i = 1; i  7; i++)
tempword ^= *ppseudohdr++;
-   }
if ((tempword != *ppseudohdr)) {
pr_debug(Pseudo header checksum mismatch\n);
/* Drop this message */
@@ -977,9 +974,8 @@ static void ft1000_proc_drvmsg(struct net_device *dev)
while (tempword  FT1000_DB_DPRAM_TX) {
mdelay(5);
i++;
-   if (i == 10) {
+   if (i == 10)
break;
-   }
}
ptr =
list_entry(info-prov_list.next,
@@ -1099,9 +1095,8 @@ static void ft1000_proc_drvmsg(struct net_device *dev)
mdelay(10);
tempword =
ft1000_read_reg(dev, 
FT1000_REG_DOORBELL);
-   if (tempword  FT1000_DB_DPRAM_TX) {
+   if (tempword  FT1000_DB_DPRAM_TX)
mdelay(10);
-   }
}
 
if ((tempword  FT1000_DB_DPRAM_TX) == 0) {
@@ -1128,9 +1123,9 @@ static void ft1000_proc_drvmsg(struct net_device *dev)
ppseudo_hdr-portsrc = 0;
/* Calculate new checksum */
ppseudo_hdr-checksum = *pmsg++;
-   for (i = 1; i  7; i++) {
+   for (i = 1; i  7; i++)
ppseudo_hdr-checksum ^= *pmsg++;
-   }
+
info-DSPInfoBlk[8] = 0x7200;
info-DSPInfoBlk[9] =
htons(info-DSPInfoBlklen);
@@ -1150,9 +1145,8 @@ static void ft1000_proc_drvmsg(struct 

Re: [PATCH RFC] staging: comedi: dt282x: condition with no effect - if identical to else

2015-02-03 Thread Nicholas Mc Guire
On Tue, 03 Feb 2015, Ian Abbott wrote:

 On 03/02/15 12:38, Nicholas Mc Guire wrote:
 The if and the else branch code are identical - so the condition has no
 effect on the effective code - this patch removes the condition and the
 duplicated code.

 Signed-off-by: Nicholas Mc Guire hof...@osadl.org
 ---

 The if and else branch are identical code thus the condition has no effect

  if (cmd-scan_begin_src == TRIG_FOLLOW) {
  /* internal trigger */
  err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
  } else {
  /* external trigger */
  /* should be level/edge, hi/lo specification here */
  err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
  }

 As the comments indicate that they are serving different purposes this
 looks like a bug. In any case - if intentional - it would need some
 comments on why.

 This needs a review by someone that knows the details of this driver.
 Also not sure about the retained comment string if that is still valid now.

 Patch was only compile tested for x86_64_defconfig + CONFIG_STAGING=y
 CONFIG_COMEDI=m, COMEDI_ISA_DRIVERS=y, CONFIG_COMEDI_DT282X=m

 Patch is against 3.0.19-rc7 (localversion = -next-20150203)

   drivers/staging/comedi/drivers/dt282x.c |   10 ++
   1 file changed, 2 insertions(+), 8 deletions(-)

 diff --git a/drivers/staging/comedi/drivers/dt282x.c 
 b/drivers/staging/comedi/drivers/dt282x.c
 index 051dfb2..22c59e5 100644
 --- a/drivers/staging/comedi/drivers/dt282x.c
 +++ b/drivers/staging/comedi/drivers/dt282x.c
 @@ -685,14 +685,8 @@ static int dt282x_ai_cmdtest(struct comedi_device *dev,

  err |= cfc_check_trigger_arg_is(cmd-start_arg, 0);

 -if (cmd-scan_begin_src == TRIG_FOLLOW) {
 -/* internal trigger */
 -err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
 -} else {
 -/* external trigger */
 -/* should be level/edge, hi/lo specification here */

 I think what that comment means is that it should allow scan_begin_arg  
 to have various combinations of the CR_EDGE and CR_INVERT bits set. I.e. 
 it ought to allow whatever combination of CR_EDGE and CR_INVERT better 
 describes the nature of the external trigger signal, in addition to 
 allowing the lazy default value 0.

 I don't know what the nature of the external trigger signal is, as I  
 haven't seen the manual.  I think Hartley might have seen one.

 -err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);
 -}
 +/* internal trigger */

 That comment would be misleading as it could be an internal or external  
 trigger.


yup - was unsure on what to put there (if any).


 If you want to apply this patch, remove that comment first.  But I'd
 rather leave the existing code there as a reminder.


if that is the preferred solution maybe someone with suitable
knowledge could add a comment in the else case explaining why
it is the same or at least making it clear that it is an
intentional placeholder.

 +err |= cfc_check_trigger_arg_is(cmd-scan_begin_arg, 0);

  err |= cfc_check_trigger_arg_min(cmd-convert_arg, 4000);



thanks for your review comments!

thx!
hofrat

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 0/2] staging: ft1000-pcmcia: ft1000_hw.c: fix checkpatch warnings

2015-02-03 Thread Daniele Alessandrelli
This small patchset fixes all the style problems reported by checkpatch.pl on
ft1000-pcmcia/ft1000_hw.c

 * Patch 1/2 fixes all trivial issues not requiring code refactoring
 * Patch 2/2 fixes all remaining line over 80 characters warnings by means of
   some code refactoring. Specifically, the function ft1000_read_dsp_timer() is
   introduced to replace a recurring block of code used for reading the DSP
   timer value.


Daniele Alessandrelli (2):
  ft1000-pcmcia: ft1000_hw.c: fix style issues not requiring code
refactoring
  ft1000-pcmcia: ft1000_hw.c: code refactoring: add
ft1000_read_dsp_timer()

 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 660 ++-
 1 file changed, 270 insertions(+), 390 deletions(-)

-- 
1.8.3.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous bug fixes and cleanup

2015-02-03 Thread Greg KH
On Tue, Feb 03, 2015 at 07:31:36AM -0800, K. Y. Srinivasan wrote:
 This is a resend of the patches from Dexuan and Nicholas

What do you mean by resend?  Did you send them to be before?  I can't
see them in my inbox anywhere.

confused,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/2] ft1000-pcmcia: ft1000_hw.c: fix style issues not requiring code refactoring

2015-02-03 Thread Daniele Alessandrelli
Fix all the trivial style issues (as reported by checkpatch.pl) not requiring
code refactoring. A following patch is expected to fix the remaining issues by
performing some code refactoring.

Signed-off-by: Daniele Alessandrelli daniele.alessandre...@gmail.com
---
 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 521 +++
 1 file changed, 260 insertions(+), 261 deletions(-)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 3d81e1f..4f165cb 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -28,8 +28,8 @@
 #include linux/timer.h
 #include linux/interrupt.h
 #include linux/in.h
-#include asm/io.h
-#include asm/bitops.h
+#include linux/io.h
+#include linux/bitops.h
 
 #include linux/netdevice.h
 #include linux/etherdevice.h
@@ -67,8 +67,7 @@ static void ft1000_disable_interrupts(struct net_device *dev);
 
 /* new kernel */
 MODULE_AUTHOR();
-MODULE_DESCRIPTION
-(Support for Flarion Flash OFDM NIC Device. Support for PCMCIA when used with 
ft1000_cs.);
+MODULE_DESCRIPTION(Support for Flarion Flash OFDM NIC Device. Support for 
PCMCIA when used with ft1000_cs.);
 MODULE_LICENSE(GPL);
 MODULE_SUPPORTED_DEVICE(FT1000);
 
@@ -204,11 +203,10 @@ static inline void ft1000_write_dpram_mag_16(struct 
net_device *dev,
/* Provide mutual exclusive access while reading ASIC registers. */
spin_lock_irqsave(info-dpram_lock, flags);
ft1000_write_reg(dev, FT1000_REG_DPRAM_ADDR, offset);
-   if (Index) {
+   if (Index)
ft1000_write_reg(dev, FT1000_REG_MAG_DPDATAL, value);
-   } else {
+   else
ft1000_write_reg(dev, FT1000_REG_MAG_DPDATAH, value);
-   }
spin_unlock_irqrestore(info-dpram_lock, flags);
 }
 
@@ -267,7 +265,8 @@ void ft1000_write_dpram_mag_32(struct net_device *dev, int 
offset, u32 value)
 /*---
 
   Function:   ft1000_enable_interrupts
-  Description: This function will enable interrupts base on the current 
interrupt mask.
+  Description: This function will enable interrupts base on the current
+  interrupt mask.
   Input:
   dev- device structure
   Output:
@@ -375,7 +374,8 @@ static int ft1000_reset_card(struct net_device *dev)
/* Make sure we free any memory reserve for provisioning */
while (list_empty(info-prov_list) == 0) {
pr_debug(deleting provisioning record\n);
-   ptr = list_entry(info-prov_list.next, struct prov_record, 
list);
+   ptr = list_entry(info-prov_list.next, struct prov_record,
+list);
list_del(ptr-list);
kfree(ptr-pprov_data);
kfree(ptr);
@@ -406,7 +406,8 @@ static int ft1000_reset_card(struct net_device *dev)
 FT1000_DPRAM_MAG_RX_BASE);
for (i = 0; i  MAX_DSP_SESS_REC / 2; i++) {
info-DSPSess.MagRec[i] =
-   inl(dev-base_addr + 
FT1000_REG_MAG_DPDATA);
+   inl(dev-base_addr
+   + FT1000_REG_MAG_DPDATA);
}
}
spin_unlock_irqrestore(info-dpram_lock, flags);
@@ -435,14 +436,14 @@ static int ft1000_reset_card(struct net_device *dev)
mdelay(10);
pr_debug(Take DSP out of reset\n);
 
-   /* Wait for 0xfefe indicating dsp ready before starting 
download */
+   /* Wait for 0xfefe indicating dsp ready before starting
+* download */
for (i = 0; i  50; i++) {
-   tempword =
-   ft1000_read_dpram_mag_16(dev, 
FT1000_MAG_DPRAM_FEFE,
-
FT1000_MAG_DPRAM_FEFE_INDX);
-   if (tempword == 0xfefe) {
+   tempword = ft1000_read_dpram_mag_16(dev,
+   FT1000_MAG_DPRAM_FEFE,
+   FT1000_MAG_DPRAM_FEFE_INDX);
+   if (tempword == 0xfefe)
break;
-   }
mdelay(20);
}
 
@@ -460,16 +461,15 @@ static int ft1000_reset_card(struct net_device *dev)
if (card_download(dev, fw_entry-data, fw_entry-size)) {
pr_debug(card download unsuccessful\n);
return false;
-   } else {
-   pr_debug(card download successful\n);
}
+   pr_debug(card download successful\n);
 
mdelay(10);
 
if (info-AsicID == ELECTRABUZZ_ID) {
/*
-* Need to initialize the FIFO length counter to zero in 

[PATCH 2/2] ft1000-pcmcia: ft1000_hw.c: code refactoring: add ft1000_read_dsp_timer()

2015-02-03 Thread Daniele Alessandrelli
Add new function ft1000_read_dsp_timer() replacing recurring code block for
reading DSP timer. Such code refactoring solves all remaining line over 80
characters warnings reported by checkpatch.pl.

Signed-off-by: Daniele Alessandrelli daniele.alessandre...@gmail.com
---
 drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 197 +--
 1 file changed, 39 insertions(+), 158 deletions(-)

diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
index 4f165cb..538ec38f 100644
--- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
+++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
@@ -302,6 +302,39 @@ static void ft1000_disable_interrupts(struct net_device 
*dev)
 }
 
 /*---
+  Function:ft1000_read_dsp_timer
+  Description: This function reads the DSP timer and stores its value in the
+   DSP_TIME field of the ft1000_info struct passed as argument
+  Input:
+  info- ft1000_info structure
+  Output:
+  None.
+
+  -*/
+static void ft1000_read_dsp_timer(struct ft1000_info *info)
+{
+   if (info-AsicID == ELECTRABUZZ_ID) {
+   info-DSP_TIME[0] = ft1000_read_dpram(dev, FT1000_DSP_TIMER0);
+   info-DSP_TIME[1] = ft1000_read_dpram(dev, FT1000_DSP_TIMER1);
+   info-DSP_TIME[2] = ft1000_read_dpram(dev, FT1000_DSP_TIMER2);
+   info-DSP_TIME[3] = ft1000_read_dpram(dev, FT1000_DSP_TIMER3);
+   } else {
+   info-DSP_TIME[0] =
+   ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER0,
+FT1000_MAG_DSP_TIMER0_INDX);
+   info-DSP_TIME[1] =
+   ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER1,
+FT1000_MAG_DSP_TIMER1_INDX);
+   info-DSP_TIME[2] =
+   ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER2,
+FT1000_MAG_DSP_TIMER2_INDX);
+   info-DSP_TIME[3] =
+   ft1000_read_dpram_mag_16(dev, FT1000_MAG_DSP_TIMER3,
+FT1000_MAG_DSP_TIMER3_INDX);
+   }
+}
+
+/*---
 
   Function:   ft1000_reset_asic
   Description: This function will call the Card Service function to reset the
@@ -579,33 +612,7 @@ static void ft1000_hbchk(u_long data)
}
if (tempword != ho) {
pr_info(heartbeat failed - no ho detected\n);
-   if (info-AsicID == ELECTRABUZZ_ID) {
-   info-DSP_TIME[0] =
-   ft1000_read_dpram(dev, 
FT1000_DSP_TIMER0);
-   info-DSP_TIME[1] =
-   ft1000_read_dpram(dev, 
FT1000_DSP_TIMER1);
-   info-DSP_TIME[2] =
-   ft1000_read_dpram(dev, 
FT1000_DSP_TIMER2);
-   info-DSP_TIME[3] =
-   ft1000_read_dpram(dev, 
FT1000_DSP_TIMER3);
-   } else {
-   info-DSP_TIME[0] =
-   ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER0,
-
FT1000_MAG_DSP_TIMER0_INDX);
-   info-DSP_TIME[1] =
-   ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER1,
-
FT1000_MAG_DSP_TIMER1_INDX);
-   info-DSP_TIME[2] =
-   ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER2,
-
FT1000_MAG_DSP_TIMER2_INDX);
-   info-DSP_TIME[3] =
-   ft1000_read_dpram_mag_16(dev,
-
FT1000_MAG_DSP_TIMER3,
-
FT1000_MAG_DSP_TIMER3_INDX);
-   }
+   ft1000_read_dsp_timer(info);
info-DrvErrNum = DSP_HB_INFO;
if (ft1000_reset_card(dev) == 0) {
pr_info(Hardware Failure Detected - PC Card 
disabled\n);
@@ -625,33 +632,7 @@ static void ft1000_hbchk(u_long data)
tempword = 

Re: [PATCH RESEND V2 0/8] Drivers: hv: vmbus: Enable unloading of vmbus driver

2015-02-03 Thread Greg KH
On Wed, Jan 28, 2015 at 04:49:20PM -0800, K. Y. Srinivasan wrote:
 Windows hosts starting with Ws2012 R2 permit re-establishing the vmbus
 connection from the guest. This patch-set includes patches from Vitaly
 to cleanup the VMBUS unload path so we can potentially reload the driver.
 
 This set also includes a patch from Jake to correctly extract MMIO
 information on both Gen1 and Gen 2 firmware.

What changed from v1 of this series?

Please refresh your patch series and send _all_ patches that need to be
applied, I see 2 different series, and a few random patches sent out,
with no specific order, so I don't know what to do here :(

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging: ft1000: fix braces warning

2015-02-03 Thread Joe Perches
On Tue, 2015-02-03 at 21:05 +0100, bill wrote:
 Ok,thank you, I will do that and resend the patch again.

I wouldn't.
It's probably better as a separate patch anyway.

btw: please don't top post.

cheers, Joe

 On Tue, Feb 03, 2015 at 11:05:08AM -0800, Joe Perches wrote:
  On Tue, 2015-02-03 at 19:58 +0100, Bilel DRIRA wrote:
   This patch fix the checkpatch.pl WARNING:
  []
   diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c 
   b/drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c
  []
   @@ -1963,11 +1948,10 @@ static irqreturn_t ft1000_interrupt(int irq, void 
   *dev_id)
[]
  trivia: the logic here is generally better inverted:


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH RESEND V2 0/8] Drivers: hv: vmbus: Enable unloading of vmbus driver

2015-02-03 Thread KY Srinivasan


 -Original Message-
 From: Greg KH [mailto:gre...@linuxfoundation.org]
 Sent: Tuesday, February 3, 2015 3:47 PM
 To: KY Srinivasan
 Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
 o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
 t...@linutronix.de
 Subject: Re: [PATCH RESEND V2 0/8] Drivers: hv: vmbus: Enable unloading of
 vmbus driver
 
 On Wed, Jan 28, 2015 at 04:49:20PM -0800, K. Y. Srinivasan wrote:
  Windows hosts starting with Ws2012 R2 permit re-establishing the vmbus
  connection from the guest. This patch-set includes patches from Vitaly
  to cleanup the VMBUS unload path so we can potentially reload the driver.
 
  This set also includes a patch from Jake to correctly extract MMIO
  information on both Gen1 and Gen 2 firmware.
 
 What changed from v1 of this series?
 
 Please refresh your patch series and send _all_ patches that need to be
 applied, I see 2 different series, and a few random patches sent out, with no
 specific order, so I don't know what to do here :(

Ok; I will resend the entire set. Do you want me to keep the RESEND tag. 

Regards,

K. Y
 
 thanks,
 
 greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous bug fixes and cleanup

2015-02-03 Thread KY Srinivasan


 -Original Message-
 From: Greg KH [mailto:gre...@linuxfoundation.org]
 Sent: Tuesday, February 3, 2015 4:01 PM
 To: KY Srinivasan
 Cc: a...@canonical.com; de...@linuxdriverproject.org; o...@aepfle.de;
 linux-ker...@vger.kernel.org
 Subject: Re: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous
 bug fixes and cleanup
 
 On Tue, Feb 03, 2015 at 11:51:53PM +, KY Srinivasan wrote:
 
 
   -Original Message-
   From: Greg KH [mailto:gre...@linuxfoundation.org]
   Sent: Tuesday, February 3, 2015 3:45 PM
   To: KY Srinivasan
   Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
   o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
   Subject: Re: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some
   miscellaneous bug fixes and cleanup
  
   On Tue, Feb 03, 2015 at 07:31:36AM -0800, K. Y. Srinivasan wrote:
This is a resend of the patches from Dexuan and Nicholas
  
   What do you mean by resend?  Did you send them to be before?  I
   can't see them in my inbox anywhere.
  
   confused,
 
  Greg,
 
  You had asked me to resend patches after reviewing them and making
  sure they applied cleanly. These patches were posted on LKML earlier; I
 resent them.
 
 But I didn't know that, as you hadn't sent them to me before.
 
 Please collect all hyperv patches and send them to me in batches like other
 subsystem maintainers do, it makes it easier for me as I'm obviously easy to
 get confused here...

Will do.

K. Y
 
 thanks,
 
 greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous bug fixes and cleanup

2015-02-03 Thread Greg KH
On Tue, Feb 03, 2015 at 11:51:53PM +, KY Srinivasan wrote:
 
 
  -Original Message-
  From: Greg KH [mailto:gre...@linuxfoundation.org]
  Sent: Tuesday, February 3, 2015 3:45 PM
  To: KY Srinivasan
  Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
  o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
  Subject: Re: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous
  bug fixes and cleanup
  
  On Tue, Feb 03, 2015 at 07:31:36AM -0800, K. Y. Srinivasan wrote:
   This is a resend of the patches from Dexuan and Nicholas
  
  What do you mean by resend?  Did you send them to be before?  I can't
  see them in my inbox anywhere.
  
  confused,
 
 Greg,
 
 You had asked me to resend patches after reviewing them and making sure they 
 applied cleanly. These patches
 were posted on LKML earlier; I resent them.

But I didn't know that, as you hadn't sent them to me before.

Please collect all hyperv patches and send them to me in batches like
other subsystem maintainers do, it makes it easier for me as I'm
obviously easy to get confused here...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous bug fixes and cleanup

2015-02-03 Thread KY Srinivasan


 -Original Message-
 From: Greg KH [mailto:gre...@linuxfoundation.org]
 Sent: Tuesday, February 3, 2015 3:45 PM
 To: KY Srinivasan
 Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
 o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com
 Subject: Re: [PATCH RESEND 0/6] Drivers: hv: vmbus: Some miscellaneous
 bug fixes and cleanup
 
 On Tue, Feb 03, 2015 at 07:31:36AM -0800, K. Y. Srinivasan wrote:
  This is a resend of the patches from Dexuan and Nicholas
 
 What do you mean by resend?  Did you send them to be before?  I can't
 see them in my inbox anywhere.
 
 confused,

Greg,

You had asked me to resend patches after reviewing them and making sure they 
applied cleanly. These patches
were posted on LKML earlier; I resent them.

K. Y 
 
 greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH RESEND V2 0/8] Drivers: hv: vmbus: Enable unloading of vmbus driver

2015-02-03 Thread Greg KH
On Tue, Feb 03, 2015 at 11:57:18PM +, KY Srinivasan wrote:
 
 
  -Original Message-
  From: Greg KH [mailto:gre...@linuxfoundation.org]
  Sent: Tuesday, February 3, 2015 3:47 PM
  To: KY Srinivasan
  Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
  o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com;
  t...@linutronix.de
  Subject: Re: [PATCH RESEND V2 0/8] Drivers: hv: vmbus: Enable unloading of
  vmbus driver
  
  On Wed, Jan 28, 2015 at 04:49:20PM -0800, K. Y. Srinivasan wrote:
   Windows hosts starting with Ws2012 R2 permit re-establishing the vmbus
   connection from the guest. This patch-set includes patches from Vitaly
   to cleanup the VMBUS unload path so we can potentially reload the driver.
  
   This set also includes a patch from Jake to correctly extract MMIO
   information on both Gen1 and Gen 2 firmware.
  
  What changed from v1 of this series?
  
  Please refresh your patch series and send _all_ patches that need to be
  applied, I see 2 different series, and a few random patches sent out, with 
  no
  specific order, so I don't know what to do here :(
 
 Ok; I will resend the entire set. Do you want me to keep the RESEND tag. 

If you use the vX numbering scheme, it doesn't make much sense, right?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH] hyper-v: allow access to vmbus from userspace driver

2015-02-03 Thread KY Srinivasan


 -Original Message-
 From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
 Behalf Of KY Srinivasan
 Sent: Tuesday, February 3, 2015 11:24 AM
 To: Stephen Hemminger; Haiyang Zhang
 Cc: de...@linuxdriverproject.org; net...@vger.kernel.org
 Subject: RE: [PATCH] hyper-v: allow access to vmbus from userspace driver
 
 
 
  -Original Message-
  From: Stephen Hemminger [mailto:step...@networkplumber.org]
  Sent: Tuesday, February 3, 2015 11:04 AM
  To: KY Srinivasan; Haiyang Zhang
  Cc: de...@linuxdriverproject.org; net...@vger.kernel.org
  Subject: [PATCH] hyper-v: allow access to vmbus from userspace driver
 
  Brocade is submitting a hyper-v driver for DPDK d...@dpdk.org but
  this driver needs a hook in the hyper-v bus layer to allow the
  additional hv_uio driver to access the shared vmbus pages. The hv_uio
  driver lives in DPDK (like
  igb_uio) and provides userspace access to raw network packets.
 
  Signed-off-by: Stas Egorov sego...@mirantis.com
  Signed-off-by: Stephen Hemminger step...@networkplumber.org
 
  ---
   drivers/hv/connection.c |   20 +---
   include/linux/hyperv.h  |3 +++
   2 files changed, 20 insertions(+), 3 deletions(-)
 
  --- a/drivers/hv/connection.c   2015-02-03 10:58:51.751752450 -0800
  +++ b/drivers/hv/connection.c   2015-02-03 10:58:51.751752450 -0800
  @@ -64,6 +64,21 @@ static __u32 vmbus_get_next_version(__u3
  }
   }
 
  +static const uuid_le HV_NET_GUID = {
  +   .b = {
  +   0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46,
  +   0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e
  +   }
  +};
  +
 
 We already have this guid defined in linux/hyperv.h; look at HV_NIC_GUID.
 
  +void vmbus_get_pages(unsigned long *int_page, unsigned long
  +monitor_pages[2]) {
  +   *int_page = (unsigned long)vmbus_connection.int_page;
  +   monitor_pages[0] = (unsigned
  long)vmbus_connection.monitor_pages[0];
  +   monitor_pages[1] = (unsigned
  long)vmbus_connection.monitor_pages[1];
  +}
  +EXPORT_SYMBOL_GPL(vmbus_get_pages);

vmbus_get_pages() is too generic. Perhaps vmbus_get_monitor_pages() may be a 
better
name for this function.

Regards,

K. Y
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] staging/fwserial: use correct vendor/version IDs

2015-02-03 Thread Stefan Richter
On Feb 03 Peter Hurley wrote:
 On 02/03/2015 03:44 AM, Stefan Richter wrote:
  On Feb 02 Peter Hurley wrote:
[...]
  The problem is a host with the old OUIs will not recognize a remote
  unit with the new OUIs, and vice versa.
 
  Even though the new ids could be added to the unit driver's id_table,
  (which would let hosts with the new OUI connect to either OUI remote),
  it wouldn't let 3.19- hosts connect to 3.20+ hosts.
  
  Actually there are no 3.19- hosts that speak fwserial; there are only
  staging hosts that do so.  So, with this patch added, certain staging
  hosts would become unable to talk with certain other staging hosts (and
  with future Linux hosts, once fwserial gets merged upstream).
 
 The breakage seems gratuitous especially considering the existing OUI
 has been in use for a decade.

This ID has never been in use to identify the specifier of a unit
architecture though, nor has it been used otherwise in any protocol.
And the way how the ID /was/ used doesn't make it an OUI.

[Since 7.5 years ago the new firewire-core puts a fixed, unregistered
value into the config ROM's root dir's vendor ID leaf, whereas until
4 years ago ieee1394 has been copying the upper 24 bits of the node's
EUI-64 there.  Years counted according to mainline Linux releases.
As another historical note, 7.5 years ago the occupied OUI space consisted
of 10456 IDs from 0…acde48, now it is 19896 IDs from 0…fcffaa.]

  Both fwserial-the-implementation and fwserial-the-protocol are your own,
  and as yet unmerged.
 
 I've been waiting for you to work through the patch backlog from Feb and
 Mar of last year before sending you more patches to merge fwserial.

If there is one or another patch among them which directly blocks your
work on fwserial, ping me so that I can reconsider priorities.  Though if
you were just expressing dissatisfaction with the subsystem's maintenance
progress, well, then that's noted and quite agreed.

   (In addition, there does not yet exist a second
  implementation, AFAIK.)  So I'd say there is still opportunity to improve
  the protocol even in incompatible ways if justified.  Switching to
  valid identifiers may very well be such a justifiable change.
 
 I would appreciate you sharing any suggestions for improving the protocol.
 
 While I concede the protocol is not perfect, I'm struggling to see how
 changing the OUI improves it.

The difference of course is nothing more than that the interoperability of
the specifier_ID:software_version tuple either depends on made-up IDs, or
on IDs whose uniqueness is based on a proper chain of registrations.
-- 
Stefan Richter
-=-= --=- ---==
http://arcgraph.de/sr/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 00/16] Drivers: hv: vmbus: Miscellaneous fixes/enhancements

2015-02-03 Thread K. Y. Srinivasan
Windows hosts starting with Ws2012 R2 permit re-establishing the vmbus 
connection from the guest. This patch-set includes patches from Vitaly 
to cleanup the VMBUS unload path so we can potentially reload the driver.
 
This set also includes a patch from Jake to correctly extract MMIO 
information on both Gen1 and Gen 2 firmware.
Also included here are some bug fixes from Dexuan and me. 


Dexuan Cui (3):
  hv: hv_util: move vmbus_open() to a later place
  hv: vmbus_post_msg: retry the hypercall on some transient errors
  hv: vmbus_open(): reset the channel state on ENOMEM

Jake Oshins (1):
  drivers:hv:vmbus drivers:hv:vmbus Allow for more than one MMIO range
for children

K. Y. Srinivasan (2):
  Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()
  Drivers: hv: vmbus: Add support for the NetworkDirect GUID

Nicholas Mc Guire (3):
  hv: channel: match var type to return type of wait_for_completion
  hv: channel_mgmt: match var type to return type of
wait_for_completion
  hv: hv_balloon: match var type to return type of wait_for_completion

Vitaly Kuznetsov (7):
  Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors
  Drivers: hv: vmbus: rename channel work queues
  Drivers: hv: vmbus: avoid double kfree for device_obj
  Drivers: hv: vmbus: teardown hv_vmbus_con workqueue and
vmbus_connection pages on shutdown
  drivers: hv: vmbus: Teardown synthetic interrupt controllers on
module unload
  clockevents: export clockevents_unbind_device instead of
clockevents_unbind
  Drivers: hv: vmbus: Teardown clockevent devices on module unload

 arch/x86/include/uapi/asm/hyperv.h |2 +
 drivers/hv/channel.c   |   18 +++--
 drivers/hv/channel_mgmt.c  |   11 ++-
 drivers/hv/connection.c|   28 +--
 drivers/hv/hv.c|   34 +++-
 drivers/hv/hv_balloon.c|3 +-
 drivers/hv/hv_util.c   |   11 ++-
 drivers/hv/hyperv_vmbus.h  |3 +
 drivers/hv/vmbus_drv.c |  153 +++-
 drivers/video/fbdev/hyperv_fb.c|2 +-
 include/linux/hyperv.h |   15 +++-
 kernel/time/clockevents.c  |2 +-
 12 files changed, 235 insertions(+), 47 deletions(-)

-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 03/16] drivers:hv:vmbus drivers:hv:vmbus Allow for more than one MMIO range for children

2015-02-03 Thread K. Y. Srinivasan
From: Jake Oshins [mailto:ja...@microsoft.com]

This set of changes finds the _CRS object in the ACPI namespace
that contains memory address space descriptors, intended to convey
to VMBus which ranges of memory-mapped I/O space are available for
child devices, and then builds a resource list that contains all
those ranges.  Without this change, only some of the memory-mapped
I/O space will be available for child devices, and only in some
virtual BIOS configurations (Generation 2 VMs).

This patch has been updated with feedback from Vitaly Kuznetsov.
Cleanup is now driven by the acpi remove callback function.

Signed-off-by: Jake Oshins ja...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/vmbus_drv.c  |  100 +--
 drivers/video/fbdev/hyperv_fb.c |2 +-
 include/linux/hyperv.h  |2 +-
 3 files changed, 87 insertions(+), 17 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 4e3760c..1fb8db0 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -45,10 +45,7 @@ static struct tasklet_struct msg_dpc;
 static struct completion probe_event;
 static int irq;
 
-struct resource hyperv_mmio = {
-   .name  = hyperv mmio,
-   .flags = IORESOURCE_MEM,
-};
+struct resource *hyperv_mmio;
 EXPORT_SYMBOL_GPL(hyperv_mmio);
 
 static int vmbus_exists(void)
@@ -915,30 +912,98 @@ void vmbus_device_unregister(struct hv_device *device_obj)
 
 
 /*
- * VMBUS is an acpi enumerated device. Get the the information we
- * need from DSDT.
+ * VMBUS is an acpi enumerated device. Get the
+ * information we need from DSDT.
  */
 
 static acpi_status vmbus_walk_resources(struct acpi_resource *res, void *ctx)
 {
+   resource_size_t start = 0;
+   resource_size_t end = 0;
+   struct resource *new_res;
+   struct resource **old_res = hyperv_mmio;
+
switch (res-type) {
case ACPI_RESOURCE_TYPE_IRQ:
irq = res-data.irq.interrupts[0];
+   return AE_OK;
+
+   /*
+* Address descriptors are for bus windows. Ignore
+* memory descriptors, which are for registers on
+* devices.
+*/
+   case ACPI_RESOURCE_TYPE_ADDRESS32:
+   start = res-data.address32.minimum;
+   end = res-data.address32.maximum;
break;
 
case ACPI_RESOURCE_TYPE_ADDRESS64:
-   hyperv_mmio.start = res-data.address64.minimum;
-   hyperv_mmio.end = res-data.address64.maximum;
+   start = res-data.address64.minimum;
+   end = res-data.address64.maximum;
break;
+
+   default:
+   /* Unused resource type */
+   return AE_OK;
}
 
+   /*
+* Ignore ranges that are below 1MB, as they're not
+* necessary or useful here.
+*/
+   if (end  0x10)
+   return AE_OK;
+
+   new_res = kzalloc(sizeof(*new_res), GFP_ATOMIC);
+   if (!new_res)
+   return AE_NO_MEMORY;
+
+   new_res-name = hyperv mmio;
+   new_res-flags = IORESOURCE_MEM;
+   new_res-start = start;
+   new_res-end = end;
+
+   do {
+   if (!*old_res) {
+   *old_res = new_res;
+   break;
+   }
+
+   if ((*old_res)-start  new_res-end) {
+   new_res-sibling = *old_res;
+   *old_res = new_res;
+   break;
+   }
+
+   old_res = (*old_res)-sibling;
+
+   } while (1);
+
return AE_OK;
 }
 
+static int vmbus_acpi_remove(struct acpi_device *device)
+{
+   struct resource *cur_res;
+   struct resource *next_res;
+
+   if (hyperv_mmio) {
+   release_resource(hyperv_mmio);
+   for (cur_res = hyperv_mmio; cur_res; cur_res = next_res) {
+   next_res = cur_res-sibling;
+   kfree(cur_res);
+   }
+   }
+
+   return 0;
+}
+
 static int vmbus_acpi_add(struct acpi_device *device)
 {
acpi_status result;
int ret_val = -ENODEV;
+   struct acpi_device *ancestor;
 
hv_acpi_dev = device;
 
@@ -948,23 +1013,27 @@ static int vmbus_acpi_add(struct acpi_device *device)
if (ACPI_FAILURE(result))
goto acpi_walk_err;
/*
-* The parent of the vmbus acpi device (Gen2 firmware) is the VMOD that
-* has the mmio ranges. Get that.
+* Some ancestor of the vmbus acpi device (Gen1 or Gen2
+* firmware) is the VMOD that has the mmio ranges. Get that.
 */
-   if (device-parent) {
-   result = acpi_walk_resources(device-parent-handle,
+   for (ancestor = device-parent; ancestor; ancestor = ancestor-parent) {
+   result = acpi_walk_resources(ancestor-handle,
METHOD_NAME__CRS,
 

[PATCH 12/16] hv: channel: match var type to return type of wait_for_completion

2015-02-03 Thread K. Y. Srinivasan
From: Nicholas Mc Guire der.h...@hofr.at

return type of wait_for_completion_timeout is unsigned long not int, this
patch changes the type of t from int to unsigned long.

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 26dcf26..f687995 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -71,7 +71,8 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
struct vmbus_channel_msginfo *open_info = NULL;
void *in, *out;
unsigned long flags;
-   int ret, t, err = 0;
+   int ret, err = 0;
+   unsigned long t;
 
spin_lock_irqsave(newchannel-lock, flags);
if (newchannel-state == CHANNEL_OPEN_STATE) {
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 05/16] Drivers: hv: vmbus: teardown hv_vmbus_con workqueue and vmbus_connection pages on shutdown

2015-02-03 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]

We need to destroy hv_vmbus_con on module shutdown, otherwise the following
crash is sometimes observed:

[   76.569845] hv_vmbus: Hyper-V Host Build:9600-6.3-17-0.17039; Vmbus 
version:3.0
[   82.598859] BUG: unable to handle kernel paging request at a0003480
[   82.599287] IP: [a0003480] 0xa0003480
[   82.599287] PGD 1f34067 PUD 1f35063 PMD 3f72d067 PTE 0
[   82.599287] Oops: 0010 [#1] SMP
[   82.599287] Modules linked in: [last unloaded: hv_vmbus]
[   82.599287] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 
3.19.0-rc5_bug923184+ #488
[   82.599287] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
[   82.599287] Workqueue: hv_vmbus_con 0xa0003480
[   82.599287] task: 88007b6ddfa0 ti: 88007f8f8000 task.ti: 
88007f8f8000
[   82.599287] RIP: 0010:[a0003480]  [a0003480] 
0xa0003480
[   82.599287] RSP: 0018:88007f8fbe00  EFLAGS: 00010202
...

To avoid memory leaks we need to free monitor_pages and int_page for
vmbus_connection. Implement vmbus_disconnect() function by separating cleanup
path from vmbus_connect().

As we use hv_vmbus_con to release channels (see free_channel() in 
channel_mgmt.c)
we need to make sure the work was done before we remove the queue, do that with
drain_workqueue(). We also need to avoid handling messages  which can 
(potentially)
create new channels, so set vmbus_connection.conn_state = DISCONNECTED at the 
very
beginning of vmbus_exit() and check for that in vmbus_onmessage_work().

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/connection.c   |   17 -
 drivers/hv/hyperv_vmbus.h |1 +
 drivers/hv/vmbus_drv.c|6 ++
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index a63a795..c4acd1c 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -216,10 +216,21 @@ int vmbus_connect(void)
 
 cleanup:
pr_err(Unable to connect to host\n);
+
vmbus_connection.conn_state = DISCONNECTED;
+   vmbus_disconnect();
+
+   kfree(msginfo);
+
+   return ret;
+}
 
-   if (vmbus_connection.work_queue)
+void vmbus_disconnect(void)
+{
+   if (vmbus_connection.work_queue) {
+   drain_workqueue(vmbus_connection.work_queue);
destroy_workqueue(vmbus_connection.work_queue);
+   }
 
if (vmbus_connection.int_page) {
free_pages((unsigned long)vmbus_connection.int_page, 0);
@@ -230,10 +241,6 @@ cleanup:
free_pages((unsigned long)vmbus_connection.monitor_pages[1], 0);
vmbus_connection.monitor_pages[0] = NULL;
vmbus_connection.monitor_pages[1] = NULL;
-
-   kfree(msginfo);
-
-   return ret;
 }
 
 /*
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 44b1c94..6cf2de9 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -692,6 +692,7 @@ void vmbus_free_channels(void);
 /* Connection interface */
 
 int vmbus_connect(void);
+void vmbus_disconnect(void);
 
 int vmbus_post_msg(void *buffer, size_t buflen);
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 1fb8db0..f824c08 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -571,6 +571,10 @@ static void vmbus_onmessage_work(struct work_struct *work)
 {
struct onmessage_work_context *ctx;
 
+   /* Do not process messages if we're in DISCONNECTED state */
+   if (vmbus_connection.conn_state == DISCONNECTED)
+   return;
+
ctx = container_of(work, struct onmessage_work_context,
   work);
vmbus_onmessage(ctx-msg);
@@ -1095,12 +1099,14 @@ cleanup:
 
 static void __exit vmbus_exit(void)
 {
+   vmbus_connection.conn_state = DISCONNECTED;
hv_remove_vmbus_irq();
vmbus_free_channels();
bus_unregister(hv_bus);
hv_cleanup();
acpi_bus_unregister_driver(vmbus_acpi_driver);
hv_cpu_hotplug_quirk(false);
+   vmbus_disconnect();
 }
 
 
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 07/16] clockevents: export clockevents_unbind_device instead of clockevents_unbind

2015-02-03 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]

It looks like clockevents_unbind is being exported by mistake as:
- it is static;
- it is not listed in include/linux/clockchips.h;
- EXPORT_SYMBOL_GPL(clockevents_unbind) follows clockevents_unbind_device()
  implementation.

I think clockevents_unbind_device should be exported instead. This is going to
be used to teardown Hyper-V clockevent devices on module unload.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 kernel/time/clockevents.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 5544990..888ecc1 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -371,7 +371,7 @@ int clockevents_unbind_device(struct clock_event_device 
*ced, int cpu)
mutex_unlock(clockevents_mutex);
return ret;
 }
-EXPORT_SYMBOL_GPL(clockevents_unbind);
+EXPORT_SYMBOL_GPL(clockevents_unbind_device);
 
 /**
  * clockevents_register_device - register a clock event device
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 06/16] drivers: hv: vmbus: Teardown synthetic interrupt controllers on module unload

2015-02-03 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]

SynIC has to be switched off when we unload the module, otherwise registered
memory pages can get corrupted after (as Hyper-V host still writes there) and
we see the following crashes for random processes:

[   89.116774] BUG: Bad page map in process sh  pte:4989c716 pmd:36f81067
[   89.159454] addr:00437000 vm_flags:0875 anon_vma:  
(null) mapping:88007bba55a0 index:37
[   89.226146] vma-vm_ops-fault: filemap_fault+0x0/0x410
[   89.257776] vma-vm_file-f_op-mmap: generic_file_mmap+0x0/0x60
[   89.297570] CPU: 0 PID: 215 Comm: sh Tainted: GB  
3.19.0-rc5_bug923184+ #488
[   89.353738] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090006  05/23/2012
[   89.409138]   4e083d7b 880036e9fa18 
81a68d31
[   89.468724]   00437000 880036e9fa68 
811a1e3a
[   89.519233]  4989c716 0037 ea0001edc340 
00437000
[   89.575751] Call Trace:
[   89.591060]  [81a68d31] dump_stack+0x45/0x57
[   89.625164]  [811a1e3a] print_bad_pte+0x1aa/0x250
[   89.667234]  [811a2c95] vm_normal_page+0x55/0xa0
[   89.703818]  [811a3105] unmap_page_range+0x425/0x8a0
[   89.737982]  [811a3601] unmap_single_vma+0x81/0xf0
[   89.780385]  [81184320] ? lru_deactivate_fn+0x190/0x190
[   89.820130]  [811a4131] unmap_vmas+0x51/0xa0
[   89.860168]  [811ad12c] exit_mmap+0xac/0x1a0
[   89.890588]  [810763c3] mmput+0x63/0x100
[   89.919205]  [811eba48] flush_old_exec+0x3f8/0x8b0
[   89.962135]  [8123b5bb] load_elf_binary+0x32b/0x1260
[   89.998581]  [811a14f2] ? get_user_pages+0x52/0x60

hv_synic_cleanup() function exists but noone calls it now. Do the following:
- call hv_synic_cleanup() on each cpu from vmbus_exit();
- write global disable bit through MSR;
- use hv_synic_free_cpu() to avoid memory leask and code duplication.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/hv.c|9 +++--
 drivers/hv/vmbus_drv.c |4 
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 50e51a5..39531dc 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -477,6 +477,7 @@ void hv_synic_cleanup(void *arg)
union hv_synic_sint shared_sint;
union hv_synic_simp simp;
union hv_synic_siefp siefp;
+   union hv_synic_scontrol sctrl;
int cpu = smp_processor_id();
 
if (!hv_context.synic_initialized)
@@ -502,6 +503,10 @@ void hv_synic_cleanup(void *arg)
 
wrmsrl(HV_X64_MSR_SIEFP, siefp.as_uint64);
 
-   free_page((unsigned long)hv_context.synic_message_page[cpu]);
-   free_page((unsigned long)hv_context.synic_event_page[cpu]);
+   /* Disable the global synic bit */
+   rdmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64);
+   sctrl.enable = 0;
+   wrmsrl(HV_X64_MSR_SCONTROL, sctrl.as_uint64);
+
+   hv_synic_free_cpu(cpu);
 }
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index f824c08..28d19e8 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1099,11 +1099,15 @@ cleanup:
 
 static void __exit vmbus_exit(void)
 {
+   int cpu;
+
vmbus_connection.conn_state = DISCONNECTED;
hv_remove_vmbus_irq();
vmbus_free_channels();
bus_unregister(hv_bus);
hv_cleanup();
+   for_each_online_cpu(cpu)
+   smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1);
acpi_bus_unregister_driver(vmbus_acpi_driver);
hv_cpu_hotplug_quirk(false);
vmbus_disconnect();
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 10/16] hv: vmbus_post_msg: retry the hypercall on some transient errors

2015-02-03 Thread K. Y. Srinivasan
From: Dexuan Cui [mailto:de...@microsoft.com]

I got HV_STATUS_INVALID_CONNECTION_ID on Hyper-V 2008 R2 when keeping running
rmmod hv_netvsc; modprobe hv_netvsc; rmmod hv_utils; modprobe hv_utils
in a Linux guest. Looks the host has some kind of throttling mechanism if
some kinds of hypercalls are sent too frequently.
Without the patch, the driver can occasionally fail to load.

Also let's retry HV_STATUS_INSUFFICIENT_MEMORY, though we didn't get it
before.

Removed 'case -ENOMEM', since the hypervisor doesn't return this.

CC: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Jason Wang jasow...@redhat.com
Signed-off-by: Dexuan Cui de...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 arch/x86/include/uapi/asm/hyperv.h |2 ++
 drivers/hv/connection.c|   11 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/uapi/asm/hyperv.h 
b/arch/x86/include/uapi/asm/hyperv.h
index 90c458e..ce6068d 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -225,6 +225,8 @@
 #define HV_STATUS_INVALID_HYPERCALL_CODE   2
 #define HV_STATUS_INVALID_HYPERCALL_INPUT  3
 #define HV_STATUS_INVALID_ALIGNMENT4
+#define HV_STATUS_INSUFFICIENT_MEMORY  11
+#define HV_STATUS_INVALID_CONNECTION_ID18
 #define HV_STATUS_INSUFFICIENT_BUFFERS 19
 
 typedef struct _HV_REFERENCE_TSC_PAGE {
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index c4acd1c..af2388f 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -440,9 +440,16 @@ int vmbus_post_msg(void *buffer, size_t buflen)
ret = hv_post_message(conn_id, 1, buffer, buflen);
 
switch (ret) {
+   case HV_STATUS_INVALID_CONNECTION_ID:
+   /*
+* We could get this if we send messages too
+* frequently.
+*/
+   ret = -EAGAIN;
+   break;
+   case HV_STATUS_INSUFFICIENT_MEMORY:
case HV_STATUS_INSUFFICIENT_BUFFERS:
ret = -ENOMEM;
-   case -ENOMEM:
break;
case HV_STATUS_SUCCESS:
return ret;
@@ -452,7 +459,7 @@ int vmbus_post_msg(void *buffer, size_t buflen)
}
 
retries++;
-   msleep(100);
+   msleep(1000);
}
return ret;
 }
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 04/16] Drivers: hv: vmbus: avoid double kfree for device_obj

2015-02-03 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]

On driver shutdown device_obj is being freed twice:
1) In vmbus_free_channels()
2) vmbus_device_release() (which is being triggered by device_unregister() in
   vmbus_device_unregister().
This double kfree leads to the following sporadic crash on driver unload:

[   23.469876] general protection fault:  [#1] SMP
[   23.470036] Modules linked in: hv_vmbus(-)
[   23.470036] CPU: 2 PID: 213 Comm: rmmod Not tainted 3.19.0-rc5_bug923184+ 
#488
[   23.470036] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090006  05/23/2012
[   23.470036] task: 880036ef1cb0 ti: 880036ce8000 task.ti: 
880036ce8000
[   23.470036] RIP: 0010:[811d2e1b]  [811d2e1b] 
__kmalloc_node_track_caller+0xdb/0x1e0
[   23.470036] RSP: 0018:880036cebcc8  EFLAGS: 00010246
...

When this crash does not happen on driver unload the similar one is expected if
we try to load hv_vmbus again.

Remove kfree from vmbus_free_channels() as freeing it from
vmbus_device_release() seems right.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel_mgmt.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index ba4b25f..36bacc7 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -262,7 +262,6 @@ void vmbus_free_channels(void)
 
list_for_each_entry(channel, vmbus_connection.chn_list, listentry) {
vmbus_device_unregister(channel-device_obj);
-   kfree(channel-device_obj);
free_channel(channel);
}
 }
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 01/16] Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors

2015-02-03 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov vkuzn...@redhat.com

When an SMP Hyper-V guest is running on top of 2012R2 Server and secondary
cpus are sent offline (with echo 0  /sys/devices/system/cpu/cpu$cpu/online)
the system freeze is observed. This happens due to the fact that on newer
hypervisors (Win8, WS2012R2, ...) vmbus channel handlers are distributed
across all cpus (see init_vp_index() function in drivers/hv/channel_mgmt.c)
and on cpu offlining nobody reassigns them to CPU0. Prevent cpu offlining
when vmbus is loaded until the issue is fixed host-side.

This patch also disables hibernation but it is OK as it is also broken (MCE
error is hit on resume). Suspend still works.

Tested with WS2008R2 and WS2012R2.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/vmbus_drv.c |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 35e3f42..90c3400 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -33,6 +33,7 @@
 #include linux/hyperv.h
 #include linux/kernel_stat.h
 #include linux/clockchips.h
+#include linux/cpu.h
 #include asm/hyperv.h
 #include asm/hypervisor.h
 #include asm/mshyperv.h
@@ -704,6 +705,39 @@ static void vmbus_isr(void)
}
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+static int hyperv_cpu_disable(void)
+{
+   return -ENOSYS;
+}
+
+static void hv_cpu_hotplug_quirk(bool vmbus_loaded)
+{
+   static void *previous_cpu_disable;
+
+   /*
+* Offlining a CPU when running on newer hypervisors (WS2012R2, Win8,
+* ...) is not supported at this moment as channel interrupts are
+* distributed across all of them.
+*/
+
+   if ((vmbus_proto_version == VERSION_WS2008) ||
+   (vmbus_proto_version == VERSION_WIN7))
+   return;
+
+   if (vmbus_loaded) {
+   previous_cpu_disable = smp_ops.cpu_disable;
+   smp_ops.cpu_disable = hyperv_cpu_disable;
+   pr_notice(CPU offlining is not supported by hypervisor\n);
+   } else if (previous_cpu_disable)
+   smp_ops.cpu_disable = previous_cpu_disable;
+}
+#else
+static void hv_cpu_hotplug_quirk(bool vmbus_loaded)
+{
+}
+#endif
+
 /*
  * vmbus_bus_init -Main vmbus driver initialization routine.
  *
@@ -744,6 +778,7 @@ static int vmbus_bus_init(int irq)
if (ret)
goto err_alloc;
 
+   hv_cpu_hotplug_quirk(true);
vmbus_request_offers();
 
return 0;
@@ -997,6 +1032,7 @@ static void __exit vmbus_exit(void)
bus_unregister(hv_bus);
hv_cleanup();
acpi_bus_unregister_driver(vmbus_acpi_driver);
+   hv_cpu_hotplug_quirk(false);
 }
 
 
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 02/16] Drivers: hv: vmbus: rename channel work queues

2015-02-03 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]

All channel work queues are named 'hv_vmbus_ctl', this makes them
indistinguishable in ps output and makes it hard to link to the corresponding
vmbus device. Rename them to hv_vmbus_ctl/N and make vmbus device names match,
e.g. now vmbus_1 device is served by hv_vmbus_ctl/1 work queue.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel_mgmt.c |5 -
 drivers/hv/vmbus_drv.c|6 ++
 include/linux/hyperv.h|3 +++
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 3736f71..ba4b25f 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -139,19 +139,22 @@ EXPORT_SYMBOL_GPL(vmbus_prep_negotiate_resp);
  */
 static struct vmbus_channel *alloc_channel(void)
 {
+   static atomic_t chan_num = ATOMIC_INIT(0);
struct vmbus_channel *channel;
 
channel = kzalloc(sizeof(*channel), GFP_ATOMIC);
if (!channel)
return NULL;
 
+   channel-id = atomic_inc_return(chan_num);
spin_lock_init(channel-inbound_lock);
spin_lock_init(channel-lock);
 
INIT_LIST_HEAD(channel-sc_list);
INIT_LIST_HEAD(channel-percpu_list);
 
-   channel-controlwq = create_workqueue(hv_vmbus_ctl);
+   channel-controlwq = alloc_workqueue(hv_vmbus_ctl/%d, WQ_MEM_RECLAIM,
+1, channel-id);
if (!channel-controlwq) {
kfree(channel);
return NULL;
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 90c3400..4e3760c 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -875,10 +875,8 @@ int vmbus_device_register(struct hv_device 
*child_device_obj)
 {
int ret = 0;
 
-   static atomic_t device_num = ATOMIC_INIT(0);
-
-   dev_set_name(child_device_obj-device, vmbus_0_%d,
-atomic_inc_return(device_num));
+   dev_set_name(child_device_obj-device, vmbus_%d,
+child_device_obj-channel-id);
 
child_device_obj-device.bus = hv_bus;
child_device_obj-device.parent = hv_acpi_dev-dev;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 5a2ba67..26a32b7 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -646,6 +646,9 @@ struct hv_input_signal_event_buffer {
 };
 
 struct vmbus_channel {
+   /* Unique channel id */
+   int id;
+
struct list_head listentry;
 
struct hv_device *device_obj;
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 09/16] hv: hv_util: move vmbus_open() to a later place

2015-02-03 Thread K. Y. Srinivasan
From: Dexuan Cui [mailto:de...@microsoft.com]

Before the line vmbus_open() returns, srv-util_cb can be already running
and the variables, like util_fw_version, are needed by the srv-util_cb.

So we have to make sure the variables are initialized before the vmbus_open().

CC: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Vitaly Kuznetsov vkuzn...@redhat.com
Reviewed-by: Jason Wang jasow...@redhat.com
Signed-off-by: Dexuan Cui de...@microsoft.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/hv_util.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 3b9c9ef..c5be773 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -340,12 +340,8 @@ static int util_probe(struct hv_device *dev,
 
set_channel_read_state(dev-channel, false);
 
-   ret = vmbus_open(dev-channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0,
-   srv-util_cb, dev-channel);
-   if (ret)
-   goto error;
-
hv_set_drvdata(dev, srv);
+
/*
 * Based on the host; initialize the framework and
 * service version numbers we will negotiate.
@@ -365,6 +361,11 @@ static int util_probe(struct hv_device *dev,
hb_srv_version = HB_VERSION;
}
 
+   ret = vmbus_open(dev-channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0,
+   srv-util_cb, dev-channel);
+   if (ret)
+   goto error;
+
return 0;
 
 error:
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 16/16] Drivers: hv: vmbus: Add support for the NetworkDirect GUID

2015-02-03 Thread K. Y. Srinivasan
NetworkDirect is a service that supports guest RDMA.
Define the GUID for this service.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel_mgmt.c |2 ++
 include/linux/hyperv.h|   10 ++
 2 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 6be93f0..0ba6b5c 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -413,6 +413,8 @@ static const struct hv_vmbus_device_id hp_devs[] = {
{ HV_SCSI_GUID, },
/* Network */
{ HV_NIC_GUID, },
+   /* NetworkDirect Guest RDMA */
+   { HV_ND_GUID, },
 };
 
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index e73cfeb..b079abf 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1110,6 +1110,16 @@ void vmbus_driver_unregister(struct hv_driver 
*hv_driver);
}
 
 /*
+ * NetworkDirect. This is the guest RDMA service.
+ * {8c2eaf3d-32a7-4b09-ab99-bd1f1c86b501}
+ */
+#define HV_ND_GUID \
+   .guid = { \
+   0x3d, 0xaf, 0x2e, 0x8c, 0xa7, 0x32, 0x09, 0x4b, \
+   0xab, 0x99, 0xbd, 0x1f, 0x1c, 0x86, 0xb5, 0x01 \
+   }
+
+/*
  * Common header for Hyper-V ICs
  */
 
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 11/16] hv: vmbus_open(): reset the channel state on ENOMEM

2015-02-03 Thread K. Y. Srinivasan
From: Dexuan Cui [mailto:de...@microsoft.com]

Without this patch, the state is put to CHANNEL_OPENING_STATE, and when
the driver is loaded next time, vmbus_open() will fail immediately due to
newchannel-state != CHANNEL_OPEN_STATE.

CC: K. Y. Srinivasan k...@microsoft.com
Signed-off-by: Dexuan Cui de...@microsoft.com
Reviewed-by: Jason Wang jasow...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel.c |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 2978f5e..26dcf26 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -89,9 +89,10 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
out = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
 
-   if (!out)
-   return -ENOMEM;
-
+   if (!out) {
+   err = -ENOMEM;
+   goto error0;
+   }
 
in = (void *)((unsigned long)out + send_ringbuffer_size);
 
@@ -199,6 +200,7 @@ error0:
free_pages((unsigned long)out,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
kfree(open_info);
+   newchannel-state = CHANNEL_OPEN_STATE;
return err;
 }
 EXPORT_SYMBOL_GPL(vmbus_open);
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 14/16] hv: hv_balloon: match var type to return type of wait_for_completion

2015-02-03 Thread K. Y. Srinivasan
From: Nicholas Mc Guire der.h...@hofr.at

return type of wait_for_completion_timeout is unsigned long not int, this
patch changes the type of t from int to unsigned long.

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/hv_balloon.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index ff16938..965c37a 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1414,7 +1414,8 @@ static void balloon_onchannelcallback(void *context)
 static int balloon_probe(struct hv_device *dev,
const struct hv_vmbus_device_id *dev_id)
 {
-   int ret, t;
+   int ret;
+   unsigned long t;
struct dm_version_request version_req;
struct dm_capabilities cap_msg;
 
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 08/16] Drivers: hv: vmbus: Teardown clockevent devices on module unload

2015-02-03 Thread K. Y. Srinivasan
From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]

Newly introduced clockevent devices made it impossible to unload hv_vmbus
module as clockevents_config_and_register() takes additional reverence to
the module. To make it possible again we do the following:
- avoid setting dev-owner for clockevent devices;
- implement hv_synic_clockevents_cleanup() doing clockevents_unbind_device();
- call it from vmbus_exit().

In theory hv_synic_clockevents_cleanup() can be merged with hv_synic_cleanup(),
however, we call hv_synic_cleanup() from smp_call_function_single() and this
doesn't work for clockevents_unbind_device() as it does such call on its own. I
opted for a separate function.

Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/hv.c   |   25 -
 drivers/hv/hyperv_vmbus.h |2 ++
 drivers/hv/vmbus_drv.c|1 +
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 39531dc..d3943bc 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -312,7 +312,11 @@ static void hv_init_clockevent_device(struct 
clock_event_device *dev, int cpu)
dev-features = CLOCK_EVT_FEAT_ONESHOT;
dev-cpumask = cpumask_of(cpu);
dev-rating = 1000;
-   dev-owner = THIS_MODULE;
+   /*
+* Avoid settint dev-owner = THIS_MODULE deliberately as doing so will
+* result in clockevents_config_and_register() taking additional
+* references to the hv_vmbus module making it impossible to unload.
+*/
 
dev-set_mode = hv_ce_setmode;
dev-set_next_event = hv_ce_set_next_event;
@@ -470,6 +474,20 @@ void hv_synic_init(void *arg)
 }
 
 /*
+ * hv_synic_clockevents_cleanup - Cleanup clockevent devices
+ */
+void hv_synic_clockevents_cleanup(void)
+{
+   int cpu;
+
+   if (!(ms_hyperv.features  HV_X64_MSR_SYNTIMER_AVAILABLE))
+   return;
+
+   for_each_online_cpu(cpu)
+   clockevents_unbind_device(hv_context.clk_evt[cpu], cpu);
+}
+
+/*
  * hv_synic_cleanup - Cleanup routine for hv_synic_init().
  */
 void hv_synic_cleanup(void *arg)
@@ -483,6 +501,11 @@ void hv_synic_cleanup(void *arg)
if (!hv_context.synic_initialized)
return;
 
+   /* Turn off clockevent device */
+   if (ms_hyperv.features  HV_X64_MSR_SYNTIMER_AVAILABLE)
+   hv_ce_setmode(CLOCK_EVT_MODE_SHUTDOWN,
+ hv_context.clk_evt[cpu]);
+
rdmsrl(HV_X64_MSR_SINT0 + VMBUS_MESSAGE_SINT, shared_sint.as_uint64);
 
shared_sint.masked = 1;
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 6cf2de9..b055e53 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -572,6 +572,8 @@ extern void hv_synic_init(void *irqarg);
 
 extern void hv_synic_cleanup(void *arg);
 
+extern void hv_synic_clockevents_cleanup(void);
+
 /*
  * Host version information.
  */
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 28d19e8..3cd44ae 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1102,6 +1102,7 @@ static void __exit vmbus_exit(void)
int cpu;
 
vmbus_connection.conn_state = DISCONNECTED;
+   hv_synic_clockevents_cleanup();
hv_remove_vmbus_irq();
vmbus_free_channels();
bus_unregister(hv_bus);
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 15/16] Drivers: hv: vmbus: Fix a bug in the error path in vmbus_open()

2015-02-03 Thread K. Y. Srinivasan
Correctly rollback state if the failure occurs after we have handed over
the ownership of the buffer to the host.

Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Cc: sta...@vger.kernel.org
---
 drivers/hv/channel.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index f687995..bf0cf8f 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -137,7 +137,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
   GFP_KERNEL);
if (!open_info) {
err = -ENOMEM;
-   goto error0;
+   goto error_gpadl;
}
 
init_completion(open_info-waitevent);
@@ -153,7 +153,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
 
if (userdatalen  MAX_USER_DEFINED_BYTES) {
err = -EINVAL;
-   goto error0;
+   goto error_gpadl;
}
 
if (userdatalen)
@@ -197,6 +197,9 @@ error1:
list_del(open_info-msglistentry);
spin_unlock_irqrestore(vmbus_connection.channelmsg_lock, flags);
 
+error_gpadl:
+   vmbus_teardown_gpadl(newchannel, newchannel-ringbuffer_gpadlhandle);
+
 error0:
free_pages((unsigned long)out,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 13/16] hv: channel_mgmt: match var type to return type of wait_for_completion

2015-02-03 Thread K. Y. Srinivasan
From: Nicholas Mc Guire der.h...@hofr.at

return type of wait_for_completion_timeout is unsigned long not int, this
patch changes the type of t from int to unsigned long.

Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
 drivers/hv/channel_mgmt.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 36bacc7..6be93f0 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -789,7 +789,8 @@ int vmbus_request_offers(void)
 {
struct vmbus_channel_message_header *msg;
struct vmbus_channel_msginfo *msginfo;
-   int ret, t;
+   int ret;
+   unsigned long t;
 
msginfo = kmalloc(sizeof(*msginfo) +
  sizeof(struct vmbus_channel_message_header),
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel