Re: [PATCH] staging: lustre: llite: drop acl from cache

2016-05-23 Thread Andreas Grünbacher
2016-05-24 2:35 GMT+02:00 James Simmons :
> Commit b8a7a3a6 change get_acl() for posix xattr to always cache
> the ACL which increases the reference count. That reference count
> can be reduced by have ll_get_acl() call forget_cached_acl() which
> it wasn't. When an inode gets deleted by Lustre the POSIX ACL
> reference count is tested to ensure its 1 and if not produces an error.

Lustre shouldn't assume that the VFS immediately drops the reference
it is passed. Please remove that check as well.

> Since forget_cached_acl() was not called Lustre started to complain.
> This patch changes ll_get_acl() to call forget_cached_acl().
>
> Signed-off-by: James Simmons 

Reviewed-by: Andreas Gruenbacher 

> ---
>  drivers/staging/lustre/lustre/llite/file.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/llite/file.c 
> b/drivers/staging/lustre/lustre/llite/file.c
> index f47f2ac..0191945 100644
> --- a/drivers/staging/lustre/lustre/llite/file.c
> +++ b/drivers/staging/lustre/lustre/llite/file.c
> @@ -3124,6 +3124,7 @@ struct posix_acl *ll_get_acl(struct inode *inode, int 
> type)
> spin_lock(>lli_lock);
> /* VFS' acl_permission_check->check_acl will release the refcount */
> acl = posix_acl_dup(lli->lli_posix_acl);
> +   forget_cached_acl(inode, type);
> spin_unlock(>lli_lock);
>
> return acl;
> --
> 1.7.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH] staging: lustre: llite: drop acl from cache

2016-05-23 Thread James Simmons
Commit b8a7a3a6 change get_acl() for posix xattr to always cache
the ACL which increases the reference count. That reference count
can be reduced by have ll_get_acl() call forget_cached_acl() which
it wasn't. When an inode gets deleted by Lustre the POSIX ACL
reference count is tested to ensure its 1 and if not produces an error.
Since forget_cached_acl() was not called Lustre started to complain.
This patch changes ll_get_acl() to call forget_cached_acl().

Signed-off-by: James Simmons 
---
 drivers/staging/lustre/lustre/llite/file.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index f47f2ac..0191945 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -3124,6 +3124,7 @@ struct posix_acl *ll_get_acl(struct inode *inode, int 
type)
spin_lock(>lli_lock);
/* VFS' acl_permission_check->check_acl will release the refcount */
acl = posix_acl_dup(lli->lli_posix_acl);
+   forget_cached_acl(inode, type);
spin_unlock(>lli_lock);
 
return acl;
-- 
1.7.1

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


Re: [PATCH 01/54] MAINTAINERS: Add file patterns for ion device tree bindings

2016-05-23 Thread Laura Abbott

On 05/22/2016 02:05 AM, Geert Uytterhoeven wrote:

Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.

Signed-off-by: Geert Uytterhoeven 
Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: de...@driverdev.osuosl.org
---
Please apply this patch directly if you want to be involved in device
tree binding documentation for your subsystem.
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 283f35b6be6907f5..6b4b2447589f36fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -781,6 +781,7 @@ M:  Laura Abbott 
 M: Sumit Semwal 
 L: de...@driverdev.osuosl.org
 S: Supported
+F: Documentation/devicetree/bindings/staging/ion/
 F: drivers/staging/android/ion
 F: drivers/staging/android/uapi/ion.h
 F: drivers/staging/android/uapi/ion_test.h



This is kind of in flux but I'd rather be cc'ed if anyone tries to add
new items so

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


Re: [PATCH v2] ION: Sys_heap: Add cached pool to spead up cached buffer alloc

2016-05-23 Thread Laura Abbott

On 05/18/2016 08:03 PM, Chen Feng wrote:

Add ion cached pool in system heap. This patch add a cached pool
in system heap. It has a great improvement of alloc for cached
buffer.

With memory pressue alloc test 800MB in userspace used iontest.
The result avg is 577ms. Without patch it's avg is about 883ms.

v1: Makes the cached buffer zeroed before going to pool
v2: Add cached param in pool to distinguish wheather need to flush
cache at a fresh alloc.
Rework the shrink function.

Signed-off-by: Chen Feng 
Signed-off-by: Xia  Qing 
Reviewed-by: Fu Jun 


Acked-by: Laura Abbott 


---
 drivers/staging/android/ion/ion_page_pool.c   |  10 +-
 drivers/staging/android/ion/ion_priv.h|   5 +-
 drivers/staging/android/ion/ion_system_heap.c | 183 +-
 3 files changed, 133 insertions(+), 65 deletions(-)

diff --git a/drivers/staging/android/ion/ion_page_pool.c 
b/drivers/staging/android/ion/ion_page_pool.c
index 1fe8016..2c5e5c5 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -30,8 +30,9 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool 
*pool)

if (!page)
return NULL;
-   ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
-   DMA_BIDIRECTIONAL);
+   if (!pool->cached)
+   ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
+ DMA_BIDIRECTIONAL);
return page;
 }

@@ -147,7 +148,8 @@ int ion_page_pool_shrink(struct ion_page_pool *pool, gfp_t 
gfp_mask,
return freed;
 }

-struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order)
+struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order,
+  bool cached)
 {
struct ion_page_pool *pool = kmalloc(sizeof(*pool), GFP_KERNEL);

@@ -161,6 +163,8 @@ struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, 
unsigned int order)
pool->order = order;
mutex_init(>mutex);
plist_node_init(>list, order);
+   if (cached)
+   pool->cached = true;

return pool;
 }
diff --git a/drivers/staging/android/ion/ion_priv.h 
b/drivers/staging/android/ion/ion_priv.h
index 0239883..f3cb8b4 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -360,6 +360,7 @@ void ion_carveout_free(struct ion_heap *heap, 
ion_phys_addr_t addr,
  * @gfp_mask:  gfp_mask to use from alloc
  * @order: order of pages in the pool
  * @list:  plist node for list of pools
+ * @cached:it's cached pool or not
  *
  * Allows you to keep a pool of pre allocated pages to use from your heap.
  * Keeping a pool of pages that is ready for dma, ie any cached mapping have
@@ -369,6 +370,7 @@ void ion_carveout_free(struct ion_heap *heap, 
ion_phys_addr_t addr,
 struct ion_page_pool {
int high_count;
int low_count;
+   bool cached;
struct list_head high_items;
struct list_head low_items;
struct mutex mutex;
@@ -377,7 +379,8 @@ struct ion_page_pool {
struct plist_node list;
 };

-struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order);
+struct ion_page_pool *ion_page_pool_create(gfp_t gfp_mask, unsigned int order,
+  bool cached);
 void ion_page_pool_destroy(struct ion_page_pool *);
 struct page *ion_page_pool_alloc(struct ion_page_pool *);
 void ion_page_pool_free(struct ion_page_pool *, struct page *);
diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index b69dfc7..32a0ebf 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -26,16 +26,18 @@
 #include "ion.h"
 #include "ion_priv.h"

+#define NUM_ORDERS ARRAY_SIZE(orders)
+
 static gfp_t high_order_gfp_flags = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN |
 __GFP_NORETRY) & ~__GFP_RECLAIM;
 static gfp_t low_order_gfp_flags  = (GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN);
 static const unsigned int orders[] = {8, 4, 0};
-static const int num_orders = ARRAY_SIZE(orders);
+
 static int order_to_index(unsigned int order)
 {
int i;

-   for (i = 0; i < num_orders; i++)
+   for (i = 0; i < NUM_ORDERS; i++)
if (order == orders[i])
return i;
BUG();
@@ -49,47 +51,55 @@ static inline unsigned int order_to_size(int order)

 struct ion_system_heap {
struct ion_heap heap;
-   struct ion_page_pool *pools[0];
+   struct ion_page_pool *uncached_pools[NUM_ORDERS];
+   struct ion_page_pool *cached_pools[NUM_ORDERS];
 };

+/**
+ * The page from page-pool are all 

Re: [lustre-devel] [PATCH] posix acls: Move namespace conversion into filesystem / xattr handlers

2016-05-23 Thread Andreas Grünbacher
2016-05-23 23:06 GMT+02:00 James Simmons :
> Nak on the Lustre changes. POSIX ACLs are also handled in mdc_request.c.
> Besides POSIX ACLs lustre has created a extended ACL as well that is
> grouped in with posix ACL handling. This extended ACL is like POSIX acls
> except it also contains the state (deleted, modified, ...) of the ACL.
> Besides normal local access control list handling Lustre manages remote
> access control list handling. You can read about this handling is in
> llite_rmtacl.c. This code was written long before I became involved with
> lustre so the exact details are fuzzy to me. The guts of this are handled
> is located at:
>
> drivers/staging/lustre/lustre/obdclass/acl.c

I'm not sure we're talking about the same thing here. As far as I can
see, the only code path from getxattr(2) and settxattr(2) into lustre
is through ll_getxattr and ll_setxattr. So far, the vfs performed the
uid/gid mappings before calling into the filesystem. With this patch,
the filesystem performs this mapping instead. In the lustre case,
pretty much directly after entering ll_getxattr and immediately before
leaving ll_setxattr. The rest of the code has and still does operate
in the "init uid/gid namespace". Did I miss anything?

> A you probably have noticed Lustre has had an uptick in development
> which means the code is now changing all the time in staging. How should
> we handle the changes you are working in your own trees verses what is
> happing in staging. For example I'm looking at moving lustre to the
> xattr_handles.

Okay, great.

> Should I push it to you and wait until it works it way
> into Greg's tree.

Changing lustre to use xattr handlers does not dependent on any of my
pending xattr changes, only the other way around. Please copy me for
review and merge through Greg's tree as usual. Once I have your
changes on a public branch, I can merge that into my xattr inode
operation removal branch.

> What do the merge schedules look like.

I hope the {get,set,remove}xattr inode operations will go away in the
next merge window, so it would be good to have the lustre xattr
handler convestion on a public branch relatively soon if possible.

> Lastly the a_refcount for the POSIX acl changed with your xattr updates which 
> now
> causes lustre to crash :-(

You mean commit b8a7a3a6 "posix_acl: Inode acl caching fixes"? It
seems a "forget_cached_acl(inode, type);" before returning the acl in
ll_get_acl is missing -- but lustre still shouldn't crash because of
that.

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


Re: [PATCH net-next 0/5] hv_netvsc: cleanup after untangling the pointer mess

2016-05-23 Thread David Miller
From: Vitaly Kuznetsov 
Date: Mon, 23 May 2016 17:50:33 +0200

> After we made traveling through our internal structures explicit it became
> obvious that some functions take arguments they don't need just to do
> redundant pointer travel and get to what they really need while their
> callers already have the required information.
> 
> This is just a cleanup series with no functional changes intended. It
> doesn't pretend to be complete, additional cleanup of other functions may
> follow.

Cleanups and new features should not be submitted at this time since the
net-next tree is closed.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [lustre-devel] [PATCH] posix acls: Move namespace conversion into filesystem / xattr handlers

2016-05-23 Thread James Simmons

> Currently, getxattr() and setxattr() check for the xattr names
> "system.posix_acl_{access,default}" and perform in-place UID / GID
> namespace mappings in the xattr values. Filesystems then again check for
> the same xattr names to handle those attributes, almost always using the
> standard posix_acl_{access,default}_xattr_handler handlers.  This is
> unnecessary overhead; move the namespace conversion into the xattr
> handlers instead.
> 
> For filesystems that use the POSIX ACL xattr handlers, no change is
> required.  Filesystems that don't use those handlers (cifs and lustre)
> need to take care of the namespace mapping themselves now.
> 
> The only user left of the posix_acl_fix_xattr_{from,to}_user helpers is
> lustre, so this patch moves them into lustre.
> 
> Signed-off-by: Andreas Gruenbacher 
> ---
> 
> I'm reasonably confident about the core and cifs changes in this patch.
> The lustre code is pretty weird though, so could I please get a careful
> review on the changes there?

Nak on the Lustre changes. POSIX ACLs are also handled in mdc_request.c.
Besides POSIX ACLs lustre has created a extended ACL as well that is 
grouped in with posix ACL handling. This extended ACL is like POSIX acls 
except it also contains the state (deleted, modified, ...) of the ACL. 
Besides normal local access control list handling Lustre manages remote
access control list handling. You can read about this handling is in 
llite_rmtacl.c. This code was written long before I became involved with
lustre so the exact details are fuzzy to me. The guts of this are handled 
is located at:

drivers/staging/lustre/lustre/obdclass/acl.c

P.S

A you probably have noticed Lustre has had an uptick in development
which means the code is now changing all the time in staging. How should
we handle the changes you are working in your own trees verses what is
happing in staging. For example I'm looking at moving lustre to the
xattr_handles. Should I push it to you and wait until it works it way
into Greg's tree. What do the merge schedules look like. Lastly the
a_refcount for the POSIX acl changed with your xattr updates which now
causes lustre to crash :-(
 
> Thanks,
> Andreas
> 
>  drivers/staging/lustre/lustre/llite/Makefile   |  1 +
>  .../staging/lustre/lustre/llite/llite_internal.h   |  3 ++
>  drivers/staging/lustre/lustre/llite/posix_acl.c| 62 
> ++
>  drivers/staging/lustre/lustre/llite/xattr.c|  8 ++-
>  fs/cifs/cifssmb.c  | 41 ++
>  fs/posix_acl.c | 62 
> +-
>  fs/xattr.c |  7 ---
>  include/linux/posix_acl_xattr.h| 12 -
>  8 files changed, 107 insertions(+), 89 deletions(-)
>  create mode 100644 drivers/staging/lustre/lustre/llite/posix_acl.c
> 
> diff --git a/drivers/staging/lustre/lustre/llite/Makefile 
> b/drivers/staging/lustre/lustre/llite/Makefile
> index 2ce10ff..67125f8 100644
> --- a/drivers/staging/lustre/lustre/llite/Makefile
> +++ b/drivers/staging/lustre/lustre/llite/Makefile
> @@ -7,5 +7,6 @@ lustre-y := dcache.o dir.o file.o llite_close.o llite_lib.o 
> llite_nfs.o \
>   glimpse.o lcommon_cl.o lcommon_misc.o \
>   vvp_dev.o vvp_page.o vvp_lock.o vvp_io.o vvp_object.o vvp_req.o \
>   lproc_llite.o
> +lustre-$(CONFIG_FS_POSIX_ACL) += posix_acl.o
>  
>  llite_lloop-y := lloop.o
> diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h 
> b/drivers/staging/lustre/lustre/llite/llite_internal.h
> index ce1f949..d454dfb 100644
> --- a/drivers/staging/lustre/lustre/llite/llite_internal.h
> +++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
> @@ -1402,4 +1402,7 @@ int cl_local_size(struct inode *inode);
>  __u64 cl_fid_build_ino(const struct lu_fid *fid, int api32);
>  __u32 cl_fid_build_gen(const struct lu_fid *fid);
>  
> +void posix_acl_fix_xattr_from_user(void *value, size_t size);
> +void posix_acl_fix_xattr_to_user(void *value, size_t size);
> +
>  #endif /* LLITE_INTERNAL_H */
> diff --git a/drivers/staging/lustre/lustre/llite/posix_acl.c 
> b/drivers/staging/lustre/lustre/llite/posix_acl.c
> new file mode 100644
> index 000..4fabd0f
> --- /dev/null
> +++ b/drivers/staging/lustre/lustre/llite/posix_acl.c
> @@ -0,0 +1,62 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Fix up the uids and gids in posix acl extended attributes in place.
> + */
> +static void posix_acl_fix_xattr_userns(
> + struct user_namespace *to, struct user_namespace *from,
> + void *value, size_t size)
> +{
> + posix_acl_xattr_header *header = (posix_acl_xattr_header *)value;
> + posix_acl_xattr_entry *entry = (posix_acl_xattr_entry *)(header+1), 
> *end;
> + int count;
> + kuid_t uid;
> + kgid_t gid;
> +
> + if (!value)
> + return;
> + if (size < sizeof(posix_acl_xattr_header))
> + return;

Re: [PATCH net-next] tools: hv: Add a script for bonding synthetic and VF NICs

2016-05-23 Thread David Miller
From: Haiyang Zhang 
Date: Thu, 19 May 2016 10:23:38 -0700

> This example script creates bonding network devices based on synthetic NIC
> (the virtual network adapter usually provided by Hyper-V) and the matching
> VF NIC (SRIOV virtual function). So the synthetic NIC and VF NIC can
> function as one network device, and fail over to the synthetic NIC if VF is
> down.
> 
> Signed-off-by: Haiyang Zhang 
> Reviewed-by: K. Y. Srinivasan 

Anything added like this to the tree should be distro neutral.

Furthermore, net-next is closed and no new features should be submitted
at this time.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/1] scsi: storvsc: Filter out storvsc messages CD-ROM medium not present

2016-05-23 Thread Cathy Avery
When a virtual scsi DVD device is present with no image file
attached the storvsc driver logs all resulting unnecessary sense errors
whenever IO is issued to the device.

[storvsc] Sense Key : Not Ready [current]
[storvsc] Add. Sense: Medium not present - tray closed

Signed-off-by: Cathy Avery 
---
 drivers/scsi/storvsc_drv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 3ddcabb..f0efa07 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -966,7 +966,9 @@ static void storvsc_command_completion(struct 
storvsc_cmd_request *cmd_request,
if (scmnd->result) {
if (scsi_normalize_sense(scmnd->sense_buffer,
SCSI_SENSE_BUFFERSIZE, _hdr) &&
-   do_logging(STORVSC_LOGGING_ERROR))
+   !(sense_hdr.sense_key == NOT_READY &&
+sense_hdr.asc == 0x03A) &&
+   do_logging(STORVSC_LOGGING_ERROR)) 
scsi_print_sense_hdr(scmnd->device, "storvsc",
 _hdr);
}
-- 
2.5.0

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


Re: [PATCH 1/1] Staging: rdma: hfi1: sdma.c: Fixed coding style issues

2016-05-23 Thread Dennis Dalessandro

On Mon, May 23, 2016 at 12:06:02PM +0530, Shyam Saini wrote:

Fixed following checkpatch.pl warnings:
   Prefer 'unsigned int' to bare use of 'unsigned'
   Prefer READ_ONCE() over ACCESS_ONCE()


Same response [1] as to your previous patch. If you do spin the READ_ONCE 
bit please squash the two.


[1] http://marc.info/?l=linux-rdma=146400717024632=2

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


[PATCH 1/1] Staging: rdma: hfi1: rc.c: Fixed coding style issues

2016-05-23 Thread Shyam Saini
Fixed following checkpatch.pl warnings:
  Prefer 'unsigned int' to bare use of 'unsigned'
  Prefer READ_ONCE() over ACCESS_ONCE()

Signed-off-by: Shyam Saini 
---
 drivers/staging/rdma/hfi1/rc.c  | 12 ++--
 drivers/staging/rdma/hfi1/ruc.c |  6 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rdma/hfi1/rc.c b/drivers/staging/rdma/hfi1/rc.c
index 792f15e..fb3a6c1 100644
--- a/drivers/staging/rdma/hfi1/rc.c
+++ b/drivers/staging/rdma/hfi1/rc.c
@@ -421,7 +421,7 @@ int hfi1_make_rc_req(struct rvt_qp *qp, struct 
hfi1_pkt_state *ps)
goto bail;
/* We are in the error state, flush the work request. */
smp_read_barrier_depends(); /* see post_one_send() */
-   if (qp->s_last == ACCESS_ONCE(qp->s_head))
+   if (qp->s_last == READ_ONCE(qp->s_head))
goto bail;
/* If DMAs are in progress, we can't flush immediately. */
if (iowait_sdma_pending(>s_iowait)) {
@@ -1103,7 +1103,7 @@ void hfi1_rc_send_complete(struct rvt_qp *qp, struct 
hfi1_ib_header *hdr)
struct hfi1_other_headers *ohdr;
struct rvt_swqe *wqe;
struct ib_wc wc;
-   unsigned i;
+   unsigned int i;
u32 opcode;
u32 psn;
 
@@ -1196,7 +1196,7 @@ static struct rvt_swqe *do_rc_completion(struct rvt_qp 
*qp,
 struct hfi1_ibport *ibp)
 {
struct ib_wc wc;
-   unsigned i;
+   unsigned int i;
 
/*
 * Don't decrement refcount and don't generate a
@@ -1571,7 +1571,7 @@ static void rc_rcv_resp(struct hfi1_ibport *ibp,
 
/* Ignore invalid responses. */
smp_read_barrier_depends(); /* see post_one_send */
-   if (cmp_psn(psn, ACCESS_ONCE(qp->s_next_psn)) >= 0)
+   if (cmp_psn(psn, READ_ONCE(qp->s_next_psn)) >= 0)
goto ack_done;
 
/* Ignore duplicate responses. */
@@ -1970,9 +1970,9 @@ void hfi1_rc_error(struct rvt_qp *qp, enum ib_wc_status 
err)
}
 }
 
-static inline void update_ack_queue(struct rvt_qp *qp, unsigned n)
+static inline void update_ack_queue(struct rvt_qp *qp, unsigned int n)
 {
-   unsigned next;
+   unsigned int next;
 
next = n + 1;
if (next > HFI1_MAX_RDMA_ATOMIC)
diff --git a/drivers/staging/rdma/hfi1/ruc.c b/drivers/staging/rdma/hfi1/ruc.c
index a659aec..cb64c80 100644
--- a/drivers/staging/rdma/hfi1/ruc.c
+++ b/drivers/staging/rdma/hfi1/ruc.c
@@ -239,7 +239,7 @@ bail:
return ret;
 }
 
-static __be64 get_sguid(struct hfi1_ibport *ibp, unsigned index)
+static __be64 get_sguid(struct hfi1_ibport *ibp, unsigned int index)
 {
if (!index) {
struct hfi1_pportdata *ppd = ppd_from_ibp(ibp);
@@ -393,7 +393,7 @@ static void ruc_loopback(struct rvt_qp *sqp)
 
 again:
smp_read_barrier_depends(); /* see post_one_send() */
-   if (sqp->s_last == ACCESS_ONCE(sqp->s_head))
+   if (sqp->s_last == READ_ONCE(sqp->s_head))
goto clr_busy;
wqe = rvt_get_swqe_ptr(sqp, sqp->s_last);
 
@@ -929,7 +929,7 @@ void hfi1_send_complete(struct rvt_qp *qp, struct rvt_swqe 
*wqe,
enum ib_wc_status status)
 {
u32 old_last, last;
-   unsigned i;
+   unsigned int i;
 
if (!(ib_rvt_state_ops[qp->state] & RVT_PROCESS_OR_FLUSH_SEND))
return;
-- 
1.9.1

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


[PATCH 1/1] Staging: rdma: hfi1: sdma.c: Fixed coding style issues

2016-05-23 Thread Shyam Saini
Fixed following checkpatch.pl warnings:
Prefer 'unsigned int' to bare use of 'unsigned'
Prefer READ_ONCE() over ACCESS_ONCE()

Signed-off-by: Shyam Saini 
---
 drivers/staging/rdma/hfi1/sdma.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/rdma/hfi1/sdma.c b/drivers/staging/rdma/hfi1/sdma.c
index abb8ebc..c2e2856 100644
--- a/drivers/staging/rdma/hfi1/sdma.c
+++ b/drivers/staging/rdma/hfi1/sdma.c
@@ -234,7 +234,7 @@ static void sdma_put(struct sdma_state *);
 static void sdma_set_state(struct sdma_engine *, enum sdma_states);
 static void sdma_start_hw_clean_up(struct sdma_engine *);
 static void sdma_sw_clean_up_task(unsigned long);
-static void sdma_sendctrl(struct sdma_engine *, unsigned);
+static void sdma_sendctrl(struct sdma_engine *, unsigned int);
 static void init_sdma_regs(struct sdma_engine *, u32, uint);
 static void sdma_process_event(
struct sdma_engine *sde,
@@ -244,7 +244,7 @@ static void __sdma_process_event(
enum sdma_events event);
 static void dump_sdma_state(struct sdma_engine *sde);
 static void sdma_make_progress(struct sdma_engine *sde, u64 status);
-static void sdma_desc_avail(struct sdma_engine *sde, unsigned avail);
+static void sdma_desc_avail(struct sdma_engine *sde, unsigned int avail);
 static void sdma_flush_descq(struct sdma_engine *sde);
 
 /**
@@ -346,7 +346,7 @@ void sdma_wait(struct hfi1_devdata *dd)
}
 }
 
-static inline void sdma_set_desc_cnt(struct sdma_engine *sde, unsigned cnt)
+static inline void sdma_set_desc_cnt(struct sdma_engine *sde, unsigned int cnt)
 {
u64 reg;
 
@@ -472,7 +472,7 @@ static void sdma_err_halt_wait(struct work_struct *work)
 static void sdma_err_progress_check_schedule(struct sdma_engine *sde)
 {
if (!is_bx(sde->dd) && HFI1_CAP_IS_KSET(SDMA_AHG)) {
-   unsigned index;
+   unsigned int index;
struct hfi1_devdata *dd = sde->dd;
 
for (index = 0; index < dd->num_sdma; index++) {
@@ -491,7 +491,7 @@ static void sdma_err_progress_check_schedule(struct 
sdma_engine *sde)
 
 static void sdma_err_progress_check(unsigned long data)
 {
-   unsigned index;
+   unsigned int index;
struct sdma_engine *sde = (struct sdma_engine *)data;
 
dd_dev_err(sde->dd, "SDE progress check event\n");
@@ -657,7 +657,7 @@ static void sdma_set_state(struct sdma_engine *sde,
 {
struct sdma_state *ss = >state;
const struct sdma_set_state_action *action = sdma_action_table;
-   unsigned op = 0;
+   unsigned int op = 0;
 
trace_hfi1_sdma_state(
sde,
@@ -989,7 +989,7 @@ static void sdma_clean(struct hfi1_devdata *dd, size_t 
num_engines)
  */
 int sdma_init(struct hfi1_devdata *dd, u8 port)
 {
-   unsigned this_idx;
+   unsigned int this_idx;
struct sdma_engine *sde;
u16 descq_cnt;
void *curr_head;
@@ -1213,7 +1213,7 @@ void sdma_all_idle(struct hfi1_devdata *dd)
  */
 void sdma_start(struct hfi1_devdata *dd)
 {
-   unsigned i;
+   unsigned int i;
struct sdma_engine *sde;
 
/* kick off the engines state processing */
@@ -1229,7 +1229,7 @@ void sdma_start(struct hfi1_devdata *dd)
  */
 void sdma_exit(struct hfi1_devdata *dd)
 {
-   unsigned this_idx;
+   unsigned int this_idx;
struct sdma_engine *sde;
 
for (this_idx = 0; dd->per_sdma && this_idx < dd->num_sdma;
@@ -1351,7 +1351,7 @@ retry:
 
swhead = sde->descq_head & sde->sdma_mask;
/* this code is really bad for cache line trading */
-   swtail = ACCESS_ONCE(sde->descq_tail) & sde->sdma_mask;
+   swtail = READ_ONCE(sde->descq_tail) & sde->sdma_mask;
cnt = sde->descq_cnt;
 
if (swhead < swtail)
@@ -1557,7 +1557,7 @@ void sdma_engine_error(struct sdma_engine *sde, u64 
status)
spin_unlock_irqrestore(>tail_lock, flags);
 }
 
-static void sdma_sendctrl(struct sdma_engine *sde, unsigned op)
+static void sdma_sendctrl(struct sdma_engine *sde, unsigned int op)
 {
u64 set_senddmactrl = 0;
u64 clr_senddmactrl = 0;
@@ -1736,7 +1736,7 @@ static void init_sdma_regs(
 void sdma_dumpstate(struct sdma_engine *sde)
 {
u64 csr;
-   unsigned i;
+   unsigned int i;
 
sdma_dumpstate_helper(SD(CTRL));
sdma_dumpstate_helper(SD(STATUS));
@@ -1854,7 +1854,7 @@ void sdma_seqfile_dump_sde(struct seq_file *s, struct 
sdma_engine *sde)
u16 len;
 
head = sde->descq_head & sde->sdma_mask;
-   tail = ACCESS_ONCE(sde->descq_tail) & sde->sdma_mask;
+   tail = READ_ONCE(sde->descq_tail) & sde->sdma_mask;
seq_printf(s, SDE_FMT, sde->this_idx,
   sde->cpu,
   sdma_state_name(sde->state.current_state),
@@ -1999,7 +1999,7 @@ static int sdma_check_progress(
return -EAGAIN;
/* pulse the