Re: [PATCH] staging: lustre: uapi: properly include lustre_errno.h

2017-08-18 Thread Greg Kroah-Hartman 
On Fri, Aug 18, 2017 at 11:04:14PM -0400, James Simmons wrote:
> The path for lustre_errno.h was not updated to the new path
> for errno.c. Also the header lustre_net.h uses code found in
> lustre_errno.h but doesn't include the header directly. It
> is easy to forget to add the header lustre_errno.h before
> including lustre_net.h so it is just easier to include
> lustre_errno.h in lustre_net.h. This should resolve the
> build issues seen on the ia64 platform.
> 
> Signed-off-by: James Simmons 
> ---
>  drivers/staging/lustre/lustre/include/lustre_net.h | 1 +
>  drivers/staging/lustre/lustre/ptlrpc/errno.c   | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)

Merge this into the correct patch and send both patch series again
please.

thanks,

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

Re: [staging:staging-testing 306/323] drivers/staging/lustre/lustre/ptlrpc/errno.c:29:44: fatal error: ../include/lustre/lustre_errno.h: No such file or directory

2017-08-18 Thread Greg Kroah-Hartman 
On Sat, Aug 19, 2017 at 02:50:48AM +0100, James Simmons wrote:
> 
> > On Fri, Aug 18, 2017 at 03:53:56PM -0700, Greg Kroah-Hartman wrote:
> > > On Sat, Aug 19, 2017 at 02:49:02AM +0800, kbuild test robot wrote:
> > > > tree:   
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> > > > staging-testing
> > > > head:   4d64b24f1fd892842e4502c0ff9c0e6b8144efa0
> > > > commit: 1c4e5aa23a78c16ac15966a7704fa8a6201be095 [306/323] staging: 
> > > > lustre: uapi: migrate remaining uapi headers to uapi directory
> > > 
> > > Ugh.  Let me drop this one, and another uapi one as well from the tree,
> > > hopefully that should fix the build issues...
> > 
> > What a mess, am dropping all of the uapi patches now, please fix them up
> > and resend.
> >
> 
> No reason to drop them all. Its just a one line fix. I will send right 
> away.

They are now all dropped, sorry, please send a fixed up patch series
that does not break the build at any point in it.

thanks,

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

[PATCH] staging: lustre: uapi: properly include lustre_errno.h

2017-08-18 Thread James Simmons 
The path for lustre_errno.h was not updated to the new path
for errno.c. Also the header lustre_net.h uses code found in
lustre_errno.h but doesn't include the header directly. It
is easy to forget to add the header lustre_errno.h before
including lustre_net.h so it is just easier to include
lustre_errno.h in lustre_net.h. This should resolve the
build issues seen on the ia64 platform.

Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/include/lustre_net.h | 1 +
 drivers/staging/lustre/lustre/ptlrpc/errno.c   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h 
b/drivers/staging/lustre/lustre/include/lustre_net.h
index 1ae7e83..bc18131 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -55,6 +55,7 @@
 #include "../../include/uapi/linux/lnet/nidstr.h"
 #include "../../include/linux/lnet/api.h"
 #include "../../include/uapi/linux/lustre/lustre_idl.h"
+#include "lustre_errno.h"
 #include "lustre_ha.h"
 #include "lustre_sec.h"
 #include "lustre_import.h"
diff --git a/drivers/staging/lustre/lustre/ptlrpc/errno.c 
b/drivers/staging/lustre/lustre/ptlrpc/errno.c
index 73f8374..faad8d8 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/errno.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/errno.c
@@ -26,7 +26,7 @@
  */
 
 #include "../../include/linux/libcfs/libcfs.h"
-#include "../include/lustre/lustre_errno.h"
+#include "../include/lustre_errno.h"
 
 /*
  * The two translation tables below must define a one-to-one mapping between
-- 
1.8.3.1

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

Re: [staging:staging-testing 306/323] drivers/staging/lustre/lustre/ptlrpc/errno.c:29:44: fatal error: ../include/lustre/lustre_errno.h: No such file or directory

2017-08-18 Thread James Simmons 

> On Fri, Aug 18, 2017 at 03:53:56PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Aug 19, 2017 at 02:49:02AM +0800, kbuild test robot wrote:
> > > tree:   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> > > staging-testing
> > > head:   4d64b24f1fd892842e4502c0ff9c0e6b8144efa0
> > > commit: 1c4e5aa23a78c16ac15966a7704fa8a6201be095 [306/323] staging: 
> > > lustre: uapi: migrate remaining uapi headers to uapi directory
> > 
> > Ugh.  Let me drop this one, and another uapi one as well from the tree,
> > hopefully that should fix the build issues...
> 
> What a mess, am dropping all of the uapi patches now, please fix them up
> and resend.
>

No reason to drop them all. Its just a one line fix. I will send right 
away.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [staging:staging-testing 306/323] drivers/staging/lustre/lustre/ptlrpc/errno.c:29:44: fatal error: ../include/lustre/lustre_errno.h: No such file or directory

2017-08-18 Thread Greg Kroah-Hartman 
On Fri, Aug 18, 2017 at 03:54:58PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 18, 2017 at 03:53:56PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Aug 19, 2017 at 02:49:02AM +0800, kbuild test robot wrote:
> > > tree:   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> > > staging-testing
> > > head:   4d64b24f1fd892842e4502c0ff9c0e6b8144efa0
> > > commit: 1c4e5aa23a78c16ac15966a7704fa8a6201be095 [306/323] staging: 
> > > lustre: uapi: migrate remaining uapi headers to uapi directory
> > 
> > Ugh.  Let me drop this one, and another uapi one as well from the tree,
> > hopefully that should fix the build issues...
> 
> What a mess, am dropping all of the uapi patches now, please fix them up
> and resend.

James, I have dropped both of your patch series from the tree now,
please sync again and resend.

thanks,

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

Re: [PATCH] staging: lustre: lustre: Off by two in lmv_fid2path()

2017-08-18 Thread Dilger, Andreas 

> On Aug 17, 2017, at 09:47, Greg Kroah-Hartman  
> wrote:
> 
> On Mon, Aug 14, 2017 at 04:01:17PM +0100, James Simmons wrote:
>> 
>>> We want to concatonate join string one, a '/' character, string two and
>>> then a NUL terminator.  The destination buffer holds ori_gf->gf_pathlen
>>> characters.  The strlen() function returns the number of characters not
>>> counting the NUL terminator.  So we should be adding two extra spaces,
>>> one for the foward slash and one for the NUL.
>>> 
>>> Signed-off-by: Dan Carpenter 
>>> ---
>>> Not tested.  Please review this one carefully.
>> 
>> This is a real bug which is impacting users. The bug is being tracked
>> at https://jira.hpdd.intel.com/browse/LU-9863. It passed our test suite
>> and its being reviewed.
> 
> So what am I supposed to do with this patch?

The patch has been reviewed and you could add them before landing:

Reviewed-by: John L. Hammond 
Reviewed-by: frank zago 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







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

Re: [PATCH] vmbus: add per-channel sysfs info

2017-08-18 Thread Stephen Hemminger 
On Fri, 18 Aug 2017 15:59:49 -0700
Greg KH  wrote:

> On Fri, Aug 18, 2017 at 02:42:14PM -0700, Stephen Hemminger wrote:
> > This extends existing vmbus related sysfs structure to provide per-channel
> > state information. This is useful when diagnosing issues with multiple
> > queues in networking and storage.
> > 
> > The existing sysfs only displayed information about the primary
> > channel. The one place it reported multiple channels was the
> > channel_vp_mapping file which violated the sysfs convention
> > of one value per file.
> > 
> > Example:
> > $ tree /sys/class/net/eth1/device/channels
> > /sys/class/net/eth1/device/channels
> > ├── 15
> > │   ├── cpu
> > │   ├── in_mask
> > │   ├── lantency
> > │   ├── out_mask
> > │   ├── pending
> > │   ├── read_avail
> > │   └── write_avail
> > ├── 21
> > │   ├── cpu
> > │   ├── in_mask
> > │   ├── lantency
> > │   ├── out_mask
> > │   ├── pending
> > │   ├── read_avail
> > │   └── write_avail
> > ├── 22
> > │   ├── cpu
> > │   ├── in_mask
> > │   ├── lantency
> > │   ├── out_mask
> > │   ├── pending
> > │   ├── read_avail
> > │   └── write_avail
> > └── 23
> > ├── cpu
> > ├── in_mask
> > ├── lantency
> > ├── out_mask
> > ├── pending
> > ├── read_avail
> > └── write_avail
> > 
> > 
> > Signed-off-by: Stephen Hemminger   
> 
> Does Documentation/ABI need to be updated?

There is no ABI documentation for vmbus now. There should be but
that can come later.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: lustre: fix structure size for ARM OABI

2017-08-18 Thread Dilger, Andreas 
On Aug 17, 2017, at 10:26, Greg KH  wrote:
> 
> On Wed, Aug 16, 2017 at 05:44:15PM +0300, Cihangir Akturk wrote:
>> When building the kernel for the ARM architecture without setting
>> CONFIG_AEABI, size of struct lov_user_md_v3 and struct lov_mds_md_v3
>> differs, due to different alignment requirements of OABI and EABI.
>> 
>> Marking the anonymous union within struct lov_user_md_v3 as
>> '_packed' solves this issue. Otherwise we get the following
>> error:
>> 
>> drivers/staging/lustre/lustre/lov/lov_pack.c:352:2: note: in expansion
>> of macro ‘BUILD_BUG_ON’
>>  BUILD_BUG_ON(sizeof(lum) != sizeof(struct lov_mds_md_v3));
>> 
>> Signed-off-by: Cihangir Akturk 
>> ---
>> drivers/staging/lustre/lustre/include/lustre/lustre_user.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> This file is no longer in the tree :(

With James' recent patch series, this has moved to 
include/uapi/linux/lustre/lustre_user.h

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation







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

RE: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-18 Thread Dexuan Cui 
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > CID is not really used by us, because we only support guest<->host
> communication,
> > and don't support guest<->guest communication. The Hyper-V host
> references
> > every VM by VmID (which is invisible to the VM), and a VM can only talk to
> the
> > host via this feature.
> 
> Applications running inside the guest should use VMADDR_CID_HOST (2) to
> connect to the host, even on Hyper-V.
I have no objection, and this patch does support this usage of the
user-space applications.
 
> By the way, we should collaborate on a test suite and a vsock(7) man
> page that documents the semantics of AF_VSOCK sockets.  This way our
> transports will have the same behavior and AF_VSOCK applications will
> work on all 3 hypervisors.
I can't agree more. :-)
BTW, I have been using Rolf's test suite to test my patch:
https://github.com/rn/virtsock/tree/master/c
Maybe this can be a good starting point.
 
> Not all features need to be supported.  For example, VMCI supports
> SOCK_DGRAM while Hyper-V and virtio do not.  But features that are
> available should behave identically.
I totally agree, though I'm afraid Hyper-V may have a little more limitations
compared to VMware/KVM duo to the  <--> 
mapping.
 
> > Can we use the 'protocol' parameter in the socket() function:
> > int socket(int domain, int type, int protocol)
> >
> > IMO currently the 'protocol' is not really used.
> > I think we can modify __vsock_core_init() to allow multiple transport layers
> to
> >  be registered, and we can define different 'protocol' numbers for
> > VMware/KVM/Hyper-V, and ask the application to explicitly specify what
> should
> > be used. Considering compatibility, we can use the default transport in a
> given
> > VM depending on the underlying hypervisor.
> 
> I think AF_VSOCK should hide the transport from users/applications.
Ideally yes, but let's consider the KVM-on-KVM nested scenario: when
an application in the Level-1 VM creates an AF_VSOCK socket and call
connect() for it, how can we know if the app is trying to connect to
the Level-0 host, or connect to the Level-2 VM? We can't. That's why
I propose we should use the 'protocol' parameter to distinguish between
"to guest" and "to host".

With my proposal, in the above scenario, by default (the 'protocol' is 0),
we choose the "to host" transport layer when socket() is called; if the
userspace app explicitly specifies "to guest", we choose the "to guest"
transport layer when socket() is called. This way, the connect(), bind(), etc.
can work automatically.
(Of course, the default transport for a give VM can be better chosen
if we detect which nested level the app is running on.)

> Think of same-on-same nested virtualization: VMware-on-VMware or
> KVM-on-KVM.  In that case specifying VMCI or virtio doesn't help.
> 
> We'd still need to distinguish between "to guest" and "to host"
> (currently VMCI has code to do this but virtio does not).
> 
> The natural place to distinguish the destination is when dealing with
> the sockaddr in connect(), bind(), etc.
> 
> Stefan

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

Re: [PATCH] vmbus: add per-channel sysfs info

2017-08-18 Thread Greg KH 
On Fri, Aug 18, 2017 at 02:42:14PM -0700, Stephen Hemminger wrote:
> This extends existing vmbus related sysfs structure to provide per-channel
> state information. This is useful when diagnosing issues with multiple
> queues in networking and storage.
> 
> The existing sysfs only displayed information about the primary
> channel. The one place it reported multiple channels was the
> channel_vp_mapping file which violated the sysfs convention
> of one value per file.
> 
> Example:
> $ tree /sys/class/net/eth1/device/channels
> /sys/class/net/eth1/device/channels
> ├── 15
> │   ├── cpu
> │   ├── in_mask
> │   ├── lantency
> │   ├── out_mask
> │   ├── pending
> │   ├── read_avail
> │   └── write_avail
> ├── 21
> │   ├── cpu
> │   ├── in_mask
> │   ├── lantency
> │   ├── out_mask
> │   ├── pending
> │   ├── read_avail
> │   └── write_avail
> ├── 22
> │   ├── cpu
> │   ├── in_mask
> │   ├── lantency
> │   ├── out_mask
> │   ├── pending
> │   ├── read_avail
> │   └── write_avail
> └── 23
> ├── cpu
> ├── in_mask
> ├── lantency
> ├── out_mask
> ├── pending
> ├── read_avail
> └── write_avail
> 
> 
> Signed-off-by: Stephen Hemminger 

Does Documentation/ABI need to be updated?

thanks,

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

Re: [staging:staging-testing 306/323] drivers/staging/lustre/lustre/ptlrpc/errno.c:29:44: fatal error: ../include/lustre/lustre_errno.h: No such file or directory

2017-08-18 Thread Greg Kroah-Hartman 
On Fri, Aug 18, 2017 at 03:53:56PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Aug 19, 2017 at 02:49:02AM +0800, kbuild test robot wrote:
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> > staging-testing
> > head:   4d64b24f1fd892842e4502c0ff9c0e6b8144efa0
> > commit: 1c4e5aa23a78c16ac15966a7704fa8a6201be095 [306/323] staging: lustre: 
> > uapi: migrate remaining uapi headers to uapi directory
> 
> Ugh.  Let me drop this one, and another uapi one as well from the tree,
> hopefully that should fix the build issues...

What a mess, am dropping all of the uapi patches now, please fix them up
and resend.

thanks,

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

Re: [staging:staging-testing 306/323] drivers/staging/lustre/lustre/ptlrpc/errno.c:29:44: fatal error: ../include/lustre/lustre_errno.h: No such file or directory

2017-08-18 Thread Greg Kroah-Hartman 
On Sat, Aug 19, 2017 at 02:49:02AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> staging-testing
> head:   4d64b24f1fd892842e4502c0ff9c0e6b8144efa0
> commit: 1c4e5aa23a78c16ac15966a7704fa8a6201be095 [306/323] staging: lustre: 
> uapi: migrate remaining uapi headers to uapi directory

Ugh.  Let me drop this one, and another uapi one as well from the tree,
hopefully that should fix the build issues...

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

RE: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

2017-08-18 Thread Dexuan Cui 
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Thursday, August 17, 2017 07:56
> To: Dexuan Cui 
> On Tue, Aug 15, 2017 at 10:18:41PM +, Dexuan Cui wrote:
> > +static u32 hvs_get_local_cid(void)
> > +{
> > +   return VMADDR_CID_ANY;
> > +}
> 
> Interesting concept: the guest never knows its CID.  This is nice from a
> live migration perspective.  Currently VMCI and virtio adjust listen
> socket local CIDs after migration.
> 
> > +static bool hvs_stream_allow(u32 cid, u32 port)
> > +{
> > +   static const u32 valid_cids[] = {
> > +   VMADDR_CID_ANY,
> 
> Is this for loopback?

No, we don't support lookback in Linux VM, at least for now.
In our Linux implementation, Linux VM can only connect to the host, and
here when Linux VM calls connect(), I treat  VMADDR_CID_ANY 
the same as VMADDR_CID_HOST.

> > +   VMADDR_CID_HOST,
> > +   };
> > +   int i;
> > +
> > +   /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x)
> is
> > +* reserved as ephemeral ports, which are used as the host's ports
> > +* when the host initiates connections.
> > +*/
> > +   if (port > MAX_HOST_LISTEN_PORT)
> > +   return false;
> 
> Without this if statement the guest will attempt to connect.  I guess
> there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> connection attempt will fail.

You're correct.
To use the vsock common infrastructure, we have to map Hyper-V's
GUID  to int , and hence we must limit
the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
we can only use half of the whole 32-bit port space for listen().
This is detailed in the long comments starting at about Line 100.
 
> ...but hardcode this knowledge into the guest driver?
I'd like the guest's connect() to fail immediately here.
IMO this is better than a connect timeout. :-)

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

[PATCH] vmbus: add per-channel sysfs info

2017-08-18 Thread Stephen Hemminger 
This extends existing vmbus related sysfs structure to provide per-channel
state information. This is useful when diagnosing issues with multiple
queues in networking and storage.

The existing sysfs only displayed information about the primary
channel. The one place it reported multiple channels was the
channel_vp_mapping file which violated the sysfs convention
of one value per file.

Example:
$ tree /sys/class/net/eth1/device/channels
/sys/class/net/eth1/device/channels
├── 15
│   ├── cpu
│   ├── in_mask
│   ├── lantency
│   ├── out_mask
│   ├── pending
│   ├── read_avail
│   └── write_avail
├── 21
│   ├── cpu
│   ├── in_mask
│   ├── lantency
│   ├── out_mask
│   ├── pending
│   ├── read_avail
│   └── write_avail
├── 22
│   ├── cpu
│   ├── in_mask
│   ├── lantency
│   ├── out_mask
│   ├── pending
│   ├── read_avail
│   └── write_avail
└── 23
├── cpu
├── in_mask
├── lantency
├── out_mask
├── pending
├── read_avail
└── write_avail


Signed-off-by: Stephen Hemminger 
---
 drivers/hv/channel_mgmt.c |  10 ++-
 drivers/hv/hyperv_vmbus.h |   2 +
 drivers/hv/vmbus_drv.c| 185 +++---
 include/linux/hyperv.h|   6 ++
 4 files changed, 190 insertions(+), 13 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 968af173c4c1..c95b175bcdec 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -350,7 +350,7 @@ static void free_channel(struct vmbus_channel *channel)
 {
tasklet_kill(>callback_event);
 
-   kfree_rcu(channel, rcu);
+   kobject_put(>kobj);
 }
 
 static void percpu_channel_enq(void *arg)
@@ -513,6 +513,14 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
newchannel->state = CHANNEL_OPEN_STATE;
 
if (!fnew) {
+   struct hv_device *dev
+   = newchannel->primary_channel->device_obj;
+
+   if (vmbus_add_channel_kobj(dev, newchannel)) {
+   atomic_dec(_connection.offer_in_progress);
+   goto err_free_chan;
+   }
+
if (channel->sc_creation_callback != NULL)
channel->sc_creation_callback(newchannel);
return;
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 1b6a5e0dfa75..bfa2d0af4e1d 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -384,6 +384,8 @@ struct hv_device *vmbus_device_create(const uuid_le *type,
 
 int vmbus_device_register(struct hv_device *child_device_obj);
 void vmbus_device_unregister(struct hv_device *device_obj);
+int vmbus_add_channel_kobj(struct hv_device *device_obj,
+  struct vmbus_channel *channel);
 
 struct vmbus_channel *relid2channel(u32 relid);
 
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 43160a2eafe0..88622a23fcd8 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -107,28 +107,30 @@ static void print_alias_name(struct hv_device *hv_dev, 
char *alias_name)
sprintf(_name[i], "%02x", hv_dev->dev_type.b[i/2]);
 }
 
-static u8 channel_monitor_group(struct vmbus_channel *channel)
+static u8 channel_monitor_group(const struct vmbus_channel *channel)
 {
return (u8)channel->offermsg.monitorid / 32;
 }
 
-static u8 channel_monitor_offset(struct vmbus_channel *channel)
+static u8 channel_monitor_offset(const struct vmbus_channel *channel)
 {
return (u8)channel->offermsg.monitorid % 32;
 }
 
-static u32 channel_pending(struct vmbus_channel *channel,
-  struct hv_monitor_page *monitor_page)
+static u32 channel_pending(const struct vmbus_channel *channel,
+  const struct hv_monitor_page *monitor_page)
 {
u8 monitor_group = channel_monitor_group(channel);
+
return monitor_page->trigger_group[monitor_group].pending;
 }
 
-static u32 channel_latency(struct vmbus_channel *channel,
-  struct hv_monitor_page *monitor_page)
+static u32 channel_latency(const struct vmbus_channel *channel,
+  const struct hv_monitor_page *monitor_page)
 {
u8 monitor_group = channel_monitor_group(channel);
u8 monitor_offset = channel_monitor_offset(channel);
+
return monitor_page->latency[monitor_group][monitor_offset];
 }
 
@@ -1134,6 +1136,145 @@ void vmbus_driver_unregister(struct hv_driver 
*hv_driver)
 }
 EXPORT_SYMBOL_GPL(vmbus_driver_unregister);
 
+
+/*
+ * Called when last reference to channel is gone.
+ */
+static void vmbus_chan_release(struct kobject *kobj)
+{
+   struct vmbus_channel *channel
+   = container_of(kobj, struct vmbus_channel, kobj);
+
+   kfree_rcu(channel, rcu);
+}
+
+struct vmbus_chan_attribute {
+   struct attribute attr;
+   ssize_t (*show)(const struct vmbus_channel *chan, char *buf);
+   ssize_t (*store)(struct vmbus_channel *chan,
+

RE: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

2017-08-18 Thread Dexuan Cui 
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Thursday, August 17, 2017 07:06
> 
> On Tue, Aug 15, 2017 at 10:15:39PM +, Dexuan Cui wrote:
> > With the current code, when vsock_dequeue_accept() is removing a sock
> > from the list, nothing prevents vsock_enqueue_accept() from adding a new
> > sock into the list concurrently. We should add a lock to protect the list.
> 
> The listener sock is locked, preventing concurrent modification.  I have
> checked both the virtio and vmci transports.  Can you post an example
> where the listener sock isn't locked?
> 
> Stefan
Sorry, I was not careful when checking the vmci code. 
Please ignore the patch.

Now I realized the expectation is that the individual transport drivers should
do the locking for vsock_enqueue_accept(), but for vsock_dequeue_accept(),
the locking is done by the common vsock driver.

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

[PATCH] staging: rtl8188eu: add RNX-N150NUB support

2017-08-18 Thread Charles Milette 
Add support for USB Device Rosewill RNX-N150NUB.
VendorID: 0x0bda, ProductID: 0xffef

Signed-off-by: Charles Milette 
---
 drivers/staging/rtl8188eu/os_dep/usb_intf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c 
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index d283341c..56cd4e5e 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -45,6 +45,7 @@ static struct usb_device_id rtw_usb_id_tbl[] = {
{USB_DEVICE(0x2001, 0x3311)}, /* DLink GO-USB-N150 REV B1 */
{USB_DEVICE(0x2357, 0x010c)}, /* TP-Link TL-WN722N v2 */
{USB_DEVICE(0x0df6, 0x0076)}, /* Sitecom N150 v2 */
+   {USB_DEVICE(USB_VENDER_ID_REALTEK, 0xffef)}, /* Rosewill RNX-N150NUB */
{}  /* Terminating entry */
 };
 
-- 
2.14.1

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

Re: [PATCH] staging: wlan-ng: Fix sparse warning: cast to restricted __le16.

2017-08-18 Thread Ricardo Silva 
Hi,

On 08/09/2017 11:35 PM, AbdAllah-MEZITI wrote:
> The same structure is used in both side, so we dont need to cast.

I believe there were no casts there, but calls to le16_to_cpu(),
meaning there was previously a bug or the data being accessed was
really stored in little-endian format, so we shouldn't just remove
them for silencing sparse.

> This will fix the following sparse warnings:
> drivers/staging/wlan-ng/prism2sta.c:1139:13: warning: cast to restricted 
> __le16
> drivers/staging/wlan-ng/prism2sta.c:1150:24: warning: cast to restricted 
> __le16
> drivers/staging/wlan-ng/prism2sta.c:1157:37: warning: cast to restricted 
> __le16
> drivers/staging/wlan-ng/prism2sta.c:1158:37: warning: cast to restricted 
> __le16
> drivers/staging/wlan-ng/prism2sta.c:1159:40: warning: cast to restricted 
> __le16
> drivers/staging/wlan-ng/prism2sta.c:1450:31: warning: cast to restricted 
> __le16
> 
> Signed-off-by: AbdAllah MEZITI 
> ---
>  drivers/staging/wlan-ng/prism2sta.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/wlan-ng/prism2sta.c 
> b/drivers/staging/wlan-ng/prism2sta.c
> index 8c34712..c9df450 100644
> --- a/drivers/staging/wlan-ng/prism2sta.c
> +++ b/drivers/staging/wlan-ng/prism2sta.c
> @@ -1136,7 +1136,7 @@ static void prism2sta_inf_chinforesults(struct 
> wlandevice *wlandev,
>   unsigned int i, n;
>  
>   hw->channel_info.results.scanchannels =
> - le16_to_cpu(inf->info.chinforesult.scanchannels);
> + inf->info.chinforesult.scanchannels;

If this is not fixing some issue, then I believe it can be introducing
one on big-endian CPUs, right?

>  
>   for (i = 0, n = 0; i < HFA384x_CHINFORESULT_MAX; i++) {
>   struct hfa384x_ch_info_result_sub *result;
> @@ -1147,16 +1147,16 @@ static void prism2sta_inf_chinforesults(struct 
> wlandevice *wlandev,
>   continue;
>  
>   result = >info.chinforesult.result[n];
> - chan = le16_to_cpu(result->chid) - 1;
> + chan = result->chid - 1;

Ditto.

>  
>   if (chan < 0 || chan >= HFA384x_CHINFORESULT_MAX)
>   continue;
>  
>   chinforesult = >channel_info.results.result[chan];
>   chinforesult->chid = chan;
> - chinforesult->anl = le16_to_cpu(result->anl);
> - chinforesult->pnl = le16_to_cpu(result->pnl);
> - chinforesult->active = le16_to_cpu(result->active);
> + chinforesult->anl = result->anl;
> + chinforesult->pnl = result->pnl;
> + chinforesult->active = result->active;

Ditto.

>  
>   pr_debug("chinfo: channel %d, %s level (avg/peak)=%d/%d dB, pcf 
> %d\n",
>chan + 1,
> @@ -1447,7 +1447,7 @@ static void prism2sta_inf_linkstatus(struct wlandevice 
> *wlandev,
>  {
>   struct hfa384x *hw = wlandev->priv;
>  
> - hw->link_status_new = le16_to_cpu(inf->info.linkstatus.linkstatus);
> + hw->link_status_new = inf->info.linkstatus.linkstatus;

Ditto.
If I'm wrong about this being incorrect, then I have a patch submitted for 
fixing
the sparse warning here that should be discarded. My patch is:

  staging: wlan-ng: hfa384x.h: Use endian type in 'hfa384x_link_status'

and changes the linkstatus field to le16.

Regards,

Ricardo Silva

>  
>   schedule_work(>link_bh);
>  }
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[staging:staging-testing 306/323] drivers/staging/lustre/lustre/ptlrpc/errno.c:29:44: fatal error: ../include/lustre/lustre_errno.h: No such file or directory

2017-08-18 Thread kbuild test robot 
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
staging-testing
head:   4d64b24f1fd892842e4502c0ff9c0e6b8144efa0
commit: 1c4e5aa23a78c16ac15966a7704fa8a6201be095 [306/323] staging: lustre: 
uapi: migrate remaining uapi headers to uapi directory
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 1c4e5aa23a78c16ac15966a7704fa8a6201be095
# save the attached .config to linux build tree
make.cross ARCH=alpha 

All errors (new ones prefixed by >>):

>> drivers/staging/lustre/lustre/ptlrpc/errno.c:29:44: fatal error: 
>> ../include/lustre/lustre_errno.h: No such file or directory
#include "../include/lustre/lustre_errno.h"
   ^
   compilation terminated.

vim +29 drivers/staging/lustre/lustre/ptlrpc/errno.c

e27db149 Greg Kroah-Hartman 2014-07-11 @29  #include 
"../include/lustre/lustre_errno.h"
2d58de78 Li Wei 2013-07-23  30  

:: The code at line 29 was first introduced by commit
:: e27db14919269176ec040479d199225a37aafb8c staging: lustre: ptlrpc/ldlm: 
remove ccflags from Makefile

:: TO: Greg Kroah-Hartman 
:: CC: Greg Kroah-Hartman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [staging:staging-testing 276/342] drivers/staging/lustre/lustre/include/lustre_net.h:2110:11: error: implicit declaration of function 'lustre_errno_hton'

2017-08-18 Thread Greg Kroah-Hartman 
On Fri, Aug 18, 2017 at 03:05:22AM +0800, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> staging-testing
> head:   8d2fa5c352a9e0f877281c2b4486347305a380db
> commit: ce6e67f2ed110fdbb89bb76bca8c2b9d2ad6c736 [276/342] staging: lustre: 
> fid: add include path to Makefile

James, I have now dropped a bunch of lustre patches from my
staging-testing tree, mostly all of the ones that messed with the
include path.

Here's the "names" of them:
0049-staging-lustre-fid-add-include-path-to-Makefile.patch
0050-staging-lustre-fld-add-include-path-to-Makefile.patch
0051-staging-lustre-ptlrpc-add-include-path-to-Makefile.patch
0052-staging-lustre-llite-add-include-path-to-Makefile.patch
0053-staging-lustre-lmv-add-include-path-to-Makefile.patch
0054-staging-lustre-lov-add-include-path-to-Makefile.patch
0055-staging-lustre-mdc-add-include-path-to-Makefile.patch
0056-staging-lustre-mgc-add-include-path-to-Makefile.patch
0057-staging-lustre-obdclass-add-include-path-to-Makefile.patch
0058-staging-lustre-obdecho-add-include-path-to-Makefile.patch
0059-staging-lustre-osc-add-include-path-to-Makefile.patch
0060-staging-lustre-lustre-cleanup-paths-for-lustre-inter.patch
0061-staging-lustre-lustre-cleanup-paths-for-lustre-UAPI-.patch
0062-staging-lustre-lnet-selftest-add-include-path-to-Mak.patch
0063-staging-lustre-lnet-add-include-path-to-Makefile.patch
0064-staging-lustre-ko2iblnd-add-include-path-to-Makefile.patch
0065-staging-lustre-ksocklnd-add-include-path-to-Makefile.patch
0066-staging-lustre-libcfs-add-include-path-to-Makefile.patch
0067-staging-lustre-libcfs-cleanup-paths-for-libcfs-heade.patch
0068-staging-lustre-lnet-cleanup-paths-for-all-LNet-heade.patch

Please fix up the build problems with these and resend.

thanks,

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

[PATCH] staging: rtl8192e: Change fixed function names with "%s: ", __func__

2017-08-18 Thread ?????? 
From: Shurong Zhang 

Replace hard-coded function names in strings with "%s", __func__
in the dot11d.c file. Issue found by checkpatch.pl.

Signed-off-by: Shurong Zhang 
---
 drivers/staging/rtl8192e/dot11d.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192e/dot11d.c 
b/drivers/staging/rtl8192e/dot11d.c
index 017fe04..be78db1 100644
--- a/drivers/staging/rtl8192e/dot11d.c
+++ b/drivers/staging/rtl8192e/dot11d.c
@@ -128,12 +128,12 @@ void Dot11d_UpdateCountryIe(struct rtllib_device *dev, u8 
*pTaddr,
pTriple = (struct chnl_txpow_triple *)(pCoutryIe + 3);
for (i = 0; i < NumTriples; i++) {
if (MaxChnlNum >= pTriple->FirstChnl) {
-   netdev_info(dev->dev, "Dot11d_UpdateCountryIe(): Invalid country IE, 
skip it1\n");
+   netdev_info(dev->dev, "%s(): Invalid country IE, skip 
it1\n",__func__);
return;
}
if (MAX_CHANNEL_NUMBER < (pTriple->FirstChnl +
pTriple->NumChnls)) {
-   netdev_info(dev->dev, "Dot11d_UpdateCountryIe(): Invalid country IE, 
skip it2\n");
+   netdev_info(dev->dev, "%s(): Invalid country IE, skip 
it2\n",__func__);
return;
}
 
-- 
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

2017-08-18 Thread Stefan Hajnoczi 
On Tue, Aug 15, 2017 at 10:18:41PM +, Dexuan Cui wrote:
> +static u32 hvs_get_local_cid(void)
> +{
> + return VMADDR_CID_ANY;
> +}

Interesting concept: the guest never knows its CID.  This is nice from a
live migration perspective.  Currently VMCI and virtio adjust listen
socket local CIDs after migration.

> +static bool hvs_stream_allow(u32 cid, u32 port)
> +{
> + static const u32 valid_cids[] = {
> + VMADDR_CID_ANY,

Is this for loopback?

> + VMADDR_CID_HOST,
> + };
> + int i;
> +
> + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
> +  * reserved as ephemeral ports, which are used as the host's ports
> +  * when the host initiates connections.
> +  */
> + if (port > MAX_HOST_LISTEN_PORT)
> + return false;

Without this if statement the guest will attempt to connect.  I guess
there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
connection attempt will fail.

...but hardcode this knowledge into the guest driver?


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

Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

2017-08-18 Thread Stefan Hajnoczi 
On Tue, Aug 15, 2017 at 10:15:39PM +, Dexuan Cui wrote:
> With the current code, when vsock_dequeue_accept() is removing a sock
> from the list, nothing prevents vsock_enqueue_accept() from adding a new
> sock into the list concurrently. We should add a lock to protect the list.

The listener sock is locked, preventing concurrent modification.  I have
checked both the virtio and vmci transports.  Can you post an example
where the listener sock isn't locked?

Stefan


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

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

2017-08-18 Thread Stefan Hajnoczi 
On Fri, Aug 18, 2017 at 03:07:30AM +, Dexuan Cui wrote:
> > From: Jorgen S. Hansen [mailto:jhan...@vmware.com]
> > Sent: Thursday, August 17, 2017 08:17
> > >
> > > Putting aside nested virtualization, I want to load the transport (vmci,
> > > Hyper-V, vsock) for which there is paravirtualized hardware present
> > > inside the guest.
> > 
> > Good points. Completely agree that this is the desired behavior for a guest.
> > 
> > 
> > > It's a little tricker on the host side (doesn't matter for Hyper-V and
> > > probably also doesn't for VMware) because the host-side driver is a
> > > software device with no hardware backing it.  In KVM we assume the
> > > vhost_vsock.ko kernel module will be loaded sufficiently early.
> > 
> > Since the vmci driver is currently tied to PF_VSOCK it hasn’t been a 
> > problem,
> > but on the host side the VMCI driver has no hardware backing it either, so
> > when we move to a more appropriate solution, this will be an issue for VMCI 
> > as
> > well. I’ll check our shipped products, but they most likely assume that if 
> > an
> > upstreamed vmci module is present, it will be loaded automatically.
> 
> Hyper-V Sockets is a standard feature of VMBus v4.0, so we can easily know
> we can and should load iff vmbus_proto_version >= VERSION_WIN10.
> 
> > > Things get trickier with nested virtualization because the VM might want
> > > to talk to its host but also to its nested VMs.  The simple way of
> > > fixing this would be to allow two transports loaded simultaneously and
> > > route traffic destined to CID 2 to the host transport and all other
> > > traffic to the guest transport.
> 
> This sounds like a little tricky to me.
> CID is not really used by us, because we only support guest<->host 
> communication,
> and don't support guest<->guest communication. The Hyper-V host references
> every VM by VmID (which is invisible to the VM), and a VM can only talk to the
> host via this feature.

Applications running inside the guest should use VMADDR_CID_HOST (2) to
connect to the host, even on Hyper-V.

By the way, we should collaborate on a test suite and a vsock(7) man
page that documents the semantics of AF_VSOCK sockets.  This way our
transports will have the same behavior and AF_VSOCK applications will
work on all 3 hypervisors.

Not all features need to be supported.  For example, VMCI supports
SOCK_DGRAM while Hyper-V and virtio do not.  But features that are
available should behave identically.

> > This is close to the routing the VMCI driver does in a nested environment, 
> > but
> > that is with the assumption that there is only one type of transport. 
> > Having two
> > different transports would require that we delay resolving the transport 
> > type
> > until the socket endpoint has been bound to an address. Things get trickier 
> > if
> > listening sockets use VMADDR_CID_ANY - if only one transport is present, 
> > this
> > would allow the socket to accept connections from both guests and outer 
> > host,
> > but with multiple transports that won’t work, since we can’t associate a 
> > socket
> > with a transport until the socket is bound.
> > 
> > >
> > > Perhaps we should discuss these cases a bit more to figure out how to
> > > avoid conflicts over MODULE_ALIAS_NETPROTO(PF_VSOCK).
> > 
> > Agreed.
> 
> Can we use the 'protocol' parameter in the socket() function:
> int socket(int domain, int type, int protocol) 
> 
> IMO currently the 'protocol' is not really used.
> I think we can modify __vsock_core_init() to allow multiple transport layers 
> to
>  be registered, and we can define different 'protocol' numbers for
> VMware/KVM/Hyper-V, and ask the application to explicitly specify what should
> be used. Considering compatibility, we can use the default transport in a 
> given
> VM depending on the underlying hypervisor. 

I think AF_VSOCK should hide the transport from users/applications.
Think of same-on-same nested virtualization: VMware-on-VMware or
KVM-on-KVM.  In that case specifying VMCI or virtio doesn't help.

We'd still need to distinguish between "to guest" and "to host"
(currently VMCI has code to do this but virtio does not).

The natural place to distinguish the destination is when dealing with
the sockaddr in connect(), bind(), etc.

Stefan


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

[PATCH] staging/rts5208: fix incorrect shift to extract upper nybble

2017-08-18 Thread Colin King 
From: Colin Ian King 

The mask of sns_key_info1 suggests the upper nybble is being extracted
however the following shift of 8 bits is too large and always results in
0.  Fix this by shifting only by 4 bits to correctly get the upper nybble.

Detected by CoverityScan, CID#142891 ("Operands don't affect result")

Fixes: fa590c222fba ("staging: rts5208: add support for rts5208 and rts5288")
Signed-off-by: Colin Ian King 
---
 drivers/staging/rts5208/rtsx_scsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/rtsx_scsi.c 
b/drivers/staging/rts5208/rtsx_scsi.c
index 36b5a11f21d2..a401b13f5f5e 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -414,7 +414,7 @@ void set_sense_data(struct rtsx_chip *chip, unsigned int 
lun, u8 err_code,
sense->ascq = ascq;
if (sns_key_info0 != 0) {
sense->sns_key_info[0] = SKSV | sns_key_info0;
-   sense->sns_key_info[1] = (sns_key_info1 & 0xf0) >> 8;
+   sense->sns_key_info[1] = (sns_key_info1 & 0xf0) >> 4;
sense->sns_key_info[2] = sns_key_info1 & 0x0f;
}
 }
-- 
2.11.0

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

[PATCH] staging:wlan-ng Fix Multiple line dereference

2017-08-18 Thread Janani S 
This patch fixes multiple line dereference warning reported
by checkpatch script.

Signed-off-by: Janani S 
---
 drivers/staging/wlan-ng/hfa384x_usb.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c 
b/drivers/staging/wlan-ng/hfa384x_usb.c
index ee5fa86..2746e13 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -1345,15 +1345,11 @@ static int hfa384x_usbctlx_complete_sync(struct hfa384x 
*hw,
kfree(ctlx);
} else if (mode == DOWAIT) {
struct usbctlx_cmd_completor completor;
+   struct usbctlx_completor *cmplt;
 
-   result =
-   hfa384x_usbctlx_complete_sync(hw, ctlx,
- init_cmd_completor(,
->
-inbuf.
-cmdresp,
->
-result));
+   cmplt = init_cmd_completor(, >inbuf.cmdresp,
+  >result);
+   result = hfa384x_usbctlx_complete_sync(hw, ctlx, cmplt);
}
 
 done:
-- 
1.9.1

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

[PATCH] [PATCH] staging:wlan-ng Fix Multiple line dereference

2017-08-18 Thread Janani S 
This patch fixes multiple line dereference warning reported
by checkpatch script.

Signed-off-by: Janani S 
---
 drivers/staging/wlan-ng/hfa384x_usb.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c 
b/drivers/staging/wlan-ng/hfa384x_usb.c
index ee5fa86..2746e13 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -1345,15 +1345,11 @@ static int hfa384x_usbctlx_complete_sync(struct hfa384x 
*hw,
kfree(ctlx);
} else if (mode == DOWAIT) {
struct usbctlx_cmd_completor completor;
+   struct usbctlx_completor *cmplt;
 
-   result =
-   hfa384x_usbctlx_complete_sync(hw, ctlx,
- init_cmd_completor(,
->
-inbuf.
-cmdresp,
->
-result));
+   cmplt = init_cmd_completor(, >inbuf.cmdresp,
+  >result);
+   result = hfa384x_usbctlx_complete_sync(hw, ctlx, cmplt);
}
 
 done:
-- 
1.9.1

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